Making Apache leak behind SSL
Posted 1 month, 1 week ago at 11:01 pm. 5 comments
I’ve been working on a really great product for terminating SSL and encrypting HTTP parameters in a FIPS-140-2 Level 3 hardware security module. This is really handy if you run an internet banking application or payment processing service and want to be able to collect or deliver credit-card related info (such as PINs, PANs, CVVs, etc) in a manner compliant with the hardcore PCI PIN Security Requirement (PCI-PSR). Some simple usages might be the ability to provide customer self-selected PIN numbers, or the ability to replace those “super secure” post office delivered PIN printer envelopes by allowing customers to register and receive their PINs from the internet banking platform.
Unfortunately, any internet banking application which deals with credit-card information is PCI-PSR non-compliant by default, purely because this sensitive information “pops” out in the clear in the web server. SSL obviously does a great job of securing the transportation of the traffic between browser and web server, but once that traffic is decrypted you’re screwed. And this is not purely a theoretical attack either - think malicious administrator schnyfing the HTTP packets off somewhere to be collected later.
So it’s a real problem, and I’d like to prove it by building a tool to grab packets out of apache memory space after SSL decrypt. I was kind of hoping this would be simple, and I started off by just making use of system tools commonly available to most Linux servers, such as strace, ltrace, and python. It turns out that apache is *actually* designed quite well, not allowing decrypted traffic to cross the system boundary, therefore making strace pretty useless. ltrace by default borks apache dead on startup, possibly because it doesn’t follow the fork() / clone() combination used by the worker-mpm threading model, so I gave up on this approach quite quickly. So thats as far as my initial investigation went, and I think I’ve got a much better idea of how to tackle this, the following doors are still open to me:
- Although I don’t get decrypted traffic out of strace, I do get all the ENcrypted traffic, including the SSL handshake / key exchange. I can schnife the key, then do the RC4 decrypt myself.
- Write a custom apache module which hooks into the apache stack and grabs traffic, this is really easy to do, but isn’t as elegant or edgy as I’d like. Some existing apache modules available already give us this, e.g. mod_forensic and mod_security
- Hack openssl to make it bleed, and dynamically overwrite the default reference to the openssl system library (using ldconfig, LD_LIBRARY_PATH, or hacking the new lib path into the apache binary directly). This one sounds like fun, and might be useful for making more than apache leak, but still not as great as I’d like
- Scrape apache memory directly from an external app - this sounds really appealing, but might have some issues. How long does the decrypted stream stay in memory and therefore how reliably can I grab packets? If I were apache I would zero my memory after handling the request, and close this door instantly on me. Also, I’d need to spend many moons researching linux memory management. So a potentially good last-resort approach for me.
And thats all I’ve got so far. Any other ideas?
