|
Workstation 6.5 and ACE 2.5 beta are out and available for download. The most interesting feature added for me is the Support for Smart Cards and Smart Card Readers. Also an interesting new feature is the “Unity” that integrates applications on guest to be controlled from the host. Not sure at the moment how will it effect the debate on testing / debugging malware in a Virtual envrironment.
Vidalia is a cross-platform controller for Tor (The Onion Router) for network anonymity, built using the Qt toolkit. It allows the user to start, stop, and view the status of Tor, monitor bandwidth usage, view, filter, and search log messages, and configure some aspects of Tor.
The most feature of Vidalia is its Tor network map, which lets the user see the geographic location of servers on the Tor network, as well as where the user’s application traffic is going.
You can even dynamically change your paths (hops) and create a new identity for each connection.
Vidalia is released under the GPL. It runs on any platform supported by Qt 4.1, including Windows, Mac OS X, and Linux or other Unix-like variants using the X11 window system.
Blogged with Flock
The world celebrated the Software Freedom Day on 15th September 2007. We had some 100+ countries and more than 300 groups covering the free software world in different form of activities, presentations and events. The webmasters of FAST-NU Karachi also organized an event and talk series on the day and I felt really honored and delighted when I got an invitation to speak before the undergraduates of what open source is and how it is used in the industry.
I chose the topic “Open Source in the enterprise” picking up the best open source projects I use frequently and have known to be used as solid, industry standard applications in different domains. It was a wonderful experience going back to my university and meeting with a bunch of brilliant future computer scientists.
The slides of the presentation can be found here.
As VMWare 6 Goes into beta 3, the most awaited feature and a tester dream comes to reality. To capture, record and replay EVERYTHING that happens to a VM. This is not a movie recording, but more of a runtime execution and state recording. You can play back a recorded instance (say a list of scripts or operations) any time and many times you like.
The only think i dislike about it is the amount of space it takes (a gigabyte for every two minutes of recording), but again this feature is very experimental and one can hope a more cleaner solution in the coming builds.
chipx86 describes the feature and its usage as:
“What is this good for? Well, have you ever tried testing a program only to encounter a bug that you just can’t reproduce? Maybe there was some memory corruption that happened under some specific case that you just can’t seem to diagnose. Or maybe it’s a network packet that came in in some form that your application didn’t expect. Under normal circumstances, you’d have to do a lot of guesswork in order to find out what exactly happened. Far too often, it’s just too hard to reproduce the bug and it goes unfixed for some time.
Now imagine instead that you’re testing the program in Workstation and, before your testing, you hit Record. You attempt the test and the program crashes in some weird manner. No problem. Hit Stop and replay the recording. Just before the crash occurs, stop the playback and attach a debugger. Messed up? Didn’t find the cause? Replay that recording again.”
The new beta also shows a virtual battery for laptops showing the battery life :). Im also found the introduction of VNC for remote control.
happy virtualising.
Seems an interesting discussion.
http://forum.sysinternals.com/forum_posts.asp?TID=9630&TPN=1
They claim none of the present anti-rootkits have been able to detect it.
The Win32 or simply the Windows API allows developers to exploit the deep power of the Windows OS internals and use them in there applications. WinAPI (and Platform SDK) provides functional interfaces to communicate directly with the OS and make system calls including base OS services, control libs, GDI, shell, network services and numerous others. With the advent of DotNET & other recent platforms high level interfaces with objects and classes to talk to WinAPI has definitely made life easier. However for anyone who wants to dig in deep, theres more to WinAPI: Something that Microsoft hasn’t documented and is termed as the “NATIVE API”. With only a limited number of functions exposed in generally accessible publications, the obfuscation has lead to a general belief that the Native API can provide phenomenal powers, perhaps even allowing an application to bypass the security measures implemented by the standard WinAPI. The concerns mainly developed are because Microsoft is keeping the API for themselves to whom some term as an unfair advantage.
The Native API Architecture
The native API is somewhat similar to the system call interface on in the *nix and bsd world since it serves one purpose: a means for calling OS services located in kernel mode in a controlled manner. Kernel mode is where the core of NT executes, and where components have direct access to hardware and services that perform management of the system resources including memory, devices and processes. Thus, whenever a program executing in user mode wants to perform I/O, allocate or deallocate virtual memory, start a thread or process, or interact with global resources, it must call upon one or more services that live in kernel mode.
NTDLL.DLL
The Native API is provided to usermode programs by the NTDLL.DLL which besides containing Native API user-mode entry points, has process startup and module loading code in it. The majority of it, though, are the Native API stubs that transfer control to kernel mode. This is mainly achieved by executing a software exception.
The Native API Catalogue
There are about 240 Native APIs in Windows. Currently, the only documentation on Native APIs is located in the Windows Device Driver Kit (DDK) and the Windows Installable File System Kit (IFS Kit). The DDK actually describes the parameters and usage of a around 25 Native APIs, and includes prototype and parameter information for a few others in NTDDK.H. The IFS Kit documents about 25 more APIS only by providing prototypes in header files that come as part of the kit, and sometimes through their use in sample code. Most of APIs included in the IFS Kit are in the file I/O and security categories. You can find prototypes and some minimal documentation for many Native APIs in the book Windows NT/2000 Native API Reference.
Further reference and a detailed analyses on native api can be found on sysinternals and google.
Blogged with Flock.
One of the biggest challenges faced by programmers, architects, testers, and security consultants is to understand the consequences of their applications when deployed into production. Even with access to source code, it is difficult to understand everything that will occur during execution due to a variety of dependencies (for example. Different OS platforms, multiple patch levels, multiple groups contributing to code or leveraging external components).
The Microsoft Application Verifier is a runtime verification tool for unmanaged code that assists in quickly finding subtle programming errors that can be extremely difficult to identify with normal application testing. It is designed specifically to detect and help debug memory corruptions and critical security vulnerabilities. It makes it easier to create reliable applications and on the other hand find potential vulnerabilities by monitoring an application’s interaction with the OS, profiling its use of objects, the registry, the file system, and Win32 APIs (including heaps, handles, locks, and more). It also includes checks to predict how well the application will perform under Least-privileged User Account operation.
Application Verifier Identifies whether the applicaion:
• Is using:
Unsafe TerminateThread APIs.
Correct use of Thread Local Storage (TLS) APIs.
Correct use of virtual space manipulations (for example, VirtualAlloc, MapViewOfFile).
• Is hiding access violations using structured exception handling.
• Is attempting to use invalid handles.
• Contains memory corruptions or issues in the heap.
• Runs out of memory under low resources.
• Usage of critical sections is correctly occurring.
• Will run well in an environment with less privilege.
• Has any potential problems when the application is running as a limited user.
• Has uninitialized variables in future function calls in a thread’s context.
Tests within AppVerifier :
The tests included in the Application Verifier are to help software developers avoid common mistakes by using verification layers to validate the usage of API families:
• Basics Verification – These are the core set of tests that check for issues within heap, handles, locks, and more.
• Low Resource Simulation Verification – This test simulates an environment under low resources for example, out of memory.
• Limited User Account Predictor Verification – This test simulates an environment running as a user with a limited user account in either predictive or diagnostic mode and identifies potential problems accordingly.
• Miscellaneous Verification – This consists of two checks: Dirty Stacks and Dangerous APIs.
Getting and Installing Application Verifier:
The latest version of Microsoft Application Verifier can be downloaded from here . The installation is pretty simple and a straightforward next next.
Using the Application Verifier Tests:
The AppVerifier can be run through either the User Interface and / or automated through the command line. I will describe both these process in detail. The expectation for these scenarios is that the application does not break into debugger and all tests pass with the same pass rate as when run without AppVerifier enabled.
The Basic Tests:
1. Enable verifier for the application(s) you wish to test using:
From the command line: appverif /verify ApplicationToTest.exe or from the user interface:
Add your application by right-clicking within the Applications area and clicking Add Application. Select Basics from the Tests area and click Save.
Note:
• /verify enables the basic tests.
• If you are testing a DLL Application, AppVerifier has to be enabled for the test .exe that is exercising the DLL. You cannot debug a standalone DLL.
• Run the verification layers separately.
2. Run ALL your test exercising the application.
3. Analyze any debugger breakpoints encountered. If a break occurs, you need to understand why and fix it. (The Help contents provide details on the breaks and how to investigate them.)
Finally from the command line: appverif /n ApplicationToTest.exe or from the user interface:
Remove your application by right-clicking within the Applications area and clicking Delete Application and click the Save button.
The Low Resource Simulation and Fault Injection :
The expectation for this scenario is that the application does not break into the debugger. This means that you have no errors that need to be addressed. The pass rate for the tests may decrease significantly since random fault injections are introduced into the normal operation.
1. Enable Application Verifier low resource simulation (fault injection) for the application(s):
From the command line: Appverif /verify ApplicationToTest.exe /faults or from the user interface: Select Low Resource Simulation from the Tests area and click save.
Note: If you are testing a DLL, you can apply low resource simulation (fault injection) on a particular DLL instead of the whole process. The command line format would be:
appverif /verify TARGET [/faults [PROBABILITY [TIMEOUT [DLL …]]]]
Example: appverif /verify ApplicationToTest.exe /faults 5 1000 d3d9.dll
2. Run ALL your tests exercising the application.
3. When finished, delete all settings. Analyze any debugger break(s) encountered. If a break occurs, you will need to understand why and fix it.
4. When finished, delete all settings:
Running with and without fault injection exercises largely different code paths in an application and therefore both scenarios must be run in order to get the full benefit of AppVerifier.
Analyzing AppVerifier Data :
All data created during AppVerifier analysis is stored in the %ALLUSERSPROFILE%\AppVerifierLogs folder in a binary. These logs can then be converted to XML via the user interface or command line for further analysis. To view the XML files, use any: 1. Web Browser 2. Create an XSLT transformation to convert raw XML content 3. Import into Excel or any Database.
Some Key Points:
• AppVerifier is designed to test unmanaged applications (non-.NET Framework applications) on Microsoft (2000 and above) platforms.
• While running a full page heap, it is recommended to be at least 1 GB.
• It does not need access to the source code to execute its tests, although the availability of either the application’s symbols or debug information will make a dramatic difference in the quality and usefulness of the data collected.
How Does AppVerifier Work?
AppVerifier works by modifying the unmanaged DLLs Method Tables so that the required checks are performed before the real function is executed (“Function Hooking”). For example, the address of the Win32 API CreateFileA method is replaced with an internal AppVerifier method that will trigger a series of tests that when positive will be logged. When new processes are started, the use of AppVerifier’s Method Table Hooking techniques is controlled by entries made in specific registry keys. If the registry entry exists, then the AppVerifier DLL will be loaded in a newly created process that will handle the Method Table replacements in the existent and subsequently loaded DLLs. Since these hooks are made when the DLL is loaded, it is not possible to use AppVerifier on a process that is already running.
When a problem is identified a verifier stop will occur. The number provided is used to identify the exact nature and reason for its occurrence.
Detecting Heap Corruptions:
In order to detect heap corruptions (overflows or underflows), AppVerifier will modify the way memory is allocated by padding the requested memory with either full non-writable pages or with special tags before and after the allocated memory.
When padding the requested memory with full non-writable pages, AppVerifier will consume a large amount of virtual memory but has the advantage that heap corruption events are cached in real time when the overflow or underflow occurs. The heap check will place a guard page at the beginning or end of allocation depending on the Backward property. If Backward is set to False, which is the default, it will place a guard page at the end of the allocation to catch buffer overruns. If it is set to True, the guard page is placed at the beginning of the allocation to catch buffer underruns.
When padding the requested memory with special tags (enabled by clearing the “Full” check box item in the heap properties), AppVerifier will check and alert you when this memory is released. The main problem in using this technique is that there are some cases when the memory corruption will only be detected when the memory is released (the minimum amount of memory block is 8 bytes), so when on a 3-byte variable or a 5-byte overflow occurs it will not be immediately detected.
On an underflow event, an attempt will be made to write to a Read-Only page. This will trigger an exception. This exception is only be caught if the target application is being executed under a debugger. Note that the full page heap mode will also detect these errors as it uses padding + guard pages. The reason you would use light page heap is if your machine cannot tolerate the high memory constraints of full page heap.
For memory intensive applications, or when it is required to use AppVerifier during long periods of time (e.g. stress testing), it is better to run normal (light) heap tests instead of full mode due to the performance degradation. However, when you run into an issue turn on full page heap to investigate further.
References and Further Reading :
MSDN, Microsoft Application Verifier Help.
Function Hooking and Patching Articles: Detours
From Code Project: API hooking revealed – Process-wide API spying – an ultimate hack
The Files used for reference can be downloaded from here.
Offensive Computing just released their presentation slides, videos and sample codes from their Defcon 14 talk. There paper Further Down the VM Spiral discusses several new tools and describes some new VM detection techniques including a generic virtual machine detector. This VM detector tries a
variety of methods including the new machine status word (MSW) method which allows you to generically detect virtual machines regardless
of whether acceleration is enabled . More information can be found here: Hacking Malware: Offense is the new Defense
Blogged with Flock
An excellent resource for security research tools:
http://research.eeye.com/html/tools/
Blogged with Flock
Did you ever had a need to know whether your Windows system is sniffing network traffic off the network without your knowledge?
This type of passive attack can be very difficult to detect. There are numerous third party tools that try to detect network sniffers running on the network by looking for signs of systems with network interfaces running in promiscuous mode. Since many of these tools use network-based detection techniques that rely on bugs in operating systems and/or specific sniffer behavior, they can generate false positive and false negative results.
Microsoft has released a tool that can detect managed Windows systems that have network interfaces running in promiscuous mode – a key indicator that a network sniffer is running on the system. It uses a host based detection technique instead of a network based detection technique to make it as accurate as possible.
Functionality:
Additionally, the tools have the following limitations:
You can get both Promqry from:
Blogged with Flock
