Thursday, March 31, 2016

What is DNSCrypt ?



When we type a URL in the address bar, our computer contacts the DNS Servers to get the corresponding IP address of the website. Normally, these DNS queries are unencrypted. So, attackers can intercept this process of Domain Name Resolution for various malicious purposes like Man-In-The-Middle Attacks. DNSCrypt is a protocol which is used to prevent those.




Why DNSCrypt ?


DNSCrypt is a network protocol which encrypts the traffic between the systems and the DNS Servers at the time of Domain Name Resolution, so that attackers cannot intercept that.

When we use HTTPS, SSL/TLS or VPN, the browsing traffic in encrypted. The data which is transferred between the servers and the user's computer is encrypted. But, before even establishing the secure connection with the server, our computer needs to resolve the IP address of the website using a DNS query and the connection between our computer and DNS Servers are normally not encrypted.

So, an attacker can perpetrate a Man-In-The-Middle Attack to intercept the communication with DNS Servers and use that for malicious purposes.

DNSCrypt uses Elliptic Curve Cryptography to encrypt the traffic between our computers and DNS Servers, making it difficult for the attackers to intercept the traffic.



How does DNSCrypt work ?





In DNSCrypt, both the clients and the DNS Servers first generate short term key pairs. A DNS resolver may have multiple certificates each including a validity period, a serial number, a version to indicate the key exchange mechanism, the encryption algorithm and the short term public key. The resolver can support multiple encryption algorithm and advertise multiple public keys.

When the client wants to resolve an IP address, it starts the DNSCrypt session with sending an unauthenticated and unencrypted DNS query including certificate versions supported by the client and public identifier of the provider.

The resolver responds with a public set of signed certificates.

The client then verifies the public key of the resolver which is already distributed to it. It selects the appropriate certificate.

Each certificate sent by the resolver includes a magic number unique to the public key and encryption algorithm to be used. The client then encrypts the actual query with the client's private key and the resolver's public key and sends it to the resolver.

The resolver decrypts the query with the public key of the client and appropriate private key of the resolver. And, it sends the response, again encrypting it with public key of the client and appropriate private key of the resolver.



How is DNSCrypt different from DNSSEC ?


DNSSEC does not provide encryption of actual DNS records. DNSSEC makes sure that the resolved IP address is an authentic one. But, it sends the response in an unencrypted fashion. DNSCrypt on the other hand encrypts the DNS response with cryptographic algorithm.



Can DNSCrypt and DNSSEC be used together ?


Using DNSSEC and DNSCrypt together is always a better option. By doing that, the client can be assured that the resolved IP address is the authentic IP address of the website. And, as the response is encrypted, the attackers cannot perpetrate any Man-In-The-Middle Attack there also.


So, beware of various security features, so that you can protect yourself in a better way. And, stay safe, stay protected.



Wednesday, March 30, 2016

S/MIME vs PGP


SMTP or Simple Mail Transfer Protocol was first developed in 1982 and at that time it had very few security features. As a result, we gradually needed to make email communications more secure. We wanted features to digitally sign, encrypt and decrypt emails. S/MIME and PGP (actually OpenPGP) are two standards that are developed for that purpose.





What is S/MIME ?


S/MIME is a standard which uses Public Key Cryptography to digitally sign, encrypt or decrypt emails.

The user first obtains a public-private keypair from a centralized trusted authority. The private key is kept secret with the user and the public key can be distributed with others.


At the time of digital signatures, the use has to sign the email with his private key and send it across. As the email is signed with the private key, the recipient will be able to verify the signature if the recipient has the sender's public key. In fact, anyone having the sender's public key would be able to verify the signature. But, as the private key is kept secret with the sender only, no one else other than the sender would be able to modify the original email.


And, if the user wants to send some secret message to a recipient, the sender would have to encrypt the email with the recipient's public key. As the private key is kept secret with the recipient, no one else other than the recipient would be able to decrypt the email.


And, if the email is signed with the sender's private key as well as encrypted with the recipient's public key, then only the recipient would be able to read the secret message after decrypting the message with the recipient's private key. And, at the same time, no one else other than the sender would be able to modify the original message.


In S/MIME, a user has to obtain his public-private keypair with a trusted authority. And, after receiving the keys, he has to use them suitably with the email application.



PGP


OpenPGP is another standard that can be used to digitally sign, encrypt and decrypt emails. PGP is a commercial program which is developed as per OpenPGP standard. Some people though prefer to use GPG which is an open source version of PGP made by GNU.

PGP also uses Public Key Cryptography to sign, encrypt and decrypt emails. So, in PGP also a user has to use his public-private keypair for signing, encryption and decryption of emails similar to S/MIME. A sender has to sign the email with his private key and the sender has to send an encrypted email to a recipient encrypting it with the recipient's public key.

So, you can say, S/MIME and PGP are very similar in one aspect – both of them use Public Key Cryptography to sign, encrypt and decrypt emails.



Difference between S/MIME and PGP


From a user's perspective, S/MIME and PGP are different in the way a user obtains his keypair. In S/MIME the user has to obtain his keypair from a trusted Certificate Authority. And, if someone wants to verify whether a public key is indeed the sender's authentic public key and is not forged by some attacker, he needs to verify it with the trusted authority and then use the key.

On the other hand, in PGP there is a concept of signing a keypair. Every user needs to sign his own keypair as well as of others with whom the user wants to communicate. Signing a key vouches for the authenticity of the public key. 

For example, if Alice is sure that a public key belongs to Bob and no one else, she would sign that public key. If another user Charlie wants to verify the authenticity of Bob's public key, Charlie can look at whoever has signed that particular public key. If Charlie knows Alice, he would be able to see that Alice has signed the public key, which in turn would increase the trustworthiness of the key. Moreover, while verifying someone else's key, one can indicate his trust level on that key by specifying four levels of trust (full, marginal, none, unknown). So, one does not need any trusted central authority to verify a public key.


So, to summarize, both S/MIME and PGP use Public Key Cryptography, yet both are two different standards. The main difference is S/MIME depends on a centralized trusted authority for verification of public keys, but PGP does not need that.


So, be informed about various security features and how you can use them, so that you can protect your data in a better way. And, stay safe, stay secured.





Tuesday, March 29, 2016

Petya Ransomware



Petya Ransomware is a ransomware which infects a victim's machine mostly via an email attachment and affects the Master Boot Record or MBR and Master File Table or MFT of the system. It also encrypts the files in the system and asks for a ransom of 0.99 Bitcoins from the victim to recover the encrypted files.




Infection of Petya Ransomware


Petya Ransomware mostly infects a system via an email attachment. As per most of the reported cases, the victim first receives an attachment of an email which seems to be from some applicant seeking for a job position. The attachment contains a link to Dropbox storage location, which purports to be the CV and photo of the applicant.


But, the downloadable file actually contains an executable script and the photo seems to be a stock image most likely used without proper permissions of the photographer.


On downloading the archive, a malicious trojan starts executing. The trojan first rewrites the MBR of the system.


An MBR or Master Boot Record is an important data structure in the disk which contains a small amount of executable code called boot loader. At the time of system start, the boot loader eventually loads the installed Operating System in the system.


After rewriting the MBR, the malware triggers a critical Windows error and reboots the system.


On rebooting the system, the malware shows a fake Windows check disk operation. It purports to be correcting hard disk errors, but what it actually does is encrypting the MFT of the system.


MFT or Master File Table of a system is a file which contains information on every file in the file system. The information includes size, time, date stamps, permission, data contents etc. Without this MFT file system cannot access any file from the file system.


There is a trick here. If the attackers had chosen to encrypt the whole file system, it would have taken lots of time, which the attackers might not have. So, they encrypted the MFT instead which is less time consuming. And, it solved their purpose of making the file system inaccessible to the victim.


After the encryption is done, the malware displays a ransom message of 0.99 Bitcoins which is worth about $430. It also displays a skull drawn with ASCII characters.


The attackers also display on the screen the specific instructions on how to pay the ransom. The decryption site looks to be professionally designed and it says the ransom amount will be doubled on missing the said deadline.


Please note that, as the MBR gets overwritten by the malware, it does not allow the system to restart in safe mode.


Countermeasure

If your system is affected by Petya Ransomware, never ever pay ransom to the attackers. Paying the ransom does not at all guarantee the retrieval of the encrypted data. And, extorting ransom from the victims is the main motivation of the attackers behind these attacks. Acceding to their demands will only worsen the situation.

There are a number of anti-malware programs that are providing solutions. Please make sure to take help of those.

And, please be careful about opening email attachments from unknown senders or downloading any software from untrusted sources.



So, beware about various malware programs and how to fight with them, so that you can protect your systems in a better way. And, stay safe, stay secured.

Monday, March 28, 2016

What is ShellShock ?



ShellShock is a security vulnerability which affects many versions of Unix like Operating Systems like Linux and results in allowing attackers to gain control over a system illegitimately.


ShellShock Vulnerability





In Unix, Shell is a command processor using which commands are executed in the Opetating Systems. Bash is one such command processor. It is mainly used in text windows, but many applications also can use it to execute required commands.

Environment Variables are variables whose values are used to affect the way the running processes will behave in the computer. For example, an application process may prefer to store temporary files in a folder. For that purpose, the running process will check the value of the Environment Variable called TEMP and store the files there.

Using ShellShock vulnerability, an attacker can attach malicious code to some Environment Variable in Bash and run it to gain control over the system.



Consequences


Many a times Web Servers use Bash to execute commands. So, the attackers can exploit this vulnerability to execute malicious commands in a Web Server. And, the results of that may be as serious as exposing sensitive files like password files to the attackers or downloading malicious files to the Web Servers.


Even other devices like Linux based routers that use CGI for Web Interfaces are vulnerable to tthis attack. Attackers can exploit ShellShock vulnerability and use CGI to execute malicious commands in those devices.


IoT (Internet of Things) devices also may be vulnerable to this attack if they are using Bash.


OpenSSH Servers are also vulnerable to this attack. Attackers can gain unrestricted shell access of the server exploiting ShellShock.


Other than that, Computers running Mac OS X, DHCP Clients, Qmail Server and IBM HMC restricted shell are also vulnerable to this attack.



Prevention


There are a number of reports of exploitation of this vulnerability by the attackers. But, the good news is that a number of Operating Systems vendors who are affected by this vulnerability have already issued patches. Website owners and business owners should apply those latest security patches to their Operating Systems to avoid ShellShock Attack.


However, users are also advised to apply recent security patches for their web enabled devices like routers, IoT devices and embedded devices etc to prevent this attack.


So, beware of various security vulnerabilities, so that you can protect yourself in a better way. And, stay safe, stay secured.

Sunday, March 27, 2016

SMTP Strict Transport Security


SMTP or Simple Mail Transfer Protocol was first developed in 1982 and at that time it had very few security features. Though at that time there was not much concerns, later it became a major security concern. And, SMTP STS or SMTP Strict Transport Security is a policy which is developed for addressing security concerns of SMTP like TLS Downgrade Attacks and DNS Hijacking while transporting emails between mail servers.



Security Concerns of SMTP


As said above, SMTP has very few security features, resulting in some major security concerns. TLS Downgrade Attacks and DNS Hijacking are two major security concerns that makes email transport quite vulnerable.

Let's discuss in brief how these two attacks make email transport so vulnerable.



TLS Downgrade Attack


When a source Mail Server wants to send an email to a destination Mail Server, the communication is not by default encrypted. A STARTTLS command is sent first and then, when both the Mail Servers agrees on STARTTLS command, they go ahead and establish a TLS connection between them to transfer the email. Otherwise, the email is sent in cleartext format.


In TLS Downgrade Attack, the attacker first perpetrates a Man-In-The-Middle Attack and changes the STARTTLS command transferred between the Mail Servers. As a result, both the Mail Servers are tricked to believe that the other one does not support TLS. And the email is transferred in cleartext format, following which the atacker is now free to steal sensitive data transferred over the email communication.

You would find more information on how TLS Downgrade Attacks are perpetrated while transporting emails here : TLS Downgrade Attacks while transporting Emails



DNS Hijacking


The source Mail Server needs to know the IP address corresponding to the destination Mail Server before transferring the email. For that purpose, the source Mail Server makes a query to the DNS Servers and fetches MX record containing the said IP address.

But, attackers can perpetrate a DNS Hijacking Attack at that time and trick the source Mail Server to obtain a fraudulent MX record containing the IP address of the attacker controlled Mail Server. As a result, the source Mail Server ends up sending the sensitive email to the attacker's Mail Server, following which the attacker can steal sensitive data and transfer the email back to the actual destination Mail Server to make the attack transparent.

You would find more information on how DNS Hijacking Attacks are perpetrated while transporting emails : DNS Hijacking Attacks while transporting Emails



DANE


DANE or DNS-based Authentication of Named Entities is a protocol which is developed recently which can address the above security concerns of SMTP, though it has some other concerns.


In this protocol, the source Mail Server makes a DNS query to obtain TLSA records from the DNS Servers before sending the email. TLSA records are a new DNS resource records that contains information on the digital certificate or the Certificate Authority which are used in the subsequent TLS connection between the source and destination Mail Servers.

So, the source Mail Server first obtains the TLSA records from the DNS Servers and then validates the records using DNSSEC. In DNSSEC, responses from DNS Servers are validated with digital signatures and cryptographic keys. As it will not be possible for attackers to duplicate cryptographic keys and affect DNSSEC responses, DANE can address the above security concerns of SMTP up to a great extent.

You would find more information on how DNSSEC works here : DNSSEC



SMTP STS


Though DANE can address the major security concerns of SMTP up to a great extent, it may not prove to be much convenient.

DANE requires DNSSEC for the secure delivery. But, implementation of DNSSEC is quite compex and its adoption is quite slow. And, to address those concerns a new protocol called SMTP STS is very recently developed.

SMTP STS or SMTP Strict Transport Security is a policy that ensures secure SMTP sessions over TLS. It presents a variant for systems which do not yet support DNSSEC. It also specifies a method for reporting TLS negotiation failures while establishing a TLS connection between the Mail Servers.

The main difference between DANE and SMTP STS is, DANE requires DNSSEC to authenticate DANE TLSA records. But, SMTP STS relies on the Certificate Authority system to avoid interceptions.



How does SMTP STS work






When an email is sent from source Mail Server to destination Mail Server, it typically follows the following steps :

  • The source Mail Server makes DNS query and obtains the TXT record and MX record of the destination Mail Server. The TXT record contains information on the SMTP STS policy of the destination Mail Server. And, the MX record presents its TLS certificate.
  • The next step for the source Mail Server honoring SMTP STS policy is to fetch and validate the policy.
  • If the TXT record specifies DNSSEC, the source Mail Server should retrieve the policy via DNSSEC.
  • If the TXT record specifies Web PKI, the source Mail Server should establish an HTTPS connection to a specified host at the domain matching that of the destination Mail Server. The HTTP response body thus obtained must match the policy initially loaded by via the DNS TXT method.
  • The next step is policy validation. For Web PKI, the certificate presented by the MX reecord must be valid for the MX name and chain to a root CA that is trusted by the source Mail Server.
  • Otherwise, DANE TLSA is used to validate the certificate.
  • Aggregate statistics on the policy failure may be reported to a specified URI for diagnosis.



Security of SMTP STS


As discussed above, SMTP STS relies on proper validation of the policy and the certificate. As the chances of compromising a Certificate Authority is considerably less, it becomes quite difficult for the attackers to intercept the connections and make attacks.


This was an informative article on SMTP STS and how it helps to address some major security concerns that SMTP has. Hope it helped.



Reference :

https://github.com/mrisher/smtp-sts/blob/master/spec.txt

Friday, March 25, 2016

TeslaCrypt Ransomware



TeslaCrypt is a ransomware which infects a computer mostly with some specific games installed and encrypt important files. And then, it extorts a ransom of $500 in order to obtain the secret key for decrypting the encrypted files.


The ransomware was first detected in August 2015 and till then, it has infected and still infecting many computers.





How does TeslaCrypt infect a computer


Most of the TeslaCrypt attack involves spam emails. Attackers first send spam emails to victims and use social engineering to convince the victims to open the email.

The subject line of the email may contain :

  • [ID:{RANDOM NUMBER}] Would you be so kind as to tell me if the items listed in the invoice are correct?
  • [ID: {RANDOM NUMBER}] Please accept our congratulations on a successful purchase and best wishes.
  • [ID{RANDOM NUMBER}] Would you be nice enough to provide us with a wire transfer confirmation.

The spam emails contain attachments which may have a .zip extension, but it actually contains a malicious JavaScript file.

On opening the attachment, the malicious JavaScript code starts execution and infects the computer with TeslaCrypt ransomware.


Upon infection, the ransomware searches for a list of files with some specific extensions, which are mainly involved in saving data, player profiles, custom maps and game mods, and encrypt them. The newer variants of TeslaCrypt are not focused on computer games only, and can encrypt files including Word, PDF and JPEG.

TeslaCrypt encrypts important files with AES symmetric keys and asks for a ransom of $500 worth of Bitcoins to get the secret key to decrypt the encrypted files.



Financial gain of attackers of TeslaCrypt


Attackers buy TeslaCrypt ransomware from underground blackmarket. They pay the TeslaCrypt authors and access various distribution channels like spam botnets or exploit kit.

After that, the attackers employ various attack methods to distribute the malware and infect computers. And upon infection, they extort money from the victims.



Is TeslaCrypt same as CryptoLocker


Though TeslaCrypt resembles CryptoLocker in function, but TeslaCrypt is quite different from CryptoLocker. TeslaCrypt shares no code with CryptoLocker and it is developed quite independently. So, TeslaCrypt is not same as CryptoLocker.



Prevention


TeslaCrypt decryption key is already published. So, if you are already affected by TeslaCrypt, you can retrieve your files using the key.

And, we can always take a couple of steps to safeguard ourselves from any ransomware like TeslaCrypt :

  • Do not open email attachments if you are not very sure of the sender of the email.
  • Do not click on suspicious links.
  • Download software only from trusted source.
  • Keep your computer updated with recent anti-malware programs from some trusted sources.
  • Update commonly used software with recent security patches. Most of the time, attackers infect a computer with a malware exploiting security vulnerabilities of commonly used software in the computer.
  • Take regular backups of your important files.
  • And, if you are infected with any ransomware, never ever pay ransom to the attackers. Instead, look for some good anti-malware programs to remove the ransomware and retrieve the data. Because, extorting money from the victims is the main motivation of the attackers behind making these attacks. So, paying ransom to them will only make the problem worse.


So, beware of various malware and how to prevent them. And, stay safe, stay protected.


Heartbleed



When two hosts share sensitive data between them, the communication must be encrypted. And, SSL/TLS is used for that purpose.

OpenSSL is one of the most common implementations of SSL/TLS. And, Heartbleed is a newly discovered security vulnerability in OpenSSL which enables attackers to steal sensitive data like login credentials, personal data or even decryption keys that are communicated over SSL/TLS.



Heartbleed Security Vulnerability


When two hosts communicate over TLS, the session must be kept alive upto a certain amount of time, even if no real communication has happened in that time. This saves the users from re-entering his login credentials again and again, if the session terminates in the middle.

Heartbeat is an extension of TLS protocol which is used for this purpose. Using this extension, the TLS session between two hosts are verified.

In Heartbleed, attackers exploit security vulnerability present in the Heartbeat extension to steal sensitive data transferred over TLS.



How do attackers exploit Heartbleed





As said above, Heartbeat extension verifies that both the hosts communicating over TLS are still connected and available for communication. For that purpose, Heartbeat sends a message to OpenSSL server and the message is then relayed back to the sender.

This Heartbeat message contains mainly two components – information on the payload size and the actual payload. This payload can be up to 64 KB in size.

But, in Heartbeat, there is no check made to verify whether the actual payload size is same as the payload size actually mentioned. And, attackers take advantage of this vulnerability to perpetrate attacks.


Supppose, an attacker spoofs the information on payload size and indicates it to be 64 KB, even though the actual payload is on size 1 KB only.

As the Heartbeat extension does not verify the information, the server would receive 1 KB of payload data, but in return it would send back to the other host 64 KB of data. It would send 1 KB of data it actually received, along with 63 KB of data stored in adjacent memory. And, that 63 KB of additional data may contain sensitive data like login credentials, personal data or even decryption keys.



How does Heartbleed pose a threat


It is quite possible that, the attacker may initially receive no useful information in the additional 63 KB of data. But, if the attackers exploit the vulnerability again and again and make repeated attacks, it becomes highly probable that the attacker would get enough sensitive data.



Countermeasures


We can take a couple of steps to safeguard us from this attack :

  • Version of OpenSSL should be upgraded to the latest available version.
  • After upgrading the OpenSSL version, if you think webserver certificates may have been compromised, contact the certificate authority for a replacement.
  • If you think, you may have been attacked, reset the end-user passwords.
  • Avoid responding to potential Phishing emails asking for resetting passwords. Instead, stick with the official site domain.
  • Monitor your bank and credit card statements to check whether any unusual transactions are made.



SPF, DKIM and DMARC in Prevention of Email Spoofing


Email Spoofing is common nowadays. Cyber criminals often send emails to victims spoofing the emails by forging some other email addresses, and sometimes forging email addresses of someone well-known to us. They often do this for Phishing or spreading malware. SPF or Sender Policy Framework, DKIM or DomainKeys Identified Mail and DMARC or Domain-based Message Authentication, Reporting and Conformance are three technologies using which we can detect as well as prevent Email Spoofing.


Let's understand how they actually help us in detecting and preventing Email Spoofing.



SPF or Sender Policy Framework





SMTP or Simple Mail Transfer Protocol was first developed in 1982 and at that time it had very few security features. Though at that time there was not much concerns, later it became a major security concern. And, we needed mechanism to counter the security concerns. SPF or Sender Policy Framework is an extension to SMTP which is developed to counter the security concerns of Email Spoofing.


When an email is sent from one email address to another, the mail server corresponding to the sender's email address or the source mail server first resolves the IP address of the mail server corresponding to the receiver's email address or the receiving mail server.


This is done through MX or Mail Exchanger records of the DNS. When the sending mail server makes a DNS query for the IP address of the receiving mail server, corresponding MX records containing the IP address of the receiving mail server is fetched from the DNS Servers.


In SPF, a reverse MX record is published in the DNS Servers by the mail servers. As a result, whenever a receiving mail server gets an email from a sender, it checks the SPF records with the DNS Servers and verifies whether the sender of the email is an authorized person to send email from the corresponding domain.


In SPF, the domain owners publish a list of IP addresses or subnets that are authorized to send emails on their behalf. So, if the SPF records corresponding to the received emails do not match with authorized email addresses, the receiving mail server can detect that the received email is a spoofed one and takes proper steps.



DKIM or DomainKeys Identified Mail





DKIM or DomainKeys Identified Mail is another technology using which one can detect Email Spoofing. Unlike SPF, DKIM uses digital signatures to detect spoofed emails.


In this technology, the sender of the email signs the email with digital signature using his private key and that signature is added to the message header. And, the public key is published in the DNS Server.


So, when a recipient receives an email, the corresponding public key of the sender is fetched from the DNS Server and the digital signature is verified. If the verification is not successful, that would mean the email is a spoofed one.



DMARC or Domain-based Message Authentication, Reporting and Conformance


DMARC or Domain-based Message Authentication, Reporting and Conformance is another technology using which the recipient can detect as well as prevent Email Spoofing.


In DMARC, both SPF and DKIM is used in conjunction to detect and prevent email spoofing.


On receiving an email, first the SPF record of the domain is verified to see whether the actual sender is authorized to send emails from the domain. And then, using DKIM the digital signature contained in the header of the message is verified with the public key of the sender received from DNS Server.


If both the verification is successful, that would mean the sender of the email is an authorized person to send the email. If either or both the SPF and DKIM verification fails, that would mean the email is a spoofed one.



How to enable SPF, DKIM and DMARC


SPF, DKIM and DMARC can be enabled by the domain owners easily. One needs to follow instructions as given by the domain-host/webhost provider.



So, beware of security threats and the techniques to prevent them. And, stay safe, stay secured.