Sometimes in security, you can do big things without spending large sums of money. In fact, during his talk at ShmooCon on Friday, Rob Fuller (@mubix) outlined a number of steps that organizations can take to better protect themselves. But the key takeaways from his talk are that each of the mitigations and processes mentioned are free (or otherwise low cost and nearly free), and can be implemented with next to no effort. All that's required is an investment of time.
On stage, Fuller said to think of EMET as a bouncer at the door, that protects memory from any kind of funny business that you tell it too. That's actually a fair assessment of the tool. However, there's been some great research into EMET for those who need additional background. On the other side of that, there have been many researchers who have focused on ways to bypass protections offered by EMET, but despite that, organizations are still better off with EMET in play than without it.
"[EMET] is opt-in. So it only protects things that you tell it to protect. Now Microsoft comes out with a configuration that it knows is good, but it's definitely opt-in," Fuller said during an interview with Salted Hash after his talk.
"It's not AV. So it's not adding any kind of overhead to your system. It's adding a hook into the things you tell it to add a hook into, and it's not encumbering the client any more than you have. Finally, it's the only thing that you cannot care about the logging on, because it's either blocking something or it's not seeing it."Blocking Java UA at the proxy:
Blocking the Java User Agent, or at the very least, the User Agent used by outdated Java installations will completely halt attacks using Java as a pathway. This trick works equally as well over SSL and on both OS X and Windows too. So no matter how the malicious Java is being served, if the User Agent is blocked, the attack is null and void.
Fuller said that he noticed this trick when he was running Phishing campaigns for an organization a while back, during a pen testing gig.
"All I have to do is initiate a fake Java piece of code that doesn't do anything, just tell it that it needs this class that doesn't exist; and then based on that User Agent, I load whatever exploit that it's going to use," he said during an interview.
To an attacker, once the Java User Agent is blocked, the only guess that can be made is that the victim doesn't have Java installed or the plug-in was disabled. However, while this trick is great for preventing Java-based attacks, it isn't an excuse to avoid patching Java regularly, nor is it an excuse to use outdated installations in production environments.Vulnerability reporting, rather than vulnerability scanning:
While scanning tools will flag all the critical vulnerabilities within an organization, those scans don't say much about actual exploitability of a given item. It's important to tune that data and focus on the issues that could actually have an impact to the organization.
If a vulnerability scan shows a critical issue, but the vulnerability isn't exploitable, or further still; the system isn't accessible to the outside or only available to a small number of people inside, it's not necessarily something to panic over. Opting for vulnerability reporting over scanning is about identifying the real risk of the vulnerability and the location, Fuller said. Implementing this will require that both system users and owners are in the loop, and that discussions focus on risk.HIPS – Turn the prevention on:
Various AV solutions and HIPS providers offer category detection and prevention, but this feature is often ignored. On the whole, HIPS is a rather powerful layer of protection, yet if prevention isn't enabled, it's just another tool that throws random alerts.
The logic behind not enabling prevention is actually understandable. HIPS can break things if enabled fully, because most HIPS solutions don't know your organization, such as custom applications. This is why many organizations choose to disable its most useful function. But if categories are turned on, and prevention and alerting are enabled, then an attacker dumping passwords is blocked (e.g. prevented from doing so), and there is an alert generated.
"It's a simple, easy fix," Fuller says. "I see so many organizations that have HIPS installed, that just do the alerting."
Sometimes the alert triggered could be a user who was just curious. But a vast majority of the time, alerts focused on malicious acts or tools are a warning that there's someone in your network that hasn't been detected by any other means, and you'll know this conclusively because the alert just flagged a tool they attempted to use that was deleted.Crowdsourcing security:
Another tip mentioned by Fuller is crowdsourcing security. It has a bit of a cost on the backend, but it could lead to huge payoffs down the line. In addition, there is the bonus of expanding on any user awareness initiatives that are in place.
The goal is to reward users who report suspicious emails or attachments, and reward those who come forward if they feel they've made a mistake by accessing the same. Make a big deal out of the employee's efforts, and use this situation to teach them should a report be invalid, by explaining the issue fully in simple language.
While the company doesn't have to spend large sums of money on the reward scheme, the cost of a lunch outing or gift card is far less than the expense of recovering from a security incident. Once the program is in full swing, and employees are freely sharing information and keeping an eye out for problematic issues, the company will have turned them into individual IDS systems.Other considerations:
Fuller also referenced some easily obtained protections, such as null routing WPAD to 127.0.0.1 and turning off NetBIOS resolutions domain wide. Furthermore, he encouraged the disabling of forward lookups on internal DNS servers. Finally, Fuller also reminded those in the audience to send all actionable alerts through the helpdesk and to stop leaving them out of the loop.