26 April 2008
Many popular services online give out code snippets to place on your site for various reasons. Usually there's nothing wrong or dangerous about it, however, sometimes the opposite is true.
Take the insanely popular Google Adsense service. The idea is awesome, the implementation however - not that much. There is one line of code that scares me in particular:
<script type="text/javascript" src="http://pagead2.googlesyndication.com/pagead/show_ads.js">
How incredibly insecure is that? By placing Google ads on your website you are pretty much putting your security in Google's hands. If an attacker would gain control over the cluster that hosts the "show_ads.js" file, we could be talking about the largest mass-deface in the history of the internet. Worse, the attacker could quietly collect cookies from thousands of websites, and then commit massive identity theft (although, technically, the amount of traffic involved may be overwhelming).
To tell the truth, I can't exactly claim I never did the same mistake. Actually, I have the Google Analytics script embedded into all of my pages right now.
I guess you can agree with me when I say that the chances of Google getting hacked are close to 0. Consequently, I'm not planning to remove the Analytics script from my site anytime soon. However, Google aren't the only ones who ask their users to include remote scripts.
Don't believe me? Take another example. Digg.com. Guess what's their solution for placing a "digg it" button on your site?
<script src="http://digg.com/tools/diggthis.js" type="text/javascript"></script>
Yes, you can argue that digg.com is a pretty secure place as well, sure you can, however that would be missing the point. By placing this code on your page, you're trusting the admins of another site to be responsible for
your site's security.
What's the solution? Iframes, maybe. Giving out the script files for local inclusion, maybe. Anything other than including code from servers that the user isn't responsible for.
I doubt anyone that manages services such as Google Adsense will ever read this post, but if you're someone who's including remote scripts on a website, always remember that what you're doing is insecure.
Oh, and P.S.
Flash (swf) ads can also run scripts. Guess how many websites embed those remotely?
Posted by: kGen | In category: Webappsec | Comments (0)
22 April 2008
You know all those times when file_get_contents() just isn't enough? If you want to send cookies with your request, or send it as POST, you'll have to use sockets.
Lately I've been writing lots of php scripts that had to handle HTTP sessions. By "sessions" I mean acting like a web browser. Saving cookies, sending them, following 301/302 redirects, etc.
Eventually I wrote up a class that handles all of that seamlessly. The class itself is new (written a few days ago), so bugs are a very real possibility.
The code is located here:
http://own-the.net/code/httpsession.txt
Except for the class httpSession, the code contains 2 other routines. extractSingle() and extractMulti(). The first one returns the first occurrence of a substring that is located between 2 given substrings. The second one returns an array of all such occurrences.These are pretty useful routines, especially if you write a bot or spider. (And yeah, I did hear about REGEX, no need to point this out).
Here is an example of how to use this class:
<?php
//Include the httpSession class php file
include 'httpsession.php';
//Create an instance of the class
$h = new httpSession();
//Allow following 301/302 redirects
$h->follow_redirect = true;
//Set a cookie named "name", and give it a value
$h->setCookie("name", "value");
//Set a referer string
$h->referer = "Something";
//Send a request to somesite.com.
//(This procedure returns the HTML of the main page, however, we don't use the return value here)
$h->httpGet("http://somesite.com");
//Echo a new cookie named "newcookie" that was set by the server.
echo $h->getCookie("newcookie");
//Echo the response after sending a POST to the specified URL with the specified data
echo $h->httpPost("http://somesite.com/form?id=123", "var=val&something=else");
?>
This example covers most of the things this class handles, however, it has more features. Feel free to take a look at the code, the class-member names are pretty self explanatory.
Enjoy, and use this wisely.
Posted by: kGen | In category: Php Development | Comments (0)
21 April 2008
I'll be honest, I was very surprised by this find. As a matter of fact, this was the first time I ever managed to crash Linux completely... Through a web browser.
The attack is too simple to brag about, just a simple JS that takes up a lot of memory fast.
<html>
<body>
<form method = "GET" action = "bla">
<input name = "vuln" value = "012345678901234567890123456789012345678901234567890123456789">
</form>
<script>
for (i=0; i<=5000; i++){
document.forms[0].vuln.value += document.forms[0].vuln.value;
}
</script>
</body>
</html>
This algorithm takes M*2^N bytes of memory (where M is the length of the "vuln" field and N is the number of loop iterations). You would expect the browser to alert you that this script is going to take a really long time to execute, but apparently, this doesn't happen.
After one second of this script running, Firefox stopped responding, a few seconds later I couldn't even launch the Force Quit applet, a few seconds after that the system reached a screeching halt.
I have a vague idea of how this is possible, but I guess this is related to the new GTK+ forms in FF 3. I ran this script on Windows in Firefox 2, and nothing too scary happened. It did take up 1GB of memory in 5 seconds, but as it appeared, some limit was reached and the page was loaded with nothing more exciting than blank text field. The same happened with IE 6.
Note however, that the windows machine had twice more RAM and processing power than the Linux machine, so I'm not sure whether this was a very "scientific" test. (I should also try installing FF 3 for Windows and see what happens).
Certainly, I know FF 3 is beta software. However, what really shocked me here is how easy it was to overload the whole system through a web page. This certainly isn't "expected behavior".
Posted by: kGen | In category: Denial of Service | Comments (0)
16 April 2008
Check this out:
http://own-the.net:110 . In Firefox 3 beta 5 (my version, didn't check the rest), it will tell you this:
Port Restricted for Security Reasons
This address uses a network port which is normally used for purposes other than Web browsing. Firefox has canceled the request for your protection.
Now, I don't actually have a POP3 server running on port 110, so obviously Firefox filters these ports without thinking twice. I'm sure you're asking yourself "why?". That was my first response too, until I finally got it.
I'll demonstrate first. I've set up a small HTTP server (just a few lines of Java) on port 1025 (
http://own-the.net:1025). All it does, is echo your request. This may seem legit, however, the funny thing is that it's obviously prone to XSS. Worse yet, cookies are sent to a specific domain or sub-domain,
but not to a specific port. Thus, the cookies from the "normal" (port 80) site, are also sent to the port 1025 "page".
You can try and send some JS with the request, but I did put some filtering against a real attack.
(Note: In Firefox, requests are automatically URL encoded, so the simplest form of XSS won't work. On IE, however, it will.)
How is this relevant? Well, many servers are running different services on standard ports. FTP, SMTP, POP3, SSH... Lots of them. If any of those services could be tricked into echoing any of the data you send through an HTTP request, you'd be able to perform XSS.
Sadly(?), I didn't actually find a popular service that is prone to this, however, now I can understand the logic behind this annoying port restriction. The aforementioned services shouldn't be responsible for filtering HTML characters, as they are not intended to be used through a browser at all. Consequently, a good browser has to filter these ports out, or else security could be compromised.
Anyway, props to Mozilla for thinking of this in advance.
Posted by: kGen | In category: XSS | Comments (2)
13 April 2008
I couldn't help but notice that many firms and agencies claim to be able to recover data from HDDs that were "wiped clean".
The rumor is that it's possible to recover traces of magnetization by "digging" deeper into the physical "layers" of a HDD platter. Or better, that you can find traces of previous magnetization "around" existing bits.
While this may sound sensible, I don't think that these recovery methods are practical, used, or even possible. About a week ago I found a test project that supports my line of thought.
http://16systems.com/zero/index.html
"The Great Zero Challenge" will reward anyone who would recover a small amount of data from a drive that had been wiped clean by the UNIX dd command.
Basically, what you can make dd do, is to overwrite *every bit* of the drive with random data or just lots of zeroes. The actual command looks like this:
sudo dd if=/dev/urandom of=/dev/hda
You can also set a different block-size, as this would improve the write speed (for this, see the man page). This command is going to take a LONG time. And this is exactly what you want, because it actually writes to every part of the drive, leaving no data left.
According to the "Great Zero Challenge", no one had recovered the data yet. When asking recovery firms for their service, they declined the request. Saying that the dd command "is a pretty good command".
Consequently, as I see it, all those feared data recovery methods simply don't exist (or aren't used, for that matter).
Recovering data from a "formatted" HDD is possible, and you could do it fairly quick with software tools. This is probably what all the "forensic data recovery" hype is all about. The dd-wipe, however, seems to be good enough in order to sustain any realistic kind of recovery.
No more need for exploding hard drives! As long as you use the right software, your data will be truly "lost forever".
Posted by: kGen | In category: General Security | Comments (2)
8 April 2008
Well, after a long while of doing nothing, I've finally decided to update this blog. For reasons unknown (laziness) I've pretty much neglected the thing for half a year.
So it happens that Godaddy were kind enough to remind me that my hosting package had expired, and that I needed to pay. Well, I didn't pay. However, as you can probably guess, I've moved the site to another host.
The host isn't only a host, but rather a VPS (virtual private server). It's pretty much weak, has only 64MB of RAM, but it's not like I have any traffic that would be affected by that.
The advantage however is that I have full root access, a dedicated IP, and a fairly generous bandwidth limitation. Considering all this, and the fact that it comes for 7$ a month, I was instantly sold.
(The company is VPSLink, by the way, and by far they were great.)
I've also installed mod_ssl on httpd, and made a self signed certificate. The "Use SSL" button above links to just that.
A self signed cert isn't much, but I don't have the resources or will to get anything more serious. Anyway, the thing still encrypts the pages, and makes sure no one intercepts them on the way to you. (Unless they're using a MITM attack, and that's what real CA certificates should protect you from).
All that said and done, I hope I'll find the drive to frequently write here.
Posted by: kGen | In category: Site news | Comments (1)
Copyright (C) 2007-2008. Some rights reserved. Distribute freely, but don't forget to link to the source.
