Tagsecurity

PETYA Crypto-ransomware

Till now we have heard of ransomware’s targeted computers files will be encrypted, in this scenario users are allowed to login to the Operating System but won’t be able to open encrypted files. The newly discovered PETYA Crypto-Ransomware has crossed one more step and it overwrites the MBR itself to lock users out of their computers.

Petya is still distributed via email. Victims would receive an email tailored to look and read like an applicant applying for a job in a company. It would present users with a hyperlink to Dropbox storage location, which would let users download the above said user’s CV.

The file downloaded is actually a self-extracting executable which will unleash the trojan into the system.

Once executed, Petya overwrites the MBR of the entire hard drive, causing windows to crash and display a blue screen. When the user tries to reboot the system the modified MBR will stop him to boot into the operating system, and will be greeted with an ASCII skull and an ultimatum: pay up with a certain amount of bitcoins or lose access to your files and computer.

Fig1: Petya’s red skulls-and-crossbones warning

petya_ransomware

This modified MBR even disable booting to safe mode also. The user is then given explicit instructions on how to do this, just like any crypto-ransomware currently making the rounds: a list of demands, a link to the Tor Project and how to get to the payment page using it, and a personal decryption code.

Fig 2: Petya’s decryption and ransom payment instructions

petya_figure2

Drown vulnerabilty

Drown stands for Decrypting RSA using Obsolete and Weakened eNcryption, and it provides a way for attackers to decrypt HTTPS communications from servers that are still supporting SSLv2. Most of us think supporting SSLv2 protocol on server is not a problem because most of the modern client software’s just don’t use it.

But looks like the mere existence of SSLv2 help attackers to crack a connection’s encryption, and initiate what is effectively a MITM attack.

drown-1

According to the researchers, a server is vulnerable to the DROWN vulnerability (also known as CVE-2016-0800) if:

It allows SSLv2 connections. This is surprisingly common, due to misconfiguration and inappropriate default settings. Our measurements show that 17% of HTTPS servers still allow SSLv2 connections.

or:

Its private key is used on any other server that allows SSLv2 connections, even for another protocol. Many companies reuse the same certificate and key on their web and email servers, for instance. In this case, if the email server supports SSLv2 and the web server does not, an attacker can take advantage of the email server to break TLS connections to the web server. When taking key reuse into account, an additional 16% of HTTPS servers are vulnerable, putting 33% of HTTPS servers at risk.

drown-illustrated

If you want to check whether a particular site is vulnerable, the researchers have helpfully provided an online tool.

MITM-diag

MITM illustrated

Browser vendors scrapping SSLv3 in wake of poodle attack

With the latest finding from Google researchers , browser vendors are scrapping SSLv3 in wake of poodle attacks.  For more information on poodle attack check this link http://www.technix.in/sslv3-poodle-attack/.

Officials at mozilla has confirmed in a blog post that only 0.3% of https connection with Firefox uses SSLv3. They are planning to remove fully SSLv3 in the upcoming release of Firefox 34 and is expected to be released by November 25. The code to disable it is landing to in the nightly releases. And as an additional precaution, Firefox35 will support a generic TLS downgrade mechanism known as SCSV. if this is supported by the server, it prevents attacks that rely on insecure fallback.

Google security officials said that Chrome has supported the SCSV mechanism since February, but warned that disabling SSLv3 will cause problems for site owners who still support the protocol.

“Disabling SSL 3.0 support, or CBC-mode ciphers with SSL 3.0, is sufficient to mitigate this issue, but presents significant compatibility problems, even today. Therefore our recommended response is to support TLS_FALLBACK_SCSV. This is a mechanism that solves the problems caused by retrying failed connections and thus prevents attackers from inducing browsers to use SSL 3.0. It also prevents downgrades from TLS 1.2 to 1.1 or 1.0 and so may help prevent future attacks,” said Bodo Möller, one of the Google researchers who developed the attack.

“Google Chrome and our servers have supported TLS_FALLBACK_SCSV since February and thus we have good evidence that it can be used without compatibility problems. Additionally, Google Chrome will begin testing changes today that disable the fallback to SSL 3.0. This change will break some sites and those sites will need to be updated quickly.”

Microsoft issued an advisory about the POODLE attack on Tuesday but didn’t announce any specific plans for disabling the protocol in Windows or Internet Explorer. IE 6, an ancient version of the company’s browser, is the only major browser that doesn’t support anything newer than SSLv3.

“This is an industry-wide vulnerability affecting the SSL 3.0 protocol itself and is not specific to the Windows operating system. All supported versions of Microsoft Windows implement this protocol and are affected by this vulnerability. Microsoft is not aware of attacks that try to use the reported vulnerability at this time. Considering the attack scenario, this vulnerability is not considered high risk to customers,” Microsoft’s advisory says.

SSLv3 – Poodle Attack

Researchers at Google has discover a new attack on the SSLv3 protocol, which takes advantage of an issue with the protocol that enables a network attacker to recover the plain text communications of the victim.

The attack is known as POODLE. The technique takes advantage of the fact that when a secure communication attempts fails, servers will fall back to older protocols such as SSLv3, in an attempt to continue communication with the remote client/server. An attacker who can trigger a connection failure can then force the use of SSLv3 and attempt the attack.

The easiest fix for the attack is to disable SSLv3, but that has compatibility implications for browsers especially older ones. Recommended response is to support TLS_FALLBACK_SCSV. This is a mechanism that solves the problems caused by retrying failed connections and thus prevent attackers from inducing browsers to use SSLv3. It also prevents downgrades from TLS 1.2 to 1.1 or 1.0.

This new attacks affects a wide range of software, including OpenSSL.

Firefox is planning to turn of SSLv3.  As per firefox updates there is only 0.3% of https uses SSLv3. An SSLv3 will be disabled by default in Firefox34 which is expected to release on Nov 25.

Bug in Bash shell allow attackers to execute code on Linux, Unix and Mac OSX

A security vulnerability in the GNU Bourne Again Shell (Bash), the command-line shell used in many Linux and Unix operating systems, could leave systems running those operating systems open to exploitation by specially crafted attacks.

The bug, discovered by Stephane Schazelas, is related to how Bash processes environmental variables passed by the operating system or by a program calling a Bash-based script. If Bash has been configured as the default system shell, it can be used by network–based attackers against servers and other Unix and Linux devices via Web requests, secure shell, telnet sessions, or other programs that use Bash to execute scripts.

Because of its wide distribution, the vulnerability could be  critical, though it may not be nearly as dangerous. The vulnerability affects versions 1.14 through 4.3 of GNU Bash. Patches have been issued by many of the major Linux distribution vendors for affected versions, including:

  • Red Hat Enterprise Linux (versions 4 through 7) and the Fedora distribution
  • CentOS (versions 5 through 7)
  • Ubuntu 10.04 LTS, 12.04 LTS, and 14.04 LTS
  • Debian

A test on Mac OS X 10.9.4 (“Mavericks”) by Ars showed that it also has a vulnerable version of Bash. Apple has not yet patched Bash, though it just issued an update to “command line tools.”

While Bash is often thought of just as a local shell, it is also frequently used by Apache servers to execute CGI scripts for dynamic content (through mod_cgi and mod_cgid). A crafted web request targeting a vulnerable CGI application could launch code on the server. Similar attacks are possible via OpenSSH, which could allow even restricted secure shell sessions to bypass controls and execute code on the server. And a malicious DHCP server set up on a network or running as part of an “evil” wireless access point could execute code on some Linux systems using the Dynamic Host Configuration Protocol client (dhclient) when they connect.

There are other services that run on Linux and Unix systems, such as the CUPS printing system, that are similarly dependent on Bash that could be vulnerable.

There is an easy test to determine if a Linux or Unix system is vulnerable. To check your system, from a command line, type:

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

If the system is vulnerable, the output will be:

vulnerable
this is a test

bash_vul

 

 

 

 

 

 

An unaffected (or patched) system will output:

 bash: warning: x: ignoring function definition attempt
 bash: error importing function definition for `x'
 this is a test

The fix is an update to a patched version of the Bash shell. To be safe, administrators should do a blanket update of their versions of Bash in any case.

 

Root Cause of this issue:

  • A flaw was found in the bash functionality that evaluates specially formatted environment variables passed to it from another environment.
    An attacker could use this feature to override or bypass restrictions to the environment to execute shell commands before restrictions have been applied. Certain services and applications allow remote unauthenticated attackers to provide environment variables, allowing them to exploit this issue.
  • For more information about this vulnerability, refer to the following article:
    Bash Code Injection Vulnerability via Specially Crafted Environment Variables (CVE-2014-6271)

 

Resolution for Bash Code Injection Vulnerability via Specially Crafted Environment Variables (CVE-2014-6271) (Source Redhat)

In order to avoid exploitation from CVE-2014-6271, ensure that your system is updated to at least the following versions of Bash.

RHSA-2014:1293

  • Red Hat Enterprise Linux 7 – bash-4.2.45-5.el7_0.2
  • Red Hat Enterprise Linux 6 – bash-4.1.2-15.el6_5.1
  • Red Hat Enterprise Linux 5 – bash-3.2-33.el5.1

RHSA-2014:1294

  • Red Hat Enterprise Linux 4 Extended Lifecycle Support – bash-3.0-27.el4.2
  • Red Hat Enterprise Linux 5.6 Long Life – bash-3.2-24.el5_6.1
  • Red Hat Enterprise Linux 5.9 Extended Update Support – bash-3.2-32.el5_9.2
  • Red Hat Enterprise Linux 6.2 Advanced Update Support – bash-4.1.2-9.el6_2.1
  • Red Hat Enterprise Linux 6.4 Extended Update Support – bash-4.1.2-15.el6_4.1

RHSA-2014:1295

  • SJIS for Red Hat Enterprise Linux 6 – bash-4.1.2-15.el6_5.1.sjis.1
  • SJIS for Red Hat Enterprise Linux 5 – bash-3.2-33.el5_11.1.sjis.1
  • In order to update to the most recent version of the Bash package run the following command:
# yum update bash
  • Specify the package name in order to update to a particular version of Bash. For example, to update a Red Hat Enterprise Linux 6.5 system run:
# yum update bash-4.1.2-15.el6_5.1
  • The only way to fix it is to install updated Bash packages.
  • The safest & simplest thing to do is to perform a system reboot.
  • Carry out the following operation if system cannot be reboot.
/sbin/ldconfig

Read more information on this @ redhat

© 2017 My techbook

Theme by Anders NorénUp ↑