osascript: for local phishing

Lately I've been finding myself on victim's laptops and they have all been OSX. I found that instead of key-logging I could simply prompt the end user for whatever password I needed using applescript.

The way we do this is with osascript, Apples built in executor for applescript and other OSA (Open Scripting Architecture) languages. Applescript provides a convenient way to interact with GUI elements within OSX so this little trick is likely only scratching the surface of what is possible. 

So straight to it, the command i'm using to do this looks like this:

osascript -e 'tell app "System Preferences" to activate' -e 'tell app "System Preferences" to activate' -e 'tell app "System Preferences" to display dialog "Software Update requires that you type your password to apply changes." & return & return  default answer "" with icon 1 with hidden answer with title "Software Update"'

And now, even though it reads like english pretty much, let's break it down.

osascript -e :  

We start off calling osascript which allows us to run apple script from the command line. -e is, you guessed it, 'execute'. Useful to note at this point that you can separate multiple lines with additional -e commands since it isn't always possible to write a giant one liner to do what you need. osascript will continue executing in the same context and remember variables across multiple "-e" statements. This could be very useful if you wanted to actually validate the users password to make sure they didn't fat finger it. 

'tell app "System Preferences" to activate' :  

Just like it reads here you can "tell" applications to do things. In this case we are telling System Preferences to activate, which will launch the application if needed and bring it to the foreground. 

-e 'tell app "System Preferences" to activate' : 

So yes this is the exact same command. What happens with some applications, System Preferences being one of them, is that they background immediately when trying to launch a dialog from them. I don't know why and frankly I don't care. What I do know is that telling it to activate twice ensures that the application stays in front and your malicious prompt is right there for the victim to see. Dog Science. 

-e 'tell app "System Preferences" to display dialog "Software Update requires that you type your password to apply changes." & return & return  default answer "" 

Here we have the bulk of the text. This basically creates the dialog box ands adds the text of our choosing. Sadly there is no formatting here. So we aren't able to fully recreate the bold text of the real Software Update prompt. 

with icon 1: 

 This tells the application to use its own default icon. Although, there are a few options for your specific needs.

with icon 0: 

with icon 1: 

with icon 2: 

with hidden answer with title "Software Update"'

This last little bit says the text the user types in should be hidden and that the title of the dialog box should be "Software Update". There are a lot more options such as customization of the buttons or removing the cancel button and all of this is position independent. 

You can read the full documentation here.

At this point you can run the command to throw the dialog. 

A few important notes:

The osascript command will timeout after 2 minutes of sitting on screen. This isn't an issue as the window will disappear when the apple event times out. 

However, if you ctrl-c your running osascript the dialog box will remain and if a user types their password in you will not see it. Running our script again after doing this will leave two of these dialogs on the screen (not very stealthy). 

Otherwise whatever is typed into the dialog box, or other actions such as hitting cancel or escape will be displayed back to your terminal.

I have a bit of code to generate osascript commands for myself quickly on the fly which you can grab here: https://github.com/fuzzynop/FiveOnceInYourLife

Happy hacking. 

-FuzzyNop

Making IDA Pretty, Pretty Quickly

Hello World,


Lately I've been spending more and more time staring at IDA Pro and have found the default color scheme somewhat lacking. I have also noticed that upon startup I am consistently setting a number of settings and running a script to colorize my disassembly. I had a little bit of trouble finding everything in one place, so I decided to write up a quick guide.

Changing Colors:

First off, changing colors in IDA is fairly straight forward. Go to "Options" -> "Colors". Most of the colors that you care about are in the first tab. I recommend resizing the window out so you can see everything at once. Additionally, I have noticed that you must click the element within the example view to edit its color, selecting from the drop down was simply not working while I was writing this up.

The four buttons under "Background Colors" may not be initially obvious.

• Disassembly - the background color of the blocks in graph view
• Selection - the highlight color when clicking and dragging to highlight text, ie. when you copy and paste
• Highlight - the highlight color for items matching the currently selected element, ie. clicking on a register
• Hint - the background color of the popup view when hovering over elements, ie. hovering over a jump

You will probably also want to visit the "Graph" tab as that is where the Main Background, Edge, and Node colors options are.

Exporting and Importing with Color Schemes:

First I know IDA 6.4 finally added this as a feature and doesn't require registry editing.

In short, Run -> Regedit -> HKCU -> Software -> Hex-Rays -> IDA, right click. Export.

Once you have saved registry key somewhere double clicking the .reg file will apply the changes.

*Note* this also will copy the history and license information contained within the sub-keys so you may want to delete those if you are sharing it. 

This is actually pretty well documented here along with the rather nice color scheme called "Consonance".

I am also making my color scheme available here.

It is a dark theme consisting of purples, green, orange, and gray.  

Highlighting Scripts:

You may have also noticed that lines that contain a call instruction are highlighed in my disassembly graph. This is accomplished with an IDA Python script similar to the one referenced in Practical Malware Analysis, available and explained here. For those of you who don't have IDA Pro, there is an IDC version of the original script here.

Making Scripts run when IDA Starts:

Unfortunately, I was having a hard time finding out exactly how to make it so that IDA would run this script on every binary I loaded. I found an interesting lead in Hex Rays Documentation that mentioned a "-S####" command line switch. Using this I came up with a quick solution that has been working well for me. 

*Note* Seems like this only works with IDA Python. So if you are using IDA Free this is probably not going to work.

Changes Made to ColorIDA.py:

So, ColorIDA.py uses the ScreenEA() function to specify start and end addresses for the location in which the script should loop through. Sadly this does not seem to work with auto started scripts. My work around was incredibly simple, "heads = Heads(0, 0xFFFFFFFF)". This may slow down things down, but I haven't noticed any negative side effects. 

The script now works with the -S option. I made some tweaks for readability and editied the colors so they work with my color scheme and I have made my version available here.

Adding Auto Start Scripts to Your Work Flow:

The best way that I have found to accomplish this is adding a right-click context menu item configured to load the script also.

Simply add an entry into HKEY_CLASSES_ROOT\*\shell\<NAME OF CONTEXT ITEM>

Then create a subkey called command and set the Default of this registry key to:
<PATH TO IDA> -S<PATH TO SCRIPT> %1

*Note* There is no space between -S and the path to the script. 

My Setup for example

If you set it up the same as me you should now be able to right-click a binary and select "Open With IDA32" and BAM, script runs automagically.

I also have a quick youtube video showing this setup.

This has saved me a ton of time and I hope it helps you out too.

Find Downloads Here:
https://code.google.com/p/making-malware-go-backwards/downloads/list

Pass the Hash without Metasploit

Problem:

Recently I found the need to pass the hash without using Metasploit's psexec module. Ok, no problem, Google Fu engage..

At least one article mentioned that psexec could pass the hash by throwing the hash after the "-p" argument.

psexec does NOT pass the hash by itself.

Here is how to do it.

Scenario: 


First, get Windows Credential Editor version 1.3 is the newest at the time of this writing. WCE is a tool that can dump clear text passwords from memory or allow you to perform pass the hash attacks.


This quick tutorial assumes that you are leveraging a local administrator account that has the same password on multiple machines in an environment. (pretty common).

First dump password hashes. There are a lot of tools to do this if the Administrator is logged on wce will work, just run wce.exe. If not you can try fgdump. Either way .. get hashes.

Here you can see the local Administrator on the machine MILTON-PC, along with the LM and NTLM hashes.

*Note* if you use "wce -w" depending on the contents of memory you may just dump plain text passwords.

But this isn't about that....

You can use "wce -s" to change your credentials in memory. Passing the hash to another system becomes a matter of changing your credentials to that system. You can then use psexec, or other commands and the remote system will not challenge your authority to do so.

The remote system I will be "passing the hash" to is PeterGibbons-pc, so in my example I just switch "MILTON-PC" with "PETERGIBBONS-PC" and that is that. (this works because the Local administrator accounts have the same password, if they are different, this will be a big fail)

A good step would be to map the administrative share so that psexec has it available when it needs it. If this works you are in business.

Some reasons this may fail:

• Windows Firewall Rules are set to disallow Remote Administration
• This is going to be default if your lab includes fresh windows VM's, just disable the firewall.
• The Local Account hashes are not the same
• dump the hashes on both systems to check if they are the same, if they are different , you're going to have a bad time.
• Your domain is wrong.
• fix it.

Now you can finally use psexec and have a remote shell, or upload whatever you want using the "-c" flag.

IDA Pro Book Chapter Two! TOOL TIME!

BTW, I'm not about to retype this whole IDA book (obviously), so you should definitely buy it if you have not already.

I am on chapter 2 and this chapter is all about TOOLS. Below is a list and a few points on the tools mentioned in this chapter. I learned about a few new tidbits like magic numbers and name mangling and what tools are the best for what situation.

• FILE
• included in all linux like OS's (this includes osx btw, and CYGWIN for Windows)
• tries to guess at the file's type
• uses magic numbers (certain bit patterns that are standard to certain files)
• usage - 'file filename'
• PE Tools
• Windows based
• collection of tools
• can analyze files on disk or running process
• usage - GUI
• Link cited in book is gone, found it available here http://uinc.ru/files/neox/PE_Tools.shtml
• PEiD
• Windows based 
• identifies entry point
• Compiler and/or Packers used
• usage - open a binary file in PEiD gui
• http://peid.info
• NM
• available in linux (includes OSX)
• lists symbols from object files
• basically lists function and variable names
• 'man nm' has more
• usage 'nm filename'
• LDD
• linux type operating systems (does NOT include OSX, see next tool)
• stands for list dynamically dependencies
• works on dynamically linked binaries (see below for what this means)
• usage 'ldd filname'
• objdump
• runs on linux and cygwin(not OSX)
• dumps out LDD information and way more
• very flexible, with lots of command line options
• Includes: headers, debugging info, symbol info, disassembly listing (dead listing)
• usage objdump filename
• otool
• runs on OSX
• similar to objdump but for OSX Mach-O binaries
• displays dynamically linked dependencies like ldd with the -L switch
• run otool with no arguments for a list of all switches
• dumpbin
• runs on Windows, is included in Visual Studio
• can extract lots of info from PE files, including: symbols, imported function names, exported function names, and disassembly listing 
• output is usually pretty, IMO
• usage dumpbin /dependents filename.exe --lists dependencies similar to ldd. 
• c++filt
• runs on linux (was native on OSX too) 
• addresses mangled name problem, (see special note below)
• treats input as a mangled name and returns more usefull function information
• usage pipe nm output to c++filt. ie. nm filename | grep functionname | c++filt
• strings
• runs on linux, osx, cygwin (also an .exe windows version out there somewhere too)
• simply returns any string data in any file
• useful for getting a quick idea of a file, but can contain loads of garbage data
• usage strings filename
• to scan the complete binary (not just initialized sections) use the -a switch
• use -t to get the hex offset of the string locations
• use -e for Unicode strings 

Special note on magic numbers

• 0xCA FE BA BE is standard for all Java .class files
• 0x4D 5A ascii MZ is standard for all Windows PE Executables
• 0xFF D8 at the beginning, then 0x4A 46 49 46 ascii JFIF is standard in all JPEG files

Special note on Dynamic and Static Linking:

• Static linking puts copies of all the required libraries into the file. 
• PRO - functions calls are faster and you don't need the libraries on your system
• CON - binary is larger and difficulty upgrading the software when components change
• Dynamic is the opposite. Library files are specified in the binary and loaded in at run time 
• Dynamic linking is the default
• You can specify static linking in gcc with the --static switch

Special note on Function Overloading and Name Mangling:

• When you overload a function, that is, have multiple functions with the same names that perform different tasks based on the number or type of arguments given, the compiler has to handle this in a unique way. It assigns random names to each function in a not that really random way. More on name mangling can be found at wikipedia! 

That is it for chapter 2. I should also mention that if you are having trouble getting through a book. Blogging your notes like I am doing right now is an awesome motivator and keeps your mind entertained and engaged. You may cover the material more slowly, but retention is greatly increased.

Best of luck world.

Reading: The IDA Pro Book, Posting: My Notes

For the few that may stumble across my blog. This is an exercise in public note taking. It helps me by keeping me accountable (I have about a dozen half read books now), and helps others by sharing some quick info. 

I do suggest that you pick up this book if you are interested in:

• Hacking (yeah that general, IDA is very widely used)
• Exploit development
• Reverse engineering
• Being better at CTF's
• Look... chances are if you're reading this, you know this already.

*****BEGIN NOTES*******

Chapter 1

• Disassembly - "undoes assembly process" 
• 0's and 1's as input, assembly language as output
• Decompilers - "attempts to give higher level language"
• assembly language as input high level code as output
• Compilation is Lossy 
• no variable names
• no function names
• no type declarations (explicitly)
• Decompilers
• hardly ever get it 100% right
• are dependent on the language 
• are dependent on OS, ie. Windows API
• Hex-Rays is the best on the market, more on that later...
• Uses for Disassembly
• Malware Analysis
• Vulnerability Analysis
• Software Interoperability
• ie. Reverse engineer legacy software to write wrappers for integration with modern app
• Compiler Validation
• Debugging
• X86 Assembly Syntax: AT&T vs INTEL
• AT&T syntax
•  has % in front of all register names (%EIP , %EBP, %EAX, ..etc.)
• the $ sign is in front of all literal constants aka immediate operands 
• source is on left, destination on right
• ie add $0x4, %eax  -- adds 4 to the value in eax storing the result in eax
• INTEL syntax
• no % or $
• destination on left, source on right
• ie add eax, 0x4 --adds 4 to the value in eax storing hte result in eax
• Personal note:
• in GDB (Gnu Debugger, available in linux) you can type "set disassembly-flavor intel" or "set disassembly-flavor att" to set the style of disassembled code. the default is ATT irrc..
• Types of Instructions
• Sequential flow
• command is executed then moves onto the next 
• Conditional Branching 
• two possible paths
• like an if statement 
• unconditional branching
• always jumps to another area of code
• like the bottom of a while loop
• Function calls
• always goes but onces a return command is hit comes back to where it left off

Thats all for chapter 1, the material was light and pretty obvious for anyone familiar with assembly language.

For the purpose of getting familiar with assembly language, I recommend Security Tube's linux assembly language megaprimer.

 

Next time, chapter 2.

Last week's presentation

http://vimeo.com/29355597

Tonight, Google Hacking!

USCC Again

There is a new US Cyber Challenge Open.

Available at http://uscc.cyberquests.org/

This challenge focuses heavily on Web App Security, you will need to identify attack signatures and be comfortable with using Wireshark.

Read These:
https://www.owasp.org/index.php/Top_10_2007
http://en.wikipedia.org/wiki/Cross-site_scripting
http://en.wikipedia.org/wiki/Cross-site_request_forgery
http://en.wikipedia.org/wiki/SQL_injection
https://www.owasp.org/index.php/Top_10_2007-Insecure_Direct_Object_Reference
http://en.wikipedia.org/wiki/Remote_file_inclusion

CEH Exam

Scheduled CEH Exam for Sept 13th, Taking version 6 since it is cheaper. Also got the 100 dollar application fee waived.

Google Code Lab

CISSP Access Control

So, Like I said, Here are the main points from the first chapter.

Types of Access Control
-Preventive
-Deterrent
-Detective
-Corrective
-Recovery
-Compensating
-Directive

Implementations Areas of Access Controls
-Administrative
-Logical/Technical
-Physical

Biometric Acronyms
Too Sensitive = Type 1 Error
Ratio of Type 1 errors to valid authentications is the
False Rejection Rate (FRR)

Not Sensitive Enough = Type 2 Error
When someone who shouldn't get authenticated did, 
This ratio is the False Acceptance Rate (FAR)

When the FRR == FAR you get the  Cross Over Error Rate (CER)
Lower CER is Better

Authentication Factors
Type 1 - Something you Know
Type 2 - Something you Have(Includes somewhere you are)
Type 3 - Something you Are (includes something you do)

Type 1 is least secure, Type 3 is most secure.
To be effective, Multifactor Authentication needs to contain authentication factors from more than 1 type.

Access Control(AC) Techniques
-How subjects can interact with objects

DiscretionaryAC, - user defines access
NonDiscretionaryAC, - rule based, like a Firewall
MandatoryAC, - think of gov't clearance levels
RoleBasedAC, - assigned by job duty
TaskBasedAC - assigned by tasks you can perform


Know Centralized vs Decentralized
Centralized:
RADIUS = Remote authentication dial in user service
TACAS = Terminal access controller access control system
Single Sign On - easy for users and administrators, but single point of failure for security
Directory Services - LDAP ..Active Directory, manages resources
Security Domain  - is a set of resources that administer a single security policy.
Thin Clients