In this internet era, we consume Giga Bytes (GBs) of data everyday, which includes surfing the internet, streaming videos, online games, or using social media such as Facebook, Instagram, LinkedIn etc. Some of the websites provide access based on user authentication, such as a login page, to restrict public access and monitor user activity and bandwidth. To access websites requiring user authentication, a user needs to create an account with username and password. After entering the credentials, the backend web server authenticates the user login and provides the access to the user which is nothing but HTTP authentication, often abused by threat actors for their malicious activity. HTTPS authentication is the recommended method and it is being used widely now-a-days but still we are witnessing HTTP authentication which is not recommended.

In this blog, we will see both valid & invalid HTTP authentications and focus on how HTTP authentication is abused by threat actors for their malicious intent, by using a technique called Fake URL authentication.

HTTP authentication

HTTP provides a general framework for access control and authentication. HTTP authentication is a standard way to pass the user’s credentials to the web server and access the restricted content of the website.

Some of the common schemes that are used in HTTP authentications are,

• Basic
• Bearer
• Digest

Websites use different methods such as, login page, sign up forms, or API key / Access tokens etc., to allow users to send credentials. 

Figure 1 represents the basic authentication with encoded credentials exchanged between the server and the client(s). Process follows:

1. Client is sending the request to the server without any authorization strings, in return server sends the login form to the user, as depicted in Figure 2.
2. Users send the credentials through the login forms and in the backend it will be validated and authenticated. If it’s HTTPS communication, credentials would be encrypted.
3. Upon successful validation user gets 200 as response code and get an access to restricted content (aka valid request) otherwise they receive 403 with Forbidden message if they don’t have access to the page or gets validation error (aka invalid request).

Web servers allow credentials to be sent along with the URL to suppress the authentication prompt. Though it is an old strategy to ease the authentication process, we are still seeing such cases, for example, let say http://yourmail.com/secured is the indent web page to visit, we can pass the credential informations(Username & Password) to the URL as  “http://username:password@yourmail.com/secured” and server would accept it and render the webpage after checking the credentials and permissions as shown in Figure 3.

Credentials sent as part of the URL are encoded with base64 which is the value of the “Authorization” field in the HTTP Get request as depicted in Figure 4. 

Legitimate server also handles the invalid request and responds with a proper message to the user as shown in Figure 5. 

The technique of passing credentials along with the HTTP URL is being misused by threat actors by Fake URL Authentication method. We will see what Fake URL authentication is in the following section.

Fake URL Authentication

In certain situations, users are made to believe as part of social engineering, that by passing the credentials as part of the URL authentication, the website might be legitimate with proper credential check at the server end. However, there is no check on credentials at the server end irrespective of the type of request from the user, resulting in the same response for any type of authentication request. This is exploited by threat actors  for delivering the malware to the victim’s machine or for stealing credentials which leads to loss of data (PII), money and/or impersonation. Such type of authentication is tagged as Fake URL authentication.

Figure 6 explains the difference between legitimate and Fake URL authentication. Authorization string will be sent along with the GET request in case of legitimate whereas no authorization string for Fake URL authentication.

Case Study: Malware delivery by Fake URL Authentication

Smart devices aka Internet of Things (IoT) with network connectivity are ubiquitous. However, smart devices without/limited security features increase the cyber-attack vector.

In this case study, we look at how an IoT malware is delivered using Fake URL authentication technique. The mentioned URL contains user credentials as part of the URL which typically must be validated at the server side. However, once a victim clicks on any of the below URLs, server response remains the same as shown in Figure 7, 8 and 9 i.e. without checking the user credentials and to prompt the download of an IoT malware (Hajime)

1. With username and password : hxxp://support:password@173[.]56[.]92[.]166:42238/Mozi[.]a
2. Without password : hxxp://support@173[.]56[.]92[.]166:42238/Mozi[.]a
3. Without username and password : hxxp://173[.]56[.]92[.]166:42238/Mozi[.]a

A downloaded malware from above said links will scan your IoT devices for weak/default usernames and passwords (credential brute-force). Once they gain access, more malware files are downloaded and executed that make the device part of the zombie network and eventually help them to do Distributed Denial-of-Service (DDoS) attack.

Now-a-days browsers come with basic security checks to protect their users. Some browsers alert the user with a warning message as depicted in Figure 10.

Whereas a few other browsers strip out “user:password@” from the URL to avoid the Man-In-The-Middle (MITM) attack and allow you to download the content from the website.

We at K7 computing have detection for all such URLs, as shown in Figure 11. As we always recommend, use a reputed security product such as “K7 Total Security” to stay safe from any cyber threats.

Security best practices

• Use a long, alphanumeric password with punctuation to match the recommended password strength, e.g. Th!sL00ks5trOng:-)
• Keep your system and software up-to-date
• Avoid clicking URLs from unknown sources (usually through social engineering)
• Install softwares only from trusted sources

Indicators of Compromise

• hxxp://support@173[.]56[.]92[.]166:42238/Mozi[.]a
• hxxp://L[.]U[.]F[.]E[.]Ngk[.]Uan[.]Gni[.]Ubi[.]xn–[.]U[.]K[.]3@1[.]246[.]223[.]18:1988/Mozi[.]a
• hxxp://skillbillz@88[.]250[.]254[.]90:1961/Mozi[.]m
• hxxp://b[.]r[.]uce[.]lee[.]b[.]es[.]t@1[.]246[.]222[.]80:4728/Mozi[.]m