Category Archives: misc


Security Unit Tests

Testing the watersOne of the reasons why security creates a challenge in software companies, is that, as a security engineer, we fail to meet the developers where they live.

Security tools and processes (pentests) typically result in a human report , or even a particular standardized file format (SARIF, etc).

During technical security reviews, teams often file bugs and do a manual re-check.  They explain what the issue is, rate its risk, give perhaps a detailed remediation plan (rather than a vague “check for malicious user input”), and may retest it when the developer team claims to have fixed the bug.  

A better way to tackle this is to prepare security unit tests.  These are essentially unit tests that check for a security control.  For example, classes such as:

  • Client certification validation
  • OAuth2 Token validation
  • File upload validation
  • WebRequest validation

Testing these could be more automated, and done in a more continuous way.  If one has a Web endpoint that allows client cert authentication, which is signed by our intermediate CA, and have a whitelisted SNI.  For that, we run the following list of tests:

  • Authenticate with the correct certificate (should succeed)
  • Cert with valid SNI, signed by a malicious CA (should fail)
  • Certificate with the wrong SNI, but the correct CA (should fail)
  • Expired certificate, yet the correct SNI and CA (should fail)
  • Revoked cert (SNI, not expired, CA) (should fail)

Some libraries that perform certificate validation, may not perform all checks (CRL check).  For debugging purposes, a developer may include a “fail open” fallback, and that code may be checked in and be deployed to production.

Some more examples:

  • File uploads: check for zip bombs, embedded ZIP’s, malware, malformed formats, XXE, Deserialization, etc. 
  • JWT token validation: look at unsigned tokens, expired tokens, tokens that are generated – and signed- by the wrong issuer, tokens for the wrong audience, wrong signing algorithms (HS* compared to RS*), etc.

So, to summarize, instead of just human output, security tools and processes should still think about creating unit tests.


The revival of (cross site) script kiddies.

First off, a Happy 2019!

Being in charge of adjudicating Microsoft’s Cloud Bug Bounty; we see many “low hanging fruit” XSS bugs coming through. While we have tools that catch these bugs, sometimes they slip through the cracks. Also, since machines won’t find every.single.bug.ever; we pay out for interesting bugs, and bump up payouts for high quality reports. Sadly though, many of these bugs make us utter a “how come our tools didn’t catch this?”, rather than a “wow, that’s an interesting approach!”. Needless to say, the latter would get higher payouts.

XSS 101

I hope most of you know cross site scripting (XSS). If you can inject active content (we mean JavaScript, 9 out of 10) into a page that, preferably others will see, you have cross site scripting. There may be other nuances to this, but that’s generally my approach. The best way of showing these; is to perform an

which will display the current context’s domain. Showing the current domain, rather than a “123”, “foo” or “pwnage!!1!” message, clearly shows which domain’s DOM, you have access to. In the world of embedded iframes, that shows to be useful.


Most XSS payloads, and there are several out there, are designed to be injected in a page’s DOM. Since the application you’re targeting may be prefixing some controls, you may have to close a previous tag. The tainted data may be included as an HTML attribute, as part of of a JS script block or just as general HTML content. For these, a payload like:

  • ” onmouseover=”alert(123)
  • “; alert(123); var foo=”
  • </textarea><script>alert(123);</script>

May have to come in effect. Needless to say, that list is endless.


Being on the receiver side of bug bounty submissions, and spending several evenings in HTTP access_log or W3SVC1 log files performing pattern analysis, I see a significant higher breadth than depth. Meaning, that many will try a vanilla <script>alert(123)</script> payload, rather than following how the data ends up in the DOM. Missing out on bugs, and payouts.

So for that, I’d ask that if you find yourself mindlessly copy pasting XSS payloads in each field, don’t see the absence of a alert dialog box as a binary (“the site is not vulnerable”), maybe you just need to perform some taint analysis and try again.


Create random passwords with PowerShell

A task I see myself do occasionally, is to generate a password or other symmetric secret. Of course, to avoid things like “Azure123!” and even going against battery horse stable mechanisms, I like to generate random strings; and store these in a password vault. Either online, or local.

At work, I (have to) use PowerShell quite a bit, so I use the following line to come up with a 20 char random password, containing digits, upper- and lowercase alphanumeric characters:

-join ((48..57)+(65..90)+(97..122) | Get-Random -count 20 | %{[char]$_ })

If you need to include special chars, I typically tend to add (!, #, *, -, @ and ~) to the mix, since they’re unlikely to have a special meaning to an underlying system. Their corresponding ASCII values can be added simple:

-join ((33,35,42,45,64,126)+(48..57)+(65..90)+(97..122) | Get-Random -count 36 | %{[char]$_ })

Washington State

So, while since I last updated this blog – bad habit of mine. So, I moved a while ago to Washington State, to be closer to work. Still setting everything up, all the usual issues that happen when moving countries, but yay! New places to visit, new people to meet, new things to do!

misc security

The fake CC conversation

During social engineering exercises, one of the difficulties we face is to get a person to click a link or open an attachment. For the past few decades, we haven’t seen much changes in it. A rather, *sad* part even, a few days ago; Cisco researchers wrote about a quite aggressive malware; Rombertik. While being relatively technically advanced (uncalled functions, anti debugging techniques, etc), one of the modes of distribution is through phishing emails, and quite bad one at that:


A better way is to do targeted attacks; i.e: spear phishing attacks, where you focus your attack on a few people, rather than just casting a net and seeing what sticks.

For this, during social engineering engagements, we often like to use the following 2 techniques:

  • Fake CC
  • Fake email thread

read more »


Filtering password lists due to policies

passwordsSometimes if you’re performing a password bruteforce attack, either against local hashes or remotely against a service, you could use password lists rather than a pure bruteforce (incremental) one. People are most likely to use dictionary words, names, keyboard combinations or anything related to it. These passwords lists can be found anywhere online.

The problem sometimes happens that when you *know* the password policy, but your password list holds a lot of combinations that you know won’t work; simply passwords that are too short or don’t have a number in them or so.
For example, a service requires at least 6 characters, and have one of them being a digit; so you know that entries such as “jesus”, “satan” and “password” won’t work. Still, they are being tried.

For an audit on a company, I ran into that problem – so I wrote a quick and dirty perl script to take a large password list, and only output passwords that adhere to a certain policy. These include minimum and maximum length, as well as password complexity (has to have a digit, uppercase, …)

You can find it on my GitHub.



MS15-034 online checking tool

lockA friend and colleague of mine, Bhadresh, made a quick page to check whether your IIS site is vulnerable to the MS15-034 (CVE-2015-1635), the HTTP.sys remote code execution vulnerability. Check now, and make sure you don’t fall into the hands of blackhats.

You can test it at:


XKCD: hack the stars

This is pretty awesome, from the XKCD cartoons


So true: code quality

From Lifehacker


HeartBleed: we’re sslcrewed

heartbleedThe year 2014 is only a hundred days old, and this is probably the security bug of the year. In case you haven’t heard it, and shame on you if you didnt. HeartBleed is an exploit on a OpenSSL’s TLS Heartbeat extensions. It goes well undetected, and nearly half a billion (yes, B) of websites are vulnerable. We’re not even talking about most other SSL services, embedded systems and so on. It allows an attacker to read chunks of memory (per 64 Kilobytes) which may contain SSL secret keys, passwords, messages, etc.

More technical information can be seen on, and you can check your site using this site.

You can be sure that most blackhat parties, including several intelligence services have tried already to extract information from your SSL enabled websites. If not, you’ll see an increase in HTTPS connections this weekend. Patch your servers, chnge your certificates, change your passwords; all of them. If somebody was storing all your SSL data in the past, they will have a way to find the key to decrypt all of it now, it’s that bad.