Information Security News
Have you ever during a penetration test collected a list of values that look very much like hashes, and thought "I could maybe start cracking those, if I only knew what algorithm was used to calculate those hash values".
I had exactly this happen recently. In the past I've found any one of the dozens of lists of hash outputs on the net to be handy - Hashcat for instance has a pretty complete list posted ( http://hashcat.net/wiki/doku.php?id=example_hashes ). But this time I donned my googles and found the handy Hash Identifier python script at https://code.google.com/p/hash-identifier/ . This tool really saves a lot of work - these days my eyes are too old and my fingers are too big to be counting tiny characters in a hash string with any accuracy.
Hash_ID.py does a nice job of the more commmon hashes. Of course, if someone has the bad judgement to hash the output of one algorithm with another one (this is a really BAD idea if you are trying to prevent collisions), an identification utility like this will only id the last hash algorithm used.
Did it work for me? Yes, yes it did! It nicely identified the hash algorithms used. With the hashes and the algorithm, I was able to dump the list into OCLHashcat on a VM I've got for this (described here https://isc.sans.edu/forums/diary/Building+Your+Own+GPU+Enabled+Private+Cloud/16505). And the values did indeed give me a list of passwords, which I was then able to use against several different systems.
The finding of course in this situation was NOT "Nyah Nyah, I got in!", that's NEVER the finding. What goes in the report is (in a tactful way) "Application XYZ is using a simple unsalted hash algorithm to protect passwords", along with an english-language explanation of why exactly this is a bad idea, worded so that the manager of the coder who owns the XYZ application will understand it.
The end goal of a pentest isn't really to get in. The goal of a pentest is to explain to your client why fixing security related issues will benefit their business, and to get that explanation in front of the folks who decide which projects get priority. Breaking in is usually just the most fun way to make your point effectively.
Back to the tool at hand - if you've used a different hash identification utility, let us know using the comment form at the bottom of this page!
High CISO employment rates means shortage for security industry
Infosec management is a seller's market; those who are qualified don't have to look too hard for work. What is good for the individual is not good for industry, however. The downside is that it is tough for enterprises to hire qualified IT security ...
Rekindling concerns about the system millions of websites use to encrypt and authenticate sensitive data, Google caught a French governmental agency spoofing digital certificates for several Google domains.
The secure sockets layer (SSL) credentials were digitally signed by a valid certificate authority, an imprimatur that caused most mainstream browsers to place an HTTPS in front of the addresses and display other logos certifying that the connection was the one authorized by Google. In fact, the certificates were unauthorized duplicates that were issued in violation of rules established by browser manufacturers and certificate authority services.
The certificates were issued by an intermediate certificate authority linked to the Agence nationale de la sécurité des systèmes d’information, the French cyberdefense agency better known as ANSSI. After Google brought the certificates to the attention of agency officials, the officials said the intermediate certificate was used in a commercial device on a private network to inspect encrypted traffic with the knowledge of end users, Google security engineer Adam Langley wrote in a blog post published over the weekend. Google updated its Chrome browser to reject all certificates signed by the intermediate authority and asked other browser makers to do the same. ANSSI later blamed the mistake on human error. It said it had no security consequences for the French administration or the general public, but the agency has revoked the certificate anyway.
I had a chat with another one of the ISC Incident Handlers the other day about inventorying large networks, which is covered in the first two Controls in the SANS "Critical Security Controls" (http://www.sans.org/critical-security-controls). Paraphrased, these controls boil down to "know what's on your network" and "know what software and services are running on those stations".
This seems like a couple of pretty obvious statements, but it started me thinking about my client base. For instance, about just how many are still running old print servers that top out at 10Mbps and advertise IPX printer SAPs. Similarly, I started implementing a standard to isolate ATMs in a banking environment (without changing any IPs), and found a number of switches sol old that they didn't support port based ACLs, or Private VLANs or source port filtering.
In short, it's really easy to let sleeping dogs lie (or prevaricate) - it's easy to let that 10 year old (plus) hardware that's been working forever stay on the network until you need a feature that doesn't exist on them. And if it's easy to let this happen with IT owned gear that you know about, how about stuff that's NOT owned by IT? Stuff like cameras, projectors and video conferencing units? Or how about even more removed from IT - gear like elevator controls and HVAC systems? Time clocks or PLCs? Or, just to up the ante, medical devices that are network attached in a hospital or other health-care setting?
And that's just the hardware. If you are inventorying your corporate stations' software, you're most likely using the OS's "list applications" commands or API calls to do this, whether in your own scripts or wrapped into a commercial product.
For windows, you might use commands like:
wmic product list /format:csv > applist_for_database_import.csv
wmic product list brief /format:htable > %COMPUTERNAME%_applist.html
In Linux, depending on the distro you might use one of these:
yum list installed
However, these commands and other active scanning methods won't help you in a lot of cases - situations like:
So, what should you do to find these incognito stations and camoflaged applications? For many of my clients, we look for evidence of these situations in the network traffic that they create, just the same way we often find Indicators of Compromise in malware or attack situations.
Several tools will help you in finding, fingerprinting and identifying versions of apps like this. The "granddaddy" of these "passive scanner" applications is p0f. Downloadable from http://lcamtuf.coredump.cx/p0f3/, it's been around for over 10 years, is still actively developed and is still free. If you have a budget and are looking for a commercial alternative, PVS from Tenable might also fit the bill - either instead of or in conjunction with p0f. Info on PVS can be found here: http://www.tenable.com/products/passive-vulnerability-scanner, it's available for free for up to 16 nodes, or you can get an "eval-ware" version for larger networks.
So, with good tools in hand and pure intentions in your heart, how to proceed? You'll need to find a spot on your network to capture traffic of interest - the obvious place is to put your sensor station would be on a SPAN port, sniffing the traffic on the inside interface of our firewall. However, this won't find traffic to identify internal-only stations like internal-use database servers, print servers and the like. For these, you'll want a SPAN port capturing an entire internal VLAN, or perhaps capturing traffic from internal router ports. It's best to take some time and apply some business process knowledge to place your station well, or in many cases several stations.
There are lots of other pointers on using "fingerprint" applications - the SANS Reading Room at http://www.sans.org/reading-room is a great place to start, or the SANS Security Resources pages here http://www.sans.org/security-resources/idfaq/p0f.php.
In my most recent deployment of p0f, we found unpatched Win95 stations running a pharmaceutical assembly line. Stations that were put in by the industrical controls vendor back in the mid-90's, buried inside the cabinets with the PLCs and so on, then just plugged into the network so the plant engineers could get to them. Nobody left in the organizations had any idea these stations were there, the plant engineers who used them knew the interfaces, but not what was behind them. And of course these stations were just about as business critical as you could find - SCADA systems in all but name.
What tools have you used for passive discovery? Use our comment form and let us know where you've placed passive sensors in your network and most importantly, what's the most interesting things that you've found?