This Week In Security: SACK Of Death, Rambleed, HIBP For Sale, And Oracle Weblogic — Again!

Netflix isn’t the first name to come to mind when considering security research firms, but they make heavy use of FreeBSD in their content delivery system and do security research as a result. Their first security bulletin of the year, not surprisingly, covers a FreeBSD vulnerability that happens to also affect Linux kernels from the last 10 years. This vulnerability uses SACKs and odd MSS values to crash a server kernel.

To understand Selective ACKs, we need to step back and look at how TCP connections work. TCP connections provide guaranteed delivery, implemented in the from of ACKnowledgement (ACK) packets. We think of a TCP connection as having a dedicated ACK packet for every data packet. In reality, the Operating System makes great effort to avoid sending “naked” ACK packets, and combines multiple ACKs in a single packet. An ACK is simply a flag in a packet header combined with a running total of bytes received, and can be included in a normal data packet. As much as is possible, the ACK for data received is sent along with data packets flowing in the opposite direction. Continue reading “This Week In Security: SACK Of Death, Rambleed, HIBP For Sale, And Oracle Weblogic — Again!”

This Week In Security: What’s Up With Whatsapp, Windows XP Patches, And Cisco Is Attacked By The Thrangrycat

Whatsapp allows for end-to-end encrypted messaging, secure VoIP calls, and until this week, malware installation when receiving a call. A maliciously crafted SRTCP connection can trigger a buffer overflow, and execute code on the target device. The vulnerability was apparently found first by a surveillance company, The NSO Group. NSO is known for Pegasus, a commercial spyware program that they’ve marketed to governments and intelligence agencies, and which has been implicated in a number of human rights violations and even the assassination of Jamal Khashoggi. It seems that this Whatsapp vulnerability was one of the infection vectors used by the Pegasus program. After independently discovering the flaw, Facebook pushed a fixed client on Monday.

Windows XP Patched Against Wormable Vulnerability

What year is it!? This Tuesday, Microsoft released a patch for Windows XP, five years after support for the venerable OS officially ended. Reminiscent of the last time Microsoft patched Windows XP, when Wannacry was the crisis. This week, Microsoft patched a Remote Desktop Protocol (RDP) vulnerability, CVE-2019-0708. The vulnerability allows an attacker to connect to the RDP service, send a malicious request, and have control over the system. Since no authentication is required, the vulnerability is considered “wormable”, or exploitable by a self-replicating program.

Windows XP through Windows 7 has the flaw, and fixes were rolled out, though notably not for Windows Vista. It’s been reported that it’s possible to download the patch for Server 2008 and manually apply it to Windows Vista. That said, it’s high time to retire the unsupported systems, or at least disconnect them from the network.

The Worst Vulnerability Name of All Time

Thrangrycat. Or more accurately, “😾😾😾” is a newly announced vulnerability in Cisco products, discovered by Red Balloon Security. Cisco uses secure boot on many of their devices in order to prevent malicious tampering with device firmware. Secure boot is achieved through the use of a secondary processor, a Trust Anchor module (TAm). This module ensures that the rest of the system is running properly signed firmware. The only problem with this scheme is that the dedicated TAm also has firmware, and that firmware can be attacked. The TAm processor is actually an FPGA, and researchers discovered that it was possible to modify the FPGA bitstream, totally defeating the secure boot mechanism.

The name of the attack, thrangrycat, might be a satirical shot at other ridiculous vulnerability names. Naming issues aside, it’s an impressive bit of work, numbered CVE-2019-1649. At the same time, Red Balloon Security disclosed another vulnerability that allowed command injection by an authenticated user.

Odds and Ends

See a security story you think we should cover? Drop us a note in the tip jar!

This Week In Security: Facebook Hacked Your Email, Cyber On The Power Grid, And A Nasty Zero-day

Ah, Facebook. Only you could mess up email verification this badly, and still get a million people to hand over their email address passwords. Yes, you read that right, Facebook’s email verification scheme was to ask users for their email address and email account password. During the verification, Facebook automatically downloaded the account’s contact list, with no warning and no way to opt out.

The amount of terrible here is mind-boggling, but perhaps we need a new security rule-of-thumb for these kind of situations. Don’t ever give an online service the password to a different service. In order to make use of a password in this case, it’s necessary to handle it in plain-text. It’s not certain how long Facebook stored these passwords, but they also recently disclosed that they have been storing millions of Facebook and Instagram passwords in plain-text internally.

This isn’t the first time Facebook has been called out for serious privacy shenanigans, either: In early 2018 it was revealed that the Facebook Android app had been uploading phone call records without informing users. Mark Zuckerberg has recently outlined his plan to give Facebook a new focus on privacy. Time will tell whether any real change will occur.

Cyber Can Mean Anything

Have you noticed that “cyber” has become a meaningless buzz-word, particularly when used by the usual suspects? The Department of Energy released a report that contained a vague but interesting sounding description of an event: “Cyber event that causes interruptions of electrical system operations.” This was noticed by news outlets, and people have been speculating ever since. What is frustrating about this is the wide range of meaning covered by the term “cyber event”. Was it an actual attack? Was Trinity shutting down the power stations, or did an intern trip over a power cord?
Continue reading “This Week In Security: Facebook Hacked Your Email, Cyber On The Power Grid, And A Nasty Zero-day”

Spoiler, Use-After-Free, And Ghidra: This Week In Computer Security

The past few days have been busy if you’re trying to keep up with the pace of computer security news. Between a serious Chromium bug that’s actively being exploited on Windows 7 systems, the NSA releasing one of their tools as an open source project, and a new Spectre-like speculative execution flaw in Intel processors, there’s a lot to digest.
Continue reading “Spoiler, Use-After-Free, And Ghidra: This Week In Computer Security”

Unlocking God Mode On X86 Processors

We missed this Blackhat talk back in August, but it’s so good we’re glad to find out about it now. [Christopher Domas] details his obsession with hidden processor instructions, and how he discovered an intentional backdoor in certain x86 processors. These processors have a secondary RISC core, and an undocumented procedure to run code on that core, bypassing the normal user/kernel separation mechanisms.

The result is that these specific processors have an intentional mechanism that allows any unprivileged user to jump directly to root level access. The most fascinating part of the talk is the methodical approach [Domas] took to discover the details of this undocumented feature. Once he had an idea of what he was looking for, he automated the process of checking every possible x86 instruction, looking for the one instruction that allowed running code on that extra core. The whole talk is entertaining and instructional, check it out after the break!

There’s a ton of research poking at the instruction level of complication processors. One of our favorites, also by [Domas], is sandsifter which searches for undocumented instructions.

Continue reading “Unlocking God Mode On X86 Processors”

When Good Software Goes Bad: Malware In Open Source

Open Source software is always trustworthy, right? [Bertus] broke a story about a malicious Python package called “Colourama”. When used, it secretly installs a VBscript that watches the system clipboard for a Bitcoin address, and replaces that address with a hardcoded one. Essentially this plugin attempts to redirects Bitcoin payments to whoever wrote the “colourama” library.

Why would anyone install this thing? There is a legitimate package named “Colorama” that takes ANSI color commands, and translates them to the Windows terminal. It’s a fairly popular library, but more importantly, the name contains a word with multiple spellings. If you ask a friend to recommend a color library and she says “coulourama” with a British accent, you might just spell it that way. So the attack is simple: copy the original project’s code into a new misspelled project, and add a nasty surprise.

Sneaking malicious software into existing codebases isn’t new, and this particular cheap and easy attack vector has a name: “typo-squatting”.  But how did this package get hosted on PyPi, the main source of community contributed goodness for Python? How many of you have downloaded packages from PyPi without looking through all of the source? pip install colorama? We’d guess that it’s nearly all of us who use Python.

It’s not just Python, either. A similar issue was found on the NPM javascript repository in 2017. A user submitted a handful of new packages, all typo-squatting on existing, popular packages. Each package contained malicious code that grabbed environment variables and uploaded them to the author. How many web devs installed these packages in a hurry?

Of course, this problem isn’t unique to open source. “Abstractism” was a game hosted on Steam, until it was discovered to be mining Monero while gamers were playing. There are plenty of other examples of malicious software masquerading as something else– a sizable chunk of my day job is cleaning up computers after someone tried to download Flash Player from a shady website.

Buyer Beware

In the open source world, we’ve become accustomed to simply downloading libraries that purport to do exactly the cool thing we’re looking for, and none of us have the time to pore through the code line by line. How can you trust them?

Repositories like PyPi do a good job of faithfully packaging the libraries and programs that are submitted to them. As the size of these repositories grow, it becomes less and less practical for every package to be manually reviewed. PyPi lists 156,750 projeccts. Automated scanning like [Bertus] was doing is a great step towards keeping malicious code out of our repositories. Indeed, [Bertus] has found eleven other malicious packages while testing the PyPi repository. But cleverer hackers will probably find their way around automated testing.

That the libraries are open source does add an extra layer of reliability, because the code can in principal be audited by anyone, anytime. As libraries are used, bugs are found, and features are added, more and more people are intentionally and unintentionally reviewing the code. In the “colourama” example, a long Base64 string was decoded and executed. It doesn’t take a professional researcher to realize something fishy is going on. At some point, enough people have reviewed a codebase that it can be reasonably trusted. “Colorama” has well over a thousand stars on Github, and 28 contributors. But did you check that before downloading it?

Typo-squatting abuses trust, taking advantage of a similar name and whoever isn’t paying quite close enough attention. It’s not practical for every user to check every package in their operating system. How, then, do we have any trust in any install? Cryptography solves some of these problems, but it cannot overcome the human element. A typo in a url, trusting a brand new project, or even obfuscated C code can fool the best of us from time to time.

What’s the solution? How do we have any confidence in any of our software? When downloading from the web, there are some good habits that go a long way to protect against attacks. Cross check that the project’s website and source code actually point to each other. Check for typos in URLs. Don’t trust a download just because it’s located on a popular repository.

But most importantly, check the project’s reputation, the number of contributors to the project, and maybe even their reputation. You wouldn’t order something on eBay without checking the seller’s feedback, would you? Do the same for software libraries.

A further layer of security can be found in using libraries supported by popular distributions. In quality distributions, each package has a maintainer that is familiar with the project being maintained. While they aren’t checking each line of code of every project, they are ensuring that “colorama” gets packaged instead of “colourama”. In contrast to PyPi’s 156,750 Python modules, Fedora packages only around 4,000. This selection is a good thing.

Repositories like PyPi and NPM are simply not the carefully curated sources of trustworthy software that we sometimes think them to be– and we should act accordingly. Look carefully into the project’s reputation. If the library is packaged by your distribution of choice, you can probably pass this job off to the distribution’s maintainers.

At the end of the day, short of going through the code line by line, some trust anchor is necessary. If you’re blindly installing random libraries, even from a “trustworthy” repository, you’re letting your guard down.

LibSSH Vuln: You Don’t Need To See My Authentication

Another day, another CVE (Common Vulnerabilities and Exposures). Getting a CVE number assigned to a vulnerability is a stamp of authenticity that you have a real problem on your hands. CVE-2018-10933 is a worst case scenario for libssh.  With a single response, an attacker can completely bypass authentication, giving full access to a system.

Before you panic and yank the power cord on your server, know that libssh is not part of OpenSSH. Your Linux box almost certainly uses OpenSSH as the SSH daemon, and that daemon is not vulnerable to this particular problem. Libssh does show up in a few important places, the most notable is probably Github and their security team already announced their implementation was not vulnerable.

Libssh has released a new version that fixes the problem. Stick around for the details after the break.

Continue reading “LibSSH Vuln: You Don’t Need To See My Authentication”