Retool, the company behind the popular development platform for building internal business software, has suffered a breach that allowed attackers to access and take over accounts of 27 cloud customers, all in the crypto industry.
According to a CoinDesk report, one the known victims is Fortress Trust, i.e., four of its customers who accessed their crypto funds via a portal built by Retool.
It all started with an SMS
The attack started with spear phishing text messages delivered to a number of Retool employees. According to the company, only one fell for the scheme.
Spoofed to look like it was coming from the companyâs IT department, the goal was to make the targets log in to a fake Retool identity portal, at which point they would receive a phone call by the attacker.
âThe caller claimed to be one of the members of the IT team, and deepfaked our employeeâs actual voice. The voice was familiar with the floor plan of the office, coworkers, and internal processes of the company. Throughout the conversation, the employee grew more and more suspicious, but unfortunately did provide the attacker one additional multi-factor authentication (MFA) code,â Snir Kodesh, Retoolâs head of engineering, shared on Wednesday.
âThe additional OTP token shared over the call was critical, because it allowed the attacker to add their own personal device to the employeeâs Okta account, which allowed them to produce their own Okta MFA from that point forward. This enabled them to have an active GSuite [i.e., Google Workspace] session on that device.â
And because the employeeâs MFA codes were synched with their Google account, the attacker now had access to all MFA tokens held within that account.
âWith these codes (and the Okta session), the attacker gained access to our VPN, and crucially, our internal admin systems. This allowed them to run an account takeover attack on a specific set of customers (all in the crypto industry),â Kodesh noted, and added that the attacker also poked around some of the Retool apps â but didnât specify which ones.
âWe have an internal Retool instance used to provide customer support; this is how the account takeovers were executed. The authentication for this instance happens through a VPN, SSO, and a final MFA system. A valid GSuite session alone would have been insufficient.â
Whoâs to blame?
âSocial engineering can affect anyone,â Kodesh noted, and âeven with perfect training and awareness of these attacks, mistakes will happen.â He also put some on the blame for the hack on Google.
The company recently released the Google Authenticator synchronization feature that syncs MFA codes to the cloud and made it easier to activate the feature than not to.
âUnfortunately Google employs dark patterns to convince you to sync your MFA codes to the cloud, and our employee had indeed activated this âfeatureâ. If you want to disable it, there isnât a clear way to âdisable syncing to the cloudâ, instead there is just a âunlink Google accountâ option. In our corporate Google account, there is also no way for an administrator to centrally disable Google Authenticatorâs sync âfeatureâ,â he explained.
âThrough this Google update, what was previously multi-factor-authentication had silently (to administrators) become single single-factor-authentication, because control of the Okta account led to control of the Google account, which led to control of all OTPs stored in Google Authenticator.â
Of course, Google cannot be blamed for this breach entirely â Retool should have regularly reviewed the protections theyâve put in place and evaluated whether they are still adequate. After all, attackers have been finding ways around multi-factor authentication for a while now, and the threat landscape is changing quickly.
If the company had used a FIDO2-compliant hardware security key instead of one-time passwords delivered via an authenticator app, this particular social engineering attack would have failed â as a similar attack against Cloudflare employees did a year ago.
The investigation is ongoing
Retool is working with law enforcement and a third party forensics firm to investigate the breach in depth.
So far, they found that 27 cloud customers have been affected (and they notified them all), but that on-premise Retool customers remain secure.
âRetool on-prem operates in a âzero trustâ environment, and doesnât trust Retool cloud. It is fully self contained, and loads nothing from the cloud environment. This meant that although an attacker had access to Retool cloud, there was nothing they could do to affect on-premise customers,â Kodesh noted.
Fortressâ customers, on the other hand, apparently lost nearly $15 million.
UPDATE (September 15, 2023, 04:35 a.m. ET):
âOur first priority is the safety and security of all online users, whether consumer or enterprise, and this event is another example of why we remain dedicated to improving our authentication technologies,â Google stated.
âBeyond this, we also continue to encourage the move toward safer authentication technologies as a whole, such as passkeys, which are phishing resistant. Phishing and social engineering risks with legacy authentication technologies, like ones based on OTP, are why the industry is heavily investing in these FIDO-based technologies. While we continue to work toward these changes, we want to ensure Google Authenticator users know they have a choice whether to sync their OTPs to their Google Account, or to keep them stored only locally. In the meantime, weâll continue to work on balancing security with usability as we consider future improvements to Google Authenticator.â
Application Security Program Handbook: A guide for software engineers and team leaders
InfoSec tools | InfoSec services | InfoSec books | Follow our blog | DISC llc is listed on The vCISO Directory
