BlogOne of my favorite Reveal(x) detections is Credentials Sent over HTTP, as a strong password is useless if the username and password are sent across the network in the clear.
Why would a hacker bother cracking passwords if they can simply sniff them out?
One technique to check for exposure is to look for basic authentication. That's how we discovered a vulnerable privileged communication channel at a recent on-site training.
Quick sidebar: Basic authentication has been around since the early days of HTTP, back when plaintext—not encryption—was used to send HTTP requests and responses. HTTPS (the "S" stands for secure) prevents bad actors from intercepting and reading your data by using SSL/TLS encryption.
Moving on. When you encounter basic authentication you'll see a dialog for your username and password:
It's the browser, not a web page, prompting you for credentials. When the credentials are transmitted, they' are sent using the following HTTP header:
Authentication: Basic blahblah
The string blahblah is a base64 encoded blob that typically follows the form:
username:password
Note that base64 is encoding, not encrypting. Base64 is a simple way of representing binary data using printable ASCII characters.
If my username is bob and my password is s3kr3t! the username:password string would look like bob:s3kr3t!, which encodes to Ym9iOnMza3IzdCE=. So, my header would be:
Authentication: Basic Ym9iOnMza3IzdCE=
(Pro tip: The trailing "=" is a dead giveaway of base64 encoding.)
Basic Auth and an Eye-Catching Detection
ExtraHop observed the use of basic authentication and raised a detection. Clicking into the detection and reading its description told us all we needed to know in just the first sentence: Over the past day, servers received HTTP data with passwords or basic authentication headers.
Uh oh.
The phrase that pays is:
basic authentication headers.We scrolled down a bit in the detection and saw the transaction records associated with the transactions. From the records, we clicked the bullseye which took us directly to the packets.
(Another pro tip: Starting with all the packets and filtering is weak sauce. What's more useful is clicking the bullseye link to jump directly into the basic authentication packets. This time-saver is killer.)
The blue bullseye allows Reveal(x) users to jump directly to the PCAP associated with the specific traffic flow.
By looking at the basic authentication packets, we saw this in the HTTP headers:
Authentication: Basic Og==
A simple base64 decode of the string 0g== revealed that the string decoded to :—a single colon.
If the username and password are separated by a colon, and all that's sent is the colon, the logical conclusion is that no username or password is supplied because none are required.
The security analyst, optimistically hoping for the best, asked, "Wait, this fails? Right?"
With an "oof," I shared the bad news: The transaction returns an HTTP 200 (OK), which means the authentication was successful.
This investigation found that the assets permitting passwordless connections were the voice infrastructure. This means that potentially sensitive communications between all related arms of the organization were vulnerable.
Reduce the risk of attack
While not inherently insecure, HTTP can be deeply problematic if it's used to transmit sensitive data and credentials. Sending plaintext credentials over HTTP exposes users and their organizations to serious risks.
Unfortunately, basic authentication is still widely used in enterprise environments for sharing sensitive data.
That said, there are several actionable steps you can take to secure your organization, including conducting a manual audit and establishing a continuous network monitoring program. For more information about the risks associated with HTTP and other insecure protocols, check out our whitepaper.
