The reason I’m in security today is because of the US Air Force’s Advanced Course in Engineering Cyber Security internship program. I turned down an internship at NASA (after I accepted it!) to attend this “information warfare bootcamp” in 2003.

The Air Force Research Lab modeled the ACE program after General Electric’s Advanced Course in Engineering. Each week, the program schedule looked like this:

The literature made the ACE program sound like a leadership development course for aspiring cyber security engineers. While this is true. The literature omitted how this leadership development happened.

The program format included one other key element:

Weekly–we were assigned a ‘real world’ problem by the person who provided the lecture. We were expected to solve this problem, deliver a solution, and provide a complete engineering report. These reports were 15-60 pages of writing… each week!

The ACE was a 10-week long course on technical writing. On top of delivering complete reports–we were also expected to follow a strict style guide. The guide took away passive voice, hidden verbs, complex phrases, gerunds, and other beautiful parts of the English language.

During the ACE program–we were taught a problem solving method. I use this method in my work today. If you think I’m productive–then consider this method my secret.

Here’s the method:

  1. State the problem
  2. Define assumptions
  3. Pick out Tools and Techniques
  4. Solve the problem
  5. Revisit the assumptions

Problem Statement

Let’s walk through this. My most recent output is Cobalt Strike’s browser pivoting capability. I started with a problem statement: how do I defeat two-factor authentication?

This problem statement is broad and that’s OK. When starting an effort it’s important to know the big picture idea behind it. Why am I doing this research? Why am I solving this problem?

The problem with broad problem statements is one could spend a lifetime trying to solve it for all possible cases. A key tenet of the ACE program is that a good enough solution on time is better than the perfect solution a week late. No one turned in a late paper during my class, but the understanding was, two late papers and you’re out of the program.

Background and Assumptions

The next step is to define assumptions. This step allows us to turn the broad problem into something tractable. When I set out to work on Browser Pivoting, I defined the following assumptions:

When I set out to work on the two-factor authentication problem–I had an idea for a solution. I wrote these assumptions to match this idea. That’s OK. A solution to the problem–even with constraints, represents progress.

Tools and Techniques

Step 3 is to explore tools and techniques. To work on browser pivoting–I took advantage of several technologies:

WinINet

WinINet is the Windows Internet API. It allows a program to interact with a URL with a few lines of code. It is also the communication layer for Internet Explorer. WinINet manages cookies, history, cache, authentication, and SSL sessions for applications that use it. Internet Explorer uses WinINet.

Reflective DLL Injection

Reflective DLL Injection is a technique to load a DLL into another process without touching disk. A Reflective DLL is a Windows DLL compiled with Stephen Fewer’s Reflective DLL Injection library.

The Metasploit Framework

The Metasploit Framework is a potential delivery platform for a two-factor authentication bypass capability. The Metasploit Framework has the ability to inject a Reflective DLL into an arbitrary process.

Solution

With these tools and techniques down–the next step is the solution. During this step, I’m expected to tie all elements together. In the case of Browser Pivoting I wrote an HTTP proxy server that fulfills requests with WinINet.

I compiled this HTTP proxy server as a reflective DLL and I use the Metasploit Framework to inject this DLL into memory.

WinINet manages session state on a per-process basis. When I inject my HTTP proxy server into an Internet Explorer process–I inherit the user’s cookies, session cookies, HTTP authenticated sessions, and client SSL certificates.

I am able to get past two-factor authentication because this solution inherits a user’s session tokens and credential material–after they’re authorized to access a web application.

At this point, I’ve solved the problem within the bounds of my assumptions.

Risk Analysis (Revisiting Assumptions)

The last step in the ACE method is the risk analysis. At this time, I revisit each assumption and I state how my solution falls apart when the assumption fails to hold. Thinking about these shortcomings is an opportunity to think about future work on the same problem.

In the case of Browser Pivoting:

  1. The target uses Internet Explorer. This solution will not work if the target uses another browser. Each browser has its own way to manage state and communicate.
  2. The attacker has control of the target’s system. This solution is suitable for the post-exploitation phase of an engagement. If an attacker can not gain access to a user’s system–another way to get around two-factor authentication is needed.
  3. I want to defeat two-factor authentication for web applications only. This concept may port to other applications–but it will require a thorough understanding of that application to do so.
  4. The attacker can wait for the target to interact with the web application of interest. This solution defeats two-factor authentication by riding on top of an authenticated session. Other ways to defeat two-factor authentication:
    • attack the web application of interest directly. Why use the user to get to it?
    • attack the two-factor authentication mechanism directly and see if there is a way to fool it.
    • create a social engineering website and try to fool the user into providing all information needed to authenticate as them.

That’s a run through the ACE problem solving method taught to Air Force cadets who went through the program. Sadly, the US Air Force decided to cancel the ACE program this year. This past summer would have made 11 years.

Clarification (21 Oct 13): In 2011, the US Air Force Institute of Technology (AFIT) took over the ACE program from the Air Force Research Lab. The AFIT ACE was cancelled in 2013. The Air Force Research Lab started an IA Internship Program that carries much of the ACE format in 2011. The IA Internship Program continues on as the spiritual successor of the ACE program.

源链接

Hacking more

...