Hi people

After a few months of work and research we have updated the SSL Analyzer tool to version 1.1. So, here is a description about the SSL Analyzer and who should use it.

What is it?

This tool was created for penetration testers and for site administrations who want to check if their server allows usage of insecure SSL algorithms.

SSL did not allow attackers to read/change the traffic between the client (computer/mobile browser) and the server, if the server allows insecure algorithms, the attacker can force the browser to use them and break the encryption (as they are named, they are insecure algorithms…).

Easy to use

SSL Vulnerabilities Analyzer has a nice interactive tool that makes it easy to run and check if the server contains insecure algorithms also for non-technical people.

Source code

SSL vulnerabilities analyzer shared with his source code under GPL v3 license, as a gift back to the open source community.

Download

You can download the current version (1.1) from here: SSL Analyzer version 1.1 zip

For more details, source code and versions, please visit the dedicated area in our website: https://appsec-labs.com/SSL_Analyzer

To-do list

Well, I plan to add some more tests, like secure flag of cookies, cache header policy, renegotiate and more, you invited to send a feedback if you want one of them first J

If you have any thought, please let me know

Israel Chorzevski

Penetration Testing Team Leader

The slides from my OWASP Israel 2012 talk “Advanced iPhone Hacking with iNalyzer” have been uploaded and are available here.

iNalyzer iPhone testing tool that was presented in the talk can be downloaded directly from Here (You will need Graphviz Dot and Doxygen installed on your PC/Laptop )
Here is an Installation Video (currently no Sound..)
iNalyzer Installation and usage

Here is a small demo of iNalyzer Vs. iSafePlay
iNalyzer Vs. iSafePlay
Enjoy,
Chilik

cPanel navigates the requests that are sent to the server to the correct account according to domain. Of course, the account owner must declare that the domain belongs to him. In order to ensure that the domain does, in fact, belong to him, cPanel offers two options (without EPP code):

1. To refer the domain DNS to the DNS storage server.
2. To create a randomly-named file on the domain, created by cPanel, which is unique per-user.

I will go into some detail regarding the first option
In order to move from one storage to another, the site owner performs the following steps:

1. Creates a copy of the website in the second storage.
2. Forwards the domain to the second storage (DNS referral).
3. Waits for DNS servers to be updated.
4. Connects to the new storage cPanel and takes ownership of the domain.

You can immediately notice that this option does not have any authorization check. In the critical step, step 4, any other user in the cPanel can take ownership of the domain.

Even if the site owner discovers this and complains, serious damage can be caused within minutes.
Using emails:

1. Sending and receiving emails from the stolen domain, can be exploited for social engineering to phish passwords, which will be useful also after the victim take over the account.
2. Create SSL certificate for the site using mail addresses such as admin@victim.com / ssladmin@victim.com and use it to MITM a long time after the victim take back his account.
3. Sending spam, it will take a while before the domain is removed from spam lists.

Using the siteitself:

1. Phishing users’ account credentials, after that, all users needs to set a new password.
2. Insertion of malware, which will cause the website to be rejected by search engines and it will take a while to get it re-approved.
3. Defacement of the website

Range Attack
The attackerwill scan websites that are located on shared storages, register the domain => IP, write a small script that will sample whether the domain IP has changed. As soon as the IP changes, it is reasonable to assume that the website has moved to a new storage. Now the attacker must quickly create an account in the new storage supplier of the victim, link the domain to it and… DONE.

P.S. Another problem that exists on cPanel is that the TOKEN protection against CSRF is performed via OPT-IN, which leaves most of the storages vulnerable to serious CSRF – but that is an entirely new subject…

The slides from my OWASP Israel 2011 talk “Tampering 101 – Automated binary protocol analysis of web applications” have been uploaded and are available here Tampering101_slides.

Belch automation tool that was presented in the talk can be downloaded directly from sourceforge in the following link Belch – Burp ExternaL CHannel v1.0.12

Enjoy,
Chilik

Slides from erez’s “When Crypto Goes Wrong” presentation at yesterday’s OWASP Israel 2011 conference.

When Crypto Goes Wrong – Presentation

Security assessment of mobile QR readers – Updated (30-Nov-2011)

Abstract:
Quick Response code, also known as QRCode has been around for several years, but in the last months there has been an incline in adoption of QRcodes as a marketing channel. A QRcode can encode a variety of information into a 2-dimentional barcode that is presented to the costumer. Customers are often referred by vendors into scanning QRCodes in order to receive coupons, discounts or other marketing media such as website, flash movie etc. The QRCode is parsed by QR-reader software on a mobile phone equipped with a camera. The true nature of QRcode content is an enigma until it is scanned; there is no possibility for the customer to authenticate the content of a QRcode without scanning it first. Because of the latter fact, an attacker with evil intent could craft a malicious QRCode (or evilQR) and lure an innocent customer to scan it. Once scanned the evilQR would be parsed by the customer mobile phone software and would initiate its’ attack. Attack vectors could vary from browser-based such as Cross-Site-Scripting (XSS) to specific buffer-overflow and command injection. The key for a successful attack lays in the default behavior of the mobile QRCode reader software. If as an example, a QRCode reader parses a link from a evilQR and preforms a URL redirection without proper confirmation of the customer – the attack would succeed. In this assessment we have compared the default behavior of several QR-readers for and noted their behavior upon the parsing of two evilQRs. Best practices for mobile users are also discussed.

The problem:

 An innocent customer can be easily tricked into scanning a malicious-crafted QRCode (evilQR) by an attacker, upon scanning the customer mobile would be attacked by the encoded payload.

Motivation:

The motive for executing such attack is very clear – the mobile phone is a gold mine for an attacker, because today’s phone contains very sensitive information such that can be abused by an attacker in several ways:

•  Personal information compromised by an attacker could lead to  impersonation, phishing and identity theft
•  Calendar and meetings compromised by an attacker could lead to business or other information disclosures.
•  Address book compromised by an attacker could lead to  impersonation, phishing and identity theft
•  Private and Cooperative email access compromised by an attacker could threaten internal business IT infrastructure.
•  Geo-location compromised by an attacker could lead to harassment, surveillance and privacy loss
•  Connectivity – (3G, GPRS, Wi-Fi, Blue-Tooth, etc.) could enable the attacker to remote control his attack
•  Credit card information compromised by an attacker
•  Social networking accounts (Twitter, Facebook, Path, LinkedIn, etc.) compromised by an attacker could lead to defacement, impersonation phishing and identity theft

Assessment:

Our assessment goal was to verify that QRCode reader software will not process an evilQR payload without proper confirmation from customer. In order to perform the test two test cases were created:

a.       JavaScript QRCode:

evilQR 1: QRCode with Java-script alert payload

In the first test case we have encoded a simple java-script code into an evilQR. The java-script that was used was very simple – an alert message that is shown upon parsing. This test demonstrates a simple case of a Cross-Site-Scripting web attack (XSS). In this kind of an attack the customer web-browser is lured into executing malicious code on behalf of the customer current context and permissions. The object of this test case was to test the autonomous parsing capabilities of the QRCode reader software. If the QRCode reader software executes the java-script code without proper confirmation of the customer – the test is regarded as failed, whereas if the QRCode reader software executes the java-script code only after customer notification – the test is regarded as success.

b.      Web link to a malicious site:

evilQR 2: QRCode with payload: http://www.appsec-labs.com

In the second test case we have encoded a simple web link into an evilQR. The web link refers to http://www.appsec-labs.com as an example for an evil website. This test demonstrates a simple case of a phishing web attack. In this kind of an attack the customer web-browser is lured into visiting a malicious website that will attack the customer. The object of this test case was to test the autonomous website redirection capabilities of the QRCode reader software. If the QRCode reader software performs redirection to the encoded website URL without proper confirmation of the customer – the test is regarded as failed, whereas if the QRCode reader software executes the website redirection only after customer notification – the test is regarded as success.

In hope to shed light on the likelihood of this attack, we have chosen fourteen different QRCode reader applications, and kept their setting to the default.  For each application we performed two scanning cycles. The first was aimed to test the autonomous java-script parsing of the QRCode reader application using the first test case. The second was aimed to test the autonomous parsing of website URLs by the application.

Results:

The QRCode reader assessment comparison chart is shown below (Table 1). We can learn that from the selected applications only one was found vulnerable to java-script evilQR (QuickMark). Furthermore, we can deduce that about 35% of the applications that were used were found vulnerable to direct website redirection. These results confirm our prior assumption that QRCode reader application may be used to introduce a malicious evilQR and to inflict an attack on an unaware customer. What more can be learned from the table below is the fact that the current QRCode reader applications parsing of java-script is not yet fully supported by the majority but could be but could be in the near future.

Table 1: Comparison table of application performance in two tests

 From these results we can confirm that the evilQR attack vector is indeed a widespread phenomenon, and it should be taken into consideration by customer and application vendors.

Recommendations:

Many QR-reader software are delivered with default setting of the QR reader to interact with URI links automatically. This behavior may expose the mobile user into scanning an evilQR which will be parsed and trusted by the user’s QR-reader software.
As a general security recommendation to our customers follow these thumb rules:

1.  You should choose a configurable QR-reader software that enables you to confirm QR-code output prior to its’ acceptance.
2. Never scan a QR-code that has an unknown origin
3. You can check your mobile QR-reader vulnerability by scanning the two evilQR (you can postback your results so we can update the table)

DC9723 is an Israeli DefCon group (currently the only one), which meets once monthly on the third Tuesday of each month. Each meeting consists of two lectures about Hacking \ Information security. I will be giving the first lecture in the next meeting, the subject being HTML5 security.

The lecture in fact deals with HTML5 & hacking, I’m not really know why they wrote HTML5 security there. But anyway, and more importantly, it is going to be very interesting.

So, open your diaries:

08/16/2011 19:30 to 20:30

Tel-Aviv University (Rosenblat Auditorium)

Free admission

Lecture: HTML5 Security (by Israel Chorzevski)

Link: https://dc9723.org/Main_Page

Looking forward to seeing you there,

Israel