Archive for April, 2011
Vuze Security Audit (Group 1)
Saturday, April 23rd, 2011WordPress Security Audit – Group 3
Tuesday, April 19th, 2011Course schedule is updated
Wednesday, April 6th, 2011With reading for tomorrow on honeynets and next Tueday on Stuxnet.
Group 2 – CVE-2006-0105
Wednesday, April 6th, 2011Perspectives on Race Conditions
Wednesday, April 6th, 2011Today looking into one CVE I bumped into this nice description about perspectives on single core vice multi core race conditions and using existing frameworks to accomplish the task. Sebastian Krahmer who has come up with a POC code for CVE-2011-0727 where he describes using cpu cores to simplify the race condition. Mr. Krahmer proves his description of his previous race condition using pppd and how there is some tuning involved with different cpu speeds. This race wins by beating the scheduler on a single core system. Now looking at the POC code for multi core systems I am left wondering what other exploits that can be simplified that are not currently known where the multi core systems makes this a trivial task.
Group 1 CVE-2009-4484
Monday, April 4th, 2011XSS on a Page Rank 5 Site
Sunday, April 3rd, 2011So I was visiting a website that I frequent pretty often to download recordings (non-copyright, legal fyi) and check the latest posts on the forum (link not included for security). Then recently, I searched for a recording and noticed that the search entry was displayed on the page:
Well, are you thinking what I’m thinking?
I decided to enter a :
<script> alert(“H@CKED”) </script>
and sure enough
This page rank 5 website was indeed vulnerable to cross site scripting.
To test what inputs could be put in I decided to see if standard html would display correctly, perhaps a paypal buy now button?
And to get rid of the ” in Track’s Title…”, one could just put in a <!– to comment it out:
What’s even worse is that the search entry is made via a GET in the URL.
Now this is a big problem. An attacker just needs to craft a URL and get some one to click on to potentially:
- Convince them that they can donate to the website, when they are really donating to the attacker
- Steal account login via javascript, which is a particular problem given that the forum has over 8000 users
The best way to deal with this problem would be to sanitize inputs or display them as text, escaping from the html
In order to deal with this ethically, the administrator of the website will be contacted and informed. A public
announcement will be made 30 days after informing the administrator if no change is made.