-
Here’s an HTML injection (aka cross-site scripting) example that’s due to a series of tragic assumptions that conspire to not only leave the site vulnerable, but waste lines of code doing so.
The first clue to the flaw lies in the querystring’s
stateparameter. The site renders thestatevalue into atitleelement. Naturally, a first test payload for HTML injection would be attempting to terminate that element. If that works, then a more impactful followup would be to append arbitrary markup such as<script>tags. A simple probe looks like this:https://web.site/cg/aLink.do?state=abc%3C/title%3EThe site responds by stripping the payload’s
</title>tag and all subsequent characters. Only the text leading up to the injected tag is rendered within thetitle.<HTML> <HEAD> <TITLE>abc</TITLE>This seems to have effectively countered the attack. Of course, if you’ve been reading this blog for a while, you’ll suspect this initial countermeasure won’t hold up – that which seems secure shatters under scrutiny.
The developers worried that an attacker might try to inject a closing
</title>tag. Consequently, they created a filter to watch for such payloads and strip them. This could be implemented as a basic case-insensitive string comparison or a trivial regex.And it could be bypassed by just a few characters.
Consider the following closing tags. Regardless of whether they seem surprising or silly, the extraneous characters are meaningless to HTML yet meaningful to our exploit because they belie the assumption that regexes make good parsers.
<%00/title> <""/title> </title""> </title id="">After inspecting how the site responds to each of the above payloads, it’s apparent that the filter only expected a so-called “good”
</title>tag. Browsers don’t care about an attribute on the closing tag. They’ll ignore such characters as long as they don’t violate parsing rules.Next, we combine the filter bypass with a payload. In this case, we’ll use an image
onerrorevent.https://web.site/cg/aLink.do?state=abc%3C/title%20id=%22a%22%3E%3Cimg%20src=x%20onerror=alert%289%29%3EThe attack works! We should have been less sloppy and added an opening
<TITLE>tag to match the newly orphaned closing one. A nice exploit won’t leave the page messier than it was before.<HTML> <HEAD> <TITLE>abc</title id="a"> <img src=x onerror=alert(9)> Vulnerable & Exploited Information Resource Center</TITLE>The tragedy of this flaw is that it shows how the site’s developers were aware of the concept of HTML injection exploits, but failed to grasp the underlying principles of the vuln. The effort spent blocking an attack (i.e. countering an injected closing tag) not only wasted lines of code on an incorrect fix, but instilled a false sense of security. The code became more complex and less secure.
The mistake also highlights the danger of assuming that well-formed markup is the only kind of markup. Browsers are capricious beasts. They must dance around typos, stomp upon (or skirt around) errors, and walk bravely amongst bizarrely nested tags. This syntactic havoc is why regexes are notoriously worse at dealing with HTML than proper parsers.
There’s an ancillary lesson here in terms of automated testing (or quality manual pen testing, for that matter). A scan of the site might easily miss the vuln if it uses a payload that the filter blocks, or doesn’t apply any attack variants. This is one way sites “become” vulnerable when code doesn’t change, but attacks do.
And it’s one way developers must change their attitudes from trying to outsmart attackers to focusing on basic security principles.
• • • -
You taught me language, and my profit on’t
Is, I know how to curse: the red plague rid you,
For learning me your language!
– Caliban (The Tempest, I.ii.363-365)
The announcement of the Heartbleed vulnerability revealed a flaw in OpenSSL that could be exploited by a simple mechanism against a large population of targets to extract random memory from the victim. At worst, that pilfered memory would contain sensitive information like HTTP requests (with cookies, credentials, etc.) or even parts of the server’s private key. Or malicious servers could extract similarly sensitive data from vulnerable clients.
In the spirit of Caliban, Shakespeare’s freckled whelp, I combined a desire to learn about Heartbleed’s underpinnings with my ongoing experimentation with the new language features of C++11. The result is a demo tool named Hemorrhage.
Hemorrhage shows two different approaches to sending modified TLS heartbeats. One relies on the Boost.ASIO library to set up a TCP connection, then handles the SSL/TLS layer manually. The other uses a more complete adoption of Boost.ASIO and its asynchronous capabilities. It was this async aspect where C++11 really shone. Lambdas made setting up callbacks a pleasure — especially in terms of readability compared to prior techniques that required binds and placeholders.
Readable code is hackable (in the creation sense) code. Being able to declare variables with
automade code easier to read, especially when dealing with iterators. Although hemorrhage only takes minimal advantage of themoveoperator andunique_ptr, they are currently my favorite aspects following lambdas andauto.Hemorrhage itself is simple. Check out the README.md for more details about compiling it. (As long as you have Boost and OpenSSL it should be easy on Unix-based systems.)
The core of the tool is taking the
tls1_heartbeat()function from OpenSSL’sssl/t1_lib.cfile and changing the payload length — essentially a one-line modification. Yet another approach might be to use the originaltls1_heartbeat()function and modify the heartbeat data directly by manipulating theSSL*pointer’ss3->wrecdata via theSSL_CTX_set_msg_callback().In any case, the tool’s purpose was to “learn by implementing something” as opposed to crafting more insidious exploits against Heartbleed. That’s why I didn’t bother with more handshake protocols or STARTTLS. It did give me a better understanding of OpenSSL’s internals. But still, I’ll add my voice to the chorus bemoaning its readability.
• • • -
Silicon Valley green is made of people. This is succinctly captured in the phrase: When you don’t pay for the product, the product is you. It explains how companies attain multi-billion dollar valuations despite offering their services for free. They promise revenue through the glorification of advertising.
Investors argue that high valuations reflect a company’s potential for growth. That growth comes from attracting new users. Those users in turn become targets for advertising. And sites, once bastions of clean design, become concoctions of user-generated content, ad banners, and sponsored features.
Population Growth
Sites measure their popularity by a single serving size: the user. Therefore, one way to interpret a company’s valuation is in its price per user. That is, how many calories can a site gain from a single serving? How many servings must it consume to become a hulking giant of the web?
You know where this is going.
The movie Soylent Green presented a future where a corporation provided seemingly beneficent services to a hungry world. It wasn’t the only story with themes of overpopulation and environmental catastrophe to emerge from the late ’60s and early ’70s. The movie was based on the novel Make Room! Make Room!, by Harry Harrison. And it had peers in John Brunner’s Stand on Zanzibar (and The Sheep Look Up) and Ursula K. Le Guin’s The Lathe of Heaven. These imagined worlds contained people powerful and poor. And they all had to feed.
A Furniture Arrangement
To sell is to feed. To feed is to buy.
In Soylent Green, Detective Thorn (Charlton Heston) visits an apartment to investigate the murder of a corporation’s board member, i.e. someone rich. He is unsurprised to encounter a woman there and, already knowing the answer, asks if she’s “the furniture.” It’s trivial to decipher this insinuation about a woman’s role in a world afflicted by overpopulation, famine, and disparate wealth. That an observation made in a movie forty years ago about a future ten years hence rings true today is distressing.
We are becoming products of web sites as we become targets for ads. But we are also becoming parts of those ads. Becoming furnishings for fancy apartments in a dystopian New York.
Women have been components of advertising for ages, selected as images relevant to manipulating a buyer no matter the irrelevance of their image to the product. That’s not changing. What is changing is some sites’ desire to turn all users into billboards. They want to create endorsements by you that target your friends. Your friends are as much a commodity as your information.
In this quest to build advertising revenue, sites also distill millions of users’ activity into individual recommendations of what they might want to buy or predictions of what they might be searching for.
And what a sludge that distillation produces.
There may be the occasional welcome discovery from a targeted ad, but there is also an unwelcome consequence of placing too much faith in algorithms. A few suggestions can become dominant viewpoints based more on others’ voices than personal preferences. More data does not always mean more accurate data.
We should not excuse an algorithm as an impartial oracle to society. They are tuned, after all. And those adjustments may reflect the bias and beliefs of the adjusters. For example, an ad campaign created for UN Women employed a simple premise: superimpose upon pictures of women a search engine’s autocomplete suggestions for phrases related to women. The result exposes biases reinforced by the louder voices of technology. More generally, a site can grow or die based on a search engine’s ranking. An algorithm collects data through a lens. It’s as important to know where the lens is not focused as much as where it is.
There is a point where information for services is no longer a fair trade. Where apps collect the maximum information to offer the minimum functionality. There should be more of a push for apps that work on an Information-to-Functionality relationship of minimum requested for the maximum required.
Going Home
In the movie, Sol (Edward G. Robinson) talks about going Home after a long life. Throughout the movie, Home is alluded to as the ultimate, welcoming destination. It’s a place of peace and respect. Home is where Sol reveals to Detective Thorn the infamous ingredient of Soylent Green.
Web sites want to be your home on the web. You’ll find them exhorting you to make their URL your browser’s homepage.
Web sites want your attention. They trade free services for personal information. At the very least, they want to sell your eyeballs. We’ve seen aggressive escalation of this in various privacy grabs, contact list pilfering, and weak apologies that “mistakes were made.”
More web sites and mobile apps are releasing features outright described as “creepy but cool” in the hope that the latter outweighs the former in a user’s mind. Services need not be expected to be free without some form of compensation; the Web doesn’t have to be uniformly altruistic. But there’s growing suspicion that personal information and privacy are being undervalued and under-protected by sites offering those services. There should be a balance between what a site offers to users and how much information it collects about users (and how long it keeps that information).
The Do Not Track effort fizzled, hobbled by indecision of a default setting. Browser makers have long encouraged default settings that favor stronger security, they seem to have less consensus about what default privacy settings should be.
Third-party cookies will be devoured by progress; they are losing traction within the browser and mobile apps. Safari has long blocked them by default. Chrome has not. Mozilla has considered it. Their descendants may be cookie-less tracking mechanisms, which the web titans are already investigating. This isn’t necessarily a bad thing. Done well, a tracking mechanism can be limited to an app’s sandboxed perspective as opposed to full view of a device. Such a restriction can limit the correlation of a user’s activity, thereby tipping the balance back towards privacy.
If you rely on advertising to feed your company and you do not control the browser, you risk going hungry. For example, only Chrome embeds the Flash plugin. An eternally vulnerable plugin that coincidentally plays videos for a revenue-generating site.
There are few means to make the browser an agent that prioritizes a user’s desires over a site’s. The Ghostery plugin is one tracking countermeasure available for all major browsers. Mozilla’s Lightbeam experiment does not block tracking mechanisms by default; it reveals how interconnected tracking has become due to ubiquitous cookies.
Browsers are becoming more secure, but they need a site’s cooperation to protect personal information. At the very least, sites should be using HTTPS to protect traffic as it flows from browser to server. To do so is laudable yet insufficient for protecting data. And even this positive step moves slowly. Privacy on mobile devices moves perhaps even more slowly. The recent iOS 7 finally forbids apps from accessing a device’s unique identifier, while Android struggles to offer comprehensive tools.
The browser is Home. Apps are Home. These are places where processing takes on new connotations. This is where our data becomes their food.
Soylent Green’s year 2022 approaches. Humanity must know.
• • •