My first ever Defcon

Defcon was something that I'd heard about for a long long time and I was pretty excited to finally be able to attend it. Matthew and me landed in Las Vegas at about midnight on the 31st and took a cab to the Rio.

The first thing that struck me..as I looked through the cab windows was how bright everything was. I'd always read about Vegas and its colourful night life but seeing it firsthand was..something else. If you think Times Square at New York is bright..then you should definitely come to Vegas at least once in your lifetime :)

Rio's very close to the airport and the roads were quite empty at that time, so it wasn't long before we arrived at the hotel. I pinged David who'd kindly stayed awake so I could get in to the room without any trouble. We talked a bit..after which I unpacked and headed off to search for some food at 1:00am. Sadly, there weren't any all veg places inside the Rio; for that matter...there was exactly one hotel open at that hour - The American Grille. The menu on the wall outside the restaurant was NOT promising. The only thing that was vegetarian was rice and fruit. That's IT. All the same I had a short discussion with the bartender which er went somewhat like this..

AD: Hey..do you guys have anything vegetarian on the menu?
Bartender: (Looks me in the eye)... Looks down...starts laughing..shakes his head in slow motion...Laughs more...
AD: (Yeah Yeah very funny). Bah.

... I ended up eating fruit and a smelly (I don't even want to think what it smelt of) plate of rice at 2:00am. Luckily I was extremely tired and dropped off very quickly.

David and me got up at around 6 and went and stood in the gigantic line for Defcon badges. We had the pleasure of speaking with a SysAdmin from France and a dude who worked in the Fraud department of a bank. We had quite a few interesting conversations about the culture in the different countries. I quite like talking about the culture in these different places...where you can just do away with all the usual 'polite social' babble and just talk. If you want to exchange names..go ahead. If not..that's fine too. I never met the guys in the line again..but enjoyed an hour with them..with zero expectations. That's probably how life is best lived...if you expect nothing. Oops..I started again ;)

The guys managing the herculean lines were incredibly efficient and we got our badges in less than half an hour. Anywhere else...that line would have taken at least a couple of hours to clear. It is amazing how every job can be done efficiently... if everyone does what they're supposed to do..the way it's supposed to be done.

I had the remaining fruit for breakfast and then attended Defcon 101..which was interesting for around half an hour. After that, the cussing and ceaseless focus on being drunk all the time started to get boring. Not that the dudes on stage cared though. They even said...' Are we boring you? Fuck off if we are'. Yep. Sounds about right :). I did just that..heh.

I spent a while roaming all around..getting my bearings of what_was_where so I wouldn't lose my way. At around 12:00 I met up with the rest of the team. It was really nice to see all of them after quite a while. That's one drawback of being in Boston...I rarely get to meet any of them. Although..thanks to those weekly calls..I do get to hear most of them at least. So we decided to eat lunch. Guess where they went. Go ahead. Guess. It was that super tasty, mouth watering American Grille. Sheesh. Needless to say..I took a pass :)

I spent the rest of the day attending a few talks..since none of the workshops were open on Thursday. Seriously..it'd be nice if they were. There would be some more stuff to do apart from attend talks which I wasn't interested in anyway. Anyway..the talks weren't too bad...although they were reasonably basic. I quite liked the Pentoo talk...maybe I'll give it a spin sometime. Maybe :)

The rest of the guys from Seattle eventually turned up at around 5:00 in the evening. It was good to meet up with Amar after quite a while...and also a lot of the other guys. Met Nora too..a long time after I first said hello about a year and a half ago..while still on contract. John I, Max C, Eby..good to fix faces to all the guys I talk to online in short.

Ian/Joe/Marcus (Dunno who...coz Ian complained Joe was getting a lot of credit :).. so I'll play safe) booked one gigantic limo/bus into which everyone piled in and roamed all around Vegas. There was one pitstop made..obviously...where a few of the guys went in and bought around 500 litres of booze of all kinds. This resulted in Tom playing a terrible game with everyone. He asked everyone to drink a peg? of whisky and eat a Hershey's kiss (chocolate) at the same time. Obviously..all the experienced dudes had no apparent trouble .. but Eby sadly suffered quite a lot and was high/in some discomfort for a while. Amar only cackled at all of it... he's an old hand at all this ;).

Eventually we reached this place called the SkyMall where there is a dome and the roof is painted to look like the blue sky. Parts of the dome are rigged to turn sprinklers on...and generate flashes of lightning and cause thunder to rumble. For a good 15 minutes .. I had no clue we were inside the mall..that's how well it was designed. This was definitely one of the most unique places I had ever seen.

Hopped in and met up with Max.V (who was my first ever project lead while I was on contract) and Jon Boyd...good to see him too..after working quite a bit with him. Had a few really good discussions with Marcus on reversing...and later Dinis popped in as well...for a while. Morgan very kindly helped me out with my salads for the night...he always looks out for my food when I'm around, which is really nice of him. Talked quite a while with Tyson and Amar too..outside the hotel....good to speak to Tyson too...after the infamous "experience" in Connecticut ;).

During dinner...there were some er disturbing parts for me...maybe this discussion will throw more light on it.

AD: Reversing blah blah
Marcus/Jon.B/Matthew/whoever: yeah yeah
Waiter: White roasted chicken...who wants
All: yeah yeah we want
Waiter: chop chop chop
AD: ugh
AD: so ..blah blah blah
All: blah blah...
Waiter: Red steak
All: yeah yeah
Waiter: chop chop chop
AD: (oh fuck off)

Repeat a million times... :D

Just when it was all finishing..Dinis turned up...and the whole saga repeated itself just as I was finally hoping it'd ended. Thanks Dinis for coming late :D

ah well.. it was a steak house really..so for me to expect Indian vegetarian delicacies was a little er.. unrealistic ;) .. but the meat chopping exhibition was not a lot of fun..frankly. I've got a very thick skin...but this was a bit too much even for me. The rest of the dinner though..thanks to all the guys was a lot of fun and I enjoyed speaking with all of them.

Tyson and me lost our way in the mall and had to run a lot..one way and then the other until we finally found the limo again..and got dropped at the Rio. A lot of the guys went off for booze session 2 at a Microsoft Party. David, Garrett and me went off to the room though and slept off..after discussing some deep stuff for a while. I just can't shut up..you know :). I must add here that Amar's plans for reducing his liver's age by another month were dashed by the security guards at the Microsoft party }:)

Day 2 started with a bunch of us having some breakfast at Starbucks and then splitting up to get to different talks. I attended the quite awesome CDMA interception talk where a bunch of complex demos worked flawlessly. It just proves once more...that if you work hard enough and have a clear thought process... the hardest thing is easily doable. Big props to Tom Ritter and the guys at Isec for pulling that talk off.

Lunch on Day 2 was downright awful as the food in the fridge had frozen up and I didn't have a microwave to defrost it. Somehow though I ate it up :D. I spent quite a while in the Tamper village learning to break seals open. The simplest one was using Acetone to peel labels off carefully without being detected. I tried to break open quite a few other seals using these things called shims (pieces of Coke cans :)) but was a miserable failure at all of it. Oh well. I'll learn.

I spent the latter part of Day 2 in the hardware village and soldered my first ever piece of hardware. That gave me a huge kick and I was very very happy that I did something new. The feeling of achievement is a unique thing...it never gets old. I was too late to join the rest of the guys for dinner. Not that I'd have eaten anything anyway ;). Some more rice and chips for dinner, a little TV, a little Kindle reading..some more discussions with the guys on tons of things that I cannot remember .. I hit the hay. Seriously...I was in Vegas..and instead of ogling at babes in strip clubs...I read the Kindle? Yes Yes.. much better :)

Day 3 on Saturday...David, Garrett and me went off to Palms for breakfast... where they actually let me eat my own food..interestingly. That wouldn't have been allowed in India. Those pancakes looked delicious...but sadly I couldn't eat any of it..coz of my rules. I spent a good 5.5 hours doing a surface mount at the hardware village. The end result was a weakly blinking LED which was utterly useless. All the same..it blinked...and it was the result of a lot of painful work. So Im happy.

The other good thing was that I discussed a ton of things with a ton of people whose names I don't know and I probably will never ever meet..but all of whom helped me a lot. I prefer it this way without all of that artificial societal crap that everyone deludes themselves into thinking is 'necessary'... life long. Also... I managed to skip a meal. Yay. One less meal at some terrible hotel.

I think I saw Amber's talk on suicides where she talked a bit about Aaron Swartz and on how to detect the signs of suicide. I thought it was a really great talk..and I hope to learn a little bit more about it going forward.

Met up with Amar and Nipun and talked a bit. Met people I never thought I'd see again. The world is a super small place. Spent quite some time playing the fool along with Zak. If you're reading this Zak...I hope you realize that you've scarred me mentally lifelong by bullying and harassing me that evening and showing interest in a lot of extremely 'delicate' rest room related issues. I hope you reflect deeply and do some soul-searching. :)

We all walked down to Palms where I found out that I had to spend 25$ and buy the sea-food buffet and then eat just a salad. That made no financial sense whatsoever so I came back and ate more rice and chips. Spent some time watching some people selling houses to people on TV. I quite enjoy that show. David got back at around 10 in the night following which we talked about a lot of things (Ayn Rand included (finally :))) for a couple of hours. Garrett was painting the town red that day and didn't get in till 5:30am  or something. I think this was the night of the famous pool party which I too attended and had a blast. Oh wait ;)

I attended Dinis's highly energetic talk on Sunday morning and met up with him as well. It was cool to see him and talk a bit. Unfortunately, he was surrounded by too many people so I couldn't talk too much with him..maybe some other time. That apart Sunday was pretty uneventful...and I kept hanging around here and there until the Defcon closing conference.

The Defcon closing showed me a side of America that I hadn't seen. There were a lot of guys who were moving on from the Defcon management team..after a ton of years of loyal service. Jeff Moss gave a number of extremely genuine tributes to all the guys moving on. The thing that touched me a lot though..was the obviously genuine affection that the rest of the team had for these people. There wasn't a bit of that ..that was fake or made up by anyone. And these are all big bad hackers...who do not have feelings and supposed to be extreme egotists who give a damn about anyone. For them to come out, express themselves and talk so well... that for me was pretty cool. It also showed me that... people.. deep down... are all the same. You just have to look beneath the surface..and not go with your instincts.

I spent a lazy evening with Amar and Eby on the Vegas strip after which I headed back to the hotel and then flew back to Boston the next morning with Matthew.

Considering the size of the event...and the complexity of it all...and having to manage a group of people who call bullshit out better than most other professions...and doing it so well...Defcon for me was an absolute hit. Sure there's little cribs...but overall...big big respect to all those who made that happen.

Hopefully... I'll be back for Defcon 22.

Read More

Restrict signed Java applets

There's a ton of information on the Internet on how to sign Java applets and restrict unsigned Java applets as well. Very strangely there is very little information on doing the same for signed applets.

I did manage to find information which eventually helped me out; just that it took an insane amount of searching. Hence this little blog..which just collects all the information I found and puts it in 1 place.

First of all, the reason (as you already most probably know) to restrict signed applets, is that they're all powerful and can perform dangerous file I/O and network operations. So it's a nice thing to be able to restrict them from doing so, if needed. So here are the steps to do so, in a nutshell:

a) Sign your Java applet using keytool and jarsigner. A self signed applet is sufficient for demo purposes. The same logic can be used in case a trusted CA signs the certificate.

b) Once the applet is signed it's usually packaged into a JAR file prior to deploying it.

c) It's then deployed by embedding it into the HTML of a web page.

d) When the user visits the page, there's a pop-up which will now appear, asking the user to grant the applet additional permissions. Note here that if you click Run, the signed applet has complete control and can make numerous file and network I/O calls. If however, you click Cancel, you're not granting it permissions. The applet still runs (contrary to what one might intuitively think) but behaves like an unsigned applet.

e) What we now want to do though, is to limit what the applet can do, when the user clicks Run. For example: If all the user wants to do, is write to /tmp and nothing else, why should it have a million other privileges?

f) There's 2 ways to do it. One is to call every single relevant method in the applet from JavaScript. The second way is to write a policy in java.policy. Without frustrating you further, I'm going to show you, with a little sample code on how to do both.

g) First of all here is the Java code that I used as a POC. It's grabbed and tweaked from some tutorial online and not my own.

import java.applet.*;
import java.awt.*;
import java.io.* ;
import java.util.*;

public class FirstApplet extends Applet{
  public void init() {
    createFile("/abc/testsignapplet.txt");
  }
 
  public void test_HTMLbutton_method_invoke() {
    createFile("/abc/booboo.txt");
  }

  public void test_js_onload() {
    createFile("/abc/doodoo.txt");
  }

  private void createFile(String filename) {
    FileOutputStream out = null;
    try {
      out = new FileOutputStream(filename);
      out.write(("Testing jar signing process...:" + new Date()).getBytes());
    } catch(Exception ex) {
      ex.printStackTrace();
    } finally  {
      try {
        if(out != null) {
          out.close();
        }
      } catch(IOException e) {}
    }
  }
}

h) Here is how you must call the public methods of the applet from either an HTML element or from JavaScript. The line in the last < script > block which embeds the applet is possibly not the best way to do things; it's just there to show you guys how to call a method via HTML and JS, which is the point of the post.

i) Doing so, will cause the applet to still behave as an unsigned applet. If there's any malicious code in any of those functions, it's not going to be able to break out and cause havoc.

j) The other way of limiting the operations an applet can perform is by editing the file called java.policy. On a Ubuntu system, by default this file is inside your home directory. It is named .java.policy.

k) Back the file up and then delete all the lines in that file. Now add these lines to the file. This limits the applet loaded from http://localhost/applets/ from writing to any other directory except /abc.

grant codeBase "http://localhost/applets/*" {
  permission java.io.FilePermission "/abc/*", "write";
};

l) Note that a cool GUI tool called policytool can also be used for this purpose. If you have JRE or/and JDK on your machine, you should have policytool as well. You can add/edit/remove policies using it as well.

m) Test your applet using appletviewer first. It's a tool which you can use to check if your policies are working properly, before deploying the applets everywhere.

appletviewer -J-Djava.security.policy=/home/arvind/.java.policy sample.html

n) If the results are as expected, launch the applet in the browser. All the HTML and JS calls to methods should be blocked :)

----------

p.s - It's a good idea to have the Java Console launched while you're doing this stuff. It throws exceptions that you can then see and modify your approach accordingly. The Java Console can be launched using javaws -viewer and ticking 'Show Console' in the Advanced Tab.

Other Java related settings can be tweaked too in here. A good guide to follow can be found here - http://seanthegeek.github.com/harden-java/

Read More

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