iSecPartners has released on GitHub a “cheat-sheet” for auditing high-value applications. It’s well worth a read.
This list is intended to be a list of additional or more technical things to look for when auditing extremely high value applications. The applications may involve operational security for involved actors (such as law enforcement research), extremely valuable transactions (such as a Stock Trading Application), societal issues that could open users to physical harassment (such as a Gay Dating Application), or technologies designed to be used by journalists operating inside repressive countries.
It is an advanced list – meaning entry level issues such as application logic bypasses, common web vulnerabilities such as XSS and SQLi, or lower level vulnerabilities such as memory corruption are explicitly not covered. It is assumed that the reader is aware of these and similar vulnerabilities and is well trained in their search, exploitation, and remediation.
A good example of the type of analysis to strive for can be shown in Jacob Appelbaum’s analysis of UltraSurf:https://media.torproject.org/misc/2012-04-16-ultrasurf-analysis.pdf
From Trail of Bits, they are offering a free online CTF and penetration testing course. Lots of great material from a well respected organization.
Chromium engineers have provided excellent clarification on compatibility issues between Google Chrome v35+ and EMET 4.1
The specific issue we have encountered with Chromium compiled using VS 2013 relates to tail-call optimizations in wrapper functions for Windows APIs. By using jmp to enter the Windows API call from the wrapper, the Visual Studio compiler avoids an additional call/ret pair, and the API would return directly into the wrapper function’s caller rather than the wrapper function itself.
However, EMET protects various ‘critical’ Windows APIs against an exploit technique known as Return-Oriented Programming (ROP), and one of these protections is incompatible with tail-call optimization. EMET’s code checks that the return address from the API call is immediately preceded by a call to that API, since in ROP exploits this will typically not be the case but in normal function calls it will.
The tail-call optimization violates EMET’s assumption and causes a false positive result for exploit detection.
The Chrome security team does not generally recommend the use of EMET with Chromium because it has negative performance impact and adds little security benefit in most situations. The most effective anti-exploit techniques that EMET provides are already built into Chromium or superseded by stronger mitigations.
I read an informative IBM article about data alignment and its importance when developing native code.
Data alignment is an important issue for all programmers who directly use memory. Data alignment affects how well your software performs, and even if your software runs at all. As this article illustrates, understanding the nature of alignment can also explain some of the “weird” behaviors of some processors.
Delphi (my preferred native Windows programming language) supports the $CODEALIGN compiler directive , as well as another interesting custom alignment method. The Delphi code below sets 128 byte boundaries:
procedure TForm1.Button1Click(Sender: TObject); type TFFTData = array[0..63535] of double; PFFTData = ^TFFTData; var Buffer: pointer; FFTDataPtr: PFFTData; i: integer; const Alignment = 128; // needs to be power of 2 begin GetMem(Buffer, SizeOf(TFFTData) + Alignment); try FFTDataPtr := PFFTData((LongWord(Buffer) + Alignment - 1) and not (Alignment - 1)); // use data... for i := Low(TFFTData) to High(TFFTData) do FFTDataPtr[i] := i * pi; finally FreeMem(Buffer); end; end;
Microsoft Premier Field Engineers step through a technical deep dive on utilizing SysInternals tools. This course focuses on key administrative and diagnostic utilities and addresses key insights, and best practices.
Some very cool Python to perform in process patching and trampolines to hook Windows API’s.
UPDATED: 5/30/2013 to cover same flaw in EnSc.exe.
There is a reason that the RunAs program doesn’t accept credentials on the command line…because people would embed passwords. Microsoft developer Raymond Chen writes:
If this offends you and you want to be insecure and pass the password on the command line anyway (for everyone to see in the command window title bar), you can write your own program that calls the
Wingnut Software offers their commercial ‘Encrypted RunAs‘ application as a way for administrators to created encrypted shortcut commands that will launch applications with Administrative credentials. The selling point is that these credentials (which an administrator would provide when creating the shortcut) are protected in an encrypted command.
So I thought I’d download it and take a look at how it protects against the username and password being monitored and captured by a user with only standard USER rights. Note that I am *not* testing how well ERunAs encrypts the command…it appears to encrypt the command and credentials as strongly as advertised. However, I’m looking to see what happens after ERunAs decrypts everything and has to pass data to the operating system (and if I can capture that).
Spoiler, as a standard user I could monitor the parameters passed by ERunAs to the CreateProcessWithLogonW API and see the administrator’s username and password that were encrypted in the shortcut:
Encrypted RunAs is a small utility that is designed to make the job of Administrators a little easier, it can be used to run applications or software installations with access rights a standard user does not have.
I created an encrypted shortcut to run “notepad.exe” as the local administrator named “ALincoln” with a password of “Fubard123”.
Using the free API Monitor application, I was able to run it as a standard user (see below, I’m demonstrating I’m a standard user and that API Monitor is not elevated, but running with limited user rights), and I set a filter within API Monitor on the CreateProcessWithLogonW API.
From there I called ERunAs.exe, supplying the “Notepad.eras” file as it’s parameter (just like the shortcut does that Encrypted RunAs creates):
And seconds after clicking OK, I can see that the CreateProcessWithLogonW API was called by ERunAs.exe and I can see the parameters passed in clear text:
This means that if a standard user can access ERunAs.exe and the command it uses, the user can capture the administrative credentials used.
Now, I’ve been picking on 1 product so far, but I’ve confirmed this same method works to capture credentials from JoeWare’s CPAU, and Quimeras’ TqcRunas. I would expect this to work with any application that passes credentials to the CreateProcessWithLogonW API.
Based on feedback from a commenter, I also looked at EnSc (Encrypted Shortcut Creator). I found that using the same method as above, I can still capture the administrator’s credentials at the time the process is called. This can be done by a user without administrative rights…meaning any user that runs an EnSc created shortcut or has access to the shortcut, and the “ensc.db” file created by the program on first run (when master password is set).