Archive for the ‘MS Windows’ Category

ms12-020 mitigations

2012/03/16 Comments off

This week has been an interesting one for followers of the info-sec arena. On Tuesday Microsoft released a patch and security bulletin for MS12-020 for a critical flaw in remote desktop protocol, allowing for remote code execution without the need to authenticate to the target system first. Since the patch was released the good, the bad and the ugly of infosec have been attempting to reverse engineer the patch to develop a functional exploit; and over the last 24hrs PoC code has started to become publicly available.

As a result, the SANS Internet Storm Centre has raised their InfoCon threat level to Yellow. This is because weaponised versions of functional exploit code are expected over the coming days and weeks, with past experience making it likely that the exploit will be linked to worm capabilities for automated propagation.

So, the sky is falling right? Not as much as the furore would have you believe. Despite this does have the potential to become a well known, well exploited and long running bug; it is defensible with solid practices in play.

  1. Turn it off: If you don’t need RDP (or any port/service for that matter), turn it off. Reduces the attack vector against known or unknown weaknesses in the service
  2. Patch it: Microsoft released a patch of the weakness on Tuesday BEFORE exploit code was widely publicly available. You should be patching systems as standard operations; if you’re not, no would be a good time to catch up and remove the oversight.
  3. Limit access: If you can’t turn the service off because you need it, does it need to be available to world? If not restrict access to trusted source locations only via either perimeter or host based firewalling (or both). It doesn’t remove the threat completely, but it should severely reduce the risk if you’re not accepting connections from any machine on the internet. Only allowing access to the port via a VPN connection would also reduce the ability of a malicious source to connect to the service.
  4. (Bonus Point) Logging: Make sure you keep a close eye on your system logs; if you do get compromised, the damage could be limited if you can identify and respond to the breach promptly.

I’ve enjoyed watching the action this week, and the potential fallout has the potential to be more interesting still; but you should be able to prevent your systems from become part of a large statistic of low-hanging fruit with a few easy or common steps to securing your environment against the threat.

–Andrew Waite

Categories: Exploit, InfoSec, MS Windows

Direct Access at NEBytes

Tonight was the second NEBytes event, and after the launch event I was looking forward to it. Unfortunately the turn out wasn’t as good as the first event, 56 were registered but I only counted approximately 22 in the audience. The topic I was most interested in was a discussion of Microsoft’s Direct Access (DA), this was billed as an ‘evolution in remote access capabilities’. Being a security guy, obviously this piqued my interest.

Tonight’s speaker covering DA was Dr Dan Oliver, managing director at Sa-V. Before I start I want to state that I have/had no prior knowledge of DA, and my entire understanding comes from the presentation/sales-pitch by Dan tonight, if anyone with more knowledge once to point out any inaccuracies in my understanding or thoughts I’d more than welcome getting a better understanding of the technology.

DA is an ‘alternative’ to VPNs (discussed more later) for a Microsoft environment. The premise is that it provides seamless access to core resources whether a user is in the office or mobile. The requirements are fairly steep, and as Dan discussed on several occasions may be a stumbling block for an organisation to implement DA immediately. These are (some of) the requirements:

  • At least one Windows 2008 R2 server for AD and DNS services
  • A Certificate Authority
  • Recent, high-end client OS: Windows 7, Ultimate or Enterprise SKU only.
  • IPv6 capable clients (DA will work with IPv6 to IPv4 technologies)

As few organisations have a complete Win7 roll-out, and even less have the resources available to roll-out the higher end versions Dan was asked why the requirement. Answer: ‘Microsoft want to sell new versions, sorry’.

With DA pitched as an alternative to VPN at numerous points in the presentation the was a comparison between the two solutions, and to me the sales pitch for DA seemed schizophrenic. Dan kept switching between DA being an improvement to the current VPN solutions completely, and DA being suitable for access to lower priority services and data but organisation may prefer to remain with VPNs for more sensitive data. At this point I couldn’t help thinking ‘why add DA to the environment if you’re still going to have VPN technologies as well’. This was especially the case as Dan stated (and I can’t verify) that Microsoft do not intend to stop providing VPN functionality in their technologies.

From a usability and support perspective DA is recommended as it does not require additional authentication to create a secure connection to ‘internal’ services. Apparently having to provide an additional username/password (with RSA token/smartcard/etc.) needed to establish a VPN connection is beyond the capabilities of the average user.

One aspect that I did agree with (and if you listen to Exotic Liability you will be familiar with) is the concept of re-perimeterisation. The concept that the traditional perimeter of assets internal to a firewall is no longer relevent to protect resources in the modern environment, and that the modern perimeter is where data and users are, not tied to a particular geographical location or network segment. However, rather than the perimeter expending to encorporate any end user device that may access or store sensitive data, Dan claimed that DA would shrink the perimeter to only include the data centre, effectively no longer being concerned with the securityof the client system (be it desktop, laptop, etc.).

This point made me very concerned for the model of DA, if the client machine has seamless, always on access to ‘internal’ corporate services and systems I would be even more concerned for the security of the end user machine. If a virus/trojan/worm infects the system with the same access as the user account, then it too has seamless, always on access to the same internal services. I’m hoping this weakness is only my understanding of the technology, seems like a gaping whole in technology. If anyone can shed any light on this aspect of DA I’d appreciate some additional pointers to help clear up my understanding.

At this point I still can’t see an advantage to implementing DA over more established alternatives, my gut feeling is that DA will either become ubiquitous over the coming years or disappear without making an impact. Due to the fact it doesn’t play nice with the most widely implemented MS technologies, let alone ‘nix or OSX clients and the strict requiremented making a roll-out expensive I expect it to be the latter, but I’ve been wrong before.

At this point I decided to make a speedy exit from the event (after enjoying some rather good pizza) as the second event was dev based (Dynamic consumption in C# 4.0, Oliver Sturm) and I definitely fit in the ‘IT Pro’ camp of NEBytes audience.

Dispite my misgivings from the DA presentation I still enjoyed the event and look forward to the next. If you were at either of the events please let the organisers know your thoughts and ideas for future events by completing this (very) short survey. Thanks Guys.

— Andrew Waite

Categories: Event, MS Windows, Presentation

AV killing with powershell

2009/09/24 Comments off

A colleague recently introduced me to scripting with Powershell. After seeing a couple of examples of it’s strength for handling legitimate administration tasks my devious side came into play and I started imaging havok in my head.

As a starting project for getting to grips with Powershell basics I thought I’d try a proof of concept to replicate Meterpreter’s ability to disable AV and other defence mechanisms within the getcountermeasure function. I love meterpreter, but sometimes you need to work with more primitive native tools, as Powershell is starting to be included by default within Windows systems it is now one of the ‘primitive’ tools. My theory was that this should give me a bit of a challange, without jumping in at the deep end.

Well I was wrong, I guess showing the strength of Powershell this proved not to be a challange at all. The code below reads a list of unwanted processes from a text file, and kills the processes. All in four lines of code (I’m told this could be shortened at the expense of readability)

#read list of AV processes to kill
$avprocs = Get-Content AVprocs.txt

#kill all unwanted processes
foreach( $procname in $avprocs)
Stop-Process -name $procname

The next time you pop a Windows box don’t dispare, there’s more power available than just batch scripts 😀

Andrew Waite

P.S. Before anyone shouts about aiding skiddies, the above code could have some great legitimate uses as well; from automatically cleaning up infected systems to aiding productivity by adding doom.exe to the list of processes 😉

The possibilities are endless, both good and bad.

VMware, Win7 & VirtualXP

2009/07/22 Comments off

Very grateful to Timmedin for pointing me in the direction of his recent work with the same issue. In usual form, Tim has even packaged up a powershell script to automate the workaround. Check his fix here, much cleaner and slicker than my own. If your still curious, read on for the backstory.

Since rebuilding part of my toolkit I’ve had issues connecting to my ESXi host server. I had originally thought this was a result of an upgrade from ESXi 3.5 to ESXi 4.0, and the resultant change from VMWare infrastructure client to the new vSphere client. After several hours and days fighting down a blind alley I found a forum post that highlighted Windows 7 as the culprit.

Further reading indicated that this is a widespread issue with no real solution. Best workaround appears to be to run the client within a sandbox via Microsoft’s Virtual XP environment for Windows 7.

After a couple of false starts the install process was fairly straightforward, found here. Simply select hardware architecture (32/64-bit), install a patch, then finally the Virtual XP image. Everything beyond this works as expected, a virtual XP machine. Once in the virtual environment install the vSphere client as normal to regain access your VMWare environment.

vSphere via virtualXP

vSphere via virtualXP

Knowing my preferences, observant readers may be wondering why not achieve the same results using a VMWare guest with the vSphere client installed. VMWare Server is already installed on my machine, and was one of my initial thoughts. However, Virtual XP and VMWare utilise virtualisation for different results. The Virtual XP client has several intergration features (can be disabled if prefered) that allow simple, native access of resources on the host machine (files, directories, peripherals etc) from within the guest. This makes working with either, and between, host and guess seamless. Obviously such intergration would be unsuitable for a lab environment as you want/need isolation, seperation and protection from the guest machines so VMWare still has it’s place. As usual, using the right tool for the right job is essential.

At this point I’m back in my lab, and the R&D rolls on, but the experience has led me to look more indepth and Virtual PC. I have started building a BackTrack4 guest with Virtual PC to run within my standard machine for everyday use. Having access to a Linux environment as simply as a double-click as per normal applications will hopefully be a nice addition to my usual working practice.

<UPDATE> BT4 works fine, but the X GUI fails to start. Guess I’ll need to polish up on my commandline kung fu </UPDATE>

Andrew Waite

Categories: Lab, MS Windows, VMware

Random Malware Analysis

2009/05/22 1 comment

Having recently been left with several hours to kill with nothing but a laptop and my virtual lab I thought I’d try my hand at some rudimentary malware analysis. For a random live sample I selected the most recent submission to my Nepenthes Server.

$ tail -n1 /opt/nepenthes/var/log/logged_submissions
[2009-05-21T19:10:59] -> creceive:// 93715cfc2fbb07c0482c51e02809b937

To start with I wanted to get an idea of what I was dealing with, so I passed the file’s hash to VirusTotal’s Hash Search utility; and promptly found that VirusTotal had no knowledge of this particular hash. Means we could be dealing with a completely new malware strain or variant! or more likely a polymorphic binary creating a unique file signature…

The question was promptly answered when transferring the binary to my analysis machine by AVG, ‘Threat detected: worm/Allaple.b’. Not wanting to take the word of a single AV vendor I proceeded to upload the binary itself to VirusTotal (have I mentioned I like VirusTotal yet?). Sure enough most AV engines agree with AVG’s analysis although there was some dissention over which version of Allaple the sample was. Most AV engines (37/40) flagged file as malicious (Comodo, nProtect and PrevX gave the binary a clean bill of health.)

Beginning with some static analysis, the ‘strings’ utility is always a safe place to start. As I’m using a Windows platform for this analysis I use the SysInternals strings binary. This revealed little, other than confirming the binary is a windows executable (usual ‘!This program cannot be run in DOS mode.’ string) and a reference to Kernal32.dll and some function names (FindFirstVolumeW, GetShortPathNameA, GetConsoleAliasesLengthW, AddConsoleAliasA, GetModuleHandleW, CreateProcessA, GetUserDefaultUILanguage, LocalReAlloc, SetHandleInformation, SetConsoleCursorInfo).

As there was limited information available from a plaintext strings search my next step was to see if the binary had been packed. For this I used PEiD utility, PEiD initially stated that there was ‘Nothing Detected’ although the entropy found within the file (7.93) caused PEiD to suggest that the binary had indeed been packed.

With some basic static analysis undertaken (this could/should have been taken further but my RE/assembly-fu is a bit rusty, especially at 3am) I changed tact and went with some initial behavioural analysis. For an initial run I utilised iDefense’s SysAnalzer tool written by David Zimmer. SysAnalyzer is a great utility for automating behavioural analysis and capturing system changes, from it’s download page:

SysAnalyzer is an automated malcode run time analysis application that monitors various aspects of system and process states.
SysAnalyzer was designed to enable analysts to quickly build a comprehensive report as to the actions a binary takes on a system.

The tool snapshots (not to be confused with VM snapshots) the state of the system, runs a given binary, then snapshots the system after execution before comparing the two snapshots. This can provide some detailed, succinct information to an analyst, but may miss any dynamic and temporary system changes. One weakness (or strength, depending on your perspective) that SysAnalyzer has is that it does not sandbox the malicious binary from the analysis system. Meaning that if the binary is destructive it *will* hose the system it is being analysed on, obviously if you’re utilising virtualisation and snapshop functionality this shouldn’t be an issue.

On starting the analysis, the malicious executable promptly errored (usual Windows’ ‘executable has failed, please send all information to Microsoft’ type pop-up) and SysAnalysis stated that the system was unchanged by the binary. Well that was disappointing, possible some form of VM detection causing the malware to shut down?

Not to be denied, I re-ran the process: Again the executable crashed with Microsoft’s pop-up, but this time SysAnalysis saw some system changes, from API and registry calls to the creation of new processes. However on further analysis the new processes and files were all only related to the DWWIN.exe executable which, as explained here, is part of Windows itself and is the cause of the pop-ups discussed above.

One aspect that may be causing the binary to lock up is that it is isolated from the network. From experience some malware will perform an initial lookup to an external resource, if the code can’t access said resource the malware assumes it is on a closed system and shuts down. To test this theory I re-ran the executable (this time manually, without the SysAnalysis utility) with Wireshark sniffing all network interfaces. As expected the binary crashed with the same error pop-up, reviewing the wireshark capture no traffic was generated outbound to any resource from the infected host.

Another possible reason for malware to refuse to run is newer VM detection techniques. However no evidence of this is present in the API calls captured by SysAnalysis, nor can I find any reference to VM detection capabilities present within the Allaple family from a search of the web. Ideally to test this theory the malware would be executed on a natively installed OS to bypass any potential VM detection. Unfortunately at this stage I do not have resources available to sacrifice a physical machine in this manner, so analysis must stop here.

One final possibility is simply that the binary is defective, just because the malware is spreading does not necessarily mean that the payload delivered upon exploitation is fully functional. It is not uncommon to have one malware strain being propogated by an entirely different strain. This is rapidly becoming more prevelant as ‘cybercrime’ (I hate that phrase) matures with the recent emergence of crimeware-as-a-service.

What-ever the reason for the binary failing to have any perceivable impact on the system, the behaviour that has been observed during this sample’s execution does not match that which is expected from other analysis of the Allaple.b malware strain. Sophos’ analysis for example, states that upon infection Allabple.b will:

  • When first run W32/Allaple-B copies itself to [system]\urdvxc.exe.
  • The W32/Allaple-B is registered as a COM object.
  • W32/Allaple-B installs itself as a service with the name “MSWindows”.

No evidence of this behaviour has been seen during analysis, nor are any of the changes present on the system post infection. This is a good example of why there isn’t always a need to panic when AV picks up a malicious item. Until the infection has been analysed in more depth there is no way of knowing how scary the compromise and infection is.

Andrew Waite

Sec610 Reverse Engineering Malware Demo

2009/03/23 1 comment

I spent a very interesting hour with Lenny Zeltser (and others) around a week ago with a live demo of part of Lenny’s Sec610 course. For those interested in taking the course, or malware in general, then I’d suggest that if the demo is a representative sample of the course then you’re likely to really enjoy it. If you’re interested the webcast session was recorded; I’m not going to provide the link here as I do not know if it is intended for public consumption, but I’m sure if you contact SANS they’ll be able to hook you up.

I don’t want to give to much away but the demo session focused on reversing an unfamiliar binary that was a dummy MSN application for password harvesting. A lot of the overall tools and theory would have been fairly straightforward for anyone with knowledge in this area, basic RE tools (VMWare, OllyDbg & Wireshark etc.) were covered as related. The demo also focused on some more specialised and less well known (at least to me) tools. Mostly these were system monitoring utils and snapshot status gathering tools to get a better feel for what the malware was up to.

The main utilities that caught my attention were fakeDNS and MailPot, these tools are designed to fake standard systems to allow the malware to communicate with external sources in a safe environment. These come part of the Malcode Analysis Pack that is distributed by iDefense. Until this point I have been using fully blown (virtual) servers to run sandboxed DNS, SMTP, etc. services for malware anaylsis, I’m hoping these utilities should reduce the implementation time required for specific analysis, leaving more time and resources available to focus on the malware itself.

Andrew Waite

Windows Right-Click context menus

Whilst doing some research on reverse engineering I came across a useful tip on the Tipping Point MindshaRE blogs. The post details the (simple) steps required to add IDA Pro‘s disassembly to Window’s right-click context menu.

This is definitely simpler than I had expected it to be,although admittedly not something I had investigated before. Judging from the comments to that post the world and his dog already knows how to do this, but I didn’t so I thought I’d share in case anyone else finds this useful aswell. (And it will give me an easy place to find the information again should I forget 😉 )

Instructions, courtesy of Tipping Point:

  1. Open “regedit.exe”
  2. Open the key “HKEY_CLASSES_ROOT”
  3. Locate the file extension class you want.* (“dllfile” and “exefile”)
  4. Open the sub key “shell”, it the key does not exist create it
  5. Create a new key
  6. Give it the text label you want displayed when you right click the file type
  7. Create another key under the label and name it “command”
  8. Open the “(Default)” key under the newly created label key
  9. Add the path to your installation of IDA Pro’s idag.exe binary in double quotes followed by “%1”
  10. Repeat for any other file extensions you want
  11. Close “regedit.exe”

Edited Registry:

Right click in action:

Andrew Waite

Categories: Lab, MS Windows