Critical Zero Day Exploit in Adobe Acrobat and Flash

Adobe has released a Critical Advisory on Flash Player and Adobe Acrobat. Here is an extract from the Adobe Advisory:

A critical vulnerability exists in Adobe Flash Player 10.1.85.3 and earlier versions for Windows, Macintosh, Linux and Solaris operating systems; Adobe Flash Player 10.1.95.2 and earlier versions for Android; and the authplay.dll component that ships with Adobe Reader 9.4 and earlier 9.x versions for Windows, Macintosh and UNIX operating systems, and Adobe Acrobat 9.4 and earlier 9.x versions for Windows and Macintosh operating systems.

This vulnerability (CVE-2010-3654) could cause a crash and potentially allow an attacker to take control of the affected system. There are reports that this vulnerability is being actively exploited in the wild against Adobe Reader and Acrobat 9.x. Adobe is not currently aware of attacks targeting Adobe Flash Player.
The really scary thing is that this vulnerability is already exploited in the wild. Adobe plans to release updates for the affected systems in the next week

There is a workaround that can be used in the meantime, but it requires a lot of footwork in a large organization.

Adobe Reader and Acrobat 9.x - Windows
Deleting, renaming, or removing access to the authplay.dll file that ships with Adobe Reader and Acrobat 9.x mitigates the threat for those products, but users will experience a non-exploitable crash or error message when opening a PDF file that contains Flash (SWF) content.

The authplay.dll that ships with Adobe Reader and Acrobat 9.x for Windows is typically located at C:\Program Files\Adobe\Reader 9.0\Reader\authplay.dll for Adobe Reader or C:\Program Files\Adobe\Acrobat 9.0\Acrobat\authplay.dll for Acrobat.

Adobe Reader 9.x - Macintosh
1) Go to the Applications->Adobe Reader 9 folder.
2) Right Click on Adobe Reader.
3) Select Show Package Contents.
4) Go to the Contents->Frameworks folder.
5) Delete or move the AuthPlayLib.bundle file.

Acrobat Pro 9.x - Macintosh
1) Go to the Applications->Adobe Acrobat 9 Pro folder.
2) Right Click on Adobe Acrobat Pro.
3) Select Show Package Contents.
4) Go to the Contents->Frameworks folder.
5) Delete or move the AuthPlayLib.bundle file.

Adobe Reader 9.x - UNIX
1) Go to installation location of Reader (typically a folder named Adobe).
2) Within it browse to Reader9/Reader/intellinux/lib/ (for Linux) or Reader9/Reader/intelsolaris/lib/ (for Solaris).
3) Remove the library named "libauthplay.so.0.0.0."


Talkback and comments are most welcome

Top 5 Ridiculous Hacking Scenes in Movies

Like any technology-fed phenomenon with increasing public exposure, hacking is often ill-conceived and exaggerated in movie scenes.

The following are five of the most implausible and amusing scenes that have resulted from this approach to hacker depiction in movies.


Mission: Impossible

Ving Rhames plays expert computer hacker Luther Stickell in the Mission: Impossible movies. One of the most ridiculous scenes in this series comes in the first film, where Ethan Hunt (Tom Cruise) hangs upside down from the ceiling and hacks into the CIA’s system by executing Luther’s directions (given to him via earpiece).
It’s also just a little too simple when Luther hacks into the CIA Headquarters’ computer-controlled electrical system to trigger the fire alarm on a specific floor. As it turns out, all you have to do is type “ACTIVATE ALARM” and you can manipulate the CIA’s emergency alert system according to your every whim. Oh, and you can do all of this while sitting in a fire truck outside the building.


WarGames


What we can learn from this movie is that all backdoor passwords can be easily guessed if there’s an immediate family member who’s tragically died. Stephen Falken, an artificial intelligence researcher, has created a backdoor with password “Joshua” (the name of Falken’s dead son), which is hacked by a high school student and used to infiltrate the system of War Operation Plan Response (WOPR). And the rest is history - you never know whether you’re playing a game or destroying a country.


Jurassic Park


Lex is just proof that any middle school girl should know Unix. And that it’s not operated by command line, but by graphics. Sure. We can make these well-informed assumptions by watching the Jurassic Park scene in which a velociraptor tries to get into the building and eat everyone, but Lex decides that she can “hack” the security system and lock the doors. This is irrelevant, since velociraptors can break glass, but let’s just go with it.
Lex takes one look at a graphical interface and announces, “Hey, it’s a Unix system! I know this!” She runs a program called “3D File System Navigator” and saves the day, at least for the next few seconds.


Independence Day

Obviously, there’s more dubious material in this movie than the hacking scene. But it’s still pretty laughable. Even if you accept the premise that aliens have power source technology that’s been impossible for humans to replicate, the hacker is way beyond executing a plausible command.
David Levinson (Jeff Goldblum) uses his trusty Mac to write a virus that infects and destroys the entire alien defense system. Unless the aliens used Unix, the remotest possibility that a human-written virus could affect their superior system is completely without substance. It appears that we’ve seriously underestimated the power of an Apple a day.


Swordfish

The hacker in this movie is played by Hugh Jackman and is an insult to any self-respecting programmer who doesn’t wear a dirty T-shirt every day. Both hacking scenes make the process seem far too easy and use bogus terms like “worms” and “hydras” that are essentially nonsensical.
Successful hacks are done by “visualizing code” and continuing to type despite warnings of “Access Denied.” The hacker does his thing while drinking wine, dancing obnoxiously in his chair, and having a gun pressed against his head. It doesn’t get much more ridiculous than that.


This is a guest post by Alexis Bonari. She is a freelance writer and blog junkie. She is a passionate blogger on the topic of education and free college scholarships. In her spare time, she enjoys square-foot gardening, swimming, and avoiding her laptop.


Talkback and comments are most welcome

Related posts
3 Things no book about hacking will ever tell you

Hacking Virtual Machines Part 2 - Environments Where Virtualization Lives

Virtualization is considered to be the new renaissance in computing. Suddenly, all those over sized servers are put to great use by putting multiple Guest OS's on them. But running IT services in a virtualized environment brings a whole host of new opportunities for hackers.

In this article, we'll review the environment in which Virtualization lives, and which targets will yield most benefits for an attacker:

The environment

  1. Virtualization for production use is not a home tool - Virtualization is usually used by organizations of 500 employees or more. Smaller organizations also use it to create multiple environments on single hardware platforms. But smaller organizations are prone to make the classic mistake of mixing development and production platforms on same hardware.
  2. Virtualization platforms can be under scrutiny of several security sensors - Corporations, as common users of virtualization also use a whole bunch of security devices. It is very common that the attack on virtual servers will be or at least logged by Intrusion Detection Systems, pattern matching logic on firewalls and log analysis systems.
  3. It is rarely possible to initially plan for an attack on virtualization - In the information gathering and reconnaissance phase it is quite difficult to detect that some systems are virtualization platforms or virtual machines. You can confirm that there is virtualization only after you penetrate the perimeter and are able to scan for MAC addresses or specific signatures on the virtual hosts.

Targets of choice

The best virtualization attack targets, in order of preference are:
  1. Training platforms - These platforms are created by the 'Let's see if I can do this' philosophy. They are notoriously unpatched, since nobody bothers to patch them - they are expendable. These platforms have a tendency of urgently becoming production platforms in times of need - resources are needed and these are available. But then, they remain unpatched for quite some time.
  2. Test and development platforms - These platforms have a much better security posture then training platforms. But still, they are usually lagging behind production on patch levels. Also, test and development platforms are very good targets because they are full of production grade or near-production grade of data.
  3. Mixed test and production platforms - Both production and test versions of applications with lower processing requirements can be placed on the same VM Host. But unless they are isolated to different VLANS or on separate physical network adapters, the test platform can be exploited and used to attack the production.
  4. Proof of concept platforms - These platforms are usually outward facing platforms, like web servers that contain demo code or proof of concept code used for customer evaluations or marketing purposes. These platforms are usually compromised by a flaw in the web applications, and in a well maintained environment should be in an untrusted DMZ.
Attack guidelines

With this description of the environment, an attacker can prepare him/herself for attack on virtualization:
  1. Virtual machines are targets of opportunity - Virtual machines are not advertised. They can be detected only after the initial penetration. In such a case, the attack should be re-planned to possibly compromise the virtualization platforms.
  2. Virtual machines will hold a lot of valuable data - In a corporate environment, any host may be source of a wealth of information. Once inside, a good attacker will seize the opportunity to attack a virtual machine.
  3. Do not make too much noise - assume that sensors are all over the place and that someone is reading through the logs. This rule also applies to attacking physical machines
  4. Choose test/training platforms - these are usually on LAN segments where there are much less sensors
Conclusion
This enviroment description should be a guideline for security personnel to properly secure their virtualization environment:

  • Patch everything - this is a well known rule, but one that is still often forgotten. When patching, incude test and experimental platforms.
  • Do not expose test applications executing on a Virtual Machine to open internet - Simply, never risk the possibility of someone exploiting a web app vulnerability to gain access to your Virtualization infrastructure. If you must expose such a test platform the open internet, treat the entire VM Host and all guests as hostiles/honeypots and isolate the rest of the network from them.
  • Do not mix production and test on the same VM Host unless you have isolated them at every level - especially network level.
  • Isolate the VM test environments in network isolation layers. - Even if someone gains access to the network, he/she should have very difficult time exploiting a VM host, simply by not being able to reach it. Test environments should be self-sufficient - all test servers, test clients and supporting systems should be in the isolated block. Minimal services should be exposed to the rest of the organization, so that remote scanning shows nothing to the attacker.

Talkback and comments are most welcome

Related posts
Hacking Virtual Machines Part 1 - Sniffing
DHCP Security - The most overlooked service on the network

Hacking Virtual Machines Part 1 - Sniffing

Virtualization is considered to be the new renaissance in computing. Suddenly, all those over sized servers are put to great use by putting multiple Guest OS's on them. But running IT services in a virtualized environment brings a whole host of new opportunities for hackers.

We will discuss the opportunities in this series of articles, with uncreative title "Hacking Virtual Machines".

Sniffing attack
By definition, a virtualization host will have several Guest OS systems running. Possibly, these systems will have a different purpose, and different levels of patching and functional configuration. The Guest OS systems should be perfectly isolated between each other and not access the same resource at the same time.

But most virtualization implementations collide on this rule at the network level. It is quite common that all Guest OS systems are accessing the LAN via one Network Adapter. And not many implementations of Virtual servers have configured virtual VLans.


All this means that if one virtual machine starts a sniffer - putting the adapter in a promiscuous mode - it is quite possible to sniff traffic from the other virtual machines, and collect all sorts of interesting information.

The sniffing attack is a second phase attack, after the first virtual machine has been compromised.

The following video presents an actual compromised VMware Guest is used for sniffing the LAN and capturing the data of a second VMware Guest on the same Host.

The sniffing target is a web server, running the Hacmebank web application. The sniffing easily captures authenticaiton process, as well as money transfer transactions



Talkback and comments are most welcome

Related posts
Checking web site security - the quick approach
Example - Bypassing WiFi MAC Address Restriction
DHCP Security - The most overlooked service on the network

Contingency Planning Conference 2010

For anyone near New York City, you can check out the Planning & Management Conference (CPM 2010 East) on November 3-4.

According to the promoters, it is a 4-track advanced-level program taught by expert faculty in small, classroom settings. Plus, you can earn up to 35 Continuing Education Activity Points (CEAPs) just for attending.

You can register for the conference rate with a $100 discount off the full conference rate. Visit http://bit.ly/CPM2010MIS and register with the promotion code NX1C79.

Shortinfosec is distributing this information without any commercial interest. Sadly, we won't be able to visit. But anyone who visits is welcome to publish a guest post on Shortinfosec about the conference.

Hacking, Security, and Privacy Concerns on Facebook

It’s not hacking if users’ privacy settings are searchable, right? It depends on who you ask. Current Facebook privacy settings come with a recommendation that urges users to leave their pages searchable to everyone.

The logic behind this is as follows: “If you’re visible to fewer people, it may prevent you from connecting with your real world friends.
But staying searchable has led to the harvesting and publication of information that includes names and profile URLs for over 100 million Facebook users.

Skull Security and Information Distribution

Ron Bowes of Skull Security did some simple reconnaissance on Facebook for some hard data to use in his research on how people choose passwords. Ron is working to figure out how many usernames are based on people’s given names (jsmith is a popular choice). By proving that usernames and passwords can be easily extracted from basic information, Ron hopes to teach people how to make their accounts more secure.

In the Facebook incident, he collected only names (which could be actual names or usernames) and URLs of all searchable profiles (about 1/5 of Facebook users), then posted the information as a 3GB file that could be downloaded by anyone with Internet access.

Facebook spokesman Andrew Noyes has said that this information could be collected from any phone book, but the URLs collected couldn’t be extracted from the White Pages. Finding these URLs could be a frustrating trial-and-error process based only on names from a phone book, but thanks to Ron, they’re now accessible to anyone who’d like a neatly packaged list of searchable Facebook users.


The Problem with Being Searchable

Contrary to Facebook’s recommendations, users might consider changing their privacy settings to “unsearchable.” Here’s the minimum amount of information that can be gathered from a profile: name, profile picture, gender, and networks.

Facebook reserves the right to keep this information visible on every account, and accessibility can only be limited through the “searchable/unsearchable” setting. So with a URL provided by Skull Security, anyone can now view this information unless these accounts’ users make them unsearchable.

The problem with this is that advertisers are extremely interested in what seems like basic information because they can make surprising inferences based on the simplest data.
The best-case scenario, then, is more targeted advertising. The degree of potential damage depends on searchable accounts’ other privacy settings.

For example, if you can be searched and you’ve made your list of friends accessible to anyone, your friends’ information is now accessible even if they’ve made their accounts unsearchable.


Deciding on Your Privacy Settings

If you’re on Facebook, go to “Account” and “Privacy Settings” to edit your preferences. If you click on “View settings” under “Basic Directory Information,” you can preview your profile to see how it looks to someone who isn’t on your friends list. You might be surprised at the amount of information that’s accessible.

Change your “Basic Directory Information” to control how searchable you are, who can send you friend requests and messages, and who can see your friend list, education, work, current city, hometown, interests, and other pages (choices are Everyone, Friends and Networks, Friends of Friends, or Friends Only).

Under “Sharing on Facebook,” you can customize the rest of your settings, which are organized under the topics “Things I share,” “Things others share,” and “Contact information.”

Even if you’re not concerned about your own information, it’s courteous to protect friends and family by selecting “Friends Only” for accessibility to your friends list, family, relationships, and everything under “Things others share.” At the very least, accept Facebook’s loose minimum recommendation for privacy settings. You can select “Recommended” under “Sharing on Facebook” to do this.


This is a guest post by Alexis Bonari. She is a freelance writer and blog junkie. She is a passionate blogger on the topic of education and free college scholarships. In her spare time, she enjoys square-foot gardening, swimming, and avoiding her laptop.

Talkback and comments are most welcome

Related posts
Keeping unneeded sensitive data off your computer
Personal data - Publish only what you can afford to get leaked
Privacy Ignorance - Was Eric Schmidt thinking?

Attacking an unpatched Windows 2008 Server

Microsoft cannot stress enough the importance of keeping your systems patched. And yet, server systems tend to drift from best practice, for several reasons

  • The patch may fail the application that the server is running
  • The patch will require reboot, which may cause unwanted downtime
  • It's simply a hassle
But non-patched systems are a great target for an attacker. Even if the attacker doesn't gain permanent access to the network, he/she can cause nasty Denial of Service (DoS) on an unpatched server.
Here is the attack scenario
We will use a Windows 2008 target for this demonstration. The Win2008 is a good example because even if it was released in 2008, and we now have the R2 version, a lot of companies are just starting to implement it.

The attack is based on two well known vulnerabilities of Win2008 based on SRV2.SYS driver. In Metasploit, these exploits are know as:

  • ms_09_050_smb2_negotiate_pidhigh
  • ms_09_050_smb2_session_logoff
Both are Denial of Service type of attacks, so we'll use them without a payload.

To use these exploits, just fire up the msfconsole and type

msf > use exploit auxiliary/dos/windows/smb/ms_09_050_smb2_negotiate_pidhigh
msf auxiliary(ms_09_050_smb2_negotiate_pidhigh) > set rhost (Target IP address)
msf auxiliary(ms_09_050_smb2_negotiate_pidhigh) > exploit


You can do the same with the second exploit.

Here is the end result from a Metasploit command line point of view.


And here is the end result from a Windows 2008 Console point of view


Conclusion
Although this is just a demo type of exploit, it provides an excellent example of what happens to an unpatched server. Imagine that this was the web server running your Web Site. Now go and patch your systems :)

Talkback and comments are most welcome

Microsoft Patch Disclosure - October 2010

October 2010 brings a HUGE update set. Microsoft released 16 patches which repair a total of 51 vulnerabilities:

  • 10 patches address Remote Code Execution vulnerabilities,
  • 3 patches address Elevation of Privilege vulnerabilities
  • 1 patch addresses an Information Disclosure vulnerability
  • 1 patch addresses a Denial of Service condition
  • 1 patch addresses a information Tampering scenario

Critical
MS10-071 - Cumulative Security Update for Internet Explorer (2360131)
MS10-075 - Vulnerability in Media Player Network Sharing Service Could Allow Remote Code Execution (2281679)
MS10-076 - Vulnerability in the Embedded OpenType Font Engine Could Allow Remote Code Execution (982132)
MS10-077 - Vulnerability in .NET Framework Could Allow Remote Code Execution (2160841)

Important

MS10-072 - Vulnerabilities in SafeHTML Could Allow Information Disclosure (2412048)
MS10-073 - Vulnerabilities in Windows Kernel-Mode Drivers Could Allow Elevation of Privilege (981957)
MS10-078 - Vulnerabilities in the OpenType Font (OTF) Format Driver Could Allow Elevation of Privilege (2279986)
MS10-079 - Vulnerabilities in Microsoft Word Could Allow Remote Code Execution (2293194)
MS10-080 - Vulnerabilities in Microsoft Excel Could Allow Remote Code Execution (2293211)
MS10-081 - Vulnerability in Windows Common Control Library Could Allow Remote Code Execution (2296011)
MS10-082 - Vulnerability in Windows Media Player Could Allow Remote Code Execution (2378111)
MS10-083 - Vulnerability in COM Validation in Windows Shell and WordPad Could Allow Remote Code Execution (2405882)
MS10-084 - Vulnerability in Windows Local Procedure Call Could Cause Elevation of Privilege (2360937)
MS10-085 - Vulnerability in SChannel Could Allow Denial of Service (2207566)

Moderate

MS10-074 - Vulnerability in Microsoft Foundation Classes Could Allow Remote Code Execution (2387149)
MS10-086 - Vulnerability in Windows Shared Cluster Disks Could Allow Tampering (2294255)

Designed by Posicionamiento Web