Here at Byte Wizards HQ, we’ve seen a lot of suspicious activity from AWS servers for CSP Browser Reports lately. Let us explain:
Along with pages, sites can send security headers to a browser. These headers ask the browser to act in a particular way in regards to security. With these headers a site can define, for example, what sites scripts can run from and if inline scripts can run. This can, sometimes, cause issues with badly written plugins but it enhances site security considerably and keeps our clients and their users safe.
Along with those headers, there’s functionality to include where the browser can send back information about, for example, when there is an attempt to break those policies. This is known as a CSP report. Your browser sends it automatically if the header is there. We gather those reports and use them to generate logs. With those logs we can then see if there are plugin problems and additionally if the site is under attack from a particular ip address.
We started getting empty reports from the IP address 37.187.215.253. What was unusual about these reports was that they were completely empty. A little research showed that this was an AWS ubuntu server that was sending these mysterious reports. Remember I said that this is an instruction to a browser, so we’d expect only browsers to send these reports.
We have, one would suspect, a bad bot on our hands. Either it is an extremely badly programmed crawler bot that is reading urls from the headers, or more likely it is a bot scanning for security vulnerabilities. We reported it to Amazon.
Twice in fact, and got a message from Amazon that it had been “mitigated”. Also in that message was an insistence that they can’t tell us anything else.
“Mitigated” in this case meant that the bad actor simply jumped to new ip addresses. Eventually landing on 44.203.160.151 . In the meantime Amazon have either claimed they needed more information ( that they already have ! ) or simply ignored the issue.
Let’s take a look at the server logs for some of its requests:
44.203.160.151 - - [15/Apr/2024:02:04:56 +0000] "GET / HTTP/1.1" 301 4379 "-" "Mozilla/5.0 (Linux; Android 7.1.1; XT1710-02 Build/NDS26.74-36) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.125 Mobile Safari/537.36"
44.203.160.151 - - [15/Apr/2024:02:05:21 +0000] "GET / HTTP/1.1" 200 26902 "-" "Midori/0.1.10 (X11; Linux i686; U; en-us) WebKit/(531).(2)"
44.203.160.151 - - [15/Apr/2024:02:05:21 +0000] "GET /wp-admin/admin-ajax.php?action=cspreport HTTP/1.1" 200 4479 "-" "Mozilla/5.0 (Linux; Android 9; Mi MIX 2S) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3809.111 Mobile Safari/537.36"
44.203.160.151 - - [15/Apr/2024:02:05:57 +0000] "GET / HTTP/1.1" 200 26903 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.142 Safari/537.36 OPR/62.0.3331.119"
44.203.160.151 - - [15/Apr/2024:02:06:00 +0000] "GET /wp-admin/admin-ajax.php?action=cspreport HTTP/1.1" 200 4479 "-" "Mozilla/5.0 (Linux; Android 9; CPH1859) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3809.111 Mobile Safari/537.36"
The top request at 02:04:56 is getting the home page of the site. The response is a permanent redirect, so we can assume this was trying to get the http version. These days, that in itself is a sign it’s a bot. Notice the browser user agent – it’s claiming to be Mozilla/5.0 on Android 7.1.1. But we know this is an AWS ubuntu server.
It comes back 25 seconds later, which is a particularly long time to follow a redirect and it has a completely different user agent. This time it’s claiming to be Midori running on X11 on Linux.
In the same second it has processed the headers and fired off a blank CSP report to the url included in the headers of the home page. Note here we can tell it’s the blank report because it’s a GET request, there’s no POST data.
Despite it being exactly the same second, the user agent has once again changed to claim it is Mozilla running on Android 9.
This sequence then repeats without the original getting of the http version with the redirect. Again, with a different set of browsers. Clearly the browser strings are just randomized each time.
It is, of course, somewhat trivial for us to ban this scanning bot based on its behavior. But we feel that it is important for Amazon to take responsibility for such activity on its network. It’s not okay to tell reporters that the problem is mitigated, when it has simply been switched to another ip address and it’s not okay to allow bots to continue to scan after they have been reported. It is, frankly, Amazon’s responsibility to operate it’s network and services properly and responsibly and to take all possible action to eliminate bad actors – not to ignore things because it’s more profitable for them to let others suffer the consequences of their lax policy on taking action.
