A watering hole attack is an indirect attack on a victim. Rather than directly attacking the victim’s network, the attacker attacks a web site that the victim’s employees are likely to visit. Then the attacker attacks the victim’s network, via its own workstations, from that web site. A former colleague asked me how you protect against watering hole attacks, and I thought this was a good exercise. So here are some strategies for watering hole attack prevention.
There’ve been some stories floating around about how to make your IT department spy on you. The advice is good. The question you may be asking is how much does your IT department really know? Or, more directly, is my IT department spying on me?
I can’t answer the second question with certainty. But the first question is a lot. I’ll tell you a story.
Last week at work, I noticed some odd events in an event log, and when I investigated them, I found they were part of a failed ransomware attack. This got me thinking about how to prevent ransomware at home.
Ransomware, if you aren’t familiar, is an attack that encrypts your data and demands a ransom, usually around $300, in bitcoins, and you get a short deadline until it destroys your files. More often than not, paying the ransom is the only way to get the files back, so it’s much better to prevent it.
I had a Java app pointing at a Forcepoint (formerly known as Websense) proxy server. The proxy server wasn’t working, and the app was giving me a 407 error.
We had Websense set to require NTLM authorization, but it turns out Java won’t do NTLM, so the Java traffic wasn’t even showing up in the monitor.
My workaround was to have users open a browser, then go to any web page immediately before opening the app. By letting the browser authenticate for it, the Java app worked thanks to Websense having the credentials cached.
If you want, you can launch the applet with a batch file that uses IEcapt to hit any web page, then starts the applet.
One of the best things you can do to improve your security in a corporate environment is to limit the use of Java, or whitelist Java. Undoubtedly there will be one or more legacy web applications your company uses that require Java, and it’s almost inevitable that at least two of them will be certified for one and only one version of the JRE, and it won’t be the same one.
Believe it or not there’s a solution to the problem of conflicting JREs, but it took me years to find it, because I had no idea that Oracle called it “Deployment Rule Set.” The secret’s out now. If you run Java, and you want security, you need Deployment Rule Set.
IT jobs aren’t as easy to come by as they were 20 years ago, but web app pentesting is one subset of the field that I don’t see slowing down any time soon. Unfortunately it’s a poorly understood one.
But if you spent any significant time in the 1980s or early 1990s abusing commercial software, especially Commodore and Apple and Atari and Radio Shack software, I’m looking at you. Even if you don’t know it, you’re uniquely qualified to be a web app pentester.
Microsoft rushed out an out-of-band patch, MS15-078, to deal with active exploits in their font driver yesterday. Since pushing out patches takes time, my boss asked me what we could do to mitigate the issue in the meantime.
The biggest threat, by far, is exploit-bearing fonts being downloaded from web sites. Ideally you only install trusted fonts from trusted sources locally on your workstations, right? If not, I suggest you start that practice as well.
You have a couple of options when it comes to blocking fonts in browsers.
Perhaps I should have titled this “When SSL isn’t foolproof security,” but it’s too late now. Oh well.
When you’re sitting on a strange network (not your home or work network), SSL is vulnerable to a classic man-in-the-middle attack. If you’re paying attention, you should know if your session is being hijacked. But who’s paying attention?