Security G33k: qualys

Showing posts with label qualys. Show all posts

Saturday, 8 February 2014

XSS (Cross Site Scripting) Vulnerability Found in Dell.com

According to OWASP, Cross-Site Scripting (XSS) attacks are a type of injection problem, in which malicious scripts are injected into the otherwise benign and trusted web sites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user in the output it generates without validating or encoding it. An attacker can use XSS to send a malicious script to an unsuspecting user. The end user’s browser has no way to know that the script should not be trusted, and will execute the script. Because it thinks the script came from a trusted source, the malicious script can access any cookies, session tokens, or other sensitive information retained by your browser and used with that site. These scripts can even rewrite the content of the HTML page

From: https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)

On May 28th 2013, an XSS vulnerability on Dell.com website was found and posted at pastebin.com.

(screenshot of the XSS on Dell)

As of now, the XSS vulnerability is fixed and could not be reproduced. However, on Jan 20th 2014, a security analyst by the name of Jordan Jones found the same issue on a different page of the same website and posted a screen shot of the POC on Twitter.

(the twitter post by Jordan Jones)

(the executed vulnerability)

He was kind enough to inform Dell Security team via Twitter about the vulnerability which led Dell to inform him the person to contact.

(Jordan Jones interaction with Dell Security)

At the same time, he also posted more information about the vulnerability on pastebin.com

(more information about the vulnerability)

Further injection of script can be tested on the parameter besides the window alert as screengrabbed by Jordan Jones. Below, is another way to exploit the vulnerability. By injecting an image to the parameter which leads to this:

(image injection to the vulnerable parameter)

To date, Dell has yet to fix this vulnerability. XSS is a serious vulnerability that is rated as High or Critical by most vulnerability scanners including Qualys and Acunetix and a well known company like Dell should fix this vulnerability as soon as possible.

Monday, 9 December 2013

Microsoft Windows Remote Desktop Protocol Remote Code Execution Vulnerability (MS12-020) - Validating the Findings

Results from Qualys Scan

ISSUE:

Microsoft Windows Remote Desktop Protocol Remote Code Execution Vulnerability (MS12-020)

THREAT:

The Remote Desktop feature in Windows enables access to all of the programs, resources and accessories on a user's computer from a second Windows-based computer.

A remote code execution vulnerability exists in the way the Remote Desktop Protocol accesses an object in memory that has been improperly initialized or has been deleted (CVE-2012-0002).

A denial of service vulnerability exists in the way the Remote Desktop Protocol service processes packets. An attacker who successfully exploited this vulnerability could cause the target service to stop responding (CVE-2012-0152).

IMPACT:

Successfully exploiting these vulnerabilities might allow a remote attacker to execute arbitrary code or cause a denial of service.

SOLUTION:

http://technet.microsoft.com/en-us/security/bulletin/ms12-020

http://support.microsoft.com/kb/2671387

Validating the Findings:

Using NMAP to verify the Vulnerability

#nmap -sV -p 3389 --script rdp-vuln-ms12-020 <IP>

Wednesday, 4 December 2013

SSL/TLS use of Weak RC4 cipher - Validating the Findings

Results from Qualys Scan

ISSUE:
-SSL/TLS use of weak RC4 cipher

THREAT:

Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS ) protocols provide integrity, confidentiality and authenticity services to other protocols that lack these features.

SSL/TLS protocols use ciphers such as AES,DES, 3DES and RC4 to encrypt the content of the higher layer protocols and thus provide the confidentiality service. Normally the output of an encryption process is a sequence of random looking bytes. It was known that RC4 output has some bias in the output. Recently a group of researches has discovered that the there is a stronger bias in RC4, which make statistical analysis of ciphertext more practical.

The described attack is to inject a malicious javascript into the victim's browser that would ensure that there are multiple connections being established with a target website and the same HTTP cookie is sent multiple times to the website in encrypted form. This provides the attacker a large set of ciphertext samples, that can be used for statistical analysis.

IMPACT:

If this attack is carried out and an HTTP cookie is recovered, then the attacker can then use the cookie to impersonate the user who's cookie was recovered.

This attack is not very practical as it requires the attacker to have access to millions of samples of ciphertext, but there are certain assumptions that an attacker can make to improve the chances of recovering the cleartext from ciphertext. For examples HTTP cookies are either base64 encoded or hex digits. This information can help the attacker in their efforts to recover the cookie.

SOLUTION:
RC4 should not be used where possible. One reason that RC4 was still being used was BEAST and Lucky13 attacks against CBC mode ciphers in SSL and TLS. However, newer versions of TLSv addressed these issues.

Validating the Findings

Using SSLscan

#sslscan --no-failed <IP>

Using Nmap

#nmap --script ssl-enum-ciphers -p 443 <IP>

Using SSLAudit.exe

Tuesday, 6 August 2013

Windows Remote Desktop Protocol Weak Encryption Method Allowed - Validating the Findings

Results from Qualys Scan

ISSUE:
-Windows Remote Desktop Protocol Weak Encryption Method Allowed

THREAT:
Remote Desktop Protocol is a protocol by which Terminal Service provides desktop level access to a remote user. It can be used to remotely login and interact with a Windows machine.
Since RDP transfers sensitive information about the user and the system, it can be configured to use encryption to provide privacy and integrity for its sessions. It is possible to configure RDP to use encryption algorithms that are considered insecure, such as RC4 40bit and RC4 56 bit.

IMPACT:
If an attacker has access to the network traffic with RDP sessions using weak encryption methods, then it will be possible for them to bruteforce the encryption parameters and compromise privacy of the RDP session.

SOLUTION:
RDP needs to be configured to use strong encryption methods or use SSL as the privacy and integrity provider. To configure RDP encryption methods 'Terminal Services Configuration' snap-in can be launched in mmc.exe. In 'Terminal Services Configuration' properties dialog box General tab for the Encryption Level 'High' should be selected.

LINKS:
http://technet.microsoft.com/en-us/library/cc770833.aspx
https://www.fishnetsecurity.com/6labs/blog/remote-desktop-protocol-security-creating-successful-implementation

Validating the Findings

In order to validate the findings, we use additional tools to see if we can get the same output as Qualys scan. In this case, Qualys detected that the encryption algorithm used are RC4-40bit and RC5-56bit, hence our objective is to use other tools to get that information.

Using NMAP

nmap -p 3389 --script rdp-enum-encryption <ip>

Using Perl Script

Download the package using wget

#wget http://labs.portcullis.co.uk/download/rdp-sec-check-0.8.tar.gz

Extract the package

#tar -xvzf rdp-sec-check-0.8.tar.gz

Run the script

#./rdp-sec-check-pl <IP address>

References:

http://nmap.org/nsedoc/scripts/rdp-enum-encryption.html

http://labs.portcullis.co.uk/tools/rdp-sec-check/

http://gacksecurity.blogspot.sg/2012/12/rdp-sec-check-audit-tool-for-remote.html

Sunday, 30 June 2013

SSLv2 Depreciated Protocol - Validating the Findings

In this post, we will look at some tools used to analyze whether the web server is using SSL version 2.

SSLv2 Depereciated Protocol as stated by Acunetix

Ref: http://www.acunetix.com/vulnerabilities/ssl-2-0-deprecated-protoc/

Description

The remote service encrypts traffic using an old deprecated protocol with known weaknesses.

Detailed Information

The remote service accepts connections encrypted using SSL 2.0, which suffers from several cryptographic flaws and has been deprecated.

Impact

An attacker may be able to exploit these issues to conduct man-in-the-middle attacks or decrypt communications between the affected service and clients.

Recommendation

Disable SSL 2.0 and use SSL 3.0 or TLS 1.0 instead.