Everyone has been atwitter lately over the heartbleed bug, and so I’m joining the bandwagon.
OpenSSL is used by a lot more than just public web servers and I wanted to know whether or not my ddwrt home router was vulnerable. I started by looking at the HTTP admin interface.
It required a surprising amount of sleuthing to determine what web server ddwrt uses. I found the source and it looked like SSL was handled by MatrixSSL. The readily available proof of concept scripts did not work against the admin interface and so I gave up investigating this avenue.
OpenVPN, on the other hand, looked like an attractive target. This service is public facing and links against OpenSSL. I could not find a good listing of what packages/versions are included in ddwrt releases to determine if my setup was vulnerable. The best I could find was a forum post that indicated it was vulnerable.
Great! But before I upgraded I wanted to see it in action.
I researched the protocol and examined some pcaps and wrote a simple script that:
- Listens for incoming TCP connections
- Wraps all data from the connected TCP stream into UDP packets following the OpenVPN spec.
- Strips the OpenVPN information from received UDP packets and plays them back on the TCP stream.
This simple TCP to OpenVPN UDP proxy server allowed me to run the various heartbleed POC’s against my vulnerable ddwrt router.
The OpenVPN wiki has a great page on what you can do to fix/mitigate this vulnerability.