I look this up about every couple weeks, so I’m posting it here for posterity. In order to nicely format Data::Dumper output…
I almost always set
$Data::Dumper::Indent = 1;
$Data::Dumper::Sortkeys = 1;
Data::Dumper. The first statement makes the output more compact and much more readable when your data structure is several levels deep. The second statement makes it easier to scan the output and quickly find the keys you are most interested in.
If the data structure contains binary data or embedded tabs/newlines, also consider
$Data::Dumper::Useqq = 1;
which will output a suitable readable representation for that data.
Much more in the perldoc.
x64_dbg is a very powerful open-source 32 and 64-bit assembler/debugger for Windows. The UI is reminiscent of OllyDbg with some additions that are clearly inspired by IDA Pro.
I’m looking forward to using this tool in place of OllyDbg, especially for 64-bit related RE tasks.
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.
As of March 7, 2014, PsExec now encrypts all communication between systems, including any username/password info! This is great news.
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.
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.