|
This is a guest diary submitted by Remco Verhoef. The cloud is bringing a lot of interesting opportunities, enabling you to scale your server farm up and down depending on the load. Everything is being taken care of automatically by auto scale groups.There is nothing to worry about anymore. But this brings me to the following point, in particular, because IPv4 addresses are harder and harder to come by: How quickly are public IP addresses being reused and what if I can collect requests, specifically HTTP(s) requests, intended for a prior user of the IP. Easily said. I’ve created a server which will just store all requests in an Elasticsearch cluster, a client who does nothing more than just listening for http and https (with an expired self signed certificate) and a userdata script that automatically starts the client, waits for about 10 minutes and then shuts it down again. I’ve configured spot instances in multiple regions and kept it running for a while. When spot instances are being shut down (because of the price, or because the instance shuts itself down), it will automatically start a new instances if it is still within the given pricing range. About the results: I’ve loaded the Elasticsearch dataset into R for easy visualisation and querying and together with good old awk, sed, wc and grep I’ve been able to draw some interesting results. Within the dataset we found several occurrences with Amazon in the User-Agent. This leads to the following Amazon related user-agents:
The health check service checks if the host is online and if it returns the expected result (statuscode 200), it will include this server to the dns based load balancing configuration. Simple Notification Service Agent is being used to send notifications to the server. We’ve received several notifications, like cache keys expired, varnish flush caches, but also a load of messages containing userdata. The Amazon CloudFront traffic is traffic originated to the original webservers, of data that needs to be cached for a longer period of time. This is interesting as well, because you’ll be able to poison the cache for a long amount of time. An analysis on the other useragents gave some interesting results as well. We’ve seen the following useragents:
In total we’ve found 159 different user agents (with the version number stripped off). Which is a lot. The complete dataset contained ~80k requests. Those useragents are strange, not the variety I had expected. This seems just normal traffic passing a proxy or a gateway. Let’s look at the hostnames, in total we have encountered 578 different hostnames, containing a lot of interesting hosts . This is just a subset.
So this is really strange. What about the X-Forwarded-For headers, if it should have been destined to a proxy server, we should be able to find those. Looking at this traffic we didn’t see really awkward things, most of them were from left over dns entries for other hosts. One super weird thing though, is this traffic destined for www.datapool.vn. X-Forwarded-For: 25.34.94.111, 197.191.79.83, 162.63.120.125, 149.133.46.21, 21.186.158.233, 214.148.185.253, 249.166.69.42, 20.90.2.104 Host: www.datapool.vn Remote Address: 103.9.158.76 Where the remote address is from somewhere in Vietnam, but the X-Forwarded-For explains the request has been forwarded by 8! different proxy servers. If you look up the block owners of these proxy servers you’ll find these organizations:
So traffic from a vietnamese client address, via my Amazon server, with in the X-Forwarded-For the UK Defense as the Department of Defense with a vietnamese website as destination. Interesting. Don’t know how to position this, any ideas are welcome. Now I’m looking at the requesting addresses, retrieving all the netblock owners of the requesting addresses. This is not 100% solid, because netblock could change ownership in time. But lets see what it brings us. To have some focus, I’ve filtered out all the traffic with the com.google.* user-agents. This is traffic I wouldn’t expect to arrive at my systems. The netblock owners are the following:
In total there were 95 different originating ip addresses, with 1446 requests (with useragent com.google.*), which is just a small sample of the complete set. AT&T and Time Warner have done the most requests. So with all the data we’ve crunched, we’ve found the following cases:
This leaves us with the following attack scenarios:
Disclosure TimelineWe’ve disclosed our findings with Amazon and Amazon has implemented an IP cooldown feature, which should fix those issues. 2016/10/13: issue reported to Amazon. AWS confirms receipt of the report, and reaches out requesting additional information Disclaimer: it is possible that the dataset has been manipulated by forged requests, but as no-one knows about this research and the launch of spot instances where to random I don’t expect that to be the case. If you have any more questions just let me know. I’ll be happy to answer them. You can contact me using: @remco_verhoef I will be teaching next: Defending Web Applications Security Essentials - SANS Munich March 2019 |
Johannes 3370 Posts ISC Handler |
| Reply Subscribe |
Feb 28th 2017 1 year ago |
|
If you look up the block owners of these proxy servers you’ll find these organizations:
UBS AG (UBSAG) DoD Network Information Center (DNIC) DoD Network Information Center (DNIC) Computer Sciences Corporation (CSC-68) UK Ministry of Defence Airtel Ghana The Swatch Group Ltd So traffic from a vietnamese client address, via my Amazon server, with in the X-Forwarded-For the UK Defense as the Department of Defense with a vietnamese website as destination. Interesting. Don’t know how to position this, any ideas are welcome. ------------------------ Are those in order of traffic flow? |
Anonymous |
| Reply Quote |
Feb 28th 2017 1 year ago |
Sign Up for Free or Log In to start participating in the conversation!
