Making Heartbleed Lab work for Ubuntu 20.04 about seed-labs

[LuminousXLB]

I'm not able to download the 2004 VM. Do I have a wrong link?

[kevin-w-du]

Sorry, I updated the image. Here is the new link: https://seed.nyc3.cdn.digitaloceanspaces.com/SEED-Ubuntu20.04.zip

[LuminousXLB]

I've built one here https://github.com/LuminousXLB/heartbleed-docker

Here's an overview of the sizes of the containers

REPOSITORY   TAG                  IMAGE ID       CREATED          SIZE
heartbleed   victim-python3.8     f7eaab4e061c   5 minutes ago    86.9MB
heartbleed   server-20.04         c0259d54e8c2   13 minutes ago   398MB
heartbleed   attacker-python2.7   db5b820eab7d   23 minutes ago   136MB
ubuntu       20.04                4dd97cefde62   3 days ago       72.9MB
python       alpine3.8            f11f279751de   22 months ago    78.8MB

The size of the server container might be able to shrink by staged build, but I would prefer to do something else :)

[kevin-w-du]

Thanks. This is great. I will give it a test on my machine and then try to merge it into one of the SEED container image, so the cached layers from other labs can be reused for this lab. Really appreciate your efforts.

[LuminousXLB]

There's something to be noticed.
The self-signed key is currently compiled into the container, with a validity of 30 days.
Thus the certificate may need to be refreshed every 30 days or generated upon start instead of building.

But this may also not bother since we'll disable certificate verification when sending requests.

[kevin-w-du]

I tried it. It does work, but I couldn't get anything useful from the returned data. In the original Heartbleed lab, we are able to get the admin's password from the server (if we try enough times). I saw that in the setup, the client keeps talking to the server. If the attacker can get some of the client data back from the server, that will be great. I didn't get anything useful. The lab will be more interesting if we can get useful data via the attack.

[LuminousXLB]

That's really a problem.
It may take me some time to figure out which factor influences the harm of the vulnerability. It may be related to the version of OpenSSL, Apache httpd or some specific application deployed.
On the other side, you may also try installing PHP and deploying your original Elgg application based on this.

[kevin-w-du]

We have already tried everything that you have mentioned, without a success. The SSL part is done inside Apache, not in PHP or Elgg. Unfortunately, Apache comes with its own built-in SSL library, compiling it with the older version of OpenSSL or use an older Apache on the new OS is a difficult (we haven't had any success so far). With your efforts, we are getting closer to our goal. Hopefully somebody else could build on top of your work and carry it to the next level. It just a matter of time. Thanks.

[Tweeks-va]

Hey guys.. just monitoring this.. so you've made containers that use/rely on older distro bases.. with vulnerable libraries? Have you tried pulling the source ofr those older (unsupported) OpenSSL packages and manunally creating your CSR/CRT with the -x509 -days 5000 option?.. (creating the CSR and CRT in one movement). Thread on this here:
https://serverfault.com/questions/920461/why-openssl-ignore-days-for-expiration-date-for-self-signed-certificate

I think doing this and keeping it all packages within a container is a great plan, if possible. I have some x509/cert/docker guru friends from Rackspace I can also sick on this issue. Lemme know if interested.

[kevin-w-du]

We will do this for sure. We actually have a lab (PKI Lab) that does this, so it should be pretty easy to set up the certificate like this. There is no need to do it right now, because we haven't figured out how to solve the problem I listed above. Once we have resolved that problem, we will definitely do what you have suggested.

[Tweeks-va]

Super.. ping me when ready to let me know exactly what you still need.