Information Security News
Photo gallery: NZ infosec industry shines at iSanz awards
New Zealand's information security community turned out in force last week for the inaugural iSanz Awards honouring people and organisation's who have set new standards for making the online space a safer and more secure place. And from dozens of ...
When you're a Fortune 500 company that's a favorite target of sophisticated hackers, it often makes sense to install security appliances at the outer edges of your network to stop attacks before they get far. Now, researchers say they have uncovered a vulnerability in such a product from security firm FireEye that can give attackers full network access.
The vulnerability, which is on by default in the NX, EX, AX, FX series of FireEye products, was FireEye last week, after researchers from Google's Project Zero privately reported it. It made it possible for attackers to penetrate a network by sending one of its members a single malicious e-mail, even if it's never opened. It's not uncommon for outsiders to find such critical flaws in a security product. Still, the proof-of-concept exploit underscores that such game-over threats often extend to some of a network's most critical equipment. As Google employee Tavis Ormandy explained in a blog post published Tuesday:
For networks with deployed FireEye devices, a vulnerability that can be exploited via the passive monitoring interface would be a nightmare scenario. This would mean an attacker would only have to send an email to a user to gain access to a persistent network tap—the recipient wouldn’t even have to read the email, just receiving it would be enough.
A network tap is one of the most privileged machines on the network, with access to employee’s email, passwords, downloads, browsing history, confidential attachments, everything. In some deployment configurations* an attacker could tamper with traffic, inserting backdoors or worse. Because FireEye devices typically have a secondary internet-connected interface for updates and management, the issue could even be wormable across the internet.
The devices are supposed to passively monitor network traffic from HTTP, FTP, SMTP connections. In instances where there's a file transfer, the security appliance will scan it for malware. Ormandy and fellow Project Zero researcher Natalie Silvanovich found a vulnerability that can be exploited through such a passive monitoring interface. The researchers used the JODE Java decompiler to reverse engineer Java Archive files used by the FireEye devices. They then figured out a way to get the appliance to execute a malicious archive file by mimicking some of the same features found in legitimate ones.
Last week, Guy wrote a nice diary to explain how to easily deploy IRMA to analyze suspicious files. Having a good tool to work on files locally is always interesting for multiple reasons. You are doing some independent research, you dont always have a safe Internet connectivity or you simply dont want to generate some traffic that could ring a bell at the attackers side. By safe connectivity, I mean a dirty Internet connectivity (like a DSL residential line) to bypass the corporate infrastructure. Locally running tools are also a nice way to prevent files to be sent to cloud services. This appliesnot only to bad guys but also topentesters who are preparing their attacks and generate targeted samples (think about the Veil framework)
If tools like IRMA or Cuckooare good tools, they must be adapted and tuned to your own environment because running them out of the box will not produce the best results. Nothing against free tools,the same problem affectscommercial products. They are delivered with standard sandboxes mimicking classic setup (WinXP, Win7, ...) but each organization has its own image to deploy workstations with, sometimes, very tricky configurations.
For a while, malware developers know that their software will be analyzed and tortured by such tools. To prevent this, they are trying to detect as soon as possible in which environment they are running. The key question is: Is the malware executed on a real victims computer or in a sandbox?If the malware detects to be running in a sandbox, its behavior will change. Some will simply terminate themselves, others could have be funny andmimickanother malware!Attackers and defenders are playing a continuous cat andmouse game to improve the evasion for the first and the detection for the second.
From an defendersperspective, it is critical to harden your sandbox. Basic tests are performed by pieces of malware like:
But they are also plenty (but very effective) things that can be tested/probed!
First of all, about the users behavior:
Classic desktops look more like this" />
More tests against the system can be performed:
If you need to deploy a sandbox, the best way is to base it on a real user workstation and update it with user behavior facts. If youre looking for a sandbox system, check if they can be customized! To conclude, here is an interesting Python tool which will test most of the points listed above: Sandbox_tester. Happy malware analysis!
ISC Handler - Freelance Security Consultant