Threat Level: green Handler on Duty: Russell Eubanks

SANS ISC: InfoSec Handlers Diary Blog - Internet Storm Center Diary 2014-03-24 InfoSec Handlers Diary Blog


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

New Microsoft Advisory: Unpatched Word Flaw used in Targeted Attacks

Published: 2014-03-24
Last Updated: 2014-03-24 19:43:23 UTC
by Johannes Ullrich (Version: 1)
1 comment(s)

Microsoft today published a new security bulletin, announcing that it has seen a new Word 2010 exploit used in recent targeted attacks. The exploit uses a so far unpatched vulnerability in Word that is triggered by opening a crafted RTF document.

To prevent exploitation of the vulnerability, Microsoft released a "Fix It" that will prevent Word from opening RTF documents. [1][2] 

Frequently RTF ("Rich Text Format") is used as a more portable way to exchange documents with basic formatting elements. The Fix-It may not be appropriate if you use RTF documents regularly. However, given that RTF documents are portable and can be opened by other software, it MAY be ok to just use software other then word to open the document.

This vulnerability is identified by CVE-2014-1761.

More details about the exploit can be found in Microsoft's "Security Research and Defense Blog" [3]. It points out that EMET can help block the exploit if the "Mandatory ASLR" and the "Anti-ROP" features are selected. This may be of help if you can't stop opening RTFs altogether. Word 2013 appears vulnerable, but the exploit fails due to ASLR and "just" crashes Word 2013. 

The blog post also includes indicators of compromise for the particular exploit seen.

 

[1] https://technet.microsoft.com/en-us/security/advisory/2953095
[2] https://support.microsoft.com/kb/2953095
[3] http://blogs.technet.com/b/srd/archive/2014/03/24/security-advisory-2953095-recommendation-to-stay-protected-and-for-detections.aspx

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

1 comment(s)

Integrating Physical Security Sensors

Published: 2014-03-24
Last Updated: 2014-03-24 15:30:10 UTC
by Johannes Ullrich (Version: 1)
3 comment(s)

I have been playing for a few years now with different network connected devices [1]. As a "security guy", a lot of this research has been about vulnerability in these devices, or what we sometimes call the "Internet of Things". Over the years, I also learned to appreciated the ability of these devices to deliver physical context to some events that I may see in my logs, and I started to add the state reported from some of these devices to my syslog collector feeding into my SIM (right now not a "full SIM, but Splunk for the most part). 

Here are a couple of experiences that I found helpful:

Servers

Servers (and many desktops) do provide a number of useful sensors. For example a sensor to detect opening the case, and various temperature sensors. The temperature sensor can easily be monitored with tools like Nagios. The case sensor is a bit more tricky. Yes, it can easily be monitored (nagios again), but I find that nobody resets the sensor in the BIOS after legitimately opening the case, and to avoid tampering with this setting, this requires a BIOS password. Not too many people are willing to set BIOS passwords and rather rely on the physical security of the data center itself. A switch port can also be used to detect disconnection of a server, and the power usage of your power distribution unit (PDU) can often be polled remotely. I haven't run into a PDU yet that can set a syslog/snmp message that would alert you of power use going to zero on a device. Usually they have alerts that will tell you about high load or high temperature.

Environmental Sensors

There are a number of environmental sensors that are available outside of the server. Many AC systems can be polled remotely I have run into http APIs, some snmp and even syslog. This can alert you of an AC failure before the temperature in your server rises significantly. Some advanced systems will also provide overall "health" information but I haven't played much with that yet. Usually this information is used for remote maintenance. Of course, you can always add additional network readable sensors for temperature and humidity. There are also a number of options to detect more "catastrophic" conditions like water leaks and to automatically shut off water feeds if they are detected.

Physical Sensors

Access cards and door open/close sensors are pretty much standard in large office buildings these days. But the information isn't always easily accessible to the network security team. Being able to correlate an event with a person's presence (or absence) from an area can be important. Not just to identify the culprit, but also to provide context to an alert. For example, a work station sending excessive HTTP requests while a user isn't sitting in front of it can be an important indicator. You may be able to get signals if a screen saver is engadged or not on a system in order to monitor physical security or additionally verify if a user is using a system or not (nagios can do that easily in Linux. Not sure if there is an easy way to poll in Windows remotely if a screen saver is engadged).

My favorite example is always a hotel in Singapore that used the signal from an opening room door to dispatch an elevator to that respective floor.

Cameras

Network cameras are pretty much everywhere these days. Some come with integrated motion sensors, or can detect motion by monitoring changes to the image. Either way, many of these cameras can send a signal whenver they detect motion, and even attach images. This can suplement some of the door sensors.

Anything else you recently integrated?

 

 

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

3 comment(s)
Diary Archives