5 Favorite Security Reads of the Week

Here’s a listing of my 5 favorite on-line security articles, papers and blog posts that I read in the past week:

Also, during the past week I published the following posts:

Looking forward to next week!

For more recommendations, see my earlier security reads of the week.

— Lenny Zeltser

How Malicious Code Can Run in Microsoft Office Documents

One of the most effective methods of compromising computer security, especially as part of a targeted attack, involves emailing the victim a malicious Microsoft Office document. Even though the notion of a document originally involved non-executable data, attackers found ways to cause Microsoft Office to execute code embedded within the document. Below are 4 of the most popular techniques used to accomplish this.

VBA Macros

Support for executing code that’s embedded as a VBA macro is built into Microsoft Office. Once the victim opens the document and allows macros to run, this code can run arbitrary commands on the user’s system, including those that launch programs and interact over the network. The penetration testing tool Metasploit makes it relatively straightforward to generate payload that attackers could embed in an Office file as a VBA macro. (See one example by Chris Patten.)

Such macros can be included in “legacy” binary formats (.doc, .xls., .ppt) and in modern XML-formatted documents supported by Microsoft Office 2007 and higher. In either case, Office will present the user with a security warning, stating that macros have been disabled and offering to “enable content.” Social engineering techniques can persuade the victim to click the button that will allow the embedded macro to run and infect the system.

Payload of a Microsoft Office Exploit

Another way to execute malicious code as part of an Office document involves exploiting vulnerabilities in a Microsoft Office application. The exploit is designed to trick the targeted application into executing the attacker’s payload, which is usually concealed within the Office document as shellcode.

In this case, Microsoft Office has to be exploited to execute the attacker’s code. This is in contrast to the previous scenario, where the attacker takes advantage of macros, supported by Microsoft Office as a feature. For instance, vulnerability CVE-2012-0141, announced in May 2012, could allow the attacker to craft a malicious Excel file to include an exploit that would “take complete control of an affected system.”

Embedded Flash Program

Embedding a Flash program inside an Office document provides attackers yet another way to run malicious code on the victim’s system. In this case, the code within the Flash object run as soon as the victim opens the document without any warnings and without relying on exploits. This code is till subject to security restrictions imposed by Flash Player, so to perform escalated actions the code would need to exploit a vulnerability in Flash Player.

One example of this attack has been described by Mila on the Contagio blog. The malicious Word document “DOC Iran’s Oil and Nuclear Situation.doc” was sent to a victim as part of a targeted attack. The document contained a Flash object, as seen below. (See steps to manually embed a Flash object in an Office document.)

Attackers can embed Flash objects in Office documents using automated tools. manual steps to do this the Flash object instructed Flash Player to download and play an MP4 file that was designed to exploit the CVE-2012-0754 vulnerability in Flash Player, announced in February 2012. This allowed the attacker to infect the victim’s system with a malicious Windows executable (trojan).

Embedded JavaScript

Another way to automatically execute code then the victim opens a Microsoft Office document involves embedding the ScriptBridge ActiveX control in the file. This control allows the attacker to embed and execute JavaScript, as was the case with the malicious “World Uyghur Congress Invitation.doc” file I obtained from the Contagio blog. This file used the “Microsoft Scriptlet Component”, implemented as the ScriptBridge ActiveX control to execute the embedded JavaScript code.

This Word file used ScriptBridge to execute embedded JavaScript code, which downloaded a malicious Flash file by from the specified URL. Microsoft Office automatically invokes embedded ActiveX controls that are marked Safe-For-Initialization, which is the case with ScriptBridge. (I’d love to better understand how ScriptBridge is being used to run JavaScript, so if you have more details, please let me know.)

In the case of this Word document, the downloaded Flash file was crafted to exploit the CVE-2012-0779 vulnerability in Flash player, announced in May 2012.

These are some of the techniques that intruders have used to execute code in Microsoft Office documents to compromise the system. The attacker could directly take advantage of a vulnerability in the targeted Office application. In other cases, the attacker uses functionality provided by Microsoft Office to either trick the user into allowing the malicious code to run (VBA macros) or to use a weakness in Office settings to run code that exploits vulnerabilities in other applications (Flash Player).

— Lenny Zeltser

Confusing the Padlock and the Favicon in the Web Browser

Web browser makers are continuing to change how they display two visual elements that people have been taking for granted: the padlock that designates an HTTPS connection and the favicon that acts as the thumbnail of the website’s visual identity. These changes are aimed at helping to minimize the risk that a favicon that looks like a lock might instill a false sense of security.

Users of web browsers have gotten accustomed to looking for the padlock image as part of the URL to determine whether the connection is “secure.” The browsers have typically displayed the lock for HTTPS connections where the SSL certificate was properly validated. Most non-geeky people don’t know what aspect of security the lock is supposed to signify, but they have been trained to rely on it as a symbol of online safety.

Webmasters can specify favicons as tiny images that web browsers have displayed in the URL bar to reinforce the site’s digital identity. Unfortunately, computer attackers can display favicons that look like padlocks, fooling victims into thinking that they were using an SSL-encrypted and authenticated connection. One tool that can automate such an attack is sslstrip, and this category of attacks is described in the Black Hat presentation by the tool’s author.

Internet Explorer

Microsoft’s Internet Explorer (v9) displays both the padlock and favicon in the URL bar. The favicon is on the left of the URL and—assuming the connection is using HTTPS with a valid certificate—the padlock is on the right:


A malicious webmaster or an attacker who can interfere with the web session may be able to display a padlock favicon even for HTTP or an invalid HTTPS connection, fooling the victim into thinking that the connection is “secure.” The distinction of where the trustworthy lock should exist in Internet Explorer (to the right of the URL, not to the left) is likely to be lost on most people.

Google Chrome

Google Chrome doesn’t display the favicon as part of the URL, showing it only in on tabs and bookmarks. Chrome displays the lock icon in the URL bar (in several variations) for connections that use HTTPS.


Because Chrome doesn’t display the favicon on the URL bar, this browser’s users are being conditioned to place greater trust in the padlock image displayed next to the URL. This is good.

Firefox

Mozilla’s Firefox stopped displaying the padlock icon for HTTPS connections starting in version 4 of the browser, phasing it out in favor of the Site Identity Button. The current production (v12) and beta (v13) releases of Firefox still display the favicon the browser’s URL bar and on the tab:


In this setup, a website that doesn’t use HTTPS display a favicon that looks like a padlock in the URL bar, fooling the victims who associate the lock with safety into thinking that the connection is “secure.”

To help address this risk, the current nightly build of Firefox (v14) no longer displays the favicon in the URL, showing it only on tabs, bookmarks and Awesome bar suggestions, according to Firefox developer Jared Wein. This version of Firefox adds the padlock to the Site Identity Button, while preventing webmasters from placing a false lock icon in the URL bar:


The approach to eliminating the favicon from the URL bar and displaying the padlock there for valid HTTPS connections is consistent with the behavior of Google Chrome. It’s encouraging to see the two browsers using compatible visual approaches that are designed to minimize user confusion.

Opera

Fortunately, the behavior of Opera is consistent with how Firefox and Chrome display locks and favicons. Opera displays favicons on tabs and bookmarks, while displaying the padlock on the URL bar for appropriate HTTPS connections:


Safari

Unfortunately, Safari displays the padlock and favicon on the URL bar, as well as on tabs and bookmarks in a manner consistent with Internet Explorer. In other words, the favicon is displayed to the left of the URL and the lock, when appropriate, is shown to the right of the URL.


There’s room for continuing to improve the visual indications that browsers present to users for making security-related decisions. Internet Explorer and Safari appear behind times in their treatment of favicons, because they display these images in the URL bar. In the meantime, individuals who educate non-technical people in web safety practices should consider how to best explain the various security indicators in the URL bar. None of these are easy undertakings.

Hand-picked related articles:

— Lenny Zeltser

5 Favorite Security Reads of the Week

Here’s a listing of my 5 favorite on-line security articles, papers and blog posts that I read in the past week:

Also, during the past week I published the following posts:

Looking forward to next week!

For more recommendations, see my earlier security reads of the week.

— Lenny Zeltser

Slides for Presentation on Real-World Social Engineering Attacks

I published the slides to my presentation “How attackers use social engineering to bypass your defenses,” which shows numerous examples of real-world social engineering attacks. These materials are designed to help you improve the relevance of your security awareness training and to adjust your data defenses by revisiting your perspective of the threat landscape. They cover techniques such as:

  • The use of alternative channels of communication
  • Focus on personally-relevant messages
  • The principle of social compliance in potential victims
  • People’s reliance on security mechanisms

Why bother breaking down the door if you can simply ask the person inside to let you in? Social engineering works, both during penetration testing and as part of real-world attacks. This briefing explores how attackers are using social engineering to compromise defenses. It presents specific and concrete examples of how social engineering techniques succeeded at bypassing information security defenses.

— Lenny Zeltser

Are Anxious People More Vigilant in Information Security?

Common wisdom suggests that anxious individuals are better at spotting danger than those with more mellow personalities. However, research by Tahl Frenkel and Yair Bar-Haim indicates that the opposite may be true: People with nonanxious personalities might be more skilled at spotting the early signs of trouble. This finding could highlight the type of people best suited for information security jobs.

Spotting Fearful Faces on Photographs

Some of the individuals selected for the study possessed anxious personality traits on the a State-Trait Anxiety Inventory scale, while others were nonanxious. The participants were shown photographs of a face that exhibited a progressive degree of fearfulness. The researchers measured how early in the progression the participants could detect fear on the photos.

“As expected anxious participants needed significantly less stimulus fear intensity for conscious fear detection,” researchers discovered. However, only non-anxious participants began exhibiting early signs of fear detection before consciously recognizing fear on the photograph. The Scientific American Mind’s March 2012 issue clarified:

“The brains of anxious subjects barely responded to the images until the frightened face had reached a certain obvious threshold, at which point their brains leapt into action as though caught off guard. Meanwhile nonanxious respondents showed increasing brain activity earlier in the exercise, which built up subtly with each increasingly fearful face.”

The researchers concluded that anxious people might lack the ability to detect threats in a granular manner and “therefore might face threats with no prior warning signal—further contributing to their already heightened anxiety level and perhaps associated with their enhanced baseline threat vigilance.”

Early Detection of Threats in Information Security

If there is a stereotype of an information security professional, it is sure to include anxious characteristics, such as concerns regarding threats, distrust and perhaps a degree of paranoia. These traits allow us to recognize the signs of danger, building defenses in anticipation of risks and also responding to the situation when the defenses fail.

Yet, those professionals who are calm and nonanxious might be better at spotting early warning signs of an intrusion before it escalates into a major breach. This skill is similar to the ability to detect the subtle signs of fear when looking at a photograph of a face. If this is true, then I wonder whether such individuals trust their instincts and have the time to begin investigating the potential problem early enough.

If this is interesting to you, see my earlier post Are Mistrustful Individuals Better at Information Security?

— Lenny Zeltser

4 Favorite Security Reads of the Week

Here’s a listing of my 4 favorite on-line security articles, papers and blog posts that I read in the past week. This week I’m featuring a series of articles that profile Anonymous that were written by Josh Corman and Brian Martin:

Also, during the past week I published the following posts:

Looking forward to next week!

For more recommendations, see my earlier security reads of the week.

— Lenny Zeltser

The Risks of Remote Desktop for Access Over the Internet

It’s convenient to use the Remote Desktop Protocol (RDP) for accessing systems over the Internet, especially in server environments. However, exposing RDP to direct connections is risky. This setup not only gives remote attackers the opportunity to guess logon credentials, but also relies on the lack of a remotely-exploitable vulnerability in Microsoft’s RDP implementation.

Microsoft’s Security Bulletin MS12-020, released in March 2012, described critical vulnerability in Microsoft’s RDP implementation on most Windows platforms (CVE-2012-0002). This bug could allow a remote unauthenticated attacker to run arbitrary code on the affected system by sending “a sequence of specially crafted RDP packets.”

Microsoft provides a detailed perspective on the CVE-2012-0002 vulnerability in its Security Research & Defense blog, stating that even though it has no knowledge of the corresponding exploits, it believes that “an exploit for code execution will be developed in the next 30 days.”

I suspect such an exploit will appear sooner than 30 days, because of the relatively fast techniques available to attackers for reverse-engineering a patch to understand the nature of the vulnerability they need to target. Such an exploit would provide an attacker with access to targeted server environments and would enable automated opportunistic break-ins into servers and workstations that expose RDP to the Internet. Such an exploit would also be effective as part of a network worm for automated propagation across vulnerable systems.

My recommendations for handling the CVE-2012-0002 RDP vulnerability and future risks related to RDP:

  • Understand what systems in your environment expose RDP to the Internet. Create a plan to apply the MS12-020 as soon as practical.
  • Change the port on which your systems listen for RDP connection to avoid using the default TCP port 3389. Automated scanners and worms will be less likely to locate your RDP listeners on high-non-standard ports.
  • Consider configuring your RDP settings to use Enable Network Level Authentication (NLA) on Windows Vista and later platforms, as suggested by Microsoft.
  • Remember to have strong authentication for systems utilizing RDP to deal with remote password-guessing attacks.

— Lenny Zeltser

At the BSides San Francisco conference I presented with Lee Kushner on the techniques for finding a good job in information security and on hiring strong candidates for an infosec position. Anthony Freed from Infosec Island recorded this 6-minute video with me at the event.

I recognize that my code will be used in ways I cannot anticipate, in ways it was not designed, and for longer than it was ever intended.
An excerpt from the Rugged Software Manifesto