Friday, November 27, 2015

What Is Pass The Hash Attack ?



I think many of us are aware of the term “Pass The Hash” attack. Some of us have heard protocols like Remote Desktop Protocol are susceptible to attacks like Pass The Hash attack. Let's understand what this attack actually is.


What is Pass The Hash attack?

Pass The Hash Attack is an attack in which the attacker hacks a user's password and breaks into the server or service to steal data or do other malicious activities.

Normally, a user needs to provide for authentication a password, which is converted into a hash using some popular hash algorithm and then is matched with the already stored hashed value in the server. Users passwords are never stored or sent in cleartext format over the wire. Cleartext passwords are never required to complete authentication for a user. And so for an attacker.

So, if an attacker can harvest hash values of passwords and try them to impersonate a user, he can break into the server. In a Pass The Hash attack, the attacker uses this mechanism. In this attack, the attacker uses LM or NTLM authentication, instead of using some brute force mechanism to obtain the cleartext password from its hash value.





What is LM or NTLM authentication?

LM Hash or LanMan Hash or Lan Manager Hash is a compromised hash function that was once the primary hash function for Microsoft Lan Manager or Microsoft Windows version prior to NT. Support for this proticol continued in later versions of Windows for backward compatibility, but it was recommended by Microsoft to turn off the protocol by the administrators. In Windows Vista the protocol is disabled by default, but in some non-Microsoft CIFS implementations it continued to be used. NTLM or NT Lan Manager is the successor for Lan Manager. NTLM is widely deployed even on new systems, to maintain compatibility with older systems. But, Microsoft no longer recommends NTLM in applications.



How is LM Hash computed?

The LM Hash is computed using the methods below:

  • A user gives a password which is restricted to fourteen characters.
  • The user's password is converted to uppercase.
  • The password is encoded in the System OEM code page.
  • The password is null padded to 14 bytes.
  • The 14 byte null padded password is halved into two 7 bytes.
  • Each 7 byte value is used to generate a DES key of 64 bits. Here, one null bit is inserted after every 7 bits, thus generating 64 bits. The null bits are later discarded. Like this two DES keys are generated from two 7 bytes halves.
  • Two DES keys thus generated are used to encrypt a constant key KGS!@#$%”, thus forming two 8 byte ciphertexts.
  • These two ciphertexts are concatenated to obtain the 16 byte LM Hash.




How is Pass The Hash Attack perpetrated


But, does not the attacker need the hash values of the users' passwords to hack the accounts? How do the attackers perform Pass The Hash attack?


Before making such attacks, the attacker harvests password hashes of user accounts. There are number of methods which an attacker normally uses to get the password hashes:

  • An attacker may hack the administrator privileges and obtain the cached values of password hashes from the SAM. But, the default behavior of offline usage of cached hashes can be disabled by the adminitrator. So, this method may not always work.
  • The attacker sometimes dumps local users account database or SAM to obtain password hashes of local users and later use them with local administrative account password hashes to hack multiple sysems.
  • The attacker sometimes sniff the LM or NTLM challenge-response dialogues between the client and server and later brute force the encrypted hash values.
  • The attacker may also dump the credentials of authenticated users stored by the Windows Isass.exe process. In this method, the attacker can obtain hash values of user accounts, not only of local users but also of users of security domain that the machine is a member of.


Mitigation


And now comes the most important question – What is the mitigation?


Actually, there is no single defense against this attack. But, there are a couple of precautions that can be taken.

Use of firewalls, intrusion prevention system, 802.1x authentication, IPSec, antivirus software, full disk encryption etc can prevent this attack. A Windows machine can be limited from storing cached values of user credentials. Principle of least privilege is always useful. Windows systems can be configured not to use LM or NTLM protocols. And last but not the least, Restricted Admin Mode is a new security feature for Windows Operating System introduced in 2014 and it is really designed to make the life of attackers more difficult.


So, be informed about all security vulnerabilities, so that you can prevent your server from attacks in a better way. Stay safe, stay secure !!

Sunday, November 22, 2015

How does HTTPS work ?



Nowadays, many servers are relying on HTTPS. Along with secure transactions, many web servers are using HTTPS for browsing also.

This raises a question in our mind. Why HTTPS and how is HTTPS more secure than HTTP?







What is HTTPS 

When we type URL in the browser, an HTTP request goes to the server and the server responds with appropriate HTML page. Now, HTML is a stateless protocol. This means, everytime the browser wants some data from the server, a new connection is established to the server and the client waits. The server sends response and closes the connection.

If we think about security, HTTP is an unsecure protocol. When data travels between the client and the server, it is unencrypted and as a result, not safe from Man In The Middle Attack. And so, HTTPS was developed.

This HTTPS uses SSL/TLS for security.


So, what does it mean?

That means, all data transferred between the server and client gets encrypted first. First, a TLS connection is established between the server and client and a key is negotiated between them. And then, all data is encrypted with the key and sent over.


How does HTTPS work

So, how does HTTPS work actually?

When a URL is typed in the browser, the server is connected. When a server supports HTTPS, it generates a public-private key pair and keeps the keys with itself. So, whenever a connection is requested to the server, it sends the public key of the key-pair to the client.

The client receives the public key of the server and verifies the authenticuty of the server's public key with a Certificate Authority. This step is done so that someone malicious cannot forge the public key of the server and send its public key instead.

After the public key is verified, it is time for the server and the client to negotiate a symmetric key using which they can encrypt the data and send over. Using symmeteric key along with encrypting it with the public key of the server ensures more security.

Here, the server and client uses Diffie-Hellman Key Exchange Algorithm to make sure a symmetric key is negotiated between the server and client, yet the key itself is never communicated directly between them. Instead, some mathematical formula is used between them to derive the key.

Once the symmetric key is derived, next the job is simple. Whenever any data communicates between the server and the client, the data is encrypted first with the symmetric key and then with the public key of the server and then communicates between them.


How secure is HTTPS

So, here comes the immediate next question, how secure is HTTPS?

It is pretty secure. Even if somene malicious intercepts the connection or performs Man In The Middle Attack, he will not be able to decipher the packets.

So, if you search something in Google, the attacker will probably know that you are having some activity in Google Search, but he won't be able to decipher what you are searching there.

So, this was just an informational blog. Stay safe, stay secure!!




Tuesday, November 17, 2015

SFTP vs FTPS



FTP or File Transfer Protocol is a standard network protocol, which is used to transfer files from one host to another host over internet.



Security concerns of FTP


FTP is normally widely used. But security is a big concern for it. FTP was not created to be a secure protocol. The traffic between two hosts are transferred unencrypted in FTP. Even the username and password transferred is also too unsecure to be sniffed by a third party. So, this protocol is very much vulnerable to sniffing or spoofing attack. So, use of FTP is deprecated in modern time for security concern.






SFTP vs FTPS


FTP over SSH or SFTP is one way of making FTP protocol more secure. In this protocol, a normal FTP session is tunneled over a Secure Shell connection. As a result, data transferred between two hosts are encrypted making the protocol more secure. In SFTP, data transfer is packet based, instead of text-based. Also, data is transferred over the main control connection, instead of opening a seperate data connection. In fact, there is very little common to FTP and SFTP.



FTPS is an extension of FTP. It adds support for the SSL/TLS cryptographic protocols. In this protocol, normally a Transport Layer Security is established from the beginning of the connection. There are normally two types of FTPS – implicit and explicit.

In case of implicit FTPS, the client is expected to send TLS ClientHello message at the beginning of the connection and if it fails, the connection is dropped.

In explicit FTPS, the client is expected to explicitly ask for security. If it fails to ask, it is up to the server to continue in the unsecure more or drop the connection.

Once a TLS connection is established, the data transfers between the hosts in encrypted manner.

In terms of security, both SFTP and FTPS are good. But, compatibility is a big concern for SFTP.


Saturday, November 7, 2015

How Does SSH Work?




If you are working remotely, especially if you have different servers and you want to login to those servers and work on their shells, rlogin, ssh etc are the options you can take.



SSH :

SSH is a network protocol that allows remote login and other network services to operate securely over an unsecured network. It was designed basically as a replacement of telnet and other unsecured remote login shell protocols like rsh, rlogin etc.







How is SSH different from others

So, the next question is, how is SSH different from other unsecured remote login shell protocols?

In an unsecured remote login shell protocols, when the server and the client transfers data between them, it is done in an unsecured fashion. So, it is not secure from eavesdropping. In SSH, all the communication between the server and the client is done using encryption and authentication. As a result, data integrity and data security is maintained properly.



How does SSH work


In modern days, mostly we use SSH version 2.

Here is how it works :

SSH uses public key cryptography initially to allow the client to verify the server's authenticity and then to exchange a symmetric key between the server and the client. Later, this symmetric key or session key is used for the rest of the secure communication.


In public key cryptography, a public and private key pair is used for secure communication. So, when a client first communicates with the server, the server sends his public key to the client. The client then verifies the authenticity of the public key of the server with a Certificate Authority.


After that, the server and the client communicates with each other to share a symmetric key between them. To make sure, this communication is secure enough from eavesdropping, Diffie-Hellman key exchange algorithm is used. Please look at this article to know how does Diffie-Hellman key exchange algorithm works.


Once a symmetric key is established between the server and the client, now it is time to authenticate the client to the server. Several mechanisms can be used for this purpose. Password authentication is one such option.


In case of password based authentication, the client sends to the server a password encrypted with the symmetric key. The server verifies it and allows the client for further communication.


But, because of vulnerability regarding password strength etc, this is not a very good option.


Public key cryptography again can be used for this purpose.


In that case, the client first generates a public-private key pair and sends the public key and its key id to the server after generating it. At the time of communication, the client again sends a key id to the server after the symmetric key is established successfully between them.


The server checks the key id and tries to find out a corresponding match of public key from the stored public keys. If a match is found, then the server generates a random number and sends the random number encrypted with the public key of the client.


The client will possess its corresponding private key. So, it will decrypt the random number, and then send a MD5 hash of the random number, encrypting with the session key.


The server now calculates the MD5 hash of the random number it sent and verifies with the bytes it got from the client, decrypted with the session key.


If both the values match, the authenticity of the client is successful. And now, the server and the client can communicate with each other securely, with data encrypted with the session key established between them previously.



So, this is how SSH works and how it is more secure than other unsecured remote login shell protocols. Hope you liked the article.