Most CVEs occur as a result of a oversight in the architecture or mishandling of how libraries may interact with your application. In some cases like what had occurred with the Rest-client gem version 1.6.13, a package maintainer account on https://rubygems.org was hijacked and used to push malicious code that would compromise sensitive credentials for payment manager accounts, database access, repository access, and others that can cause irreparable damages. The hijacker conducted a series of releases – 1.6.10, 1.6.11, 1.6.12, and 1.6.13 – all of which contained malicious code. This attack was also more elusive in that it was affecting a point release from a older version. This strategy could have been for a target using a version within 1.6.10-.

What Possibly led to the CVE

We had a chance to speak to Matt Manning who provided some clues to what may have led to his account being compromised.

I probably hadn’t logged into the rubygems web UI since 2011/2012. I don’t know if they had 2fa back then, and I wasn’t disciplined about using a password manager then. I use 1password now, but that login was so old that I didn’t even have it in 1pass, so I didn’t catch it when I audited dupes, etc there. I probably haven’t pushed a public gem since 2014. I guess my api key was cached for that.

Matt raises a point of interest in which we’ll dive into further later, but, its worth noting that he hadn’t pushed to a public gem since 2014. This long predates when 2FA was introduced to RubyGems, which was announced on this blog post November 2018 RubyGems Updates (rubygems.org) in 12/09/2018.

It is possible that the hijacker looked for a package that would compromise the most codebases. The rest-client was certainly a prime target, with nearly 114 million downloads. This approach would ensure that the malicious code would spread fast, far, and wide due the ubiquitous nature of the gem. However, that the attacker chose to release an update to a very old version of rest-client suggests that it is possible that the attack may have been more targeted to particular company’s codebase that was known to the attacker to use the ~> operator in its Gemfile. The targeted company may presumably automatically upgrade to newer 1.6 releases unattended and deploy, but would not upgrade to a 1.7 or 2.x release on its own. An alternative theory would be that the attacker is going after old codebases expected to go unnoticed for a longer time that if the latest releases of the Gem were updated.

The hijacker then obtained the account name for a maintainer (mwmanning), Matt Manning. From there, going dumpster diving in old password dumps may have provided him with the credentials necessary to access to the maintainer’s account.

What did the CVE do?

On the Github thread, a user named @JanDintel summed up how the exploit would work if deployed:

1. It sent the URL of the infected host to the attacker.
2. It sent the environment variables of the infected host to the attacker. Depending on your set-up this can include credentials of services that you use e.g. database, payment service provider.
3. It allowed to eval Ruby code on the infected host. Attacker needed to send a signed (using the attacker’s own key) cookie with the Ruby code to run.
4. It overloaded the #authenticate method on the Identity class. Every time the method gets called it will send the email/password to the attacker. However I’m unsure which libraries use the Identity class though, maybe some

• @JanDintel

What can you do to prevent this type of attack in the future?

There are many popular package managers like RubyGems(Ruby), NPM(JavaScript), and pypi(Pyhton) all of which have 2FA options for maintainer accounts. So if you are a maintainer or have a in-house company library shared amongst the dev teams, there are many security measures your team can take with 2FA, YubiKeys, password managers like LastPass and 1password.

Here at Rietta, we have a company wide policy to have 2FA on all of our accounts as the base minimum. We have password rotation reminders and some of our employees use something called a YubiKey for that extra layer of security. This step is not to only protect our in-house credentials, but most importantly to protect our clients as it is our responsibility to keep that information secure.

What can the Community do to prevent future occurrences?

Due to the nature of Open Source Software, where libraries of code are open for anyone to contribute to, maintainers are everyday developers contributing to the ecosystem. Security is extremely important when millions of other codebases are integrating these libraries into their systems. Maintainers should always take the extra step of using 2FA at a minimum, to ensure that the good code they are providing to the community isn’t poisoned by bad actors.

Most popular package manager platforms do not enforce a 2FA policy for maintainer accounts for even libraries being used by millions of people. These maintainer accounts are treated with the same level of scrutiny as libraries with even 1 download. The package manager platforms should start enforcing the use of 2FA for all maintainer accounts.

Additionally, for accounts like Matt Manning’s, which haven’t been used in a long time, simply adding an additional security protocol for stale accounts would go a long way. For example, when an account hasn’t been used in X months (>=12 would be a good place to start), users without 2FA activated are required to go through an account recovery email verification or similar process, to regain access to their accounts.

This story is continuing to evolve, so look for further updates soon.

Keeping a clean git history can save a lot of time when trying to track down commits related to a bug or issue that is disrupting dev efforts. GitHub provides three options when merging in commits, these three options being: – Create a Merge Commit – Squash and Merge – Rebase and Merge Merging with a merge commit, squash merging, and “Rebase & Merge” should be pretty familiar as these are commands that are already commonly used when working on dev branches to keep commits on PRs tidy. We can apply this way of thinking when we want to keep the master branch Git history clean and helpful to future you and other developers who may be combing through the history to figure out why the code structure is the way it is.

The Short Answer (TL;DR)

If GAAP Compliance is required or you need 4 decimal places:

1

DECIMAL(13, 4)

Which supports a max value of:

$999,999,999.9999

Otherwise, if 2 decimal places is enough:

1

DECIMAL(13,2)

Which supports a max value of:

$99,999,999,999.99

The compromise of a staff user account credentials is a critical step in the kill chain of many data breaches. This compromise may be accomplished in many ways, including a staff user falling victim to a:

• credential stuffing attack when email and passwords in outside breaches are used to authenticate with work systems (because people reuse the same passwords frequently)
• targeted spear-phishing campaign to intercept valid credentials via a spoofed login form
• business e-mail compromise via a convincingly forged e-mail supposedly from a supervisor or the CEO

There are a few levels of staff credentials to address, those with access to:

1. legitimate business e-mail
2. the administrative portal/customer service via a web interface
3. development resources and testing environments
4. production resources like cloud providers and the domain name configuration

Traditional information security practice calls for the separation of duties between developers and those with production access. However, often only the most sophisticated, established organizations have the dedicated resources to do that. For everyone else, the developers usually have access to all these resources.

Abuser stories have been around for a while, and while not a revolutionary idea, it is somewhat of an untapped one, an underappreciated one, one that I personally hadn’t been exposed to in my nearly 30 years working as a business analyst. That’s a huge problem, if you ask me.

If you’ve been following our Git related posts, you probably notice we use git add --p with many of the examples used. This a great way for developers to split up code changes on one file to their own commit message. Not only will this make your pull requests cleaner, but will allow the code reviewer to get valuable context when diving into code changes on said file.

Git add patch gives us many options: Stage this hunk [y,n,q,a,d,e,?]?, the split option allows us to split lines that are close in proximity to each other. There are times where split won’t conveniently break up lines into hunks, lets explore how we can manually edit those tricky splits.

Fuzzy finders find files that almost no developer would intentionally find via a fuzzy finder from paths such as node_modules/, deps/, and dist/. These tend to get in the way of the true power of fuzzy file searching and ignoring these individually can be a pain. There are also files like .circleci/config.yml, .gitignore, and .rubocop.yml that are opened often enough to be included in the result set.

Luckily when working in a git repository, developers typically only care about the files they commit. When using fzf.vim, this technique returns files based on the git tree leaving out irrelevant files, including the hidden files that were shown before.

Managing many Clients with several projects where multiple team members are working them, across an Agency that has a different product offerings can be a challenge. Finding tools and processes to sort it out and ensure everything gets done, is on time, and on budget can be really hard, especially for a small Agency whose trying to keep costs down. The productivity tool market is flooded with options, and finding a good one is tough – but when you do, you want to share. Here’s a quick story on what we’re currently trying to tame the todo list. I hope you find it useful!

At Rietta, we understand the importance of continuing our education outside of the classroom. We use a reading channel in our company Slack to keep a pulse on industry and keep each other informed on the latest vulnerabilities. It’s been working great. Here’s how we do it.

An anonymous attacker has been compromising Git repositories and demanding ransom. This attacker stole the contents and used a force push to wipe the remote repository causing many to lose access to their critical source code assets. Use critical security tools available within the Git ecosystem to protect your company from this threat with:

• Deploy Keys
• Mandatory Two Factor Authentication
• Protected Branches and Pull Requests
• Backups of your Git Repositories