19 October 2007
CAPTCHAs are pretty effective at keeping the spammers away, but they have their own weaknesses too. Some CAPTCHAs are "easy to read", and a simple OCR algorithm could solve them. Yet, there are even simpler ways of defeating certain CAPTCHAs, without even OCRing them.
The problem usually lies in the fact that at lest 3 different pages need to share the same code. The form page, the receiving page, and the page that generates the image. Some implementations simply don't make sure that the code isn't forged on the way.
Let's look at a very simple CAPTCHA system and understand what's wrong.
The 3 pages share a single encryption key known only to the server. The form page generates the code and encrypts it using a shared algorithm. The cipher appears on the form page inside an <img> tag for the CAPTCHA generator, and in an <input> tag for the receiver. The generator decrypts it and displays, while the receiver decrypts it and compares it to the code it got from the client.
This seems to be fine, and doesn't require the server to remember any codes or sessions. However, here is the problem. The server can't know if the code it received was the one it generated. The client can always use a single known cypher/plaintext combination in the form, and the attack will work every time.
Now it's clear that the sever must remember the code. If so, it'll have to use some sort of a session. Moreover, if the code is known to the server, there is no need to encrypt it.
Let's look at a system that abides this principle. The form page starts a session, and places a new CAPTCHA value in the session. The generator page reads the code from the session, and displays it. The receiver just compares the user input to the code in the session.
Sounds nice and simple, but you must make sure of a few things before you can deem the technique as secure.
1) Regenerate the code in the session after every submission, especially a successful one. Otherwise it will be possible to reuse the session many times over.
2) Make sure that your session system is secure. It should generate a single random key, and place it in the cookie. Do not trust the cookie to contain the CAPTCHA code (even in encrypted form, note the previous example).
3) If you must have multiple CAPTCHAs on a single page, you'll need to ID them in your HTML. Make sure the ID is not the md5 hash of the CAPTCHA code (or something of the sort), but a newly generated random number. Remember that the hash of a 6 character code can be quickly cracked.
Just one last thing to remember. A good implementation is far more important than excessive entropy in the CAPTCHA. As you see, no matter how complex the images were, in vulnerable systems they became pretty much useless.
Posted by: kGen | In category: CAPTCHA | Comments (1)
8 October 2007
Proxies are a very vital resource if you want to stay anonymous online. Ofcourse, there are a couple of ways to compromise that anonymity, and I'm going to explain one of them.
True, you can't really get to the real IP address behind an "elite" proxy from the server side. However, let's not forget the client side, as it should provide us with the answer we're looking for.
Webapps today can easily send HTTP requests and even open sockets using stuff like AJAX (Javascript), Flash and Java Applets. Normally, you would expect the plugins to obey the browsers' proxy settings, but in certain circumstances this isn't so.
Sockets don't have to use the HTTP protocol, so they can't go through HTTP proxies by default. Even if you do use the HTTP protocol and connect to port 80, the system still isn't going to enforce the proxy settings on your connection. This makes sense, but also compromises the security a proxy can provide.
And yet, it just so happens that the JavaScript way to open a socket isn't cross browser, and the Flash way requires communications across an nonstandard port (1024+). This is bad for a couple of reasons. First, the server will have to listen on an arbitrary port, a feature that most web hosting companies won't provide (so this will require a dedicated server). Second, if the user is behind a firewall, the communications could be blocked.
For reference, here are two sources that demonstrate both ways:
JS:
http://ha.ckers.org/blog/20070926/de-anonymizing-tor-and-detecting-proxies/
Flash:
http://hackademix.net/2007/09/26/cross-browser-proxy-unmasking/
So, the last reliable way to bypass a proxy is to utilize a Java Applet. It can communicate through port 80, and JVM is a very trusted and popular plugin (usually built in). I've set up a small demo for you here :
http://own-the.net/ip/demo.php . Just set some proxy settings, and watch the applet discover your real IP.
You can get the .java source here:
http://own-the.net/ip/IpApplet.java . The source is commented, and pretty self explanatory. The "ip.php" file just echoes the $_SERVER["REMOTE_ADDR"] value within <ip> and </ip> tags (in an XML-like fashion).
Now you may think that proxies are dead, but wait just a moment. You can simply disable scripting, flash and applets in your browser settings, and be safe again. Remember to go "NoScript" every time you need anonymity, and it will be fine. Consequently, this anti-anonymization trick won't work on experienced users, but it will still help in 90% of the cases. This tactic still remains quite useful and accurate.
An that's it for now.
See you on my next post.
Posted by: kGen | In category: Webappsec | Comments (0)
3 October 2007
XSS allows an attacker to insert arbitrary HTML code into the victim's website. Now, you may ask- how is this related to any kind of SEO?
Well, if you could place an <a href> tag with a link to your site, say, on cnn.com, this would be awesome- right? Sure it would be. If you can find an XSS hole in a major site, this can easily be used for SEO.
Let's say you've got a vulnerable URL that looks like this:
http://major-site.com/vuln.php?s=XSS . Instead of "XSS", you could inject some text with a link to your site. The XSS may not be persistent, and it doesn't have to be. Just post this URL on some other websites (discussion boards, or whatever), and wait for Googlebot to pick it up. You will have a one-way link from a major site in no time.
And even better. This kind of tactic doesn't require full-blown XSS holes. I've read this on another blog (
http://ha.ckers.org/blog/20070919/another-fun-seo-blackhat-spam-tactic/ ),
And apparently the Google search available on cnn.com (and many other large sites have this feature on them) allows you to use the "site:" thing in the search query. Not only that, Google seems to pick up it's own search results as genuine links from cnn.com . This means that by posting a URL like:
http://search.cnn.com/search?query=site%3Amy-ste.com&type=&sortBy=&intl= on some other website, you get yourself a pretty high rated link from CNN.
And that's not limited to links. Take a look at this:
http://search.cnn.com/search?query=site:pills-supplier.com?buy-viagra .
The page contains the keywords "buy Viagra", links to a Viagra supplier website, and is located on cnn.com . This sure means something to Googlebot as an incoming link, but it also means something as a search result upon itself. This very URL appears on the second results page for the query "buy Viagra" on Google (don't know how much longer this will persist).
Obviously, this is pretty impressive for an almost no-work trick. I mean, all the guy did was to place this URL somewhere Googlebot visits. That's all.
When users search for the keywords, and see a result on cnn.com, they're likely to check it out. When they see outgoing links on that page, they will probably click them as well . Evidently, this results in lots of traffic to the destination website, and generates cash.
With a lucky XSS hole, you could even get some text on the front page of a website. Even if the XSS is not persistent, as long as Googlebot visits the XSS link, it sees what you want it to see. Actually, it's better for the XSS to be non-persistent, since it will probably go un-noticed by the webmasters.
Only problem of course, is that finding XSS on websites such as cnn.com is close to impossible. However, if you do pull something like this off, I'd love to know how it went =)
Posted by: kGen | In category: Black hat SEO | Comments (0)
1 October 2007
Check this out:
http://en.msnspy.biz/ (Not a link for SEO reasons)
They offer a program that lets you spy on other people using their own webcam. Sounds neat, but look at what they request you to do in order to download it.
Yeah, that's right. They want you to distribute a referral link to 13 people, otherwise the thing won't download.
Well, after seeing this, considering the amount of Ads on that page, I bet it's now pretty clear what this whole thing is all about.
The program really doesn't work (I haven't tested it myself, tho), but it does sound very lucrative. The site owner manged to make it look very authentic (using a video), and since it doesn't cost money to the visitor, he/she has a great chance of getting this feeling of "what have I got to lose here?".
When they give it a try, the same process repeats itself 13 more times, and expands over the net at an exponential rate. It doesn't matter if the thing works or not, since it's been recommended before it was even tested.
I stumbled into this link on at least 5 discussion boards yesterday, and you can imagine how many of them are really out there.
Take a look yourself:
http://www.google.com/search?hl=en&safe=off&q=msnspy.biz&btnG=Search . Note that Google hates things like that, but it still has tens of thousands of those links indexed.
To say the least, this guy earned some serious cash by now. And thanks to him, we all got to see all of the classic techniques to creating something truly viral.
It will work if it:
1) Sounds good, looks authentic (doesn't have to work as promised)
2) Designed in a way that exploits the natural curiosity of people.
3) Programmed so people have to distribute it BEFORE they can get it themselves.
So there we go. I don't know what's the chance to successfully pull something like this off, but it sure ended up being profitable.
Posted by: kGen | In category: General SEO | Comments (0)
Copyright (C) 2007-2008. Some rights reserved. Distribute freely, but don't forget to link to the source.
