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.
Wednesday, May 6. 2009
SSL und andere Geschichten
Ein kurzer Abriss der Geschichte: Bis Ende der 90er wurde starke Kryptographie unter anderem von den USA als militärische Komponente gesehen (siehe WP/Export of crypto und USML). Gleichzeitig erfand Netscape den Verschlüsselungsstandard SSL, der als Basis für TLS diente. In der Kombination wurde die erste öffentliche Version von SSL (SSLv2) absichtlich unsicher gestaltet, um nicht durch US-Exportbestimmungen eingeschränkt zu werden. In aktuellen Browsern wird SSLv3 und TLSv1 verwendet. Der erste Netscape Browser mit SSL wurde mit 128-Bit symmetrischer Verschlüsselung als US-only Variante gebaut und mit 40-Bit zum Export für den Rest der Welt. Die so abgeschwächte "Verschlüsselung" kann heute in Minuten gebrochen werden.
In einer Phase des TLS-Protokolls handeln Server und Client aus, welche Verschlüsselungsmethode (Cipher) verwendet werden soll. Das OpenSSL-Tool zeigt leicht eine Liste der möglichen Cipher für auf OpenSSL basierende Anwendungen an:
Nicht verwenden möchte man eben SSLv2, unsichere 40-Bit Export-Cipher, niedrige 56-Bit oder garkeine Verschlüsselung (eNULL) oder keine Authentifizierung (aNULL). Übrig bleibt noch folgendes:
Einen Apache Webserver passend zu konfigurieren, macht nur eine Zeile aus:
oder noch besser
Randnotiz: Firefox zeigt mit CipherFox den aktuell verwendeten Cipher an.
Heute, etwa zehn Jahre nach dem Wegfall absurder US-Exportbeschränkungen antworten Webserver immer noch auf Anfragen mit SSLv2 oder mit LOW/EXPORT Ciphern. Das OpenSSL-Tool testet das gerne:
Leute, Leute, Leute, - und damit soll sich mein Internetbankingprovider angesprochen fühlen - schaltet bitte den alten und unsicheren Krempel ab.
In einer Phase des TLS-Protokolls handeln Server und Client aus, welche Verschlüsselungsmethode (Cipher) verwendet werden soll. Das OpenSSL-Tool zeigt leicht eine Liste der möglichen Cipher für auf OpenSSL basierende Anwendungen an:
$ openssl ciphers -v ALL:eNULL
DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1
DHE-DSS-AES256-SHA SSLv3 Kx=DH Au=DSS Enc=AES(256) Mac=SHA1
AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1
...
Nicht verwenden möchte man eben SSLv2, unsichere 40-Bit Export-Cipher, niedrige 56-Bit oder garkeine Verschlüsselung (eNULL) oder keine Authentifizierung (aNULL). Übrig bleibt noch folgendes:
$ openssl ciphers -v 'ALL:!SSLv2:!LOW:!EXPORT:!eNULL:!aNULL'
DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1
DHE-DSS-AES256-SHA SSLv3 Kx=DH Au=DSS Enc=AES(256) Mac=SHA1
AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1
...
Einen Apache Webserver passend zu konfigurieren, macht nur eine Zeile aus:
SSLCipherSuite ALL:!SSLv2:!LOW:!EXPORT:!eNULL:!aNULL
oder noch besser
SSLCipherSuite HIGH:!SSLv2:!EXP:!aNULL:!eNULL
Randnotiz: Firefox zeigt mit CipherFox den aktuell verwendeten Cipher an.
Heute, etwa zehn Jahre nach dem Wegfall absurder US-Exportbeschränkungen antworten Webserver immer noch auf Anfragen mit SSLv2 oder mit LOW/EXPORT Ciphern. Das OpenSSL-Tool testet das gerne:
$ openssl s_client -no_tls1 -no_ssl3 -cipher EXP -connect www.my-bank.foo:443
...
New, SSLv2, Cipher is EXP-RC2-CBC-MD5
...
Leute, Leute, Leute, - und damit soll sich mein Internetbankingprovider angesprochen fühlen - schaltet bitte den alten und unsicheren Krempel ab.
(Page 1 of 1, totaling 3 entries)
