Secure Code Warrior

Hardcoded credentials can introduce security risks

Secure Code Warrior

Hardcoded credentials can introduce security risks

Secure Code Warrior is deeply committed to helping educate the security and developer community on how to write code securely as well as mitigate the risk of vulnerabilities introduced through insecure code. As part of this goal, we will be utilizing the developing story of Uber’s recent security incident as an opportunity to discuss the importance of developer driven security and shifting left.

Security Incident at Uber

Uber released a statement about the cyber security incident on September 16th and they continue to update it. Readers should keep in mind this is an ongoing story. Let’s recap what we’ve learned through Uber’s announcement so far and other reputable posts in the security community. 

The hacker started by socially engineering an Uber employee, after having found their What’sApp number. The attacker contacted them and started phishing for credentials by having the unsuspecting employee login to a fake Uber site and then capturing their username and password. 

Uber accounts are protected via Multi-factor Authentication (MFA), meaning that apart from submitting a password, the user must present a second piece of evidence that confirms their identity. In most cases, this is a prompt sent to a mobile device. 

After obtaining the credentials, the attacker initiated an MFA fatigue attack by continuously trying to login to the genuine Uber site, and overwhelming the employee with numerous push notifications on their device. Again, the attacker contacted the victim via WhatsApp. This time they allegedly pretended to be IT support and successfully convinced them to accept.

Hardcoded credentials

At the basis of Uber’s security breach was a successful phishing attack. Once inside, the intruder found network shares containing PowerShell scripts. One of these scripts contained an admin user’s hardcoded credentials, which led to the compromise of Uber internal services, such as AWS, G-Suite, and code repositories. The hacker also got access to Uber’s HackerOne account. According to Uber, however, “any bug reports the attacker was able to access have been remediated."

Curious to see what this vulnerability would look like in code? Try out our PowerShell challenge for free.

How common are these types of attacks?

Social engineering as an attack vector is difficult to defend against, as the human factor has always been considered the weakest part of cyber security. The Uber hack has clearly illustrated that MFA implementations can easily be circumvented. The key to preventing this is creating more awareness amongst employees about the workings of phishing attacks. 

What caused the exposure of Uber’s internal services, however, are the admin’s username and password that were found in a PowerShell script. Hardcoding credentials is never a good thing, as they become readable to any developer, and basically anyone with access to the code. 

But again, awareness is key! Developers with a security-centered mindset are more likely to spot vulnerabilities, and less likely to write them.

A two-pronged approach of general education on social engineering, and more specifically, proactive secure coding training, will reduce the number of vulnerabilities in a code base, and therefore prove to be critical in the fight against security threats.

Want to learn more about staying up to date with secure coding best practices? Check out Secure Code Coach. Here you can learn secure coding guidelines and tryout training exercises for free.  

*Indicates mandatory fields.

Contact permission

We would like your permission to send you information on our products and/or related secure coding topics. We’ll always treat your personal details with the utmost care and will never sell them to other companies for marketing purposes.

Thank you!

Oops! Something went wrong while submitting the form.

Secure Code Warrior is deeply committed to helping educate the security and developer community on how to write code securely as well as mitigate the risk of vulnerabilities introduced through insecure code. As part of this goal, we will be utilizing the developing story of Uber’s recent security incident as an opportunity to discuss the importance of developer driven security and shifting left.

Security Incident at Uber

Uber released a statement about the cyber security incident on September 16th and they continue to update it. Readers should keep in mind this is an ongoing story. Let’s recap what we’ve learned through Uber’s announcement so far and other reputable posts in the security community. 

The hacker started by socially engineering an Uber employee, after having found their What’sApp number. The attacker contacted them and started phishing for credentials by having the unsuspecting employee login to a fake Uber site and then capturing their username and password. 

Uber accounts are protected via Multi-factor Authentication (MFA), meaning that apart from submitting a password, the user must present a second piece of evidence that confirms their identity. In most cases, this is a prompt sent to a mobile device. 

After obtaining the credentials, the attacker initiated an MFA fatigue attack by continuously trying to login to the genuine Uber site, and overwhelming the employee with numerous push notifications on their device. Again, the attacker contacted the victim via WhatsApp. This time they allegedly pretended to be IT support and successfully convinced them to accept.

Hardcoded credentials

At the basis of Uber’s security breach was a successful phishing attack. Once inside, the intruder found network shares containing PowerShell scripts. One of these scripts contained an admin user’s hardcoded credentials, which led to the compromise of Uber internal services, such as AWS, G-Suite, and code repositories. The hacker also got access to Uber’s HackerOne account. According to Uber, however, “any bug reports the attacker was able to access have been remediated."

Curious to see what this vulnerability would look like in code? Try out our PowerShell challenge for free.

How common are these types of attacks?

Social engineering as an attack vector is difficult to defend against, as the human factor has always been considered the weakest part of cyber security. The Uber hack has clearly illustrated that MFA implementations can easily be circumvented. The key to preventing this is creating more awareness amongst employees about the workings of phishing attacks. 

What caused the exposure of Uber’s internal services, however, are the admin’s username and password that were found in a PowerShell script. Hardcoding credentials is never a good thing, as they become readable to any developer, and basically anyone with access to the code. 

But again, awareness is key! Developers with a security-centered mindset are more likely to spot vulnerabilities, and less likely to write them.

A two-pronged approach of general education on social engineering, and more specifically, proactive secure coding training, will reduce the number of vulnerabilities in a code base, and therefore prove to be critical in the fight against security threats.

Want to learn more about staying up to date with secure coding best practices? Check out Secure Code Coach. Here you can learn secure coding guidelines and tryout training exercises for free.  

Learn more about the risks associated with hardcoded credentials and social engineering as we discuss Uber's recent security incident and why it's so important for organizations to shift left and ensure their developers are up-to-date on secure coding best practices.

Secure Code Warrior is deeply committed to helping educate the security and developer community on how to write code securely as well as mitigate the risk of vulnerabilities introduced through insecure code. As part of this goal, we will be utilizing the developing story of Uber’s recent security incident as an opportunity to discuss the importance of developer driven security and shifting left.

Security Incident at Uber

Uber released a statement about the cyber security incident on September 16th and they continue to update it. Readers should keep in mind this is an ongoing story. Let’s recap what we’ve learned through Uber’s announcement so far and other reputable posts in the security community. 

The hacker started by socially engineering an Uber employee, after having found their What’sApp number. The attacker contacted them and started phishing for credentials by having the unsuspecting employee login to a fake Uber site and then capturing their username and password. 

Uber accounts are protected via Multi-factor Authentication (MFA), meaning that apart from submitting a password, the user must present a second piece of evidence that confirms their identity. In most cases, this is a prompt sent to a mobile device. 

After obtaining the credentials, the attacker initiated an MFA fatigue attack by continuously trying to login to the genuine Uber site, and overwhelming the employee with numerous push notifications on their device. Again, the attacker contacted the victim via WhatsApp. This time they allegedly pretended to be IT support and successfully convinced them to accept.

Hardcoded credentials

At the basis of Uber’s security breach was a successful phishing attack. Once inside, the intruder found network shares containing PowerShell scripts. One of these scripts contained an admin user’s hardcoded credentials, which led to the compromise of Uber internal services, such as AWS, G-Suite, and code repositories. The hacker also got access to Uber’s HackerOne account. According to Uber, however, “any bug reports the attacker was able to access have been remediated."

Curious to see what this vulnerability would look like in code? Try out our PowerShell challenge for free.

How common are these types of attacks?

Social engineering as an attack vector is difficult to defend against, as the human factor has always been considered the weakest part of cyber security. The Uber hack has clearly illustrated that MFA implementations can easily be circumvented. The key to preventing this is creating more awareness amongst employees about the workings of phishing attacks. 

What caused the exposure of Uber’s internal services, however, are the admin’s username and password that were found in a PowerShell script. Hardcoding credentials is never a good thing, as they become readable to any developer, and basically anyone with access to the code. 

But again, awareness is key! Developers with a security-centered mindset are more likely to spot vulnerabilities, and less likely to write them.

A two-pronged approach of general education on social engineering, and more specifically, proactive secure coding training, will reduce the number of vulnerabilities in a code base, and therefore prove to be critical in the fight against security threats.

Want to learn more about staying up to date with secure coding best practices? Check out Secure Code Coach. Here you can learn secure coding guidelines and tryout training exercises for free.  

Learn more about the risks associated with hardcoded credentials and social engineering as we discuss Uber's recent security incident and why it's so important for organizations to shift left and ensure their developers are up-to-date on secure coding best practices.

Secure Code Warrior is deeply committed to helping educate the security and developer community on how to write code securely as well as mitigate the risk of vulnerabilities introduced through insecure code. As part of this goal, we will be utilizing the developing story of Uber’s recent security incident as an opportunity to discuss the importance of developer driven security and shifting left.

Security Incident at Uber

Uber released a statement about the cyber security incident on September 16th and they continue to update it. Readers should keep in mind this is an ongoing story. Let’s recap what we’ve learned through Uber’s announcement so far and other reputable posts in the security community. 

The hacker started by socially engineering an Uber employee, after having found their What’sApp number. The attacker contacted them and started phishing for credentials by having the unsuspecting employee login to a fake Uber site and then capturing their username and password. 

Uber accounts are protected via Multi-factor Authentication (MFA), meaning that apart from submitting a password, the user must present a second piece of evidence that confirms their identity. In most cases, this is a prompt sent to a mobile device. 

After obtaining the credentials, the attacker initiated an MFA fatigue attack by continuously trying to login to the genuine Uber site, and overwhelming the employee with numerous push notifications on their device. Again, the attacker contacted the victim via WhatsApp. This time they allegedly pretended to be IT support and successfully convinced them to accept.

Hardcoded credentials

At the basis of Uber’s security breach was a successful phishing attack. Once inside, the intruder found network shares containing PowerShell scripts. One of these scripts contained an admin user’s hardcoded credentials, which led to the compromise of Uber internal services, such as AWS, G-Suite, and code repositories. The hacker also got access to Uber’s HackerOne account. According to Uber, however, “any bug reports the attacker was able to access have been remediated."

Curious to see what this vulnerability would look like in code? Try out our PowerShell challenge for free.

How common are these types of attacks?

Social engineering as an attack vector is difficult to defend against, as the human factor has always been considered the weakest part of cyber security. The Uber hack has clearly illustrated that MFA implementations can easily be circumvented. The key to preventing this is creating more awareness amongst employees about the workings of phishing attacks. 

What caused the exposure of Uber’s internal services, however, are the admin’s username and password that were found in a PowerShell script. Hardcoding credentials is never a good thing, as they become readable to any developer, and basically anyone with access to the code. 

But again, awareness is key! Developers with a security-centered mindset are more likely to spot vulnerabilities, and less likely to write them.

A two-pronged approach of general education on social engineering, and more specifically, proactive secure coding training, will reduce the number of vulnerabilities in a code base, and therefore prove to be critical in the fight against security threats.

Want to learn more about staying up to date with secure coding best practices? Check out Secure Code Coach. Here you can learn secure coding guidelines and tryout training exercises for free.