UW CSE Resources

By ezwelty at 4:42 pm on February 5, 2009 | 2 Comments

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.

Conclusions

Even in the context of a security-focused class of students, there were still a good portion of students that clicked my phishing link. For this reason, it is extremely important for clients of web applications to install plugins that can enable them to spot phishing attacks and respond to them. As well, there is a obligation to anyone running a server-side application to sanitize any XSS vectors, and remove the amount of data that is exposed via cookies.

Filed under: Ethics,Privacy,Security Reviews2 Comments »

2 Comments

  • 1
    Get your own gravatar for comments by visiting gravatar.com

    Comment by liaowt

    February 5, 2009 @ 8:26 pm

    If the malicious website is from the trustful resource such as class email, we will mostly click it. This is one type of internal security threat. In fact, I clicked that website.
    When I was doing lab2, I can access my authtokens.txt through http://www.abstract.cs.washington.edu/~CSEnetID/authtokens.txt. This was due to misconfiguration. I made the authtokens.txt to be read by others too. I think that other people might make the same mistakes. We can access easily get other people’s authtoken by replacing the CSEnetID with the other people’ real id. As mentioned in this post, we can modify other people’s grade.
    Since the authtoken cookies never expired, it will be easier for malicious people to change other people grade once they obtain it. I suggest that there should be expired time for the cookie. Therefore, if people found that their grade was changed form 10 back to 0, they can get a new cookie and try to figure out how malicious people get their authtoken.

  • 2
    Get your own gravatar for comments by visiting gravatar.com

    Pingback by UW Computer Security Research and Course Blog » Smashing abstract: more on Lab 2

    February 6, 2009 @ 11:31 pm

    […] 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 […]

RSS feed for comments on this post