I offer here some friendly advice about public kiosk systems. Now, I define a kiosk system as any system provided for public use. I realize that most of us, when we think of kiosks think of those systems set up with a fixed interface to allow us to find a store in the mall, or check to see if a book at Barnes and Noble is in stock.
I’m being a bit more general when I talk about kiosk systems, however. I am speaking of systems provided for public use to allow people to check email, browse the web, or update their Facebook page. I am talking about systems found in libraries, hotel lobbies, and sometimes airport terminals. Sometimes you have to pay a fee to use them, but quite often they’re just sitting out there for anyone to use.
Seeing these systems I have to ask myself the following question: Who maintains them? Some are provided by a 3rd-party company as a service. Other systems are probably are set up by roaming hotel or library personnel. Perhaps they get pre-configured at headquarters and sent out to all the “branches.” Regardless, as I see them sitting there all dusty and abused with coffee cup rings on case, I have to wonder if these battered systems are ever again touched by the IT guys after their original setup. Oh sure, if a hard drive fails or coffee gets spilled into the keyboard someone will eventually come along and fix it. But these are not my concerns.
About three years ago I was waiting in a hotel lobby for my wife when I noticed one of these systems and, given my compulsive tendency to fiddle with things, I sat down at the keyboard and started looking around. I noticed stuff almost immediately. Shortcuts to games–obviously not installed with the original software–filled the desktop. I checked the internet cache and was not terribly surprised. Porn and gaming sites were apparently often visited on this system.
The web browser seemed very slow to come up, and when it finally appeared on the screen I started seeing quite a number of pop-up ads. This system was riddled with ad-ware and probably various kinds malware as well. I looked on the tray for some indication of anti-virus software. An expired version of Norton or something similar had been installed, but was never purchased.
However, the biggest surprise was still to come. A quick check of the Windows XP system settings revealed that the user account I was currently using, and that which dozens if not hundreds had used before me, had administrative rights on that system. This explained the seemingly endless list of software that others freely installed. The system was a dangerous mess, and it seems to be the “norm” among those publicly available. These systems should ALWAYS be avoided. What follows are my reasons…
First of all, giving average user administrative rights is like giving a kid a baseball bat to play with in a glass shop. I don’t say this to be insulting, I’m just stating a fact. Malware can do irreparable damage to an operating system when it runs under an account with access to all the system files and the registry. It’s common sense, but many who set up such systems are too lazy or apathetic to care. It’s much easier just to give everyone administrative rights so that nobody bothers you to install something or change a setting. Let them do it. It’s easier.
A few years ago I did IT administrative work for a securities trading company. I stood firm with regards to administrative rights. Normal user accounts were not members of the local administrative group on systems. I never took the position, however, of withholding these rights as some sort of personal power trip, nor did I tell people I thought they’d break their systems. I was always quick to explain about malware and how I was trying to protect them. Heck, I even created secondary administrative accounts they could use if they needed it. I bent over backwards, but it was never enough for some.
One lady was in constant gripe mode about not having administrative rights. I explained, and still she complained. One day, she brought her home system in and asked if I could have a look. It had gotten slow. I took it home that evening and spent an entire weekend removing dozens…no..hundreds of instances of malware. When I brought it back, I asked her “why did your home system have so much malware and your work system does not?” Her immediate answer was “Antivirus software is better on the work system” to which I replied “Nope.” I explained that her system was such a mess because she ran this system normally with administrative rights, giving malware much more to work with. She thanked me, gave me a case of Guinness for my work, and continued to complain, but perhaps a little less vehemently.
The point is that any system where users regularly do their day-to-day activities with administrative rights is on borrowed time. It’s like silly putty or that toy slime you sometimes buy (ok sometimes “I” buy). Once you drop it on the carpet you might as well toss it as you’ll never get out all the nasty bits that it picks up. A kiosk system sitting in a lobby with administrative rights will pick up every bit of digital nastiness out there.
If I were evil, I believe I’d infect kiosk systems with keylogging software, collecting all the user names and passwords for every person logging in to Paypal, Facebook, or even their bank accounts. Such logins are ripe for the harvest on kiosk systems. Keyloggers come in two varieties. Software keyloggers collect all the keystrokes through memory-resident software and then transmits this data to a 3rd party. Hardware keyloggers are devices installed between the keyboard and the system. While hardware keyloggers require the bad guy to retrieve the device at a later time, they are also nearly impossible to detect unless they are visibly noticed.
To further exacerbate the problem, often these kiosk systems are connected to the same network as everything else in the hotel. Imagine, if you will, a bit of nasty code running in memory on the kiosk system that scans the network looking for additional victims. A kiosk system could be a launching point for an attack on your laptop as you use the wireless network at the hotel, not to mention the hotel’s point of sale system and business related servers and databases. A clever virus could be written to constantly make reservations for all rooms or cancel such. Of course, I’m just thinking out loud here.
If you run a hotel or library and have such systems, here’s a couple of excellent ideas. Hint: Read all three, but pay special attention to the first two. There’s a pop quiz at the end.
1. Use a live CD, not a hard drive. Boot the system to an Ubuntu or Knoppix Live CD and let people browse all they want. At the end of the day, reboot the system. Nothing in memory will reside, and you’ll provide a cleaner computing experience. It’s a little slower to operate from a live CD to be sure, but worth it.
2. Re-image the system daily. Create a basic system image and use this to restore the system every evening or when problems occur. This will put you back at square one every day. There really is no excuse for not at least doing this on kiosk systems.The process can even be automated to happen at night with very little effort.
3. If for some incredible reason points 1 and 2 are not available to you (which, if you’re honest, they ARE) then make sure that you have decent anti-virus software, keep the systems patched, and, above all, do NOT give the default account administrative rights. I do not recommend this point, however. It requires some ongoing “maintenance.” You may start off with good intentions, but eventually the cares and woes of your other responsibilities will distract you and before you know it the patches and virus signatures are out of date. Then there’s that time you make an “exception” and give someone admin rights for some strange reason and then forget to revoke them. Necessity may be the mother of invention, but laziness can be it’s favorite uncle. Make your life easier and do the smart thing: Use a Live CD or re-image the systems regularly.
There are other options as well. The use of thin clients such as Citrix may be available so that the OS is not really running on the system which you are using but instead a remote server. However, such solutions are usually costly and not within the budget of most.
So what if you’re a hotel customer or you want to use that library system? Don’t do it unless you know they are following one of my first two points above. But also don’t be afraid to bring along your own live CD and ask if you can use it. You may get strange looks or be viewed suspiciously. This is a good opportunity to introduce that library IT guy to the wonders of a clean, bootable, non-persistent environment.
If you “have” to use a kiosk without proper protection (and you never have to) then use common sense. Don’t visit sites to which you log in. If you happen to visit any such site, even on a safe system, make certain you log out completely. My wife’s family visited once and one of her relatives often used her computer for his facebook updates. Almost every time my wife sat down she found herself logged into his facebook account. (I had some really good ideas but she wouldn’t let me do anything.:-) ) Imagine a stranger sitting down at that kiosk system in the hotel finding himself logged into your online bank account or email.
Finally, I just want to say that Kiosk systems “can” be safe if those in charge follow best practice, but they should never be completely trusted. Besides, you’re on vacation. Give Facebook a rest and go to the beach.
Quiz: Which of the following is the least desirable option for keeping public systems “clean” in a hotel or library.
A) Use a live CD
B) Use a hard drive-based OS, but keep patches and anti-virus up to date.
C) Use a hard-drive based OS, but re-image or clone it daily.
The correct answer is B.
David H.
Aza Raskin reports of a Javascript new tool in the phishing scammer’s arsenal that allows a phishing site opened in a tab in your web browser to change its content after focus is lost on that tab. A user opens the site in a tab, leaves it, and after a few seconds, it looks just like his gmail site that he needs to log into again. This attack could be combined with other types of attacks designed to detect browser history so that the site that appears will seem normal to the end user.
Using the NoScript plugin in Firefox is probably one of the best ways to avoid this trap, though I’m still trying to decide whether this provides some true, additional danger or is simply an interesting novelty. Regardless, it does take advantage of our tendency to have so many things open in our browser at one time that it would be easy to think that we actually DID open that Gmail page and simply forgot about it. I have seen end users with up to 30-40 tabs open at the same time.
I’ll probably be saying more about this as I have a look at the Javascript source that Raskin provides on his site.
David H.
Botnets have historically been often controlled via IRC. A Bot-herder would use specially-designed scripts in IRC channels from which the infected systems could retrieve special commands. IRC served as a platform for control.
Over the last couple of years Twitter has also become such a platform because of its wide accessibility. Accounts on Twitter can easily be set up anonymously. Using a twitter client, an attacker may now control Botnet systems using a Smart Phone. While he’s standing in the frozen food section of his local grocery store, he’s launching a DDOS attack against a network. The appeal of this is certainly understood.
A new tool called TwitterNET Builder has recently made the news as it provides script kiddies an easy way to achieve Botnet control using Twitter. The software creates an executable used to infect the target systems, causing them to watch for specific commands in specific Twitter accounts.
Twitter’s response has been swift. It seems that accounts where these commands are showing up are understandably being suspended. The same thing happened back in IRC days when accounts were found to be automatically posting such things in chat channels. Attackers at this point would need to find a way to encode these commands in such a way as to fly under Twitter’s administrator’s radar. The TwitterNET Builder seems to provide a certain list of commands which could be easily detected. The ability to customize the commands to use more common keywords or even encode the command text would provide more cover for the attacker.
Social Networking has always provided a stealthy platform from which attackers may control their victims. I wonder if, somewhere out there, someone’s writing “FacebookNET Builder.” Maybe it’s already being used. Setting up accounts on Facebook is a process that is a bit more involved than Twitter, so that might be an impediment for an attacker.
The best solution from the standpoint of a network administrator who desires to protect his people from these attacks would be to block Twitter and other social networking sites altogether. IRC is blocked for this very reason, and this would effectively remove the ability for an infected system tor receive instructions from its Botnet master.
The scenarios for doing evil are many, and becoming more numerous as more platforms for social networking are unveiled. Today it’s Facebook and Twitter. Tomorrow –who knows? The question is, as these new social networking platforms are being created, are their creators thinking about how their applications could be used for evil? Probably not. But it’s such a nice thought.
David H.
I do not believe I have laughed this hard in a very long time. Enjoy!
http://tv.gawker.com/5526868/jon-stewart-slams-apple-over-its-handling-of-gizmodo-case
In other Apple news, Jobs explains why Flash is not supported on any of his products. They will support HTML 5 instead, but his reasoning is interesting:
Jobs begins by questioning the closed nature of the product, noting that “Adobe’s Flash products are 100% proprietary. They are only available from Adobe, and Adobe has sole authority as to their future enhancement, pricing, etc.” Closed products stifle innovation, Jobs argues.”
Uh…and Apple products are somehow more…open…than Adobe’s? Unbelievable.
According to this article, Google has announced that, as part of its Street View services that, along with photographs of streets and such, it is going to also collect Wifi ESSID’s and Mac addresses as well, meaning that Google is now in the business of wardriving. This is starting in Germany, but it will assuredly happen in the United States as well. This in and of itself is not terribly troubling. I’m not certain how useful such information is really going to be. As I wardrive, I notice networks named after businesses and people, but quite often they are left at the default “Linksys” or “Netgear” names. SSIDs can be changed, and so can Mac Addresses.
What should be alarming to all is the that this is just another step in Google’s agenda to know everything it can about you. Google has made no secret of the company’s lack of respect for privacy, taking the “if there’s something you don’t want anyone to know about maybe you shouldn’t be doing it” position. It’s an old argument used to further erode our rights. People who want privacy obviously have something to hide.
What I propose is this. Everyone who reads this who owns a wireless router, change your SSID to “GoogleStinks” or “GooglehatesPrivacy”. Obviously, my readership will need to expand beyond 2 people for this to make a difference.
David H.
This article caught my eye this morning. The CIO of CNL Bank in Oriando is considering sending its customers Ubuntu Live CDs customized to autoload the web browser defaulting to the banking website. This places the customer in a sanitized operating system isolated from the customer’s home operating system. The reason for this is obvious–to mitigate against the effects of malware infections on the customer’s system while the user performs online banking transactions. Malware, depending on how it was designed, can often steal authentication information from banking customers as they log in. Software keyloggers as well can steal all the keystrokes and transmit them to the attacker, giving him access to all sorts of data.
This is a very good idea. The Live CD would not be persistent, meaning that whatever bad things are in memory would be no longer there when the system was rebooted. The user would always be greeted by the same safe, clean environment.
Making this a requirement of customers is also not a bad idea. The session to the bank could somehow be keyed to the Live CD, making any other connection impossible. It is really more about protecting the bank than the consumer. Perhaps the FDIC could lower premiums for banks who inforce such policies and controls? <shrug>.
However, we must not fall into what I call the SSL trap. Some companies who started doing business transactions online have had a bad habit the past of telling their customers that because their site uses SSL, it’s perfectly safe from intruders. Many such companies have found out the hard way that SSL does nothing to mitigate against XSS, SQL Injection and the like. Hopefully, banks will not think of this kind of sandboxing as a bullet proof vest either. While Malware may be virtually eliminated, other man-in-the-middle attacks still pose a threat. And let us not forget about hardware keyloggers.
I say that Malware may be “virtually” eliminated. A system booted from a live CD may be isolated from the user’s hard drive and any malware that infects it, but it is not invincible against memory-resident baddies that infect the system while the user has it up and running.I wouldn’t be surprised if malware creators shifted their attention to Ubuntu should the live CD become a popular way to do banking. I’m also thinking about how simple it would be to create a trojan version of the LiveCD with a counterfeit label. Hey, I’m a paranoid weirdo geek. I can’t help but think of such things.
The inconvenience exists, of course, with having to reboot your system every time you want to do online banking transactions.One alternative to rebooting, however, is that he user could also install Virtualbox and run the live CD in a virtual machine. As with security controls and policies, we are always slowed down a bit. Security is no friend to efficiency. It is the price we pay.
Nonetheless, my hat’s off to the geeks working at banks who come up with these simple, elegant solutions for end-user security.
DH


I’d almost forgotten about this XKCD strip until I stumbled upon it again yesterday.

In December of last year CNN carried a story about US military drones in Iraq having their video feeds “hacked.” The full article is here:
What I find amazing is the way, once again, the “h” word is thrown around. The fact is, the transmissions were unencrypted. I’m not downplaying the skills needed to intercept such signals. I’m not sure I could do it, but then again, if I can buy equipment and/or software (http://www.skygrabber.com) somewhere which would allow me to intercept the signals without having to have a passphrase or a certificate or a token or something, then no skills are really required. The US military were simply caught with their technological pants down. The article already mentions that higher-end,
The U.S. military and intelligence operations use pilotless drones in Iraq and Afghanistan both for surveillance and to fire missiles at targets.
While the CIA has never publicly acknowledged it, the agency operates the unmanned planes in Pakistan, where it has used drones to strike at Taliban and al Qaeda operatives, according to officials familiar with the strategy. But a U.S. official with knowledge of CIA and military UAV missions told CNN the drones used in Pakistan missions use encrypted feeds and are not vulnerable to hacking like the military drones used in Iraq.
The official said the drones employed by the intelligence community in Pakistan, which use state-of-the-art encryption technology, are used in a much more limited capacity than the military drones.
So the technology does exist to encrypt the transmissions as our intelligence agencies are using it, but the military is using older, less secure equipment in their drones. Apparently, at Langley they’re using WPA2 for their wireless and the Pentagon is using WEP (Or maybe just an open Linksys).
This leads to a higher concern. If the video surveillance can be intercepted and potentially altered, what about the actual commands that control these unmanned drones? Could a drone be turned around to attack our own troops?
All that aside, I think using the word “hacked” in any way associated with this incident is to shift blame. It would be like labeling someone a “spy” who overheard two soldiers at Wal-Mart discuss a secret mission and then later blogged about it.
My prediction is that, unfortunately, much more effort will go towards stopping people from developing software like Skygrabber than it will towards actually fixing the drone technology. We need a scapegoat, and it probably won’t be our military and the risk analysis performed when developing such technology.
A lot of stuff has been written and said lately about MITM attacks, and quite a number of different kinds of such attacks exist. SSL MITM attacks, such as SSLStrip, basic ARP Spoofing, and even a few wireless MITM attacks exist to cause end users grief.
It should be noted, however, that the average user sitting at home or in his office accessing his Paypal account is not that susceptible to such attacks unless his local network has been compromised. THe aforemented attack requires the attacker to have access to that network and place himself between the victim and the victim’s gateway in the actual data path. There’s no real way to perform ARP spoofing between a guy sitting in his basement in Idaho and his bank in New York if you’re on a system in Austin, TX. The public network we commonly call the Internet just doesn’t work that way, and inserting yourself passively between two entities there is nearly impossible unless you manage to hijack a router along the way or become a router. That’s probably not gonna happen.
I say “passively” as to suggest a kind of a attack that requires no action on the part of the victim to perform. Some attacks do exist, usually on the Web application level, whereby a victim is tricked into launching a script or going to a harmful site while thinking they’re at their bank’s website. Not really the scope of what I’m discussing here. In future posts such types of attacks will be discussed.
However, while a guy sitting in is home may not be as vulnerable to passive MITM attacks, the guy sitting in Starbucks or using the wireless in his hotel is very vulnerable. How can someone be certain the SSID listed as “RamadaInn” is actually broadcasted from a hotel-owned access point and not some guy in the next room or at the next table with a laptop and/or a funny plastic pineapple? Forget wireless. Even the wired networks in many hotels are still based on hubbed networks where everyone sees all traffic, and even on a switched network, you’re still exposed.
Try to show some wisdom when using public internet hotspots, airport Wifi or complementary hotel wireless networks. There are people like me out there who know how to do perform these various kinds of MITM attacks, and many of them are not nearly as nice.
How many times have we heard people say “I know I’m safe when I visit my bank’s website because it uses SSL.”? Of course, there’s some element of truth here. Nobody casually sniffing the network is going to be able to read any of those SSL packets. The level of security here, of course, ignores any of the possible application vulnerabities on the site itself. SSL does not protect someone from XSS or the site from SQL Injection attacks. SSL is often thought of, unfortunately, as a cure-all for our website security woes.
But now, clients browsing SSL-enabled sites may fall victim to another form of attack. Using a MITM (Man-in-the-middle) method, an attacker is able to strip off all SSL from the victim’s session using a tool called SSLstrip. First, let’s look at the logical view of how it all works.
- An attacker on the victim’s network (LAN or possibly wireless) uses ARP spoofing to insert himself between the client and the gateway, intercepting all traffic between the two.
- The attacker forwards all HTTP traffic to a predetermined port.
- The attacker then launches SSLstrip and listens on that port.
- The victim attempts to visit an SSL-Enabled site, but what happens is that the attacker intercepts this request and serves the victim the site without SSL. The attacker still communicates with the site over SSL, but the victim is communicating through the attacker using clear HTTP.
- The victim’s username and password is collected by SSLstrip and stored in a log file.
The creator of this tool, Moxie Marlinspike, has a very good tutorial of how this tool works on his website here.
This adds a new level of danger for those using public WiFi in airports and hotels. Wireless MITM attacks are already know about, and SSLstrip makes them all the more effective. When using public hotspots, it is always recommended to do all such sensitive browsing over a VPN Connection.
As with all such tools mentioned on this site, SSLstrip should not be used for illegal purposes or without prior approval.
