Watch A Web Page Fetch Itself Over TLS, Complete With Commentary

May 21, 2023 by Donald Papp 12 Comments

TLS, byte by byte performs an unusual and interesting function: it fetches itself over HTTPS, and provides a complete annotation of what’s going on in the process, one byte at a time. Visit the site and give the button a click to watch it happen, it’s neat!

Transport Layer Security (TLS) is what’s responsible for encrypting traffic over the internet, and it’s normally implemented on top of TCP to encrypt an application-layer protocol like HTTP (resulting in HTTPS and the little padlock icon in browsers indicating a connection with a web site is encrypted.) Back in the day, traffic over the internet was commonly unencrypted, but nowadays no communication or hardware is too humble for encryption and methods are easily accessible.

So for what purpose would someone actually need or use such an implementation of TLS? Well, probably no one actually needs it. But it is a userspace TLS implementation in javascript that may fit a niche for someone, and it certainly provides beautifully-indented and annotated binary data in the process. Sound up your alley? The GitHub repository for the project has all the details, so give it a look.

This Week In Security: VMWare, Microsoft Teams, Python Fuzzing, And More

December 11, 2020 by Jonathan Bennett 9 Comments

There’s a VMWare problem that’s being exploited in the wild, according to the NSA (PDF). The vulnerability is a command injection on an administrative console. The web host backing this console is apparently running as root, as the vulnerability allows executing “commands with unrestricted privileges on the underlying operating system.”

The wrinkle that makes this interesting is that VMWare learned about this vuln from the NSA, which seems to indicate that it was a zero-day being used by a foreign state. The compromise chain they list is also oddly specific, making me suspect that it is a sanitized account of observed attacks.

Microsoft Teams, And the Non-CVE

[Oskars Vegeris] found a pair of interesting problems in the Microsoft Teams client, which together allows an interactionless, wormable RCE. The first vuln is an XSS problem, where a message containing a “mention” can be modified in transit to include arbitrary Javascript. To get that JS past the XSS protection filter, a unicode NULL byte is included in the payload. The second vuln is using the built-in file download code in the Teams app to download and auto-run a binary. Put together, anyone who simply loads the message in their Teams app runs the code.

Vegeris points out that since so many users have a presence in multiple rooms, it would be trivial to use this exploit to build a worm that could infect the majority of Teams users worldwide. The bug was reported privately to Microsoft and fixed back in October. A wormable RCE in a widely used tool seems like a big deal, and should net a high CVE score, right? Microsoft gave two ratings for this attack chain, for the two versions of Teams that it can affect. For the Office365 client, it’s “Important, Spoofing”, which is about as unimportant as a bug can be. The desktop app, at least, was rated “critical” for an RCE. The reason for that seems to be that the sandbox escape only works on the standalone desktop app.

But no CVE was issued for the exploit chain. In the security community, collecting CVEs is an important proof of work for your resume. Microsoft replied that they don’t issue CVEs for products that get updated automatically without user interaction. Kerfuffle ensued. Continue reading “This Week In Security: VMWare, Microsoft Teams, Python Fuzzing, And More” →

Let’s Encrypt Will Stop Working For Older Android Devices

December 1, 2020 by Lewin Day 20 Comments

Let’s Encrypt was founded in 2012, going public in 2014, with the aim to improve security on the web. The goal was to be achieved by providing free, automated access to SSL and TLS certificates that would allow websites to make the switch over to HTTPS without having to spend any money.

Hundreds of millions of sites rely on Let’s Encrypt for their HTTPS certificate needs. HTTPS security helps protect sites and users, and makes it harder for malicious actors to steal private information.

The project has just announced that, come September 1, 2021, some older software will stop trusting their certificates. Let’s look at why this has come to pass, and what it means going forward.

Certificates Expire

When Let’s Encrypt first went public in early 2016, they issued their own root certificate, by the name ISRG Root X1. However, it takes time for companies to include updated root certificates in their software, so until recently, all Let’s Encrypt certificates were cross-signed by an IdenTrust certificate, DST Root X3. This certificate had been around much longer, and was already supported by the vast majority of OSes and browsers in regular use. This allowed Let’s Encrypt to hit the ground running while they waited for the majority of software to support their own root certificate. Continue reading “Let’s Encrypt Will Stop Working For Older Android Devices” →

Troubleshooting A Symlink — A Whodunnit For The Git Record Books

February 6, 2020 by Jonathan Bennett 14 Comments

While I normally sport the well-worn fedora of a hard-boiled sysadmin, Sunday mornings I swap that neo-noir accessory for the tech-noir: a pair of pro headphones. This is the tale of the collision of those two roles. An educational caper, dear reader. You see, my weekly gig is to run a Facebook Live Stream, and Facebook just recently began enforcing a new policy: all video streams are required to use encryption. We have Fedora installed on the media machine, and use Open Broadcaster Software (OBS) to stream. It should have been easy to update the stream settings. I made the necessary changes and tested it out — no luck. The error message was less than helpful: “Failed to connect to server”. With a sigh, I took off my headphones, put my sysadmin hat on, and walked out into the digital darkness. It was time to get back to work.

Continue reading “Troubleshooting A Symlink — A Whodunnit For The Git Record Books” →

DNS-over-HTTPS Is The Wrong Partial Solution

October 21, 2019 by Maya Posch 51 Comments

Openness has been one of the defining characteristics of the Internet for as long as it has existed, with much of the traffic today still passed without any form of encryption. Most requests for HTML pages and associated content are in plain text, and the responses are returned in the same way, even though HTTPS has been around since 1994.

But sometimes there’s a need for security and/or privacy. While the encryption of internet traffic has become more widespread for online banking, shopping, the privacy-preserving aspect of many internet protocols hasn’t kept pace. In particular, when you look up a website’s IP address by hostname, the DNS request is almost always transmitted in plain text, allowing all the computers and ISPs along the way to determine what website you were browsing, even if you use HTTPS once the connection is made.

The idea of also encrypting DNS requests isn’t exactly new, with the first attempts starting in the early 2000s, in the form of DNSCrypt, DNS over TLS (DoT), and others. Mozilla, Google, and a few other large internet companies are pushing a new method to encrypt DNS requests: DNS over HTTPS (DoH).

DoH not only encrypts the DNS request, but it also serves it to a “normal” web server rather than a DNS server, making the DNS request traffic essentially indistinguishable from normal HTTPS. This is a double-edged sword. While it protects the DNS request itself, just as DNSCrypt or DoT do, it also makes it impossible for the folks in charge of security at large firms to monitor DNS spoofing and it moves the responsibility for a critical networking function from the operating system into an application. It also doesn’t do anything to hide the IP address of the website that you just looked up — you still go to visit it, after all.

And in comparison to DoT, DoH centralizes information about your browsing in a few companies: at the moment Cloudflare, who says they will throw your data away within 24 hours, and Google, who seems intent on retaining and monetizing every detail about everything you’ve ever thought about doing.

DNS and privacy are important topics, so we’re going to dig into the details here. Continue reading “DNS-over-HTTPS Is The Wrong Partial Solution” →

A New Way To Remote Terminal

August 9, 2019 by Bryan Cockfield 14 Comments

Thanks to the wonders of the internet, collaborating with others across great distances has become pretty simple. It’s easy now to share computer desktops over a network connection, and even take control of another person’s computer if the need arises. But these graphical tools are often overkill, especially if all we really need is to share a terminal session with someone else over a network.

A new project from [Elis] allows just that: to share an active terminal session over a web browser for anyone else to view. The browser accesses a “secret” URL which grants access to the terminal via a tunnel which is able to live stream the entire session. The server end takes care of all of the work of generating this URL, and it is encrypted with TLS and HTTPS. It also allows for remote control as well as viewing, so it is exceptionally well-featured for being simple and easy to run.

To run this software only a binary is needed, but [Elis] has also made the source code available. Currently he finds it a much more convenient way of administering his Raspberry Pi, but we can see a lot of use for this beyond the occasional headless server. Certainly this makes remote administration easy, but could be used collaboratively among a large group of people as well.

Transcending The Stack With The Right Network Protocol

April 9, 2019 by Maya Posch 14 Comments

The increase in network-connected devices the past years has been something of a dual-edged sword. While on one hand it’s really nice to have an easy and straight-forward method to have devices talk with each other, this also comes with a whole host of complications, mostly related to reliability and security.

With WiFi, integrating new devices into the network is much trickier than with Ethernet or CAN, and security (e.g. WPA and TLS) isn’t optional any more, because physical access to the network fabric can no longer be restricted. Add to this reliability issues due to interference from nearby competing WiFi networks and other sources of electromagnetic noise, and things get fairly complicated already before considering which top-layer communication protocol one should use. Continue reading “Transcending The Stack With The Right Network Protocol” →