Ethical Hacking and Penetration Testing

Discussion on ethical hacking and penetration testing subjects.

InfoSec Institute's most popular information security and hacking training goes in-depth into the techniques used by malicious, black hat hackers with attention getting lectures and hands-on lab exercises . While these hacking skills can be used for malicious purposes, this class teaches you how to use the same hacking techniques to perform a white-hat, ethical hack, on your organization. You leave with the ability to quantitatively assess and measure threats to information assets; and discover where your organization is most vulnerable to hacking in this network security training course.

Some of the instructor-led hands-on hacking lab exercises in this security training experience:

* Capture the Flag hacking exercises every night
* Abusing DNS for host identification
* Leaking system information from Unix and Windows
* Stealthy Recon
* Unix, Windows and Cisco password cracking
* Remote buffer overflow exploit lab I - Smashing the Stack
* Remote buffer overflow exploit lab II - Integer Overflows
* Remote heap overflow exploit lab III - Beyond the Stack
* Desktop exploitation
* Remote keylogging
* Data mining authentication information from clear-text protocols
* Remote sniffing
* Breaking wireless security
* Malicious event log editing
* Transferring files through firewalls
* Hacking into Cisco routers
* Harvesting web application data
* Data retrieval with SQL Injection Hacking
* Calculating the Return on Investment (ROI) for an ethical hack


Click here to learn more about the most hands-on Ethical Hacking course ever!

Thursday, February 17, 2005

Secret Service hacker, how did he do it?

Nick Jacobsen pleaded guilty today to hacking into T-Mobile, specifically for violating 18 U.S.C. § 1030(a)(2)(C), accessing a computer without authorization. It looks like Nick was part of the carding community that has been recently attracting a lot of attention from the US Secret Service (little known, but the Secret Service have jurisdiction over counterfeiting crimes). Carders have gotten bold in the last couple of years, opening online exchanges (muzzfuzz.com, shadowcrew.org) for trading stolen credit cards, selling data used for identity theft, etc. When I first heard of this incident a few months ago, I was very interested on how he actually did it. There was very little information on how the attack was performed, and I decided to a little bit of research to see what I could find.

A summarization of affidavit, is that Nick was already under investigation by the Secret Service, hacked into T-Mobile, where was able to access accounts including those of agents in the Secret Service that were investigating him for other activities. He found that they had been monitoring his conversations over ICQ, (Nick's ICQ # was 23292256). Nick also discovered a number of Secret Service documents that an Agent, Peter Cavicchia, had left in his inbox unencrypted. Nick posted on muzzfuzz that he was selling T-Mobile account information, offering:

reverse lookup of information for a tmobile cell phone, by phone number at the very least, you get name, ssn, and DOB at the upper end of the information returned, you get web username/password, voicemail password, secret question/answer, sim#, IMEI#, and more.

Also of interest, he went on to access Paris Hilton's account and capture some of the pictures she had been taking with her camera. Now, here is where it gets interesting. How did Nick get into T-Mobile? Did he use an IIS exploit? Did he hack the web interface for T-Mobile accounts?

The affidavit from Nick's case states that he was observed logging into a specific server, http://login.sidekick.dngr.com, with Agent Peter Cavicchi's account information. While this site itself is hosted by Danger, Inc., the makers of the Sidekick device used by Agent Cavicchi, it appears that the same username/passwords that are used on the primary T-Mobile login page, https://my.t-mobile.com/Login, can also be used to log into this page. We also get some very valuable information from the affidavit, that will help us narrow down how Nick hacked these accounts (the CI is a Confidential Information, who was working with the Secret Service to bring Nick in, ethics is the semi-ironic pseudonym Nick chose for himself):

On or about October 19, 2004, Ethics sent a private message to the CI which contained a link that provides unauthorized access to the T-Mobile database. This link allows a user to input a phone number ultimately allowing access to the user’s personal information.

This information leads me to believe it was likely a web application attack, not a "traditional" buffer overflow attack against a server storing account information. Although it is possible to peform a buffer overflow against a program by passing input through a web app, we can also read Nick's resume on SecurityFocus, and see that he doesn't seem to have enough experience in that area. Unless he picked up a copy of The Shellcoder's Handbook last year. ;)

To further corraborate that Nick used a web application hack, most likely SQL Injection (a little research shows that the T-Mobile site uses IIS/ASP/SQL Server, which happens to be the easiest and most well documented platform for SQL Injection attacks), we can check out the website and try to put some invalid input into the T-Mobile login page. I was very surprised with the results, we can still put all sorts of crazy input into the login page! It is still vulnerable, even after one of the largest, most well known, and high profile hacks in the last couple of years! Let's try some (notice the error text on the resulting T-Mobile webpage):

https://my.t-mobile.com/Login/?rc=I%20like%20to%20eat%20cheese

Result:



https://my.t-mobile.com/Login/?rc=T-Mobile%20is%20not%20very%20secure,%20please%20use%20Nextel%20instead!

Result:



While this is a very, very lame bug, it could be used in a phishing attack on T-Mobile customers, especially if you hex encoded portions of the URL. We also find a little more serious bug here, we can inject script tags as well, which could possibly be exploitable and used to steal cookies and therefore circumvent authentication. The resulting HTTP 500 error lets us know that something is wrong with the site, causing a server error. (I have not taken the attack any further, and I would not recommend that you do so either):

http://my.t-mobile.com/Login/?rc=~script~alert('vulnerable')~script~

In order for this demo to work, you must replace the four ~ with a <>.

Result:



We can also find literally hundreds of injection vulnerabilties littered throughout the T-Mobile website. They seemed to have cleansed out all of the obvious injection holes accessible via browser input, but if you use a simple web proxy (I like Paros, we use it in both Ethical Hacking classes at InfoSec), you can find them by the hundreds on just about every dynamic page on the website! Here is one (once again, do not attempt to exploit this):

http://support.t-mobile.com/plan.html?treeName=plans&path='

Result:



Based on the affidavit, plus the fact that T-Mobile remains highly vulnerable to all sorts of web input attacks, I would say it is highly likely that Nick used some sort of web application bug to circumvent authentication.

~Jack
jack (at) infosecinstitute (dot) com

24 Comments:

  • At 3:45 PM, morning_wood said…

    sql injection... nope
    flaw was in third party web plugin.., plublic info is avail on the vector.

    nuff sed,

    morning_wood

     
  • At 1:23 PM, Anonymous said…

    And Microsoft was recently claiming that their software was sooooo secure. lol.

    http://uptime.netcraft.com/up/graph/?host=www.voicestream.com

     
  • At 1:30 PM, Anonymous said…

    Could you please elaborate on the NumberFormatException? I can't see the vulnerability there.

     
  • At 1:48 PM, DamienG said…

    First of all SQL Injection happens on any database where the developers are building dynamic SQL statements without proper encoding, it is NOT any more exploitable on SQL Server and ASP than MySql and PHP or any other DB + script language technology.

    While you can display various error messages and fake error text the fact that when you tried to HTML inject it showed an error page shows that HTML injection is NOT possible - at least on the page you demonstrated.

     
  • At 2:06 PM, Anonymous said…

    Nice analysis. BTW, CI stands for "Confidential Informant". Also, how does ASP figure into this? The stack trace displayed is from Caucho's Resin Java-based servlet container.

     
  • At 2:30 PM, Hagen said…

    t-mobile is not the only company in the T-Com-family that has problems with insecure webfrontends. The T-Hack (german) for example is a report about multiple security holes in the T-Com OBSOC system. Due to these holes a unauthorized person could gain access to nearly every information on these systems (account information, payment information...). Obviously many applications used by this company are not trust worthy at all.

     
  • At 2:43 PM, TaylorTAP said…

    Nice article... Would you like to cross link eachother??? http://taylortap.com.

     
  • At 3:07 PM, Stasyna said…

    now where's those photos

     
  • At 3:18 PM, Anonymous said…

    intresting stuff.

     
  • At 4:16 PM, deadlyh said…

    thanks for the information

     
  • At 4:23 PM, Anonymous said…

    uhhh right get your facts straight. tmobile is running ASP? Is that way there was a JAVA SERVLET EXCEPTION?!! Have you ever programmed before? Why would you save an error msg into a database? NO INJECTION PROBLEM THERE. Good job blowing smoke. Enjoy your 15 min of fame from the slashdot crowd.

     
  • At 5:23 PM, Jack Koziol said…

    I guess my previous blog post yesterday concerning T-Mobile was posted to Slashdot. Numerous people have send me email concerning why I chose to term the last vulnerability an "injection flaw". Others have asked for code to exploit the T-Mobile web applications.

    What I am referring to here when I say an "injection flaw" is a generic term for not properly validating input, which may result in an exploitable vulnerability. At the very least the application tells us version information (Resin 2.1.9). This version happens to have some publically know source code disclosure vulnerabilties that can be exploited quite easily. A vulnerability in Resin also allows you to view the contents of the WEB-INF directory (if you aren't a Java programmer, this directory contains configuration files). I found several locations on the dozens T-Moblie websites (which run both Microsoft and Open Source Java components) where input was not validated. If you want to read more about how to protect against such vulnerabilities, I suggest you lookup literature on blacklisting vs. whitelisting.

    The point of the post was to try to determine the methods that Nick Jacobsen used to compromise T-Mobile's accounts last year. In about 3-5 mintues of looking around on the website, it was widely apparent that T-Mobile has chosen not to review for even the most basic and obvious of web application flaws. I remain confident that a comprehensive audit (I do not have authorization from T-Mobile to do such an audit, so I cannot be 100% sure) would result in the discovery of many exploitable vulnerabilties.

     
  • At 9:15 PM, Anonymous said…

    this is a blog, allright? no need to be so formal and tied up, fool!

     
  • At 12:16 AM, Anonymous said…

    The last example was bogus. The support.t-mobile.com site was obviosly running on a servet container, Resin, NOT IIS. And if you look at the stack trace, it's clear to see that the programmer was actually converting the parameter to an integer, which threw an exception. So there was no danger of an SQL injection attack.

     
  • At 7:05 AM, Anonymous said…

    The last example was bogus. The support.t-mobile.com site was obviosly running on a servet container, Resin, NOT IIS. And if you look at the stack trace, it's clear to see that the programmer was actually converting the parameter to an integer, which threw an exception. So there was no danger of an SQL injection attack.
    ----------------------------------
    Re:
    If you want to get all nit-picky, yeah maybe at this part of the application you couldn't directly inject variables, but looking at the exceptions thrown out (eg its looking for an integer) could help you start mapping out the db schema.

    Either way T-Mobile is not acting as responsible as they should and it seems they aren't even trying to follow the most basic web app security practices.

     
  • At 4:50 PM, Anonymous said…

    yip which was the entire point of the post. t-mobile after they was hacked have still not done anything about there security.

    look after how long?

    https://my.t-mobile.com/Login/?rc=T-Mobile%20is%20not%20very%20secure,%20please%20use%20Nextel%20instead

    they still havent done anything. i wonder if they even view there hits log.

     
  • At 4:32 AM, Keydet89 said…

    There is a Yahoo Group called "CISSPForum"...not a lot of great information, but a bit ago, there were two people posting to the group who claimed to work for TMobile. One of them stated that the system that was compromised was known to be vulnerable, as the result of an audit, but a business decision had been made to not pursue fixing it. There wasn't a great deal of information beyond that, however.

    Having held FTE positions, I have seen things like this...where disabling script mappings in IIS are considered "too expensive" (ie, only 'costs' a batch file and a couple of seconds...).

     
  • At 7:33 AM, TripleThree333 said…

    It looks like T-Mobile has changed their code. I tried the above technique and the "token" has been removed from the first site. I never set up a "secret" question so there was not even an option to reset my password so getting to a token wasn't even a possibility (looks like the safest way to protect your privacy is not to set up a way to recover it, you can always use the tool that texts your pass to your phone).

    It also looked like they fixed the other problems with their code. The media is still publishing that T-Mobile is full of security holes, I don't know enough about it to tell if their site is still vulnerable to easy hacks.

     
  • At 11:55 PM, Anonymous said…

    check to see if their international sites still have this flaw.
    http://www.t-mobile.co.uk/ or https://my.t-mobile.co.uk/Login/?rc=T-Mobile%20is%20not%20very%20secure,%20please%20use%20Nextel%20instead

     
  • At 11:48 AM, CITSF said…

    Now you're getting to it. Most opportunities for an exploit are the result of a flawed business practice regarding security governance. I am convinced of this. Fixing technical flaws is required, but it is just a function of a much broader issue: Security Business Process.

    I harp on this daily at my blog http://www.citsf.com. Thanks for playing.

     
  • At 5:09 AM, Anonymous said…

    First off, let it be known,, T-mobile had this coming. It was over 2 years ago, i found an exploit in T-mobile/Deutch telecom's sidekick's webpage. I was battling demon's, to decide wether or not to shine light on this exploit. After month's of fighting demon's :), I decided to contact T-mobile about this, which i called and spoke to the manager's of the Customer relations and the Customer care dept's. Both of which blew me off. When i called the Customer relations dept, a guy with a deep burly voice answered. I told him what was up with the sidekick page, and he kept assuring me it was safe. Hehe, I told him how can it be safe, if i just hacked it. And then i told him, my next step is going public with this, which he said good luck and hung up on me. :| As you can imagine i was PISSED. I was literally trying to help them, and this "dick" hang's up on me. IF ANYONE AT T-MOBILE KNOWS THE MANAGER(WHICH HAS A SUPER DEEP VOICE) OF THE CUSTOMER RELATIONS DEPT,,,, FIRE HIM! I went to the Washington Post about this, which they never contacted me, Oh well. I did my good deed for the day. Anyway, as a security analyst i cant emphasize the importance of writing clean code. Just because they slipped
    up, and left a token value, somewhere where they shouldnt have,, I and a couple hundred people by now owned T-mobile. They say knowlege is power,, If that's the case, then i owned ALL of T-mobile's 3 MILLION customers worldwide. I will NEVER do business with T-mobile, and it's amazing how they have kept this out of the spotlight, "scary actually".
    Ps. T-mobile has partnered with the CIA, haha does this mean i own CIA also? Anyhoo, i will continue to audit the security of webhost's, in the name of GOOD. I believe we all need to tighten up security, in real life as well as online.

    PPS. Did i mention there is a spoofing exploit on this webpage? :)

    "Junk"

     
  • At 5:09 AM, Anonymous said…

    First off, let it be known,, T-mobile had this coming. It was over 2 years ago, i found an exploit in T-mobile/Deutch telecom's sidekick's webpage. I was battling demon's, to decide wether or not to shine light on this exploit. After month's of fighting demon's :), I decided to contact T-mobile about this, which i called and spoke to the manager's of the Customer relations and the Customer care dept's. Both of which blew me off. When i called the Customer relations dept, a guy with a deep burly voice answered. I told him what was up with the sidekick page, and he kept assuring me it was safe. Hehe, I told him how can it be safe, if i just hacked it. And then i told him, my next step is going public with this, which he said good luck and hung up on me. :| As you can imagine i was PISSED. I was literally trying to help them, and this "dick" hang's up on me. IF ANYONE AT T-MOBILE KNOWS THE MANAGER(WHICH HAS A SUPER DEEP VOICE) OF THE CUSTOMER RELATIONS DEPT,,,, FIRE HIM! I went to the Washington Post about this, which they never contacted me, Oh well. I did my good deed for the day. Anyway, as a security analyst i cant emphasize the importance of writing clean code. Just because they slipped
    up, and left a token value, somewhere where they shouldnt have,, I and a couple hundred people by now owned T-mobile. They say knowlege is power,, If that's the case, then i owned ALL of T-mobile's 3 MILLION customers worldwide. I will NEVER do business with T-mobile, and it's amazing how they have kept this out of the spotlight, "scary actually".
    Ps. T-mobile has partnered with the CIA, haha does this mean i owned CIA also? Anyhoo, i will continue to audit the security of webhost's, in the name of GOOD. I believe we all need to tighten up security, in real life as well as online.

    PPS. Did i mention there is a spoofing exploit on this webpage?
    Anyone want a demonstration? ;)

    "Tell the world,, Junk was here"

     
  • At 2:29 PM, Anonymous said…

    Waaay back when tmobile was still voicestream, they were running on weblogic.
    They were running on a version of weblogic that also happened to have a vulnerability to viewing directory contents.
    They were also Smart enough to leave a "Stresstest" page in the same directory with superuser login creditials to their watson system, (WATSON is a web-based application that allows you to activate a customer's device.). Ethics found this and was the start of his delving into the tmobile system.

     
  • At 5:50 PM, gatekeeper said…

    are you talkin to me? I'm just a
    little ole women.

     

Post a Comment

<< Home