UW Computer Security Research and Course Blog

Security Review: Automated Traffic Enforcement
Summary:

This security review was motivated on a family member of mine receiving a ticket from this technology: the automated traffic enforcement. This is a fairly new system cities are using to enforce traffic laws. They are using systems that detect when drivers run red lights and speed in certain zones. The purpose of these systems is to reduce traffic infractions in area and overall improve traffic safety. The Stop Red Light Running systems work by taking two photos, a front and back picture, of the vehicle running the red light. The sensors are synchronized with the traffic lights and are able to detect vehicles driving through intersections on red lights. The sensors trigger the cameras that record the day, time and place of the violation. As for the speeding systems, they use photo radar, which measures the speed of the vehicle, and snaps two pictures of the front and back of the vehicle. Once a vehicle is detected as violated, it is sent to traffic enforcement and the traffic infringement is mailed to the owner of the vehicle.  The traffic enforcement expects the delivery of the letter to be reliable such that if you do not submit a payment within the time frame, the vehicle owner will receive a late notice and the ticket fee increases.  Unfortunately, this is what happened to my family member.
Although I agree that this is step in the right direction to improve traffic safety. One question that poses in my mind is how accurate are the infractions? In the case of a vehicle running a red light, it is apparent if the car in the middle of the intersection and the light is red. But for a speeding infraction, how accurate is the system in correctly identifying infractions, meaning does it generate false positives? Also, is it possible for someone to access the traffic enforcement network and speeding systems to generate false speeding infractions?

Assets & Security Goals

• Drivers’ Info, we do not want the driver’s information stored in the DMV to read by parties other than the person who made the infraction. If this is not secure, privacy can become an issue.
• Tickets, we do not want the system to distribute false tickets based on false information.  If this is not accurate, the system can be recognized as not usable.
• Streets, we want to drivers to abide to traffic laws in all areas such that it does not endanger the safety of other drivers and pedestrians. We want to ensure traffic safety overall.

Potential Adversaries & Threats

• Malicious users – A user can obtain unauthorized access to the system and begin printing out false tickets, having information from the DMV sent out to vehicle’s owner and intercept that parcel to read information about the vehicle’s owner.
• Unauthorized car users – A person who has unauthorized access to another person’s car can force tickets upon the vehicle’s owner by break the law at known automatic traffic enforcement sites. This is because there isn’t a form of verification from this system. It only uses the infraction and vehicle, not driver.

Potential Weaknesses

• Weak passwords or mis configuration of the automatic traffic enforcement may exist such that they are known and malicious users are able to obtain this information to gain unauthorized access.
• Eavesdroppers can intercept the ticket notification through the mail to read sensitive information in the parcel.
• A hijacker/malicious driver can obtain unauthorized access to a car and perform these infractions. However, the system will always send tickets to the vehicle’s owner address. Therefore, a malicious user can “rack up” many tickets for a vehicle’s owner despite the vehicle’s owner not performing the infraction

Potential Defenses

• Strengthen aspects of the system to prevent unauthorized access to the ticketing system.
• Determine a new method to notify a vehicle owner of the infraction they have made.
• Redesigned the system to include verification of the driver performing the infraction such that it does not default to the vehicle owner.

Conclusions
Despite some of this system’s weaknesses, there has been a noticeable improvement on traffic infractions and traffic collisions due to running red lights and speeding. It was stated that in New York City, crashes that were caused by running red lights were reduced by 70%. As a result of this, it improved traffic safety. Before this system was created, traffic infractions were cited only if an officer on duty was able to spot it, either with their own vision if it was someone running a red light or with their radar gun. With this new system, this allows officers to improve their public safety coverage and focus on things other than traffic enforcement.  Furthermore, the system acts as a deterrent as well because drivers are well aware that if they do speed or run red light they will be caught. Prior to the system, many people are aware of the laws and aware of the consequences but weight it against the notion if they are caught performing the act. Most of the time, drivers believe they won’t be caught because they bank on the fact cops are not at specific areas for 24 hours a day, 7 days a week. With this automatic system, it allows this 24/7 coverage. The next steps for this system would to be reducing false positives and ensuring delivery of tickets. This is because delivery is never guarantee to be reliable.

Since many people are probably busy working on or wrapping up lab 2, I thought it would be a good time to post a security review based on some interesting findings that I discovered in the course of completing the lab. My search began with version 5. When I began attempting version 5, I became increasingly frustrated to the point where I believed that version 5 was completely secure from cross site scripting and the only way to break it for extra credit was to break the server itself. So that’s what I attempted.
(Read on …)

According to a post on the Internet Storm Center (ISC), some malware writers have turned to leaving false parking tickets in order to lure victims into running malicious programs. The parking tickets contained a URL where one could see a picture of the supposed offense. Upon arrival to the site, users were prompted to download a toolbar in order to view their particular picture(s). Link here.

Writers of malware often have to contend with the question of how to make users visit a particular site, or run some untrusted code. Spam emails, submitting links on popular social websites, and inserting malicious programs into data downloaded from peer to peer applications are all common practice. Savvy users know the danger of running untrusted programs, especially when appearing from a dubious source. The trick, then, is for the malware writers to make the source appear legitimate. By using a physical medium (paper, as opposed to a link or an email), potential victims were more likely to trust the website. In addition, many of the supposed parking violators likely felt wrongfully accused, and wished to dispute, or at least view, the evidence against them. And in trying to obtain that evidence, they allowed a malicious program to install itself on their computer.

This tactic also puts the writers or distributors of the malware at some risk. In most cases, locating the original person or people behind malicious software is very difficult. Because of the nature of the internet, anyone could release malware from anywhere in the world. But, when these distributors placed their false parking tickets on cars, they also told authorities where they were. Instead of being perhaps some anonymous author in who knows what country, the distributors of these parking tickets (or some accomplice) physically had to be in Grand Forks, North Dakota on the days the tickets were given out. Law enforcement agencies now have a chance of catching the perpetrators, and charging them.

Preventative measures against this sort of attack are difficult. As always, the key is to not run untrusted software, and to be aware of the dangers. But just what does untrusted mean? Nobody expects an attack to come from a parking ticket. Awareness in this case would have helped as well. When this website began asking to install a special toolbar so you can view pictures, you should get suspicious. Some problems, such as social engineering, are just too difficult with technology alone. Being informed about risks, about methods of attacks, and about trusted information systems will go much farther than any malware detection/prevention software, and is more likely to keep up with the times, as well.

Link to article.

In early September 2008 during the TechCrunch50 Conference, there we many companies that came forward presenting ideas on how to change the advertising business.  One such company, Adgregate Markets, presented an idea they call the ShopAds widget. This widget can be placed on any website like a normal banner ad, but is instead a fully transactional ad that allows visitors to the site the ad is place on to conduct a business transaction (such as buying and item or ordering a service) without leaving the hosting web page.

This is big news both for host sites that may gain revenue from their ads, as well as the companies trying to sell a product. For host sites, it means their pages are sticky; visitors no longer leave the for a 3rd party site when they see a product they like. Instead, they can just purchase it and continue to view the content. For the company selling the product, it means their returns are much greater than previous click-through counting methods as the results they are in the form of actual sales and revenue.

But what does this mean for the online consumer? Of course, it means they can now make purchases through ads without having to go to another site, but it also means they have to be smarter. Adgregate claims in their press release that “Through ShopAds, Adregate Markets enables consumers to securely purchase products entirely within the confines of the ad unit, without being redirected away from the publisher’s site.” However, a problem arises when a ShopAds widget is placed on a web page that uses HTTP instead of HTTPS. Since the page itself is transmitted HTTP, the content of the page is in plaintext. Additionally there is no way to verify that widget came from any particular location. For example, a malicious router launching a man-in-the-middle attack could replace the widget on a page with their own widget that appears to be legitimate. Visitors to the web page may then interact with it assuming it is the company it says it is. Although ShopAds are flash-based, and thus can establish secure connections, this only has meaning if the source of the ad itself can be verified.

Assets and Security Goals:

• Purchase Orders – The purchase made by a visitor/customer must be accurate when it is received by the merchant company.
• Consumer Identities – Identifying information, such as credit card numbers, should not.
• Merchant Identities – It should be possible for a consumer to know for sure that they are buying from a particular merchant.  In other words, it should not be possible for an adversary to pretend to be a Macy’s ad.

Potential Adversaries or Threats

• Eavesdroppers – It could be possible to collect customer information by sniffing packets
• Copy Cats –  By replacing ShopAds widgets with a malicious flash ad, one could pretend to be a company that they are not.
• Modifiers – By modifying the information being exchanged, it may be possible to alter the purchase order itself (such as the quantity of certain items) or change where it is being shipped to.

Potential Weaknesses

• HTTP Pages – Pages using HTTP cannot guarantee the origin of the content displayed on the page, including the ShopAds widget, and would be vulnerable to man-in-the-middle attacks.  Additionally, information is sent over plaintext.
• HTTPS Pages – Even on an HTTPS page, you would have to trust the hosting (publishing) website you were visiting.  HTTPS only verifies that the site is who they say they are. So, visiting https://www.evil.com and conducting a business transaction through one of their evil ads is still dangerous.
• ShopAds Widget – If the widget does not take advantage of  the features in flash to establish secure connections, information may be sent over plaintext.

Potential Defenses

• HTTPS Pages – HTTPS pages can at least guarantee that the page is who they say they are and that the data is not sent over plaintext.  If a customer trusts the hosting/publishing site, and they trust the company who owns the ad, they could trust the transaction.  However, this would require every page with a ShopAds widget to use HTTPS…
• Flash Security – Make sure to take advantage of features to establish secure connections to prevent transaction information from being transmitted in plaintext, even if the widget is properly placed on a trusted HTTP page that has not been maliciously modified.
• Ad/Merchant Verification – Having the potential for a consumer to verify that the ad belongs to a particular consumer would help guarantee online shoppers do not buy from copy-cats.  Ideally, this would be done in the widget as well so as to keep to the nature of this new technology.

The largest problem here is that consumers may have no idea about the threats posed by these types of ads.  Many customers may not even know why HTTPS is important, let alone how it affects the security of shopping through an ad. Furthermore, it is unlikely that every page that will be sporting the ShopAds widgets will start using HTTPS, so shoppers will learn to have trust in these very dangerous situations. Even if the publishing site can be trusted, if the widget is not on an HTTPS page, it cannot be trusted.

If the ShopAds widget is to become the next best thing in advertisement and online shopping, these security concerns will have to be addressed.  In the same way that an online banker would not (hopefully!) enter their bank account number and password on an insecure page, neither should an online shopper provide their credit card or other identifying information.  It will also be necessary for shoppers to be more aware of where and how they are making purchases.  To help out visitors to the site, some of the responsibility may rest with the publishing website to make sure the ads they are providing do not compromise the identities of its visitors.  If this does catch on, it may become necessary in the future for browsers to be able to verify the origin of chunks of content, such as the ShopAds widget, to guarantee the security of its users.

In Current Event: WarCloning Passport RFID Tags, The recent experiment was introduced, which was done by researcher Chris Paget. According to the article, Paget could scan passport RFID tags. During a recent 20-minute drive in downtown San Francisco, it successfully copied the RFID tags of two passport cards without the knowledge of their owners.

The RFID tags contain no personally identifiable information, but rather what amounts to a record pointer to a secure Department of Homeland Security database. But because the pointer is a unique number, the American Civil Liberties Union and other civil libertarians warn the cards are still susceptible to abuse, especially if their RFID tags can be read. The tags could also be correlated to other signals, such as electronic toll-booth payment systems or RFID-based credit cards, to track the detailed movements of their holders.
(Read on …)

As I found on Slashdot, a controversial piece of legislation is being considered that would allow for the collection of DNA from arrested persons. The DNA may be collected prior to the arrested person being charged with a crime, and the arrest can be for crimes as minor as shoplifting. The DNA would be sent to State Patrol and FBI databases, where it would be compared against DNA collected in unsolved crimes. If the person who was arrested is not charged, is not convicted, or has her conviction overthrown, her DNA would be destroyed.

(Read on …)

As an undergraduate student in the computer science department, there are a number of computing resources available for use. A number of these resources are through the web browser, and have private, personal information associated with them (for instance, MyCSE).

Experimental Attack

Since we were recently doing XSS attacks in our lab, I decided to experiment with them in a more real setting by sending a fake email to the cse484 mailing list, to see how many students/TAs clicked:

Hey, I’m trying to set up my web server for lab 2, but I think I’m having DNS issues with the subdomain I set up not propagating. Can anyone check this page (http://security.30tonpress.com) and see if they get an OK page?

Thanks,
David

That URL then loaded a fake DNS success page, as well as version 1 of my Yoshoo exploit in a small FRAME at the bottom of the page. Surprisingly, 19 people in the class clicked the phish link. Since class mailing lists are generally not thought of as being adversarial places, students are much more likely to click links that are posted to it — especially if there’s a halfway-decent cover story to back. This makes an adversary’s life much easier.

There are a number of reasons that someone might try to exploit XSS attacks on CSE resources. For example, malicious students that want to cause havoc and chaos for others in their class by modifying what they have turned in. Or, someone might want to gain access to all the personal information that the CSE department has on another student.

Weakness #1 – Yoshoo Lab 2

The first attack is on Lab 2 for CSE484, which involves using any captured Yoshoo authtokens to change a student’s grades back to zeroes for part 1-5. This will cause them to lose points on the lab come grading time, lowering the average score on the lab, and boosting the attacker’s score with respect to the grading curve.

An stolen authtoken can be used to log into someone’s y.um.my account, and upload new phishing URLs. These URLs could then be used to grab authtokens for part 1-5 of the grades DB. An adversary could then easily change the grades with these tokens using the same steps they did for their own project.

Weakness #2 – CSENetIDs

When accessing a protected resource on any *.cs.washington.edu, the CSENetID service is used to authenticate users in the browser. A cookie is then saved on that user’s computer under the domain: *.cs.washington.edu, with the key: csenetid_l. This puts an implicit trust on all subdomains under the cs.washington.edu domain. This means that any malicious phishing page that runs on a subdomain of cs.washington.edu that is set up to capture document.cookie from the browser will pick up the CSENetID token of any user who has recently logged in.

Once an attacker has that token, they can spoof your session. If the CSENetID auth service does any additional IP validation of the machine, the IP of the phished user can be spoofed in order to fool the web server into granting access to the attacker.

Potential Defenses

There are defenses against these attacks that can be implemented on both the server-side and the client-side.

On the server-side, any site that wants to use CSENetID authorization could explicitly talk to an authorization server within their web applications’ code (given a standard module for use with different languages like PHP, Python, etc). This could then set an authtoken cookie only on the CSE subdomain that needs authorization. However, this has two downsides. One is that every subdomain would require a user to log in again. Another is that if the module is not well-designed, some of the burden of providing a high-level of security might be shifted to each individual web application, as opposed to one central module.

On the client-side, there are a number of extensions to Firefox that can make browsing safer. One is NoScript, which only lets JavaScript, Java, and Flash execute on sites you explicitly trust. This way, you can check out a link before deciding to let it run arbitrary code. As well, Google provides a Firefox plugin based on data they have gathered about various phishing sites, that will alert a user when they are about to visit a known XSS site.