Saturday, September 16, 2017

Beware of the Bashware: A New Method for Any Malware to Bypass Security Solutions

With a growing number of cyber-attacks and the frequent news headlines on database breaches, spyware and ransomware, quality security products have become a commodity in every business organization. Consequently a lot of thought is being invested in devising an appropriate information security strategy to combat these breaches and providing the best solutions possible.

We have recently found a new and alarming method that allows any known malware to bypass even the most common security solutions, such as next generation anti-viruses, inspection tools, and anti-ransomware. This technique, dubbed Bashware, leverages a new Windows 10 feature called Subsystem for Linux (WSL), which recently exited Beta and is now a fully supported Windows feature.

This feature makes the popular bash terminal available for Windows OS users, and in so doing, enables users to natively run Linux operating system executables on the Windows operating system.

Existing security solutions are still not adapted to monitor processes of Linux executables running on Windows OS, a hybrid concept which allows a combination of Linux and Windows systems to run at the same time. This may open a door for cyber criminals wishing to run their malicious code undetected, and allow them to use the features provided by WSL to hide from security products that have not yet integrated the proper detection mechanisms.

Watch the Demo of the Attack: https://youtu.be/fwEQFMbHIV8

Bashware is so alarming because it shows how easy it is to take advantage of the WSL mechanism to allow any malware to bypass security products. We tested this technique on most of the leading anti-virus and security products on the market, successfully bypassing them all. This means that Bashware may potentially affect any of the 400 million computers currently running Windows 10 PC globally.

Following this discovery, we updated our SandBlast Threat Prevention solutions, to protect our customers from Bashware. We call the security industry to take immediate action and to modify their security solutions to protect against this new method.

BASHWARE

The Bashware technique leverages the underlying mechanism of the Windows Subsystem for Linux (WSL). This feature, introduced as part of Windows 10, allows native Linux ELF binaries to run on Windows. Before diving into Bashware's internals, we will first review the inner workings of WSL.

WSL overview

The WSL feature goes far beyond having the familiar Linux "Bash" shell on Windows OS.

It contains both user mode and kernel mode components, which together create a complete compatibility layer for running an environment that looks and behaves just like Linux, without having to fire up any virtual machine.

Microsoft aimed to run the target application and OS entirely within the user-mode address space of a single process, by implementing a way to run an application in an isolated environment, with reduced overhead. In order to allow this new concept, Pico processes were introduced. Pico processes are the containers that allow running ELF binaries on the Windows OS. These new types of processes are minimal and lack the structural blocks that are commonplace in regular Windows NT processes (PEB, TEB, NTDLL, etc.).

By placing unmodified Linux binaries in Pico processes, WSL enables Linux system calls to be directed into the Windows kernel. The lxss.sys and lxcore.sys drivers translate the Linux system calls into NT APIs and emulate the Linux kernel.

The WSL concept originally started as the Astoria projectand Drawbridge project, designed to run native Android applications on Windows systems. Later on, it shifted its focus and became the foundation for the service available today.

Following multiple issues found in WSL's initial release, Microsoft decided to offer this project in beta mode, and add a support section on their GitHub page to gather live issues from the community. After fixing most of the issues raised by the community and reaching a somewhat stable version, Microsoft officially announced the release of WSL at July 28, 2017. The service will become available on the public release, starting from the Windows 10 Fall Creators Update (FCU), scheduled for October 17.

Although WSL has become a stable feature and many of its issues are now resolved, it seems the industry has still not adapted to the existence of this strange hybrid concept which allows a combination of Linux and Windows systems to run at the same time. This may open a door for cyber criminals wishing to run their malicious code undetected, and allow them to use the features provided by WSL to hide from security products that have not yet integrated the proper detection mechanisms.

Additional information regarding WSL internals can be found in "Appendix A".

Figure 1 – https://blogs.msdn.microsoft.com/wsl/2016/04/22/windows-subsystem-for-linux-overview/

Bashware Explained

Bashware is a generic and cross platform technique that uses WSL in order to allow running both ELF an EXE malicious payloads in a stealthy manner that could bypass most current security solutions.

The key to the technique lies within the design of the Pico process structure. The Pico process has none of the common windows process characteristics, and in fact – nothing that would identify it as a regular NT process at all. Nevertheless, Pico processes have the same capabilities as normal NT process and do not pose any less threat.

Figure 2 – The four steps of Bashware

Bashware loads the malicious payloads in 4 major steps:

Step 1: Loading WSL components

In order to take advantage of WSL, Bashware must first verify that the WSL feature is enabled; this is achieved by inspecting the state of the Pico drivers (checking if lxcore.sys & lxss.sys are presented in the windows drivers' path).  In cases where the feature is disabled, Bashware will load the drivers using the DISM utility. This method appears to be the simplest, and the one that does not raise any suspicion. This way, by running a single command line silently in the background, invisible to the user, Bashware loads the WSL components and is ready to move on to the next step.

Step 2: Enabling developer mode

A common assumption is that the risk of abusing WSL is minimal, since it requires developer mode to be manually set by the user. However, it's a little known fact that all it takes to enter developer mode is setting these registry keys:

HKLM \ SOFTWARE \ Microsoft \ Windows \ CurrentVersion \ AppModelUnlock \ AllowAllTrustedApps

HKLM \ SOFTWARE \ Microsoft \ Windows \ CurrentVersion \ AppModelUnlock \ AllowDevelopmentWithoutDevLicense

Although these values are set by TrustedInstaller, this can be easily done by any user (or application) running with local admin privileges.

WSL feature was defined as a beta version and could only work when developer mode is enabled.

There is no native validation or any advanced security checks to verify these values or their modification. Bashware abuses these registry keys by turning them on instantly, for just long enough to allow it to perform its malicious actions. Once Bashware's operations are complete, the keys are turned back off making this operation practically invisible.

Step 3: Installing Linux

Although Bashware has by now enabled WSL and entered developer mode, the Linux instance still doesn't contain any file system. The next step for Bashware is to download and extract the Linux file system from Microsoft's servers.

The user management installation is done by "Lxrun", using the /install option. "Lxrun" command-line interface downloads and installs the file system on Windows PC. The Linux-facing file system in WSL is Ubuntu 16.04, which comes with regular support for UNIX rights. Bashware uses the Lxrun.exe utility, which downloads the Linux file system from Microsoft servers. This process seems legitimate and runs silently.

It's interesting to note that during our research we have found that this installation process is also vulnerable to a race condition vulnerability, which will be explained in depth in the "More Security issues" section below.

Step 4: Wine

Now that Bashware has set up a fully-fledged Linux environment on the Windows system, and is able to execute anything on both environments, the question is what could it do next?

Obviously, our final goal was to show that we can run malware attacking the Windows system from the Linux instance, although malware is not designed to be cross-platform in that way. We found that Winehq project is the perfect solution for that – a free open-source compatibility layer that allows Microsoft Windows programs to run on Unix-like operating systems. Even better – for those unfamiliar with it – Wine is not an emulator, but rather it translates Windows API calls into POSIX (Portable Operating System Interface), which is perfect for our needs.

This is exactly what we needed in order to make a Windows malware run from the WSL environment, turning it invisible as well. Bashware uses the Winehq project capabilities and installs a pre-optimized wine project into the WSL Linux environment.

Next, EXE formats need to be converted by Wine, turning its NT syscalls to POSIX syscalls. Later on, the Pico provider (lxcore.sys) will convert these POSIX syscalls back to NT syscalls, turning lxcore to the actual caller of this process. This way, a file running on the Windows OS can execute any known malicious payload from the Linux OS, where it remains hidden from most security products.

Conclusions

As "Bashware" completes these 4 steps, it becomes a perfect demonstration tool for running any malware undetected, bypassing the most common security products – anti-viruses, inspection tools, debugging tools, and more.

Bashware does not leverage any logic or implementation flaws in WSL's design. In fact, WSL seems to be well designed. What allows Bashware to operate the way it does is the lack of awareness by various security vendors, due to the fact that this technology is relatively new and expands the known borders of the Windows operating system.

However, we believe that it is both vital and urgent for security vendors to support this new technology in order to prevent threats such as the ones demonstrated by Bashware.

Microsoft has already taken steps that should assist the security vendors to deal with the new security considerations presented by WSL, including a Pico APIsthat can be used by AV companies in order to monitor these types of processes.

More Security Issues – Double Privilege Elevation 

Figure 3: Race Condition Bug Flow

During WSL's installation process, "LxRun.exe" is responsible for downloading and extracting the Linux file system from Microsoft's servers. Under the hood, the filesystem is saved in a hidden folder under %APPDAT% directory as a file named "lxss.tar.gz".

After saving the filesystem archive, "LxRun.exe" then continues to extract it into the same directory. After this task is finished, the hidden folder contains a full Linux file system, later used by WSL, and more specifically by BASH.exe.

Microsoft has taken a lot of effort into protecting the Linux file system itself, such as prevention of Linux init modification, common injection techniques (such as LD.SO.PRELOAD previously discussed and disclosed by Alex Iounesco). But what about the protection mechanisms for the file system itself?

During our research we noticed that the Linux installation process is vulnerable to a simple race condition. If an attacker manages to modify the file system archive after it was downloaded but before it is extracted, there is no check to validate the authenticity of the file system. Thus, it allows the attacker to completely change the file system and load any Linux file system.

The main issue related with implementing this technique is recognizing the exact time in which the archive should be switched. Luckily for us, Microsoft calculates a SHA256 for the downloaded file system, which saves the hash value into a file right after the download process is complete and before extraction begins. For some reason, there is no other use for this value, other than signaling when to switch the file system archives.

When a user wishes to use WSL, he runs "Bash.exe", which is executed with the user's permission. In every WSL run, NTFS partitions are automatically mounted under /mnt in the Linux environment, granting the ability to read write and execute NTFS from within the WSL.

Figure 4: Trying to write a file into System32 directory from within the Linux environment – unprivileged "Bash.exe"

If a threat actor utilizes an admin token to launch Bash.exe, then Bash.exe + children will execute with full Admin token, including all privileges causing UAC bypass on the Windows side and full privilege escalation on the Linux side.

 

References

  1. Official Microsoft's Blog and GitHub on WSL:
  1. Alex Ionescu's repository on GitHub:
  • https://github.com/ionescu007/lxss – Dedicated to research, code, and various studies of the Windows Subsystem for Linux used as great source of information and inspiration for this project.
  1. Wine project – a free open-sourcecompatibility layer that allows Microsoft Windows programs to run on Unix-like operating systemshttps://www.winehq.org/

Appendix A

WSL – Windows Subsystem for Linux

Following security researches who pointed to the security bugs within it, Microsoft had opened a GitHub page for WSL, where people could report bugs. Microsoft also took several security measures, such as shipping Windows 10 with the feature off by default. This means that WSL drivers and user-mode management service components are not being loaded to the memory until the WSL feature is enabled manually (we will further explain this below). Furthermore, the feature was defined as a beta version, and could only work when developer mode was enabled.

The WSL feature goes far beyond having the familiar Linux "Bash" shell on Windows OS. It's a complete compatibility layer for running an environment that looks and behaves just like Linux, allowing it to run any type of Linux code: Linux build system, GNU tools and anything else needed in order to build and test your application without having to fire up any virtual machines.

WSL contains both user mode and kernel mode components:

  • User mode session manager service, which handles the Linux instance life cycle (LxssManager.exe).
  • Pico provider drivers (lxss.sys, lxcore.sys) that emulate a Linux kernel by translating Linux system calls.
  • Pico processes ("Minimal processes") that host the unmodified Linux executable (e.g. /bin/bash).

Pico Processes

At the heart of the WSL design is a new type of process, called Pico. Pico processes are minimal and lack the structural blocks that are common to regular Windows NT processes (PEB, TEB, NTDLL, etc.). Pico processes are the containers that allow running ELF binaries on the Windows OS.

The concept of a Pico process was first introduced in a project called Drawbridge, and was originally used to run an application in an isolated environment (a form of virtualization for application sandboxing).

One way of establishing an isolated environment is by using a virtual machine, but this approach might cause resource overhead. The Drawbridge project aimed to reduce this overhead by running the target application in a lightweight and secure container. The container has an isolated address space and is serviced by a component called "Security Monitor".

Despite being virtually empty if examined from within the Windows OS, Pico processes have the ability to interact with a Windows NT Kernel. The interaction is achieved by the Pico provider – a special driver which is responsible for the transition from Linux ELF to a running Windows executable.

WSL uses Pico processes as containers for native Linux binaries. Pico processes are being monitored and serviced by a kernel component called 'Pico Provider' (implemented in lxcore.sys). The Pico Provider driver dispatches system calls and user mode exceptions made by the various Pico Processes. This processes/provider architecture provides the foundation for the Windows Subsystem for Linux. The end result of this architecture is the ability to run native unmodified Linux binaries by loading executable ELF binaries into a Pico process' address space and executing them above Linux-compatible layer of syscalls.

(Drawbridge project)  (WSL)

System Calls & Pico Providers

WSL executes unmodified Linux ELF64 binaries, by virtualizing a Linux kernel interface on top of the Windows NT kernel. One of the kernel interfaces that it exposes are system calls (syscalls), a service provided by the kernel that can be called from user mode.

The Windows Subsystem for Linux includes kernel mode drivers (lxss.sys and lxcore.sys). Pico providers are responsible for handling Linux system call requests in coordination with the Windows NT kernel. The drivers do not contain code from the Linux kernel but are instead a clean room implementation of Linux-compatible kernel interfaces.

Pico providers are essentially custom written kernel drivers which implement the necessary callbacks to respond to the list of possible events that Pico processes can trigger. When a syscall instruction is made, the NT kernel detects that the request came from a Pico process. Since the NT kernel does not know how to handle syscalls from Pico processes, it saves off the register state and forwards the request to the Pico driver (lxcore.sys). The Pico driver then determines which Linux syscall is being invoked, by inspecting the rax register and then passes the parameters using the registers defined by the Linux syscall calling convention. After the Pico driver has handled the syscall, it returns to the NT Kernel, which restores the register state, places the return value in rax, and invokes the sysret\iretq instruction to return to user mode.

User mode session manager service

While running the Bash terminal, there are numerous procedures running under the hood of Windows OS:

  • exe – a Windows launcher service that communicates with the LxssManager.exe and spawns a new instance of WSL, executing the desired process.
  • exe – a user-mode management service (the LxssManager.dll service living in SVCHOST.exe), which provides an external-facing COM interface, passing information to the Pico Provider through its Device Object.
  • Pico Provider driver (LXSS.SYS / LXCORE.SYS) which provides the kernel-mode implementation of a Linux-compatible Kernel ABI and API, as well as a Device Object (\Device\lxss) for command & control.

The detailed procedure explained above launches the Pico process that contains the Linux environment. This Linux instance enables running ELF binaries through an interface which lxcore.sys exports. Lxcore.sys intercepts all ELF syscalls and adapts them into NT syscalls.

At the end of the day WSL is a very useful and innovative feature that provides developers with the familiar Bash shell and Linux environment in which they can run most Linux command-line tools, eliminating the need of creating a Linux virtual machine. However, there is limited security awareness with regards to the WSL design, which allowed us to take advantage of this feature and run undetected malicious code inside a Linux instance.

Appendix B

(BASH.exe – image from https://msdn.microsoft.com/en-us/commandline/wsl/faq



Sent from my iPhone

Friday, September 15, 2017

Sonic “Attacks” on US Diplomats in Cuba: Don’t Rush to Conclusions

 

Reports of "health attacks" in Cuba which left several American and Canadian diplomats with health problems and hearing loss has led to wide and dramatic speculation.  Several stories have hyped possible "acoustic attacks" that may be related to weapons used by police for riot control, or even weapons developed by the U.S. Navy.  The Associated Press reported that "after months of investigation, U.S. officials concluded that the diplomats had been attacked with an advanced sonic weapon that operated outside the range of audible sound and had been deployed either inside or outside their residences…"  Florida Senator Marco Rubio issued a statement condemning what he concluded was a blatant and intentional attack.  According to Rubio, the Cuban government has been harassing U.S. personnel for decades and, "this has not stopped with President Obama's appeasement.  Personal harm to U.S. officials shows the extent the Castro regime will go and clearly violates international norms."  Scary indeed.

There has been no shortage of theories as to the reasons for the attacks, some speculating that it was payback against specific individuals, a possible operation by third parties (the Russians?) to drive a wedge between the U.S. and Cuba, or a means by Cuba to send some sort of message to Washington.

If so, the message is mighty garbled.  No report has provided anything definitive as to what happened, and how.  To date, the State Department has remained relatively mum, only commenting that the administration has an "active investigation" to determine the source of the health problems, many of which resemble concussions.  The affected U.S. diplomats have returned home from Havana. In May, the State Department asked two Cuban diplomats to leave Washington though did not publicly announce this expulsion at the time and has since specifically declined to call it an act of reciprocity.

While I have not served in Cuba, my experience in a number of similar hostile, high counterintelligence threat countries suggests that this is more likely a surveillance effort gone wrong, than the use of an offensive sonic weapon.  We have very little experience anywhere in the world with directed attacks designed to physically harm to our diplomats.  However, the use of intrusive technical collection and surveillance which sometimes causes harm in its own right, is consistent with past practice in Cuba and elsewhere.

Why don't I believe this was an attack intended to harm diplomats?

First, I don't think the timing or diplomatic atmosphere accords with such hostile action by the Cuban government.  U.S. and Canadian diplomats reported their symptoms in the fall of 2016.  At that time, the Obama Administration had relaxed diplomatic relations with Cuba, and Obama was the first U.S. President to visit the island only months before.  During the early to mid-fall, most observers assumed that Hillary Clinton would win the Presidential election and continue the warming of relations with Cuba.  If the operations began shortly after the US presidential elections, it would have been irrational for Cuba to start out relations with the incoming administration in this manner.  Further, I suspect if the Trump Administration believed Cuba sought to purposely harm U.S. diplomats, they would have reacted in a more aggressive and public manner.  Indeed, the Cubans who were asked to leave the U.S. were not kicked out "persona non grata" as is usually the case when countries have on-the-ground diplomatic or espionage disagreements.  Conspicuously, the two Cuban diplomats were not prohibited from ever returning to the U.S., and the door was left for them to return depending on the outcome of the FBI/State investigation.

Finally, and more significantly, we have seen too many similar technical "attacks" around the world which caused unintended harm. These efforts, while designed to further surveillance and eavesdropping and not to cause malicious damage, nevertheless risked or resulted in residual physical harm to U.S. diplomats.

During my time overseas, I have had personal experience with several of these "attacks."  In the 1980s and 1990s, the Soviet and then Russian intelligence services deployed doses of nitrophenyl pentaden (NPPD) against American diplomats whom they suspected of managing espionage operations against Russian interests.  This so-called "spy dust" was an invisible electromagnetic powder with a customized chemical identifier.  It was smeared onto door handles, furniture and cars of suspected American spy handlers.  It was a tagging agent used by Russian security elements to covertly monitor their own community by revealing unreported (and potentially espionage related) contacts between Russian and American officials.  It was somewhat ingenious. After deploying the invisible material on a suspected U.S. intelligence officer, Russian counter-intelligence would snoop after-hours through the offices of Russian government employees looking for traces of the material.  Discovery of the powder in the office of someone who had not reported contact with the American provided significant proof of suspicious activity.

What was not ingenious, however, were the threats to human health. There were concerns at the time that the material was carcinogenic and could be harmful to American diplomats.  Following studies, the United States determined there was no specific evidence of a threat to the U.S. diplomatic community since it was only used against a handful of people.  As someone who was "dusted," that explanation didn't really make me feel much better.  However, the substance was at least a step up from earlier Russian tracking devices like radioactive nails hammered into the tires of U.S. diplomatic vehicles, allowing Russian surveillance vehicles to hang back unseen and follow along by using special equipment to track targets' tire residue.

The Russian security services were also known to flood the U.S. embassy in Moscow with electromagnetic radiation.  They would beam concentrated microwaves and electronic pulses at the Embassy in an attempt to eavesdrop on U.S. typewriters and conversations.  In the 1970s, a U.S. Ambassador contracted and died of a blood disease that many assumed to be a result of the attacks.  The State Department detected high levels of radiation in the embassy staff, and provided hazard pay to personnel who worked in Moscow.  A variety of electronic attacks continued over the years to include mobile Russian vans that acted as a giant x-ray that could be directed at diplomats all over town.  In a similar fashion, high frequency devices can be used to pulse other devices, perhaps turning on or off collection devices in homes or offices.

Similarly, the Russian security services undertook a massive effort to bug the new embassy building in Moscow with all sorts of technical gear, some of which could potentially affect the health of Americans.  Indeed, the new embassy construction was even abandoned in 1985 due to the sheer volume and sophistication of electronic eavesdropping equipment that was found throughout the walls, concrete floors and underground.  A second attempt to improve the security of the building also faltered when the United States found an equally aggressive and sophisticated attack, which included building listening devices directly into the steel beams holding the building upright.  Even the sidewalks and streets throughout the neighborhood were embedded with electronic collection gear which was designed to turn the embassy building into a giant antenna.  The United States lost hundreds of millions of dollars trying to fix the problems, and eventually tore off the top several floors of the Embassy and rebuilt it with specially imported materials put together by American-only labor – an effort the U.S. called the "Top Hat" solution.  The decades-long process displayed the remarkable expertise of the Russians in the use of technical sensors and surveillance gear.  Russian technology was consistently underestimated by the U.S.  and often our best scientists had difficulty understanding what the Russians were up to.

On the U.S. side, the FBI has also deployed sophisticated tracking efforts to monitor foreign spies.  During the waning days of the Cold War, the FBI deployed sophisticated monitoring gear on bridges and highways around Washington to track Russian spies.

The arrest of FBI Special Agent Robert Hanssen also uncovered an elaborate effort by the FBI and NSA to tunnel under the Russian embassy in Washington and place surveillance gear, bugs, and receivers in an effort to attack the embassy's telecommunication gear.  The U.S. team employed cutting edge technology including directing laser beams through the steel support columns to pick up electronic emanations, and aiming energy beams at the embassy windows to "read" the vibrations in the glass and pick up conversation.  A less high-tech component of the attack reportedly included using a dwarf to scale inside the embassy wall and emplace listening devices.

Given this historical practice, I suspect what happened in Havana was unfortunate but probably a collection/counterintelligence attack gone wrong rather than a directed attack intended to hurt diplomats. As Senator Rubio correctly pointed out, the Cuban government has long harassed U.S. representatives, and engaged in intrusive tracking of our representatives in Havana. However, we have never seen them try to do serious harm to our diplomats perhaps for fear that we could do the same).  Deployment of a weapon across these different times and locations by a third party is possible but highly unlikely without the direct assistance of the Cuban government.  If Cuba or another country was hoping to use a dangerous and sophisticated attack to achieve some goal or send a message, it doesn't sound like the message was received either. Usually the simplest explanation is the most likely.  Either way, the Cuban government has an obligation under existing treaties to protect foreign diplomats, and harmful effects, whether they result from surveillance or not, should be condemned.

There is also another lesson here. Our diplomats overseas often work in difficult places, sometimes facing harassment, surveillance and other challenges.  That is why President Donald Trump's thoughtless comments about our diplomats (and by extension their families) in Moscow go over so poorly with our public servants around the world.  Despite the obvious hardships of being away from the United States in difficult environments, there are often hidden or untold challenges which potentially include being monitored day and night and serious health risks from invisible corners.

The story emerging out of Cuba is simply not as bizarre as it might seem at first blush. It is unfortunately all too familiar to those who serve our country in hostile and risky environments.

Monday, April 07, 2014

Bypassing the XSS filter using function reassignment

The XSS filter introduced in IE8 is a really powerful defence against XSS. I tested the filter for a number of years and found various bypasses one of which I would like to share with you now. You can read more about the filter and its goal in the following blog post.

Scope

There have been numerous public bypasses of the filter however very few within the intended scope of the filter. The filter blocks reflected XSS in HTML context, script, style and event context. It does not support attacks that use multiple parameters or same origin requests. Once you are aware of the intended scope the difficulty of bypassing the filter is very high.

Function reassignment

This bypass was fixed in later versions of Internet Explorer but still works in compatibility mode. You can use the vector in a penetration test by forcing the target site into compatibility mode using an iframe with an EmulateIE7 meta element as shown below.

<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" />

This loads IE in emulate mode and the entire JavaScript engine will revert to an older mode enabling the vector to function. We need to setup a page with the target input inside a function argument in order to demonstrate the bypass. As you can see below the parameter "x" appears inside a string which calls the function "x".


<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" />
<script>
function x() {

}
<?php
$x = isset($_GET['x']) ? $_GET['x'] : '';
?>
x('<?php echo $x?&gtl');
</script>

In older versions of Internet Explorer it's possible to redefine a function within its calling arguments. This is very useful for bypassing the filter when your XSS hole executes within a function argument. To see how this works we pass a GET request to "x" within a payload that redefines the function "x" to alert and uses an argument before our break out string to pass to the function. The GET request looks like this:
somepage.php?x=1′,x=alert,'

The output of the page now looks like this:

<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" />
<script>
function x() {

}
x('1',x=alert,'');
</script>

"1" is inserted at the start of the argument then we break out of the string and redefine the function "x" to alert then finish up by completing the string. The alert function only accepts 1 argument so our other arguments are ignored and alert(1) executes successfully.

Conclusion

As mentioned previously this vector was patched in later versions of IE however it will still work where a target site is in compatibility mode or you can force it into the older mode using iframes. The newer JavaScript engines in IE will not allow you to redefine functions within arguments. To protect against this vector you can force your site into standards mode by specifying a doctype or using the X-UA-Compatible header or meta element in edge mode. Preventing your site from being framed is also a good idea using the X-Frames-Option header and of course fixing the actual XSS hole in the first place is preferred.

 

Saturday, April 05, 2014

How I Hacked Your Router

Some time ago a friend in infosec asked me to do a strange thing.  He asked me to hack him.  We will call him Bill, for the sake of anonymity.  Other names and places have been changed to protect the innocent.  Vendor names have been kept to incriminate the guilty.

Hacking a large corporation is easy(ish).  They have information assets that may span the globe, and despite investments in various protection technologies, it's just hard to keep track of all that stuff.  It requires Zen-like discipline to rigorously follow the cycle of scan-patch-repeat day after day, on all assets in an organization, without fail.

Hacking a person can be tough.  It's true that blackhats have the advantage in terms of the asymmetric nature of information security.  Sometimes it only takes one bug.  But the attack surface area of a single individual is quite small compared to a corporation.  In addition, most people trust large vendors with their information and the cloud vendors typically do a decent job of protecting people.

I started with basic recon.  I like to use Maltego, along with sites like checkusernames.com, knowem.com, pipl search, and other tools to enumerate online presence.  There's also the classics like Google+, Facebook and Linkedin.  It helps to have a fake profile on Facebook for this kind of work.  A good bait profile should be tuned to your target.  It will help when extracting additional information via social engineering.

In terms of online presence, password reset questions are good low hanging fruit.  I've seen webmail accounts asking for information that you can pull right out of the target's Facebook profile.  I'm sure most people don't even make the connection; they may have written their reset questions 5 years ago.  None of this stuff was going to work in this case though.  My target was an infosec nerd, and he was expecting me.

Time to take the fight to him.  First, I checked to see if he is hosting anything on his home Internet connection.  He may have been doing this and not even know it.  Many apps and devices use UPnP to punch holes in consumer-grade firewalls without much fanfare.  Sometimes all it takes is a NAS or media server to open up a backdoor.  To find his home IP address, I used a Skype resolver, such as resolvme.org.  It worked brilliantly, so I scanned his IP address (and a few neighboring IPs) to see if I could find any services.  No dice though… I'm sure he figured I would do this.

Next up, 802.11.  Wireless networks are a great attack vector.  I have two Radeon 6990′s in an i7 rig that chews through WPA hashes.  I use a Markov predictive wordlist generator to feed guesses to oclHashcat.  It can achieve an 80% average crack rate over an 8 hour time frame.

So I set about to Bill's address with various Alfa wifi cards in tow.  While in this case I actually know Bill's address, I may have been able to get this information via recon or social engineering.  It's not exactly a secret.  After successfully capturing a WPA handshake, I ran the cracker for a week.  Still no dice.  This would probably work on most people, but Bill is an infosec guy.  His WPA key is probably >32 characters long.

At this point you're probably wondering why I didn't just spear-phish him with a Java 0-day and go have my victory beer.  The answer is simple — I know my target.  He has mastered the mantra of scan-patch-repeat.  Java isn't even installed.  And if I did have a browser 0-day in my back pocket, I would have used it to win the pwn2own last week.

After my visit to Bill's place, I did come away with one useful piece of information.  The wireless MAC address (BSSID) of his router: 06:A1:51:E3:15:E3.  Since I have the OUI (the first 3 bytes of the MAC), I know that it's a Netgear router.  I also know that Netgear routers have some issues, but Bill was running the latest firmware.  That doesn't mean that all the vulnerabilities were patched in the latest firmware though.  The only way to be sure was to buy a Netgear router and test it myself.

Determining the exact model is probably not possible (not remotely anyway).  Consumer devices may have a lot of variation between different models as the reference platforms come from SoC vendors such as Broadcom and Atheros.  I know that Bill is a bit frugal, so I went with the WNDR3400v3 — the entry level unit.

After reading about some of the vulnerabilities this device has had in the past, I created two Metasploit modules.  In the first module, I would use a CSRF bug to POST to the UPnP interface and punch a hole to access the telnet service of the router itself.  This issue likely exists in numerous other devices and is worth emphasizing:

If you can spoof UPnP requests via CSRF, you can turn the entire network inside-out.

That's an important point.  I was opening up a single port.  You can use Ajax requests from the victim's browser to configure NAT entries for every IP in a subnet, effectively disabling the firewall.  There are hard limits to the number of UPnP NAT entries of course, but most devices will allow enough entries to map a few key ports for a hundred hosts or so.

In order to trick Bill into connecting to my exploit, I sent him an email with an embedded link.  Cobalt Strike has a tool to copy an existing email (headers and all), which makes this basically turn-key.  All you need to do is modify the links.  So what email does everyone always click?  What would work even against an infosec guy?  Linkedin invites.

Now before I sent the email, I needed a follow up payload.  By default, the telnet port is enabled on Netgear routers, but the service is unresponsive.  You have to connect to the port and send a special unlock key.  Public exploits exist for this flaw, but I wrote another MSF modulebecause I love my Ruby (and Metasploit).

Bill clicked the link.  As soon as I saw the callback, I triggered the second module and logged into the router via telnet.  Once I obtained root access to the router, I immediately changed the DNS settings to point to a DNS server that I control.

Controlling DNS is a powerful thing; it effectively provides you with on-demand man-in-the-middle.  There are plenty of MITM attack vectors, but I like Evilgrade for stealth.  Evilgrade has been out for years, and still works great (some modifications necessary).  It took about a week before Bill decided to upgrade notepad++ to the new version.  When he did, he was fed a backdoored version that gave me a Meterpreter shell on his computer.  I immediately emailed him a few screen shots and a keystroke log, and he unplugged his computer a few minutes later.

For my efforts, I was rewarded with a six-pack of Ruby ale.  I do love my Ruby.

Wednesday, March 12, 2014

SamsungGalaxyBackdoor

This page contains a technical description of the back-door found in Samsung Galaxy devices.
For a general description of the issue, please refer to the statement published on the Free Software Foundation's website.

This back-door is present in most proprietary Android systems running on the affected Samsung Galaxy devices, including the ones that are shipped with the devices. However, when Replicant is installed on the device, this back-door is not effective: Replicant does not cooperate with back-doors.

Abstract

Samsung Galaxy devices running proprietary Android versions come with a back-door that provides remote access to the data stored on the device.
In particular, the proprietary software that is in charge of handling the communications with the modem, using the Samsung IPC protocol, implements a class of requests known as RFS commands, that allows the modem to perform remote I/O operations on the phone's storage. As the modem is running proprietary software, it is likely that it offers over-the-air remote control, that could then be used to issue the incriminated RFS messages and access the phone's file system.

Known affected devices

The following table shows which devices are known to contain this back-door as part of the software they ship with.
Please contact us if you know about some other device that could be concerned by this back-door or have more information on one of the listed devices!

DeviceIncriminated program running as rootSELinux enabledlibsamsung-ipc supportReplicant support
Nexus S (I902x)NoPossible with Android 4.2 and laterYesYes
Galaxy S (I9000)Yes?YesYes
Galaxy S 2 (I9100)No?YesYes
Galaxy Note (N7000)No?YesYes
Galaxy Nexus (I9250)NoPossible with Android 4.2 and laterYesYes
Galaxy Tab 2 7.0 (P31xx)No?YesYes
Galaxy Tab 2 10.1 (P51xx)No?YesYes
Galaxy S 3 (I9300)No?YesYes
Galaxy Note 2 (N7100)No?YesYes

Back-door sample

In order to investigate the back-door and check what it actually lets the modem do, some code was added to the modem kernel driver to make it craft and inject requests using the incriminated messages and check its results.

The following patch: 0001-modem_if-Inject-and-intercept-RFS-I-O-messages-to-pe.patch (to apply to the SMDK4412 Replicant 4.2 kernel) implements a sample use of the back-door that will:
  • open the /data/radio/test file
  • read its content
  • close the file

This demonstrates that the incriminated software will execute these operations upon modem request. Note that the software implementation appends /efs/root/ to the provided path, but it's fairly simple to escape that path and request any file on the file system (using ../../). Note that the files are opened with the incriminated software's user permissions, which may be root on some devices. On other cases, its runs as an unprivileged user that can still access the user's personal data (/sdcard). Finally, some devices may implement SELinux, which considerably restricts the scope of possible files that the modem can access, including the user's personal data (/sdcard/).

The following sample was obtained on a Galaxy Note 2 (N7100) running CyanogenMod 10.1.3.

Sample file

The sample file used for this demonstration (/data/radio/test) is filled with "Hello World!":

root@android:/ # hexdump -C /data/radio/test  00000000  48 65 6c 6c 6f 20 57 6f  72 6c 64 21 0a           |Hello World!.|  0000000d  

Kernel log

<3>[   62.712637] c0 mif: rx_iodev_skb: rx_iodev_skb: Dropping RFS frame  <3>[   62.712808] c0 mif: rfs_craft_start: rfs_craft_start: Crafting open  <3>[   62.712966] c0 mif: rfs_craft_start: rfs_craft_start: Adding SKB to queue  <3>[   62.713122] c0 mif: rx_iodev_skb: rx_iodev_skb: Dropping RFS frame  <3>[   62.744690] c0 mif: misc_write: misc_write: Intercepted RFS response  <3>[   62.744867] c0 mif: rfs_craft_write: rfs_craft_write: Open response: fd=21, errno=0  <3>[   62.745116] c0 mif: rfs_craft_write: rfs_craft_write: Adding SKB to queue  <3>[   62.792888] c0 mif: misc_write: misc_write: Intercepted RFS response  <3>[   62.793026] c0 mif: rfs_craft_write: rfs_craft_write: Read response: 12 bytes read  <3>[   62.793154] c0 mif: mif_print_data: 0000: 48 65 6c 6c  6f 20 57 6f  72 6c 64 21    <3>[   62.793284] c0 mif: rfs_craft_write: rfs_craft_write: Adding SKB to queue  <3>[   62.796168] c0 mif: misc_write: misc_write: Intercepted RFS response  <3>[   62.796269] c0 mif: rfs_craft_write: rfs_craft_write: Rx RFS message with command 0x6 and size 14  <3>[   62.796422] c0 mif: mif_print_data: 0000: 00 00 00 00  00 00 00 00    

The relevant part is the response to the read request:

<3>[   62.793026] c0 mif: rfs_craft_write: rfs_craft_write: Read response: 12 bytes read  <3>[   62.793154] c0 mif: mif_print_data: 0000: 48 65 6c 6c  6f 20 57 6f  72 6c 64 21    

which matches the content of the /data/radio/test file, hence making it obvious that the incriminated software implements the back-door.

Incriminated software log

E/RIL     ( 1927): processRFS: received standalone RFS frame. len 35  E/RIL     ( 1927): ipc_recv_rfs()  E/RIL     ( 1927): get_wakelock: 1. on 1, ril_WakeLock_Mask 0  E/RIL     ( 1927): get_wakelock: 2. on 1, ril_WakeLock_Mask 1  E/RIL     ( 1927): RxRFS_OpenFile:   E/RIL     ( 1927): RxRFS_OpenFile: open file "/efs/root/../../data/radio/test" flag O_RDWR (0x00000002)  E/RIL     ( 1927): check dir '/efs/root/../../data/radio'  E/RIL     ( 1927): A directory already exists.  E/RIL     ( 1927): RxRFS_OpenFile: length 14  E/RIL     ( 1927): TxRFS_CfrmOpenFile()  E/RIL     ( 1927): TxRFS_CfrmOpenFile(): length 14  E/RIL     ( 1927): IPC_send_singleRfsIPC: fd 16 sendto 14 bytes rfs_hdr =6  E/RIL     ( 1927): get_wakelock: 1. on 0, ril_WakeLock_Mask 1  E/RIL     ( 1927): get_wakelock: 2. on 0, ril_WakeLock_Mask 0  E/RIL     ( 1927): set_wakelock: secril_rfs-interface 0  E/RIL     ( 1927): set_wakelock: secril_fmt-interface 1  E/RIL     ( 1927): processIPC: Single IPC plen 23, pkt 23  
E/RIL     ( 1927): processRFS: received standalone RFS frame. len 14  E/RIL     ( 1927): ipc_recv_rfs()  E/RIL     ( 1927): get_wakelock: 1. on 1, ril_WakeLock_Mask 0  E/RIL     ( 1927): get_wakelock: 2. on 1, ril_WakeLock_Mask 1  E/RIL     ( 1927): RxRFS_ReadFile:   E/RIL     ( 1927): RxRFS_ReadFile: length 4110  E/RIL     ( 1927): TxRFS_CfrmReadFile()  E/RIL     ( 1927): TxRFS_CfrmReadFile(): length 4110  E/RIL     ( 1927): IPC_send_singleRfsIPC: fd 16 sendto 4110 bytes rfs_hdr =6  
E/RIL     ( 1927): processRFS: received standalone RFS frame. len 10  E/RIL     ( 1927): get_wakelock: 1. on 0, ril_WakeLock_Mask 1  E/RIL     ( 1927): get_wakelock: 2. on 0, ril_WakeLock_Mask 0  E/RIL     ( 1927): set_wakelock: secril_rfs-interface 0  E/RIL     ( 1927): [EVT]:Req(0), RX(0)  E/RIL     ( 1927): ipc_recv_rfs()  E/RIL     ( 1927): get_wakelock: 1. on 1, ril_WakeLock_Mask 0  E/RIL     ( 1927): get_wakelock: 2. on 1, ril_WakeLock_Mask 1  E/RIL     ( 1927): RxRFS_CloseFile:   E/RIL     ( 1927): RxRFS_CloseFile: length 14  E/RIL     ( 1927): TxRFS_CfrmCloseFile()  E/RIL     ( 1927): TxRFS_CfrmCloseFile(): length 14  E/RIL     ( 1927): IPC_send_singleRfsIPC: fd 16 sendto 14 bytes rfs_hdr =6  

Analysis

The following analysis was conducted using the libsec-ril.so binary file (the incriminated proprietary software) as extracted from the CyanogenMod 10.1.3 system zip for the Galaxy S 3 (I9300), from location system/lib/libsec-ril.so.

The developers involved in the present analysis did not ever agree to any sort of End User License Agreement that explicitly prohibited the reverse engineering and decompiling operations of the incriminated binary. The reverse engineering operations that led to these findings originally took place during the development of Samsung-RIL, the free software replacement for the incriminated program. Hence, we believe these operations were conducted for the sole purpose of interoperability and not with the intent of creating a competing product. As the involved developers were based in Europe, we believe the legality of these operations is granted by article 6 of the 1991 EU Computer Programs Directive.

As a first approach, using the strings tool against the incriminated program reveals numerous suspicious command names that appear to be Samsung IPC protocol definitions:

IPC_RFS_READ_FILE  IPC_RFS_WRITE_FILE  IPC_RFS_LSEEK_FILE  IPC_RFS_CLOSE_FILE  IPC_RFS_PUT_FILE  IPC_RFS_GET_FILE  IPC_RFS_RENAME_FILE  IPC_RFS_GET_FILE_INFO  IPC_RFS_UNLINK_FILE  IPC_RFS_MAKE_DIR  IPC_RFS_REMOVE_DIR  IPC_RFS_OPEN_DIR  IPC_RFS_READ_DIR  IPC_RFS_CLOSE_DIR  IPC_RFS_OPEN_FILE  IPC_RFS_FTRUNCATE_FILE  IPC_RFS_GET_HANDLE_INFO  IPC_RFS_CREATE_FILE  

The names of these commands make it obvious that they let the modem perform I/O operations.

The strings utility also reveals matching function names that seem to implement the handling of these commands:

RxRFS_GetFile  RxRFS_CreateFile  RxRFS_ReadDirectory  RxRFS_OpenDirectory  RxRFS_RenameFile  RxRFS_Default  RxRFS_OpenFile  RxRFS_ReadFile  RxRFS_FtruncateFile  RxRFS_WriteFile  RxRFS_GetFileInfoByHandle  RxRFS_GetFileInfo  RxRFS_PutFile  RxRFS_LseekFile  RxRFS_CloseFile  RxRFS_DeleteFile  RxRFS_MakeDirectory  RxRFS_CloseDirectory  RxRFS_RemoveDirectory  TxRFS_CfrmCreateFile  TxRFS_CfrmPutFile  TxRFS_CfrmOpenDirectory  TxRFS_CfrmGetFileInfo  TxRFS_CfrmReadDirectory  TxRFS_CfrmRenameFile  TxRFS_CfrmCloseFile  TxRFS_CfrmFtruncateFile  TxRFS_CfrmGetFileInfoByHandle  TxRFS_CfrmDeleteFile  TxRFS_CfrmCloseDirectory  TxRFS_CfrmRemoveDirectory  TxRFS_CfrmMakeDirectory  TxRFS_CfrmGetFile  TxRFS_CfrmReadFile  TxRFS_CfrmWriteFile  TxRFS_CfrmLseekFile  TxRFS_CfrmOpenFile  

Taking a closer look at these functions, using the objdump decompiler, reveals that they are actually called from the ipc_recv_rfs function, itself called fromprocess_ipc_notify_message, which appears to handle the received messages from the modem. Hence we can deduct that the incriminated functions are actually called upon modem request.

Taking a closer look at one of these functions, e.g. RxRFS_ReadFile reveals multiple calls to the Procedure Linkage Table (PLT). Hence we believe these calls are linked functions from the libc library, especially I/O-related functions such as (in a general manner) openclosereadwrite, etc.

Samsung IPC RFS messages

The following table associates each Samsung IPC RFS message with its hexadecimal command value:

MessageHexadecimal command value
IPC_RFS_NV_READ_ITEM0x01
IPC_RFS_NV_WRITE_ITEM0x02
IPC_RFS_READ_FILE0x03
IPC_RFS_WRITE_FILE0x04
IPC_RFS_LSEEK_FILE0x05
IPC_RFS_CLOSE_FILE0x06
IPC_RFS_PUT_FILE0x07
IPC_RFS_GET_FILE0x08
IPC_RFS_RENAME_FILE0x09
IPC_RFS_GET_FILE_INFO0x0a
IPC_RFS_UNLINK_FILE0x0b
IPC_RFS_MAKE_DIR0x0c
IPC_RFS_REMOVE_DIR0x0d
IPC_RFS_OPEN_DIR0x0e
IPC_RFS_READ_DIR0x0f
IPC_RFS_CLOSE_DIR0x10
IPC_RFS_OPEN_FILE0x11
IPC_RFS_FTRUNCATE_FILE0x12
IPC_RFS_GET_HANDLE_INFO0x13
IPC_RFS_CREATE_FILE0x14
IPC_RFS_NV_WRITE_ALL_ITEM0x15

Legitimacy

The incriminated RFS messages of the Samsung IPC protocol were not found to have any particular legitimacy nor relevant use-case. However, it is possible that these were added for legitimate purposes, without the intent of doing harm by providing a back-door. Nevertheless, the result is the same and it allows the modem to access the phone's storage.

However, some RFS messages of the Samsung IPC protocol are legitimate (IPC_RFS_NV_READ_ITEM and IPC_RFS_NV_WRITE_ITEM) as they target a very precise file, known as the modem's NV data. There should be no particular security concern about these as both the proprietary implementation and its free software replacement strictly limit actions to that particular file.

Areas of work

Some work could be done in order to handle that back-door:
  • Samsung-RIL could show a message alerting the user when the back-door is being used, including the requested path and asking the user to save logs and contact us.
  • Alternatively, the kernel could block the incriminated RFS requests and keep a trace of them in the logs for the record. That option would work for CyanogenMod, where the incriminated proprietary blob is still used.

Notes

Our free software replacement for the incriminated binary is Samsung-RIL which relies on libsamsung-ipc: both are used in Replicant.

The affected devices have modems that use the Samsung IPC protocol, mostly Intel XMM6160 and Intel XMM6260 modems. Note that despite this back-door, the devices using these modems are most likely to have good modem isolation, compared to other devices using Qualcomm platforms. Bear in mind that this back-door is implemented in software and can easily be removed by installing a free replacement for the incriminated software, for instance by installing Replicant. Hence, we don't consider the incriminated devices to be inherently bad targets because of this back-door.

0001-modem_if-Inject-and-intercept-RFS-I-O-messages-to-pe.patch (5.6 kB) Paul Kocialkowski, 02/04/2014 06:57 PM