Root in 70 Seconds | TechSNAP 293

RSS Feeds:

HD Video Feed | Mobile Video Feed | MP3 Audio Feed | Ogg Audio Feed | iTunes Feed | Torrent Feed

Become a supporter on Patreon:

Show Notes:

CryptoSet bug: Get a root shell by holding down enter

• “A vulnerability in Cryptsetup, concretely in the scripts that unlock the system partition when the partition is ciphered using LUKS (Linux Unified Key Setup). The disclosure of this vulnerability was presented as part of our talk “Abusing LUKS to Hack the System” in the DeepSec 2016 security conference, Vienna.”
• “This vulnerability allows to obtain a root initramfs shell on affected systems. The vulnerability is very reliable because it doesn’t depend on specific systems or configurations. Attackers can copy, modify or destroy the hard disc as well as set up the network to exflitrate data. This vulnerability is especially serious in environments like libraries, ATMs, airport machines, labs, etc, where the whole boot process is protect (password in BIOS and GRUB) and we only have a keyboard or/and a mouse.”
• Note that in cloud environments it is also possible to remotely exploit this vulnerability without having “physical access.”
• Suddenly that Digital Ocean HTML5 console makes you want to setup 2 Factor Authentication.
• “If you use Debian or Ubuntu/ (probably many derived distributions are also vulnerable, but we have not tested), and you have encrypted the system partition, then your systems is vulnerable.”
• “Update: We have found that systems that use Dracut instead of initramfs are also vulnerables (tested on Fedora 24 x86_64).”
• “During the installation of Ubuntu, one of the first steps is to prepare the target partition (make partitions if needed, and/or format them). At this stage, the user is asked to “Encrypt the new (LXK)ubuntu installation for security”. Nowadays, there is very little performance penalty working with an encrypted disk and it is an effective solution to protect data when the computer is not running. It is advisable to enable this feature.”
• “An attacker with access to the console of the computer and with the ability to reboot the computer can launch a shell (with root permissions) when he/she is prompted for the password to unlock the system partition. The shell is executed in the initrd environment. Obviously, the system partition is encrypted and it is not possible to decrypt it (AFAWK). But other partitions may be not encrypted, and so accessible. Just to mention some exploitation strategies:”
  • Elevation of privilege: Since the boot partition is typically not encrypted:
    • It can be used to store an executable file with the bit SetUID enabled. Which can later be used to escalate privileges by a local user.
    • If the boot is not secured, then it would be possible to replace the kernel and the initrd image.
  • Information disclosure: It is possible to access all the disks. Although the system partition is encrypted it can be copied to an external device, where it can be later be brute forced. Obviously, it is possible to access to non-encrypted information in other devices.
• Denial of service: The attacker can delete the information on all the disks.
• “The fault is caused by an incorrect handling of the password check in the script file /scripts/local-top/cryptroot. When the user exceeds the maximum number of password tries (by default 3), then boot sequence continues normally.”
• “The calling script, /scripts/local, handles the error as if it were caused by a slow device that needs more time to warm-up. The booting scripts then tries to recover/mount the “failing” device, in the function local_deveice_setup(), multiple times (up to 30 times on an x86 system, and 150 on a powerpc machine). Every time the top level script tries to mount the encrypted partition (line 99 in /script/local), the user is allowed to try 3 more LUKS passwords. This gives a total of 93 password trials (on x86).”
• “But the real problem happens when the maximum number of trials for transient hardware faults is reached (30 times for non ppc systems), line 114 at function local_device_setup(). In this case, the top level script is not aware of the root cause of the fault and drops a shell (busybox) to the user, line 124. The panic() function (see below) tries to insert additional drivers and runs a shell.”
• The Exploit: “The attacker just have to press and keep pressing the [Enter] key at the LUKS password prompt until a shell appears, which occurs after 70 seconds approx.”
• “In general, the GNU/Linux ecosystem (kernel, system apps, distros, …) has been designed by developers for developers. Therefore, in the case of a fault, the recovery action is very “developer friendly”, which is very convenient while developing or in controlled environments. But then Linux is used in more hostile environments, this helpful (but naive) recovery services shall not be the default option.”
• “UEFI and GRUB contain two complete and very powerful shell facilities. Initrd system has powerful busybox with complete access to the network.”
• “May be all this “just in case” functionality shall be removed, or seriously reconsidered, for the sake of security.”
• Additional Coverage: TheHackerNews

---

Comprising a Linux desktop using… 6502 processor opcodes on the NES?!

• “A vulnerability and a separate logic error exist in the gstreamer 0.10.x player for NSF music files. Combined, they allow for very reliable exploitation and the bypass of 64-bit ASLR, DEP, etc. The reliability is provided by the presence of a turing complete “scripting” inside a music player. NSF files are music files from the Nintendo Entertainment System.”
• “Here is a screenshot of the exploit triggering. Somewhat alarmingly, it does so without the user opening the exploit file — they only have to navigate to the folder containing the file.”
• Just the preview of the file, generated by your file manager, is enough to exploit your system, and in this case, pop calculator.
• “You can download the file: exploit_ubuntu_12.04.5_xcalc.nsf. In the image above, the file has been renamed to “time_bomb.mp3”. As the filename suggests, this exploit works against Ubuntu 12.04.5. This is an old but still supported distribution. Specifically, for reproducibility, it works against exactly Ubuntu 12.04.5, without further updates. If you take all the updates, you’ll get a new glibc, which changes some code offsets and the exploit will crash. The crash is of course deterministic and it would be possible to code the exploit to cater for arbitrary glibc binaries; this is left as an exercise for the reader.”
• “The vulnerability is in libgstnsf.so, an audio decoder present in the gstreamer-0.10 distribution. Ubuntu 12.04 uses gstreamer-0.10 for all its audio handling needs. Ubuntu 14.04 is apparently affected because the default install includes gstreamer-0.10, but most media handling applications use gstreamer-1.0 which is also installed. The exact circumstances under which Ubuntu 14.04 uses the vulnerable gstreamer-0.10 are not clear. The Ubuntu 16.04 default install has only gstreamer-1.0, which is not affected by this vulnerability.”
• “Here’s the patch for Ubuntu 12.04: sudo rm /usr/lib/x86_64-linux-gnu/gstreamer-0.10/libgstnsf.so”
• “While at first glance, this “patch” would appear to remove functionality, it does not. Your wonderful NSF files will still play. WTF? Would you believe that Ubuntu 12 and 14 ship not one but two different code bases for playing NSF files? That’s a lot of code for a very fringe format. The second NSF player is based on libgme and does not appear to have the vulnerabilities of the first.”
• “This exploit abuses a vulnerability in the gstreamer-0.10 plug-in for playing NSF music files. These music files are not like most other music files that your desktop can play. Typical music files are based on compressed samples and are decoded with a bunch of math. NSF music files, on the other hands, are played by actually emulating the NES CPU and sound hardware in real time. Is that cool or what? The gstreamer plug-in creates a virtual 6502 CPU hardware environment and then plays the music by running a bit of 6502 code for a little while and then looking at the resulting values in the virtualized sound hardware registers and then rendering some sound samples based on that.”
• “In order to actually exploit this vulnerability, or a vulnerability like it, there are various plausible and different avenues:”
  • Send exploit via e-mail attachment. If the victim downloads and opens the file, they are compromised. Note — for this to work, you likely need to rename exploit.nsf to exploit.mp3. Most Linux desktops don’t know what to do with an NSF file, but they’ll happily stuff any sequence of bytes in an MP3 file through a media player. Most gstreamer based media players will ignore a file’s suffix and use file format auto detection to load the file with the most appropriate decoder.
  • Partial drive-by download. By abusing Google Chrome’s somewhat risky file download UX, it’s possible to dump files to the victim’s Downloads folder when a booby trapped web page is visited. When the Downloads folder is later viewed in a file manager such as nautilus, an attempt is made to auto thumbnail files with known suffixes (so again, call the NSF exploit something.mp3). The exploit works against the thumbnailer.
  • Full drive-by download. Again, abusing Google Chrome download UX, there’s a path to a possible full drive-by download. This will be explored in a separate blog post.
  • USB drive based attack. Again, opening a USB drive opens up the thumbnailing attack described above.
• The Vulnerabilties:
• “1: Lack of checking ROM size when mapping into 6502 memory and bank switching (Absent a CVE, you can uniquely identify this as CESA-2016-0001.) There is a near total lack of bounds checking on proposed ROM mappings. This applies to be the initial ROM load, as well as subsequent ROM bank switching.”
• “2: Ability to load or bank switch ROM to writable memory locations (Probably not an actual vulnerability per se; no identified assigned.) Other NES music players I’ve looked at do not permit the loading or bank switching of ROM data at addresses below 0x8000. But this particular player does, either via a ROM load address in the file header that is below 0x8000, or via writes to the bank registers 0x5ff6 or 0x5ff7 (other emulators do not even have bank registers as low as 0x5ff6 or 0x5ff7)”
• “Writing e.g. 0x00 to 0x5ff6 will result in the first 4096 bytes of ROM being mapped read and write at 6502 virtual address 0x6000. In our 200 byte file example, this means that a subsequent write of 0x41 to virutal address 0x6048 will result in 0x41 being written out of bounds relative to the host emulator heap. As can be appreciated, we now have a lot of read and write control over the host emulator heap and the more experienced exploit writers will realize that successful exploitation is already all but assured.”
• The article them walks through each step of the exploit to actually pop calculator
• “There’s a critical reason that decent, reliable exploitation was possible with this bug: the presence of some form of “scripting” language. In this case, that script happens to be 6502 opcodes. Having an exploit running in script enables important exploitation aspects, such as making decisions based on exploitation environment, and in particular, using code to observe the effects of a corruption (such as a memory leak) and make sensible follow-up decisions.”
• “One of the reasons that browsers and browser plug-ins (Flash, Java) are popular exploitation targets is precisely because they are fundamentally scripting environments.”
• “Another great example of this phenomena is Windows font parsing and rendering. This has traditionally occurred in the kernel(!!) and rending modern fonts involves…. yes, running a little language to make rendering decisions. Well, many times, attackers have used that same language to cause Windows kernel corruptions and proceed to full ring 0 compromise by using a script-inside-font to make decisions about reliably proceeding with the exploit.”
• Maybe our file browsers should not be tasting these untrusted files and exposing us to these vulnerabilities

---

PoisonTap

• An updated version of an exploit we covered previously
• Plugging a PoisonTap device into most computers allows the attacker to: siphons cookies, exposes internal router & installs web backdoor on locked computers
• “When PoisonTap (Raspberry Pi Zero & Node.js) is plugged into a locked/password protected computer, it”:
  • emulates an Ethernet device over USB (or Thunderbolt)
  • hijacks all Internet traffic from the machine (despite being a low priority/unknown network interface)
  • siphons and stores HTTP cookies and sessions from the web browser for the Alexa top 1,000,000 websites
  • exposes the internal router to the attacker, making it accessible remotely via outbound WebSocket and DNS rebinding (thanks Matt Austin for rebinding idea!)
  • installs a persistent web-based backdoor in HTTP cache for hundreds of thousands of domains and common Javascript CDN URLs, all with access to the user’s cookies via cache poisoning
  • allows attacker to remotely force the user to make HTTP requests and proxy back responses (GET & POSTs) with the user’s cookies on any backdoored domain
  • does not require the machine to be unlocked
  • backdoors and remote access persist even after device is removed and attacker sashays away
• “PoisonTap is built for the $5 Raspberry Pi Zero without any additional components other than a micro-USB cable & microSD card, but can work on other devices that can emulate USB gadgets such as USB Armory and LAN Turtle.”
• “PoisonTap produces a cascading effect by exploiting the existing trust in various mechanisms of a machine and network, including USB/Thunderbolt, DHCP, DNS, and HTTP, to produce a snowball effect of information exfiltration, network access and installation of semi-permanent backdoors.”
• How the Web-Based backdoor works:
• “While PoisonTap was producing thousands of iframes, forcing the browser to load each one, these iframes are not just blank pages at all, but rather HTML+Javascript backdoors that are cached indefinitely”
• “Because PoisonTap force-caches these backdoors on each domain, the backdoor is tied to that domain, enabling the attacker to use the domain’s cookies and launch same-origin requests in the future, even if the user is currently not logged in”
• “For example, when the https://nfl.com/PoisonTap iframe is loaded, PoisonTap accepts the diverted Internet traffic, responds to the HTTP request via the Node web server”
• “Additional HTTP headers are added to cache the page indefinitely”
• “The actual response of the page is a combination of HTML and Javascript that produces a persistent WebSocket out to the attacker’s web server (over the Internet, not on the PoisonTap device)”
• “The WebSocket remains open allowing the attacker to, at any point in the future, connect back to the backdoored machine and perform requests across any origin that has the backdoor implemented (the Alexa top 1,000,000 sites – see below)”
• “If the backdoor is opened on one site (e.g., nfl.com), but the user wishes to attack a different domain (e.g., pinterest.com), the attacker can load an iframe on nfl.com to the pinterest.com backdoor (https://pinterest.com/PoisonTap)”
• “Again, any “X-Frame-Options”, Cross-Origin Resource Sharing, and Same-Origin Policy security on the domain is entirely bypassed as the request will hit the cache that PoisonTap left rather than the true domain”
• Securing Against PoisonTap:
• “Server-Side Security: If you are running a web server, securing against PoisonTap is simple:”
  • Use HTTPS exclusively, at the very least for authentication and authenticated content
• Ensure Secure flag is enabled on cookies, preventing HTTPS cookies from leaking over HTTP
  • When loading remote Javascript resources, use the Subresource Integrity script tag attribute
  • Use HSTS to prevent HTTPS downgrade attacks
• Desktop Security:
  • Adding cement to your USB and Thunderbolt ports can be effective
  • Closing your browser every time you walk away from your machine can work, but is entirely impractical
  • Disabling USB/Thunderbolt ports is also effective, though also impractical
  • Locking your computer has no effect as the network and USB stacks operate while the machine is locked, however, going into an encrypted sleep mode where a key is required to decrypt memory (e.g., FileVault2 + deep sleep) solves most of the issues as your browser will no longer make requests, even if woken up

---

Feedback:

• Media server

• Alerts on local network

• Zed-FS Datasets

• Converting to mirrored VDEVs

• ZFS and hard drive disposal

---

Round Up:

• iPhone sends call logs to Apple servers even when iCloud backup switched off
• Without internet security, free speech won’t matter
• IBM Opens Attack Simulation Test Center
• Demystifying the Apple NVMe NAND
• Investigatory Powers Bill: what is it and how will it affect you?
• Tesco Bank blames ‘systematic sophisticated attack’ for losses accross 20,000 accounts
• Introducing Firefox Focus – a free, fast and easy to use private browser for iOS
• Office Depot Allegedly Diagnosing Computers With Nonexistent Viruses To Meet Sales Goals
• Spray-on conductive concrete will shield us from EMP attacks
• How the FBI could review 650,000 emails in just 8 days (I could have done it in 1)
• Budget Android phones are secretly sending users’ text messages to China
• Schneier: We Need a New Agency For IoT Security
• Qualcomm jumps on the bug bounty bandwagon with $15,000 for bashing blips
• If you are a KDE neon user, reinstall

---