Xen Gets bashed | TechSNAP 182

chris

8 years ago

Recent major flaws found in in critical open source software have sent the Internet into a panic. From Shellshock to Xen we’ll discuss how these vulnerabilities can be chained together to own a box.

Plus how secure are VLANs, a big batch of your questions, our answers, and much much more!

Thanks to:

Direct Download:

RSS Feeds:

Become a supporter on Patreon:

— Show Notes: —

Bash plus Xen bug send the entire internet scrambling

A critical flaw was discovered in the bash shell, used as the default system shell in most versions of linux, as well as OS X.
The flaw was with the parsing of environment variables. If a new variable was set to contain a function, if that function was followed by a semi-colon (normally a separator that can be used to chain multiple commands together), the code after the semicolon would be be executed when the shell started
Many people are not aware, that CGI scripts pass the original request data, as well as all HTTP headers to the scripts via environment variables
After those using bash CGI scripts ran around with chickens with their heads cut off, others came to realize that even if the CGI scripts are actually perl or something else, if they happen to fork a shell with the system() call, or similar, to do something, that shell will inherit those environment variables, and be vulnerable
As more people spent brain cycles thinking of creative ways to exploit this bug, it was realized that even qmail was vulnerable in some cases, if a user has a .qmail file or similar to forward their email via a pipe, that command is executed via the system shell, with environment variables containing the email headers, including from, to, subject etc
While FreeBSD does not ship with bash by default, it is a common dependency of most of the desktop environments, including gnome and KDE. PCBSD also makes bash available to users, to make life easier to linux switchers. FreeNAS uses bash for its interactive web shell for the same reason. While not vulnerable in most cases, all have been updated to ensure that some new creative way to exploit the bug does not crop up
Apparently the DHCP client in Mac OS X also uses bash, and a malicious DHCP server could exploit the flaw
The flaw also affects a number of VMWare products
OpenVPN and many other software packages have also been found to be vulnerable
The version of bash on your system can be tested easily with this one-liner:
env x='() { :;}; echo vulnerable’ bash -c “echo this is a test”
Which will print “this is a test”, and if bash has not yet been patched, will first print ‘vulnerable’
ArsTechnica: Bug in bash shell creates big security hole on anything with linux in it
Concern over bash bug grows as it is actively exploited in the wild
First bash patch doesn’t solve problem, second patch rushed out to resolve issue
Now that people are looking, even more bugs in bash found and fixed
Shellshock fixes result in another round of patches as attacks get more clever
Apple releases patch for shellshock bug
There were also a critical update to NSS (the Mozilla cryptographic library, which was not properly validating SSL certificates)
The other big patch this week was for Xen
It was announced by a number of public cloud providers, including Amazon and Rackspace, that some virtual server host machines would need to be rebooted to install security fixes, resulting in downtime for 10% of Amazon instances
It is not clear why this could not be resolved by live migrations
All versions of Xen since 4.1 until this patch are vulnerable. The flaw is only exploitable when running fully virtualized guests (HVM mode, uses the processor virtualization features), and can not be exploited by virtual machines running in the older paravirtualization mode. Xen on ARM is not affected
Xen Security Advisory
Amazon Blog Post #1
Amazon Blog Post #2
Rackspace Blog Post
Additional Coverage: eweek

Cox Communications takes the privacy of its customers seriously, kind of

A female employee of Cox Communications (a large US ISP) was socially engineered into giving up her username and password
These credentials were then used to access the private data of Cox Customers
The attacker apparently only stole data about 52 customers, one of which was Brian Krebs
This makes it sound like a targeted attack, or at least an attacker by someone who is (or is not) a fan of Brian Krebs
It appears that the Cox internal customer database can be accessed directly from the internet, with only a username and password
Cox says they use two factor authentication “in some cases”, and plan to expand the use of 2FA in the wake of this breach
Cox being able to quickly determine exactly how many customers’ data was compromised suggests they atleast have some form of auditing in place, to leave a trail describing what data was accessed
Brian points out: “This sad state of affairs is likely the same across multiple companies that claim to be protecting your personal and financial data. In my opinion, any company — particularly one in the ISP business — that isn’t using more than a username and a password to protect their customers’ personal information should be publicly shamed.” “Unfortunately, most companies will not proactively take steps to safeguard this information until they are forced to do so — usually in response to a data breach. Barring any pressure from Congress to find proactive ways to avoid breaches like this one, companies will continue to guarantee the security and privacy of their customers’ records, one breach at a time.”

Other researches recreate the BadUSB exploit and release the code on Github

The “BadUSB” research was originally done by Karsten Nohl and Jakob Lell, at SR Labs in Germany.
Presented at BlackHat, it described being able to reprogram the firmware of USB devices to perform other functions, such as a USB memory stick that presented itself to the computer as a keyboard, and typed out commands once plugged in, allowing it to compromise the computer and exfiltrate data
Brandon Wilson and Adam Caudill were doing their own work in this space, and when they heard about the talk at BlackHat, decided to accelerate their own work
They have now posted their code on Github
“The problem is that Nohl and Lell—and Caudill and Wilson—have not exploited vulnerabilities in USB. They’re just taking advantage of weaknesses in the manner in which USBs are supposed to behave“
“At Derby Con, they were able to demonstrate their attack with the device pretending to be a keyboard that typed out a predetermined script once it was plugged into the host computer. They also showed another demo where they had a hidden partition on a flash drive that was not detected by the host PC“
“It’s undetectable while it’s happening,” Wilson said. “The PC has no way of determining the difference. The way a PC determines the type of device all happens through the USB and code on the other device. Our ability to control that code means you cannot trust anything a USB device tells you.”
The way around this issue would be for device manufacturers to implement code signing
The existing firmware would only allow the firmware to be updated if the new firmware was signed by the manufacturer, preventing a malicious users from overwriting the good firmware with ‘bad’ firmware
However, users could obviously create their own devices specifically for the purpose of the evil firmware, but it would prevent the case where an attack modifies your device to work against you
At the same time, many users might argue against losing control over their device, and no longer being able to update the firmware if they wish
The real solution may be for Operating Systems and users to evolve to no longer trust random USB devices, and instead allow the user to decide if they trust the device, possibly something similar to mobile apps, where the OS tells the user what functionality the device is trying to present
You might choose to not trust that USB memstick that is also attempting to present a network adapter, in order to override your DHCP settings and make your system use a set of rogue DNS servers