Lead Image © Galyna Andrushko, 123RF

Credential harvesting at the network interstice

Where the Wild Things Are

Article from ADMIN 53/2019

By James Stanger

To thwart credential harvesters at the network interstice, you must understand how attackers exploit browser transactions.

Brute forcing the web browser and the conversations it has with Internet-based resources now seems to be the primary hacking method. Although many people still use their Microsoft Outlook clients, the web browser is where most users store their credentials to check email, log on to cloud services, use social media, and generally do what they do every day. This means the browser and its subsequent transactions are the main target of credential harvesters worldwide.

Credential harvesting is the practice of obtaining usernames and passwords illicitly and then either selling them to the highest bidder (often on the dark web) or handing them over to an attacker – a relatively new practice. (See the "Have I Been Harvested?" box.) Traditionally, hackers were interested in compromising systems either smash-and-grab style or as "full-stack" attackers trying to control systems through long-term advanced persistent threat (APT) techniques. These methods are really no longer the most popular. Many attackers simply focus on obtaining credential information, which can include usernames, passwords, and associated metadata, such as email addresses, connection data, and the equipment potential victims use every day.

Have I Been Harvested?

You can discover whether you've been harvested already by going to the Have I Been Pwned website [1] and conducting a simple search. This website is, in many ways, a Google-like service for anyone who is curious about whether their user credentials have been stolen. The site's operator has specialized crawlers, bots, and engines that obtain information about millions of hacked users and then place that information into a searchable database. You can search for websites and, for example, social media platforms that have been hacked recently by credential harvesters. You can even enter your email address to determine if any of your online identities have been compromised.

Okta has provided a useful Chrome app called PassProtect [2] that uses information from the Have I Been Pwned database to provide real-time checks to see if you're using a compromised password.

Harvester Targets

Credential harvesters usually attack wherever the action is. I tend to describe the current credential harvesting landscape by stealing the title from Maurice Sendak's children's story Where the Wild Things Are ; in this case, they're most likely user credentials, including, in order (according to me):

Web browsers for stored credentials and session information stolen through cross-site scripting (XSS) attacks and social engineering, because the web browser remains the primary way to access online identities.
Internet-based databases and web servers for email and social media accounts and logins to cloud services, such as Amazon Web Services (AWS), Google Cloud, and Alibaba.
Operating systems (e.g., Linux, Windows, and related IoT systems) for information in the network "interstice," which is where one technology connects to and works with another technology.

Hackers take advantage of interstices. If you've ever read your email, you've participated in an interstice: Your brain is one technology; the email client is another, and email is the primary means of conducting social engineering attacks.

How Browsers Communicate with Servers

Hackers naturally target the most credential-rich resource, which remains the web browser. With this tool, you usually access your email, social media, and especially cloud services. Each time you administer AWS, Google Cloud, or Alibaba Cloud, you're creating another interstice, where browser-based technologies meet cloud services. Credential harvesters are especially interested in hacking the client side of this browser and cloud equation, because they can use social engineering tactics, in addition to exploiting the browser itself.

Browsers are also pretty chatty and open. Even during an encrypted session, a browser will communicate sensitive information, which sometimes is encrypted. However, sometimes metadata, which includes the first parts of a negotiated Transport Layer Security (TLS) or Secure Sockets Layer (SSL) session, are not encrypted, which means an attacker could identify the particular language a web script might be using (e.g., PHP, Python), as well as where the web server's scripts are stored.

Remember that any web browser, whether it is found on a mobile device or a PC, isn't really a monolithic structure. It's a collection of individual applications and elements (Figure 1). Each time these elements communicate with each other, with the host operating system, or with remote systems in particular, they create an interstice. The primary interstices that credential harvesters attack include the interpreter, the network stack, and the caching and storage features. They also attack persistence mechanisms, which include cookies and add-on applications.

Figure 1: Browser elements.

When exploiting the browser, attackers generally focus on the interstice created between user mode and kernel mode. User mode is where you spend most of your time: the non-administrative/non-root user space that does the job of creating HTTP connections and network sockets. Figure 2 shows how the modes are generally separated; however, when an attacker discovers a flaw, the distinction between user mode and kernel mode is erased, creating a condition in which credential harvesters can thrive.

Figure 2: User and kernel mode separation in the browser.

Flaws occur in two ways: first, through the browser code itself. Chances are, you've received dire warnings to update your browser because of flaws in the internal code that can lead to either a buffer overflow condition or a failure in a sandbox component. The second issue is far more insidious, because it is where a browser does its job properly but processes code that defeats all security measures, including firewalls, proxy servers, and antivirus.

When this separation collapses, either through a buffer overflow or through a manipulated user, credential harvesters thrive. When a user is tricked into going to a site that contains XXS code, few browser-related controls can help. (See the "XSS Attack Types" box.) The best way to apply controls is to improve logging on the web server, use two-factor authentication (2FA), and use privileged access management (PAM) software.

XSS Attack Types

Although a few system administrators know the abstract concept of an XSS attack, they really don't understand the specifics. Three types of attacks exist:

Persistent: The attacker's malicious input originates from the web server's database. This is the most common type of attack, because once bad code gets put on a website, the attacker exploits it as long as possible. A "watering hole" attack often exploits persistent XSS vulnerabilities, because all an attacker has to do is get multiple people to go to the compromised website. In this article, I profile a persistent XSS attack.
Reflected: Malicious input originates from the victim's request, which means the victim has either unwittingly created a condition for an XSS attack on their own, or they have been manipulated by an attacker.
Document object model (DOM) based: The vulnerability is in the client-side code read by the browser.

Anatomy of a Web Session

Figure 3 provides a quick overview of a typical web session. To conduct a brute force attack, all you need to learn is the exact sequence and syntax used by a particular application. Once you have determined how a web server formats steps 2 and 3, you can imitate this section. Many times, this information can be gathered by a simple packet sniffer such as Wireshark or more sophisticated tools such as Burp Suite [3]. Figures 4 and 5 show how these tools can capture entire web sessions.

Figure 3: Anatomy of a web session.

Figure 4: Viewing HTTP session information in Wireshark.

Figure 5: Viewing HTTP session information in Burp Suite.

In each of the sessions, notice how the following metadata has been exposed:

Communication method: HTTP sessions communicate in either GET or POST methods. In this case, the GET method is used.
Script: In this case, the script is /login.php.
Current ID of the HTTP session: Here, a PHP session is being viewed, which is important because, in some cases, the PHP developer might make the mistake of storing password information inside the cookie. If that's the case, the credential harvester has now reached the goal of obtaining a password.

Now, the credential harvester can take the next step.

1 2 Next »