The Firefox add-in Firesheep caused quite an uproar a few weeks ago, and justifiably so. Here's how it works:
•Connect to a public, unencrypted WiFi network. In other words, a WiFi network that doesn't require a password before you can connect to it.
•Install Firefox and the Firesheep add-in.
•Wait. Maybe have a latte while you're waiting.
•Click on the user / website icons that appear over time in Firesheep to instantly log in as that user on that website.
Crazy! This guy who wrote Firesheep must be a world-class hacker, right?
Well, no. The work to package this up in a point-and-click way that is (sort of) accessible to power users is laudable, but what Firesheep actually does is far from magical. It's more of an art project and PR stunt than an actual hack of any kind. Still, I was oddly excited to see Firesheep get so much PR, because it highlights a fundamental issue with the architecture of the web.
The web is kind of a primitive medium. The only way websites know who you are is through tiny, uniquely identifiying strings your browser sends to the webserver on each and every click:
GET / HTTP/1.1
Host: diy.stackexchange.com
Connection: keep-alive
User-Agent: Chrome/7.0.517.44
Accept-Language: en-US,en;q=0.8
Cookie: diyuser=t=ZlQOG4kege&s=8VO9gjG7tU12s
If-Modified-Since: Tue, 09 Nov 2010 04:41:12 GMT
These are the typical sort of HTTP headers your browser sends to a website on every click. See that little cookie in bright red? To a website, that's your fingerprint, DNA, and social security number all rolled into one. Some part of the cookie contains a unique user ID that tells the website you are you.
And guess what? That cookie is always broadcast in plain text every single time you click a link on any website. Right out in the open where anyone -- well, technically, anyone who happens to be on the same network as you and is in a position to view your network packets -- can just grab it out of the ether and immediately impersonate you on any website you are a member of.
Now that you know how cookies work (and I'm not saying it's rocket surgery or anything), you also know that what Firesheep does is relatively straightforward:
1.Listen to all HTTP traffic.
2.Wait for HTTP headers from a known website.
3.Isolate the part of the cookie header that identifies the user.
4.Launch a new browser session with that cookie. Bam! As far as the target webserver is concerned, you are that user!
All Firesheep has to do, really, is listen. That's pretty much all there is to this "hack". Scary, right? Well, then you should be positively quaking in your boots, because this is the way the entire internet has worked since 1994, when cookies were invented.
So why wasn't this a problem in, say, 2003? Three reasons:
1.Commodity public wireless internet connections were not exactly common until a few years ago.
2.Average people have moved beyond mostly anonymous browsing and transferred significant parts of their identity online (aka the Facebook effect).
3.The tools required to listen in on a wireless network are slightly … less primitive now.
Firesheep came along at the exact inflection point of these three trends. And mind you, it is still not a sure thing -- Firesheep requires a particular set of wireless network chipsets that support promiscuous mode in the lower level WinPcap library that Firesheep relies on. But we can bet that the floodgates have been opened, and future tools similar to this one will become increasingly a one-click affair.
The other reason this wasn't a problem in 2003 is because any website that truly needed security switched to encrypted HTTP -- aka Secure HTTP -- long ago. HTTPS was invented in 1994, at the same time as the browser cookie. This was not a coincidence. The creators of the cookie knew from day one they needed a way to protect them from prying eyes. Even way, way back in the dark, primitive ages of 2003, any banking website or identity website worth a damn wouldn't even consider using plain vanilla HTTP. They'd be laughed off the internet!
The outpouring of concern over Firesheep is justified, because, well, the web's cookie jar has always been kind of broken -- and we ought to do something about it. But what?
Yes, you can naively argue that every website should encrypt all their traffic all the time, but to me that's a "boil the sea" solution. I'd rather see a better, more secure identity protocol than ye olde HTTP cookies. I don't actually care if anyone sees the rest of my public activity on Stack Overflow; it's hardly a secret. But gee, I sure do care if they somehow sniff out my cookie and start running around doing stuff as me! Encrypting everything just to protect that one lousy cookie header seems like a whole lot of overkill to me.
I'm not holding my breath for that to happen any time soon, though. So here's what you can do to protect yourself, right now, today:
1.We should be very careful how we browse on unencrypted wireless networks. This is the great gift of Firesheep to all of us. If nothing else, we should be thanking the author for this simple, stark warning. It's an unavoidable fact of life: if you must go wireless, seek out encrypted wireless networks. If you have no other choices except unencrypted wireless networks, browse anonymously -- quite possible if all you plan to do is casually surf the web and read a few articles -- and only log in to websites that support https. Anything else risks identity theft.
2.Get in the habit of accessing your web mail through HTTPS. Email is the de-facto skeleton key to your online identity. When your email is compromised, all is lost. If your webmail provider does not support secure http, they are idiots. Drop them like a hot potato and immediately switch to one that does. Heck, the smart webmail providers already switched to https by default!
3.Lobby the websites you use to offer HTTPS browsing. I think we're clearly past the point where only banks and finance sites should be expected to use secure HTTP. As more people shift more of their identities online, it makes sense to protect those identities by moving HTTPS from the domain of a massive bank vault door to just plain locking the door. SSL isn't as expensive as it used to be, in every dimension of the phrase, so this is not an unreasonable thing to ask your favorite website for.
This is very broad advice, and there are a whole host of technical caveats to the above. But it's a starting point toward evangelizing the risks and responsible use of open wireless networks. Firesheep may indeed have broken the web's cookie jar. But it was kind of an old, beat up, cracked cookie jar in the first place. I hope the powers that be will use Firesheep as incentive to build a better online identity solution than creaky old HTTP cookies.
Comments
> if you must go wireless, seek out encrypted wireless networks.
Is this enough?
I'm quite sure that with WEP or WPA or WPA2 without Radius-servers etc., where everyone uses a common password that is the same for every user, this does not help:
If someone knows that password and is inside the encrypted wireless network, he should be able to run Firesheep and capture the traffic of everyone else in the same network.
The only solution for using public wifi is to always use a VPN of a trusted entity, e.g. your company. Of course it must be setup to send all web surfing over the vpn
Bugmenot5 on November 14, 2010 12:01 AM
@Bugmenot5,
WPA generates a unique encryption key for every connection. The key you type is only used for the connection, after that everything is encrypted with a separate key. That's why free public networks are starting to use WPA2 with the key "free" (or something similar). This way nobody can sniff your traffic (except for the router), as the connection between your computer and the router is encrypted.
Mircea Chirea on November 14, 2010 12:06 AM
Nice article! There' s also another case in which unencrypted network are used to steal credentials: when somebody leaves the connection open and set up a proxy in order to pretend to be the server of interest, in which case even ssl wouldn' t save you because being the proxy the one that does the ssl handshake(instead of the original server), you get your credential stolen again. So it' s always better not to rely on free wifi networks, even when using ssl.
And btw, do you mind offering https browsing? :D
cheers!
Omissis on November 14, 2010 12:12 AM
@Mircea Chirea
Bugmenot5 is right. In a standard WPA2 setup, as long as the attacker is listening when you connect to the network, encryption is not sufficient.
WPA2 uses PTK for private transmission between the AP and each client, but in order to set up the PTK channel, it has to send the key to the client in the first case. This is done via the broadcast GTK, and any users who are already connected to the network (authorized users) can intercept the key that is sent. That is, if I am on the network when you connect, then I will see the key the AP sends you via GTK that you will use to encrypt your PTK messages, and thus I can trivially decrypt each one. Further, if I have the right tools, I can force you to disconnect and reconnect, so even if you connected before I did, it won't really matter that much (just an extra step).
Even in the case where the right tools are set up to prevent this attack (and doing so is far beyond the reach of most coffee shops), there are other proven man-in-the-middle attacks against WPA2. Assuming that WPA2 will protect you is not a good idea. Here's an example:
http://www.networkworld.com/newsletters/wireless/2010/072610wireless1.html
VPN is an excellent suggestion; if you have a host somewhere you trust that can serve as a proxy for all of your web traffic then using it through VPN, SSH tunnel, or otherwise, it is a great way to protect yourself.
TL;DR: wireshark can still snoop your traffic if it is on the network before you; wpa2 isn't good enough, but VPN is
Olpersonality on November 14, 2010 12:26 AM
For nitpickers, let me be more clear:
Vulnerable:
WEP
WPA/WPA2 Personal using Wireshark
WPA Enterprise using brute force
WPA2 Personal/Enterprise with TKIP using brute force
Harder but Vulnerable:
WPA2 Enterprise AES
Perfect:
...
For Wireshark's excellent "How To Decrypt 802.11" website:
http://wiki.wireshark.org/HowToDecrypt802.11
Do you trust your coffee shop to use the right wireless security settings? If not, the above advice - "be very careful how we browse on unencrypted wireless networks" - is insufficient. Be very careful how you browse on any network you don't trust, period, and if you're very worried about security, tunnel.
Olpersonality on November 14, 2010 12:58 AM
Another con with https is that nothing gets cached on the client, so every css, image, js etc has to be fetched on every page load.. Btw, doesnt everybody use 3g/4g these days? Free wlan feels so 2005 :P
Carlhoerberg on November 14, 2010 1:03 AM
Thank you Jeff for this amazing email. We can actually can call it "Firesheep Anatomy" :)
Ahmed Magdy on November 14, 2010 1:05 AM
For immediate purposes, its good to have BlackSheep installed to detect if any one is running Firesheep on your unsecured Wifi
http://research.zscaler.com/2010/11/blacksheep-tool-to-detect-firesheep.html
Swaroop on November 14, 2010 1:07 AM
Am I missing something or does this only work if a security system authenticates by only a cookie check? For example if you would have the auth system compare your HOST + IP + cookie + session_id everything would be fine? I thought it was more common to use sessions than cookies for authentication nowadays....
Oskar Schöldström on November 14, 2010 1:24 AM
@Swaroop,
BlackSheep does nothing interesting; it is, in fact, a DDoS against facebook.
Blog on November 14, 2010 1:31 AM
@Oskar Schöldström
I am quite sure that the session_id is what is stored in a cookie. If more parameters than the session id was required, i would guess you could just sniff them out of the HTTP header as well.
Andreas Vinter-hviid on November 14, 2010 2:01 AM
.. what about HTTP Digest Authentication?
Mikekelly85 on November 14, 2010 2:39 AM
@oskar: as @andreas already mentioned, no matter what session mechanism you use, there are only two ways to link a client-side user with a server-side session: via cookies or via a URL parameter. You can encrypt the session id all you want but if somebody simply steals it, they are you.
You are right though that you could perform additional checks on the server-side, for example by IP, hostname, user-agent, etc. That will help a bit. Another helpful strategy is to regularly regenerate the session id. These will reduce but not eliminate the fundamental issue of shared physical network access.
Fchristant on November 14, 2010 3:12 AM
Firefox users should probably consider installing HTTPS Everywhere: https://www.eff.org/https-everywhere
eetu on November 14, 2010 3:20 AM
IF you are using Chrome, I wrote an extension called Fidelio that will automatically rewrite requests to https for certain sites (Facebook and Twitter by default, but you can add more in options):
http://github.com/nikcub/fidelio
unlike other extensions, it will also rewrite all your cookies and set the secure flag, so that you session is not passed in the clear during the initial request before the plugin gets a chance to rewrite it. The cookies are set to secure as soon as you install the extension or add a site in options.
Nikcub on November 14, 2010 3:49 AM
Browsing anonymously is quite difficult. I, and I assume a lot of other people, tick the remember me box on most websites. Your browser will send the corresponding cookies without you having to explicitly indicate that you want to log in.
So the best option is to use a separate browser or browser profile when you have to browse over an unencrypted and untrusted network.
Johan on November 14, 2010 3:55 AM
Jeff, I think I remember you tweeting about having to deal with a popular OpenID provider that had an expired certificate.
Then there are web mail providers / rss reader providers that don't deal well (if at all) with mixed content.
Then there are sites with home grown ad networks that don't do well with mixed content and each ad wants to set a new cookie.
The point being, until people actually learn how to implement https correctly and how to interpret browser warnings, a lot of 'facebookers' are just going to use a link that doesn't present warnings.
We have "Don't drink and drive" , yet people do it.
We have "Don't smoke in bed" and it seems that people are finally waking up to the danger of that, but way after burning to death was the consequence at hand.
Barring the invention of a reverse multicast mind meld that works via osmosis, we aren't going to get the majority of people that use web browsers to follow good practices. HTTP was never, ever meant to do what it is doing.
And now, we won't rest until the majority of the developed world has some kind of wifi enabled 'pad' in their hands, ensuring that they have several more inches of screen real estate to utilize at their every convenience when screwing up.
Do not transmit information that you don't want anyone else to have over the public internet, period. Anything beyond that is a calculated gamble.
It's going to be years before the public at large starts 'calculating' prior to taking that gamble.
Tinkertim on November 14, 2010 4:31 AM
Yet codinghorror.com doesn't support HTTPS. Hypocrite.
bah on November 14, 2010 4:43 AM
Mikekelly85 is right, you should have mentioned HTTP Digest.
Adish876 on November 14, 2010 5:32 AM
I wrote a short post about this:
http://restafari.blogspot.com/2010/11/cookies-are-gross.html
Mikekelly85 on November 14, 2010 6:10 AM
Thats only when a service checks just for a valid cookie. One can make it secure for users by also considering the IP address while generating the cookie.
e.g: An MD5 of the userid-IPaddress-SecretKey
Omtalk on November 14, 2010 6:11 AM
>> build a better online identity solution than creaky old HTTP cookies.
We did. 5o9 Inc.
Cheers,
Peter
Cranstone on November 14, 2010 7:29 AM
Just for fun, I turned on a unencrypted router at work (router was not connected to any network). Within minutes I had almost 100 connections. What this suggests to me is that the majority of people have no idea what WEP, WAP, HTTPS or TKIP is. Could this possibly why identity theft continues to rise. To me, education is the only solution. The problem is that only the people who know about Firesheep know about the dangers of unencrypted data.
App_Anarchy on November 14, 2010 7:29 AM
Github team also commented on this issue, and how they started dealing with it by setting secure flag and https for critical actions: https://github.com/blog/737-sidejack-prevention
Metaphysicaldeveloper.wordpress.com on November 14, 2010 7:40 AM
Considering that only you and the service provider (i.e. your bank) benefit from security, and that local hardware (WiFi router) is far more vulnerable to attacks than your/bank's hardware, HTTPS is the best option by far.
I think all web traffic should be encrypted, though we'd need to work on how browsers cache it etc. HTTPS is cheap enough to be used everywhere -- it shouldn't increase your CPU load by more than 1-2%.
I think that a great way to make people use encryption more would be to issue free SSL certificates with every new domain name sold.
Michał Tatarynowicz on November 14, 2010 8:16 AM
- SSL certs can be had for less than $10 these days. Cost is not an issue.
- Hardware impact is negligible.
- Browsers DO cache CSS and other resources, if the correct headers are sent. By default they are not written to disk.
obijan on November 14, 2010 9:05 AM
That's non-sequitur.
Better on-line identity will not solve problem of unencrypted traffic. Any identity solution will be vulnerable unless:
1.
Browser expects to get secure protocol and will refuse to fall back to an older one. Without this you can do MITM swapping new, secure protocol for old leaky one (e.g. replace Digest authentication with Basic auth).
2.Browser can verify identity of server using other/trusted communication channel (SSL does that by storing CA certificates offline). Without this you'll be securely sending your identity to an attacker spoofing a server.
1.All traffic has to be encrypted and tamper-proof. If you only protect identity, then attacker performing MITM can perform replay attack, change request parameters, steal data, etc. — you're still exposed to lot of risks.
kl on November 14, 2010 9:09 AM
It would seem this Firesheep would also work on wired connections within the same subnet. Is that not the case?
Jo and Kang Su G. on November 14, 2010 9:49 AM
To all the comments that says that checking for the IP secure anything :
Firesheep is used with the attacker on the SAME network as the victim, and except if you use a full IPv6 setup to communicate to an IPv6 server they will have the same IP seen from outside the LAN.
Black Fox on November 14, 2010 9:54 AM
"build a better online identity solution than creaky old HTTP cookies. "
Yeah we already have that. It's called HTTPS cookies, supported by all browsers, secure and has negligible costs to implement.
HTTPS is our only practical solution. Even if this Unobtainable solution were to be invented today, have zero per user cost to implement, somehow magically be simpler than SSL, be universally accepted, we would still have to wait months if not years for it to supported well enough in every browser and web server.
We _have_ the solution, we know it _works_, we know _how_ to use it, all we have to do _is_ use it.
Warll Dressler on November 14, 2010 10:44 AM
"Lobby the websites you use to offer HTTPS browsing."
Jeff, have you ever tried:
https://stackoverflow.com/
?
It greets me with "The site's security certificate is not trusted!" and then further with Access Denied.
Isn't it ironic?
Dennis Gorelik on November 14, 2010 10:49 AM
HTTPS is not "overkill". In fact, given the somewhat broken certificate authority model that browsers impose, it's a bit underkill.
First of all, it's not too slow. See the links here - http://twitter.com/glyph/status/2958424706916352 - so there's no real reason to consider it 'overkill' if it's not taking up an unreasonable amount of resources.
Second of all, any "better" identity solution must necessarily involve crypto. So, why go to the massive amount of trouble to create a new cryptographic standard when the existing one is adequate? Keep in mind that if the stuff other than your "identity" isn't protected, your identity isn't really protected either. Active attacks aren't significantly harder than passive attacks on unencrypted traffic; if your authentication is encrypted but the commands you're performing aren't, an attacker could just as trivially capture your outgoing commands and modify them rather than modify your authentication.
Or, alternately, if you are concerned about people being able to masquerade as you, and you're using authenticated, encrypted connections, but the people reading your activity aren't, then the attackers can just spoof them instead of you.
So, turn on https on stackoverflow, please, and stop advocating for some mythical broken solution when a very real, working one already exists. The biggest problem here is that everyone thinks they understand the problem but very few people really do. So, while "Use HTTPS" is an oversimplification, it's the only message that is going to get through: if you say "Use HTTPS because there's nothing better but we should really come up with some better thing" then lots of people are going to take away "Oh, I should wait until there's a better thing, until then I'll just use HTTP and ignore the problem".
Glyph on November 14, 2010 12:15 PM
Several people have proposed combining and IP check with the cookie check. That doesn't work, however - many of these open WiFi routers are NATed, so the FireSheep connection will appear to come from the same IP that was issued the cookie. In fact, short of HTTPS or other similar encryption protocols, there is no solution. The required solution must be immune to forgery or to replay attacks; a give set of credentials must be unusable by anyone other than the sender and replaying a set of stolen credentials must not work. Given the stateless nature of HTTP, this is incredibly difficult to enforce, as the protocol doesn't provide a means to negotiate the necessary changes in magic numbers.
A solution could be approached using cryptographic signatures over some data including a timestamp and a nonce, but the current browsing technology doesn't make that a viable solution unless everything is done in JavaScript (thereby further breaking the Web).
Michael on November 14, 2010 12:31 PM
Hi Jeff,
Great post, thanks for clearly thinking this through and you no doubt understand most of the problem and what's happening to make it all possible.
Regarding your stance that Stack Overflow should not be SSL to protect the auth cookie, if there were some mechanism to somehow lock a browsing user to their session such that it couldn't be stolen/replayed/whatever by a passive attacker, what about active attacks? What about Man in the Middle attacks, where someone injects JS in to your page and performs actions as you by those means? This could happen on the local network, at your ISP, or by your government depending on what your personal threat model is. For protection against that, you need integrity and authentication, two things that SSL does very well. Add in privacy with symmetric crypto essentially for free (really, because you'd already be doing public-key operations to get authentication, and SSL/TLS session resumption make this quite fast after those operations are finished initially) - why not go with SSL for this?
Obviously I'm using Stack Overflow as an example here, not to poke and troll at you - I trust you can think about this idea as it applies to many other sites.
Do you have any thoughts on Google's SPDY (http://dev.chromium.org/spdy)? It stands to fix a lot of the problems with HTTP and streamline things. The security model there appears to just default to having everything be in an SSL channel, vs an option.
Thanks!
Ian Gallagher
Firesheep co-dev/co-presenter
Ian on November 14, 2010 12:58 PM
"If you have no other choices except unencrypted wireless networks, browse anonymously"
I think you need to be a little clearer about this statement. In the age of Facebook "Like" buttons on every damn page, if you browse with your regular browser that has the Facebook login saved, then you're sending Facebook cookies even as you browse other sites that are nothing to do with Facebook. To really browse anonymously you need to use an alternate browser with no saved credentials. Something like Opera is good because you can completely clear your saved data at the end of each session. (And even then, Flash cookies persist...)
Julian Melville on November 14, 2010 1:39 PM
I hardly think that all-encrypted traffic is 'boiling the seas'. As others write - it should be the bare minimum.
The second you tell everyday people that almost everything they read, write, click, view, etc are completely readable by anyone in the middle (governments included) they are noticeably, and understandably, upset.
Like most people, I don't have anything to hide, but that doesn't mean we don't value our privacy.
Maybe it doesn't matter to you if people know what products you like on Amazon, or how often you visit thinkgeek, or if you have a predilection for anime. Maybe you descend from the Dutch and never draw the blinds on your house. Good for you, but most people expect a modest amount of privacy and do not want someone else linking all their habits together (if they're lucky, it's just to sell them something).
Otherwise things become far too Orwellian for my liking. There's no need for 2-way tv's in them if you can glean all you need from someone's online life simply by capturing some of their traffic, or watching the websites they frequest.
SSL is cheap, and for a modestly-size site, SSL offloading firewalls are easy for an experienced sys admin.
Frank Black on November 14, 2010 1:55 PM
So, where do I go to lobby Stack Overflow and the other Stack Exchange sites to switch to https? While I'm only an infrequent user of the site, I can imagine other user's could be quite irked by the reputation hit that could be caused by someone hijacking their cookies - especially if they're using that reputation as part of their credentials/CV.
Stuart Jones on November 14, 2010 2:17 PM
SessionLock and SessionLock Lite (to a lesser extent) present a partial SSL solution: http://benlog.com/articles/2010/10/25/keep-your-hands-off-my-session-cookies/
George V. Reilly on November 14, 2010 4:54 PM
I assume then you never tried dsniff, which included a program (webspy) that did something very similar and has been around for a decade. It provided tools to sniff out sensitive data on a wired network.
As for a greater use of SSL for sensitive bits, if you want to make the web safer then push for better SNI (Server Name Indication) in servers and clients.
Joseph Scott on November 14, 2010 9:30 PM
Hey, does anyone else see the effects of bold text tag that didn't get closed properly in kl's comment? Or is it just me?
(I see it on latest firefox Ubuntu 10.10 and Windows XP, and I'm too lazy to inspect the html.)
http://i.imgur.com/4wAbm.png
David Czech on November 14, 2010 11:36 PM
Websites I've designed have used the technique Oskar describes to make a canonical string from data about the client, which is hashed to make a more individual session key. It works.
A hacker would need to fake a few details about a customer's active session to steal it. It's enough to not be the lowest hanging fruit.
HTTPS wouldn't be too much of a pain, except for maybe upgrading to a NIC that has full TCP IP and SSL chimney offload to accelerate it, and some possible problems with mixed HTTP/HTTPS content on the same page (ads), and that's probably the biggest barrier to wide-scale SSL adoption.
Luke
Lukepuplett on November 15, 2010 3:03 AM
Let's close this BOLD text first
Session ID's are saved through cookies, so if your security is based on sessions, it is based on cookies.
IP is pretty secure, but since the ip would come from the router / provider and not the computer, this adds nothing to prevent something like firesheep.
Also, people who use AOL have dynamic IP's, which can change at every request, breaking every site with IP-Based security.
User Agents are meh, it does add security, but not much.
Personaly I make sure that IF a session gets stolen, a person can't do TOO much damage, highly personal data (like credit-data) is only shown partialy and nothing personal can be changed without a password.
TL:DR
A website can't do much to prevent session theft so it is better to assume every session will be stolen and make sure nothing can go to hell if that happens.
JohanDam on November 15, 2010 5:12 AM
"That cookie is always broadcast in plain text every single time you click a link on any website. Right out in the open where anyone -- well, technically, anyone who happens to be on the same network as you and is in a position to view your network packets -- can just grab it out of the ether and immediately impersonate you on any website you are a member of."
(emphasis mine)
Very misleading. Jeff, i'm sure you understand how cookies really work, so i'll assume this is just poorly worded, but for the benefit of others reading: a single cookie will only ever be sent to a single domain, at most, and cannot be used to impersonate your identity on other websites.
Bobbykjack on November 15, 2010 6:53 AM
Hopefully that closes the bold. It does in the preview window.
@Jo and Kang Su G.
"It would seem this Firesheep would also work on wired connections within the same subnet. Is that not the case?"
It depends on the networking equipment. If it's a hub, then yes. If it's a switch or router, then no. Hubs fell out of favor years ago because Switches, for slightly more money, were considerably faster. Namely because a switch doesn't broadcast every packet to every computer, only to ones with matching addresses... or to the network gateway/router, which is responsible for sending the packet on to the next part of the network, or in home-use cases, to the public Internet.
Powerlord on November 15, 2010 8:28 AM
So does Yahoo mail simply not support HTTPS? I used Chrome + Use HTTPS (https://chrome.google.com/extensions/detail/kbkgnojednemejclpggpnhlhlhkmfidi) and when I logged in to mail.yahoo.com and provided credentials, I got this "The webpage at https://us.mc1103.mail.yahoo.com/mc/welcome?.gx=xxxxx might be temporarily down or it may have moved permanently to a new web address."
Hughdbrown on November 15, 2010 9:36 AM
What I'd be interested to know is how hardened the wired side of the typical coffee shop is. Encrypting the Wi-Fi traffic doesn't help you against that.
queisser on November 15, 2010 12:20 PM
@queisser: "how hardened the wired side of the typical coffee shop is." Considering most shops are not run by computer security experts I'd wager that the router is probably right next to the stereo controls for when they have to reset it.
Technically, I guess you would have to trust the coffee shop manager to not put a box in between the router and their internet connection in order to capture the traffic. But we have that problem everywhere already.
All of this reminds me of when I was giving a talk to some co-workers on network security. I fired up cain and able and showed them half the company's twitter, remote email, and facebook passwords within 5 minutes. The impact was everyone was a little bit frightened. BTW, the desktop machines were plugged into a router (not a switch/hub). The network guy had failed to do anything other than plug it in and it was defaulted to act like a basic hub (thanks Cisco). This was not a small company and they should have known better.
chris on November 15, 2010 12:45 PM
>a single cookie will only ever be sent to a single domain, at most,
>and cannot be used to impersonate your identity on other websites.
While that is technical true, most people don't understand how serious the lack of SSL is:
If I'm in such an open wifi (without you using VPN), I just have to intercept ANY http page you access and on the fly add some img-Tags into the unencrypted, unprotected html you download. That way I can make your browser send me many more cookies!
And another big big problem: Did you notice how IE sometimes warns you that secure and insecure traffic is mixed? Mostly because of horrible ad netwoks?
The attacker just has to modify that js that is loaded insecurely into a secure page and insert some javascript to steal the cookies and send them to me using GET-requests!
BTW: How about me offering you a cable with internet in my company and me saving all your network traffic and passwords to your extranet?
ALWAYS use VPN!
Bugmenot5 on November 15, 2010 1:05 PM
You could protect yourself online when using public WiFi networks by tunnelling your HTTP traffic through server over SSH.
See http://thinkhole.org/wp/2006/05/10/howto-secure-firefox-and-im-with-putty/ for how to set it up using putty + firefox
Grepmonster.wordpress.com on November 16, 2010 5:17 AM
Some websites won't do HTTPS for all traffic since they rely on Google Adwords for sponsorship. However Adwords won't allow HTTPS based advertisements.
Can someone convince Google to offer HTTPS? Otherwise they are encouraging bad paractices
Cmankowski on November 16, 2010 8:02 AM
What we really need is some way to encrypt just the cookie. I mean, seriously, I don't need my images, my css, my js or even my html encrypted, just the login.
Jeffrey Davis on November 16, 2010 9:28 AM
Before I get totally blasted off the internet, I suppose I should clarify that the the transmission of login/cookie needs to be encrypted, not just the cookie value itself. Encrypting the cookie value wouldn't really help. Still, it would be nice to be able to separate that process from the transmission of regular data, which often has no need to be encrypted.
Jeffrey Davis on November 16, 2010 9:37 AM
Now I'm quite ignorant about good http security but it seems to me that using different passwords for each website would help a little. Not much but at least only those websites that you visited from a given WiFi hotspot would be vulnerable.
I really like the open soruce KeePass utility as it will generate random passwords and I can use a hot key to fill in my userid and password.
One complaint though is websites that don't allow a 20 character password and don't ell you that it's too long. So you register with a 20 character password which is truncated and now you have to figure out what the length really is.
Of course folks reading this blog undersrant this issue. The masses have not a clue.
Tonytoews on November 16, 2010 2:11 PM
Does this "trick" apply if the cookie pertains to an SSL/TLS session? In other words, if I access my bank account - is the cookie still in the clear - not encrypted by SSL?
Mystagogue on November 16, 2010 10:16 PM
@Mystagogue:
No, SSL/TLS negotiation happens before most HTTP headers, including Cookie. TLS has a possible exception for the domain name (Host?) header, but support for that is not mandatory... Apache web server, I'm looking at you!
Also, the cookie specification allows you to specify that cookies are only sent if it is a secured transmission.
Powerlord on November 17, 2010 8:35 AM
@Jeffrey Davis - There's a number of issues with that:
Lets look at a http get request (using Fiddler2).
-------------
GET http://www.google.com/search?hl=en&q=cookie&btnI=I%27m+Feeling+Lucky HTTP/1.1
Accept: image/gif, image/jpeg, image/pjpeg, image/pjpeg, */*
Referer: http://www.google.com/
Accept-Language: en-us
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1;)
Accept-Encoding: gzip, deflate
Host: www.google.com
Connection: Keep-Alive
Cookie: PREF=asdf=1234&abc=123; NID=asdf=1234&abc=123
--------------
The important part in the request is the query string, and the cookies.
Without SSL, others can see everything.
With SSL, others only see 'www.google.com'
Cookies are, in reality, just another header in the list of http headers.
Further, most authentication cookies and/or cookies that hold identifying information should already be encrypted by the server and only decryptable by the server, and there's already a mechanism for cookies to only transmit the cookie when the connection is secure.
The authentication cookie for a typical web stack might look like:
745370B77DC347648F307DCFC800CD7BBF584A030D6477337ADD77670B77654222560F77A0DA36A4F5732D2AB867C828B22FC7777D05047B74AA08373FA70500DAFF2D2D0B7B7356BD22BAB0CA48DBF6D4D7872C5062DD8788B376F757B62D26D27F83AF777CD767B7427DDCA0DAFD82DD74DDA4
So if you can see the transmission in plain text, even with encrypted cookies, you can still become the person. The web's http protocol is stateless in the sense that between requests, a server has no ongoing connection with you. To achieve an illusion of state, the client holds the state, and cookies are a key ingredient to make it happen. Steal the state, become the person.
So maybe you're saying you want to open 2 sockets per request? The first socket is the encrypted channel for transmitting the headers and sensitive information, and the 2nd socket is unencrypted. The web server would then have to combine multiple incoming requests, do something, then split the result into sensitive and non-sensitive information. The client then recombines the two streams and presents something to the user.
I'm making a stab in the dark, but I recall the most expensive part of SSL is establishing the connection. So if you're already making an SSL connection, why wouldn't you just use that and avoid all the complicated and error prone splitting and recombining? Not to mention the re-architecture of every web server and every web client to support a new split protocol, and hoping that every web developer gets it right and never accidentally transmits sensitive information insensitively.
Right now it's easy for a web client to display the green bar/padlock icon.
if(All requests for content SSL) -> secure!
if(no SSL) -> not secure
if(partial SSL) -> not secure.
The beauty of SSL is that it encrypts everything*. Your web client can be sure it's talking to the correct web server, and nothing* in the middle can know what you're doing.
Frank Black on November 17, 2010 12:59 PM
| Yes, you can naively argue that every website should encrypt all their traffic all the time, but to me that's a "boil the sea" solution.
The sea should be boiled, because guess what, HTTPS is your mystical "more secure identity protocol than ye olde HTTP cookies"
| I don't actually care if anyone sees the rest of my public activity on Stack Overflow; it's hardly a secret.
Nobody is worried about the publicly accessible information being read.
| Encrypting everything just to protect that one lousy cookie header seems like a whole lot of overkill to me.
I don't want to be profiled in a database at my ISP or local neighborhood government cyber-spy agency of what websites I goto, what content I've read, or what my general habits are, that's between me and the website. The comment I've posted here, my ISP knows that I've done that. I don't have a problem with "Brian G. -- Content" being on this public website, but I don't want it to be hijacked along the way (from various nodes that carry the packet), nor do I want to get profiled.
Brian G. on November 18, 2010 8:34 AM
Don't forget about ARP spoof when connected to a switch/router, you can still intercept those packets if you arp poison.
David Czech on November 18, 2010 5:12 PM
Using SSL across an open network is simply not enough. Moxie Marlinspike has outlined a relatively easy way to hijack SSL sessions on an open network (http://www.thoughtcrime.org/software/sslstrip/) with his freely downloadable tool. Simply put: Don't trust open networks.
Kevin Scheetz on November 18, 2010 8:11 PM
Two things: a two-part authentication verification scheme is always preferable to a single-part scheme. Those suggesting IP as the second part above are on the right track: you want IP + HTTP-Forwarded-For value; this allows a user to access your site securely over a protocol-supporting proxy server.
Second, all the talk about SSL is protecting the cookie *in transit*, but not in rest. You are not protecting yourself from an XSS-initiated session hijack, nor from a disk-read or memory-read based session hijack. These are "harder" than the simple wire sniff attack, so SSL is a solid first step, but don't believe it gets you all the way there.
Overall, taking SSL + two-part identification gets you a whole lot closer to secure (based primarily on how well the user secures their end of the conversation), to the point that neglecting to do so should really be considered a security failure on your site.
From the user's end, never, ever, ever do anything on an open wireless connection (or any unknown network). Always use SSL where possible. Should go without saying, but obviously the world needs more education on the matter.
Tom Dibble on November 21, 2010 12:33 AM
Insightful article. Now we need an extension to show people how easy man-in-the-middle attacks against SSL over rouge wireless access points are :)
jagwio.blogspot.com on November 22, 2010 9:18 PM
Just use HTTPS-everywhere addon for Firefox and you will be fine. Almost all sites supported.
If you use any other browser, you are screwed :/
Anuj More on November 23, 2010 8:59 AM
Leo LaPorte has made a good suggestion. He suggests owners of hotspots use protected wifi so traffic is encrypted. Since a secure password is not just not needed but undesirable it should be included in the network name--for example: networkname(password=password).
spookie on November 25, 2010 12:32 PM
Sphere: Related Content
Mostrando entradas con la etiqueta web security. Mostrar todas las entradas
Mostrando entradas con la etiqueta web security. Mostrar todas las entradas
28/11/10
31/10/10
Hosting backdoors in hardware
Posted in security on October 27th, 2010 by rwbarton – 12 Comments
Have you ever had a machine get compromised? What did you do? Did you run rootkit checkers and reboot? Did you restore from backups or wipe and reinstall the machines, to remove any potential backdoors?
In some cases, that may not be enough. In this blog post, we’re going to describe how we can gain full control of someone’s machine by giving them a piece of hardware which they install into their computer. The backdoor won’t leave any trace on the disk, so it won’t be eliminated even if the operating system is reinstalled. It’s important to note that our ability to do this does not depend on exploiting any bugs in the operating system or other software; our hardware-based backdoor would work even if all the software on the system worked perfectly as designed.
I’ll let you figure out the social engineering side of getting the hardware installed (birthday “present”?), and instead focus on some of the technical details involved.
Our goal is to produce a PCI card which, when present in a machine running Linux, modifies the kernel so that we can control the machine remotely over the Internet. We’re going to make the simplifying assumption that we have a virtual machine which is a replica of the actual target machine. In particular, we know the architecture and exact kernel version of the target machine. Our proof-of-concept code will be written to only work on this specific kernel version, but it’s mainly just a matter of engineering effort to support a wide range of kernels.
Modifying the kernel with a kernel module
The easiest way to modify the behavior of our kernel is by loading a kernel module. Let’s start by writing a module that will allow us to remotely control a machine.
IP packets have a field called the protocol number, which is how systems distinguish between TCP and UDP and other protocols. We’re going to pick an unused protocol number, say, 163, and have our module listen for packets with that protocol number. When we receive one, we’ll execute its data payload in a shell running as root. This will give us complete remote control of the machine.
The Linux kernel has a global table inet_protos consisting of a struct net_protocol * for each protocol number. The important field for our purposes is handler, a pointer to a function which takes a single argument of type struct sk_buff *. Whenever the Linux kernel receives an IP packet, it looks up the entry in inet_protos corresponding to the protocol number of the packet, and if the entry is not NULL, it passes the packet to the handler function. The struct sk_buff type is quite complicated, but the only field we care about is the data field, which is a pointer to the beginning of the payload of the packet (everything after the IP header). We want to pass the payload as commands to a shell running with root privileges. We can create a user-mode process running as root using the call_usermodehelper function, so our handler looks like this:
int exec_packet(struct sk_buff *skb)
{
char *argv[4] = {"/bin/sh", "-c", skb->data, NULL};
char *envp[1] = {NULL};
call_usermodehelper("/bin/sh", argv, envp, UMH_NO_WAIT);
kfree_skb(skb);
return 0;
}
We also have to define a struct net_protocol which points to our packet handler, and register it when our module is loaded:
const struct net_protocol proto163_protocol = {
.handler = exec_packet,
.no_policy = 1,
.netns_ok = 1
};
int init_module(void)
{
return (inet_add_protocol(&proto163_protocol, 163) < 0);
}
Let’s build and load the module:
rwbarton@target:~$ make
make -C /lib/modules/2.6.32-24-generic/build M=/home/rwbarton modules
make[1]: Entering directory `/usr/src/linux-headers-2.6.32-24-generic'
CC [M] /home/rwbarton/exec163.o
Building modules, stage 2.
MODPOST 1 modules
CC /home/rwbarton/exec163.mod.o
LD [M] /home/rwbarton/exec163.ko
make[1]: Leaving directory `/usr/src/linux-headers-2.6.32-24-generic'
rwbarton@target:~$ sudo insmod exec163.ko
Now we can use sendip (available in the sendip Ubuntu package) to construct and send a packet with protocol number 163 from a second machine (named control) to the target machine:
rwbarton@control:~$ echo -ne 'touch /tmp/x\0' > payload
rwbarton@control:~$ sudo sendip -p ipv4 -is 0 -ip 163 -f payload $targetip
rwbarton@target:~$ ls -l /tmp/x
-rw-r--r-- 1 root root 0 2010-10-12 14:53 /tmp/x
Great! It worked. Note that we have to send a null-terminated string in the payload, because that’s what call_usermodehelper expects to find in argv and we didn’t add a terminator in exec_packet.
Modifying the on-disk kernel
In the previous section we used the module loader to make our changes to the running kernel. Our next goal is to make these changes by altering the kernel on the disk. This is basically an application of ordinary binary patching techniques, so we’re just going to give a high-level overview of what needs to be done.
The kernel lives in the /boot directory; on my test system, it’s called /boot/vmlinuz-2.6.32-24-generic. This file actually contains a compressed version of the kernel, along with the code which decompresses it and then jumps to the start. We’re going to modify this code to make a few changes to the decompressed image before executing it, which have the same effect as loading our kernel module did in the previous section.
When we used the kernel module loader to make our changes to the kernel, the module loader performed three important tasks for us:
1. it allocated kernel memory to store our kernel module, including both code (the exec_packet function) and data (proto163_protocol and the string constants in exec_packet) sections;
2. it performed relocations, so that, for example, exec_packet knows the addresses of the kernel functions it needs to call such as kfree_skb, as well as the addresses of its string constants;
3. it ran our init_module function.
We have to address each of these points in figuring out how to apply our changes without making use of the module loader.
The second and third points are relatively straightforward thanks to our simplifying assumption that we know the exact kernel version on the target system. We can look up the addresses of the kernel functions our module needs to call by hand, and define them as constants in our code. We can also easily patch the kernel’s startup function to install a pointer to our proto163_protocol in inet_protos[163], since we have an exact copy of its code.
The first point is a little tricky. Normally, we would call kmalloc to allocate some memory to store our module’s code and data, but we need to make our changes before the kernel has started running, so the memory allocator won’t be initialized yet. We could try to find some code to patch that runs late enough that it is safe to call kmalloc, but we’d still have to find somewhere to store that extra code.
What we’re going to do is cheat and find some data which isn’t used for anything terribly important, and overwrite it with our own data. In general, it’s hard to be sure what a given chunk of kernel image is used for; even a large chunk of zeros might be part of an important lookup table. However, we can be rather confident that any error messages in the kernel image are not used for anything besides being displayed to the user. We just need to find an error message which is long enough to provide space for our data, and obscure enough that it’s unlikely to ever be triggered. We’ll need well under 180 bytes for our data, so let’s look for strings in the kernel image which are at least that long:
rwbarton@target:~$ strings vmlinux | egrep '^.{180}' | less
One of the output lines is this one:
<4>Attempt to access file with crypto metadata only in the extended attribute region, but eCryptfs was mounted without xattr support enabled. eCryptfs will not treat this like an encrypted file.
This sounds pretty obscure to me, and a Google search doesn’t find any occurrences of this message which aren’t from the kernel source code. So, we’re going to just overwrite it with our data.
Having worked out what changes need to be applied to the decompressed kernel, we can modify the vmlinuz file so that it applies these changes after performing the decompression. Again, we need to find a place to store our added code, and conveniently enough, there are a bunch of strings used as error messages (in case decompression fails). We don’t expect the decompression to fail, because we didn’t modify the compressed image at all. So we’ll overwrite those error messages with code that applies our patches to the decompressed kernel, and modify the code in vmlinuz that decompresses the kernel to jump to our code after doing so. The changes amount to 5 bytes to write that jmp instruction, and about 200 bytes for the code and data that we use to patch the decompressed kernel.
Modifying the kernel during the boot process
Our end goal, however, is not to actually modify the on-disk kernel at all, but to create a piece of hardware which, if present in the target machine when it is booted, will cause our changes to be applied to the kernel. How can we accomplish that?
The PCI specification defines a “expansion ROM” mechanism whereby a PCI card can include a bit of code for the BIOS to execute during the boot procedure. This is intended to give the hardware a chance to initialize itself, but we can also use it for our own purposes. To figure out what code we need to include on our expansion ROM, we need to know a little more about the boot process.
When a machine boots up, the BIOS initializes the hardware, then loads the master boot record from the boot device, generally a hard drive. Disks are traditionally divided into conceptual units called sectors of 512 bytes each. The master boot record is the first sector on the drive. After loading the master boot record into memory, the BIOS jumps to the beginning of the record.
On my test system, the master boot record was installed by GRUB. It contains code to load the rest of the GRUB boot loader, which in turn loads the /boot/vmlinuz-2.6.32-24-generic image from the disk and executes it. GRUB contains a built-in driver which understands the ext4 filesystem layout. However, it relies on the BIOS to actually read data from the disk, in much the same way that a user-level program relies on an operating system to access the hardware. Roughly speaking, when GRUB wants to read some sectors off the disk, it loads the start sector, number of sectors to read, and target address into registers, and then invokes the int 0x13 instruction to raise an interrupt. The CPU has a table of interrupt descriptors, which specify for each interrupt number a function pointer to call when that interrupt is raised. During initialization, the BIOS sets up these function pointers so that, for example, the entry corresponding to interrupt 0x13 points to the BIOS code handling hard drive IO.
Our expansion ROM is run after the BIOS sets up these interrupt descriptors, but before the master boot record is read from the disk. So what we’ll do in the expansion ROM code is overwrite the entry for interrupt 0x13. This is actually a legitimate technique which we would use if we were writing an expansion ROM for some kind of exotic hard drive controller, which a generic BIOS wouldn’t know how to read, so that we could boot off of the exotic hard drive. In our case, though, what we’re going to make the int 0x13 handler do is to call the original interrupt handler, then check whether the data we read matches one of the sectors of /boot/vmlinuz-2.6.32-24-generic that we need to patch. The ext4 filesystem stores files aligned on sector boundaries, so we can easily determine whether we need to patch a sector that’s just been read by inspecting the first few bytes of the sector. Then we return from our custom int 0x13 handler. The code for this handler will be stored on our expansion ROM, and the entry point of our expansion ROM will set up the interrupt descriptor entry to point to it.
In summary, the boot process of the system with our PCI card inserted looks like this:
• The BIOS starts up and performs basic initialization, including setting up the interrupt descriptor table.
• The BIOS runs our expansion ROM code, which hooks the int 0x13 handler so that it will apply our patch to the vmlinuz file when it is read off the disk.
• The BIOS loads the master boot record installed by GRUB, and jumps to it. The master boot record loads the rest of GRUB.
• GRUB reads the vmlinuz file from the disk, but our custom int 0x13 handler applies our patches to the kernel before returning.
• GRUB jumps to the vmlinuz entry point, which decompresses the kernel image. Our modifications to vmlinuz cause it to overwrite a string constant with our exec_packet function and associated data, and also to overwrite the end of the startup code to install a pointer to this data in inet_protos[163].
• The startup code of the decompressed kernel runs and installs our handler in inet_protos[163].
• The kernel continues to boot normally.
We can now control the machine remotely over the Internet by sending it packets with protocol number 163.
One neat thing about this setup is that it’s not so easy to detect that anything unusual has happened. The running Linux system reads from the disk using its own drivers, not BIOS calls via the real-mode interrupt table, so inspecting the on-disk kernel image will correctly show that it is unmodified. For the same reason, if we use our remote control of the machine to install some malicious software which is then detected by the system administrator, the usual procedure of reinstalling the operating system and restoring data from backups will not remove our backdoor, since it is not stored on the disk at all.
What does all this mean in practice? Just like you should not run untrusted software, you should not install hardware provided by untrusted sources. Unless you work for something like a government intelligence agency, though, you shouldn’t realistically worry about installing commodity hardware from reputable vendors. After all, you’re already also trusting the manufacturer of your processor, RAM, etc., as well as your operating system and compiler providers. Of course, most real-world vulnerabilities are due to mistakes and not malice. An attacker can gain control of systems by exploiting bugs in popular operating systems much more easily than by distributing malicious hardware.
Comments (12)
AOrtega says:
October 27, 2010 at 1:07 pm
Great article.
I saw something similar in the paper “Implementing and Detecting a PCI Rootkit” by Heasman (http://www.blackhat.com/presentations/bh-dc-07/Heasman/Paper/bh-dc-07-Heasman-WP.pdf) and “PCI rootkits” by Lopes/Correa (http://www.h2hc.com.br/repositorio/2008/Joao.pdf) If my memory don’t fail me, they used INT 10h as the attack vector.
Finally, we suggested something similar on our own paper “Persistent BIOS Infection” (http://www.phrack.org/issues.html?issue=66&id=7) by using BIOS32 calls directly from the Kernel, but maybe your approach is more simple and effective.
However, I’m not sure if it’s correct to call this “backdoors in hardware”, as you are clearly modifying software or in the best case, firmware.
BTW, patching a gzipped binary like vmlinuz should be non-trivial. Any idea on how to make this simple?
Anonymous says:
October 27, 2010 at 5:00 pm
This is all very good and fine — but how does it deal with customized kernels? Or compressed vmlinux binaries? The kernel’s build system permits at least three kinds of compression already.
Kristian Hermansen says:
October 27, 2010 at 11:02 pm
Cool technique. I was at the first LEET conference in San Francisco where a guy presented a method of doing something similar by disabling protected memory space after the kernel was loaded (no need for BIOS hijacking).
http://www.usenix.org/event/leet08/tech/full_papers/king/king_html/
Atul Sovani says:
October 28, 2010 at 6:26 am
Hi, please excuse if it’s my poor understanding, but I think there is a mismatch between the sample code.
In the sample code given, the handler function is exec_packet(), whereas in struct net_protocol proto163_protocol, the handler is defined to be print_packet(). Shouldn’t that be exec_packet() instead?
Very good and informative article otherwise! Thanks for the great article!
Christian Sciberras says:
October 28, 2010 at 9:50 am
Nice read. Saw this being done with graphics cards. For those still thinking this is fiction, may I remind you about the batch of Seagate (I think?) harddisk infected with MBR virii?
Of course that worked differently.
Either case, think of this, who’s the major hardware manufacturer? The next time your silicon valley guy designs a new processor and tasks some Chinese people to do the manufacturing, how do you know that you’re getting what you think you are?
Oh, and there was the issue of the DoD and US Military using compromised (and/or fake) Cisco routers from cheap “gold” partners.
Indeed, if one does some research one might see how the battlefield in cyberwarfare is actually changing.
Peter da Silva says:
October 28, 2010 at 10:08 am
Next step, patching the firmware of a PCI card to include this hack by flashing it from a running system…
rwbarton says:
October 28, 2010 at 12:40 pm
Hi Atul,
Oops, you’re quite right–print_packet was accidentally left over from an older version of the code. I’ve corrected this mistake.
nerd says:
October 28, 2010 at 3:47 pm
Good explanation. But the difficulties are the huge amount of different Linux OS and different Graphic-cards, isn’t it? You must have a large library of several flashing progs for all of these cards – correct?
Kevin Marquette says:
October 29, 2010 at 12:44 pm
Nice write up. Just because it is hard to pull off today with all the different hardware and versions of Linux, people will find a way to make this easier and better.
Anonymous says:
October 29, 2010 at 3:33 pm
I can think of much better ways to do this off the top of my head. Why not infect the bootblock of the BIOS flash rom? The user can’t normally change this area of flash. An area of the flash chip can be protected from change, so a normal BIOS flash upgrade would not affect it. This area is normally used for bootstrapping, i.e. “QFlash” which can automatically read a bios update from floppy. Only a hardware signal WP can allow flash change. Simply touch a certain pin on the chip, install the spyware, now the system is permanently infected. Same flash chips are used across board vendors, and protection level varies by implementation, but it’s possible even some boards can be infected in pure software and consequently permanently locked down, so only a new flash chip could un-infect it.
See http://www.winbond-usa.com/products/winbond_products/pdfs/Memory/APNMNV07.pdffor a sample datasheet.
I can think of far nastier things too – can’t a rogue card on the PCI bus read any memory? Could you snoop on PCI transactions? What about the ASIC (ie another cpu on the board) that normally controls the overclocking functions etc., even if the CPU isn’t working? As for sending data, don’t use the normal internet – you can easily use Van Eck techniques to reliably send data with just software. What about hiding a bluetooth chip?
Anyone of you can now go off and develop such products – and I’m sure it’s all been done already, and just think a company in business 10 years has developed even the most advanced techniques, somewhere in the world it’s for sale right now. Many security products are advertised publically actually, however some countries have laws against such advertisements in public, so they have to use direct marketing.
Anonymous says:
October 29, 2010 at 3:40 pm
ps all you really need is the ability to read/write memory (and avoid normal memory protection mechanisms). I would make the backdoor the client and the host program can be a full fledged GUI with continual updates for various control functions for all major operating systems. Keyboard data and screengrabs would be two useful utilities based on the simplest of clients. Realtime video would need some high bandwidth, RF based communication however. But remember any tv/flatpanel is easily picked up with Van Eck (in the case of flatpanel, you receive a differntial signal so certain color schemes are more secure than others). Displayport was specifically designed with van eck in mind… and I think HDMI was too. Sphere: Related Content
Have you ever had a machine get compromised? What did you do? Did you run rootkit checkers and reboot? Did you restore from backups or wipe and reinstall the machines, to remove any potential backdoors?
In some cases, that may not be enough. In this blog post, we’re going to describe how we can gain full control of someone’s machine by giving them a piece of hardware which they install into their computer. The backdoor won’t leave any trace on the disk, so it won’t be eliminated even if the operating system is reinstalled. It’s important to note that our ability to do this does not depend on exploiting any bugs in the operating system or other software; our hardware-based backdoor would work even if all the software on the system worked perfectly as designed.
I’ll let you figure out the social engineering side of getting the hardware installed (birthday “present”?), and instead focus on some of the technical details involved.
Our goal is to produce a PCI card which, when present in a machine running Linux, modifies the kernel so that we can control the machine remotely over the Internet. We’re going to make the simplifying assumption that we have a virtual machine which is a replica of the actual target machine. In particular, we know the architecture and exact kernel version of the target machine. Our proof-of-concept code will be written to only work on this specific kernel version, but it’s mainly just a matter of engineering effort to support a wide range of kernels.
Modifying the kernel with a kernel module
The easiest way to modify the behavior of our kernel is by loading a kernel module. Let’s start by writing a module that will allow us to remotely control a machine.
IP packets have a field called the protocol number, which is how systems distinguish between TCP and UDP and other protocols. We’re going to pick an unused protocol number, say, 163, and have our module listen for packets with that protocol number. When we receive one, we’ll execute its data payload in a shell running as root. This will give us complete remote control of the machine.
The Linux kernel has a global table inet_protos consisting of a struct net_protocol * for each protocol number. The important field for our purposes is handler, a pointer to a function which takes a single argument of type struct sk_buff *. Whenever the Linux kernel receives an IP packet, it looks up the entry in inet_protos corresponding to the protocol number of the packet, and if the entry is not NULL, it passes the packet to the handler function. The struct sk_buff type is quite complicated, but the only field we care about is the data field, which is a pointer to the beginning of the payload of the packet (everything after the IP header). We want to pass the payload as commands to a shell running with root privileges. We can create a user-mode process running as root using the call_usermodehelper function, so our handler looks like this:
int exec_packet(struct sk_buff *skb)
{
char *argv[4] = {"/bin/sh", "-c", skb->data, NULL};
char *envp[1] = {NULL};
call_usermodehelper("/bin/sh", argv, envp, UMH_NO_WAIT);
kfree_skb(skb);
return 0;
}
We also have to define a struct net_protocol which points to our packet handler, and register it when our module is loaded:
const struct net_protocol proto163_protocol = {
.handler = exec_packet,
.no_policy = 1,
.netns_ok = 1
};
int init_module(void)
{
return (inet_add_protocol(&proto163_protocol, 163) < 0);
}
Let’s build and load the module:
rwbarton@target:~$ make
make -C /lib/modules/2.6.32-24-generic/build M=/home/rwbarton modules
make[1]: Entering directory `/usr/src/linux-headers-2.6.32-24-generic'
CC [M] /home/rwbarton/exec163.o
Building modules, stage 2.
MODPOST 1 modules
CC /home/rwbarton/exec163.mod.o
LD [M] /home/rwbarton/exec163.ko
make[1]: Leaving directory `/usr/src/linux-headers-2.6.32-24-generic'
rwbarton@target:~$ sudo insmod exec163.ko
Now we can use sendip (available in the sendip Ubuntu package) to construct and send a packet with protocol number 163 from a second machine (named control) to the target machine:
rwbarton@control:~$ echo -ne 'touch /tmp/x\0' > payload
rwbarton@control:~$ sudo sendip -p ipv4 -is 0 -ip 163 -f payload $targetip
rwbarton@target:~$ ls -l /tmp/x
-rw-r--r-- 1 root root 0 2010-10-12 14:53 /tmp/x
Great! It worked. Note that we have to send a null-terminated string in the payload, because that’s what call_usermodehelper expects to find in argv and we didn’t add a terminator in exec_packet.
Modifying the on-disk kernel
In the previous section we used the module loader to make our changes to the running kernel. Our next goal is to make these changes by altering the kernel on the disk. This is basically an application of ordinary binary patching techniques, so we’re just going to give a high-level overview of what needs to be done.
The kernel lives in the /boot directory; on my test system, it’s called /boot/vmlinuz-2.6.32-24-generic. This file actually contains a compressed version of the kernel, along with the code which decompresses it and then jumps to the start. We’re going to modify this code to make a few changes to the decompressed image before executing it, which have the same effect as loading our kernel module did in the previous section.
When we used the kernel module loader to make our changes to the kernel, the module loader performed three important tasks for us:
1. it allocated kernel memory to store our kernel module, including both code (the exec_packet function) and data (proto163_protocol and the string constants in exec_packet) sections;
2. it performed relocations, so that, for example, exec_packet knows the addresses of the kernel functions it needs to call such as kfree_skb, as well as the addresses of its string constants;
3. it ran our init_module function.
We have to address each of these points in figuring out how to apply our changes without making use of the module loader.
The second and third points are relatively straightforward thanks to our simplifying assumption that we know the exact kernel version on the target system. We can look up the addresses of the kernel functions our module needs to call by hand, and define them as constants in our code. We can also easily patch the kernel’s startup function to install a pointer to our proto163_protocol in inet_protos[163], since we have an exact copy of its code.
The first point is a little tricky. Normally, we would call kmalloc to allocate some memory to store our module’s code and data, but we need to make our changes before the kernel has started running, so the memory allocator won’t be initialized yet. We could try to find some code to patch that runs late enough that it is safe to call kmalloc, but we’d still have to find somewhere to store that extra code.
What we’re going to do is cheat and find some data which isn’t used for anything terribly important, and overwrite it with our own data. In general, it’s hard to be sure what a given chunk of kernel image is used for; even a large chunk of zeros might be part of an important lookup table. However, we can be rather confident that any error messages in the kernel image are not used for anything besides being displayed to the user. We just need to find an error message which is long enough to provide space for our data, and obscure enough that it’s unlikely to ever be triggered. We’ll need well under 180 bytes for our data, so let’s look for strings in the kernel image which are at least that long:
rwbarton@target:~$ strings vmlinux | egrep '^.{180}' | less
One of the output lines is this one:
<4>Attempt to access file with crypto metadata only in the extended attribute region, but eCryptfs was mounted without xattr support enabled. eCryptfs will not treat this like an encrypted file.
This sounds pretty obscure to me, and a Google search doesn’t find any occurrences of this message which aren’t from the kernel source code. So, we’re going to just overwrite it with our data.
Having worked out what changes need to be applied to the decompressed kernel, we can modify the vmlinuz file so that it applies these changes after performing the decompression. Again, we need to find a place to store our added code, and conveniently enough, there are a bunch of strings used as error messages (in case decompression fails). We don’t expect the decompression to fail, because we didn’t modify the compressed image at all. So we’ll overwrite those error messages with code that applies our patches to the decompressed kernel, and modify the code in vmlinuz that decompresses the kernel to jump to our code after doing so. The changes amount to 5 bytes to write that jmp instruction, and about 200 bytes for the code and data that we use to patch the decompressed kernel.
Modifying the kernel during the boot process
Our end goal, however, is not to actually modify the on-disk kernel at all, but to create a piece of hardware which, if present in the target machine when it is booted, will cause our changes to be applied to the kernel. How can we accomplish that?
The PCI specification defines a “expansion ROM” mechanism whereby a PCI card can include a bit of code for the BIOS to execute during the boot procedure. This is intended to give the hardware a chance to initialize itself, but we can also use it for our own purposes. To figure out what code we need to include on our expansion ROM, we need to know a little more about the boot process.
When a machine boots up, the BIOS initializes the hardware, then loads the master boot record from the boot device, generally a hard drive. Disks are traditionally divided into conceptual units called sectors of 512 bytes each. The master boot record is the first sector on the drive. After loading the master boot record into memory, the BIOS jumps to the beginning of the record.
On my test system, the master boot record was installed by GRUB. It contains code to load the rest of the GRUB boot loader, which in turn loads the /boot/vmlinuz-2.6.32-24-generic image from the disk and executes it. GRUB contains a built-in driver which understands the ext4 filesystem layout. However, it relies on the BIOS to actually read data from the disk, in much the same way that a user-level program relies on an operating system to access the hardware. Roughly speaking, when GRUB wants to read some sectors off the disk, it loads the start sector, number of sectors to read, and target address into registers, and then invokes the int 0x13 instruction to raise an interrupt. The CPU has a table of interrupt descriptors, which specify for each interrupt number a function pointer to call when that interrupt is raised. During initialization, the BIOS sets up these function pointers so that, for example, the entry corresponding to interrupt 0x13 points to the BIOS code handling hard drive IO.
Our expansion ROM is run after the BIOS sets up these interrupt descriptors, but before the master boot record is read from the disk. So what we’ll do in the expansion ROM code is overwrite the entry for interrupt 0x13. This is actually a legitimate technique which we would use if we were writing an expansion ROM for some kind of exotic hard drive controller, which a generic BIOS wouldn’t know how to read, so that we could boot off of the exotic hard drive. In our case, though, what we’re going to make the int 0x13 handler do is to call the original interrupt handler, then check whether the data we read matches one of the sectors of /boot/vmlinuz-2.6.32-24-generic that we need to patch. The ext4 filesystem stores files aligned on sector boundaries, so we can easily determine whether we need to patch a sector that’s just been read by inspecting the first few bytes of the sector. Then we return from our custom int 0x13 handler. The code for this handler will be stored on our expansion ROM, and the entry point of our expansion ROM will set up the interrupt descriptor entry to point to it.
In summary, the boot process of the system with our PCI card inserted looks like this:
• The BIOS starts up and performs basic initialization, including setting up the interrupt descriptor table.
• The BIOS runs our expansion ROM code, which hooks the int 0x13 handler so that it will apply our patch to the vmlinuz file when it is read off the disk.
• The BIOS loads the master boot record installed by GRUB, and jumps to it. The master boot record loads the rest of GRUB.
• GRUB reads the vmlinuz file from the disk, but our custom int 0x13 handler applies our patches to the kernel before returning.
• GRUB jumps to the vmlinuz entry point, which decompresses the kernel image. Our modifications to vmlinuz cause it to overwrite a string constant with our exec_packet function and associated data, and also to overwrite the end of the startup code to install a pointer to this data in inet_protos[163].
• The startup code of the decompressed kernel runs and installs our handler in inet_protos[163].
• The kernel continues to boot normally.
We can now control the machine remotely over the Internet by sending it packets with protocol number 163.
One neat thing about this setup is that it’s not so easy to detect that anything unusual has happened. The running Linux system reads from the disk using its own drivers, not BIOS calls via the real-mode interrupt table, so inspecting the on-disk kernel image will correctly show that it is unmodified. For the same reason, if we use our remote control of the machine to install some malicious software which is then detected by the system administrator, the usual procedure of reinstalling the operating system and restoring data from backups will not remove our backdoor, since it is not stored on the disk at all.
What does all this mean in practice? Just like you should not run untrusted software, you should not install hardware provided by untrusted sources. Unless you work for something like a government intelligence agency, though, you shouldn’t realistically worry about installing commodity hardware from reputable vendors. After all, you’re already also trusting the manufacturer of your processor, RAM, etc., as well as your operating system and compiler providers. Of course, most real-world vulnerabilities are due to mistakes and not malice. An attacker can gain control of systems by exploiting bugs in popular operating systems much more easily than by distributing malicious hardware.
Comments (12)
AOrtega says:
October 27, 2010 at 1:07 pm
Great article.
I saw something similar in the paper “Implementing and Detecting a PCI Rootkit” by Heasman (http://www.blackhat.com/presentations/bh-dc-07/Heasman/Paper/bh-dc-07-Heasman-WP.pdf) and “PCI rootkits” by Lopes/Correa (http://www.h2hc.com.br/repositorio/2008/Joao.pdf) If my memory don’t fail me, they used INT 10h as the attack vector.
Finally, we suggested something similar on our own paper “Persistent BIOS Infection” (http://www.phrack.org/issues.html?issue=66&id=7) by using BIOS32 calls directly from the Kernel, but maybe your approach is more simple and effective.
However, I’m not sure if it’s correct to call this “backdoors in hardware”, as you are clearly modifying software or in the best case, firmware.
BTW, patching a gzipped binary like vmlinuz should be non-trivial. Any idea on how to make this simple?
Anonymous says:
October 27, 2010 at 5:00 pm
This is all very good and fine — but how does it deal with customized kernels? Or compressed vmlinux binaries? The kernel’s build system permits at least three kinds of compression already.
Kristian Hermansen says:
October 27, 2010 at 11:02 pm
Cool technique. I was at the first LEET conference in San Francisco where a guy presented a method of doing something similar by disabling protected memory space after the kernel was loaded (no need for BIOS hijacking).
http://www.usenix.org/event/leet08/tech/full_papers/king/king_html/
Atul Sovani says:
October 28, 2010 at 6:26 am
Hi, please excuse if it’s my poor understanding, but I think there is a mismatch between the sample code.
In the sample code given, the handler function is exec_packet(), whereas in struct net_protocol proto163_protocol, the handler is defined to be print_packet(). Shouldn’t that be exec_packet() instead?
Very good and informative article otherwise! Thanks for the great article!
Christian Sciberras says:
October 28, 2010 at 9:50 am
Nice read. Saw this being done with graphics cards. For those still thinking this is fiction, may I remind you about the batch of Seagate (I think?) harddisk infected with MBR virii?
Of course that worked differently.
Either case, think of this, who’s the major hardware manufacturer? The next time your silicon valley guy designs a new processor and tasks some Chinese people to do the manufacturing, how do you know that you’re getting what you think you are?
Oh, and there was the issue of the DoD and US Military using compromised (and/or fake) Cisco routers from cheap “gold” partners.
Indeed, if one does some research one might see how the battlefield in cyberwarfare is actually changing.
Peter da Silva says:
October 28, 2010 at 10:08 am
Next step, patching the firmware of a PCI card to include this hack by flashing it from a running system…
rwbarton says:
October 28, 2010 at 12:40 pm
Hi Atul,
Oops, you’re quite right–print_packet was accidentally left over from an older version of the code. I’ve corrected this mistake.
nerd says:
October 28, 2010 at 3:47 pm
Good explanation. But the difficulties are the huge amount of different Linux OS and different Graphic-cards, isn’t it? You must have a large library of several flashing progs for all of these cards – correct?
Kevin Marquette says:
October 29, 2010 at 12:44 pm
Nice write up. Just because it is hard to pull off today with all the different hardware and versions of Linux, people will find a way to make this easier and better.
Anonymous says:
October 29, 2010 at 3:33 pm
I can think of much better ways to do this off the top of my head. Why not infect the bootblock of the BIOS flash rom? The user can’t normally change this area of flash. An area of the flash chip can be protected from change, so a normal BIOS flash upgrade would not affect it. This area is normally used for bootstrapping, i.e. “QFlash” which can automatically read a bios update from floppy. Only a hardware signal WP can allow flash change. Simply touch a certain pin on the chip, install the spyware, now the system is permanently infected. Same flash chips are used across board vendors, and protection level varies by implementation, but it’s possible even some boards can be infected in pure software and consequently permanently locked down, so only a new flash chip could un-infect it.
See http://www.winbond-usa.com/products/winbond_products/pdfs/Memory/APNMNV07.pdffor a sample datasheet.
I can think of far nastier things too – can’t a rogue card on the PCI bus read any memory? Could you snoop on PCI transactions? What about the ASIC (ie another cpu on the board) that normally controls the overclocking functions etc., even if the CPU isn’t working? As for sending data, don’t use the normal internet – you can easily use Van Eck techniques to reliably send data with just software. What about hiding a bluetooth chip?
Anyone of you can now go off and develop such products – and I’m sure it’s all been done already, and just think a company in business 10 years has developed even the most advanced techniques, somewhere in the world it’s for sale right now. Many security products are advertised publically actually, however some countries have laws against such advertisements in public, so they have to use direct marketing.
Anonymous says:
October 29, 2010 at 3:40 pm
ps all you really need is the ability to read/write memory (and avoid normal memory protection mechanisms). I would make the backdoor the client and the host program can be a full fledged GUI with continual updates for various control functions for all major operating systems. Keyboard data and screengrabs would be two useful utilities based on the simplest of clients. Realtime video would need some high bandwidth, RF based communication however. But remember any tv/flatpanel is easily picked up with Van Eck (in the case of flatpanel, you receive a differntial signal so certain color schemes are more secure than others). Displayport was specifically designed with van eck in mind… and I think HDMI was too. Sphere: Related Content
30/10/10
A Hacker's Story: Let me tell you just how easily I can steal your personal data
Posted by Kole McRae on Wed, October 27, 2010 11:31 AM · Filed under Denver-Boulder, Portland, Seattle, Calgary, Edmonton, Montréal, Ottawa, Toronto, Vancouver, Victoria, Kitchener-Waterloo, Atlantic-Canada , Guest Posts and 12 other categories· 20 Comments
A little bird told me people are pissed at Google. According to some sources the streetview cars roaming the country have been recording private data from people's routers. By private they mean usernames, passwords, websites visited and more.
Because of this story I decided to show all of you just how easy it is for me to get all that same information. Tonight, I grabbed my laptop and went on a mission.
Wearing pyjama pants and an ironic t-shirt, I headed towards a large apartment building near where I live. I choose it because a lot of students live there and I could easily blend in. That and I knew there would be lots of targets.
I used to be a door to door salesman, so I know a few unique ways to get into a building, but I didn't need them. As I walked up to the door, someone else was leaving. They held the door open for me and I was in. As soon as I entered, I noticed a video camera. What I planned to do would look weird on camera and I didn't want security on my butt, so I was more careful from there onwards.
I went to the elevators and clicked the button. After a few minutes of waiting, I got on. Two other people joined me and I stood uncomfortably. I had to wait for them to click their floors so I didn't get off on the same floor as them.
When I finally made it to my floor a camera greeted me. I ducked my head low and walked over to the staircase. If security was watching me, I didn't want them knowing where I was.
After dropping down a few floors and switching to the other staircase I decided to do my dirty work on the 18th floor. The building was huge and it would take hours for them to search the entire thing. I opened up my laptop and lo and behold, there were eight insecure networks. I picked one at random and hit the mother-load.
If you look at the screenshot you can see 5 IP address. That means 5 people were connected to the network. It could be a bunch of roommates but because of what I found later I decided it was probably a few people stealing the same internet.
The program you see those IP's in is called Ettercap. It's no longer in development and I don't want to go over everything it does, lets just say it makes it so I can steal usernames and passwords among other things. All I had to do was install the program and run it.
I then opened a program called WireShark (you can see it in the second screenshot). Using this program I can easily see the websites these four people were browsing. As you can see this person is browsing IMDb. And in the next screenshot the person is... err...
I'd been watching these people browse the web for a while when I decided to go a little deeper. I did a search for MSN. It's interesting what I found.
That's mostly msn telling Microsoft's server that it's still alive but a little later on I was able to read the guys entire msn conversation. I also got his e-mail and the address of the guy he was talking too. It made for an interesting read.
I'm was just doing a little creepy stalking in the name of journalism but it would be incredibly easy for someone to use this info as blackmail or to hack into people's accounts. The information was being publicly broadcasted and was easy enough to get access too. The person who set up the router didn't bother to use a password and other people decided to steal it.
Not only this, a lot of the seemingly 'secure' networks in the building were protected with WEP encoding. Which, with a few simple tools found online, is hackable within seconds. In fact, our friends at Lifehacker.com just posted a tutorial on how to do it.
I did it one way but there are thousands of other ways to get this information. Any public network (such as at Starbucks or at your university) has this information floating around for anyone to read it. Remember that next time your chatting on MSN while at school, someone nearby could be reading the conversation.
Your best defense against people like me is to password protect your router using WPA encoding. If you don't know how to do this contact your internet service provider. They will give you step by step instructions.
Also, don't browse hardcore porn on a public network. Sphere: Related Content
A little bird told me people are pissed at Google. According to some sources the streetview cars roaming the country have been recording private data from people's routers. By private they mean usernames, passwords, websites visited and more.
Because of this story I decided to show all of you just how easy it is for me to get all that same information. Tonight, I grabbed my laptop and went on a mission.
Wearing pyjama pants and an ironic t-shirt, I headed towards a large apartment building near where I live. I choose it because a lot of students live there and I could easily blend in. That and I knew there would be lots of targets.
I used to be a door to door salesman, so I know a few unique ways to get into a building, but I didn't need them. As I walked up to the door, someone else was leaving. They held the door open for me and I was in. As soon as I entered, I noticed a video camera. What I planned to do would look weird on camera and I didn't want security on my butt, so I was more careful from there onwards.
I went to the elevators and clicked the button. After a few minutes of waiting, I got on. Two other people joined me and I stood uncomfortably. I had to wait for them to click their floors so I didn't get off on the same floor as them.
When I finally made it to my floor a camera greeted me. I ducked my head low and walked over to the staircase. If security was watching me, I didn't want them knowing where I was.
After dropping down a few floors and switching to the other staircase I decided to do my dirty work on the 18th floor. The building was huge and it would take hours for them to search the entire thing. I opened up my laptop and lo and behold, there were eight insecure networks. I picked one at random and hit the mother-load.
If you look at the screenshot you can see 5 IP address. That means 5 people were connected to the network. It could be a bunch of roommates but because of what I found later I decided it was probably a few people stealing the same internet.The program you see those IP's in is called Ettercap. It's no longer in development and I don't want to go over everything it does, lets just say it makes it so I can steal usernames and passwords among other things. All I had to do was install the program and run it.
I then opened a program called WireShark (you can see it in the second screenshot). Using this program I can easily see the websites these four people were browsing. As you can see this person is browsing IMDb. And in the next screenshot the person is... err...
I'd been watching these people browse the web for a while when I decided to go a little deeper. I did a search for MSN. It's interesting what I found.
That's mostly msn telling Microsoft's server that it's still alive but a little later on I was able to read the guys entire msn conversation. I also got his e-mail and the address of the guy he was talking too. It made for an interesting read.I'm was just doing a little creepy stalking in the name of journalism but it would be incredibly easy for someone to use this info as blackmail or to hack into people's accounts. The information was being publicly broadcasted and was easy enough to get access too. The person who set up the router didn't bother to use a password and other people decided to steal it.
Not only this, a lot of the seemingly 'secure' networks in the building were protected with WEP encoding. Which, with a few simple tools found online, is hackable within seconds. In fact, our friends at Lifehacker.com just posted a tutorial on how to do it.
I did it one way but there are thousands of other ways to get this information. Any public network (such as at Starbucks or at your university) has this information floating around for anyone to read it. Remember that next time your chatting on MSN while at school, someone nearby could be reading the conversation.
Your best defense against people like me is to password protect your router using WPA encoding. If you don't know how to do this contact your internet service provider. They will give you step by step instructions.
Also, don't browse hardcore porn on a public network. Sphere: Related Content
12/8/10
The Future of the Internet
“In only a few short years, electronic computing systems have been invented and improved at a tremendous rate. But computers did not ‘just grow.’ They have evolved… They were born and they are being improved as a consequence of man’s ingenuity, his imagination… and his mathematics.” — 1958 IBM brochure
The Internet is a medium that is evolving at breakneck speed. It’s a wild organism of sweeping cultural change — one that leaves the carcasses of dead media forms in its sizeable wake. It’s transformative: it has transformed the vast globe into a ‘global village’ and it has drawn human communication away from print-based media and into a post-Gutenberg digital era. Right now, its perils are equal to its potential. The debate over ‘net neutrality’ is at a fever pitch. There is a tug-of-war going on between an ‘open web’ and a more governed form of the web (like the Apple-approved apps on the iPad/iPhone) that has more security but less freedom.
So what’s the next step in its evolution, and what’s the big picture? What does the Internet mean as an extension of human communication, of the human mind? And forget tomorrow — where will the web be in fifty years, or a hundred? Will the Internet help make the world look like something out of Blade Runner or Minority Report? Let’s just pray it doesn’t have anything to do with The Matrix sequels, because those movies really sucked.
This article will offer in-depth analysis of a range of subjects — from realistic expectations stemming from current trends to some more imaginative speculations on the distant future.
[By the way, did you know we have a free Email Newsletter? Subscribe now and get fresh short tips and tricks in your inbox!]
Security
“Death of the Open Web”?
Those words have an ominous ring for those of us who have a deep appreciation of the Internet as well as high hopes for its future. The phrase comes from the title of a recent New York Times article that struck a nerve with some readers. The article paints a disquieting picture of the web as a “haphazardly planned” digital city where “malware and spam have turned living conditions in many quarters unsafe and unsanitary.”
There is a growing sentiment that the open web is a fundamentally dangerous place. Recent waves of hacked WordPress sites revealed exploited PHP vulnerabilities and affected dozens of well-known designers and bloggers like Chris Pearson. The tools used by those with malicious intent evolve just as quickly as the rest of the web. It’s deeply saddening to hear that, according to Jonathan Zittrain, some web users have stooped so low as to set up ‘Captcha sweatshops’ where (very) low-paid people are employed to solve Captcha security technology for malicious purposes all day. This is the part where I weep for the inherent sadness of mankind.
“If we don’t do something about this,” says Jonathan Zittrain of the insecure web, “I see the end of much of the generative aspect of the technologies that we now take for granted.” Zittrain is a professor of Internet governance and regulation at Oxford University and the author of The Future of the Internet: and How to Stop It; watch his riveting Google Talk on these subjects.
The result of the Internet’s vulnerability is a generation of Internet-centric products — like the iPad, the Tivo and the XBOX — that are not easily modified by anyone except their vendors and their approved partners. These products do not allow unapproved third-party code (such as the kind that could be used to install a virus) to run on them, and are therefore more reliable than some areas of the web. Increased security often means restricted or censored content — and even worse — limited freedoms that could impede the style of innovation that propels the evolution of the Internet, and therefore, our digital future.
The web of 2010 is a place where a 17 year-old high school student can have an idea for a website, program it in three days, and quickly turn it into a social networking craze used by millions (that student’s name is Andrey Ternovskiy and he invented Chatroulette). That’s innovation in a nutshell. It’s a charming story and a compelling use of the web’s creative freedoms. If the security risks of the Internet kill the ‘open web’ and turn your average web experience into one that is governed by Apple or another proprietary company, the Andrey Ternovskiys of the world may never get their chance to innovate.
Security Solutions
We champion innovation on the Internet and it’s going to require innovation to steer it in the right direction. Jonathan Zittrain says that he hopes we can come together on agreements for regulating the open web so that we don’t “feel that we have to lock down our technologies in order to save our future.”
According to Vint Cerf, vice president and Chief Internet Evangelist at Google, “I think we’re going to end up looking for international agreements – maybe even treaties of some kind – in which certain classes of behavior are uniformly considered inappropriate.”
Perhaps the future of the Internet involves social structures of web users who collaborate on solutions to online security issues. Perhaps companies like Google and Apple will team up with international governmental bodies to form an international online security council. Or maybe the innovative spirit of the web could mean that an independent, democratic group of digital security experts, designers, and programmers will form a grassroots-level organization that rises to prominence while fighting hackers, innovating on security technology, writing manifestos for online behavior, and setting an example through positive and supportive life online.
Many people are fighting to ensure your ability to have your voice heard online — so use that voice to participate in the debate, stay informed, and demand a positive future. Concerned netizens and Smashing readers: unite!
Freedom
Net Neutrality
Some believe that the fate of the Internet has been up for grabs ever since the federal government stopped enforcing ‘network neutrality’ rules in the mid-2000’s. In a nutshell, net neutrality means equality among the information that travels to your computer: everyone has the right to build a website that is just as public, affordable, and easily accessible as any other. However, some companies like phone and internet service providers are proposing ‘pay tiers’ (web service where you need to pay premium fees in order to allow visitors to access your site quickly). These tiers of web service could kill net neutrality by allowing those who can afford premium service (particularly large media companies who don’t like sharing their audience with your blog) greater access to consumers than the average web user.
The debate over net neutrality reached a boiling point when Google and Verizon announced a ‘joint policy proposal for an open Internet’ on August 9th, 2010. Despite the proposal’s call for a “new, enforceable prohibition against discriminatory practices” amongst online content, many criticized it, citing leniency and loopholes.
Net neutrality needs to be made law. If the Internet were to have a slow lane and a fast lane, your average web user could lose many of his or her freedoms and opportunities online, thereby shattering the core values that make the Internet so profoundly valuable to society. However, that’s just the tip of the iceberg for this thorny issue. To learn more, read the full proposal or watch the Bill Moyers episode ‘The Net @ Risk.’
The World into the Web
Browser-based Everything
Google is developing a variety of applications and programs that exist entirely within the browser. Their PAC-MAN game was a preview of what’s to come because it allowed in-browser play of a simple, lightweight video game that required no downloads and relied on pure HTML, CSS, and Javascript. At the company’s 2010 I/O conference, Google laid out its plans to develop “rich multimedia applications that operate within the browser” (according to this New York Times report on the conference). The company plans to sell in-browser web applications like photo editing software (imagine using a Photoshop equivalent entirely within the browser) that it will sell in a web applications store called the Chrome Web Store.
If our programs and applications are about to be folded into the browser, what will exist within the browser in ten years? Currency? Education? Consciousness? Personally, I’m hopeful that my browser will be able to produce piping hot cheeseburgers sometime soon.
The Internet as a Collective Consciousness
The Internet is a medium, and philosopher Marshall McLuhan believed that all media are extensions of the human senses. The engine of our collective creative efforts is the force that’s causing the web to evolve more rapidly than any biological organism ever has.
The Internet is an extension of the collective human mind and it’s evolving into a medium of transcendence. By constructing a place where the collective human consciousness is both centralized in one location (on your computer) and globally accessible (for those with the means to reach or use a computer, that is), our human spirit is transcending the human body. Way back in 1964, McLuhan himself wondered, “might not our current translation of our entire lives into the spiritual form of information seem to make of the entire globe, and of the human family, a single consciousness?”
With the advent of trends including social media, ‘lifecasting,’ and ‘mindcasting,’ the Internet is being used as a real-time portal for the human consciousness. Perhaps those trends will be inverted by some web users of the future: instead of bringing offline life to the web (as so-called ‘lifecasters’ do when they stream live video of their attendance at an offline event), some web users will live their entire public lives online. Imagine a pop star who conducts her entire career online: every interview, live performance, music video or album release conducted solely through a browser window or mobile screen. Or a media theorist who exploited the platform of the web while discussing the theoretical ramifications of those actions. It’d be a great gimmick.
The Web into the World
The ‘Web of Things’
The ‘web of things’ or ‘Internet of things’ is a concept that will be a reality (at least in a rudimentary form) in the near future. The idea is that devices, appliances, and even your pets can all be tracked online. With Google Maps for iPhone, you can currently track your location on a digital map in relation to the streets and landmarks in your area. So it’s not hard to imagine a world where you can zoom in on your location and see detailed, 3D renderings of your surroundings: the cars on your block, the coffee machine in your kitchen, even Rover running around in your backyard! And it’s a good thing that you’re digitally tracking the location of poor Rover; he’s liable to hop the fence and make a run for it now that you’ve created a satellite computer out of everything you own (including his dog collar) by attaching a tracking device to it.
AT&T is betting big on the web of things. According to this Reuters article, the phone service provider is investing in tracking devices that could be installed in cars, on dog collars, and on the pallets used to move large shipments of products. The dog collar, for example, “could send text messages or emails to the owner of a pet when it strays outside a certain area, or the device could allow continuous tracking of the pet.”
Combine the concept of the ‘web of things’ with Second Life-style 3D imaging and you can imagine a web-based duplicate world — a virtual world that corresponds to the real one. But what are the implications of a world where every physical item has a corresponding digital existence online? Can we track the physical effects of climate change in the web of things? Will there be a digital avatar for every pelican carcass in the vicinity of the oil spill that’s devastating the Gulf of Mexico? It’s a tragic shame to develop a virtual world if we let the natural one go to waste in the meantime.
Interactive Landscapes
It has been said that today’s science fiction is tomorrow’s reality. Unfortunately, most good science fiction stories are cautionary tales set in dystopian nightmares.
Simon Mainwaring reports on the N building in Japan, where “the whole building facade has been transformed into a real time dialogue between smart phones and what’s going on inside the store.” The exterior of the building is layered with QR codes (an alternate form of bar code) that can deliver real-time information to your phone. In Stephen Spielberg’s film Minority Report (adapted from a short story by mad genius Philip K. Dick), Gap ads came alive to hawk khakis to Tom Cruise. Looks like we’re about one step away from this scenario.
Mr. Mainwaring imagines a future with “billboards that watch you shop and make targeted suggestions based on your age, location and past buying habits,” and “stores will effectively be turned inside out as dialogue and personalized interaction with customers begins outside the store.”
The technology is cool, but it sounds like a pretty annoying future if you ask me. Who wants to be accosted by a holographic salesperson? The web grants us a great opportunity to use our collective voices to speak out on topics that matter to us. Because there are no regulations yet for much of this technology, it may be up to concerned citizens to make themselves heard if Internet-based technology is used in intrusive or abrasive ways.
The ‘Innerweb’
Cyborgs are among us already — humans whose physical abilities have been extended or altered by mechanical elements built into the body (people who live with pacemakers are one example). What will happen when the Internet becomes available on a device that is biologically installed in a human? What will the first internal user interfaces look like?
Here’s one speculation.
In the near future, we may be capable of installing the Internet directly into the user’s field of vision via a tiny computer chip implanted into the eye. Sound far-fetched? I doubt that it would sound far-fetched for Barbara Campbell, whose sight has been partially restored by a digital retinal implant (CNN reports on Barbara’s artificial retina).
Ms. Campbell was blind for many years until she had a small microchip surgically implanted in her eye. A rudimentary image of Ms.Campbell’s surroundings is transmitted to the device, which stimulates cells in her retina, in turn transmitting a signal to her brain. It’s a miracle that the development of a bionic eye has begun to help the blind see.
How else might doctors and scientists take advantage of the internal microchip? Perhaps the user’s vision will be augmented with an Internet-based interface with capabilities including geolocation or object identification. Imagine if technology like Google Goggles (a web-based application that identifies images from landmarks to book covers) was applied inside that interface. The act of seeing could not only be restored but augmented; a user might be capable of viewing a landscape while simultaneously identifying web-based information about it or even searching it for physical objects not visible to the naked eye. Apply the concept of augmented sight with the idea of the ‘web of things’ — an environment where physical objects have a corresponding presence on the web — and you can imagine a world where missing people are located, theft is dramatically reduced, the blind can see, and ’seeing’ itself means something more than it used to.
If the web is an extension of our senses, it follows suit that the web may be capable of modifying those senses or even accelerating their evolution.
The Crown Jewels
“The next Bill Gates will be the deliverer of a highly technological solution to some of our climate change challenges.” — Lord Digby Jones of Birmingham
In preparation for this article, I considered a variety of wild ideas and fun speculations about the future. Could the Internet be used to solve the problem of climate change, generate tangible matter, or contact extraterrestrial life? Maybe those ideas sound like the stuff of imaginative fiction, but in a world where quantum teleportation has been achieved and researchers have created a living, synthetic cell, it almost seems as if the concept of science fiction is being eradicated while real technology brings our wildest fantasies to life. Here is the result of my most daring (absurd?) speculation.
Time Travel
I called on physics teacher Mark Stratil to answer my last burning question: could the Internet ever be capable of facilitating the development of time travel? Here’s Mark’s answer:
“The Internet is still based on computers, which make linear calculations. Right now, all computers are based on binary code, which is a series of yes and no questions. You can make something that’s incredibly complex with a series of yes and no questions, but it takes a certain amount of time. The Internet still has to go through those calculations and it still physically has to make one calculation that will lead to the next calculation that will lead to the next. So no matter how fast we can get our computers – they’re making billions of calculations, trillions of calculations per second – there’s still going to be some lag time. They’re still limited by time in that way. They still need some time to make that conversation or that calculation.
In that way, they’re kind of chained to time. Their whole existence is based on a linear sequence of things that happen. In order to create something else, something that goes outside of time, you would have to make it a non-linear system — something that that’s not based on a series of yes and no questions, because those have to be answered in a precise order. It would have to be some kind of system that was answering all the questions at once.”
So Mark’s short answer to my fundamental question was basically that the Internet, in its current state, would not be capable of facilitating time travel. However, if the Internet was liberated from the linear structure of binary code and migrated onto an operating system that ‘answered all questions at once,’ then maybe it could have the potential to manipulate time or transcend the boundaries of time.
Sounds unlikely at this point, but one of the Internet’s greatest capabilities is the opportunity to share and develop ideas like these!
Conclusion
Responsible Evolution
Through technology, we hold the reins to our own evolution.
For the first time in history, it might be said that there are moral implications in the act of evolution. The Internet is an extension of our senses and our minds, and its progress is propelled by our own creative and intellectual efforts. The future of the Internet will be shaped by millions of choices and decisions by people from all walks of life. Designers and programmers like us have the advantage of technical skill and specialized knowledge. Given the increasing presence of the Internet in our lives, our choices can have deep reverberations in human society.
We’ll face small choices like what color to use for a button and larger choices like which platforms to endorse and which clients to support with our work. But the real questions form broad patterns behind every media trend and every mini technological revolution. Can we use technology to develop solutions to environmental problems — or will we abandon the natural world in favor of a digital one and the ‘web of things’? Have we fully considered what it means to merge biology and technology? And finally, do we really need a digital tracking device on our coffee machines?
What a thrilling time to be alive! Let’s proceed with great enthusiasm and a commitment to designing a future that is meaningful, peaceful, and staggeringly exciting.
Partial Bibliography
* New York Times Magazine: “The Death of the Open Web”
* Simon Mainwaring: “The Future of Shopping: What Happens When Walls Start Talking”
* The Gutenberg Parenthesis: Parallels Between Pre-Printing Communication and the Digital Era
* New York Times: “Google Pitches a Web-Centric Future”
* Google Talks: The Future of the Internet
* Moyers on America: ‘The Net @ Risk’ (Video)
* Pew Internet Research Poll: Future of the Internet IV
* Google I/O: The Web is Killing Radio, Newspapers, Magazines, and TV (TechChrunch reports)
Related Posts
You may be interested in the following related posts:
* The Evolution of the Logo
* The Dying Art Of Design
* Lessons From Swiss Style Graphic Design
* Art Manifestos and Their Applications in Contemporary Design Sphere: Related Content
The Internet is a medium that is evolving at breakneck speed. It’s a wild organism of sweeping cultural change — one that leaves the carcasses of dead media forms in its sizeable wake. It’s transformative: it has transformed the vast globe into a ‘global village’ and it has drawn human communication away from print-based media and into a post-Gutenberg digital era. Right now, its perils are equal to its potential. The debate over ‘net neutrality’ is at a fever pitch. There is a tug-of-war going on between an ‘open web’ and a more governed form of the web (like the Apple-approved apps on the iPad/iPhone) that has more security but less freedom.
So what’s the next step in its evolution, and what’s the big picture? What does the Internet mean as an extension of human communication, of the human mind? And forget tomorrow — where will the web be in fifty years, or a hundred? Will the Internet help make the world look like something out of Blade Runner or Minority Report? Let’s just pray it doesn’t have anything to do with The Matrix sequels, because those movies really sucked.
This article will offer in-depth analysis of a range of subjects — from realistic expectations stemming from current trends to some more imaginative speculations on the distant future.
[By the way, did you know we have a free Email Newsletter? Subscribe now and get fresh short tips and tricks in your inbox!]
Security
“Death of the Open Web”?
Those words have an ominous ring for those of us who have a deep appreciation of the Internet as well as high hopes for its future. The phrase comes from the title of a recent New York Times article that struck a nerve with some readers. The article paints a disquieting picture of the web as a “haphazardly planned” digital city where “malware and spam have turned living conditions in many quarters unsafe and unsanitary.”
There is a growing sentiment that the open web is a fundamentally dangerous place. Recent waves of hacked WordPress sites revealed exploited PHP vulnerabilities and affected dozens of well-known designers and bloggers like Chris Pearson. The tools used by those with malicious intent evolve just as quickly as the rest of the web. It’s deeply saddening to hear that, according to Jonathan Zittrain, some web users have stooped so low as to set up ‘Captcha sweatshops’ where (very) low-paid people are employed to solve Captcha security technology for malicious purposes all day. This is the part where I weep for the inherent sadness of mankind.
“If we don’t do something about this,” says Jonathan Zittrain of the insecure web, “I see the end of much of the generative aspect of the technologies that we now take for granted.” Zittrain is a professor of Internet governance and regulation at Oxford University and the author of The Future of the Internet: and How to Stop It; watch his riveting Google Talk on these subjects.
The result of the Internet’s vulnerability is a generation of Internet-centric products — like the iPad, the Tivo and the XBOX — that are not easily modified by anyone except their vendors and their approved partners. These products do not allow unapproved third-party code (such as the kind that could be used to install a virus) to run on them, and are therefore more reliable than some areas of the web. Increased security often means restricted or censored content — and even worse — limited freedoms that could impede the style of innovation that propels the evolution of the Internet, and therefore, our digital future.
The web of 2010 is a place where a 17 year-old high school student can have an idea for a website, program it in three days, and quickly turn it into a social networking craze used by millions (that student’s name is Andrey Ternovskiy and he invented Chatroulette). That’s innovation in a nutshell. It’s a charming story and a compelling use of the web’s creative freedoms. If the security risks of the Internet kill the ‘open web’ and turn your average web experience into one that is governed by Apple or another proprietary company, the Andrey Ternovskiys of the world may never get their chance to innovate.
Security Solutions
We champion innovation on the Internet and it’s going to require innovation to steer it in the right direction. Jonathan Zittrain says that he hopes we can come together on agreements for regulating the open web so that we don’t “feel that we have to lock down our technologies in order to save our future.”
According to Vint Cerf, vice president and Chief Internet Evangelist at Google, “I think we’re going to end up looking for international agreements – maybe even treaties of some kind – in which certain classes of behavior are uniformly considered inappropriate.”
Perhaps the future of the Internet involves social structures of web users who collaborate on solutions to online security issues. Perhaps companies like Google and Apple will team up with international governmental bodies to form an international online security council. Or maybe the innovative spirit of the web could mean that an independent, democratic group of digital security experts, designers, and programmers will form a grassroots-level organization that rises to prominence while fighting hackers, innovating on security technology, writing manifestos for online behavior, and setting an example through positive and supportive life online.
Many people are fighting to ensure your ability to have your voice heard online — so use that voice to participate in the debate, stay informed, and demand a positive future. Concerned netizens and Smashing readers: unite!
Freedom
Net Neutrality
Some believe that the fate of the Internet has been up for grabs ever since the federal government stopped enforcing ‘network neutrality’ rules in the mid-2000’s. In a nutshell, net neutrality means equality among the information that travels to your computer: everyone has the right to build a website that is just as public, affordable, and easily accessible as any other. However, some companies like phone and internet service providers are proposing ‘pay tiers’ (web service where you need to pay premium fees in order to allow visitors to access your site quickly). These tiers of web service could kill net neutrality by allowing those who can afford premium service (particularly large media companies who don’t like sharing their audience with your blog) greater access to consumers than the average web user.
The debate over net neutrality reached a boiling point when Google and Verizon announced a ‘joint policy proposal for an open Internet’ on August 9th, 2010. Despite the proposal’s call for a “new, enforceable prohibition against discriminatory practices” amongst online content, many criticized it, citing leniency and loopholes.
Net neutrality needs to be made law. If the Internet were to have a slow lane and a fast lane, your average web user could lose many of his or her freedoms and opportunities online, thereby shattering the core values that make the Internet so profoundly valuable to society. However, that’s just the tip of the iceberg for this thorny issue. To learn more, read the full proposal or watch the Bill Moyers episode ‘The Net @ Risk.’
The World into the Web
Browser-based Everything
Google is developing a variety of applications and programs that exist entirely within the browser. Their PAC-MAN game was a preview of what’s to come because it allowed in-browser play of a simple, lightweight video game that required no downloads and relied on pure HTML, CSS, and Javascript. At the company’s 2010 I/O conference, Google laid out its plans to develop “rich multimedia applications that operate within the browser” (according to this New York Times report on the conference). The company plans to sell in-browser web applications like photo editing software (imagine using a Photoshop equivalent entirely within the browser) that it will sell in a web applications store called the Chrome Web Store.
If our programs and applications are about to be folded into the browser, what will exist within the browser in ten years? Currency? Education? Consciousness? Personally, I’m hopeful that my browser will be able to produce piping hot cheeseburgers sometime soon.
The Internet as a Collective Consciousness
The Internet is a medium, and philosopher Marshall McLuhan believed that all media are extensions of the human senses. The engine of our collective creative efforts is the force that’s causing the web to evolve more rapidly than any biological organism ever has.
The Internet is an extension of the collective human mind and it’s evolving into a medium of transcendence. By constructing a place where the collective human consciousness is both centralized in one location (on your computer) and globally accessible (for those with the means to reach or use a computer, that is), our human spirit is transcending the human body. Way back in 1964, McLuhan himself wondered, “might not our current translation of our entire lives into the spiritual form of information seem to make of the entire globe, and of the human family, a single consciousness?”
With the advent of trends including social media, ‘lifecasting,’ and ‘mindcasting,’ the Internet is being used as a real-time portal for the human consciousness. Perhaps those trends will be inverted by some web users of the future: instead of bringing offline life to the web (as so-called ‘lifecasters’ do when they stream live video of their attendance at an offline event), some web users will live their entire public lives online. Imagine a pop star who conducts her entire career online: every interview, live performance, music video or album release conducted solely through a browser window or mobile screen. Or a media theorist who exploited the platform of the web while discussing the theoretical ramifications of those actions. It’d be a great gimmick.
The Web into the World
The ‘Web of Things’
The ‘web of things’ or ‘Internet of things’ is a concept that will be a reality (at least in a rudimentary form) in the near future. The idea is that devices, appliances, and even your pets can all be tracked online. With Google Maps for iPhone, you can currently track your location on a digital map in relation to the streets and landmarks in your area. So it’s not hard to imagine a world where you can zoom in on your location and see detailed, 3D renderings of your surroundings: the cars on your block, the coffee machine in your kitchen, even Rover running around in your backyard! And it’s a good thing that you’re digitally tracking the location of poor Rover; he’s liable to hop the fence and make a run for it now that you’ve created a satellite computer out of everything you own (including his dog collar) by attaching a tracking device to it.
AT&T is betting big on the web of things. According to this Reuters article, the phone service provider is investing in tracking devices that could be installed in cars, on dog collars, and on the pallets used to move large shipments of products. The dog collar, for example, “could send text messages or emails to the owner of a pet when it strays outside a certain area, or the device could allow continuous tracking of the pet.”
Combine the concept of the ‘web of things’ with Second Life-style 3D imaging and you can imagine a web-based duplicate world — a virtual world that corresponds to the real one. But what are the implications of a world where every physical item has a corresponding digital existence online? Can we track the physical effects of climate change in the web of things? Will there be a digital avatar for every pelican carcass in the vicinity of the oil spill that’s devastating the Gulf of Mexico? It’s a tragic shame to develop a virtual world if we let the natural one go to waste in the meantime.
Interactive Landscapes
It has been said that today’s science fiction is tomorrow’s reality. Unfortunately, most good science fiction stories are cautionary tales set in dystopian nightmares.
Simon Mainwaring reports on the N building in Japan, where “the whole building facade has been transformed into a real time dialogue between smart phones and what’s going on inside the store.” The exterior of the building is layered with QR codes (an alternate form of bar code) that can deliver real-time information to your phone. In Stephen Spielberg’s film Minority Report (adapted from a short story by mad genius Philip K. Dick), Gap ads came alive to hawk khakis to Tom Cruise. Looks like we’re about one step away from this scenario.
Mr. Mainwaring imagines a future with “billboards that watch you shop and make targeted suggestions based on your age, location and past buying habits,” and “stores will effectively be turned inside out as dialogue and personalized interaction with customers begins outside the store.”
The technology is cool, but it sounds like a pretty annoying future if you ask me. Who wants to be accosted by a holographic salesperson? The web grants us a great opportunity to use our collective voices to speak out on topics that matter to us. Because there are no regulations yet for much of this technology, it may be up to concerned citizens to make themselves heard if Internet-based technology is used in intrusive or abrasive ways.
The ‘Innerweb’
Cyborgs are among us already — humans whose physical abilities have been extended or altered by mechanical elements built into the body (people who live with pacemakers are one example). What will happen when the Internet becomes available on a device that is biologically installed in a human? What will the first internal user interfaces look like?
Here’s one speculation.
In the near future, we may be capable of installing the Internet directly into the user’s field of vision via a tiny computer chip implanted into the eye. Sound far-fetched? I doubt that it would sound far-fetched for Barbara Campbell, whose sight has been partially restored by a digital retinal implant (CNN reports on Barbara’s artificial retina).
Ms. Campbell was blind for many years until she had a small microchip surgically implanted in her eye. A rudimentary image of Ms.Campbell’s surroundings is transmitted to the device, which stimulates cells in her retina, in turn transmitting a signal to her brain. It’s a miracle that the development of a bionic eye has begun to help the blind see.
How else might doctors and scientists take advantage of the internal microchip? Perhaps the user’s vision will be augmented with an Internet-based interface with capabilities including geolocation or object identification. Imagine if technology like Google Goggles (a web-based application that identifies images from landmarks to book covers) was applied inside that interface. The act of seeing could not only be restored but augmented; a user might be capable of viewing a landscape while simultaneously identifying web-based information about it or even searching it for physical objects not visible to the naked eye. Apply the concept of augmented sight with the idea of the ‘web of things’ — an environment where physical objects have a corresponding presence on the web — and you can imagine a world where missing people are located, theft is dramatically reduced, the blind can see, and ’seeing’ itself means something more than it used to.
If the web is an extension of our senses, it follows suit that the web may be capable of modifying those senses or even accelerating their evolution.
The Crown Jewels
“The next Bill Gates will be the deliverer of a highly technological solution to some of our climate change challenges.” — Lord Digby Jones of Birmingham
In preparation for this article, I considered a variety of wild ideas and fun speculations about the future. Could the Internet be used to solve the problem of climate change, generate tangible matter, or contact extraterrestrial life? Maybe those ideas sound like the stuff of imaginative fiction, but in a world where quantum teleportation has been achieved and researchers have created a living, synthetic cell, it almost seems as if the concept of science fiction is being eradicated while real technology brings our wildest fantasies to life. Here is the result of my most daring (absurd?) speculation.
Time Travel
I called on physics teacher Mark Stratil to answer my last burning question: could the Internet ever be capable of facilitating the development of time travel? Here’s Mark’s answer:
“The Internet is still based on computers, which make linear calculations. Right now, all computers are based on binary code, which is a series of yes and no questions. You can make something that’s incredibly complex with a series of yes and no questions, but it takes a certain amount of time. The Internet still has to go through those calculations and it still physically has to make one calculation that will lead to the next calculation that will lead to the next. So no matter how fast we can get our computers – they’re making billions of calculations, trillions of calculations per second – there’s still going to be some lag time. They’re still limited by time in that way. They still need some time to make that conversation or that calculation.
In that way, they’re kind of chained to time. Their whole existence is based on a linear sequence of things that happen. In order to create something else, something that goes outside of time, you would have to make it a non-linear system — something that that’s not based on a series of yes and no questions, because those have to be answered in a precise order. It would have to be some kind of system that was answering all the questions at once.”
So Mark’s short answer to my fundamental question was basically that the Internet, in its current state, would not be capable of facilitating time travel. However, if the Internet was liberated from the linear structure of binary code and migrated onto an operating system that ‘answered all questions at once,’ then maybe it could have the potential to manipulate time or transcend the boundaries of time.
Sounds unlikely at this point, but one of the Internet’s greatest capabilities is the opportunity to share and develop ideas like these!
Conclusion
Responsible Evolution
Through technology, we hold the reins to our own evolution.
For the first time in history, it might be said that there are moral implications in the act of evolution. The Internet is an extension of our senses and our minds, and its progress is propelled by our own creative and intellectual efforts. The future of the Internet will be shaped by millions of choices and decisions by people from all walks of life. Designers and programmers like us have the advantage of technical skill and specialized knowledge. Given the increasing presence of the Internet in our lives, our choices can have deep reverberations in human society.
We’ll face small choices like what color to use for a button and larger choices like which platforms to endorse and which clients to support with our work. But the real questions form broad patterns behind every media trend and every mini technological revolution. Can we use technology to develop solutions to environmental problems — or will we abandon the natural world in favor of a digital one and the ‘web of things’? Have we fully considered what it means to merge biology and technology? And finally, do we really need a digital tracking device on our coffee machines?
What a thrilling time to be alive! Let’s proceed with great enthusiasm and a commitment to designing a future that is meaningful, peaceful, and staggeringly exciting.
Partial Bibliography
* New York Times Magazine: “The Death of the Open Web”
* Simon Mainwaring: “The Future of Shopping: What Happens When Walls Start Talking”
* The Gutenberg Parenthesis: Parallels Between Pre-Printing Communication and the Digital Era
* New York Times: “Google Pitches a Web-Centric Future”
* Google Talks: The Future of the Internet
* Moyers on America: ‘The Net @ Risk’ (Video)
* Pew Internet Research Poll: Future of the Internet IV
* Google I/O: The Web is Killing Radio, Newspapers, Magazines, and TV (TechChrunch reports)
Related Posts
You may be interested in the following related posts:
* The Evolution of the Logo
* The Dying Art Of Design
* Lessons From Swiss Style Graphic Design
* Art Manifestos and Their Applications in Contemporary Design Sphere: Related Content
Suscribirse a:
Entradas (Atom)
+18.20.50.png)
Blinklist.com
