Virgin mobile - Customer service

I was having trouble paying my monthly bill so I call up Virgin customer support. Here's what happens. I'll let the conversation speak for itself.

Virgin Customer Support = VCS

Me: Hey..I cannot seem to pay my monthly charge. Can you help out?
VCS: Sure..what's your phone number.
Me: Gives number
VCS: Thank You. (Does address and other verification)
VCS: Can you give me your mobile Pin? (Mobile pin = password)
Me: Huh? Do you mean my login password?
VCS: Yes correct
Me: Why do you need my login password?
VCS: Because I need to see why you can't pay your bill
Me: Why do you need my "password" for this?
VCS: (Repeats)
Me: (Tries to explain) This is like asking me for my Email password. Would you ask that of anyone?
VCS: (Ignores) If you don't remember your password...I can send it to you?
Me: Huhhhhh !!! .. still... lets play along. Okay..I say
VCS: Sends text message. Password happily on my phone in clear text now :-o
Me: Reads out pin...(still in shock)
VCS: Thank You (so they had it...just wanted to verify. Ah that's fine then. Good grief)
VCS: Okay I am going to check what happened to your payment
VCS: Okay it didn't go through. Lets try it again.
VCS: Can you give me your card number? and expiry date?
Me: Gives details
VCS: Can you also give me your CVV?
Me: Huh !!! (Another WTF moment)
Me: Why do you need my CVV? That's sensitive information.
VCS: Oh never mind..you have saved card info here. Click. Click. Done.
Me: Er..thank you.

Now there are multiple problems here which I quickly list.

-- My pin is in clear text there. Anyone who has access to the records can basically screw me if they wanted to. How much ..is debatable but at the least they can login as me.

-- They use a password as a verification tool. And when the customer doesn't know, hey no problem...we'll send it to you. So if there's a targeted attack..and someone's phone is flicked he's screwed.

-- Asking for CVV. I don't think you need this to complete a transaction. And assuming it is in fact needed, isn't it risky to give someone this on a call? They now have all my card related information and can misuse it anywhere.

-- Lastly..I hope all my card info is not stored in plain text in the DB. I really don't know.

So..while I did end up paying my bill, this experience shook me a little. Thoughts?

Read More

JavaScript application testing - Firebug - Part 2

I wrote about how one can use Firebug over here. Today I'll extend that a little by introducing a few of the features I didn't touch upon last time. There's not too many left as I did the bulk last time, but hey..let's complete stuff :)

So the last time, we talked about setting breakpoints inside Javascript to look at code. We'll do 2 things now..firstly we'll actually set those breakpoints and take an actual application and see how these breakpoints help and secondly we'll introduce DOM breakpoints and see how those can be helpful at times.

So here's a client side application. On logging in as an Admin user we can see the first image and while logging in as a normal user, we can see the second image.

 

The goal here is to try and make those extra links appear for a normal user. Since the purpose of this blog is to just show you what breakpoints can accomplish, I won't dive too deep into how I identified the right place to set the breakpoint. Here I know that the critical place is line 4598.

The application is checking if the current user has a role of 'Edit Articles'. Where is it checking? It's looking into the TM.Gui.CurrentUser.userRoles element. Now how do we know what that contains? Well there's 3 ways. The first way is to look directly at the DOM element in question by navigating to the DOM tab and expanding nodes till you reach that element.

The second way is to do this through the console by typing in the whole path. If that path exists, the values will be displayed. Autocomplete by the way is enabled in the Firebug console...use the arrow keys to complete a word (left/right) or view possibilities (up/down) and hit Enter 2 times when done. If you type the whole thing out you need to hit Enter only once.

The final way is by means of something called a Watch expression. This is something completely new. It was to me too a day or so ago :). Navigate to the Scripts Tab and look at the right pane. Now click on watch and then inside the box which says 'New watch expression' and type in the exact same path you typed in the console. Autocomplete is enabled here as well. You can also right click on any property in the DOM and say 'Add to Watch List'.

NOTE though that the Watch is useful only when a breakpoint is enabled. We'll see why very soon.

Coming back to our example, which we've forgotten completely :).. we want to do something so that those 2 extra links appear for a normal user. Now if you've followed through, you'll know that the normal user does not have the 'EditArticles' role at all. And if she does not have the EditArticles role, she cannot get those 2 extra links. This means that we'll have to somehow edit the DOM and add that role in.


If you look at the Watch tab here before editing you can immediately see the value of the specific property without changing tabs to go to the DOM or the Console. You can stay in the Script tab and do it.


If you'd read Part 1 you'll know that this can easily be achieved by using the Console. If you haven't, and are frantically right clicking inside the DOM without success, don't worry. Here's how you do it again.

If you look at the DOM, using any of the 3 above techniques you'll see an additional role (EditArticles) that's added.

Let's now hit Continue (F8) and see if we get an additional link. We sure do :). The exact same exercise can be repeated by setting a breakpoint on the isAdmin line (4597) and adding the "Admin" role to the DOM. If you'd like to try it out,  grab a copy of TeamMentor from Git.

DOM Breakpoints

All this while we've been setting breakpoints in the JavaScript. It's also possible to set these breakpoints in the DOM instead and alert us when that particular property changes. Let's extend this same example now, shall we.

On clicking logout, there's a high chance that the DOM is going to get flushed and we won't have access to any of these menus any more. Let's see when exactly the 'role emptying' of the DOM happens.

Navigate to the DOM and expand the CurrentUser node. Right click on the currentuserName element and click 'Break on Property Change'. You now have a DOM breakpoint set which are also visible in the Breakpoints menu in the right pane of the Script Tab (You may have to scroll down). Let's now logout and see if this gets triggered.

Yes! The DOM breakpoint is triggered and points us to the exact line of JS code that was editing the property. Click F8 and then go back to the DOM to see if there actually was a change and you'll find that the same property is now "undefined". Which means the DOM breakpoint did work :). This is extremely useful when you can see the exact path of an interesting element in the DOM but don't know where its corresponding JS code is.

 Other useful features:

There's the 'Break on Next' feature which will break on the immediate next script. I want to see what happens as soon as I click login? Click the Break on Next button and then click Login.

As mentioned by a person who read the previous article, you can set XHR breakpoints if you want to break on a specific XHR call; that's the easiest approach to do things...many a time. Break on the XHR and then use all these other techniques. Similarly you can also break inside the HTML tab when an attribute is added or removed. Make sure though that you're clicking on a leaf node...the last node...the attribute. You can't break on a non leaf node. The same logic applies to DOM elements as well.

If you want to look at the entire Call tree. For example: If you've broken on isEditor and want to know where it is called from you can look at the Stack (middle menu - right pane - Script menu). The most recent function is at the top and the first caller right at the bottom.

That apart you can edit HTML, add elements, destroy or modify cookies and possibly many other little things. To know everything this fantastic tool can do go on to its webpage and read the documentation :).

Hope you liked this small series. Again..if you  missed it.. here is Part 1.

Read More

Javascript application testing - Firebug

Recently I was testing a Javascript application. By Javascript application what I mean, is that a lot of the business logic was written on client side. Now it's a reasonably well known fact that client side logic is easily by-passable.

There's plenty of ways to do it ..intercept in Burp, delete the Javascript from the cache folder on your disk, create your own forms or use Firebug. Maybe more. Largely though I find that a combination of manual probing to detect where client side validation is being used, intercepting every single request for every file type and then dropping the Javascript request responsible...works.

There are times though, like in my last application where the entire UI of the app is constructed client side, where dropping Javascript will not load the app at all or mess it up bigtime. So Burp, in such cases, while you can still certainly use it...is not the best tool for the job. The next thing you will hear, if you google about 'Client side testing' is that 4 out of 5 people will say - Use Firebug.

Now once you understand it, it's an absolutely fabulous little tool to use but until then, it can get a little frustrating to use. So what I'm going to do here is to just point out the features I use the most and why I do so.

Inspect Element

The first feature that I use a lot is the 'Inspect Element'. You can open up Firebug and click the button that's highlighted in Red below and then move your mouse over the upper half of the page. As you hover over each part of the page, the corresponding part of the HTML in Firebug will start flashing. It's all in real time.

When you're clear which bit of the page you want to look at in Firebug, click on that element. Firebug too will stop flashing around. I tend to use this a lot when I want to look at the attributes set for a particular form. For example: If I want to check if the autocomplete attribute has been set on the password element, I can focus just on that and click. Then I can read the HTML on that page in the lower pane.

If you want to change the maximum length of an input field in a form, you can double click on the bit you want to change, and enter a new value. The key here is to ensure that whatever you're typing in is syntactically correct otherwise Firebug won't make the change and will leave you frustrated. For example: If you're entering a string, make sure you put it between double quotes.

Javascript

If you want to change just a part of the Javascript on a page, click on the script tab and then reload the page. All the Javascripts on that page will get loaded. Now you can click on the little drop down there (marked in Red) and see all the Javascript loaded. Click on any one to load it up in Firebug. Don't keep clicking on the dropdown marked in Blue. That's just the main tab that you can use to get there.

If it's a small application you might want to manually review the Javascript on each page. Click menu - Let Javascript load - Review. Repeat the cycle. If it's a huge application like the one I was testing though, there's a high chance you'll go mad very quickly :). Trust me. So you need an upgrade to your testing technique. That's where the DOM tab comes in.

DOM

Anything that's loaded in the browser will read/write something from the DOM. Now lets say you loaded a page up which dealt with logging in to an application and you want to check if the authentication logic is client side. That'd be a rare thing and largely quite a stupid thing to do, but it'll do for now :).

So if it is, there's a chance that some JS functions are being called. But you don't know which one and in which Javascript. So as soon as the login page loads, click on the DOM tab and scroll down a little. In whatever Javascript applications I've seen, there's usually a tree full of elements at the top of the DOM. All the reading and writing from/to the DOM happens here. Just below that though there is a large list of functions (all in green font) as shown in the figure below.

Now read through all of those names and make a little list of which functions 'sound' like performing a login sequence. If you click on each of those functions in the DOM, you'll immediately jump to the Javascript which has the code for that function. NOW you can study just that code and see if its insecure. Yes, you're still studying code..sure..but at least the scope is reduced a little.

Setting Breakpoints

Now we've made progress and come up to a point where you know what bit of code is "possibly" doing what. I say possibly, because you haven't actually run it or in this case, clicked on the login button to actually make it happen and see if THAT function is triggered. Let's now confirm that.

If you look at the screen-shot below it'll show you the exact line number on which those 2 functions are called. You want to make sure that those ARE called. So you set a breakpoint on those lines. A breakpoint, for anyone reading this and not too familiar with the term does what it says. It breaks. Breaks what? Execution. Of what? Code. What code? Javascript. When? When I click login.

So I'm just saying..I'll click Login and if the code here is triggered and my guess was right..don't go on. Stop right there. Set breakpoints as follows..set it on the first line of the function and not the definition itself. I'm not sure the line that has "function" is triggered; it may be..I'm just not sure as I haven't had success. Here's a screen-shot with the breakpoints.

Now try and login..

Yeah..actually put in a user-name and password..and login. If your function guess was right, you should stop right where you put a breakpoint. If it doesn't stop, it's the wrong path flow for THAT function. So maybe there's some other place login is called. Search for all such instances..and whenever you see a function with login in it...set a breakpoint.  Here's a screenshot where I've searched for login, a breakpoint has triggered and the credentials I entered can be seen in the Right side pane.

Now it's like Burp inside a browser window :). Read. Edit. Forward. Only the forward button here is the Continue button .. the right pointing arrow. If you want to go Step By Step and see what happens...and many times you will want to do this, you can use the Step Into or F11 key to now proceed line by line and watch the path the code takes. Again..when you're editing stuff..make sure you are syntactically correct. Otherwise the change will not persist.

Adding to the DOM

So the last cool feature in Firebug that I'll go over today is how you go about adding an element to the DOM. So suppose you want to add a parameter called 'admin' and set its value to 'YES' so you can try logging in as admin, you have to use the Firebug console to do so. So first decide where you want to add the property.

Once you're clear right click on a different property; in this case any root element like PR_TAB_WIDTH and say "Copy Path". Then click on the leftmost tab called Console and paste the path into the bar at the bottom and change its name and value. Like this..

And hit Enter. Now go to the DOM and you should see a new property called Admin with the value YES. It didn't work here of course..to give me admin privileges, but you get what I am trying to say :)

So that's it...start playing around with Firebug, it's a supremely powerful tool, specially when you're testing JS applications. Until next time..Cya :)

Read More

Salt your passwords = Existing accounts password reset

This one is just a simple conclusion that I drew when a customer had MD5 hashed passwords in his database and we recommended them to salt them instead and use PBKDF as the algorithm of choice.

Now the customer added code in, but left the old code in as well which did the simple hash comparisons. So I asked them why and they said..for old users. I started thinking about it and it made sense. Here's why:

Think of it. I have a MD5 password in the database. Say I add a new column for 'salt' , generate 1000 random hashes..one for each user..and add a new column. I then change the code to query the DB for the 'salt' as well, when a person logs in and run the user's password through the PBKDF function before comparing it with the hash. Looks good?

Sure. Except that no one will be able to login. Why? It's super secure now :). No one can find any more vulnerabilities inside. Jokes apart, what's happening here? Lets say the user's original password was abc123 and it had a 32 bit MD5 hash XYZ. Now when the user logs in something like MD5(user entered password) runs..hashes what he entered and compares it to the stored hash. Match? Login successful.

Now there's the salt. So when the user logs in, the new 'salt+pbkdf' code is triggered. So PBKDF(userpwd + salt) is calculated and compared to ..what? The stored MD5 hash. Is there ever going to be a match? Largely no. Because..there is no way you can predict the salt for a particular hash..BEFORE you store it in the DB. Remember those 1000 salts you generated? All random? Did you check if they'd give you the user's password after "decryption"? Nope.

So since there's no way to get the "right salt" for each user ID, the easiest solution is to force a password reset across users. The next time they login everything will automatically fall into place.

Read More

Incremental code review - MD5 hashes

This one is a reasonably obvious tip to be frank. I was recently doing a code review retest for a Java app. Now I don't know too much Java so I was finding it hard stepping through code.

One thing I knew though was that if you have the previous code base and the current one and are "re-testing" it's helpful to see which files have changed. Now anyone with a little Linux experience or programming experience will immediately say 'diff'. And yeah..diff is fine..but that will give you a very detailed listing in a slightly cryptic form. Its readable enough if you go slow, but it's not the first step IMO. I'd like a slightly more high level view first. That's how I stumpled upon md5deep.

So I go into the first root directory of the old code and run md5deep -rl > old_list there. Then I change directories to the new code and run md5deep -rl -X old_list > changes over here. Basically all it means is that I compared the new list against the old. Once I have my changes, I know that any fixes they made MUST be in some of those files.

Now I can run diff on each of those file combinations to search a little bit slowly. It's the same really..but it gives me a little more control over the process.

A tip here to further reduce changes is to use md5deep with grep to filter your results out. So I knew I was looking only for java file changes...so I could either do something like:

md5deep -rl -X old_list| egrep -i '.java$'

OR

md5deep -rl * -X ~/list_md5_old |egrep -v ".doc$|.DS_Store|.js|xml|changed_files|hibernate" > changed_files;wc -l changed_files

I used the 2nd one :) coz I knew what all I didn't want. If you don't know that..start with what you know and filter on from there.

There's a million ways of doing this of course; I just dropped in what I did :). Here's the blog post which saved me some time..

http://linhost.info/2010/02/checksum-a-directory-with-md5deep/

Read More

Cross Domain XHR

Recently I was doing a project (REST web services) where there was an interesting implementation of a defense against CSRF attacks. You would login to the application and immediately be assigned a session ID in a cookie; along with this you would also be assigned an AntiCSRF token, in another cookie. Now this immediately means that both cookies are going to be sent across to the server each time and going to be verified each time. Hence, if this had been the only defense it would be pretty useless; as the additional cookie does..nothing.

In the application though, what was happening was..the cookie 'token' was read, its value grabbed and a new custom header called X-Security-token added in the header with its value. So if on login I get a cookie: token=abcd, the next time I say...do an Edit Profile...I have a new HTTP header called X-Security-token: abcd as part of the request header.

Now my first thought was, Ha, spoofable...the attacker just needs to write a little Javascript, read the cookie (document.cookie) and then add a new custom header and send the request off.

The data was all in JSON format and I wanted a POC to show so I thought I'd just have a simple HTML file with some Jquery code which would make an XHR request by doing all the stuff I talked about above. The code seemed all okay when I tested it on localhost. As in..I set a cookie with the domain as localhost and value as 'arvind' and tried writing JQuery to pick it up and create a new header. That worked and the request DID read the cookie, append it to the header..and send a request to localhost.

The moment I changed the URL to the actual site URL, the request never even fired. I could understand it if the cookie didn't get sent but the request never fired either. More reading revealed that this was due to XHR's limitation of sending cross origin requests. It just refused to send anything at all; I couldn't even see anything in Firebug. I change the URL to localhost..immediately an XHR request gets fired. I tried removing the cookie and resending it...no luck..same behavior. Posts to localhost. Okay. Anywhere else. Browser doesn't allow sending an XHR request anywhere else. Not yet totally clear what's happening.

The other strange thing though is that there is this addon called a REST client which is installed in the same browser and seems to be able to make calls happily to multiple domains other than localhost.

So the question is..What is the difference between an HTML file hosted on a local web server..making XHR calls to abcbank.com AND a firefox addon making calls (not sure if its XHR as I did not see an X-Requested-With header) to abcbank.com? Why does the latter work?

So as a CSRF protection...it doesn't seem safe but I'm not able to get it working with XHR at least. There's some suggestions elsewhere that some versions of Flash allow this; but right now I'm not sure. I'll update this later if I stumble upon something.

Read More

SoapUI - XML Entity Injection

So another thing that I tried out with some help from the guys I work with was this attack called XML Entity Injection. It has been around for quite a while and there are plenty of resources on it so I won't talk about it too much. Here is an OWASP reference and another link which was quite cool and explained things well.

In my previous post I described how to use SoapUI through Stunnel to test HTTPS web services. So following up on that, I was using SoapUI to test XXE attacks as well. So I followed stuff given above on the link to try and read the passwd file from the remote machine (which I'd confirmed was a Ubuntu box). To my pleasant surprise it immediately worked and the entire /etc/passwd file got displayed in the Soap response. Yay. Victory jig. And all that ;)

I was brought down to earth though when I saw an account called 'arvind' in the response. For some stupid reason, SoapUI was retrieving my own passwd file and displaying it in the response. Huh?

So I set Burp up again and set Intercept to on to see what was happening. To my surprise, the request itself already had my passwd file..and the response was just reflecting it back. So even before hitting my own client proxy SoapUI had done 'something' with my request, expanded my own entities and THEN sent it to Burp. It wasn't ever reaching the server directly. Meaning..if I used SoapUI there wasn't any way to directly test XXE...unless there was some tweak somewhere where I could turn off request parsing.

Anyway since I had Burp as well in my proxy chain before it hit the server, it didn't really matter and I could test it in Burp. Turned out that the server was not vulnerable at all. Oh well. Maybe next time it will be ;)

Read More