Moving sites! Update your links!

Here is the new site:http://michael-coates.blogspot.com/

Here is the new RSS feed link: http://feeds.feedburner.com/MichaelCoates/security

Overwrite Page Content of Any URL – Passerby Attack

Here’s the trick. You can create false html content under the guise of any URL. This is a pretty limited attack, but interesting in my opinion.

Here’s the basics:

Go to http://www.somepage.com

Go to the URL and type the following

javascript:document.writeln(“<h1>sometext</h1>”);

Observe that the page content switches to “sometext” but the URL remains at http://www.somepage.com

This attack doesn’t change what the user would see if they refresh the page. Nor does it change the content if they browsed to another URL in the future. It only changes the content until the user takes an action (submits a post, follows a link, etc). However, that action could be submitting their logon credentials…

So, why is this important? Well this enables a pretty convincing passerby attack. Imagine a user leaves their computer unlocked and the browser is left open at somebank.com. The attacker comes by and executes the above attack. But instead of entering sometext, the attacker inserts html which creates the bank.com page and changes one small item. The post of the login points to evilsite.com instead of somebank.com.

Now, the user comes back to the machine and remembers they need to check their bank account. The browser is already at the banks website. The URL is correct. The little URL bar is even yellow since the page is https (depending on the browser).

The user enters the username and password, hits submit, and off go the credentials to evilsite.com.

Clearly, it is not hard to add more complex html to create a convincing page.

Should you be concerned? Well, fundamentally this situation is not good. Arbitrary html content while keeping the URL address bar unchanged is a big security risk. But luckily, this attack can only be executed by a user with local access (at least to the best of my knowledge). This attack is a major threat for shared workstations and kiosks. However, most users are the only one using a machine. This is not a threat in that scenario. Now, if it is possible to do this remotely, then we have a huge problem. My tests so far have not been able perform this test remotely.

Here’s a couple screenshot examples

Able to overwrite content of an https site. The nice little lock is still there

Can also read the content of the page, modify it and then return it to the browser.

Before

After

I just changed some text on the page, but I could have changed hidden fields, form elements, or inserted new data.

Just to be clear, this is an attack against the browser and how it handles local javascript calls in the URL. The remote site is never attacked, we simply use the javascript:document.writeln(“blah”) in the url. The browser made the incorrect decision to process the javascript and then replace the URL with the previous entry.

I really have no idea why the browser allows you to execute the javascript:document.writeln without changing the URL to some sort of local document reference. This is the case for both Internet Explorer 7 and Firefox 2.0.0.14

Happy browsing.

-Michael Coates

Hacking Cellular Networks – The Door Is Already Open

A new smart phone hack has been released which is touted to help attackers understand cellular networks and potentially “open the door to hacking the cellular network itself”.

http://www.darkreading.com/document.asp?doc_id=154864&WT.svl=news1_2

Cell networks weren’t built with security in mind, Maynor says. And knowing the frequency of a smart phone means you can also find control channels for the cell towers, Maynor says, many of which carry information such as SMS messages destined to all phones in that cell area, for instance. “It would be the equivalent of turning on a sniffer on a computer for certain types of data,” he says.

The tool itself is interesting, and gathering frequency and channel information is new information that perhaps the cell owner should not have access to. However, the claims that this tool is opening the door to hacking cellular networks is woefully incorrect. That do is already open and doesn’t need a tool like this.  This tool allows an attacker to go after the over the air (ota) portion of the cellular network. From an attackers perspective, this is not the path of least resistance.

So what is the path of least resistance? Its through the data connection of the subscriber itself. Connect up your phone to a laptop, and use the data connection to browse through the infrastructure of the cellular network. All of the wonderful security issues we’ve seen over the years are still present in cellular networks too. The bigger problem is that the subscriber connection is often placed inside the cellular network. So all that stuff about a DMZ and strong perimiter doesn’t usually apply in cellular networks (it shoud, but in practice thats not what’s happening).

Cellular networks should be concerned about security, but not because of this tool. They should be concerned because most every data subscriber has been given direct access into the internal network of the cellular infrastructure. This isn’t theoretical stuff, I’ve tested several major cellular networks throughout the world. These issues are rampant.  The telecom people are getting the message though. They’re moving in the right direction. Hopefully they are moving fast enough.

Take a look at this presenation topic from Hack in the box Dubai 2008.

Real World Attacks Against 3G Networks Using Subscriber Devices

 -Michael Coates

RSS: the next conduit to launch CSRF against MASHUPS

[Substitute "Google" with your favorite mash-up site throughout this article]

RSS feeds are slowly gaining more acceptance among the average Internet user population. Overall, my impression is that the user base is still somewhat small compared to the total Internet user base. Google, and other sites, are offering more convenient methods to access all of your RSS feeds and any other info you need. For Google, consider the Google Reader App and the Google Custom Home Page (portal). Google keeps it simple for the user, sign-in, set everything up and you’re good to go. Everytime you go to your Google Home Page you see your RSS feeds and whatever other widgets you added.

There are a few problems that I’ve noticed here. Who are we trusting to ensure the RSS feeds don’t contain malicious data, such as javascript?

Lets look at who could be the good guy and take responsibility:

• RSS Source: We trust the RSS feed source to restrict input and only deliver safe RSS data.
  -Doubtful. Anyone can serve and RSS feed. Perhaps the bigger feeds want to avoid association with an attack and take some actions. But I doubt the smaller feeds have robust security here.
• RSS reader widget: The actual RSS reader widget was well developed and concerned about its users, so all output is encoded.
  -Not very likely since anyone can build widgets and we know how often security holes are found in quick and dirty code.
• Google: Google (or MASHUP X) wants to protect the user’s account (since the user is logged in) and output encodes everything on the home page.
  -This is possible. Google has a vested interest to take action here. They want to protect the account of their user base. I can see them taking action to protect their users’ cookies and credentials.

I’ve done some preliminary research on the Google home page and found that Google is taking some action to protect their users. What action is that? They are putting the widgets into individual iframes. Aside from that, not too much. Custom widges can fire scripts within their iframe (tested and confirmed) and poorly designed RSS feeds would likely be vulnerable to execute malicious RSS feed data (haven’t tested yet).

Google uses iframes to separate these malicious widgets from accessing the cookie associated with Google. 1 point for google.

However, the attacker knows that a user has to be logged in with the google account to view the homepage. This account is shared with Gmail, Calendar, Reader, and so on. What if the is a CSRF vulnerability in any of these applications? An attacker will place the CSRF attack within the widget or RSS feed and the users will be hit.

More specifically, the CSRF request will be to a google domain page. While the iframe itself does not have access to the google cookies, the browser does. The browser will see the request to page x.google.com and will happily send along the user’s cookie (since they are already logged in to view the google home page). End result, CSRF attack executes to perform whatever bad stuff was possible because of the vulnerability.

In Google’s defense they have taken steps to prevent CSRF and I’m not aware of any outstanding issues on the moment. However, this is just an example. This issue can happen in any mashup environment.

Lots more to say on this topic. Stay tuned for more.

-Michael Coates

Narrow-Minded Security

While passing an electronics store I saw a demo of an electronic surveillance system. I found this to be rather ironic and an accurate reflection of many failed approaches to security. (Hint: look at the right corner of the screen) (Hint #2: Thats the Windows message alerting the user that a firewall is not running)

Other fun firewall notices:

http://www.veracode.com/blog/?p=80

-Michael Coates

OWASP Summer of Code

Want to contribute to the security industry and make a few bucks at the same time? OWASP is hosting the Summer of Code where they provide funding and support to enable the creation of some new security tools, documents and more.

If it sounds interesting then check out the page: http://www.owasp.org/index.php/OWASP_Summer_of_Code_2008

Here is the list of projects they suggest. But, you can submit your own idea too.
http://www.owasp.org/index.php/OWASP_Request_for_Proposal_List

Best of luck

-Michael Coates

OWASP Chicago Meeting this Wednesday.

The Chicago OWASP meeting is this Wednesday (3/5/08) starting at 6pm

Anyone in our area interested in information security is welcome to attend. Our meetings are informal and encourage open discussion of all aspects of application security. We invite attendees to give short presentations about specific topics.

If you have any questions about the Chicago chapter, please send an email to our chapter leaders, Joe Bernik, Cory Scott, or Jason Witty.

The Chicago chapter is sponsored by LaSalle Bank[1]

The info
Where: ABN AMRO Plaza at 540 W. Madison, Downtown Chicago, 23rd floor.
When: 6-8pm
RSVP to jason@wittys.com by Monday 3/3/2008

Agenda
6:00 Refreshments and Networking
6:30 Integrating Security Into the QA Group - Taylor McKinley, Product Manager at Fortify Software
7:10 Web app penetration testing with scripting languages – Mike Tracy, Security Consultant at Matasano Security

–Michael Coates

Distributed Account Lockout Attack

Over the past few days I’ve been pondering an older threat against applications – lockout attacks. The old attack would involve a single user who wanted to lockout another individual or group of individuals by entering multiple unsuccessful passwords. The goal isn’t to guess the password, but to lock the account by sending multiple unsuccessful login attempts. Now, if this user was particularly malicious he could try to enumerate all of the usernames for an online system and then use a script to lock out all of the users. This is a real threat for current online systems. However, once the system owners detected this attack they could respond and block incoming requests from the IP address and likely track down previous activity from that user.

Lets take this idea and add make it a distributed attack originating from a botnet. Instead of a single user attacking multiple user accounts, we now have thousands of individual machines scattered throughout the world attacking a small number of accounts. How would we defend against this sort of attack? Previously a single machine was launching the attack and action could easily be taken against the offending IP address. But now the number of malicious machines increases to the thousands – all locking 10-20 accounts each.

How does this attack compare to a distributed network based denial of service? One key item is the attacker does not have to actually exhaust network resources. A network based denial of service requires a large number of machines for it to be successful. Each machine sends legitimate requests to the site in an attempt to use up all the available bandwidth on the server side. Once the bandwidth from the botnet attack stops clogging the pipe, the attack is over. However, an account lockout attack would cause damage with any number of attacking machines. 1000 machines wouldn’t cause a DDOS against a major online site, but it could lock out 50,000 users without difficulty. Another issue with this attack is simply unlocking the affected accounts won’t solve anything. The attacked site must quickly identify the attacking machines or eliminate their ability to lock out accounts. Otherwise any accounts which are unlocked, will just be locked by the next wave of attacks.

I can see this type of attack being a real threat to the massive social networking sites and possibly financial sites which have not added multi-factor authentication. Given the large botnets that have been forming, I’m almost surprised we haven’t seen this type of attack yet (please correct me if I’m missing some).

Here are some solutions I came up with:

• A captcha of some sort may be a good option. We are seeing this in more financial sites. But for those sites that don’t want a captcha for every login, consider requiring the captcha after 3 failed logins. At this point we should get suspicious and want to confirm that we are dealing with a person and not a bot.
• Incident response should be prepared for this type of attack. Be able to quickly pull metrics showing IP addresses which have a large number of failed logins or have locked out more than 1 account in a small amount of time.
• Along that line, it may be worthwhile to generate an IDS alert whenever a single IP locks more than 1 account in a small window of time. Generating alerts on this behavior could provide information on the beginnings of an attack (instead of hearing from the helpdesk that you just received thousands of password reset phone calls)

-Michael Coates

New Look

I decided to switch up the look a bit. Hopefully the new layout is a little easier on the eyes.

-Michael Coates

Upcoming ChiSec Event

For all of you fellow Security enthusiasts in the Chicago area, there is an upcoming social event.

From the ChiSec Website:

An informal meetup of information security professionals in Chicago. Unlike other meetups, you will not be expected to pay dues, “join up”, or present a zero-day exploit to attend.

The basics
Thursday, February 28, 2008
Houlihan’s on Wacker (in the back)
7pm – about 10pm
RSVP Required? Nope
Membership Required? No

More info here: http://www.sockpuppet.org/chisec/

Hope to see you there.

-Michael Coates