Could the Twitter Social Engineering Hack Happen to You?

Learning from the experiences of others should be a key job requirement for all cybersecurity, AppSec, DevSecOps, CISO, CRMO and SecSDLC professionals. The recent attack against Twitter where high-profile accounts were compromised to promote a Bitcoin scam is one such opportunity.

As new information comes to light (and I sincerely hope that Twitter continues to provide meaningful details), everyone within the cybersecurity realm should look to both their internal IT and application development practices as well as those of your suppliers for evidence that this particular attack pattern couldn’t be executed against your organization.

What we know as of now is that on July 15th, an attack was launched against Twitter that targeted 130 accounts. Of those 130, 45 had their passwords reset and eight had their Twitter data downloaded. While the initial public focus was on Twitter Verified accounts, those eight accounts were not verified.

The attack itself was based on the concept of social engineering where the targets were Twitter employees with access to an administrative tool capable of modifying account access of individual Twitter employees.

The attacker’s actions included posting a Bitcoin scam on prominent accounts, but it has also been reported that there was an effort to acquire Twitter accounts with valuable names.

That the attack had a prominent component of a Bitcoin scam and a secondary component of account harvesting, there is an obvious first question we should be thinking about: With the level of access the attackers had, why wasn’t their attack more disruptive? This is a perfect example of attackers defining the success criteria and thus the rules of their attack.

That being said, it’s entirely plausible that the true goal of this attack has yet to be identified and that the attackers might easily have installed backdoors in Twitter’s systems that could lay dormant for some time.

Looking solely at the known information, everyone working with user data should be asking these types of questions:

• Which accounts have administrator, super administrator or God-mode privileges?
• Can a normal user possess administrator capabilities, or do they need to request them with specific justification?
• Are all administrator-level changes logged and auditable?
• Can an administrator modify logs of their activities?
• Are there automated alerts to identify abnormal administrator activity, which might occur from rarely used accounts?
• What limits are in place surrounding administrator access to user data?
• What controls are in place to limit damage should an administrator misuse their credentials, either intentionally or as the result of a credential hack?

For most organizations, administrator access is something given to their most trusted employees. For some, this trust might stem from how long the employee has been with the organization. For others, trust might stem from a variety of background checks. None-the-less, administrators are humans and humans make errors in judgement – precisely the type of scenario social engineering targets.

Knowing that an administrator, particularly one with God-mode access rights, will be a prime target for social engineering efforts, any access granted to an administrator should be as limited as possible. This includes scenarios where an administrator is called upon to resolve users access issues.

After all, someone claiming to be locked out from their account could easily be an attacker attempting to coerce someone in tech support to transfer rightful ownership into their hands. This implies that on occasion a successful account takeover will occur, and that the legitimate owner will retain control of the original contact methods, such as email address, phone numbers and authenticator apps.

If the business sends a confirmation notice to the previous contact method when it changes, that then offers an additional level of warning for users who may be potential targets. The same situation should play out with any security settings such as recovery questions or 2FA configuration.

Since this attack on Twitter exploited weaknesses in their account administration process, it effectively targeted some of the most trusted people and processes within Twitter. Every business has trusted processes and people, which means that they could be equally vulnerable to such an attack.

This then serves as an opportunity for all businesses to reassess how they build and deploy applications with an eye on how they would be administered and what process weaknesses could be exploited.

About the author: Tim Mackey is Principal Security Strategist, CyRC, at Synopsys. Within this role, he engages with various technical communities to understand how to best solve application security problems. He specializes in container security, virtualization, cloud technologies, distributed systems engineering, mission critical engineering, performance monitoring, and large-scale data center operations.

Copyright 2010 Respective Author at Infosec Island via Infosec Island Latest Articles "https://ift.tt/30Jye1x"