UW Computer Security Research and Course Blog

Intel healthcare: SOA Expressway for Health Care

http://www.intel.com/healthcare/ps/soa/index.htm?iid=health+lhn_soa

Intel has created a scalable, easy to deploy health care network with the hopes of enabling sharing and collaboration of health care information. Intel Health Care network is build upon common components such as J2EE and the .Net framework, relying upon a High-performance XML Engine for data transmission. It is a “codeless” system, which means the network can be deployed and managed without the need for software development assistance. Once fully deployed this network promises great cost and efficiency gains, as healthcare and patient information can be shard much more easily. However the creation of a new system which will handle large amounts of sensitive patient and drug information brings about many interesting security questions.

Assets:

· Patient Information – it is of utmost importance to protect all sensitive patient information, including condition and treatment as well as address and billing information.

· Drug information – Many hospitals have strict regulatory policies on the management of drugs, outlining proper administration and inventory practices. The integrity (and sometimes secrecy) of information regarding the status of the pharmaceuticals in the organization must be maintained.

Adversaries:

· Doctors and hospital workers – The primary users of the system will be the various hospital staff. They will have the most interaction with the system as they will use it on a daily basis. Hospital staff utilizing the network will require a certain amount of authority (within the system) in order to properly operate it. This presents a potential threat, as they will have direct access to patient and drug information, as well as the authority to modify this information.

· Network maintenance technicians – The system is designed to be stand-alone on a day-to-day basis. There will be instances when the system will require a certain amount of routine technical maintenance. The people performing this maintenance will be very familiar with the internal workings of the system and will have full access to the system. This poses a threat, as it could potentially compromise patient information.

· Patients – If patients are given a chance to interact with the system, it may be possible that they can in some way compromise the system to extract confidential information, or falsify information.

Potential Weaknesses:

· Information Storage – If sensitive information is stored on accessible and/or unencrypted hard drives, it becomes increasingly easy to tamper with those components (the disks) in the interest of obtaining or modifying confidential information.

· Information Interception over Transmission – When sensitive information is shared between multiple nodes (a network), there must some kind of transmission mechanism. Such a mechanism could be a weakness if it does not properly protect the integrity and confidentiality of the data being transmitted. Also if the mechanism is not robust or reliable, this could result in the loss of important patient information, vital to patient care.

Defenses:

· Required authentication – all persons who will have any interaction with the system should have a strong means of identifying and authenticating themselves as valid users. All users should be limited in their actions and given just enough authority to perform the needed task.

· All information (both patient and otherwise) should be stored on encrypted hard drives which are protected physically.

· Any transmission of information should be done through an encrypted channel.

Risks:

The risks associated with this system are of grave consequences, as they involve sensitive and personal information for many patients. The risk of information leakage/compromise is present not only when the system is accessed/operated by hospital staff, but is also inherent in the fact that much sensitive information is stored and transmitted over potentially unsafe mediums.

Conclusion:

The Intel SOA Expressway for Health Care is a very promising technology which unites health care services and provides access to a great breadth of information. It is important to handle this information with great care and a sense of responsibility, as the information is oftentimes sensitive private. Intel is doing this by utilizing industry standard security practices, such as XML and web Security.

Self-scanning checkout, also called “self-checkout” is an automated process that enables shoppers to scan, bag, and pay for their purchases without human assistance. A typical self-scanning checkout lane looks like a traditional checkout lane except that the shopper interacts with a computer’s user interface (UI) instead of with a store employee. Instructions are given to guide shoppers to complete the checkout process. Typically, the customer scan each item or manually enter its identification code and bag it. The weight observed in the bagging area is verified against previously stored information to ensure that the correct item is bagged, allowing the customer to proceed only if the observed and expected weights match. After scanning and bagging, customer may choose method of payment: debit card, credit card, or cash. There is normally an attendant watching over several self checkout machines, to provide assistance, prevent theft through exploitation of the machines’ weaknesses, and to enforce payment. Attendant assistance is also required for the purchase of age-restricted items.

(Read on …)

In the United States, automobiles are everywhere.  Most middle-income families own more than one vehicle, and chances are that everybody knows of at least one person whose vehicle has been broken into or stolen.  Cars, trucks, and SUV’s are very expensive and contain many assets that would interest adversaries.  As technology improves, the ways vehicles are secured continually gets better, but thieves also get smarter.  There will never be a completely secure vehicle.

(Read on …)

The HomeLink Universal Transceiver is a device that, like a universal remote, can record the output of a wide variety of garage door openers and home automation control systems and emulate the output for future use. When used as advertised, the HomeLink system simply replays signals that you could have produced anyway, but from a central source. However, since the HomeLink device basically allows replay attacks, there are security implications if the device is to be used by someone with sinister intentions.

Community gate openers and garage door openers are, by their very design, long-range communication devices. If the signal the opener emits cannot be detected a good distance away, the devuce is not doing its job. Therefore, it follows that the HomeLink device could record garage door opener signals while passing by a car that is using a garage door opener. With access to many types of garage doors after being in the proximity of the door opening, a world of possibilities opens up.

(Read on …)

An add-on is a simple plugin that you use, say for firefox, to let you do your work more easily. This also lets you customize the browser in ways that do not affect the productivity of other people. Add-ons are becoming a major part of the browser functionality but sans the scrutiny that goes into developing a browser.

Assets and Security Goal:

* Assets: Your browser, everything that you use it for and your cookies. Uh, not the ones you eat. and privacy.
* Security Goal: Protect your privacy at all cost and your cookies and your intimate browsing secrets!

Adversaries and Threats:

* Unauthorized publishers: This is the dreaded group of publishers that are able to make an add-on for your browser and pass it off as being legitimate and harmless. This is much easier than you think since most add-ons are unverified or rather community verified and it might take a while to find an exploit.

Weaknesses:

* Counterfeit add-ons are the biggest risk – a majority of the add-ons are through unverified authors.
* Deceived by community rating. Since the rating for the plugins is done by the community, an obscure/malicious add-on can be easily made to look like a legitimate one through a community of attackers/ an attacker with a community of profiles.
* Unauthorized plugins from third party websites.

Defenses:

* Other legitimate users – These are probably the best and most formidable defense when it comes to validating add-ons. However, this also a delayed defense since ‘enough’ users will have had to use the add-on for someone to finally detect a malicious exploit.
* Firewall – Your firewall is also your second line of defense when preventing backdoor access through the malicious add-on
* Antivirus software – An up-to-date virus definition file should help the software detect a malicious plugin. However, this also assumes that the attacker used a known exploit/trojan/virus to inject into the add-on.
* Security updates from the browser, OS – These can help patch the exploits that are currently in place.

Risks:
The risk of being duped means to lose a significant amount of personal information that is stored in the browser. With the shift of browser towards acting like an OS with features to save passwords,sessions, etc, there is an unbelievable amount of personal information that can be stolen through a malicious add-on. The add-on can also redirect to malicious websites that involve elaborate phishing scams leading to the loss of information and money. Such attacks give the hacker a complete control of your online portfolio which can be held for ransom and also misused, causing personal damage.

Conclusion:
Overall, although there are inherent risks to open source projects like a community browser, a large part of the attacks are easily mitigated due to the sheer number of users that pass through such an add-on. There also seems to be significant,active and unofficial community that monitors the plugins for malicious intent. One way to decrease the probability of such an attack would involve letting a significant time pass from the release of the plugin to the installation for it to be tested by active community members. Filtering the installation of add-ons also becomes an important but often impossible task in a corporate environment where the risks are especially high. Add-ons(unsigned) are definitely a double edged sword that need to be dealt with care.

A game of poker can be played for fun or money. The game itself uses low tech equipments, and the two main ones are a standard deck of cards and playing chips of different colors to represent different amounts of money. Depends on the type of poker game, the dealer usually shuffles the card and deals out the cards to the players. Then the players would bet chips to play against each other. The goal is to garner as much money (in chips) as you can. I’m going to use the terms chips and money interchangeably.

(Read on …)

“Facebook is slowly tearing down the wall around its silo and is starting to expose more of its data to the outside” (From Facebook Opens Up: Lets Developers Access Status Updates, Notes, Links, and Videos). Now Facebook allows the third-party developers to have access to users’ private data, such as status updates and notes. This is intended to make both developers more flexible in making and using applications. Moreover, Facebook wants to make more and more people use Facebook by join the OpenID foundation. However, weaknesses and potential security problems are found by doing this update for Facebook’s API.

Assets and security goals

• Since the Facebook joined the OpenID foundation, people who posses OpenID (one account, one password, multiple sites login) account will also have Facebook account. Thus, more and more people will join Facebook and use Facebook for networking.
• The developers’ application should be verified before release it to public and allow people to use it. Moreover, there should be stricter terms and conditions on registration for developer, such as phone number validation or email validation, so that they will not misuse users’ private information (pictures, videos…etc)

(Read on …)

Most people in our society today are familiar with the concept of MMO gaming.  World of Warcraft, for example, is something most everyone has heard of.  Most MMO games operate under a fairly strict client/server paradigm.  A company that desires to produce an MMO will create a client that handles the graphics processing, user input and output, and perhaps may store some basic per user settings, usually again related to display settings and interface options.  The remainder of the game, including all user character data and user interaction with the online world, is stored and run on company controlled servers.  This assists the company in its endeavor to give the users the experience they intended as well as control various types of cheating.  In addition, users generally cannot play offline – this means that a given user must authenticate with the server in order to access a given character or play with others in the virtual world.

(Read on …)

EDIT: It appears that I goofed with the “more” tag when I first posted this, so I’ve included the rest of the article below.

Since the days of waking up at 5am to watch the Tour de France live with my dad at eight years old, I’ve been a big fan of bikes. I’ve since grown to love riding them, and spent several years as an avid road racer. While I’m somewhat of an anomaly, many of you also rely on cycling for transportation to class, to work, and elsewhere. Unlike cars, which are just slightly harder to steal, bikes are the candy-from-a-baby in the world of theft. One magazine article I read several years ago had a “professional bike thief” (probably a security professional who learned methods of theft in his research) attempt to steal a bike secured by one each of every available bike lock on the market at the time. In public. The result? All but a single lock could be circumvented so quickly that nobody in the area even noticed that it was not unlocked by normal means.

I have to say, I am particularly bitter about bike security. A few years ago I was living in Stevens Court with a few friends. A past summer job at Gregg’s Greenlake Cycles had yielded an absurdly cheap employee purchase of a Lemond Tourmalet, a very nice road bike. I wasn’t using it to commute to school (who locks up a bike like that around the Ave?), but I did have it in our apartment so I could go riding. One day I came home and it had been stolen from my living room. My roommates had left the front windows wide open and the door unlocked. Go go speed racer, go.

(Read on …)

I was lost at first when starting Lab 2, as I had little to no eperience with web programming. After floundering around for a few hours I got a better idea of what we were supposed to be doing and with the  XSS cheat sheet was able to rapidly discover appropriate exploits for each of the filter versions on the mock search engine (except #5, of course).

Once I’d satisfied myself that I could get all the cookies I wanted I immediately launched into a more thorough investigation of the environment I had been working with, and began discovering real vulnerabilities. I was excited by the prospects available and decided to make a security review out of it. I spent the next couple days experimenting, then jumped onto the blog to write my security review only to find that two of my classmates had addressed the same topic the day before. Eriel Thomas addressed the security of the server at yoshoo.cs.washington.edu in his post “Smashing the Lab for Fun and Profit”, whereas David Balatero discussed his success in phishing about a third of the security class (including me… ouch) in “UW CSE Resources”. Just goes to show you that you should always examine links, even from trustworthy and computer savy friends :P.

I nearly despaired at several days’ work gone for naught, but after carefully reading both of the posts I believe that I still have something to contribute. My discussion will focus a bit more on the security of abstract and provide other additional details.

(Read on …)