Testing for "reverse" Heartbleed | Hacker News Reader

Testing for "reverse" Heartbleed

blog.meldium.com

149 pointsborisjabes18 comments

If you don't want to expose your client to a third-party, you can download the pacemaker[1] (Python 2/3) tester locally and test that way.

[1] https://github.com/Lekensteyn/pacemaker

So when NetCraft's report [0] shows 17% of servers out there appear to be vulnerable, that's just for one direction ... internal servers using HTTP in the other direction might not get patched immediately since they're "not vulnerable". Sheesh.

----------------------------------------

[0] http://news.netcraft.com/archives/2014/04/08/half-a-million-...

Note: while building this tool, we discovered key sites that were patched yet still vulnerable to Heartbleed including reddit! (now fixed)

Patched, but still vulnerable... how come?

They probably patched their public-facing web servers, but not their internal link-fetching app servers.

Their public-facing servers (that receive requests) were patched but not the code that made outbound HTTP requests.

Can wordpress be coaxed into performing outbound requests? Pingbacks and the like? Next-level malicious spam comments forcing WP into heartbleeding outbound, even if the wordpress install itself never had SSL?

It can be coaxed into performing outbound requests, whether it is related to this specific issue I wouldn't know.

http://blog.sucuri.net/2014/03/more-than-162000-wordpress-si...

They are pretty good at staying on top of WP related vulnerabilities.

That's rough. I bet there are a lot of sloppy wordpress installs that never bother patch the heartbleed thing "since they're not using SSL".

e: "sloppily maintained", if you will

As far as I understand, the sloppy ones are the sysadmin behind those sites, not the WordPress installs. And as far as I know, lazy sysadmins don't discriminate regarding what technology they are lazy with.

Actually, they do generally discriminate.

Software which is easy to set up initially, but hard to upgrade, tends to be much more likely to be out of date than software which is easier to upgrade.

Things that consist of "a big blob of PHP plus a lot of extensions" tend to fall into this camp. PHP apps are generally very easy to get set up the first time, and popular ones like Wordpress have lots of extensions you can add on; but then once you've been running that for a while, you discover that if you upgrade, these n extensions all break, and rather than bothering to find replacements, you just don't bother upgrading.

How do you fix this? Make upgrading easy, don't rely on extensions, or make sure you have bulletproof, stable APIs so that no one worries "if I upgrade, all these things are going to break."

Since 3.7 WordPress auto-upgrades itself in the background (for minor versions), like Chrome does. So not sure what are you talking about.

I don't understand what I am supposed to do with the URL they generate. Can someone explain this?

You give a URL that exists on an HTTPS webserver you control that you've patched to send SSL Heartbeats that have a payload size much greater than the real payload.

If the client code (at whatever site you are targeting) is vulnerable then each heartbeat response you get from the client site may give you up to 64KB of its memory contents.

curl on cygwin seems to be vulnerable.

As if this couldn't get worse...

There is an update available to openssl 1.0.1g which fixes the issue with curl. Just run setup.exe again to get it.

Heartsuck?

I don't trust.

Reply on news.ycombinator.com