The SourceClear Blog

Rails GEMS Vulnerable to CSRF Show Vulnerability Disclosure in Open-Source Projects Needs a Re-Think

Posted By: Ang Ming Yi and Mark Curphey
March 20, 2017

Four weeks ago, we blogged about the issue with Rails’ built-in anti-CSRF mechanism, protect_from_forgery, where we calculated that over 50,000 Ruby developers were impacted by Cross-site Request Forgery (CSRF) attacks.


Over 50,000 Ruby developers impacted by CSRF attacks

Posted By: Ang Ming Yi, Darius Foo, Jason Yeo
February 22, 2017

There’s been some buzz recently about protect_from_forgery, Rails’ built-in anti-CSRF mechanism, and how it’s not secure by default. Having found, evaluated, disclosed, and tried to fix issues with it in the past, we decided to perform a thorough evaluation of how severe the problem was.


Millions of program builds vulnerable to Man-in-the-Middle attacks

Posted By: Ming
January 16, 2017

According to a blog post made on 18f, it is a standard to ensure all federal websites and web services to serve only via secured connections (HTTPS). Yet in its recent study, about 6.1% of the domains do not have HTTPS enabled. Package managers have, in the past, deprecate certain commands/features that defaults to HTTP. RubyGems has deprecated source :rubygems in Gemfile due to the insecurity of HTTP, and recommends the explicit use of HTTPS.

In this post, we will highlight the issues of insecure network connection(s) made by open-source libraries during build time. Also, we introduce an open-source monitoring tool, Build Inspector, that can be used to detect insecure network traffic made during the build process. Finally, we analyze the number of affected builds from a sample pool of open-source repositories.


Rails_admin Vulnerability Disclosure

Posted By: Jason Yeo
December 25, 2016

A few days ago, I found a CSRF vulnerability in rails_admin. rails_admin is a Ruby gem that generates administrative interfaces for your models automatically. Interestingly, this vulnerability is similar in nature to the one I found in administrate, a similar gem. Additionally, past Ruby gems affected in a similar fashion can be explored at this link.


The Ransomware in our Dependencies

Posted By: Darius Foo & Steve Ng
November 30, 2016

Ransomware is a growing pernicious threat. Some ransomeware called ‘Locky’ was recently discovered spreading through Facebook Messenger, and just last weekend San Francisco’s light-rail system was compromised by ransomware. Today we’ll take an in-depth look at how ransomware can target developers, proliferating through library dependencies.


The biggest SourceClear release yet!

Posted By: Brian Doll
November 21, 2016

We’ve got a present for you this week. This is the biggest release of SourceClear since we launched, and we can’t wait for you to dive in. Thanks to everyone who’s ideas and feedback have helped shape this release, and a special thank you to all of our beta testers who have shown us how crucial SourceClear is in helping teams build secure software.

If you’re not using SourceClear yet, today is a great day to sign up. Here is a rundown of all the new features being released today:


Abusing npm libraries for data exfiltration

Posted By: Asankhaya Sharma
November 11, 2016

Package and dependency managers like npm allow command execution as part of the build process. Command execution provides an easy and convenient mechanism for developers to script tasks during the build. For instance, npm allows developers to use pre-install and post-install hooks to execute tasks. A pre-install hook can be used to compile some dependent native library before starting the build. A post-install hook can be used for clean up after the build.

In this blog post, we demonstrate how an attacker can use npm to exfiltrate information from the developer’s machine. Although we show the attack scenarios for npm, similar attacks can also be done on other package managers like gradle.


Build Inspector - A forensic sandbox for Continuous Integration environments

Posted By: Brian Doll
November 10, 2016

Don’t trust user input. That’s a core security tenet for building secure software. In our web applications we sanitize text input to protect against XSS, and verify uploaded files are free of malware. But what happens when you take user-submitted software and execute whatever it tells you to do? That’s essentially what Continuous Integration environments are made for. If the tests say to count to 10, the system counts to 10. If it says to download software and start mining for Bitcoin, that’s exactly what it’ll do.

Misbehaving or even malicious builds are a difficult threat for CI environments to protect against. Continuous Integration services are essentially asked, every day, by every customer, to run random pieces of software. If you run a CI system at your company, you’re doing the same. To help identify these potentially dangerous builds, we’ve been working on a project called Build Inspector.


A deep dive into analyzing dynamic languages

Posted By: Darius Foo & Asankhaya Sharma
November 8, 2016

Analyzing programs written in dynamic languages presents some unique challenges. Here’s a bit of a deep dive into how we do it. First, what exactly is a dynamic language? For the purposes of this article, we will define a dynamic language as one where types are checked for safety only at runtime. Languages like Ruby, Python, and JavaScript follow this model, in contrast with static languages like Java and C#, where type safety is ensured at compile time.


A look at Vulnerabilities and Dependencies by Language

Posted By: Brian Wallace
October 25, 2016

As a Data Scientist at SourceClear I get to analyze lots of interesting vulnerability data as well as anonymized project data. New customers often ask us what “normal” looks like when it comes to vulnerabilities in their projects, so I thought I’d take a look and share a few insights.

Page 1 of 9 >