The Mossad 2019 Challenge - Part 2
The second challenge begins.
When visiting the included URL - missilesys.com, we’re introduced with a “not welcome” page:
Upon inspection of the HTML source, we can see the included image is linked from a different domain - dev.missilesys.com.
When registering, a CSR (Certificate Signing Request) and a private key is generated in the browser. The CN (Common Name) in the CSR is set to the username you requested. The CSR and private key are sent to the server, and it serves you with a password-protected PKCS #12 file (the password is the password we’ve given). PKCS #12 is a file format standard that stores a certificate and a private key.
The server, which is the CA (Certificate Authority), creates and signs our certificate, per the CSR we’ve sent. We can then use the .p12 file to authenticate against missilesys.com:
In the page there’s nothing interesting except the settings button. However, when trying to reach
/settings, we get an error:
You are not the administrator!
If we try to register with the
administrator username, we receive an error:
User already exists!. Changing the CSR in-place yields the same error, as the server probably validates the CN in the CSR.
Our primary playground is the CSR we’re sending to the server. As it’s generated in the client side, we can send whatever CSR we want, the question is whether the server will honor it.
The Chain of Trust
As we can see, the server is playing the role of the root certificate authority. The definition of a CA from wikipedia:
A certificate authority is an entity the issues digital certificates.
So simply put, any CA can issue a certificate, and right now we only know one CA. But the truth is, there can be more than one CA.
If the root CA signs a certificate for an intermediate CA, that intermediate CA can now sign end-entity certificates, thus creating a “chain of trust”.
So how do we ask to create a CA certificate from a CSR? Turns out you can add extension requests to CSR. The “Basic Constraints” extension specifies whether the certificate is a CA or not, and the maximum depth of valid certification paths.
So let’s add a Basic Constraints extension request to our .csr, first we’ll need to create
ca.conf with the following config:
We can now generate the private key and CSR for our intermediate CA, and verify the basic constraints exist in the .csr:
We can now send the POST request to the server to get the .p12 file, and check if we got a CA cert:
As you can see the CA is set to TRUE. Now that we’re a valid intermediate CA, we can sign an underlying certificate with the CN of ‘administrator’. First, generate a CSR:
Now let’s extract our intermediate CA certificate from the .p12 file:
Now we’re ready to create and sign the new administrator certificate:
So now we have admin.crt, all we need is to prepend that certificate to our already existing chain. To do that, we’ll first extract the root CA certificate (that belongs to the server), then we’ll
cat them together into a .pem file and create a final PKCS #12 file:
Now you can import final.p12 to your certificates, and use that to identify against the server. If you were to look at the certificate chain, this is what you would see:
We now own the
administrator end-entity certificate. Let’s access the
This seems to be some sort of telnet client, and a list of hosts in the LAN and their ports. If we tried to connect to any of the hosts with port 23, we would get an error:
Only one connection at a time is allowed.
However, port 80 on 10.0.0.1 seems to work correctly. We can input raw HTTP requests into the textbox. I have sent a GET to /:
We got a response! The internal domain seems to be different, as it’s returning a cookie for
.missilesystem.com. The page would look like this:
After sending a GET request to /settings, we receive a
302 Found response with a redirect to /. So something’s missing. After trying a bit of different things, it appears that adding the
SID cookie from the previous request allows you to access the settings page.
In the returned page, we can see a button to turn off the management system:
So all we need is to POST to /settings now, with our cookie.
After sending the POST, we’ll be redirected to the completion page: