For most organizations, their Internet presence is the public face of their organization. The average consumer no longer shops via mailed catalogs or by visiting brick and mortar stores nor do they call the customer service line when they have a problem. Instead, people now shop mainly online and often take advantage of the customer service options offered on an organization’s website before talking to a “real person”.
As a result, the security of an organization’s website is an important priority. If a website can be taken down, defaced, or otherwise compromised by an attacker, it can have a significant impact on the organization’s bottom line and ability to engage with their customers.
An important component of website security is web application security. An organization’s web applications are code that is directly accessible and exposed to their customer base, including malicious users like hackers. As executable code, these applications are the most likely place for a vulnerability to exist on a website and are a common target for hackers.
As a result, developers need to take extra care to ensure that vulnerabilities do not creep into their applications during updates. However, as in the case of the Ruby on Rails strong_password backdoor, this can be more difficult than it seems.
The Ruby strong_password Library
Ruby on Rails is a programming language that can be used for the development of web applications. While it has lost some popularity in recent years, it is still embedded in many organizations’ websites at some level. The Ruby strong_password library, as the name suggests, is designed to test whether or not a user’s proposed account password is a good one. The calculation is based on the entropy of the password or how much randomness it contains.
With the number of data breaches that have been occurring in recent years, the need for strong passwords on user accounts is a significant one. Data breaches commonly involve collections of hashed passwords, which means that hackers cannot directly read the password a user has for a website. This is because hash functions are one-way calculations with no ability to go from the output of the hash function to the input that produces it.
However, hash functions are also deterministic, meaning that hashing the same value twice produces the same result. Therefore, if a hacker with access to a list of password hashes can guess a user’s password, then they can confirm that they have the right one.
This makes the use of strong passwords for user accounts vital for web application security. As the length and entropy of a password increases, the harder it is for an attacker to guess it. The Ruby strong_password library helps to ensure guessing difficulty, but only if it itself is secure.
Discovering a Backdoor
In July 2019, a backdoor was discovered in the Ruby strong_password library, or “gem”, completely by chance. A developer working on updating his own company’s software (which uses Ruby’s strong_password library) was performing due diligence by checking the changelogs that described the feature changes made in each update of each piece of software.
When he got to the strong_password library, he couldn’t find a changelog describing the differences between version 0.0.6 and 0.0.7. Digging further into the source code, which is publicly available on Github, he discovered that code has been added to perform a download from Pastebin (a site that allows online text storage).
This paste included code that the modifications to strong_password download and executed on the webserver running the application, allowing remote code execution by the attacker. After Tute Costa, the developer who discovered the backdoor, reported it to the maintainer of strong_password, the code was updated to version 0.0.8 to remove the malicious code. At this point, anyone who may have updated to the malicious version 0.0.7 should perform the update as well as perform incident response activities to determine the scope of the impact on potentially compromised systems.
Implications for Application Security
Web applications fill an important role in any organization’s web presence. These applications are exposed to the organization’s customers, open them up to attack, yet also have access to sensitive data and functionality within the organization’s protected network. As a result, their security is of vital importance since their unique position and power makes them a common target of attack by hackers.
Web application developers commonly leverage library code to help in building their applications. This is considered best practice since it helps improve efficiency and minimizes the probability that a mistake by the developer can compromise the effectiveness or security of the application. However, the developer is also trusting that the library functions are, themselves, secure.
The backdoor in the Ruby strong_password library is an example of a threat associated with a commonly used library function that was only detected by an eagle-eyed developer. Many organizations likely ignored the lack of changelogs for the malicious update and introduced malicious code into their production environment.
This vulnerability also represents the “easy” case for detection where the code is intentionally and maliciously inserted into a legitimate application. A mistake or oversight by a library function’s developer can be equally damaging to a web application that uses it. The value and vulnerability of a web application makes protecting it a priority. The potential for malicious or vulnerable code being snuck into an application via its updates poses a significant security risk. As a result, mitigating this risk by deploying a web application firewall (WAF) should be an essential part of any organization’s security strategy.