MFA Fatigue Leads to Breach of Uber’s Corporate Systems
Regular readers of this blog are no doubt very familiar with the increasing threat of smishing along with multi-factor authentication (MFA) prompt bombing. In both attack vectors, bad actors are taking advantage of the commonality of SMS messaging in many authentication systems. Receiving a text (SMS) one-time password (OTP) on our phones to complete an authentication for a site seems like a daily occurrence. And as Uber recently discovered through a systems breach, MFA fatigue is a real security vulnerability.
MFA fatigue attacks are on the rise because they are working. The attacks exploit our human weakness by sending repeated MFA requests via SMS until the user completes the MFA verification. Users will often comply to make the requests go away as they assume it is a bug or other error in the system causing the requests or they subconsciously complete the request out of habit.
In the case of a recent attack on Uber’s corporate network, a hacker gained access by MFA prompt bombing an employee for over an hour and finally contacting them directly with an official-looking request via WhatsApp. The WhatsApp message appeared as though it originated from the Uber IT team. The victim was told they needed to accept the MFA requests in order to make the requests stop. As the victim complied, the hacker was authenticated and continued with the breach. The Uber attack required the hackers to already possess the victim’s login credentials and leverage prompt bombing to complete the MFA verification. In the Uber case, the attackers were able to purchase the credentials from the dark web. User data and credentials from prior breaches are commonly available and easily purchased on the dark web. Never reusing a password and always utilizing a truly random, unique, and strong password may have thwarted this attack.
Although the attack on Uber was disruptive to their internal systems, the latest release from the company states that no user data was compromised as part of the hack. The hackers initially gained access to Uber’s Slack messaging service and from there moved laterally within to access other internal databases. Employees of Slack initially thought the announcement of the hack on Slack was a joke and responded with emojis and GIFs. The attacker ultimately gained access to the Uber Amazon Web Services (AWS) account and Google Cloud account.
So far the Uber attack has not resulted in a ransom or leak of corporate data although that obviously can change. While it seems Uber got off easy from the attack, it should serve as a stern reminder that the human element is often the weakest link in security defenses. In the Uber attack, the victim was part of the incident response team and likely had some administrative privileges. Through these privileges, the attacker gained access to a file with other credentials giving them essentially the keys to the kingdom. Are you educating your employees and contractors on the active threats out there so you aren’t the next victim?