Credentials leaked in public? Here’s what Grofers implemented to prevent such mi...

 2 years ago
source link: https://lambda.grofers.com/credentials-leaked-in-public-heres-what-grofers-implemented-to-prevent-such-mishaps-66a40b5743af
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

Credentials leaked in public? Here’s what Grofers implemented to prevent such mishaps!

A report from the security firm Detectify said that they analyzed public GitHub repositories and found more than 1,500 unique “access tokens” that could be used to retrieve private messages from Slack — the popular office messaging app that many companies rely on as their primary communication platform.

The biggest threat to any organization comes from leakage of their system credentials whether it is due to an application level vulnerability, server mis-configuration issues, credentials shared via communication channels compromised or an employee’s mistake. While we can definitely implement stringent controls around the application and monitor it, server hardening prevents from various kind of mis-configuration issues but what about when an employee or developer mistakenly hard codes the credentials into the project, unknowingly push it to Github, make it public or share the secrets via communication channels like Slack, Hangout, Pastebin, etc. and someone outside the organizationgets hold of it. It’s an easy mistake to make that can lead to catastrophic breaches, particularly when the credentials can unlock systems that are crucial to business functions.

A simple query on Github search can give you access to a bunch of credentials which people inadvertently leave in their code. This is what happened with Uber in 2014 when hackers stole data of 50,000 drivers by getting into the company’s database using login credentials which an Uber employee had committed to a public GitHub repository by accident and was available for months.

The detective measures we implemented

We at Grofers strongly believe in is to give freedom to developers while keeping security protocols that do not hinder their pace.

This is the mission that we constantly push to achieve. Keeping this mission in mind, we implement various kinds of central monitoring to prevent any big security mishaps without controlling everything our developers do on a day-to-day basis.

Monitoring Git Repositories

We put in place an open source tool Gitrob which scans the repositories for secret, credentials and lists them down. The best part is that it not only can scans organization repositories but also repositories owned by the developers. This is very important as sometimes developers clone organization’s repositories and make them public mistakenly from their personal accounts.

Image for post
Image for post
Gitrob analyzing the repositories for credentials
Image for post
Image for post
Gitrob reporting credentials leak

To cover more ground around Github leaks, we also built an in-house tool which continuously scans an organization’s repositories and commits and scans repositories of all committers (current and ex-employees) for sensitive credentials and sends out alerts:

Image for post
Image for post
Gitleaks alerts

Sharing Sensitive Data

We have observed many incidents where people share sensitive keys and credentials in plain text via various channels like Slack or via popular code sharing sites like pastebin.com. The risk around sharing it by communication channels is straightforward. If your account gets compromised or laptop gets stolen, etc. then an attacker can scroll the chats or search through history messages to extract all the juicy information. However, if things get shared via pastebin they can easily be found by some simple google searches.

According to a report published in nextweb.com — In December 2010, Nick Denton’s Gawker Media was targeted by Gnosis, which used Pastebin to host an extremely long readme file detailing server logins, staff usernames, and passwords. The paste was associated with a 500MB torrent file posted to ThePirateBay, allowing anyone with a Bittorrent client to download 1.3 million usernames and passwords.

In comes our private sharing bin

To prevent this and helping employees to share credentials securely, we have implemented an open source snippet sharing platform — privatebin — where employees can share anything that they want to share with password protection over the shared link. They can also use the cool “burn after reading” option so in case anyone gets hold of the link, they won’t be able to read it again.

Image for post
Image for post
Privatebin home
Image for post
Image for post
Password protection over the shared link

We consider our employees as our first line of defense and so we always encourage them to follow the best security practices which not only help the organization to grow securely but also help our employees to be securer in the online world. Here are some of the best practices to remember:

1. Don’t leave sensitive credentials in your code public.

2. Make sure server config file/env files are not publicly accessible.

3. Don’t share passwords/credentials via Slack/Hangout or over mail in plain text.

4. Don’t use public sharing sites for sharing secrets or code sensitive to your organization.

What next?

As we scale up our platform bringing more people and technologies into our system, the chances of having security mishaps only grow, in turn increasing the challenges in keeping our infrastructure and products secure. Since security is a continuous process, we will continue working towards strengthening the security of our infrastructure and apps through tools and processes. Keep following us to know more about what we are doing. Stay tuned!

If you are interested in solving problems like this then drop me a DM or for other roles, you can reach out here.

About Joyk

Aggregate valuable and interesting links.
Joyk means Joy of geeK