Burp suite tip / tutorial: renaming tabs

June 29th, 2013

This will be a quick and simple tip that you may not have been aware of, you can rename tabs within Burp. A friend of mine who works out of Raleigh turned me onto this. I find new sometimes obvious and hidden features in Burp all the time and this is one of them.

I find this feature handy especially in a large application as I can easily keep track of what I’m testing.  I use the tab renaming on the Repeater and Intruder functionality. In order to rename a tab simply double click the tab which will allow you to edit the tab.

Repeater before

Repeater after

Intruder before

Intruder after

Hope this simple tip helps you perform better application pen testing.

Burp suite tutorial / tip: determining cookie functionality

April 1st, 2013

When testing web applications you may come across an application that passes a ton of cookies along with each request. Cookies are used to maintain state within the application and typically only one cookie is needed within the application. There are times when other cookies are used as well and when testing web applications it may be difficult to determine what cookie is associated with session and functionality. Hopefully my technique of determining cookie functionality will also help others as well. Let’s get started with an example. I’m going to take a look at ubuntu forums as an example.

So configure burp to capture traffic and make a request to Ubuntu forums. Below is the screen shot of Burp making the first couple of requests to ubuntuforums.org.

Here we see that simply going to the forum home page without authenticating we get two cookies “bb_lastvisit” and bb_lastactivity”. We’re lucky in some sense as these cookies are fairly descriptive, often times cookies have nondescript names which makes it even more difficult to understand their functionality. Now let’s authenticate and see what other cookies come into play.

Now we have two additional cookies (bb_sessionhash and IDstack) that get submitted with each request. At this point it’s a safe bet to say that either IDstack or bb_sessionhash is responsible for handling session to ubuntu forums. One of the quick and easy ways to determine which cookie is truly used for session is to intercept a request that requires authentication, manually delete that cookie and see if you get kicked out of the application. Below is a screenshot of me performing that action.

In this example I clicked on my profile because some portions of the profile require authentication to view. So I deleted the IDstack cookie to see if it had any affect on session. After forwarding the request it did indeed bring me to my profile so the IDstack cookie isn’t responsible for handing the session. We can see this in the browser as shown in the screenshot below.

Next let’s try the getting rid of the bb_sessionhash cookie via the same method.

After the bb_sessionhash cookie is removed we do indeed loose the authenticated features of the “My Profile” page as seen below.

So now we have identified the cookie that maintains session for this application. It’s also a good idea to delete all the cookies except for bb_sessionhash or your particular cookie in question. I did go ahead and delete all the cookies except for bb_sessionhash and I maintained session so the other cookies have nothing to do with session in this instance. In this scenario you can wipe your hands clean knowing that you’ve correctly identified the cookie that properly handles the session but sometimes other cookies will appear within the same application when you stumble across other functionality. One example of this is when a web application has some reporting piece to it. I’ve seen where the reporting functionality may be a bolted on third party application that uses it’s on session handling which would call another cookie. Because of this I like to only pass the cookie that handled the initial authentication and see if any other functionality, a la reporting, gets broken with only the one cookie being passed. So what I like to do is set up a intercept rule that will only pass the initial authentication cookie and monitor what gets broken as I walk the application. To setup this rule go into the Options tab within the Proxy tab and create a “Match and Replace” rule to perform this. I add a rule with type of “Request header” and then paste the entire cookie line into the “Match” field then I only place the session handling cookie in the “Replace” field which in this case is the bb_sessionhash cookie. A screenshot of this rule can be seen below.

After this every single request will only contain the cookie you’ve identified as the one belonging to the main session. If you look in the history tab and view a request after you’ve made the rule you’ll see where this comes into play as seen in the screenshot below.

Now you’ve successfully isolated one cookie that deals with initial authentication and while you’re walking the app and you stumble across some broken functionality it may be because another cookie got introduced into the application. Hopefully this rule will help you identify other cookies that get introduced into the application. Also hopefully this will keep you mind open to other rules that you can make regarding sessions within the application.

Please leave feedback and let me know if this was helpful and if you know of any other good burp suite tips please leave feedback on that as well.

Burp suite tutorial / tip: using intercept to locate automated scanner findings

February 23rd, 2013

So the problem I have in my job and maybe others do as well is that when assessing a web application for vulnerabilities you want to throw automated tools at it first to get the low hanging fruit. So you get the results back and you have some good findings but you’re not exactly sure where that finding resides inside the application. Meaning first click here, then here, then here, and modify parameter X. It’s not crucial to know this because with burp or any decent web proxy we can replay that request to retrieve and prove the vulnerable results but when dealing with laymen and even developers you have to hand hold them through the exploitation process via the browser as much as possible hence the need to know where in the application the vulnerability exists.

In big applications simply knowing a what GET or POST request is vulnerable may not tell you where the vulnerability lies. Let’s say the scanner reports back that http://example.com/xskw/requestID?=blah is vulnerable, well this is a generic URL without much context so it’s not obvious where you would have to browse to stumble upon that request. It’s even worse for POST requests because going directly to the URL without the parameters can produce errors within the application.

Let’s walk through an example of using the burp intercept feature to find where scanner results are located. I’ll be using an intentionally vulnerable web application named Peruggia found within the owaspbwa project which is a great project to learn web app testing. So I ran the active scan against peruggia and got the following results.

I’m going to focus on the highlighted cross site scripting vulnerability in the screen shot above. I picked this request for a number of reasons but first let’s take a look the details of the request below.

Here we see it’s a POST request and I wanted to focus on a POST request because some of the challenges faced with these requests. In the top third tab we see the response was redirected which means we’ll get a 302 status code. If you were to copy and paste the URL into the browser and make that request you’ll be redirected to the home page. This is the nature of POST requests we can’t just put the URL into the address bar and be take to that location. Because of this it can be hard to determine where in the application the vulnerability exists. Especially for XSS (cross site scripting) vulnerabilities I like to obtain screen shots of the alert box to prove to the customer that I was able to exploit the vulnerability. With a GET request this is easier but POST requests add a level of difficulty.

Let’s walk through an example to understand the challenges. I’ll be starting out on the about page of the Peruggia application. Next I’ll paste the URL from the XSS finding into the address bar.

After I enter this request I get redirected to the home page.

This is also reflected in burp where we see the 302 redirect status code that sends us back to the home page.

So the challenge is to find that “comment” parameter that burp flagged as vulnerable but without a simple GET request this can be difficult. I didn’t pick the greatest example because the “comment” parameter shouldn’t be that hard to find in this application because it’s fairly small and the parameter is actually providing some context, adding a comment, which doesn’t always happen. So for this example let’s ignore the big comment box on the home page and pretend we didn’t see that.

We’ll now set up a rule inside the proxy intercept to alert us when we stumble across the vulnerable “comment” parameter. Let me explain the term stumble for a second. When I get a result back from a scanner and I’m not sure where it’s located inside the application I’ll typically start walking the application and monitor my proxy history to see if that parameter was passed within a request. This can be a pain in the butt so setting up a proxy intercept rule can help automate the process. The rule is somewhat counter intuitive because we’ll leave the intercept on the entire time and let it catch when it sees our parameter. In this case we’ll disable the default file extension match rule and add our new rule to look for the parameter in question. Below is the rule I setup to catch the vulnerable parameter “comment”.

Now the next thing is to start browsing / walking the application and the proxy intercept will automatically alert you when you come across the vulnerable parameter. So while walking the application I decide to post a comment on a picture to ensure I’m touching every functionality of the application. My intercept is on with my new rule waiting for it to flag the vulnerable parameter.

After I make this request my proxy starts blinking and alerting me to the fact that I’ve come across the “comment” parameter.

Unfortunately for large applications it may take some time before you stumble upon the proper vulnerable parameter but hopefully this will help you out when trying to pinpoint the location of automated findings. Of course once we’ve found the vulnerable parameter that the automated scanner has found we’ll want to capture a screenshot of the exploit and this case we’ll need to document that we’re abe to execute javascript inside the application. So now I’ll capture that POST request again and insert the classic javascript alert message.

And now the alert message proving to the application owner’s, developer’s, and customer’s that executing javascript is possible.

XSS FTW. Hopefully my little small tip will help you when trying to hunt down where in the application an automated finding resides. Happy bug hunting.

Security testing iPhone – local data storage

October 13th, 2012

One of the areas you need to focus on when performing security / penetration testing on iOS applications is what information is written to disk or stored locally. There are a number of things that can be written to disk (text files, config files, plist files, databases, etc). There are a handful of directories that an application typically uses to store local data within an iOS device which you’ll need to keep in mind when combing through the local file system. I’ll cover these directories and walk through an iOS application security assessment.

The application we’ll walk through is iGoat, an intentional vulnerable application written for the iPhone / iOS devices. The iGoat application can be ran inside the iOS Simulator which is free to use assuming you have an Apple OSX device. I’m not going to walk through setting up the iGoat application within the simulator, please check online resources for getting iGoat up and running. Once up and running go to “Data Protection (Rest)” > “Local Data Storage” and start the exercise. You’ll notice the exercise describes that it’s using an underlying SQLite database to store information, keep in mind you won’t normally know this information. Initially when performing a security test on an iOS application you won’t know if data is being stored locally, it could be it’s storing all information server side. If it does store data locally it can be in a number of locations and in different formats such as a SQLite database. Once you start the iGoat data storage exercise you should come to the following screen.

At this point just put in some fake username and password, I’ll choose username “super” and password “secret”. After you click “Login” nothing will happen, this isn’t meant to be a full blown application. So the application took input from the user but what happened to that information? The iOS simulator is no substitution for an iOS device but the behavior of the application remains the same, meaning if you’re testing an application in the simulator on your Macbook then if the application stores local data then that data will be stored in some location on your Macbook. The application data is typically stored in the following location on your OS X device.

/Users/travis/Library/Application Support/iPhone Simulator/5.1/Applications/UID

Where UID is a unique identifier for the application installed and of course you’ll substitute my name with your username in the “Users” directory. My UID in this case is “8813AE1B-3FC7-4503-99D0-666E974A74D7”. If you open up Finder in OS X and try to navigate to the Library directory you won’t see it that’s because it’s hidden, you can enable the viewing of hidden files and folders but I’ll be navigating via the Terminal which is in the Utilities folder under applications. Once in the UID directory perform a “ls -lh” command to see the files and directories the application is utilizing.

mac:8813AE1B-3FC7-4503-99D0-666E974A74D7 travis$ ls -lh
total 0
drwxr-xr-x   4 travis  staff   136B Sep 27 19:08 Documents
drwxr-xr-x   5 travis  staff   170B Jul 11 09:50 Library
drwxr-xr-x  28 travis  staff   952B Sep 25 21:44 iGoat.app
drwxr-xr-x   2 travis  staff    68B Jul 10 21:37 tmp

Here we see four directories (Documents, Library, iGoat.app, and tmp), we know they’re directories because each line begins with a “d”, if it wasn’t a directory you would just see a “-” dash. These are the four main directories you’ll have for each application and you’ll replace iGoat.app with whatever application you’re testing (e.g. AppName.app). When it comes to looking for items of interest when security testing one should focus on these four directories, listed below is a chart showing the type of information that can be found in those directories.

The contents and location are not set in stone but these locations are the best place to start. So now you know the location of where files may be stored locally on an iOS device but what’s the best way to discover the files we’re interested in? Let’s use what we know in this case, the application tells us that it stores login information into a SQL lite database. Normally you’re not going to know that the application uses a SQL lite database to store information unless you’re in close communication with the developers of the application. For now we know the app uses a SQL lite database so let’s search through these directories looking for that file. We could do this manually but I think dropping to a command prompt is always best. Use the “find” command to locate any SQL lite databases, the command is below.

mac:8813AE1B-3FC7-4503-99D0-666E974A74D7 travis$ find . -name *.sqlite
./Documents/credentials.sqlite
./iGoat.app/articles.sqlite
mac:8813AE1B-3FC7-4503-99D0-666E974A74D7 travis$

From the output of the find command we’ve located two SQL lite databases for this application, credentials.sqlite and articles.sqlite. Credentials.sqlite is the obvious place to start. There are multiple ways to view that sqlite file but the two I prefer are the sqlite database browser and the command line utility sqlite3. I’ll be sticking with the sqlite3 command to give you a different perspective as the sqlite database browser is GUI based and easier to use. One thing to note with GUI tool is that it can’t browse hidden directories so you’ll have to copy and paste sqlite database from the “hidden” Documents directory into a directory that the GUI tool can navigate tool. Next open the sqlite database with the command below.

travis@mac:Documents$ sqlite3 credentials.sqlite
SQLite version 3.7.14 2012-09-03 15:42:36
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite>

You’ll be presented with a sqlite prompt. Next issue the “.tables” command into the sqlite prompt.

sqlite> .tables
creds

Here we see a “creds” table, to view the contents of that table use the “.dump” command.

sqlite> .dump
PRAGMA foreign_keys=OFF;
BEGIN TRANSACTION;
CREATE TABLE creds (id INTEGER PRIMARY KEY AUTOINCREMENT, username TEXT, passwordTEXT);
INSERT INTO "creds" VALUES(1,'super','secret');
DELETE FROM sqlite_sequence;
INSERT INTO "sqlite_sequence" VALUES('creds',1);
COMMIT;

Here we see in the first INSERT statement the values of username and password that we typed into the application. So the vulnerability is that credentials to the application are stored in plain text so if someone were to remotely or locally gain access to the iphone then they could glean these credentials. It’s always best if possible to store credentials server side and if you must store credentials locally then encrypt that information. This goes for any sensitive information stored locally (text files, config files, plist files, etc). I could extend this example to those types of files but the same concept applies. So if you’re curios about one of your iOS apps check out those locations and if develop iOS applications make sure you store local sensitive information in an encrypted format.

Feel free to comment with questions or concerns.

Reverse engineer an obfuscated .Net application

June 16th, 2012

Some of the concepts I’ll be covering will be new to some people and may be hard to understand but for others who are familiar with this field will find the concepts simple. Hopefully no matter what your comfort level or experience you’ll get something out of this.

First I’ll give a brief intro to .Net and how it varies from other applications. There two main kinds of applications / programs that you install on your Windows 7 / XP / etc machine, these are either compiled or interpreted. Compiled applications can be a standalone executable but usually you’ll have to install it by clicking the usual “Install, Next, Next, Finish” on the other hand an interpreted application doesn’t require this. An interpreted application comes as an EXE but an interpreted application does require an “application virtual machine”, the interpreted application doesn’t run natively on your machine instead the virtual machine takes care of all the execution. In this case the .Net framework is the application virtual machine we’ll need to have installed. You may have downloaded an EXE in the past and got the message that it requires “.Net framework 3.5” that’s because you downloaded an interpreted application. Java is the very similar to the .Net framework in that it employs a virtual machine as well which explains why almost everyone has to have both Java and .Net installed on their windows machine.

Compiled apps are in assembly machine language and we don’t have source code and going from compiled assembly back to original source code is difficult which is why companies like microsoft and apple only give you compiled applications because they want to make it hard for you to get original source code. With interpreted applications it’s quite different, for the most part it’s easy to decompile interpreted applications back into their original source code. This is true generally because the application virtual machine expects much more information about the application it’s about to compile and execute which makes going in reverse easier as well. I may not have explained that well but hopefully this stackoverflow thread will shed some light.

So by nature of having a .Net application it’s easier to get source code from the compiled exe which makes it easier to reverse engineer. Some developers and most users are not aware how easy it is to get source code from applications that run in a virtual machine. Developers that are aware of this sometime utilize obfuscation techniques so that competitors aren’t easily able to obtain source code. Obfuscation is simply a way of hiding something you don’t want others to know about. Typically it goes “source code –> obfuscation –> hard to understand (garbage)”. This is a simple explanation of obfuscation and some techniques are better than others. There are a handful of obfuscation programs on the market that developers can use to hide their code. In the example I’ll be showing you the developer used an obfuscation technique but this isn’t going to stop us from reversing the program then modifying it to our content.

So the first thing you’ll need to do is determine if the exe you have is actually a .Net application and not some other compiled application. There are a couple of tools but the one I like the most is CFF Explorer. Once installed you can right click on any exe and it’ll try and determine what language and compiler was used to make the executable. Let’s browse to firefox.exe, right click and choose CFF Explorer.

From the output of CFF Explorer we can tell that the language Visual C++ was used to create this executable and that it’s a PE (portable executable) file type. PE’s are normally compiled using one of the C based family languages. This differs from application virtual machine compiled executables such as a .Net application. I’ve created a small .Net application called GuessPassword.exe that we’ll discuss in just a bit but first let’s look at the output from CFF Explorer on GuessPassword.exe.

Here we can confirm that it’s a .Net application. So in both cases we have an EXE that we’re not completely sure what type of executable it is but with CFF Explorer we can easily find out. So step one was identifying that you have a .Net application, step two will be to decompile the EXE. There are numerous tools out there that can decompile .Net applications. One of the more popular but paid tools is Reflector but an awesome free open source tool that I’ll be going over is ILSpy. So grab the GuessPassword.exe here and open it up in ILSpy. Keep in mind you’ll need to either have or install the .Net framework for all of this to work. Below is a screenshot of what GuessPassword.exe looks like in ILSpy.

ILSpy will automatically decompile the application, not all at once put as you go down into the tree of the application. So the screenshot above may not mean much to you if it’s your first time looking through a decompiled .Net application. There are a couple of things to keep in mind. One only focus on items within the tree of the application you are reviewing, in this case GuessPassword.

The items that I’ve marked as ignore are dependencies of GuessPassword.exe that ILSpy pulls in. Secondly you only really need to focus on the “pink bricks” inside of ILSpy. Most of the other components of the tree can be ignored as they’re simply tying up loose ends such as defining text boxes the “real” code lies in the pink bricks.

With this being said go ahead and load GuessPassword.exe into ILSpy and click on the first pink brink named “button1_Click(object, EventArgs): void”, you should see the following.

This is a very simple application and from the code above you can probably guess what happens. The application checks to see if the password entered into the text box is “monkey”, if it is the message “Correct” is presented if it isn’t then the message “Incorrect” will be seen. This is bad practice as you should never hard code passwords into your application but I wanted to show you what it would look like when you’re asking for input from the user. Go ahead and run GuessPassword.exe and give it a shot.

So this was fairly straight forward and you can see how easy it is to decompile, review code, reverse engineer, and determine ways to subvert the logic of the application. Even though this is considered straight forward the same concepts apply on all applications. At this point we could actually modify this compiled application and change the password “monkey” to anything we like or make it so that we don’t even need a password, more on that later.

Now it’s time to take our skills to the street. I randomly pulled down an application from download.com called SafeAsHouses. This application is a password safe that keeps all of your passwords in one place, or at least that’s the plan. Our goal is to reverse engineer this application so that we can subvert the authentication and glean all passwords. You can grab a copy of SafeAsHouses over at download.com but I’ve also saved a copy here in case it gets lost in the internets. If you grab it from download.com then the initial password = password and you can change it from there but my copy in the tools directory has the password of “monkey”. Next let’s throw SafeAsHouses into ILSpy and see what we get.

As you can see from the screenshot SafeAsHouses immediately shows some signs of obfuscation. In a normal situation the pink bricks will contain the name of the class used, in the case of GuessPassword.exe it’s “Form1” but SafeAsHouses is hiding this information. Let’s dig further and compare the decompilation of the first pink brick / class for both GuessPassword and SafeAsHouses, first GuessPassword.

Now SafeAsHouses.

Once again we see signs of obfuscation. Anywhere you see a gray box is a sign of obfuscation and this obfuscation technique is essentially hiding names within the code such as variable names. This won’t stop us but it does make the reversing process a little bit more difficult. So now you’ve successfully decompiled the application and see the signs of obfuscation, at this point you could start digging through code but it’s always to run the application to get a better understanding of what the application is doing.

So soon as you launch the application we see that it’s asking for a password, after typing in the correct password we’ll have access to all of our usernames and passwords. If we enter the incorrect password the application will show a message box saying “Password incorrect”.

So we’re trying to figure out how to get around the whole password authentication, that being said there are several areas we can focus on. The first is the fact that the application asks for input before allowing us full access into the application. The second is that the application will close if the input is incorrect. What strings can be seen during this process? Another thing to consider is the fact that the application presents you with one window for authentication then shows you a second window where your passwords are stored.  For each consideration you should ask yourself what would the code look like in a .Net application.

In the case of input it’s more than likely form input. In my simple GuessPassword.exe the code that takes is “this.textBox1.Text” where I provided the name textBox1 which is actually the default variable name give inside of Visual Studio. So in the application you’re trying to reverse you would need to look for a similar construct, this can be done manually or you can search through the decompiled code. Keep in mind when searching or viewing manually an obfuscated application you probably won’t see something similar to “this.Variable.Text”, at the very least an obfuscation tool will mangle “Variable” so keeping your eyes open for “this.something.Text” maybe your next best step.

So the application closes when an incorrect password is typed in, what does the code look like to close an application in .Net? For the most part the application will be closed with an Application.Exit or Environment.Exit so when you go to reverse the application those are the constructs you’ll need to keep in mind for when you search or manually review the decompiled code.

I mentioned “strings” earlier, one thing we notice when the application closes is “Password incorrect” and the title of the window is “ACCESS DENIED”. These strings have to be somewhere in the source code, they might be obfuscated but it’s definitely a good idea to search for them within the source code. If they aren’t in the source code then what other constructs generate these messages? If you decompile my GuessPassword.exe you’ll notice that my incorrect password message is “Incorrect” and that the title of the window is “Incorrect” but these are generated by MessageBox.Show so if the obfuscation tool hides the phrase “Incorrect” it may not hide the function “MessageBox.Show” so it’s just another thing to consider when trying to reverse a .Net application.

Last but not least is the fact that the application goes from one small window that takes your password to a second window that has all your passwords, how does the application do this and what does the code look like when this is performed in a .Net application? This can be handled in a number of different ways. Probably the most popular method is using the “window.Show” and “window.Hide” functions. Another option is using form opacity, form opacity is typically used to make a window more transparent but you could make the window completely transparent with this option as well. So when searching through code it’s a good idea to keep both of these functions in mind.

Now that I’ve laid out some things to consider now it’s time to put this to practice. For each consideration I’ve laid out you can manually look through the decompiled code for these constructs but ideally we’ll want to search for these constructs. At the time of this writing I’ve found a couple of ways to accomplish this. One is to decompile all the code of the application into a text file then search that text file with your favorite text editor. For this I prefer ILSpy to decompile into one text file then I can search inside that text file for any construct I like. First select the program you want to save into a file.

Next choose File > Save Code

Then save to a “single file”, you can save to a project but for searching through code I prefer one flat file.

Now that you have that single file you can open up your favorite text editor and search for any construct or item of interest. Go ahead and search for MessageBox.Show and see what hits you get.

So we see present a message box but these message boxes are all throughout the application so it’s hard to say that this is the functionality we’re looking for. Another thing to note is that the obfuscation is hiding what the message is with large negative numbers. Having all the code in one text file is helpful but it doesn’t put much context around what we’re trying to go after. Most developers don’t code inside one giant text file they usually develop inside an IDE such as Visual Studio which breaks up the code to help with contextual understanding. That being said whenever I’m looking at an application that can be decompiled I always save that decompiled code into text files so that I can search it at anytime for items of interest, IDE’s are nice but plain text rules.

Another great option to search for constructs is using the plugin CodeSearch for the .Net Reflector tool. What’s great about this tool is that if you’re already working inside Reflector or if Reflector is your favorite tool for assessing .Net applications then you have everything in one place. Let’s do the same messagebox.show search inside of the CodeSearch plugin. One thing you’ll need to keep in mind with the CodeSearch plugin is that it will only search through what you’ve clicked on in the left hand column. So if you want to search the entire tree of SafeAsHouses you’ll need to make sure you’re on the root of that application. Below you’ll see that Reflector tags SafeAsHouses as PasswordSafe, so first I clicked on PasswordSafe then performed my search in CodeSearch.

The nice thing about CodeSearch is that it will break down the results into the path were the results can be found. CodeSearch is case sensitive so that’s another thing you’ll need to keep in mind when performing searches. As you can see from the screenshot above we have quite a number of hits from “MessageBox.Show” this is probably because it’s a popular function to use in .Net applications. You can click through each result and it will take you to the location of where it found your search term, from there you’ll have to determine if that location has the functionality you’re looking for. Usually it’s best to search for all the relative constructs to get the best idea of where the functionality you’re looking for resides. For example you should also search for “this.*.Text” looking for form input, “Environment.Exit” when the application closes, “Opacity” “*.Hide” for hiding windows / forms, and “*.Show” for showing windows, etc. So it’s a good idea to search for all these terms as it relates to SafeAsHouses to find the code that actually does the authentication piece. In this case the search term “Opacity” does a really good job of narrowing down the location of the code we’re interested in.

So looking at the decompiled code in the top right column it appears that this is the authentication functionality we’ve been looking for in the SafeAsHouses application. Congratulations we found the functionality we’ve been searching for. It may not seem that obvious but let’s take a closer look, I prefer to use ILSpy in this case because it does a better job of showing the original code.

On line six the developer is assigning the variable to whatever you type into the password field, he’s then comparing that to the obfuscated value we see on line seven. If the password is correct you then enter the if statement, this is crucial you have to enter the if statement in order for the application to open / show you the passwords. I don’t completely understand the role of the opacity code but the code “base.Hide();” on line 17 hides the password window and the code “SO.Show” (where SO is the obfuscation) will show you the second window which contains all your passwords. Line 22 is the pop up message that tells you that your password is incorrect and line 23 closes the application because you entered the wrong password. So after looking at all the functionality in this section we can determine that this is definitely the section we need to focus on. Now we need to figure out how we can modify the code to bypass the authentication. The idea here is that someone has downloaded this application to their machine and use this application to store all their super secret passwords, what we want is to do is figure out all their passwords by modifying / patching the application. With a .Net application it’s fairly easy to modify to get your desired goal. There are a couple of tools that will allow us to modify a .Net application, GrayWolf and the Reflector plugin Reflexil. Both are great tools and must haves in your .Net reversing toolbox but for this demonstration I’ll stick to reflexil. I’m not going to discuss installing reflexil so please refer to the documentation on how to get that setup. Once the plugin is installed simply go to Tools > Reflexil inside of Reflector, you should see something similar to the screen shot below.

So the upper half of this screen shot is the authentication code we’ve identified for the SafeAsHouses application and the bottom half is reflexil. What reflexil shows you is the CIL (common intermediate language) often called IL for short. You can read through the wiki article that I’ve linked to but basically it’s the lower level language used by the .Net virtual machine. For example, you write your code in C Sharp, that code then gets converted to CIL. The CIL is ran through the virtual machine which got installed when you installed the .Net framework on your computer. It’s not important that you understand all the inner workings of the .Net framework all you really need to know is that if we want to modify a .Net application then having a general knowledge of CIL will come in handy. I wouldn’t try to completely understand CIL out of the box because it shouldn’t be too difficult to follow the CIL instructions and map them to the decompiled code. For instance we can compare lines 01, 02, 03 in the CIL to the decompiled code and piece together that System.Window.Forms.TextBox plus the other instructions are getting input from the user via a text box inside a windows form. This is also consistent with how the application behaves.

The next step is to use reflexil to modify the CIL then save those modifications. What we want to do is eliminate the need to provide a valid password, this can be accomplished a number of ways. You’ll notice in the CIL on line 07 there is a CIL instruction, “op_Equality”, that compares the user supplied password to the actual password associated with the application. You’ll notice on line 08 the OpCode instruction is “brfalse“, this essentially means that if the passwords don’t match (false) then go into that if clause which will pop up a message and the application will exit. You’ll also notice the operand for the brfalse opcode is “-> (36)”, this means branch to target on line 36 which jumps into the message box functionality. To get around providing the correct password we can simply change the condition from false to true that way if we provide the incorrect password it will open the application to whereas providing the correct password will cause the application to close. To change the CIL right click on brfalse and select edit.

Now change the opcode from brfalse to brtrue then click update.

Once you’ve modified the CIL instruction you’ll need to save your changes. To do this right click on the root of your application, then go to reflexil, then save as.

I typically stick with the *.Patched naming that way I don’t modify the original executable. After you’ve saved SaveAsHouses.Patched go ahead and double click on the application. It should work out that if you supply the incorrect password you’ll be authenticated but if you supply the correct password the application will close.

Congratulations, that’s it you’ve successfully reversed an obfuscated .Net application and modified the executable to subvert authentication. At this point you’ve accomplished your mission but you could have gone another route. Instead of changing the brfalse to brtrue we could have deleted all those instructions that way it doesn’t even check for the password. The code block below shows what can be deleted to achieve this functionality.

In order to delete this code within the application we’ll need to delete lines 1-28 within reflexil, you can do the usual select line one then while holding shift select line 28. After that right click and select delete then save the changes. Open your patched version of SafeAsHouses and type whatever you like into the password field, this can be the correct password or not it doesn’t matter. Congratulations you’ve accomplished another method to subvert functionality of a standalone .Net application. Just to prove we’ve removed that functionality of the application open up the patched version of SafeAsHouses in either Reflector or ILSpy, below is my screenshot that shows the removed code.

So there you have it, hopefully this explanation was helpful. I’ve been kind of hiding a secret Relfexil has an option called “Obfuscator search” which will automatically try and deobfuscate code. This tool actually works really well and it will deobfuscate SafeAsHouses for you automatically. Even though Reflexil can remove obfuscation on some applications it can’t do them all and even it could the concepts that I’ve covered still apply. So even if you have a deobfuscated application you’ll still need to identify certain constructs within the code to find the functionality you’re looking for.

I’m not here to bash on .Net it’s actually a great platform to quickly stand up applications but people need to be aware that it’s not incredibly difficult to reverse the application, tear it apart, and inject / subvert functionality. That’s all I got, if you see where I’ve made a mistake or left out some important information please let me know. Happy .Net hunting.