Archive for the 'Web' Category

Protecting Your Cookies

Published on September 29, 2008 in Risk Analysis and Web. 6 Comments

I like to think I’ve got operating system security down pretty well. I know I’m not as good with network security, but I try just as hard. When I got into web security this summer, I took a hard look at how I could improve the security of my web browser and it’s only taken me 4 months to realize that it’s probably a pointless endeavor.

This is what my desktop looked like up until yesterday:

That’s 4 different web browsers and 7 different Prism Single-Site-Browsers (SSBs). That’s right, I sucked it up and used SSBs for a whole 4 months after I wrote a post denouncing them because they seemed like the only good option I had. Oh, and every SSB had NoScript installed on it.

The purpose for all this was to keep my cookies isolated from eachother and divide my browsing habits into different domains, so if I got caught in an attack on… say, this weblog, there would be no way an attacker could also walk away with my Google auth tokens. Google obviously means a lot to me, so I decided I need to keep all of their services completely isolated from everything else, hence the SSBs. I also cleared the data stored in each browser on a regular basis to minimize the information stored by them at any given time.
Continue reading ‘Protecting Your Cookies’

Fall Penetration Testing and Exploit-Dev course

Published on August 24, 2008 in Exploits, Meta, Reverse Engineering, Social Engineering, Targeted Attacks and Web. 6 Comments

This year’s Penetration Testing and Exploit Development course (Fall 2008) will contain completely rewritten course material, guest lectures from leading security professionals, and free access to commercial tools provided by Fortify Software and Matta (thank you!). Additionally, the class will be held on-campus rather than online as it has been.

The instructor for the course is Nasir Memon with TA’s Dan Guido (me) and Vikram Padman. The syllabus has been finalized and the guest professors as well as their respective topics are as follows:

  • December 4th — FINAL PROJECTS
  • December 11th — hack the planet/show off projects

Students will have to complete one homework assignment every two weeks, a take-home midterm, and do a final project of their choosing. Each two week session will contain one full session of Q&A to review the homework associated with it. Extra credit will be given for participating in CSAW and UCSB iCTF.

Any questions about the course can be e-mailed to me at dguido@gmail.com.

EDIT: The course will be held in room RH227

PHP strip_tags not a complete protection against XSS

Published on August 16, 2008 in Meta and Web. 3 Comments

On August 13th .mario, a high-profile member of the sla.ckers.org forum, alerted me to a XSS issue on the CSAW registration form. I had previously looked through the code and concluded it was safe based on this block of filtering code included at the top of the page:

//don't use this script!
foreach ($_COOKIE as &$cookie) {
  $cookie = trim(strip_tags(@mysqli_real_escape_string($mySQL, $cookie)));
}
foreach ($_POST as &$post) {
  if (is_array($post)) {
    foreach ($post as &$_post) {
      $_post = trim(strip_tags(@mysqli_real_escape_string($mySQL, $_post)));
    }
  }
  else {
    $post = trim(strip_tags(@mysqli_real_escape_string($mySQL, $post)));
  }
}

Additionally, the registration script limits sources of user controllable input by only ever using the POST and COOKIE superglobals.
Continue reading ‘PHP strip_tags not a complete protection against XSS’

Fortify Hacking Challenge

Published on August 15, 2008 in CTF, Conferences, Events and Web. 1 Comment

I also did the Fortify [Web] Hacking Challenge last week. Their challenge was refreshingly different, fun, and relaxing compared to the other web hacking challenges I’ve done. I really enjoyed playing in it even if it only lasted a short time. Here’s the official description of the contest:

The link below will take you to a Web site which contains numerous vulnerabilities but is being defended by the Fortify Real-Time Analyzer (RTA). When you conduct an attack, Fortify RTA will block your efforts and redirect you to a separate page. However, if you conduct a particularly impressive attack, Fortify RTA will redirect you to a different page, with a code word. There are three code words available.

Fortify RTA had a tight lock on that website! I probably came up with a hundred separate attacks against their website, but they were only looking for a very specific 3. Every so often, I’d come up with what I thought was an impressive attack but it wouldn’t give me any points! Here’s one example:

I found an authorization problem when viewing account details that let me enumerate the database for and grab the account details of every client in the bank. I used Burp Intruder to automate harvesting this data, making over 10,000 requests to the server to gather the info. Then I manipulated client-side parameters on the ‘transfer funds’ page to steal money from other clients and deposit it into my account. This wasn’t an attack they were looking for and didn’t get me any points! Grrr..

I took screenshots of all the actual attacks below.
Continue reading ‘Fortify Hacking Challenge’

ratproxy 1.51 tutorial

Published on July 5, 2008 in Web. 16 Comments

Ratproxy is a [mostly] passive web vulnerability scanner that Michal Zalewski released a few days ago. Set ratproxy to proxy your web browser and go surf! When you’re done, run a shell script and out pops a clear report of all the vulnerabilities ratproxy thinks it saw.

I’ve played around with ratproxy the past few days and used it to find vulnerabilities in some major websites. Here is a short cheatsheet I wrote up, an example report file and what it means, and a quick look into the source code of ratproxy.

Continue reading ‘ratproxy 1.51 tutorial’

Social Engineering final presentations

Published on May 14, 2008 in Academic Papers, Psychology of Security, Social Engineering and Web. 0 Comments

Yesterday marked the end of our first-run Psychology of Security/Social Engineering course here at Poly. Every student made a presentation that described the research project they designed and attempted to run during the semester. I’ll upload the presentations as I get them so check this page often :-) .

  1. The Effectiveness of Security Training / Graphical Indicators of Security
    Joint project by Dan Guido and Boris Kochergin
  2. Personalized Phishing
    Joint project by Brad Schonhorst and Jonathan Voris

I’ve made an executive decision. The mailing list that we used for the course will now be opened to the public for discussion of Social Engineering / Psychology of Security issues. I placed a link on the sidebar of this blog, please sign up if you’re interested!

Update to Single-Site-Browsers (SSBs)

Published on April 28, 2008 in Psychology of Security, Risk Analysis, Security Engineering, Security Industry, Social Engineering and Web. 3 Comments

I spent a lot more time thinking about SSBs over the last week or so and I’d like to use this blog to do a bit of a brain dump. A few days ago, Andrew Jaquith publicly posted the presentation that was sent me to privately. Here are links to his blog and to his presentation.

His presentation makes a number of claims about the security benefits of SSBs. It lists protection against phishing, CSRF, some types of XSS (likely all non-persistent varieties), and domain whitelisting as a future improvement to harden those protections.

I don’t think [current] SSBs completely provide those security benefits unless you do two things:

  1. You block non-SSBs from accessing your website (blocking on user agent string would be enough)
  2. You train users that an SSB is the only acceptable place to enter their password

Without those two requirements satisfied, it is my opinion that SSBs give little security benefit.

If you still allow non-SSBs to access citibank.com, then when a user clicks an XSS’d link to citibank.com, the citibank.com page will still load, and they will still be XSS’d. Similarly, CSRF continues to function as it is likely that the ’session cookie isolation’ benefit of SSBs are negated by the user likely having duplicate cookies in both their SSB and in Firefox (you must ensure the user never logs into citibank.com with their normal browser and obtain a session cookie there, hence the first requirement).

In order for the phishing protection to be effective, users must be aware that they are only supposed to encounter Citibank content in their SSB and not in their normal browser. For instance, if an SSB user encounters a Citibank phishing website in Firefox, will they close their browser and open their SSB instead? It might be the case that users will behave in this way, but I haven’t seen any verifiable proof either way.

[This hasn't been reported on ISIS Blogs yet, but next week marks the end of our first run of "The Psychology of Security/Social Engineering", a first-run research course here at Poly. I'm writing up a research proposal to test the above hypothesis with a group of students in the Fall.]

Lastly, if a bank starts deploying SSBs to their customers, I see this as a first step towards successfully forcing client-side requirements on users where the end-game is fully trusted computing and the open commercial web starts to disappear. This actually goes back to our “Refusing Insecure Customers” debate. It’s an evolution of the same (bad, according to readers) idea.

So, although I see where SSBs have some use and can positively affect your web security, let’s not kid ourselves, they don’t solve that much. To really be effective, they require major changes in the way you do business and [still] rely on an intelligent user. Rather, they look like avoidance of the base problem and an idealistic patch that isn’t going to work.

Oddly enough, I have been using a set of 4 Prism SSBs for the last 2 weeks and have actually grown fond of them, but not for security reasons at all. I like how they show up in my dock, that they rarely crash, and it seems natural to give such webapps “first-class” status as desktop applications. I’ll probably continue using them, but I don’t think I’ve gained any security from doing so.

That said, I think part of the problem here is that SSBs haven’t fully matured yet. I just heard about these things 2 weeks ago and I haven’t heard anyone else in the security community talking about them besides Andrew. They are a topic that deserves more attention and particularly more research from the security community as they embody a lot of attractive ideas. Despite my harsh words, I’m not ready to give up on them yet.

Let’s brainstorm: how could SSBs be more useful to security? Could we change the way they work or change how they are deployed to give us additional benefits? If you’re an InfoSec student with no good topic to research, this is without a doubt a good avenue to explore.

We promise we won’t store your password

Published on March 30, 2008 in Privacy, Psychology of Security, Social Engineering and Web. 3 Comments

This is a short rant prompted by another student’s observation that Yelp actually asks for your Gmail password as part of their signup process…

Have you encountered a website that asks for the username and password to your e-mail provider? I’m talking about this:

Facebook asking for my Gmail password
Continue reading ‘We promise we won’t store your password’

Single Site Browsers

Published on March 13, 2008 in Academic Papers, Psychology of Security and Web. 2 Comments

Single Site Browsers [to be uploaded later]

It’s an interesting idea and I can’t disagree with the concept (<3 <3 separation of privilege) but I think it’s missing a few things. Here are some observations I made about it.

  1. They acknowledge that SSB’s do nothing against malware.
  2. It solves the problem of webpages bringing in resources from all over pretty nicely. Since the organization pushing the SSB knows whats on their own website they can easily publish a whitelist of allowed domains/content or even change their own site to be simpler in that regard.
  3. I think this might come down to a social problem. If I’ve got one general purpose browser I use every day (IE, Firefox, Safari) and I have it open right now, what is going to convince me to close my browser and open a new app just to get to a website that I already have bookmarked? There needs to be some incentive besides security tied into the SSB to get people to perform the above action or companies need to disable functionality on their public websites.
  4. I think the SSB idea is really just a crutch because people can’t implement robust security policies in a browser. Think “IE Zones” on steroids or even GreenBorder (wow when did they get bought out???).

Still, it’s kind of cool.

Refusing Business from Insecure Customers

Published on March 12, 2008 in Legal, Psychology of Security, Social Engineering and Web. 2 Comments

Late last year in an article titled “In Zombies We Trust,” Dan Geer suggested that there are two types of users — those who blindly say yes to everything and are probably infected with a dozen viruses and those who say no to most everything and likely escape most virus problems — and that it could be a legitimate practice for websites to further scrutinize the actions of those who always say yes to prevent them from getting into trouble while using their site. The premise is that these virus-infected users end up costing the businesses they frequent a significant amount of money by being such persistent problems.

A member of our lab (I’ll leave it to him to take credit for this idea) suggested last week that maybe this should be taken a step further. If I know that one customer of mine is more likely to be infected with a virus (or has a higher susceptibility to phishing, pick your threat) now or in the future, is it reasonable for me to completely deny him my business?

This can be easily tested using either Dan Geer’s test or by sending my customers random phishing messages for my own business (there’s even a phishing appliance to do it for you!). Ie., Paypal sends you a phishing email for themselves (sent from another domain, self-signed certificate, graphics copied incorrectly, differently formatted e-mail, whatever) and if you fall for it, they calculate your future profitability and weigh it against the costs you’ll incur if you actually do get phished in the future. If you’ve got a negative balance after this calculation, your account will be canceled and PayPal will have saved money.

The observation was also made that this is standard practice in other industries. Insurance and, regrettably, healthcare come to mind. Would this be a bad thing for web services?

How do you protect yourself online?

View Results

Loading ... Loading ...

Reverse Engineering a PHP “Virus”

Published on February 23, 2008 in Code, Forensics, Reverse Engineering, Targeted Attacks and Web. 9 Comments

In a recent incident a school server (not an ISIS server) was compromised. PHP code was injected that listened to and executed commands passed through a POST request with ‘www’ user privileges. Some of the commands that were run include id, pwd as well as directory searches and wgets of various files. The compromised machine also served as a hop in a pharmacy ad delivery scheme. It redirected HTTP requests for medications to a possible ‘mothership’ server. There is evidence that links to our server were posted as ads on websites like MySpace.

sample_ads

Continue reading ‘Reverse Engineering a PHP “Virus”’

Top 10 Web Hacks of 2007

Published on January 31, 2008 in Web. 0 Comments

Jeremiah Grossman has posted his Top 10 Web Hacks of 2007 to his blog. It collects the state of the art in one short, simple blog post. Highly suggested reading if you’re into webapp-sec.