(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
[SECURITY] [DSA 3422-1] iceweasel security update

ChannelLife NZ

Photo gallery: NZ infosec industry shines at iSanz awards
ChannelLife NZ
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 ...

and more »
[security bulletin] HPSBUX03529 SSRT102967 rev.1 - HP-UX BIND service running named, Remote Denial of Service (DoS)
Shockwave Flash Object DLL side loading vulnerability
Shutdown UX DLL side loading vulnerability
Event Viewer Snapin multiple DLL side loading vulnerabilities
Multiple FireEye Products 'JAR Analysis' Remote Code Execution Vulnerability

Enlarge (credit: Project Zero)

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.

Read 4 remaining paragraphs | Comments

SQL Injection in orion.extfeedbackform Bitrix Module
libnsbmp: heap overflow (CVE-2015-7508) and out-of-bounds read (CVE-2015-7507)
Adobe Flash Player and AIR Multiple Unspecified Security Bypass Vulnerabilities
Adobe FlashPlayer and AIR APSB15-32 Multiple Unspecified Heap Buffer Overflow Vulnerabilities
Adobe Flash Player and AIR CVE-2015-8445 Unspecified Integer Overflow Vulnerability
Adobe FlashPlayer and AIR CVE-2015-8415 Unspecified Buffer Overflow Vulnerability
RCE in Zen Cart via Arbitrary File Inclusion
libnsgif: stack overflow (CVE-2015-7505) and out-of-bounds read (CVE-2015-7506)

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:

  • To test the presence of a debugger
  • To slowdown the malware execution by adding sleep() calls here and there (A malware has plenty of time to remain below the radar and perform tasks later. On the other side, a sandbox analysis must be completed as soon as possible. Speed is a key).
  • To test the host MAC address - Virtualization tools use dedicated pools of MAC addresses.

But they are also plenty (but very effective) things that can be tested/probed!

First of all, about the users behavior:

  • Is the mouse moving? Most sandboxes keep the mouse at the center of the screen.
  • Are they icons on the desktop?
  • Is there a wallpaper (and not the standard one)
  • Are they applications running?
  • Are they bookmarks saved in the browser?

Classic desktops look more like this" />

More tests against the system can be performed:

  • What is the system uptime? (a sandbox is rebooted from a clean snapshot for each new analyze)
  • Whats the system drive C: size? (sandboxes do not have plenty of storage)
  • How many CPU / cores are available?
  • The memory size is also a good indicator (whos running a sandbox with less than 8GB of RAM today?)
  • The screen resolution (99% of users have a screen resolution 1024x768)
  • The computer model (sandboxes emulate oftenold computers likeDell desktops)
  • The hostname (sandbox001 or win7_001)
  • Is there a printer defined
  • No temporary files nor application data
  • Does the sandbox have no Internet connectivity?
  • Does the sandbox run suspicious processes (python.exe or perl.exe are not common on a corporate computer)
  • No antivirusinstalled? Really? On a classic desktop?
  • Is the sandbox part of a domain? Is it linked to a domain controller? Are shares available?
  • What about the presence of tools/applications: VMware tools, Microsoft Office, ...

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!

Xavier Mertens
ISC Handler - Freelance Security Consultant

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
[slackware-security] openssl (SSA:2015-349-04)
[slackware-security] libpng (SSA:2015-349-02)
[slackware-security] bind (SSA:2015-349-01)
[SECURITY] [DSA 3420-1] bind9 security update
Internet Storm Center Infocon Status