Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Making Heartbleed Lab work for Ubuntu 20.04 #2

Open
kevin-w-du opened this issue Sep 28, 2020 · 11 comments
Open

Making Heartbleed Lab work for Ubuntu 20.04 #2

kevin-w-du opened this issue Sep 28, 2020 · 11 comments
Labels
enhancement New feature or request help wanted Extra attention is needed network category of labs: network security

Comments

@kevin-w-du
Copy link
Member

Right now, the Heartbleed lab can only be conducted on our Ubuntu 12.04, because the versions of the OpenSSL in newer Ubuntu OSes have already fixed the problem. I really want to port this lab to our newest VM, Ubuntu 20.04. In theory this should be doable, because all we need to do is to install the older OpenSSL library, which is quite easy to do. However, we haven't succeeded yet in making this lab work for Ubuntu 16.04. Since we will soon migrate all our labs to Ubuntu 20.04, we will directly do it in 20.04. Help is needed to make this work. I added some details in the TODO.md file inside the Heartbleed lab folder.

@kevin-w-du kevin-w-du added enhancement New feature or request help wanted Extra attention is needed network category of labs: network security labels Sep 28, 2020
@LuminousXLB
Copy link
Contributor

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

image

@kevin-w-du
Copy link
Member Author

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

@LuminousXLB
Copy link
Contributor

LuminousXLB commented Mar 7, 2021

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
Copy link
Member Author

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
Copy link
Contributor

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
Copy link
Member Author

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
Copy link
Contributor

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
Copy link
Member Author

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
Copy link

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
Copy link
Member Author

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
Copy link

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

kevin-w-du pushed a commit that referenced this issue Sep 20, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed network category of labs: network security
Projects
None yet
Development

No branches or pull requests

3 participants