I’ve been mouthing off about the much anticipated arrival of my new EEE PC, and when it arrived at work for its glorious unboxing, my wonderful co-workers were ready to own me with a samba exploit -locked and loaded. Reference: ASUS Eee PC rooted out of the box

That’s what you get when you work in this industry. I had it coming I suppose. The EEE PC is just too damn cute. How could anybody forcibly overflow its cute tiny little heap! That’s just cold hearted pwnage.

A series of updates were released for the Asus EEE PC today, pdf reader, messenger, firefox, openoffice, the samba daemon of course, and some other tweaks.

Recognize! My EEE PC is patched like a mug now! Leave my lil’ EEE PC alone!

-higB

What is http://port139online.com:139/ ?

• Port139online.com:139/ IS a website
• Port139online.com:139/ IS a protocol
• Port139online.com:139/ IS a service (a service that tells you if your ISP is providing a tampered, filtered, limited, and incomplete service.)

I started port139online.com:139 to annoy the tech support agents at Cox Communications. I subscribed to their business Internet service because the sales rep told me that absolutely NO port filters existed for business customers. I don’t know if the sales rep lied to me on purpose to meet a quota, or if she just didn’t have all the information.

After several phone calls to Cox support, I finally got them to admit which ports they filtered (both inbound and outbound). They offered to reduce my bill by 45 dollars a month, but they would not remove the filters. I’m now a Verizon Business FIOS customer and couldn’t be happier with my pure, unmolested Internet.

Shortly after my Shmoocon presentation, Comcast went before the FCC. An executive vice president for Comcast lied to the FCC commissioner and the rest of the panel, when he said:

“I’m going to say again, on the record in front of this Commission, Comcast does not block any Web site, application, or Web protocol, including peer to peer services. Period. Doesn’t happen.”

Oh really? Well http://port139online.com:139/ IS a website AND an application AND uses a WEB PROTOCOL… and guess what? Comcast IS blocking it.

Read more about it here:

http://arstechnica.com/news.ars/post/20080225-comcast-and-net-neutrality-advocates-clash-at-fcc-hearing.html

And listen to the MP3 here: http://arstechnica.com/news.media/fcchearing25feb08.mp3

Reference: Comcast does block websites, ports, and protocols: http://taosecurity.blogspot.com/2005/07/what-does-your-isp-block-only-low-cost.html

http://www.dslreports.com/forum/remark,15481407

**** NOTE ****

You can only visit http://port139online.com:139/ from Internet Explorer. Firefox blocks many ports.

We might finally have some decent mobile viruses to worry about.

Why is it that McAfee’s VirusScan Mobile is only Windows Mobile 5 and 6? Simply put, it’s because that platform gives the end-user enough rope to hang themselves. Users can grab a .CAB file of the brick breaker game from only god knows where and install it themselves through Activesync.

Surely tech-savy users don’t just install any hackware from untrusted sources right? If you believe that then you haven’t spent much time on http://www.howardforums.com/ or http://www.mobile-files.com/forum/ where every day, technophiles repackage and swap DLLs and other tasty bits from one carrier’s phone to another. Users don’t care about running untrusted code. To them, it’s just an annoying split second while they click away the nag window so they can dive into Justin Timberlake-screensaver-ring-tone wallpaper bliss.

It goes beyond running untrusted code from untrusted sources. Users will replace entire operating systems through unofficial channels:
Windows Mobile 6 for the XV6700: www.downloadsquad.com

If you step outside of your tech circle for a moment you’ll notice that most of your friends and family (you know, the people that will be watching football over Thanksgiving while you’re fixing their computers) don’t have windows mobile, RIM, or palm phones. If they have a typical Verizon phone then they follow a path like this to get applications:
Developers create and sign BREW code, that code is then tested and certified via Qualcomm’s NSTL site: https://www.nstl.com/brew/ . Ultimately the wireless carrier decides on what application they put in their catalog. (Usually after they test it themselves.)

Some see this path as a way to lock the user into the carrier’s applications. Another way to look at is the carrier is certifying that code for your phone. Given that the wrong code can put your handset into a chronic state of reboot permanently ruining the device I can see why carriers like to keep tabs on what users load on the phone.

The masses are crying about an open iPhone API. I’m sure they’ll get the open API, along with everything else that comes with it.
If you look at any of the press surrounding Android, the mantra is clearly openness and convenience. Openness and convenience; security’s best friend? <borat> NOT! </borat>

-higB

“We’ve never been hacked.” Those words are generally what let IT people sleep at night (or take long breaks to go play Guitar Hero). While it gives everyone a nice warm, fuzzy feeling like a lolcat, how would you know that it is true? Cause you haven’t had a customer complain about a strange transaction? Cause the data in your database looks fine? Cause your web server hasn’t crashed recently? Often, it’s because of a strong belief that logs will tell you everything and you don’t see anything crazy in there.

While most companies do spend some time and money on log analysis, a number of web attacks can go completely undetected given common logging architectures and configurations. A very simple example of this would be POST parameters. You can check all the boxes for the IIS logging configuration, but there’s still no way to enable logging of POST parameters without some custom programming. Not logging POST parameters makes sense as they are most often used to send usernames and passwords (something you wouldn’t want sitting as plaintext in your logs); but then any SQl injection attempts to bypass login go undetected. So, some programmers take it upon themselves to add additional logging in the application itself. Items such as writing out when someone logs in, or what data they are viewing or entering. While this is recommended and can often be helpful, it can also lead to a false sense of security. Most often a vulnerability in an application occurs at a point where the developer was unaware of a security risk. Therefore, developers commonly miss logging data at the correct spots, logging the correct parameters, that are used in an attack. In a number of cases, there is often no validation or encoding of data written to these custom logs. Thus it’s rather easy for an attacker to forge entries into the logs or truncate data by appending null characters in their attacks.

Even if you do log everything properly, some attacks don’t have signatures that would stand out. Parameter manipulation attacks often take advantage of subtle changes to the information sent to the webserver.  Changing one account number to another valid account number. Flipping a zero to a one to get admin access. These attacks are going look like normal request to anyone reviewing the logs unless you already know some information about an attack that has occurred.

We have also seen a number of attacks against weak encryption that can go unnoticed for a huge amount of time. This should be painfully obvious now in the wireless world after the TJX attacks. Consider your own wireless network for a moment. Even if you are logging MAC addresses for every connection, how do you know someone is not passively capturing your traffic and decrypting it? Or has sniffed a legitimate user’s MAC address and is impersonating it?

In the web application world, we have seen weak homegrown session “encryption” for persistent logins. This didn’t take millions of sessions ids to crack, but rather just a handful any normal user would be issued. Think you would detect it based on IP addresses in your logs? Fairly unlikely, because your logs probably aren’t saving the session ids. If they are, the number of false positives is so high based on legitimate mobile users, that its often impossible to use that information to realize it’s an attack. Your IPS/IDS often will miss this attack as well since there’s nothing out of the ordinary in the requests or paths through the site.

How about Session Riding attacks? In these cases, we have a legitimately logged in user, coming from their normal IP address and standard web browser. If the attacker has done a proper job, a single Session Riding attack entry in a log file will look exactly like legitimate traffic. You would need to analyze the user’s path through the site to realize something was out of order. Again, in most cases, companies to not have the tools or resources to do this.

So before the next board meeting when someone announces “we’ve never been hacked”, take a few minutes to think about if there’s anyway you could know that is true. In most cases, there should be reasonable doubt to know the jury is out on that myth.

-b3nn

Till a couple of years ago, the input validation wand could be waved to solve almost any application security flaw - XSS, SQL Injection, Response Splitting, and the list goes on. That made it easy to become an application security consultant. If you could chant the “Input Validation” mantra you would be right most of the time. The advent of attacks like cross-site request forgery (which I prefer to call session riding) and session fixation, however, have made it difficult to pull off the input validation bluff.

Let’s talk about Cross Site Request Forgeries (XSRF) for starters. Corey Benninger explained the difference between the often confused XSS and XSRF in a previous blog post. The root cause of XSRF is the predicability of key HTTP requests that result in transactions with signifcant impacts.

E.g. If the HTTP request for transfering funds from one account to another is - http://www.hellobank.com/transfer.aspx?amt=1000&srcacct=1001829&srcaba=021000091&dstacct=9008990&dstaba=012000076

an attacker can lure a victim to visiting a web page, that in the “background” executes such a request to transfer funds from the victim’s bank account to that of the attackers. If the victim is logged in to his/her online bank then this transaction will execute successfully. The systemic issue is the predicability of the HTTP request. The way to thwart such an attack is to introduce a random element in every request to transfer funds, and more importantly verify that the random token has not been tampered with.

Now on to session fixation. The potential impact of exploitation of this vulnerability is often underestimated; for those that feel that this is a “Medium” or “Low” risk issue check out my BlackHat 2006 presentation. The fix for this issue is real simple - invalidate and re-issue user sessions after critical events like login, and  switching from non-SSL to SSL on the website. It’s not input validation though.

I started thinking about this post while teaching my class at Carnegie Mellon University. One of the students came up to me after the web hacking class and asked me “What is the ONE thing I should take away from this session”. I said -  ”If it had to be ONE thing for application security it would still be Input Validation, but hopefully you didn’t just learn ONE thing” 

There was an interesting update yesterday about last month’s story about a Swedish security researcher who released the password and login information for 100+ embassy and government workers.

(I’m going to take some liberties summarizing this)

A Swedish researcher released 100+ passwords claiming he wanted to expose that the practice of using pop3, imap, etc shows a lack of user awareness. This also shows a lack of care and regard from the government institutions that permit inbound plain text authentication.

Some called for the lynching of this “hacker” while others were more curious about how the passwords were obtained. My initial off-the-cuff guess was a web exposure or a password list carelessly left online for google to cache.

How the passwords were really obtained proved to be much more interesting. In a blog posting yesterday, Dan Egerstad, revealed that he has been operating TOR exit nodes and sniffing passwords. I’m absolutely not surprised some people think that using TOR magically fixes all clear text protocols. What did surprise me is that government and embassy workers are using TOR. Are these workers really using TOR? It’s true that Tor is effective at masking the origination IP address from the destination address.

I think the REAL story here is that 100+ accounts have been compromised for months (maybe years) and that the real attackers have been using Tor to mask their origin IP address. Without Dan Egerstad exposing this; hackers, spies, (and who knows) could have gone on accessing these government email accounts unobstructed.

-higB

As a security consultant with exposure to many large enterprises I admit I’m biased to RSA SecurID tokens. During penetration tests, our company has cracked tens of thousands of passwords. When I’m standing in front of a customer explaining why their password policies failed, they want to believe that changing this policy will help them. Secretly I know that humans will defeat the spirit of any password policy and that the best approach is to take the responsibility of password composition away from the end user. (When you stare at thousands of clear text passwords you develop a cynicism.)

August2007, you’ve been a good password, but it’s time I move on to owning enterprises with September2007.

The other day a friend asked me if there are any other products like SecurID he should be evaluating for his company as part of their plan to introduce two-factor authentication. Apart from SecurID the only other device that left me thinking “Hey this thing works” is Vasco’s Digipass. Any two factor system worth its weight in salt should provide authentication hooks to the popular services. If you plan to use the solution with custom web applications, you may need to dig a little deeper…maybe a lot deeper. Most solutions have hook-in APIs, but it takes some effort to piece it all together.

If you are evaluating two factor authentication devices make a list of the top services you need authentication for:

• Network devices
• Windows authentication
• Unix authentication
• VPN users
• Wireless user authentication

If a solution can cover 80% of your authentication needs and is cost effective, go with it. 80% coverage is 80% better than letting humans pick passwords; chances are with a little effort and creativity you can put something together to rein in the residual 20%. If you don’t have a two-factor solution, evaluate Vasco with the others.

-higB

Security conscious developers, world over, look to the OWASP Top Ten as their do’s and dont’s guide. The importance of this list, to the application development and security communities, cannot be exaggerated. Have a look at these impressive statistics from one of Jeff Williams’ recent presentations:

Thus, a Top Ten vulnerability should be one that occurs most commonly and has a high potential impact; something that developers should be made aware of. Based on this premise, session fixation should bull doze into the OWASP Top Ten.  Over 90% of all Java web applications that we have reviewed in the last couple of years have been susceptible to this attack. Combined with a little phishing, this attack can result in users’ accounts on vulnerable websites being hijacked. Let’s take a little detour and understand how this attack most often works.

• The attacker requests the home page of the vulnerable website
• In response the attacker’s browser is provided a jsessionid. Note: No authentication has occurred
• The attacker extracts the jsessionid from the response and constructs a legitimate URL with the jsessionid in it as follows:

https://www.vulnerablesite.com/login.jsp;jsessionid=<insert the extracted token here>

• The attacker then emails this link to a potential victim – a legitimate user of the website
• The victim does not find anything “phishy” with the URL. It actually points to the SSL website; no phony subdomains, suspicious IP addresses, illegible URL encoding, etc.
• The user clicks the link and is presented the login page. What the user doesn’t know is that his or her session is associated to the jsessionid in the clicked URL.
• The jsessionid continues to be associated with the user’s session post-login too.
• Now, the attacker can browse to any restricted page of the website by merely appending the jsessionid in question to the request. The application believes that the attacker is the victim and will readily provide the former access to the victim’s profile- think bank account.

Due to the default behavior of most Java application servers, web applications using the jsessionid for authorization, are often rendered vulnerable. Don’t get me wrong – I am not recommending against the use of jsessionid as an authorization token. I am only calling for the issue to be brought to the fore front by the foremost application security community – OWASP. Especially because it has an easy fix; developers should invalidate the session after critical events like login and re-issue a session ID.

session.invalidate();
session=request.getSession(true);

Also, disable URL re-writing in web.xml.

Some may argue that session management is  included in “A7 – Broken Authentication and Session Management” of the OWASP Top Ten. Yes, it is. However, just like cross site scripting and injection flaws got their own spots and were not clubbed under input validation, session fixation too demands the spotlight.    

-Rohyt 

The Defcon 15 schedule has been posted and I’m glad to have the 7pm time slot on Friday. I’ve presented about automatic outbound covert channels using untraditional hardware in the past but this year my DefCon presentation is for the gear heads.

Short summary: This presentation is about a modern cars ECU and how reflashing it can net you more power. It’s a super ambitious topic to cover in 75 minutes. There are tomes of information about performance tuning theory so it won’t be possible to make everyone an expert in the matter. What I can do is show the tools of the trade, explain some of the basics of tuning and data acquisition, and highlight some of the opensource projects dedicated to the subject. http://www.enginuity.org/ http://www.openecu.org

I’d like to give special thanks to Intrepidus Group for letting me present on the topic and for graciously donating some cool giveaways that will be handed out during the presentation.

-higB

This morning the story that caught my eye was a Slashdot link about CallerID Spoofing to be Made Illegal.

`(1) IN GENERAL- It shall be unlawful for any person within the United States, in connection with any telecommunications service or IP-enabled voice service, to cause any caller identification service to transmit misleading or inaccurate caller identification information, unless such transmission is exempted pursuant to paragraph (3)(B).’

You can read the full text about it here: http://thomas.loc.gov/cgi-bin/bdquery/z?d110:s.00704:

During the last couple years I’ve made use of the Telespoof.com’s caller ID spoofing service during telephonic social engineering engagements. Spoofing caller ID is something a motivated attacker will do to look more legitimate. I’ve also seen an occasion where spoofing the caller ID could fool certain PBX systems into direct access into voice mail boxes.

Do I wish it was technologically impossible to spoof caller ID? You bet I do, it would make avoiding political fund raiser calls much easier. I know better, the bad guys will still spoof caller ID knowing that it will be virtually impossible to get caught. This means my customers who want authentic social engineering phone calls won’t get the total package and won’t know their true risk.

The downside to this law is only the bad guys will be spoofing caller ID. This will also put companies like telespoof.com out of business.
The upside is that it looks like Skype will be legally obliged to transmit caller ID. This is good news for people who have purchased Skype-IN phone numbers and whish it would transmit something other than +000000

More about Skype and caller ID here: http://share.skype.com/sites/en/2007/05/caller_identification_for_skyp.html

-higB