Happy New Year!

Happy New Year!

A good fingerprinting session

A good place to look.... well in researching so many new texts on web app vulnerabilities, they all rightfully begin with the "fingerprinting" of the application to not only understand how it works but with what technologies it depends upon. This may not be much of a revelation to some but it was a bit of a "....why didn't I think of that before..." to me. I was poking around a job board reading potential employment opportunities and in reading a specific job description (all of them had this trait in fact) I realized that the employer, in giving it's ideal candidate prerequisites, also gave all of the technologies it currently uses! It said something like this:

Ideal Qualifications:
BS degree in Computer Science or related discipline preferred.
Strong knowledge and proficiency for system administration and concepts for software utilized in HP Peregrine Service Center, HP Peregrine Asset Center and MS SQL Server.
ITIL experience with and/or ITIL certification
Bank operations and proven project management experience is a plus
Prior operational experience in a support position and/or in a position requiring a high level of technical customer service.
Strong organizational abilities


So I now know that this employer uses HP Peregrine Service Center, HP Peregrine Asset Center and MS SQL Server... (which is really nice to know so that I do not waste time trying to inject the incorrect SQL syntax if they are in fact vulnerable to SQL Injection) and it goes without saying that if you do not know what the technologies are you can easily Google for the latest vulnerabilities. I searched through additional job postings and they did the same in all of them, effectively "fingerprinting" their entire technology network for me! Who needs tools (just kidding)... again so much of hacking boils down to you, not the tools that you have, for YOU are the most powerful tool in your arsenal!

Reflection Injection

According to OWASP, reflection injection problems are a subset of injection problem, in which external input is used to construct a string value passed to class reflection APIs. By manipulating the value an attacker can cause unexpected classes to be loaded, or change what method or fields are accessed on an object. They give the following example:

The following Java code dynamically loads a connection class to be used for transferring data:

// connType is a String read from an external source
Class connClass = Class.forName(connType);
HttpURLConnection conn = (HttpURLConnection)connClass.newInstance();
conn.connect();

Suppose this application normally passed "javax.net.ssl.HttpsUrlConnection". This would provide an HTTPS connection using SSL to protect the transferred data. If an attacker replaced the connType string with "java.net.HttpURLConnection" then all data transfers performed by this code would happened over an un-encrypted HTTP connection instead. Interesting, I was not aware of this attack vector. Does anyone have any experience with this sort of thing? Here are some additional examples from OWASP:

In C/C++:

unsigned char *simple_digest(char *alg,char *buf,unsigned int len, int *olen) {
       const EVP_MD *m;
       EVP_MD_CTX ctx;
       unsigned char *ret;

       OpenSSL_add_all_digests();
       if (!(m = EVP_get_digestbyname(alg)))
               return NULL;
       if (!(ret = (unsigned char*)malloc(EVP_MAX_MD_SIZE)))
               return NULL;
       EVP_DigestInit(&ctx, m);
       EVP_DigestUpdate(&ctx,buf,len);
       EVP_DigestFinal(&ctx,ret,olen);
       return ret;
}

unsigned char *generate_password_and_cmd(char *password_and_cmd){
       simple_digest("sha1",password,strlen(password_and_cmd)...);
}

In Java:

String command = new String("some cmd to execute & the password")
MessageDigest encer = MessageDigest.getInstance("SHA");
encer.update(command.getBytes("UTF-8"));
byte[] digest = encer.digest();

Social Engineering

Sorry this has gotten a little of topic lately... In an effort to continue this blog nearly daily I guess there will be posts about some differing topics as well. At the referenced OWASP meeting yesterday the moderator got to speaking about a colleague of his that is a professional social engineer, testing companies fortitude. Some of the stories were quite interesting how easily he was able to get an employee to give up either sensitive information or complete remote control of their local system. I guess my point here is that this type of attack is possibly the first type of "hack" ever executed and it still works today. So even with all of our technology and security, you can still get someone to give you the "keys to the front door" just by asking. And that is by far the best solution right? I guess what I am saying is that don't over look anything, even if you think it will not work because you just never know. Dumpster diving anyone?

OWASP

I was invited, through my work, to attend a local OWASP (Open Web Application Security Project) chapter meeting today. I must say that this project is just what I was looking for as a security professional diving into web application security. The website is simply loaded with tons and tons of information, instruction, the code examples I so desire and even tests and test site modules to allow you to learn how to use the various exploits covered. They have a Java application that you can install locally and run attacks and test modules against to familiarize you with each class of vulnerability. My last post was sort of a rant, as pointed out by an unnamed poster, and this experience has really awakened me to what is out there aside from text books and trial and error. The industry is certainly taking the web application issue quite seriously from this example and it is great to have access to this information. If anyone is in my "boat" I would strongly encourage you to take a look at this site and join a local chapter if you have one i your area. It was well worth my time and I will be a participating member from this day forward.

The WASP

So I was surfing around today and found a great blog on here that I thought I would post for others interested in this field to check out. http://jeremiahgrossman.blogspot.com/ I had this guys company in here a few months ago for a POC while we were deciding on a app security vendor. The sales guy was intolerable, but Jeremiah is quite astute in this field and his blog is really full of great stuff from an industry perspective. In addition the Burp Suit BETA is now available for those familiar with it...it is available at http://blog.portswigger.net/ and it is loaded with lots of new features. It did crash one of my PC's, but lots of newer apps do...(it may be specific to my older PC) so it should be safe on an updated box. Anyway, I wanted to get back to the topic of code disclosure. I was reading through a text I have about Trojans and worms and I am really upset, or more to the point sick and tired, that they do not post an actual coded variant. What is the big stigma...? Anyway... tools are great but you really have to have a core understanding of what you are doing to really get anything out of them.

My Favorite Tool

You may have already guessed that I am a big proponent of the proxy interceptor tool(s). They make me feel as if time stands still, and it does in terms of the breakpoint(s). So I was at another site today, this time a retail store. I was interested in testing the durability of this shopping cart. Here we go. Upon my first breakpoint. Lets back up a bit. A proxy interceptor is a tool that allows you to control the submit and response of a web application by allowing you to set breakpoints (defined URLs tagged as the point to halt the submission or response so that you can modify the text that would normally be unmodifiable) . This should be obvious but in case its not, the proxy tool sits between your browser and the application, allowing it to control the flow of execution. OK, so I engage my proxy, navigate to the site and put an item into my cart. At this point you go back to the proxy and select the corresponding URL in which to set the first breakpoint. I set the breakpoint and refresh the page, the proxy halts the submission (I set the proxy to break on a submit first) this allows you to see if the server is going to validate the data that I change when it comes back from the server. I altered a bunch of stuff here to test many potential vulnerabilities. Make note of the "referrer" field as this will allow you to spoof the session and go right to the URL you want by naming the expected URL referrer, kind of a short-cut. Anyway, this site used some type of obfuscation which I did not follow at this point (using an x=n;y=n equation) to hide the price of the item in plain text by using a product code instead of a dollar/numeric value. So the submit was not overly viable at this point. My proxy of choice allows me to break on the response at this point so I will do that and review the response. This actually halts the response before it presents in your browser so you still have the ability alter data. I was able to alter price, logic and quantity to my liking on the response. However, as a credit to the site, I am in HTTPS (443) mode at this point by the way, and the process of transversing to the check out thwarted all of this effort as the data is sanitized and is reset to the correct denominations. No worries right? Right. I will just change the values at the check out. Here is where it gets fun. They employ a nice validation of the session on this specific page so the token changes upon every refresh of the page, causing my breakpoint to fail as I do not have it set correctly because the token is dynamically changing as I refresh the page. I set it to the last time I was there, which is not what the next time I am there will be. Pretty good, although I am able to view all of this data during the failing breakpoint (it allows me to view but not edit the data presented) and I can clearly see that if I do find the correct breakpoint I will in fact be able to alter the numeric data as I did previously and change the price. As a side note I also checked to see if I would be able to enter a negative number for my price as I would like very much to be paid for my effort by way of a refund to my chosen method of payment. Ha Ha..! But that didn't work, they did account for negative integers, at least in decimal format, I did not try a hex or base64 conversion here (I have a nice browser based converter for this that I will post up at some point unless you enjoy manually processing these conversions!), but that would be an option in the future..Moving on..now I have the option to test out my skills as an algorithm predictor...Or better yet I can continue this process several times, noting the change in the algorithm and try to deduce the pattern and predict accurately the next token. I basically stopped here for today as I was side tracked... The point is that this entire process took me less than 10 minutes to get to this point. I know my tools, but this is much more about understanding what you are looking for than being a speedy tool wielder....Spend the time to really understand what each aspect of the application means and you will be rewarded in the end. It is more about finding an over looked aspect of code or logic than it is about speed of execution. Slow down grasshopper, slow down.