

Testing for "reverse" Heartbleed - borisjabes
http://blog.meldium.com/home/2014/4/10/testing-for-reverse-heartbleed

======
dahjelle
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](https://github.com/Lekensteyn/pacemaker)

------
BrandonMarc
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-...](http://news.netcraft.com/archives/2014/04/08/half-a-million-
widely-trusted-websites-vulnerable-to-heartbleed-bug.html)

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

~~~
pygy_
Patched, but still vulnerable... how come?

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

------
0x0
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?

~~~
opendais
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...](http://blog.sucuri.net/2014/03/more-than-162000-wordpress-sites-used-
for-distributed-denial-of-service-attack.html)

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

~~~
0x0
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

~~~
rabino
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.

~~~
lambda
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."

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

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

~~~
alexkus
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.

------
xg15
curl on cygwin seems to be vulnerable.

As if this couldn't get worse...

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

------
automatthew
Heartsuck?

------
31cup
I don't trust.

