Video: Coding WebInspect in real-time to Inject Fortify Plugin Views

Here is a detailed video that shows the multiple steps required to inject windows originally hosted in Eclipse (Java process) into WebInspect (.NET process).

Of course that this workflow could be automated using a script, but I hope that the video below helps to explain how it is actually works, and how windows are hijacked from one process into another:

Injecting Fortify Eclipse Plug-in Views into Notepad and WebInspect (and key difference between Fortify content and TeamMentor content)

Following from Opening up a native Chrome Browser window inside Eclipse (raw version) and Injecting HP Fortify Eclipse Plug-in Views into HP’s WebInspect UI  here are a couple more examples of how to reuse Fortify Eclipse Plug-in Views into other processes.

Example 1: WebInspect with Fortify and TeamMentor (inside Chrome)

Injecting HP Fortify Eclipse Plug-in Views into HP’s WebInspect UI

Using the O2’s Win32 Window Hijacking capabilities (see also Opening up a native Chrome Browser window inside Eclipse (raw version)) , here is a PoC on how to inject a couple Eclipse Views from the HP Fortify Eclipse plug-in (which is Java app running under an JVM) into the HP WebInspect UI (which is .NET app running under an CLR).

The power of this PoC is to show that we can have the best of both worlds and show security consultants and developers the best possible environment/UI for them to analyze, review and fix security vulnerabilities.

Opening up a native Chrome Browser window inside Eclipse (raw version)

On the Win32 Window’s Hijack theme, here is a raw version of how to show an actual Chrome browser window inside an Eclipse view (ie. a window from a C++ process inside a JVM-based Process).

Using the Groovy execution capabilities described in the Programming Eclipse in Real-Time (using an 'Groovy based' Eclipse Plug-in) post, in Eclipse, I start by creating an instance of a SWT panel and get its handle:

Writing REPL scripts on side-by-side Chrome and IE

Following the Chrome-Hijacking posts, I’m starting to convert the WatiN Extension methods into ChromeDriver, and to do so needed to execute requests side-by-side (to test the APIs and to be able to write UnitTests for them).

To do that (side-by-side Chrome and IE execution) I wrote this script:

PoC of Auto-Screenshot of Hijacked Notepad main Window

On the topic of Window-Hijacking, here is a PoC that:

• creates a GUI with two Panels (left and right)
• starts a new notepad process
• hijacks its main window into the left panel
• takes a screenshot of a captured Nodepad window every 100ms
• checks if the screenshot is different from the last one, and if it is:
• shows the screenshot of the hijacked notepad window into the right panel (inside a PictureBox)

Here is the code:

Using WebStorm with Chrome and ChromeDriver (to view KarmaJS execution results)

Following from the example described inWhen the best way to automate Chrome is to use ... Chrome ,  here is a more practical scenario where I’m creating a GUI that has both WebStorm and Chrome running side-by-side

Here is what it looks like:

When the best way to automate Chrome is to use ... Chrome (with examples on Google search, direct AngularJS scope manipulation and ChromeDriver javascript access)

On the topic of Web Automation, I always wanted to have a REPL environment for Chrome like I have for IE (using Watin).

In the past I have explored multiple solutions, for example the use of CefSharp (see here and here). But that was never the real thing, and there was always a couple issues (caused by the fact that the ‘real’ chrome wasn't being used).

For a while, in the back on my mind the solution was simple and obvious: Use the real Chrome process in a way that it can be programmatically accessed from an O2’s C# repl environment!

Well, the good news is that is exactly what I have done :)

I just created the Gui you can see below, which uses the Window-Hikacking technique to inject an (Selenium's ChromeDriver started) Chrome process' window in a Panel, and pass its reference (as a variable) to an O2 REPL environment.

Adding KarmaJS support to WebStorm to automagically run tests on file changes (and test UI with SublimeText, Chrome and Cmd.exe)

On the AngularJs and KarmaJS theme (see A small AngularJS Jasmine test executed by KarmaJS and the related posts linked at the bottom), here is my first attempt at using Karma to test AngularJS code inside TeamMentor.

I’m using WebStorm instead of VisualStudio, since for Javascript coding WebStorm is MUCH better/faster/cleverer, specially since it has good support for AngularJs and Jasmine (with KarmaJS support easily added, as we are about to see).

Also shown below is a cool tool I created that hijacks windows from SublimeText, Chrome and Cmd.exe windows into the same UI (an O2 Platform .NET Script)

Here is the directory structure:

Using Chrome inside a native VisualStudio pane (using Window Handle Hijacking)

To help me debug and visualize an AngularJS page I was developing, I used the O2’s Window Handle Hijack technique to insert an Chrome window inside VisualStudio 2010.

Here it is in action:

GUI with WebStorm and JsTestDriver controlling 3 Hijacked Browser windows (Chrome, Firefox and IE)

Following from PoC - Selenium - Gui with 3 Hijacked Browser Windows and  Running JavaScript TestCase Unit Tests using JsTestDriver (in WebStorm)  here is a similar PoC, now with JsTestDriver controlling 3 Browsers in the same GUI:

PoC - Selenium - Gui with 3 Hijacked Browser Windows.h2

While working on TeamMentor’s browser automation using Selenium, I created a pretty cool PoC/Script where I was able to show natively the 3 main browsers (IE, Firefox and Chrome) in the same Application/GUI.

The O2 Platform script is called PoC - Selenium - Gui with 3 Hijacked Browser Windows.h2, and this is what it looks like when opened up:

IBM AppScan Standard, Source and VisualStudio (in the same GUI/App)

Here are some cool screenshots sent to me by an O2 user, that used the technique shown in Using a .Net/CLR, a Java/JVM and a C++ Window in another process (to show consolidated security findings) to create a GUI, where windows from AppScan Standard (.Net app), AppScan Source (Java app) and VisualStudio (C++/.NET/WPF app) are shown side by-by-side (fully functional) in an external process.

Bellow you can see the four Windows in action:

• Top Left: Findings TreeView from AppScan Standard (.Net)
• Top Right: Code Editor from VisualStudio (C++/WPF)
• Bottom Left: Trace View from AppScan Source (Java)
• Bottom Right: Guidance from AppScan Standard (WebBrowser)

Using a .Net/CLR, a Java/JVM and a C++ Window in another process (to show consolidated security findings)

UPDATE (Jan/13): See PoC - Selenium - Gui with 3 Hijacked Browser Windows.h2 post for another powerful example of consuming Chrome (and IE and Firefox) window in another process

---

Here is the video presented at OWASP BeNeLux conference, which shows how I used the O2 Platform to create a consolidated view of 3 different window's processes (one from .Net/CLR, one from Java/JM and one from C++ applications). Note that these windows are hosted by a 4th (.Net) process and are fully functional.

The objective of this 'consolidated multi-process window view', is to give developers a really strong 'vulnerability fixing environment'.

Showing Chrome, Eclipse, IBM AppScan Standard and VisualStudio in the same Process/Window

UPDATE (Jan/13): See PoC - Selenium - Gui with 3 Hijacked Browser Windows.h2 post for another powerful example of consuming Chrome (and IE and Firefox) window in another process

---

Using the control shown in Util - Win32 Window Handle Hijack (4x host panels) I was able to create a process that has windows from:

• Chrome (top left)
• Eclipse (top right)
• IBM AppScan Standard (bottom left)
• VisualStudio (bottom right)

Util - Win32 Window Handle Hijack (4x host panels) v1.0.exe

Using the exact same control used in Util - Win32 Window Handle Hijack (simple) v1.0 here is a 4x Panel version of it (i.e. using 2 rows and 2 columns)

This allows for the hijack of a multiple Windows into a common (external) process/GUI

You can download this 1Mb tool from Util - Win32 Window Handle Hijack (4x host panels) v1.0.exe

Util - Win32 Window Handle Hijack (simple) v1.0.exe

After Util - Windows Handles Viewer (with Child Windows), I created a tool that allows the easy hijacking (or borrowing) of any Window/Control (that is running in the same Logged-in user Window's Desktop )

This is possible due to  Win32 SetParent's capability to allow a Win32 Window/Control to have a parent from a different process (see first examples of this technique in action in: IBM AppScan Source's and AppScan Standard's TreeViews running side-by-site in the same GUI and in Injecting a .NET REPL into an Unmanaged/C++ application (Notepad)

You can download the 1 Mb tool from:  Util - Win32 Window Handle Hijack (simple) v1.0.exe

Util - Windows Handles Viewer (with Child Windows) v1.0.exe

Following from the tool shown in Util - Windows Handles - View Handle Screenshot v1.0, the next step was to create a tool that shows (for the selected Win32 Window) the handle's children structure (i.e. what 'child windows' exists for the selected window/control)

You can download the 1 Mb tool from Util - Windows Handles Viewer (with Child Windows) v1.0.exe

Here is what the tool looks like (with the 'target icon' used to select the control):

Here is the Pdf with the 'how the script was created' step-by-step guide:

Util - Windows Handles - View Handle Screenshot v1.0.exe

Following from Util - Windows Handles Viewer (Simple GUI with REPL) here is nice utility that takes a screenshot of the target handle's window (when the target process doesn't use the the Win32 Windows controls, you will get a screenshot of the main Window)

You can download the 868 Kb tool from: Util - Windows Handles - View Handle Screenshot v1.0.exe

Windows Shatter attacks (research links)

Following on my research on Win32 Messaging and the O2's Util - Windows Handles Viewer tool, I just started the day by (re)reading about the Windows Shatter attacks (since it used Windows Messages)