Roy Firestein

My Top 6 Honeytokens

June 4th, 2009. Published under My Recent Reads. No Comments.

pulled from Google Reader (click on title for original post)

A few years ago, I was looking for a new developer to join our team. Of course, the hard part was to find a developer that was up to the task. I don’t believe much of what people say in their resumes, so I rather had them show me a site they coded and give me permissions to take a closer look. Many of the sites failed miserably after only some minor probing. The result was a small guide I published to summarize my experience, Web Application Auditing over Lunch. Sadly, a lot of attacks are just so simple. But then again, lets see how we can turn this around and use it against the attacker. An attacker will likely try to use simple tricks just like the once outlined in the guide. As a counter measure, I am using a set of “honeytokens”. Simple tripwires to alert me of an attacker.

1. Don’t hand session credentials to automated clients: Whenever a browser identifies itself a “wget”, or a search engine, don’t bother setting a session cookie for them. They shouldn’t log in. Yes, it is easy to fake the user agent. But many attackers don’t bother.
2. Add fake admin pages to robots.txt: Add a fake admin page as “Disallowed” to your robots.txt file. We all know of course that robots.txt should not be used as a security tool. But many websites still use it that way and as a result, attackers use it as a road map to attack a site. Whenever someone hits your fake “admin” page, you know they are up to no good.
3. Add fake cookies: Add a fake “admin” cookie and set it to “FALSE”, or “No”. This is a classic mistake attackers are looking for. But you are of course not using this cookie to assign admin privileges. Instead, you detect attacks whenever the cookies value changes.
4. Add “spider loops”: Little redirect loops to send spiders in a loop. Be nice, and add “NOFOLLOW” tags to not annoy legit search engines too much. See if anybody falls for it. It is kind of like a La Brea tarpit for web application vulnerability scanners.
5. Add fake hidden passwords as HTML comments: On your login page, add a comment like <!– NOTE: developer test login, user: alkhewr password: 234kjw –> … Wait for someone to use it
6. “Hidden” form fields: This is different from the <input type=”hidden”> form field. Instead, add a regular form field <input type=”text”> but set the style to “display: none” . That way, the form field will not be visible to normal browsers. But vulnerability scanners will happily fill it in. Note that this can be a problem for “audio browsers” used by the blind. You may want to pre-fill the form with something like “do not change this field”.

Now isn’t that all just about hiding more serious vulnerabilities? Security through obscurity? Sure … it is… but it works. In my opinion, a good defensive technique is easy to implement but hard to bypass. These techniques only take minutes to implement, but break most automated tools and will cost hours of the attackers time.

You have to decide for yourself what to do once you detected an attacker. Maybe just hope for the attacker to go away? A more aggressive, but dangerous approach is to automatically shun attackers. It all depends on how much you are willing to lock out the wrong person. In particular the hidden URLs in robots.txt are dangerous as someone who discovers the trick my now spam this hidden URL to your customers and lock them out of the side if they click on it. If you decide to shun attacker: Have a plan ready to mass “unblock” a large number of false positives.

Got your own tricks like that? Let us know and write a comment below!

Friedrich Nietzsche

June 3rd, 2009. Published under My Recent Reads. No Comments.

pulled from Google Reader (click on title for original post)
“There are no facts, only interpretations.”

TEDTalks : Ray Kurzweil: A university for the coming singularity – Ray Kurzweil (2009)

June 2nd, 2009. Published under My Recent Reads. No Comments.

pulled from Google Reader (click on title for original post)
Ray Kurzweil’s latest graphs show that technology’s breakneck advances will only accelerate — recession or not. He unveils his new project, Singularity University, to study oncoming tech and guide it to benefit humanity.

HTTP is Dead, Long Live The Realtime Cloud

June 1st, 2009. Published under My Recent Reads. No Comments.

pulled from Google Reader (click on title for original post)
Last week Google announced a new service called Google Wave. Loosely it can be thought of as a realtime communication and collaboration platform & protocol. The platform is based on hosted XML documents (called waves) which focus on supporting massive concurrency and low-latency updates on top of a decentralized XMPP architecture. It’s taken me a few days to fully understand what this announcement really means and the importance it may have in terms of the future of the Internet and how we use and consume it.

The Internet for all intents and purposes is a living organism, continually adapting and changing. It has evolved from a somewhat static medium where content updates were typically pulled from fairly simple syndication and transfer sources to a network of realtime data sources continually changing at an ever quickening pace. Combined with the ability to semantically describe millions of new data sources through powerful on demand cloud based computing platforms — we are in the midst of a realtime computing transformation. One that is fundamentally different then the hyper text based Internet that was first described more then 26 years ago.

In Google’s announcement what I found most fascinating was the protocol they choose for the basis of their new realtime vision. It wasn’t HTTP but instead XMPP was selected as the foundation for this decentralized and interoperable vision. What this means in very simple terms is Google has declared the HTTP protocol is dead, an inefficient relic of the past. A protocol that was never designed with the requirements for the reality of a global realtime cloud.

Among HTTP numerous problems is it's requirement that a user's machine poll a server periodically to see if any new information is available. For a few data sources this may seem like a small burden, but multipled by millions or even billions of constantly changing sources and you have a major problem on your hands — enter the wonders of decentralization & XMPP.

XMPP is the ultimate interoperability layer, letting one server send messages to any other XMPP server that it is available to receive new information. When another user sends new content through the XMPP server, the message is passed on immediately and automatically to all recipients who are marked as available. Building upon this core, Google’s XMPP based Wave federation protocol goes well beyond by including the additional auto discovery of IP addresses and ports using SRV records (Service record is a category of data in the Internet Domain Name System specifying information on available services). As well as TLS authentication and encryption of connections. The great thing about TLS authentication is it’s unilateral: only the server is authenticated (the client knows the server’s identity) but not vice versa (the client remains unauthenticated or anonymous). Basically Googles vision for XMPP is everything HTTP should be, but sadly isn’t.

Googles ambition with Wave goes far beyond the creation of a new kind of messaging or collaboration platform but instead seems to be an effort to fundamentally re imagine how the Internet itself is managed and used.

---

Announcing The Enomaly Cloud Service Provider Edition | Twitter Me | Get Linkedin | Contact Reuven | Disclosure Policy

---