I’ve released a new version of CCSRCH, the open-source PAN (a.k.a credit card number) search tool to help companies maintain PCI compliance. This is a fairly minor release, primarily focusing on reducing false positives. The scanner has been updated to exclude the following:
- Results made up of the same two digits repeating (i.e. 5454545454545454).
- Results that have seven or more of the same digits repeating (i.e. 5555555555554444).
I also fixed a bug that I introduced in v1.0.6 that prevented it from compiling on certain *nix systems; while I was in there I also fixed several instances of this building warning on newer Linux distros:
warning: call to __builtin___strncat_chk might overflow destination buffer
[enabled by default]
I also took the time to write-up really simple build instructions for *nix users:
$ wget -O ccsrch.tar.gz https://github.com/adamcaudill/ccsrch/tarball/master
$ tar -xvzf ccsrch.tar.gz
$ cd adamcaudill-ccsrch-<rev>/
$ make all
This will probably be the last release for now unless a bug turns up; to improve results further I’m working on a new project (ccsrch-score), hopefully it’ll be released soon.
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.
On August 28th ElcomSoft announced that they had determined a method to extract Windows passwords from the registry for users of UPEK’s fingerprint readers and Protector Suite software (UPEK is now owned by AuthenTec, which is now owned by Apple). What they didn’t announce was the technical details of how they did it. Myself and Brandon Wilson have been working to recreate their research – and we have.
We have not been in contact with ElcomSoft, so this is an independent re-discovery of this vulnerability.
I recently finished building my first MiniPwner – a tiny OpenWrt-based system for pen-testing. At only 2.25 x 2.25 inches, the device plus battery is still extremely small – it easily fits in a pocket, and could be hidden anywhere.
The device is based on the TP-LINK TL-WR703N, which uses a 400Mhz Atheros AR7240 CPU – not exactly a power-house, but enough power for standard pen-testing (or even just as a super-portable linux box).
The last release of YAWAST was on January 1, 2020; while the release history was sometimes unpredictable, the goal was a new release each month with new features and bug fixes. I intentionally took January off from the project. In February, I left the company I was at; the team of penetration testers there had helped to inspire new features while looking for ways to make them more productive. But something else happened in February, an issue was opened – something that appeared to be simple, but in fact, made me realize that the entire project was in doubt.
Testing for SWEET32 isn’t simple – when the vulnerability was announced, some argued that the best solution was to assume that if a TLS server supported any of the 3DES cipher suites, consider it vulnerable. The problem is, it’s not that simple. On my employer’s corporate blog, I wrote about practical advice for dealing with SWEET32 – and pointed out that there are ways around the vulnerability, and some are quite simple.
