11

I'm seeing a lot of Content Security Policy (CSP) reports raised because of client-side malware. Many have "blocked-uri" entries like randomstring.cloudfront.net, something.akamaihd.net and so on.

I would like to detect CSP reports caused by malware, so I can ignore them. Ignoring *.cloudfront.net doesn't seem right, is there a way?

Anand Bhat
  • 121
  • 5
  • Great question! How do you know they are caused by client-side malware? – D.W. Jul 01 '14 at 16:07
  • I Googled the blocked URIs, e.g.: cdncache-a.akamaihd.net, savingsslider-a.akamaihd.net – Jackson Pauls Jul 01 '14 at 20:32
  • wouldn't a web anti virus make your task easier? – Ebenezar John Paul Jul 14 '14 at 11:51
  • Not for this, no. – Jackson Pauls Jul 14 '14 at 15:57
  • I would use regex Because of the fact its a randomly generated number string Example Regex("('az-ZA-09')\.cloudfront") i believe that should help.. my regex is crap, but that should help out a bit i hope – EnergyBrew Jul 31 '14 at 07:23
  • The regex I think you intended to write ('[a-zA-Z0-9]+.cloudfront') is functionally equivalent to *.cloudfront.net. – Mark Jul 31 '14 at 08:41
  • 1
    @MichaelGuier Ignoring everything from, say, cloudfront is easy. But the reports may also contain cloudfront URLs that aren't used by client-side malware, and I don't want to ignore those. – Jackson Pauls Jul 31 '14 at 12:03
  • 3
    Why do you want to ignore CSP reports caused by malware ? That can be dangerous; it is like ignoring the Google Safe browsing service –  Aug 13 '14 at 08:17
  • @begueradj I'm interested in CSP reports raised because of any XSS vulnerabilities in my app, I'm not interested in what malware clients have installed. – Jackson Pauls Aug 13 '14 at 09:14
  • Are you interested in the reports communicated by a third party ? If yes, you can check those of free and even open source online web vulnerabilities scanners (http://wepawet.iseclab.org/samples.php) –  Aug 13 '14 at 09:46
  • @begueradj Thanks, but I'm only interested in CSP reports in this question. – Jackson Pauls Aug 13 '14 at 09:53
  • @jackson, thank you for answering begueradj's question about why you want this; could you add that information to the question? It really helps me to understand what you're asking and why. – MCW Aug 13 '14 at 12:39
  • @MarkC.Wallace My question is just about filtering out CSP reports raised because of client malware. I did mention XSS vulnerabilities (the first example that came to mind, sorry if that was misleading), but I do want to see all other CSP reports: XSS vulnerabilities, botched CSP configuration issues, etc... – Jackson Pauls Aug 13 '14 at 12:59
  • 1
    @jackson - that helps - but it would help more if you put those facts in the question, rather than in the comments. – MCW Aug 13 '14 at 13:02
  • @MarkC.Wallace yes, you are right, to be honest i do not understand exactly the meaning of this question even if it sounds interesting. –  Aug 13 '14 at 20:24
  • I'm pretty sure you can't just write a simple pattern on the URI itself, because cloudfront, akamai, and so on are legitimate services that are occasionally used for various malicious purposes. Since they are a type of Content Distribution Network (CDN), some of their files may be malware, such as Flash, Java, etc, but most payloads are benign or even useful, which is why those services exist (to distribute network load across multiple devices). – phyrfox Aug 19 '14 at 13:26
  • There are so many qeustions posted to Security.se "I'm having all these strage log entries", but then they never post the logs. I feel like most people treat hackers like magic. It as if these OPs expect us to say: "Oah yeah, let me just root your box and copy over those log files..." – rook Nov 01 '14 at 18:35

3 Answers3

2

I highly doubt that these CSP reports where generated with client-side malware. I suspect this the behavior of a load-balancer that is leading to positives. Malware authors prefer hosting their applications using infrastructure with less oversight, where as Akamai and Cloudflare provide security services and have their own highly skilled security teams.

Without actually seeing these logs, no one can help you. The first thing I would do is download the JavaScript in the CSP report and perform an malware analysis on it.

rook
  • 46,916
  • 10
  • 92
  • 181
1

The question is mainly what you mean by "ignoring". I recommend you collect every CSP violation, but only act upon the ones that are obviously unrelated to your website. Your analysis & visualization steps should take care of that.

The cloudfront hosts are likely not malware but scripts running from browser extensions.

freddyb
  • 521
  • 3
  • 9
0

Akamai and Cloudfront are both names associated with CDN's. In many cases CDN's are hosting collection sites for metadata associated with IP addresses for tracking purposes as well as their initially intended use of caching large files for various websites. Although these particular names may or may not be associated with legitimate traffic, your lack of concern regarding client side malware is all too prevalent in our world and suggest you remediate that belief system by doing some research regarding how malware has been one of the biggest security threats in last decade.

Malware is associated with the vast majority of compromised environments.

Owning a desktop is the first step of owning it all.

Understanding that you are probably dealing with more CSP violations than is humanly possible to investigate there is a certain amount of empathy associated with your position. Building a body of knowledge, even if you have to use a spreadsheet, about the various domains that are being listed in your CSP is the long term key to success, especially if you are apart of a small team or are a one man show. Once you understand these domains and investigate their registrations and content they may share, you can begin to look into their ToS and even capture traffic too and from these url 'strings' you are seeing (ensure this machine is isolated). Your packet captures and time investment should assist your in beginning to identify legitimate and illegitimate DNS names and will allow you to focus on more self evident risk.

It is best to keep in mind that most compromises are shown in various systems and sysops ignored them due to the vast amount of false positives they are culling through. They were alerted but they weren't alert and process driven in their culling. In short, trust nothing until you can prove it trustworthy.

Citizen
  • 378
  • 3
  • 16