Archive Page 2

China is a Good Place to Pen Test

In the midst of crazy work, I breezed through certain websites and randomly injected some simple attack vectors over this month in China. I found several large sites that are vulnerable to XSS and SQL Injection.

Large sites including DangDang, Sina China, Sogou, Baidu, some of them fixed the problems after emailing them or maybe after reading the logs, too. However, the SQL Injection in DangDang remains unfixed and that is not good. I will not disclose here though ( you can certainly find it easily. It is just simple and buggy. )

To give you an idea of how big the sites above are relative to China, here are some analogies :

DangDang – Amazon

Sina China – Yahoo! News

Sogou –

Baidu – Google ( bonus, Baidu beats Google in China )

I guess I will have to find more time to play with these sites to look for more holes. But for now, I have tons of work piling up. Ouch. I have vacation today, in office.


More About the Characters Causing XSS in Opera

I talked about an XSS in Opera 9.51 as discovered by Chris Weber [1]. I talked with Chris and he hinted me something about the character encoding, which I certainly have little concept about it, and I found out why it is happening.

Except U+180E, U+180F, they are all associated with spaces ( The Zs, Zl, Zp categories ) [2] [3]. In fact :

U+2028 – Line separator in unicode 3.0
U+2029 – Paragraph separator in unicode 3.0

Different kind of spaces in unicode :

U+2000 to U+200A

U+180E is a Mongolian Vowel Separator character [4], and U+180F is a non-existent character. Somehow U+180E fall into the Space Separator category as well. For U+180F, I really have no idea how it happened. If you know what is happening, I really appreciate your sharing.

Well, quite a good lesson on international character sets, no? I really recommend Chris Weber’s blog [5] because it contains a lot of information on character encoding and web application security that you should not miss it out.

References :

[1] –
[2] –
[3] –
[4] –
[5] –

My Performance Test on Browsers

While playing with browsers last time on character encoding issues, I timed every browser loading 10000 non-existent image tags. As you may have guessed, the script is this :

<img src=non-existent&onerror=alert(1) />

Notice that the javascript is rarely involved unless the exploit succeeded. So for almost all the cases only the image tag is involved, and not the Javascript Engine.

The test is conducted on a VMWare Windows XP Single Core 2 GHz CPU with 256 RAM. A poor specification but nonetheless helps to magnify the problems in within.

With 10000 image tags on a single page, the test is conducted without closing the browser process for 6 iterations so as to capture possible memory leaks and consistent results. The results is as follows :

Browser name Time (seconds)
Opera 9 61.2 90.9 44.2 54.5 47.2 58.2
Chrome 0.2 102.6 120.3 109.6 122.9 N/A N/A
Firefox 3 41.8 50.1 45.1 52.1 57.4 66.6
Internet Explorer 7 9.2 8.3 8.8 8.0 8.5 8.9
Safari 3 84.2 79.0 138.4 352.6 (>900)* N/A

* – Safari 3 only executed 3/4 of the scripts after 900 seconds, and was terminated because it is too slow.

Opera 9 – It scores consistently at about 50 seconds except for the 2nd iteration, which is quite good for 10000 tags. At such a poor specification, it is very responsive although it is heavily loaded.

Chrome 0.2 – It is slow at some 110 seconds, and scores consistently bad. The browser also literally hung and remains unusable during the load. As it is a beta, I am sure they will improve in time.

Firefox 3 – Fast at 50 seconds, but seems to have a slowing trend, could be caused by memory problems although formal memory profiling suggests otherwise [1]. Facts are facts. Overall experience is very responsive despite the heavy load.

Internet Explorer 7 – 8 seconds. Internet Explorer 7 seems to perform very well on such failing image tags, scoring consistently over the 6 iterations, and no signs of memory leakage. Probably optimizations are behind the scenes.

Safari 3 – An obvious growing trend from 80 seconds to exceeding 300 seconds, and took 900 seconds just to execute about 7500 of the image tags in the page at the 5th iteration. Obvious memory leakage and other problems are behind. The browser stays responsive, but its crawling speed is making it unusable.

Conclusion :

It seems to me the worst browser seems to be Safari here. If a formal performance test is conducted on such browsers, it may tell a lot more. But meanwhile, I do not have a reason to use Safari unless I want to test any new Carpet Bombing. =) Firefox 3 is still the road to go! And in China, inevitably the IE7 as well.

This is not a formal performance test and the test case consists of just a single type of script. I am just magnifying the case when a page has more images and seeing what are the capabilities of the browser is. I think IE7 should really get rid of that odd loading at the start of the browser, and maybe it can help pull back the users from Firefox 3.

References :


Interesting XSS In Opera 9.51

Bad things can happen when things are not treated as what they are. Consider the HTML tag below :

<img src=non-existent-link&onerror=alert(1) />

The browser should treat it as the following content :

<img src=”non-existent-link&onerror=alert(1)” />

Not too bad, right? But, what if the character “&” is treated as space?

<img src=”non-existent-link” onerror=”alert(1)” />

Not too great, our image tag points to something non-existent, and inadvertently triggers the onerror callback, and free javascript for everyone who comes along… in Opera 9.51. Credits to Chris Weber to the discovery.

This is the case when some character becomes a space character. ( No, the “&” character is just for easier interpretation. )

Here is a list of characters that is treated as a space character :

U+2000 to U+200A

The list of Chris Weber seems to be smaller, but the above are working as I tested it against with Opera 9.51 on Windows XP. So I am pretty sure those are extra. =)

I also tested on Firefox 3.0.1, Internet Explorer 7.0.5730.13, Chrome The vulnerability does not exist there. For Safari 3.1.2 (525.21), I *think* there are not problems because it passed some of tests, but I failed to run all the tests due to its serious performance problems ( guesstimating to be memory leak? ). More on that in the next post.

Reference :

Advisory : Attack of the Mongolian space evaders

Bypass Basic Authentication in Routers

A friend bought a router model GN-B46B of Gigabyte, and asked me if it is dangerous to expose the router to the WAN.

“Yes, of course, but you must have at least one point of contact anyway. By the way, if you cannot access the administrator page, the account name is ‘admin’ and password is ‘password’.”

Yup, I changed the password, Well, that was simple, as it was a creation of the year 2004. I searched SecurityFocus and immediately answered my friend’s question. No, I invented nothing. How did it happen?

The main page redirects to a login page secured by a HTTP Basic Authentication. However, the rest of the pages do not require the HTTP Basic Authentication. Here is the point, if you know the URL to the page that does certain function ( e.g. change password ), you can skip the login page and enter the URL to that page directly! The router site map is trivial to obtain, and I changed the password. Ouch…

This is old news, but such grave mistakes are still present out there. Time to check your own router!

References :

Dump URL Handler Script

I will have a look into the URL Handler Bugs soon, and there must be a lot to learn inside. Prior to that, I still need to find out what to investigate. So here are the scripts to dump URL Handlers for Windows and Linux, scripted uglily in Python in minutes. My Macbook is pretty screwed for those who know, so no Mac version. Feel free to use.

Windows :

from _winreg import OpenKey, EnumValue, EnumKey, HKEY_CLASSES_ROOT

handlers = []

hkcrKey = OpenKey(HKEY_CLASSES_ROOT, "")
	i = 0
	while 1:
		keyName = EnumKey(hkcrKey, i)
		keyHandle = OpenKey(HKEY_CLASSES_ROOT, keyName)
			j = 0
			while 1:
				valueName = EnumValue(keyHandle, j)
				if valueName[0] == 'URL Protocol':
				j = j + 1

		except WindowsError:
		i = i + 1
except WindowsError:

for handler in sorted(handlers):
	print handler

Linux :

import os
import re
import sys
from sets import Set

file = open('/usr/share/gconf/schemas/desktop_gnome_url_handlers.schemas', 'r')
data =

The interesting parts are "applyto" tags. The term between 4th and 5th slash is the URI we want.

uris = re.compile('([a-zA-Z0-9/\-]+)', re.MULTILINE).findall(data)
handlers = []

for uri in uris:
    handler = uri.split('/')[4]

for handler in sorted(Set(handlers)):
    print handler

Here we go…

I am so sorry the scripts look so awful, and thanks to Kane for the PRE tag tip!

URL Bruteforce Discovery

Save as .bak ??? Ouch!

Save as .bak ??? Ouch!

Have you ever saved .php into .php.bak? ?

Yep, no kidding. Did you ever do that? I did. By reversing the thoughts of a web developer, we can guess a lot of logic and pattern out of his own creation. For the case above, the page might leak its naming pattern, or the salt to its password or even a cleartext database connection string. By bruteforcing different naming conventions you can find a lot of unexpected resources, which you can be sure is not for strangers and us.

But since the resources expose themselves naked…

So, here is a list of extensions you can try ( any more? Some of them are from w3af. ) :

== Web Pages ==
.htm .html .shtml .php .aspx .asp .jsp .py .txt .out .pl

== Source Code ==
.js .phps .java .c .cpp .cs .fla .vb .inc .old .old1 .bak .bak1 .backup .backup1

== Source Code Append ==
.v1 .v2 ,v1 ,v2

== Data File ==
.xml .properties

== Archives ==
.tar .zip .rar .gzip .bzip2 .gz .tgz .tar.gz .jar .arj

== Binaries ==
.swf .class .exe

To notice is that, one of them Source Code Append, such as login.php,v1 . It is one convention used.

There is also another kind of URL discovery, but more elegant and harder to automate – by guessing the naming convention of pages. Suppose it is 2nd of September now, you can also exploit logic errors such as date mechanism URL such as this :

Maybe we can have a look into the future, stocks? =) Not bad. There are a lot of such guesses you can try and unexpected rewards awaits. As the case here shows, such unexpected access to certain areas of the website can prove disastrous.

References :
w3af –