Tag Archives: security


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.

security web

Cross domain cookie contamination

TLDR: XSS attacks can be used to set cookies for sub domains that share the same top level domain. This increases the scope of XSS attacks.

In a cloud world; several applications are hosted under the same top level domain. An organization can have hostnames such as:

  • company.com: corporate landing page
  • mail.company.com: webmail
  • intranet.company.com: internal resources .
  • store.company.com: web store.

Since they all share the same top level domain, an XSS vulnerability could help an setting domain wide cookies. Domain-wide cookies are inherited by all sub domains, so it could contaminate cookie values of other sub domains.

The “attack”

There are two main scenarios, both using vuln.domain.com, which has an exploitable XSS attack, and intranet.domain.com, which uses cookies for session management. An attacker exploits a victim using the XSS vuln, but instead of doing the obvious cookie stealing or DOM manipulation (on vuln.domain.com), he can set arbitrary cookies for the entire domain; including intranet.domain.com. If he’d execute something like:

domain.cookie="sessionid=attackersessionid; domain=domain.com;";
domain.cookie="csrftoken=a1b2c3d4; domain=domain.com;";

He could successfully “log in” the victim onto an arbitrary account, alter settings or even CSRF tokens.


If a host, such as intranet.domain.com has a cookie set already, the browser (FF under u18.04 at least, testing others) will present both cookies. I’m currently figuring out what different frameworks to when several cookies are presented with the same name.

This may prove for interesting attacks, especially for applications that are hosted on a “more critical” top level domain, or are “shared” across cloud providers.


Not a fool proof solution, but you probably want to move away from storing values in cookies that can dictate a particular state, unless it can be validated (signature, …), or host applications of different “value” off different top level domains.

If you have a JavaScript rich application, and you handle authentication (api calls, etc) with tokens that you store in cookies; you may want to opt for localStorage or sessionStorage, rather than HTTP cookies.

And of course, don’t host applications with XSS. 🙂


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.


Post exploitation tools: Lazagne

lasagnaOften, after a compromise of a machine, red teams / adversaries search for certificates or credentials to hop to other machines, often referred to as “lateral movement”. When doing so, many use Mimikatz, a tool that extracts credentials, PIN codes and kerberos tickets from memory. There are countless blog articles about how to detect it, and hide it from AV, etc.

But another nifty tool, that many don’t know about is Lazagne. It searches for credentials in files and registry. Not just your windows credentials, but things you save in your browsers, mail clients, FTP clients, keyrings etc.


KeyWalking: pattern based passwords

keywalkingTL,DR; download the script here.

In security audits, when we get a password file we -even though we may have admin or root access on the target already- usually grab the password file for offline cracking, just to see if there’s any passwords that users re-use, which would give us more access to other systems.

Doing so, we sometimes find passwords such as “cft6&YGVbhu8“, which by the looks of it seem secure; they have uppercase characters, special characters and numbers. When typing them, you’ll notice that they are keyboard patterns.

For this, I was wondering if it was possible to generate a list of all/many keyboard pattern based passwords, a technique referred to as “key walking“. Some tools exist already, but are often based on predefined patterns (“qwe”, “asdf”, “1qaz”, …). I wanted to make something based on a keyboard layout, so it could be extended. This is KeyWalker; a ruby script that generates keyboard pattern based passwords.
read more »


But the camera rocks

On my way home form a merely thought-inspiring movie, I passed by a few girls sharing a cigarette on your typical San Francisco cafe’s terrace. One of them was showing her (?) phone to the other, who told her friend “…but the camera rocks”.

It made me, continuing the movie’s aftermath realize how we’ve given up openness and privacy on our mobile devices, the modern equivalents of our dearest friends (who else do you check at night, early in the morning and take with you to the restroom?), for gimmicks such as cameras and polyphonic ringtones (ok, not anymore, but you get the idea).

Earlier I checked the website of Openmoko, whose goal was to “Free the phone”. Now it seems they have abolished these projects in favor of making a mobile wikipedia device, but I wish they or a similar body would take up the movement again.

We live in an ecosystem that has many “services” and closed systems; and we happily accept it. It’s ok to give up the freedom of tinkering with a mobile phone you just paid 500$ for, because it has cool apps the other platform doesn’t have, oh and of course, because “the camera rocks”.

I hope we start swaying towards openness again, and take back the right on our digital devices and lives, the same as we have with other, everyday, things. You buy a car, you’re allowed to open the hood and change pretty much everything about it, as long as it doesn’t affect it’s safety or the environment. You spend money on clothes but want to rip off the sleeves, nobody stops you. Let’s keep that in mind, and hold on to that. A device that his so dear to us should be transparent;. And I’m sure its camera would not be so bad either.

internet security uae

Phone numbers as default eLife WiFi keys

antsThe UAE’s internet is pretty much provided by two ISP’s: Etisalat and Du who provide broadband services to its customers.

Focusing on the largest of the two, Etisalat, they provide a eLife program that allows triple play services into the homes of their customer base, which include a WiFi network. The problem though is that many of these wireless access points are setup by Etisalat’s technicians themselves, sporting a certain convention for encryption keys; the client’s mobile phone number.

This mobile number convention is a limited keyspace, with just a few numbers short of 36 million possibilities. (8999999 * 4 prefixes). Knowing a possible key, helps tremendously in brute forcing the keys of a Wireless network. To create a list that creates all these numbers in a list, one could write that in Perl:

# generates 05[0256][1-9][0-9]{6} numbers
$| = 1;
foreach my $a (0, 2, 5, 6){
  foreach my $b (1000000..9999999){ print "05".$a.$b."\n"; }

*Note: this script can be optimized of course, since it will be unlikely that you’ll have networks with several repetitive numbers having a default eLife installation.

Another handy fact is that “default” eLife setups have their SSID configured as etisalat-XXXXX where XXXXX is a “random” number.

Aside from “having free Internet access” to load balance your torrent web surfing traffic, there’s a much greater risk here.

eLife is delivered with a Aztech HW550 3G wireless router. These devices have an embedded version of Linux available, and Aztech was so kind to have make the source code available. Alternatively, you can resort to OpenWRT’s efforts, but the latter might raise some suspicion if the original owners decide to change something about their WiFi network.

Now, the danger lies in the following scenario:

  • Attacker adds a backdoor into the HW550’s firmware.
  • Attacker cracks your wireless keys and accesses your network
  • Attacker accesses your wireless router (assuming you didn’t change the admin password)
  • Attacker uploads the new firmware
  • Attacker has access to your connection at all times, can use it to launch attacks and tunnel connections

Since the HW550 has a MIPS CPU of “only” 384 Mhz, and only 32 Megabytes of RAM, it can’t be used for heavy load network traffic, but you get the basic idea. Aside from creating “AP zombies”, one could redirect your traffic to do a MITM attack, etc …

So, to prevent this scenario from happening, choose a strong Wireless encryption key and change it regularly. Or, install OpenWRT yourself, or just get an other (better) Access Point.
That, and living inside a Faraday cage, so nobody picks up your wireless signals.


keyspace limitations

I can’t really say which website this is, but it’s a middle eastern telecommunication company.

Maximum 8 character password, in 2012, really?

But then again, in a confirmation email, I noticed that these guys store the password in cleartext. Is diskspace really that expensive that we have to make it a VARCHAR(8)? I know these guys have an internal IT security department, wonder why.

Javascript security web

JQlog: JQuery Keylogger, or why not to trust your proxy admin.

Note that this post is for awareness and educational purposes only. I do not encourage, and cannot be held responsible for malicious actions using these tools.

The Internet, as it is today, is a mash-up of JavaScript enabled services, often included from external websites. Internet companies offer so-called widgets, which are JavaScript tools that can be used in your own page. Popular examples of this are site analytics (Omniture, Google Analytics, etc) or share-abilities (AddThis, AddToAny, …). It’s by overwriting Javascript libraries on a page, that we can do other things, such as recording keystrokes.

“Overwriting” javascript libraries, or rather “inserting javascript” can be done in several ways. Cross Site Scripting is one of them, but for the sake of this blog post, I will act as a malicious proxy administrator, and overwrite the Google Analytics DNS entry (www.google-analytics.com) and “fake” the ga.js javascript file.

For this, you’d need only 2 files:

This javascript file, found here, holds 3 parts: JQuery, a base64 encoder and the keylogger code itself: read more »


Dubai Credit Card Fraudsters arrested

Dubai Police arrested a gang of Arab men, who stole over 200 million dirhams using credit cards doing online shopping, Gulf News said.

They were tipped off in August about the guys, and caught most of them now (one out of four is out of the country).