Abstract
Both PHP and JavaScript are frequently being targeted for exploiting web applications. This article elaborates on the idea of building a set of virtual machines on top of each programming language. As a result a single type of bytecode can be executed by both VMs. Particular emphasis is put on designing virtual machines to be most suitable for code obfuscation in a post exploitation scenario.
[PDF Article]
[Code]
Tuesday, June 1. 2010
Virtual Meta-Scripting Bytecode for PHP and JavaScript
Saturday, May 9. 2009
VirtualDocumentRoot and ImaginaryProtection
Apache's mod_vhost_alias provides a neat little feature for easing up virtual host configurations:
Now suppose the following not so uncommon scenario: Two IP addresses share the same host - let's say 10.0.0.10 and 10.0.0.11. One IP is meant for production services, the other IP may be totally unrelated. However, both IPs are configured for named virtual hosts with overlapping wildcards and share the same VirtualDocumentRoot:
Our second virtualhost beta.foo.bar blocks access to /protected/ - the first virtualhost has no such protection. Let's check out beta's protection manually:
Now, just for fun, the very same request goes to the other IP:
Please, keep that in mind when rolling out VirtualDocumentRoots on more than one IP with overlapping wildcard hostnames.
This module creates dynamically configured virtual hosts, by allowing the IP address and/or the Host: header of the HTTP request to be used as part of the pathname to determine what files to serve.
Now suppose the following not so uncommon scenario: Two IP addresses share the same host - let's say 10.0.0.10 and 10.0.0.11. One IP is meant for production services, the other IP may be totally unrelated. However, both IPs are configured for named virtual hosts with overlapping wildcards and share the same VirtualDocumentRoot:
NamedVirtualHost 10.0.0.10:80
NamedVirtualHost 10.0.0.11:80
<VirtualHost 10.0.0.10:80>
ServerName www.foo.bar
ServerAlias *.foo.bar
VirtualDocumentRoot /var/www/%0
</VirtualHost>
<VirtualHost 10.0.0.11:80>
ServerName beta.foo.bar
ServerAlias *.foo.bar
VirtualDocumentRoot /var/www/%0
<Location "/protected/">
Order deny,allow
Deny from all
</Location>
</VirtualHost>
Our second virtualhost beta.foo.bar blocks access to /protected/ - the first virtualhost has no such protection. Let's check out beta's protection manually:
$ telnet 10.0.0.11 80
Trying 10.0.0.11...
Connected to 10.0.0.11.
Escape character is '^]'.
GET /protected/ HTTP/1.1
Host: beta.foo.bar
HTTP/1.1 403 Forbidden
Date: Sat, 09 May 2009 15:25:38 GMT
Server: Apache/2.2.11 (Ubuntu)
Vary: Accept-Encoding
Content-Length: 290
Content-Type: text/html; charset=iso-8859-1
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>403 Forbidden</title>
</head><body>
<h1>Forbidden</h1>
<p>You don't have permission to access /protected/
on this server.</p>
<hr>
<address>Apache/2.2.11 (Ubuntu) Server at beta.foo.bar Port 80</address>
</body></html>
Connection closed by foreign host.
Now, just for fun, the very same request goes to the other IP:
# telnet 10.0.0.10 80
Trying 10.0.0.10...
Connected to 10.0.0.10.
Escape character is '^]'.
GET /protected/ HTTP/1.1
Host: beta.foo.bar
HTTP/1.1 200 OK
Date: Sat, 09 May 2009 15:23:22 GMT
Server: Apache/2.2.11 (Ubuntu)
Last-Modified: Sat, 09 May 2009 14:48:32 GMT
ETag: "e8127-1c-4697bd6c57000"
Accept-Ranges: bytes
Content-Length: 28
Vary: Accept-Encoding
Content-Type: text/html
secrets all over this page.
...and ponies.
Connection closed by foreign host.
Please, keep that in mind when rolling out VirtualDocumentRoots on more than one IP with overlapping wildcard hostnames.
Thursday, January 24. 2008
SWF in a nutshell and the malware tragedy
SWF - or otherwise known as the flash file format - recently caught my attention while discussing web security issues. It can be played on virtually any platform's browser nowadays, which makes it a perfect environment for cross-platform applications (including malware). But before getting into exploring our options of how to exploit the format, let's just get a brief insight into the binary structure of SWF.
The file starts with the string FWS or CWS, followed by an 8-bit version number and 32-bit file length field. In case of CWS all the remaining file contents are zlib compressed:
The complete SWF specification can be found on Adobe's site (registration required), or here.
Now, the uncompressed data part starts with a header followed by a list of tags.
Each tag acts as a container for a datatype, e.g. for a jpeg image, rgb color or an actionscript bytecode. A tag starts with a tag type identifier and the tag's length, followed by arbitrary data.
The complete swf looks like this:
As indicated, the last tag is a tag with tag type 0 and length 0 hence resulting in a 16 bit representation of 0.
If we wanted to analyze an SWF file, it would be best to uncompress where needed, parse the header and then break down each tag by its code first. When doing so with real world data we may encounter undocumented or unknown codes. There can be several reasons for these mysterious tag codes, for example the file could be corrupted or our parser could be incomplete. More likely, however, is either that a commonly used - yet undocumented - tag was used correctly according to the programmer's point of view (tag type IDs 16, 29, 31, 38, 40, 42, 47, 49, 50, 51,52, 63, 72), OR the tag was deliberately marked with an unknown code in order to hide bytecode or other data.
We'll go along with the latter case, so let's assume - just for a moment - that we are programming a malware flash file. As such our code needs to avoid detection and should be obfuscated as well. The actionscript2 bytecode as located inside doAction tags can issue a branch action (aka. jump or goto) which is ordinarily being used for loops and conditions. Each branch action comes with a relative address of the next action. Example:
Ominously the branch offset (here -0x16) is not restricted to the current code block, but could jump to an entirely different tag instead, where the code is being executed as if it were a code block. Example:
This way the code inside tag1 is hidden from ordinary SWF analyzer tools and can still be executed. In order to make it even harder to find the hidden code, random bytecode could be inserted in between actual bytecode, or dormant bytecode (which is never executed) could be used as distraction. Fortunately this technique is also really easy to detect since a checker only needs to be able to check for uncommon branch offsets, however most disassemblers (such as flare) can be fooled.
Another interesting way to hide code, which is by far not the last one, would be a base64 encoded SWF file ebmedded in an image of another swf file, such as
In the end it does not really matter, which way your code is protected or even if it is hidden at all, because there is no security or malware check anywhere within a flash advertising deployment process. An evil attacker could simply buy ad space from an ad broker, the delivered ad is then quickly checked (possibly manually) for style guidelines such as size or close buttons, and finally delivered to their ad servers. That's the end of the (slightly simplified) deployment process.
Let's explore a few technical possibilities on how to protect yourself from flash malware. (Non-technical solutions such as contract fines or national law are not applicable for the anonymous evil hacker.) Java applets - for example - can have signatures. Since there is no way specified to embed cryptographic signatures in SWF files, and by the way only few people would grasp the signature's relevance anyway, this is not a viable option here. Then there is a sort of capability whitelisting: The SWF file could be checked against allowed capabilities, which include having obfuscated code hidden in unknown tags as described above. The check could be done automatically on client side (e.g. by a browser plugin) or by a proxy either intermediately or on server side. But such a capability filter is yet to be written.
related URLs: https://www.flashsec.org/ http://osflash.org/
The file starts with the string FWS or CWS, followed by an 8-bit version number and 32-bit file length field. In case of CWS all the remaining file contents are zlib compressed:
[FWS] [Version] [Length] [Data] or [CWS] [Version] [Length] [Zlib Data]
The complete SWF specification can be found on Adobe's site (registration required), or here.
Now, the uncompressed data part starts with a header followed by a list of tags.
[Header] [Tag] [Tag] ...
Each tag acts as a container for a datatype, e.g. for a jpeg image, rgb color or an actionscript bytecode. A tag starts with a tag type identifier and the tag's length, followed by arbitrary data.
[tag code and length (16 bits)] [data (length bytes)]
The complete swf looks like this:
[FWS/CWS] [Version] [Length] [ [Header] [[Tag Code + Length] [Tag Contens]] ... [0] ]
As indicated, the last tag is a tag with tag type 0 and length 0 hence resulting in a 16 bit representation of 0.
If we wanted to analyze an SWF file, it would be best to uncompress where needed, parse the header and then break down each tag by its code first. When doing so with real world data we may encounter undocumented or unknown codes. There can be several reasons for these mysterious tag codes, for example the file could be corrupted or our parser could be incomplete. More likely, however, is either that a commonly used - yet undocumented - tag was used correctly according to the programmer's point of view (tag type IDs 16, 29, 31, 38, 40, 42, 47, 49, 50, 51,52, 63, 72), OR the tag was deliberately marked with an unknown code in order to hide bytecode or other data.
We'll go along with the latter case, so let's assume - just for a moment - that we are programming a malware flash file. As such our code needs to avoid detection and should be obfuscated as well. The actionscript2 bytecode as located inside doAction tags can issue a branch action (aka. jump or goto) which is ordinarily being used for loops and conditions. Each branch action comes with a relative address of the next action. Example:
0x00: action 1
0x01: some actions...
...
0x10: jump -0x10
Ominously the branch offset (here -0x16) is not restricted to the current code block, but could jump to an entirely different tag instead, where the code is being executed as if it were a code block. Example:
0x100: tag1 header with unknown code
0x104: code in tag 1
...
0x200: doAction tag
0x204: jump -0x100
This way the code inside tag1 is hidden from ordinary SWF analyzer tools and can still be executed. In order to make it even harder to find the hidden code, random bytecode could be inserted in between actual bytecode, or dormant bytecode (which is never executed) could be used as distraction. Fortunately this technique is also really easy to detect since a checker only needs to be able to check for uncommon branch offsets, however most disassemblers (such as flare) can be fooled.
Another interesting way to hide code, which is by far not the last one, would be a base64 encoded SWF file ebmedded in an image of another swf file, such as
<img src="data:application/x-shockwave-flash;base64,..."/>
In the end it does not really matter, which way your code is protected or even if it is hidden at all, because there is no security or malware check anywhere within a flash advertising deployment process. An evil attacker could simply buy ad space from an ad broker, the delivered ad is then quickly checked (possibly manually) for style guidelines such as size or close buttons, and finally delivered to their ad servers. That's the end of the (slightly simplified) deployment process.
Let's explore a few technical possibilities on how to protect yourself from flash malware. (Non-technical solutions such as contract fines or national law are not applicable for the anonymous evil hacker.) Java applets - for example - can have signatures. Since there is no way specified to embed cryptographic signatures in SWF files, and by the way only few people would grasp the signature's relevance anyway, this is not a viable option here. Then there is a sort of capability whitelisting: The SWF file could be checked against allowed capabilities, which include having obfuscated code hidden in unknown tags as described above. The check could be done automatically on client side (e.g. by a browser plugin) or by a proxy either intermediately or on server side. But such a capability filter is yet to be written.
related URLs: https://www.flashsec.org/ http://osflash.org/
(Page 1 of 1, totaling 3 entries)
