iSecPartners – Auditing high-value applications cheat-sheet

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

Google Chrome 35+ and EMET 4.1 Compatability

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.

 

PsExec now encrypts all communication

As of March 7, 2014, PsExec now encrypts all communication between systems, including any username/password info! This is great news.

http://blogs.technet.com/b/sysinternals/archive/2014/03/07/updates-process-explorer-v16-02-process-monitor-v3-1-psexec-v2-1-sigcheck-v2-03.aspx

PSExec v2.1: This update to PsExec, a command-line utility that enables you to execute programs on remote systems without preinstalling an agent, encrypts all communication between local and remote systems, including the transmission of command information such as the user name and password under which the remote program executes.

Avoid unsafe functions with Microsoft’s ‘banned.h’

banned.h is an import header file to include in your Windows C++ projects to help avoid introducing security flaws into your application.

The banned.h header file is a sanitizing resource that is designed to help developers avoid using and help identify and remove banned functions from code that may lead to vulnerabilities. Banned functions are those calls in code that have been deemed dangerous by making it relatively easy to introduce vulnerabilities into code during development.  For example, if a developer decided to use the strcpy function in his/her code, using banned.h in the same application will generate error(s) when its recompiled telling the developer that strcpy has been deprecated.  When the developer investigates why the error is being generated, they will likely figure out that strcpy has been replaced with a more secure version called strcpy_s, that makes it more difficult to make mistakes that lead to simple buffer overflows.

 

Simon Tatham: “The Descent to C”

The author of PuTTY has written an excellent primer on native code fundamentals for those coming from higher level languages (Perl, Python, Java, etc).

This article attempts to give a sort of ‘orientation tour’ for people whose previous programming background is in high (ish) level languages such as Java or Python, and who now find that they need or want to learn C.

My favorite part is this, under the section 10. So why is C like this, anyway?:

To a large extent, the answer is: C is that way because reality is that way. C is a low-level language, which means that the way things are done in C is very similar to the way they’re done by the computer itself.

If you were writing machine code, you’d find that most of the discussion above was just as true as it is in C: strings really are very difficult to handle efficiently (and high-level languages only hide that difficulty, they don’t remove it), pointer dereferences are always prone to that kind of problem if you don’t either code defensively or avoid making any mistakes, and so on.