The PMKID Attack

A new attack vector, but not the golden ticket to Wi-Fi pwnage. 

So, you've seen the new attack one can do on Access Points. Its client-less, meaning no need to do Spiderman stunts on the sides of buildings trying to be in range of both the AP's AND the client's using them.
No doubt you thus pulled out your Wi-Fi adapters and began trying to perform this attack. Only to find your success rate is less than stellar.

We're going to go through some background about this attack vector, as well as some ways we can approach it. Keep in mind that the "old" or traditional method of WPA2 attacks based on capturing handshakes is still the most viable to guarantee results. However, the method of capturing PMKID's is easier if you are not within range of clients - especially with highly directional antennas.

How does it work?

A brief lesson in Wi-Fi and how client's and AP's talk to each-other is in order.

STEP 1 - Who's out there?
When your Wi-Fi network adapter kicks in and comes online, your system (be it Windows, Linux, MacOS, iOS etc.) will perform a few things. One of those is to find known networks that it has connected to before. It does this by sending a "probe" request along with the network name (SSID) that it is looking for.

For example, if your device connects to your home network called "HOME_WIFI", even when you are at the Mall, your device is "probing" for "HOME_WIFI" - to see if it is available and to connect to it.

If an Access Point is within range who's name is "HOME_WIFI" - it will respond to the probe request.
Note that your AP will respond with an RSN, which is Robust Security Network. This RSN enables negotiation of available encryption and authentication types. 

STEP 2 - "Hi, its me!"
Your system, and thus Wi-Fi adapter now reply to the response from the AP with an Authentication Request. Note that your Wi-Fi adapter cannot "Associate" to an Access Point until Authentication is done. For obvious reasons - much like you would not first open the door to find out who the stranger is, vs looking through the intercom and checking they're who they say they are before opening the door.

The Authentication Request prompts the Access Point to reply with its own frames for authentication, now being Sequence 2 and indicating if your request to associate is successful.

STEP 3 - "Let me in!"
Upon receiving the Sequence 2 frame from the AP, your client can now do a few things. For the PMKID attack however, the client is going to do the following:
The client is going to send an Association Request to the AP along with the ESSID and RSN (see above) information.
At this point, the stranger is saying open the door, but we have not authenticated yet.

The AP responds with "Hmmm, lets negotiate your access first." - It does this by replying with an EAPOL frame (1/4 sequence) which, if supported by the AP, would contain the PMKID.

At this point, we now have the PMKID. But what exactly do we have?

The PMKID consists of the PMK, a feature of RSN which includes the PMK Name, The AP's MAC Address and the Station's Mac Address all concatenated together and processed through HMAC-SHA1-128 algorithm to result in a hash value.
The below is taken from the Hashcat website to illustrate how the PMKID is derived:
PMKID = HMAC-SHA1-128(PMK, "PMK Name" | MAC_AP | MAC_STA)

Let's get Cracking

One avenue of this new attack vector that I very much like, is that I not only do not need to be in range of clients AND an AP, but also that I can actually be very FAR from an AP with a good quality and powerful directional antenna. Since I'm only interested in traffic to/from a single point, not a potential client as well.

To test this, I pulled out my trusty "Can"-tenna for this example. Once you have it pointed in the general direction, use airodump-ng to scan for networks and tweak the "can"-tenna movement until you have a nice strong signal from your target AP.

You will need to download and compile HCXTools and HCXDumptool from https://github.com/ZerBea - doing this on Kali is trivial and should take just a few minutes.

NOTE: By default, HCXDumptool is going to target ALL AP's your adapter can see. I document how to prevent this further below if you do not want your attacks hitting all available networks around you.

STEP 1 - Put your Adapter into Monitor Mode

Put your Wi-Fi adapter into monitor mode, by using either of the two options below. Note that your adapter must support Monitor Mode & Packet Injection for it to be used with these tools.

OPTION 1 (assuming wlan0 is your wireless adapter)
ifconfig wlan0 down
iwconfig wlan0 mode monitor
ifconfig wlan0 up

(note the difference between iWconfig and iFconfig above)

OPTION 2 (assuming wlan0 is your wireless adapter)
airmon-ng check kill
airmon-ng start wlan0

(note that airmon-ng check kill is used to kill the WPA supplicant and DHCP clients which can mess up tools trying to monitor traffic. Even if using Option 1, you could still run airmon-ng check kill to kill unwanted processes).

If you used OPTION 1, your adapter will remain wlan0 and be in monitor mode. If you used OPTION 2, your adapter is now called wlan0mon and is in monitor mode.

STEP 2 - Use HCXDumpTool to get those PMKIDs

By default, running HCXDumpTool with the below syntax will work:

However, as mentioned, we want to target only specific network(s) and their AP's. To do this, simply run airodump-ng and find your target SSID plus the Base Station Mac Address:

We will now tell HCXDumpTool to perform the same attack above but this time with 2 extra switches - one will give it a "filter" file which contains the MAC address of the target AP we want to attack, and the second switch will tell HCXDumpTool to ONLY TARGET the Mac addresses in the filter list.

Note that the filter list should not have blank or empty lines in it. Also Note that the filter file's Mac address should have the colons (":") removed from the hex address.

We now run HCXDumpTool again, using the filter switches and watch as it attacks our target network, waiting for a PMKID.
The switches are:
--filterlist=<filename>  To tell the tool which file contains the Mac Addresses
--filtermode=2  Tells the tool that these Mac Addresses in --filterlist are our targets, ignore anything else:

STEP 3 - Extract the PMKID hash value

To do this, we use HCXTools OR you can upload your packet capture file to https:///labs.bitcrack.net/pmkidtool.php which will extract the PMKID from any Wi-Fi capture file for you.

The PMKIDTool on Bitcrack's website is also useful if you have an older capture file lying around from Wireshark or airodump-ng and want to check if it contains any PMKIDs.

The example below is using HCXTools:

STEP 4 - Crack the hash with Hashcat

Download Hashcat from https://hashcat.net or build it from source.
Once you have Hashcat, simply use Mode 16800 ( -m 16800) and crack it as you would any other hash file.

Assuming you have a wordlist called MyBigWordlist.txt, your Hashcat command would look like this:

We won't go into detail of the cracking job, as it will vary greatly according to your hardware. Note that GPU's are preferred over CPU's for this kind of hash. Also note that if you want to use only CPUs, you will need to install the Intel OpenCL drivers. See more on the Hashcat website.

Conclusion

As you can see, this is a very viable attack vector if you do not have access to clients on the target Wi-Fi network. However, it is only supported by certain Access Points, and hence you may not be able to obtain a PMKID.
The best solution is to use a dual-approach of this method and the original 4-way handshake capture method. Between the two, your success rate of obtaining something to crack will be much higher.



-------
Dimitri Fousekis AKA RuraPenthe.

Thank you to ZerBea/ZeroBeat and Atom for their work on the PMKID attack vector. 
The information in this article is strictly for education purposes only. We take no responsibility for how this information is used. 

KRACK What!?!

Hours after hitting the web, the vulnerability in WPA2 known as "KRACK" is causing major waves and making people panic.

It is still unclear how far and how quickly attackers will take this. But rest assured as the vulnerability becomes better known and more exploitation software and scripts are written for it - its going to go like wildfire!

So, what is "KCRACK"? What does the vulnerability entail? Should we throw all our Wi-Fi devices in the Bin and rewind the world back 30 years?

The short answer is No, the long answer is: You've been warned...

What is KRACK?

Without venturing too deeply into how WPA2 handshakes work, in its simplest form when a wireless device (a client, like your mobile phone) connects to an AP (Access Point, the thing that runs your Wi-Fi network) the following happens between the two to ensure security...

1. The AP sends a nonce (a value used only once) to the client. It does this using the key that is derived from the PSK (Pre-shared key - the "password" you typed into the AP at setup)
2. The client takes that value and creates a Pairwise Transient Key (PTK) along with the the authentication code and a new nonce value it generates. It sends this back to the AP.
3. If all is well, the AP responds with a Message Integrity Code (MIC) and a Group Temporal Key (GTK) to the client.
4. If all is well, the client responds with an ACK (all ok/acknowledgement) and the client is now connected.

Due to the fact that at any time, a client could be temporary disconnected, or out of range etc - the WPA2 protocol allows the packet with the key to be re-sent subsequent handshakes to re-establish the connection. 

It is at this function of the WPA2 protocol that KRACK's exploitation exists.

Note that at MESSAGE 3 above - the client installs the key it receives from the AP. To support the possibility that packets of data may have dropped, or were lost - the AP has the ability to re-transmit MESSAGE 3, and herein lies the problem.

Every-time the Client receives "MESSAGE 3" of the handshake, it re-installs the key it was given and resets its incremental packet transmit number (or IV) to 0 (this is used as part of blocking potential replay attacks).

Now think about this - If I can collect and replay these "MESSAGE 3"'s what happens? I can force the Client to keep on re-inserting a key and resetting its transmit number to 0. So we force the client to always use an increment packet number (or Initialization Vector) of 0. The encryption key the client will use for the next packet send will be the same encryption key already used and with nonce values already used in the past! Now we have got the client to encrypt the data with something we know and can control.

The result is that the WPA2 Encryption process will use the same stream of computed random characters when encrypting packets.

So...

What can someone do with this attack?

They can potentially decrypt data in transit (through the air) by having forced the encryption process into a direction they control and/or have decryption of.

They can also inject packets and/or modify TCP/IP packets with the correct attack vectors and tools in place.

This applies to WPA2 Pre-Shared Key (PSK) and Enterprise-based WPA2 Authentication.

What can someone NOT do with this attack?

They cannot obtain the password of the WPA2 network (the older, well-known methods of obtaining password keys can still be used).

They cannot recover new encryption keys created between the legitimate AP and its client. 

How do I mitigate against this?

We have to wait for patches. The problem is many IoT device manufacturers are barely patching their unstable devices, let alone patching this! 

The result is many devices will be unpatched and in-use that will remain vulnerable. 

For mainstream systems, and software/hardware vendors who put effort into user support - we can expect patches to start coming through to fix this vulnerability urgently. 

Another method of mitigation, especially within corporate environments, is to make sure you use (proper) SSL security for critical internal data traffic. This way even if the WPA2 encryption is breached, the data is still going over secure SSL channels.*

-Dimitri Fousekis
@rurapenthe0

*Bitcrack highly recommends that you avoid using SSL with invalid certificates. This causes users to become accustomed to accepting errors in SSL/HTTPS browser warnings which could allow someone performing a man-in-the-middle attack to be extremely successful. Use SSL certificates that are signed by global parties and are installed with correct URL names etc.  Any errors in a browser should make the user suspicious, not be part of normal operation.

Some information was obtained from the official KRACK founder's website: https://www.krackattacks.com/

Any vulnerability information shown or explained here is for educational and informational purposes only. 

1 Backpack, Many HIDs.

DISCLAIMER:
The following information, illustrations and design are for educational purposes, and the furtherance of protecting secure areas with the explicit permission of the owners. Please do not use such devices for any illegal purposes.

At Bitcrack, we often find ourselves conducting a red-team, or penetration test that involves access control assessment,  Wi-Fi assessments, RFID and so forth.

One thing that often gets in the way of a successful assessment is having to stop and take stock of collected data, process logs and so forth. We have thus embarked on a project to consolidate our attack hardware into a platform that can be easily used and deployed in the field.

In this blog post we are detailing our HID RFID clone tool. It is loosely based on the Tastic RFID thief, with some modification.

The Problem
We liked the Tastic RFID Thief (thanks to BishopFox) for our assessments, but it had some issues for us. A major one being that one has to capture HID tag IDs, then stop somewhere, eject the SD card and open it on a computer/laptop to clone the HID using a Proxmark or something similar.

The Solution
Build an all-in-one solution to capture-and-write cards on demand with nothing more than your backpack and mobile phone/tablet.

To do this, we did the following;
1. Build our own Tastic version and modify it to suit our needs.
2. Build a central control unit to manage our "captured" RFID cards, and writing the cards on the fly.
3. All the necessary programs and scripts written to run it.

Below is a picture of our final products, shown individually:

The items above are;
1. a HID ProxPro II Reader
2. a 2.1A 5V Li-Ion Battery Pack
3. an Elec House Proxmark 3 RDV2
4. a custom-built Tastic RFID Thief with a home-made 3D-Printed box, LCD display. We removed the SD card and its associated program code. We also modified the code for our serial data requirements, and added a Li-On battery.
5. a Raspberry Pi with our code running on it.

The Tastic RFID unit close-up and on, looks like this:

We take all our components, and put them in a back-pack to create an easy-to-use walk-around HID read-and-clone system.

Backpack

HID Card Reader in Front of Bag

Tastic + Raspberry Pi + Battery Pack in center of backpack

Proxmark in side pocket

The Attack Process

The attack process is:

STEP 1

Get the bag near a HID RFID card (if it is worn, simply hang around people with cards in close proximity, around +/- 20-25cm)

STEP 2

As the system obtains RFID cards from people around you, the website open on the Phone/Tablet automatically updates to show you what cards you've captured.

STEP 3

Take a "blank" card out of your pocket, hold it against the side of the bag against the Proxmark  and click CLONE ME for the corresponding captured card you wish to clone.

DONE!

The cloned card can now be used to access the areas the original card would have access to. A Red-Team simulated attack or Penetration Test can now continue. The system verifies that the cloned card is a match of the captured card you chose. 

TODO:

Still on our list to add to our system is;

1. Support for other TAG types by simply holding them against the side of our bag to the Proxmark and using the phone interface to modify/clone them. 

2. Addition of a Wi-Fi dongle to our Raspberry Pi and the building of a Wi-Fi attack module into the website to allow for Wi-Fi audits directly from the hand-held via the Backpack while walking around in the environment.

-Dimitri AKA RuraPenthe

Bitcrack Cyber Security

@bitcrack_cyber

@rurapenthe0

Copyright © 2017 Bitcrack Cyber Security.

New Hashcat Optimization - Faster Maxwell Cards!

NOTE: Edited to include a measurement of the next optimization done on build 3.10-620. See table at the end.

Hashcat, the de-facto password cracking tool that recently went open-source, works very well on both AMD and Nvidia GPUs.

One problem however, was that when everyone went out to buy their GTX 980's and other Maxwell-based cards, they discovered that rule-based attacks on wordlists were slower than brute-force attacks on some algorithms. They were also just slow compared to other similar-spec cards from AMD. Obviously, wordlist and rule-based attack speeds depend on how many hashes you have, and how many wordlist candidates are keeping the GPU's busy. However, even when properly optimized, and due to OpenCL constraints, the speed of Maxwell GPU's in wordlists+rule modes lags behind their AMD cousins.

Until now that is.

Thank's to a recent tweak by atom (Hashcat's developer) we are enjoying a major speed boost for Maxwell-based cards. The tweak was a work around for how OpenCL is used by Hashcat with Maxwell-based Nvidia cards.

I have decided to do some benchmarks to show the difference.
the benchmarks were done using;

• 1 SHA256(p./s), MD5, NTLM & PHPass Hash
• A 1GB wordlist to ensure that all GPU's are 100% utilized during our measurement run.
• The d3ad0ne.rule ruleset that ships with Hashcat
• A timer of 60 seconds to let everything settle and run.
• No reboots, no driver changes, no extra Hashcat settings (all on automatic).
• 4 measurements of speed during the 60 seconds, averaged to a final speed.

The Benchmarks were done in the following manner;

1. Old Hashcat + 1 980 GPU
2. New Hashcat + 1 980 GPU
3. Old Hashcat + 6 x 980 GPUs
4. New Hashcat + 6 x 980 GPUs

Note: Old Hashcat refers to the version built off Github before 3.10 which is the newly optimized version built from Github.

All the results are published in the graphs below, which indicate the changes:

As can be clearly seen on 1 GPU, NTLM & MD5 have received an awesome speed boost with the new optimization. PHPass and SHA256 (p.s) remained much the same.

Let's look at 6 GPU's...

With 6 GPU's the increase remains the same (which is what we want!) - we see a speed increase for all 6 Maxwell cards doing NTLM and MD5. 

How much increase did we measure?

Clearly, atom's changes have given Hashcat a major boost :) 

Check that 45% speed increase in NTLM on Maxwell cards!

 -- snip --

Atom pushed some more optimization that increases speed although not as much as the initial changes did. For brevity sake and not to redo all the graphs again, below is the table showing the differences between the current optimized version (3.10-611) and the one after that (3.10-620).

--snip--

Your numbers may be higher or lower than mine, given that you can still tweak the utilization, overclock the GPU's or other settings. However, its clear everyone with Maxwell-based GPU's is in for a nice treat with the changes.

You can grab the updated Hashcat from here: https://github.com/hashcat/hashcat OR download the pre-built binaries here : https://hashcat.net/beta/

Happy Cracking! And of course thank you to atom for continually making Hashcat better.

@Rurapenthe0

Research & Hardware by Bitcrack Cyber Security

Keeping Your Cyber Security Posture in Check

As cybercrime becomes more and more sophisticated and wide spread with technology, demand for cyber security services are ever increasing. With this, thousands of cyber security companies have emerged offering all sorts of services using powerful words and brilliant marketing schemes. This can be really confusing to many businesses who want fortify their cyber infrastructure.

All you need to know and fix your cyber security posture in the most basic way are two critical assessments, namely vulnerability assessments and penetration tests.

Vulnerability Assessments

This is a technique of discovering IT security vulnerabilities that hackers use to harm your business.

The goal of a vulnerability assessment is to identify vulnerabilities, quantify their impacts should they be exploited by malicious hackers, chart a risk matrix with classifications based on impact and business value, and mitigating them to reduce the business risk exposure. 

Penetration tests

This is a simulation of an intrusion on your business IT network as a hacker would.

The goal of a penetration test is to identify how a hacker would hack into your business and what kind of harm the attacker can do, for example, reach into your customer database which can cause massive damage to your business and reputation. Not to mention compliance issues in your country. The second goal is to put your security systems through a test of their effectiveness and efficiency.

What should your business start with?

If your IT team has never put focus on security, it is crucial to take on a vulnerability assessment first. This will map out your business’s critical assets to a security risk matrix and determine the current status of your IT infrastructure.

Penetration tests are more effective after a vulnerability assessment. This is because you can not only test your infrastructure but also test all the security measures you have put into place to reduce your risk which you discovered from the vulnerability assessment findings.

Going the next step…

By now, with regular vulnerability assessments and periodic penetration tests, your defenses are quite strong. And you will have a cyber security team in place to maintain the security measures and overall security posture of your business network infrastructure.

Occasionally, it is very beneficial for both your cyber security team and the support staff of your network infrastructure to run a red team-blue team simulation.  A red team-blue team is an offensive-defensive simulation. The blue team comprises of your internal cyber security team, and the red team comprises of an external cyber security team.

The simulation can be run as a planned event or an unplanned event. The latter is always advised as it will test how effective your internal cyber security team are at identifying intrusions and mitigating them from doing more damage.

This will give the business the most practical view as to how much the it can withstand against a fully-fledged cyber-attack. 

-Jayesh Kerai (@secjay)

Not a lot of "yahoo" at YAHOO! - PART II

-snip- update 16 DEC: With the recent announcement of yet another Yahoo! breach, this time in 2013, I no doubt expect that the information below applies to data from 2013, not just the 2014 breach anymore.

Following-on from my previous Blog post, I decided to give more attention to the domains aspect of the Yahoo! data leak.

Side Note: This blog post is not intended to discourage, or force anyone to stop using Yahoo! services. Like any other provider, Yahoo! maintains a high level of security and complies with international laws and best-practices. However, this article does address the issue of data having been leaked in 2014 - which has been confirmed by Yahoo! and tries to provide more insight into persons possibly affected by the leak.

As articles like the one on CNN Money (click here) state, many people may have Yahoo! accounts without even knowing it. A prime example is email hosting that Yahoo! allows you to do via their business email services. This gives you your own email address, while Yahoo! manages all the back-end work.

Similar to how Google allows you to host your domain with Google Apps, Yahoo! allows you to host your domain and thus email and other services with them. What this means of course, is that the login account Yahoo! kept in its database for your "custom" domain was also stolen in the leak.

I decided to do an analysis to see what domains are hosting their services with Yahoo!. The best way for me to achieve this, as someone who loves password cracking, was to use a wordlist of domains - and compare their MX records to see who they host their email with.

My research led me to believe that Yahoo! services for email would point to some or other MX record like the ones below;

• am0.yahoodns.net
• mx-biz.mail.am0.yahoodns.net.

The common pattern there is that am0.yahoodns.net is associated with Yahoo! accounts - in particular email since we are looking at MX records here.

Using a Wordlist, of 560 000 domain names, I set out to find which are hosting their email at Yahoo!. I already knew of some so I used those to also double-check my script's findings. Keep in mind that this is not necessarily a complete list, since my data source was 560 000 domains, not all domains. 

A Python script was written to perform MX lookups on ALL 560 000 domains and log the ones hosted at Yahoo!. The results of my findings are shown below;

Number of Domains using Yahoo! Email Services

My research shows that at least 572 162* domains are using Yahoo! as their email provider, and thus Yahoo!'s web-based account services and portals.
(* Thanks to Royce Williams (@TychoTithonus on Twitter) for the addition of a large number of domains we added to our Checker. )

Country-Domain Breakdown (or other TLD's)

Which countries are using Yahoo! Email for their domains?

.COM's accounted for the most - 461 911 domains.
Following that was .NET's with 44 128 and .ORG's with 36 150.


Note: Only countries with 10+ domains where counted, there are many more in the 1-10 category.

The USA is in the graph below, as there were too many to include with other countries.

Clearly, the .COM market is Yahoo!'s major driver in hosted domains.

Interesting findings of domains hosted include Churches, Medical Companies,  a lot of Legal Firms, Online Stores and Pharma companies.

Is my Domain on Yahoo!'s platform?

I did not want to release the list of domains I found to be pointing to Yahoo!'s mail services. So I therefore decided rather to allow user's to be able to search for their domain in my list and see if its hosted with Yahoo!. 

You can do that here : http://yahoocheck.bitcrack.net

If your domain is hosted with Yahoo!, and you used it on or before 2014, there is a chance your data was compromised in the leak.

Conclusion

It is clear, that with the stolen login information, attackers have had 2 years to not only get into @yahoo.com accounts but also a vast array of domains belonging to other companies and organizations. Clearly, a major impact for people and companies  - the impact of which may only be realized much later on. 

-Dimitri Fousekis (@rurapenthe0)

Dimitri is Chief Technology Officer at Bitcrack Cyber Security.

Not a lot of "yahoo" at YAHOO!

-snip- update 16 DEC: With the recent announcement of yet another Yahoo! breach, this time in 2013, I no doubt expect that the information below applies to data from 2013, not just the 2014 breach anymore.

There is little on the "oh no!" scale that can beat waking up to hearing that over 500 million user accounts have been compromised on a very popular portal.

Unfortunately for YAHOO! such is the case. Well, such was the case - in 2014 - when the breach supposedly occurred. Comments from the company seem to indicate that there was an idea, albeit not confirmed, that there might have been a compromise, but until now it was not cast in stone. As of yesterday, YAHOO! has confirmed that the breach did in fact occur, real data was stolen and that data can/could include email addresses, passwords (hashed), address information, telephone information and so forth.

The prime suspect appears to be a nation state actor, or actors. Until more information on this becomes evident however, it may not be wise to start pointing at possible targets.

What we want to focus on, is the passwords aspect of the breach. The passwords were hashed using the bcrypt algorithm, although some information coming forward indicates there may be mixed hash types - possibly from imported/merged sites that YAHOO! took over. Either way, the majority are bcrypt according to YAHOO!.

Bcrypt, based on the Blowfish cipher is no small fish when it comes to password security. It is harder to crack (especially with brute-force techniques) than many other widely used hash algorithms, and it is generally very "slow" to attack as it is not efficiently processed by GPU-based cracking software.

Of course, the real matter is not so much the algorithm but the passwords. Bcrypt may be slow to crack,  but if passwords like 123456 or password1 are in use, they are going to fall pretty quickly when cracked, Bcrypt or not. At 500+ Million hashes - assuming all accounts had a hash - there are going to be a lot of "easy" passwords.

So what is an "easy" password for YAHOO!? Let's examine their password rules from around 2015;

Note: I obtained this information from YAHOO! help sites, and other sources. If incorrect please let me know.

Password Length : Minimum of 8, Maximum of 32
Complexity : No plaint-text only,  requires mixed alphanumeric.
Password History : Yes, cannot use previous.
Password Tip : "Mix up lowercase & uppercase letters, numbers and symbols to create a strong password (instead of a weak one)."

From the above, a few things are clear. Firstly, YAHOO! is not the worst candidate for user password requirements out there. Secondly, they avoided and checked for plain words so hopefully, "password" will not account for hundreds or more of the passwords in the leak once cracked.

However, where the above requirements do fall a bit short is;

• A minimum password length of 8 should really be at least 9 or higher. 
• Their "tip" says use lowercase, uppercase, symbols, numbers etc - however their password verification only checked if you had used alphanumeric. i.e, instead of )ThE00Big#BrownFOX$ you would be allowed to use thebigbrownfox1
• A maximum of 32 characters may not fit the needs of those using Password managers such as 1Password that can do much higher candidates, and allow one to have high levels of complexity in their password. 

Given the above, we therefore are expecting to see some passwords being cracked in the leak as;

[email protected]

[email protected] (or [email protected] etc)

Password1 (or 2 or 3 etc...)

yahoo123 (or other triple-digit)

and so forth..

The other risk we are expecting to see realized is that people who shared their passwords amongst a few sites will still be using them there, allowing attackers to "script" scanners to try their credentials on other popular sites. 

Additionally, since the YAHOO! account was probably used for email, the entire account and probably the same password could have been used by many  to register on other sites. 

The result for YAHOO! ? I think Per Thorsheim puts it well in this excerpt from CNN Money:

"This is massive," said cybersecurity expert Per Thorsheim on the scale of the hack. "It will cause ripples online for years to come."

Our view?

"Please assume the brace position!"

-Article by Dimitri Fousekis, Bitcrack Cyber Security  t: @rurapenthe0

Defence in Depth - Security or False Comfort?

Defence in Depth has been an information assurance approach used for many years to protect networks and systems within ICT environments.

In short, it involves adding multiple layers of security around your “core” protected system/environment so that attacks can be fended off as attackers meet these layers one after the next.  Should a control fail to protect a system, another control is there to prevent further attacks. It was introduced by the NSA and has been used by many companies in the past, and of course the present.

However, does DID (Defence-in-Depth) protect against hackers? Does it even slow them down?

This question is asked a lot because many companies that have implemented this kind of security approach found themselves to be hacked, or had breaches and other security-related problems.

Like any security methodology or process, DID has to yield to certain business requirements in order to be an enabler of business (this is a topic for another blog post, but suffice it to say, Security has to be a business enabler, not just a defender of business from risks).

In the process of enabling business, certain facilities have to be implemented for DID to allow business services to be properly provided. For example, for a user to access a website with an accounting system, that user needs access to the website. So, a firewall rule is created to allow users to access the web application. Now, for the web application to work – it needs to see the Database server behind the DMZ (see Google), as such access is opened for the web server to see the database server. Layer by layer we grant access to various systems for them to work together properly.

I wont go into more detail but you get the point? Our sphere of protection with its layers of defence in depth, now has a sharp “needle” put into it to the core to allow business to operate. This is not a problem, since of course the company’s security would be useless if it did not enable business systems to function for the company.

However, think of an attacker now. The attacker has access to the same website as “normal users”. Say this hacker finds a vulnerability to exploit in the web application that is available on the internet.

The hacker starts to exploit functions on the web application to access the database within the company. Defence in Depth is no longer a viable method of protection because as we mentioned above, we have opened a hole between the layers for our systems to work. The hacker thus is able to exploit the database and steal data via the web application front-end – all the while the company had a Defence in Depth approach.

The short fact is, trusted paths have to be carved into your DID implementations for business functions and other IT functions to operate. And it is through these methods that attackers attack your systems.

In conclusion, DID should be viewed as a piece of a much larger pie. It cannot be viewed as a check-box approach that guarantees security. In fact, it is an approach that should form a foundation towards a tailor-made solution that is implemented to suit your needs – both security, and business.

Add Defence in Depth to your overall strategy, but do not rely solely on it. Cyber Security is an ever-changing, evolving and granular entity that needs the correct input and advisory partners to make it work.

We operate in various countries globally. Contact us for any Cyber Security related needs such as Architecture, Advisory, Ethical Hacking, Threat Intelligence and more.

Mac fix for Bash Shellshock

NOTE: Apple have released their own patch now, and I highly recommend you use that one. 

It can be found here: http://support.apple.com/kb/DL1769

No sooner than the dust settled on the first bash bug, have a few more vectors been found. And so the term "Shellshock" has been coined to refer to the recent spate of vulnerabilities affecting bash.

Unfortunately, MacOS (Mavericks) is not immune to this and the version of bash included with your installation is also vulnerable. I'm confident Apple will patch it soon, but incase you want to get it quickly patched ASAP you can follow the steps below to do so.

NOTE: If you don't have Xcode, you will need it to compile the replacement bash, and its a LARGE download. Be aware of this before proceeding.

Thanks to Loïc for the steps which I've tested and work fine.

• mkdir tmp && cd tmp
• curl https://opensource.apple.com/tarballs/bash/bash-92.tar.gz | tar zxf -
• cd bash-92/bash-3.2
• curl https://ftp.gnu.org/pub/gnu/bash/bash-3.2-patches/bash32-052 | patch -p0    
• cd ..
• xcodebuild
• sudo cp /bin/bash /bin/bash.old
• sudo cp /bin/sh /bin/sh.old
• build/Release/bash --version # GNU bash, version 3.2.52(1)-release
• build/Release/sh --version   # GNU bash, version 3.2.52(1)-release
• sudo cp build/Release/bash /bin
• sudo cp build/Release/sh /bin

Enjoy and adios for now. Keep those hashes cracking!