Hack Culture

Migrating posts

proto@hackculture.com (Mike) — Sat, 13 Feb 2010 06:38:00 +0000

Check out the new site in support of my new book! New content will be posted on that site and old posts from here will eventually be migrated.

Briefly

proto@hackculture.com (Mike) — Wed, 21 Oct 2009 19:11:00 +0000

Cloud computing means CSOs can deal with the security of information rather than infrastructure.

Briefly

proto@hackculture.com (Mike) — Wed, 21 Oct 2009 19:10:00 +0000

XSS vulnerabilities are the cockroaches of the Internet.

Factor of Ultimate Doom

proto@hackculture.com (Mike) — Thu, 21 May 2009 15:00:00 +0000

Vulnerability disclosure presents a complex challenge to the information security community. A reductionist explanation of disclosure arguments need only present two claims. One end of the spectrum goes, “Only the vendor need know so no one else knows the problem exists, which means no one can exploit it.” The information-wants-to-be-free diametric opposition simply states, “Tell everyone as soon as the vulnerability is discovered”.

The Factor of Ultimate Doom (FUD) is a step towards reconciling this spectrum into a laser-focused compromise of agreement. It establishes a metric for evaluating the absolute danger inherent to a vulnerability, thus providing the discoverer with guidance on how to reveal the vulnerability.

The Factor is calculated by simple addition across three axes: Resources Expected, Protocol Affected, and Overall Impact. Vulnerabilities that do not meet any of the Factor’s criteria may be classified under the Statistically Irrelevant Concern metric, which will be explored at a later date.

Resources Expected
(3) Exploit doesn’t require shellcode; merely a JavaScript alert() call
(2) Exploit shellcode requires fewer than 12 bytes. In other words, it must be more efficient than the export PS1=# hack (to which many operating systems, including OS X, remain vulnerable)
(1) Exploit shellcode requires a GROSS sled. (A GROSS sled uses opcode 144 on Intel x86 processors, whereas the more well-known NOP sled uses opcode 0x90.)

Protocol Affected
(3) The Common Porn Interchange Protocol (TCP/IP)
(2) Multiple online rhetorical opinion networks
(1) Social networks

Overall Impact
(3) Control every computer on the planet
(2) Destroy every computer on the planet
(1) Destroy another planet (obviously, the Earth’s internet would not be affected -- making this a minor concern)

The resulting value is measured against an Audience Rating to determine how the vulnerability should be disclosed. This provides a methodology for verifying that a vulnerability was responsibly disclosed.

Audience Rating (by Factor of Ultimate Doom*)
(> 6) Can only be revealed at a security conference
(< 6) Cannot be revealed at a security conference
(< 0) Doesn’t have to be revealed; it’s just that dangerous

(*Due to undisclosed software patent litigation, values equal to 6 are ignored.)

Evaluating a web application scanner: Link coverage

proto@hackculture.com (Mike) — Mon, 02 Feb 2009 20:00:00 +0000

Many web sites consist of thousands, tens of thousands, or even a few hundred thousand links. The initial approach to a scanning a 300,000 link site might be to give the scanner a starting URI, launch a scan, then sit back while the scanner attempts to navigate the entire site. This approach isn't wrong, but it is inefficient and often unnecessary.

There's good motivation for scanning every link of a web site: coverage. Coverage refers to the amount of the web application exercised by the scanner. It's an important factor to security testing because, in simple terms, a link that isn't crawled is a link that isn't tested. However, the real goal isn't coverage of links, but coverage of functionality. The site's functionality is responsible for accepting user input and reacting to it in some manner. This is where vulnerabilities occur.

Scanning 300,000+ links isn't feasible from either a scanner perspective or a time perspective. Many of the links could be redundant. For example, there could be 10,000 links that point to a database record like /document.cgi?id=1 through /document.cgi?id=10000. In such a case there's no need to go through all 10,000 to test the page's functionality with regard to XSS and SQL injection; it's just necessary to test the id parameter.

There are counter-arguments to the id example. Many site design patterns use parameters to control different code paths. For example, /page.cgi?action=viewProfile and /page.cgi?action=editUser involve (as the parameters imply) two different sets of functionality. Consequently, the scanner shouldn't blindly throw away redundant links just because the page and parameter names are identical.

Ideally, a scanner should cover the target's site's full functionality. In practice, measuring coverage solely from a black box perspective is hard. Solutions can take the brute force approach, scan every link, or an iterative approach that slowly narrows the scanner's focus. Some possible methodologies are

- Divide the web site into logical areas based on directory structure. Scan those areas separately.

- Sort the list of crawled URIs. Look for redundant links. Create scan rules (e.g. black lists) that avoid those links.

- Determine high-risk areas of the web site. Create scan rules (e.g. white lists) that instruct the scanner to only visit those links.

yawnjacking

proto@hackculture.com (Mike) — Fri, 30 Jan 2009 23:48:00 +0000

So, I was asked to comment about clickjacking today. Technically, it isn't a new vulnerability (IE6 fixed a variant in 2004, Firefox fixed a variant in September 2008), but a refinement of previous exploits and ennobled with a catchier name. It gained widespread coverage in October 2008 prior to the OWASP NYC conference when Jeremiah Grossman and Robert Hansen first said they would describe the vulnerability, then cancelled their talk for fear of unleashing Yet Another Exploit of Ultimate Doom.* The updated technique combines devious DOM manipulation with well-established attack patterns to make a respectable type of attack.

I still hope that this doesn't make it into the OWASP Top 1o. (I'll explain why elsewhere.)

Anyway, in the interest of further polluting the internet with opinionated cruft, here's more information about clickjacking:

Clickjacking tricks a user into clicking on an attacker-supplied page while the user only sees the appearance and effect of clicking on a plain link. The attacker identifies an area in the target HTML that should receive the click event. This HTML is placed within an IFRAME such that the X and Y offsets of the frame place the target area in the upper left-hand corner of the frame’s visible area. This target IFRAME is visually hidden from the user (though the element remains part of the DOM). Then, the IFRAME is set within a second page (the content of which doesn’t matter) beneath the mouse cursor and, very importantly, dynamically moves to always be underneath the mouse. Then, when the user clicks somewhere within the second page the click is actually sent to the target area even though it appears to the user that the mouse is only above some innocuous link.

Essentially, an attacker chooses some web page that, if the victim clicked some point (link, button, etc.) on that page, would produce some benefit to the attacker (e.g. generate click-fraud revenue, change a security setting, etc.). Next, the attacker takes the target page and places a second, innocuous page over it. The trick is to get the victim to make a mouse click on what appeared to be the innocuous page, but was actually an invisible element of the target page that has been automatically, but invisbly, placed beneath the cursor.

The attack relies on luring a user to a server under the attacker’s control or a site that has been compromised by the attacker. Web site owners who ensure their site is free of cross-site scripting or other vulnerabilities can prevent their sites from being used as a relay point for the attacker. Yet other successful attacks, such as phishing, also rely on luring users to a server under the attacker’s control. The relative success of phishing implies that just securing web applications at the server isn’t the only solution because users can be tricked into visiting malicious web sites.

The core of the attack occurs in the browser, which is where the real fix needs to appear. The problem is that browsers are intended to handle HTML from many sources and provide mechanisms to manipulate the location and visibility of elements within a web page. Consequently, any solution would have to block this attack while not inhibiting legitimate uses of this functionality.

*Yes, I made you scroll all the way down here to get the link. How evil is that?

Baud boy, baud boy, what'cha gonna' do?

proto@hackculture.com (Mike) — Mon, 29 Dec 2008 20:00:00 +0000

Matthew Broderick was l33t* years before Trinity ran Nmap and pulled off an OpenSSH sploit. Seriously, it's not that hard to run a port scanner and download a canned exploit. David Lightman (Broderick's character) put real effort into his gear. Plus, the Matrix sequels were philosophical silliness dolled up with CGI to arouse drowsy neurons. WarGames explored some similar themes with better plot and better acting as summed up in David Lightman's "Is it a game... or is it real?" vs. Neo's "Whoa."

The movie's hacking premise rests on the tools in chapter 18 of AHT3. Wardialers also featured in the non-fiction account of computer espionage, The Cuckoo's Egg: Tracking a Spy Through the Maze of Computer Espionage, by Cliff Stoll.

More recent examples of what can be done with a laptop, modem, and free time can be found in this SCADA presentation. (The author is from New Zealand. If you look closely at some of the photos you can see hobbits.) The presentation also debunks a few myths about the Ultimate Doom (UD) that could be caused by messing with SCADA systems. While UD isn't impossible, the most common examples of potential UD cited in news stories are significantly overblown.

*This is the only time leetspeek will appear on this web site. I promise.

Insecurity is like writing good and what you end sentences with

proto@hackculture.com (Mike) — Mon, 15 Dec 2008 20:00:00 +0000

Pick a programming language. There are good odds that a web application has been written in that language and better odds that the application contains at least one vulnerability. Many vulnerabilities result from simple coding mistakes that look obvious once they're identified, just as incorrect adverbs and sentence-terminating prepositions stand out to anyone who pays attention to English grammar. Secure coding has many parallels with good writing (or writing well). Grammar rules make communication clearer.

Straying from the path of grammar isn't always bad: text messaging, quick e-mails, inside jokes serve specific purposes. Incorrect grammar can even be unintentionally funny. Incorrect coding might lead to funny error messages or logic loops, but it also leads to security vulnerabilities.

In the last two years at my current job I've written roughly 30,000 lines of C++ code. Every once in a while the QA team finds a bug or reports a core discovered in the released code. During my periodic code review and re-factoring I come across even more undiscovered bugs that haven't yet manifested themselves.

Well-written code should be more secure code. (This assertion, like many others made here have anecdotal support, but no empirical support -- beware that common sense can often turn into nonsense if subjected to the scrutiny of testing and validation.) Yet code that can be parsed and compiled correctly doesn't inherently imply secure code. Just as documents can have non sequiturs and lack coherent flow so too can well-written code fall into logic traps or misaligning a variable's time of check with its time of use.

Metaphors for computer security -- cars, onions, castles, moats, cheese (I made up that last one) -- are usually stupid, unhelpful, and break down under the slightest inquisition of relevance. Writing an essay, e-mail, etc. at least shares the same physical process and more closely resembles the good and bad aspects of adhering to a language's rules and the ease with which simple mistakes can be made.

Ad Mortem Festinamus

proto@hackculture.com (Mike) — Sun, 30 Nov 2008 20:00:00 +0000

Music to hack by. Qntal released their first album 16 years ago in 1992.

In April of that year three RFCs appeared that covered MD2, MD4, and MD5. MD5 survived several years of cryptanalysis until a significant, practical attack was announced at the Crypto 2004 conference. Additional information appeared at the EUROCRYPT 2005 conference. Currently, the U.S. government only approves five hash algorithms: SHA-1, SHA-224, SHA-256, SHA-384, SHA-512.

Note that the attacks against MD5 are based on cryptanalysis of the algorithm. This attack differs greatly from those based on "Rainbow Tables." A Rainbow Table trades the computational time required to discover, via brute force, the input value of a hash with the memory required to store all possible hashes for a set of input values. This technique, a time-memory trade-off, is hardly new. An IEEE paper by Martin Hellman described an approach to attacking DES in 1980.

However, the feasibility (and popular adoption) of rainbow tables also needed the cost of memory -- gigabytes to terabytes of disk space -- to drop. In 2008, it is trivial (though perhaps still expensive) to have three terabytes of disk space in a desktop computer. Consequently, the input value of a hash can be discovered in a matter of seconds or minutes rather than days or years. Rainbow tables are generated by running through a key space, say all seven-character alphanumeric combinations, once and storing the mappings between input value and hash. Any subsequent lookup merely requires the user to look up a hash value and then find the input value that generated it. In other words, all of the exhaustive brute force only needs to be executed by one user and the results shared with multiple users.

Rainbow tables can be generated for any algorithm, from MD5 to SHA-512 to certain modes of AES. They are based on simple brute force attacks rather than any underlying weakness of the algorithm. However, rainbow tables can also be trivially defeated.

Think of a rainbow table as something like this:

hash = MD5(input value)

Where hash is the result of an MD5 operation on input value. Typically, input value will be the complete key space of a length of characters (e.g. seven character alphanumeric).

Now, consider this small modification:

hash = MD5(salt + input value)

In this case, a fixed set of characters, the salt, is prepended (it could also be appended) to the input value to produce the hash. The salt doesn't need to be secret or even random -- it could be "apple" or "zombie." The function of the salt is to extend the length of characters used as the input and to prevent trivial hash comparisons. The combination "zombie" plus "password" turns an eight-character input value into a 14-character one. For an attacker who relies on a rainbow table to attack eight character passwords, the addition of "zombie" doesn't make the table any bigger, but it makes it different from the rainbow table for hashes without a salt. As a result, the attacker needs to rebuild the table -- which turns the problem back into a time-consuming brute force attack.

If your application stores hashed passwords, then make sure that the hashes are salted. It won't make the passwords more secure against phishing, sniffing, or replay attacks, but it can make them resistant to rainbow attacks if the hashes are compromised.

If your web application stores passwords in plain text, then it has more fundamental security issues.

Paul Atreides predicted further ahead in time, but he had spice

proto@hackculture.com (Mike) — Wed, 26 Nov 2008 00:50:00 +0000

In November 2008 the National Intelligence Council (NIC) released a report that looks at "how key global trends might develop over the next 15 years to influence world events." The report doesn't claim prophecy. The authors review current trends in order to "provide US policymakers with a view of how world developments could evolve, identifying opportunities and potentially negative developments that might warrant policy action."

One interesting aspect is the discussion of cyber warfare as an emerging aspect of conflict. The report avoids details of what cyber warfare might look like (or already looks like, for that matter), but the type of conflict earns specific mention. So, it must be important to some degree.

Rather than focus on the future right now, it might be worthwhile to see how previous editions of the NIC's report fared with time and hindsight. In November 1997 the NIC released a report looking towards 2010. It makes for interesting reading through the lens of computer security.

The report intentionally avoids specific predictions, but its expectation of the clash between government and technology arrived with significant examples, a few of which include DRM, freedom of speech, Google and Yahoo in countries with human rights problems, and the Great Firewall of China.

The good news is that governments will derive benefits from technology that moves information, goods, and services rapidly. The bad news from the perspective of governments is that they will have less and less capacity to control these flows unilaterally.

This message was reinforced with:

However, communications will also thwart government efforts to control the flow of information, which, in some instances, will undermine their authority.

The report also deserves credit for explicitly highlighting organized crime's adoption of the Internet, exploiting its underlying technologies, and targeting its multitude of rubes:

International organized crime groups will take advantage of such technology as well, bypassing governments, or seeking to undermine them when governments try to block their efforts to run and expand their illegal activities.

A few examples are the Russian Business Network, sophisticated credit card black markets, auction fraud, and cons. Not only does technology enable criminal markets (IRC bots running credit card exchanges), but common vulnerabilities provide the attackers with a large pool of potential victims. No longer do attackers deface web sites to impress friends. Newer attacks rely on subtle infection of a web page with a single line of JavaScript that may point to a server in China or Russia. This infected web page then loads an exploit that tries to attack the web browser of each person visiting the site. Vulnerable browsers leave their users open to theft of credit card numbers, online game account credentials (e.g. World of Warcraft), or banking information.

On the cyberwar front, the report provides only vague extrapolations for the future:

Precision- guided munitions and information technologies will continue to be the hallmarks of the revolution in military affairs. Other countries will have technologically advanced military equipment at their disposal, obtained from arms merchants and other governments. However, no power will be able to match US battlefield technological capabilities during this time frame, and potential adversaries are unlikely to repeat Iraq's mistake in challenging the United States via set-piece conventional warfare.

So, it alludes to a continued U.S. superiority of information technologies, but at the same time emphasizes

we may find what some would call a "doctrine of massive technological superiority" as limited in the future as the doctrine of massive retaliation was forty years earlier.

For the moment consider cyberwar simply hacking between opposing state-sponsored groups. The U.S. has the 24th Air Force (among others, surely), which faces counterparts across the world -- most notably China. For example, a 2008 DOD report to Congress notes

...China’s leaders stress asymmetric strategies to leverage China’s advantages while exploiting the perceived vulnerabilities of potential opponents using so-called “assassin’s mace” programs (e.g., counterspace and cyberwarfare programs).

The same report also details why the U.S. has concern for China's hacking efforts (detailed on pages 3 and 4).

Yet Cyberwar may not only be a term in search of a definition, but a topic for which contemporary examples are few (at least to public knowledge). Russia vs. Estonia typically serves as the most recent popular example, but being state-sponsored on both sides and the actual impact of the "war" diminishes under scrutiny and skepticism. Russia vs. Georgia was rumored to be a sequel. However, that conflict included tanks, guns, and soldiers crossing borders -- all a more pressing concern for civilians than a virtual carpet-bombing of computer networks with IP packets.

It will be interesting to see how Internet-related events unfold in relation to the trends recorded in the 2025 report.

Yet it won't be necessary to wait until 2025 to review the current trends report. By November 2019 a much more important event will occur.

The Internet is dead! Long live the Internet!

proto@hackculture.com (Mike) — Sun, 23 Nov 2008 01:15:00 +0000

In 1998, L0pht claimed before Congress that in under 30 minutes their seven member group could make online porn and Trek fan sites unusable for several days. (That's all that existed on the Internet in 1998.) In February 2002 an SNMP vulnerability threatened the very fabric of space and time (at least as it related to porn and Trek fan sites -- if you still don't believe me, consider that Google added Klingon language support the same month). More recently, a DNS vulnerability was (somewhat re-)discovered that could enable attackers to redirect traffic going to sites like google.com and wikipedia.com to sites that served porn, even though many people wouldn't notice the difference. (Dan Kaminsky compiled a list of other apocalyptic vulnerabilities that similar issues with those that plagued DNS.)

This year at the OWASP NYC AppSec 2008 Conference Jeremiah Grossman and Robert "RSnake" Hansen shared another vulnerability, clickjacking, in the Voldemort "He Who Must Not Be Named" style. In other words, yet another eschatonic vulnerability existed, but its details could not be shared. This disclosure method continued the trend from Black Hat 2008 prior to which the media and security discussion lists talked about the secretly-held, unsecretly-guessed DNS vulnerability information with the speculation usually retained for important things like when Gn'Fn'R would finally release Chinese Democracy. [If you don't care about gory details of the disclosure drama and just want to skim the abattoir, then read this summary.]

Yet none of these doom-laden vulnerabilities have caused to Internet to go pfft like a certain parrot that need not be named.

Until now.

I've discovered a web-based vulnerability that can be trivially exploited called Cross-Hype Attack Forgery Exploit (CHAFE). It affects all web browsers and can't be patched (nor will you be protected by FireFox's NoScript or using lynx). In fact, if you're reading this entry then I guarantee you can be vulnerable to it. Public release of the details would be self-defeating, but I'm willing to sell the details to the highest bidder -- as well as anyone else who wants to pay for the information. To ensure the validity of this vulnerability, consider that it has both "cross" and "forgery" in the name. So, it clearly has a working exploit associated with it. No peer review is necessary to establish the vulnerability's credibility. To build further confidence, I'll hint that the vulnerability builds on prior research, but who really cares about dusty problems from 1991 when you can have a working exploit in 2008?

Since I haven't gotten around to creating PayPal account yet (although a reminder to update my account information just arrived in my InBox a few moments ago), send an e-mail to chafe@hackculture.com if you're interested in the details and you have some money from which you'd like to be departed.

A sense of history

proto@hackculture.com (Mike) — Sat, 22 Nov 2008 03:34:00 +0000

Cross-site scripting (XSS) vulnerabilities provide some of the most interesting and creative exploits. These exploits range from banal pop-up windows that annoy people to using the browser as a port scanner to insidious theft of authentication credentials. The fundamental cause of the vulnerability is well known and has been described in many other places. What isn't commonly discussed is the history of XSS (more generally described as HTML injection) and the provenance of the security concern.

The original CERT advisory was published on February 2, 2000.

Keep in mind that the term "XSS" is neither an accurate description of the vulnerability or the original short-hand reference for attacks that modify the HTML DOM or execute scripting code in the browser. USENET references to "malicious html" and "malicious javascript" go back as far as 1996. In March of that year a post showed up on comp.security.unix that described what malicious content might do:

A funny-looking link can persuade a fancy browser to send mail, perhaps to exploit a bug in the mail program to do something much worse. The newest craze, Java, actually downloads programs into the browser, and runs them.

Another post in comp.sys.acorn.misc in June of 1996 contained a nice description of the potential of malicious JavaScript:

Another 'application' of JavaScript is to poke holes in Netscape's security. To *anyone* using old versions of Netscape before 2.01 (including the beta versions) you can be at risk to malicious Javascript pages which can
a) nick your history
b) nick your email address
c) download malicious files into your cache *and* run them (although you need to be coerced into pressing the button)
d) examine your filetree.

Now, compare the previous description with the definition of XSS from the most recent OWASP Top Ten list.

Cross-site scripting, better known as XSS, is in fact a subset of HTML injection. XSS is the most prevalent and pernicious web application security issue. XSS flaws occur whenever an application takes data that originated from a user and sends it to a web browser without first validating or encoding that content.

XSS allows attackers to execute scripts in the victim’s browser, which can hijack user sessions, deface web sites, insert hostile content, conduct phishing attacks, and take over the user’s browser using scripting malware. The malicious script is usually JavaScript, but any scripting language supported by the victim’s browser is a potential target for this attack.

Of course, it's important to have a term or phrase that codifies a type of web application vulnerability. XSS serves this purpose quite well -- think of it as the Kleenex or Xerox of HTML injection vulnerabilities. On the other hand, there's clearly a fundamental problem with web application development and web browser design if such a long-standing vulnerability can continue to pose such a threat to web security.

Advice on creating a conference presentation

proto@hackculture.com (Mike) — Sat, 22 Nov 2008 02:49:00 +0000

Follow these five easy steps to create a presentation for a security conference. Don't bother asking for a Top Ten list. They're unnecessary and would take twice as long to implement anyway.

1. Select a title that includes a bad pun. If you can't think of a pun, then use a weak double entendre. Don't worry about the topic yet.

2. Use copious amounts of bullet points. Each slide should have at least 20 bullets. Use a smaller font if you find it difficult to fit that many on one page. Also consider that one bullet point counts as six punctuation characters. So, don't worry about periods, commas, or even capitalization; semi-colons are equally useless.

3. Omit any references to previous work on the same topic. This just makes the slide deck longer and confuses people who want to find out more information -- the lazy bastards can use a search engine.

4. Make a snide comment about Microsoft. This works very well if you used PowerPoint to make the slides.

5. Create a new acronym. This should preferably contain the word "cross" or "injection." Bonus points if you manage to think of an acronym that can be used as a pun. If it is a profanity, then you've spent too much time coming up with a snappy acronym -- get back on task and write some bullet points.

That's it! Your presentation is ready to satisfy most conferences' Call For Papers. If it gets rejected, then you probably forgot to litter the slides with quotes from Sun Tzu.

proto@hackculture.com (Mike) — Thu, 20 Nov 2008 23:29:00 +0000

Sing this corrosion to me

proto@hackculture.com (Mike) — Thu, 13 Nov 2008 20:00:00 +0000

Music to hack by. The Sisters of Mercy released Floodland 21 years ago on November 13, 1987.
To give some perspective, this was about a year before the first Internet Worm appeared. On November 2, 1988 the Morris Worm [more here] raged across the fledgling Internet. It spread using a command injection attack against Sendmail, a buffer overflow against fingerd, and brute force password guessing against rsh and rexec. Twenty years later, web applications still suffer from these exact types of vulnerabilities.

Does Web 2.0 need Web Security 2.0?

proto@hackculture.com (Mike) — Tue, 21 Oct 2008 19:52:00 +0000

Abstract for a presentation submitted to RSA 2009. Stay tuned for details as the slides creep closer to completion.

Web 2.0 fueled a growth of web applications focused on collaboration, social networking, user-driven content, and highly interactive UI design. The move towards web sites that acted more like traditional desktop applications introduced new risks to users’ data and exposed more complex vulnerabilities that weren’t necessarily non-existent before Web 2.0, but became more prevalent. This presentation highlights new trends in web vulnerabilities and how those vulnerabilities are becoming increasingly profitable to exploit.

The underlying technologies of Web 2.0, oftened summed up in the term AJAX, as well as HTTP itself still face the same problems that web developers have faced since the web browser was born. Old, well-defined and understood vulnerabilities still crop up in modern web applications. So, even as security looks toward identifying and addressing new types of vulnerabilities it’s important to evaluate how those dusty vulnerabilities still have an impact on web sites. Equally important is the distinction between attacks targeting the web application and attacks that target web browsers, because the browser is becoming more and more central to storing and manipulating personal information.

As web applications evolve in complexity and adopt new technologies, security methodologies and tools must be sure to keep pace. This presentation looks at the current state of web security in order to offer insight into what’s needed for Web Security 2.0 in order for it to stay relevant to the challenges faced by today’s web applications.

[In other words, how well do web scanners deal with "modern" web sites? Do they even need to?]

Good morning, Worm, Your Honor

proto@hackculture.com (Mike) — Thu, 14 Aug 2008 19:00:00 +0000

[This was originally posted August 2003 on the now-defunct vulns.com site before the Samy worm and sophisticated XSS attacks appeared. In the five years since this was first posted, web applications still struggle with fixing XSS and SQL injection vulnerabilities. In fact, it's still possible to discover web sites that put raw SQL statements in URL parameters.]

With the advent of the Windows RPC-based worm, security pros once again loudly lament the lack of patched servers, security-aware power users once again loudly blast Microsoft for (insert favorite negative adverb here) written code, and company parking lots at midnight still have a few sticker-laden cars of sysadmins fixing the problem. Of course, there are a few differences such as Joe and Jane's home computers have been caught red-handed showing vulnerable ports (unlike SQL Slammer or the IIS worm of the month which targeted servers not usually found in home networks), but the usual suspects still linger.

In fact, we could diverge onto many different topics when talking about worms. For starters, what's the point of arguing against full disclosure when worms arise weeks (SQL Slammer, our RPC friend) or months (Nimda and Code Red) AFTER the patch has been released? Obviously, that sidesteps many arguments against full-disclosure but it's food for thought. What about the plethora of port scanners and one-time "freebie scanners" that security companies pump out to capitalize the hysteria? Yes, there are administrators who don't know what's on their network, but I'm willing to bet there's a larger number of administrators trying to figure out how to test, update, and manage a patch for 100, 1,000, or 5,000+ systems. You can't release a patch and expect it to be applied to 1,000 servers within 24 hours. The tools to manage the patch process are too few, while the number of scanners is overwhelming. That's not to say that security scanning isn't necessary -- it's just a small part of the process. Administrators need help with patch testing, installation, and management.

Okay, so I've diverged onto a few topics already; but the one I wanted to highlight is what happens when a worm exploits a Web Application vulnerability? Cgisecurity.com has a nice essay on one concept of such a worm. How easily could one spread? It may not be hard with a SQL injection and xp_cmdshell(). Who will be the scapegoat? It probably won't involve cute references to "Billy Gates." You can't blame administrators for not being able to download a universal patch (although some ISAPI filters or Apache modules could prevent a lot of attacks). In the end, you have to return to the programmers. They must be aware that Web applications have vulnerabilities that don't fall into the bloated category of "Buffer Overflow."

Buffer overflows are sexy to report when they involve popular software. Plus, it's nice to see a group doing security research for fun. Yet when a worm finally targets Web applications, nmap and vulnerability scanners in the nature of nikto or nessus probably won't cut it when administrators want to check if their Web applications are vulnerable. Instead, they'll want web application-aware tools to check live systems and code review tools to audit the source code. The proliferation of buffer overflows has led to some useful code review tools and compilers that can spot a minority of potential overflow vulnerabilities. The OWASP is a good start. Hopefully, the tools to audit web applications and review source code will reach a point so that the next worm won't spread through e-commerce applications. Everyone talks about how much worse a buffer overflow-based worm could have been, but a worm that gathers passwords and collects credit card numbers from an e-commerce application has more implications for the average Internet user than a worm erasing a company's hard drives.

So, so you think you can tell

proto@hackculture.com (Mike) — Wed, 30 Jul 2008 19:00:00 +0000

[This was originally posted July 2003 on the now-defunct vulns.com site. Even after five years, no web application scanner can automatically identify these types of problems in a reliable, accurate manner -- many vulnerabilities still require human analysis.]

Sit and listen to Pink Floyd’s album, Wish You Were Here. “Can you tell a green field from a cold steel rail?” Yes. Could you tell a buffer overflow from a valid username in a Web application? Yes again. What about SQL injection, cross-site scripting, directory traversal attacks, or appending “.bak” to every file? Once again, Yes. In fact, many of these attacks have common signatures that could be thrown into Snort or passed through a simple grep command when examining application log files. These are the vulnerabilities that are reported most often on sites like www.cgisecurity.com or www.securityfocus.com. And they pop up for good reason: they’re dangerous and quickly cripple an e-commerce application.

On the other hand, a different category of attacks has not yet crept far enough into the awareness of security administrators and application programmers: session attacks. There are several reasons for this relative obscurity. No automated tool does a proper job of identifying session vulnerabilities without customization to the application. There are no defined signatures to try, as opposed to the simpler single quote insertion for a SQL injection test. Most importantly, session state vulnerabilities vary significantly between applications.

The consequence of session attacks is no less severe than a good SQL injection that hits xp_cmdshell. Consider last May’s Passport advisory in which an attacker could harvest passwords with tools no more sophisticated than a Web browser. The attack relies on selecting proper values for the “em” (victim’s e-mail) and “prefem” (attacker’s e-mail) parameters to the emailpwdreset.srf file. It should really be stressed that nowhere in this attack were invalid characters sent to the server. Both parameters were attacked, but the payload contained valid e-mail addresses – not e-mail addresses with single quotes, long strings, Unicode encoded characters, or other nefarious items.

The attack succeeded for two major reasons. The e-mail addresses are exposed to the client, rather than tracked on the server in a session object. The four steps ostensibly required for a user to complete the password reminder process did not have to be performed in sequential order, which demonstrates lack of a strong state mechanism.

It seems that most buffer overflow-style attacks against operating systems or Internet servers such as IIS or Apache have led to site defacements or denial of service attacks. Yet as e-commerce has grown with Web applications, so have the vulnerabilities moved on from buffer overflows. Plus, the attacks against Web applications no longer lead to site defacement, but to identity or financial theft (credit cards). Thus, vulnerabilities that used to affect only the server’s owners (and perhaps annoy users who can’t access the service for a period) now include Web application vulnerabilities that quite directly affect users.

As administrators and programmers, we need to be aware of all the vulnerabilities that crop up in Web applications – not just the easy (yet still important!) ones that currently populate the Web vulnerability encyclopedia.

Off-Topic Horror

proto@hackculture.com (Mike) — Mon, 03 Mar 2008 11:33:00 +0000

On this day in 1692, Elizabeth Selwyn was accused of witchcraft and burned at the stake.

[Christopher Lee was in many classic cult films before he played Saruman. This one isn't exactly subtle, but none the less builds a tense atmosphere.]

Off-Topic Horror

proto@hackculture.com (Mike) — Fri, 04 Aug 2006 00:45:00 +0000

Rosemary and Guy Woodhouse receive word that an apartment in the Bramford has become available. It was a Tuesday.

[A classic by Ira Levin from 1967.]

AHT3 Review

proto@hackculture.com (Mike) — Thu, 13 Jul 2006 21:23:00 +0000

The Register has a review of the third edition. It hits on exactly what we're trying to convey:

As you would expect from a book devoted to tools, the focus on the book is decidedly practical. That's not to say that it's just a glorified all-in-one manual for the tools that are covered. It's the material on usage that makes the book valuable, it shows how the tools can be used to attack (or seek out vulnerabilities in) networks and servers.

Automating SQL Injection

proto@hackculture.com (Mike) — Wed, 01 Mar 2006 18:28:00 +0000

Presentation on SQL injection techniques for enumerating data via inference (also known as blind SQL injection). It was prepared for IT Underground Berlin 2006 (pdf). Unfortunately, the conference was cancelled.

[The images are from John Carpenter movies.]