During my employers annual PCI audit, our auditor requested that we perform a search of all of our servers for credit card data. He recommended a tool called “ccsrch” – which like many open source projects had a couple of issues, and hadn’t been updated in years. So, I fixed it.
CCSRCH is a cross-platform, command-line application that reads every file from the starting point passed in, and scans them for what looks like credit card numbers (and using the Luhn algorithm to check each possible result). It’s fairly brute-force, but it gets the scans required for PCI – though I would be careful about using it during production hours, it can have a pretty significant impact on a server’s I/O performance.
I’ve forked the application and setup a new ccsrch project over at github (the original is on SourceForge), and made a few modifications to better suit my needs (from the change log):
- Added option to output the file name, and how many hits were found to the console when using -o (see -c in usage).
- Added option to limit the number of results from a single file before going on to the next file (see -l in usage).
- Added option to exclude certain file types from the scan (see -n in usage).
- Fix for ignoring NULL, CR & LF.
- Ignore dash when scanning.
- Exclude results with the last 8 digits repeating (very unlikely to be a real PAN).
I’ve uploaded a Windows build of the new 1.0.5 release to github, and for *nix systems, you can just download the latest tag.
An Issuer Identification Number (IIN, more commonly called a BIN) is the first 6 digits of a credit or debit card, and it identifies the bank that issued it – and if you want to know if a number is a real credit card or just a bunch or random digits, it’s a huge help. While credit card numbers do use the Luhn algorithm (mod 10 check) to see if the number is valid, it still produces a huge false-positive rate.
SOPA, while it’s not likely to be passed as-is, I would be willing to bet money that something SOPA-like will be passed. It may be watered down with many of the most offending parts removed, but for those backing SOPA it’ll still be a real victory. For them getting it on the books, even in a weakened form means it can be tweaked (and extended) later.
There’s been an amazing resistance to SOPA, from the boycott of GoDaddy to public statements from celebrities such as Adam Savage – the public outcry against this horrid piece of legislation has been quite inspiring.
It has been 20 years since I first used machine learning to solve a complex business problem. The underlying problem was simple: the company was selling a new service and wanted to know who was most likely to buy it. We had millions of records, and each record had hundreds of fields. A vast amount of data, but no idea how to extract insight from it. Countless hours from various data analysts had been invested into finding a pattern, but none was forthcoming.
Much has been said, especially recently, about that mess of dependencies that modern applications have – and for those of us working in application security, there is good reason to be concerned about how these dependencies are being handled. While working on YAWAST, I was adding a new feature, and as a result, I needed a new dependency – ssllabs.rb.
While most Ruby dependencies are delivered via Gems, ssllabs.rb is a little different – it pulls directly from Github:
Update: The VICIDIAL team has publicly released a new version that, according to them, has corrected the issues I’ve pointed out here. Please make sure you are using the latest version available. If you aren’t sure if your instance is safe, contact your friendly local penetration tester to verify it’s secure as you expect it to be.
Update: The SQL Injection vulnerability has been assigned CVE-2013-4467, and Command Injection assigned CVE-2013-4468.
