БэФ블로그 - Security

Virtual Meta-Scripting Bytecode for PHP and JavaScript

nospam@example.com (БэФ) — Tue, 01 Jun 2010 14:32:00 +0200

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]

VirtualDocumentRoot and ImaginaryProtection

nospam@example.com (БэФ) — Sat, 09 May 2009 17:39:00 +0200

Apache's mod_vhost_alias provides a neat little feature for easing up virtual host configurations:

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.

SSL und andere Geschichten

nospam@example.com (БэФ) — Wed, 06 May 2009 09:57:00 +0200

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:

$ 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.