Juniper Mykonos – Mostly Serious Web Security

Back in February 2012, Juniper announced that they were acquiring Mykonos, a Web Security vendor, and quite honestly my reaction was “uh, ok then”. I’d never heard of them, and figured I never would again – it would probably just have its technology sucked up into a firewall and integrated into a larger feature set. Evidently I was wrong, because on Friday afternoon at Networking Field Day 4, Juniper gave us a presentation and demonstration of their Mykonos product, and I have to say, I loved it.

First though, let’s figure out what this thing actually is.

Mykonos Web Security

The first thing to make me smile is that Mykonos has trademarked the phrase Intrusion Deception™. I like word play, so they’ve got me hooked from the outset, and while – as it turns out – it’s also a terrific description of what the product does, you need the full picture to make sense of it. Knowing that it’s ‘web security’ doesn’t help much either, does it?

Typical Web Attacks

So what does a typical attack on a web site look like? The answer to that may depend to some extent on how good the hacker is. Some approaches might include:

• URL tampering
• Form field tampering (especially hidden fields)
• Checking for unprotected configuration files (e.g. a readable .htaccess or .htpasswd)
• Vulnerability checking (e.g. check known vulns for particular software)
• Password cracking
• Form field overflows and similar character-based trickery to crash the application or allow the entry of SQL commands

Each of these can require a different skill level on the part of the “hacker”, but part of the challenge can be for a security system to figure out what kind of hacker you are up against, how best to deter and detect them, and how to track a consolidated attack that might spread over days or weeks.

Typical Defense Strategies

Intrusion Detection and Prevention (IDS, IPS, IDP and similar acronyms) are usually deployed in DMZ environments to look for malformed strings, standard attack signatures and so on. They’re pretty effective, and for the script-kiddie attacks on software vulnerabilities they’re very effective (as signatures are well known), but they’re not usually designed to track attacks over a broad time period, and may not be able to identify some of the tampering that can occur within a legitimate HTTP request.

Intrusion Deception

Enter Mykonos and their Intrusion Deception. Mykonos’ logic seems to go something like this:

• People are going to hack no matter what you do;
• Most hackers want to see results – there’s an ROI of sorts in terms of the time they’re willing to spend trying to get into a site before they decide it isn’t worth the investment of time, and they move on to a less well secured site;
• The key is to identify these people and, well, discourage them.

But how do you do that?

Tar Pits

Mykonos creates what they describe as a “tar pit”. It’s not quite a honeypot, in that you aren’t leaving a vulnerable server out there to see what hits it. Rather, the Mykonos product injects little tidbits into the HTTP streams to tease hackers into revealing themselves. For example, what hacker, seeing this URL in their address bar, would not be tempted?

https://www.fakecorp.com/store/product.asp?id=9192&p=1&admin=false

That’s just begging for them to see what happens if you set admin to true, isn’t it? How about if a hacker looks at the HTML for a form and sees this:

<input type="hidden" name="adminpriv" value="false">

It would be hard to resist, and after all it would only take a moment to try it out.

Inline Tampering

Mykonos sits inline with web server traffic, intercepts the HTTP/HTTPS stream from the server to the client and tampers with the HTML. It can either terminate HTTPS (with your certificate) then re-encrypt as HTTPS to the server, or you can do the SSL offload on the Mykonos product and pass requests to the web application servers unencrypted as HTTP.

Mykonos also grabs client-server responses and can either fake a response, alter it, or pass it though. In the examples above, the web site itself does not use the “admin=false” parameter – it is added by Mykonos as it’s passed through so that the client sees it. Fake form fields can be added, as can code, <!– comments –> apparently left over from the developers, perhaps with old code in, and more. Mykonos claim that their tampering does not affect the as-built behavior of the existing site, and thus with a very few exceptions, Mykonos can be dropped inline, and it just works.

Now, if the tampering was as blatant as the examples above, then arguably it would be just a little bit obvious. But in operation the product is far more subtle than that, and the result looks very well blended with the original site.

Why Tamper?

Mykonos does not affect existing site operations. That means that it’s not looking at the form fields you already have, for example – it would not detect somebody injecting an SQL string into a username field, and for that you still want your regular intrusion detection systems in place. However, by adding unique fields, url tweaks and fake code, it’s obvious that if any of these is being played with, you must have a hacker on your hands, because the actual web application doesn’t use those fields. Sounds kind of simple doesn’t it? If you take the bait, you’re operating outside the parameters of the web site, which means you’re a “bad guy”. The claim is “no false positives”, and on that basis, I think they are probably right.

Having various levels of potential exploit also helps categorize the type of hacker you’re dealing with.

Tampering extends beyond injecting code too; Mykonos can fake file responses and content. For example, if a hacker tries to read a .htaccess file, they might actually succeed – but it might be a file created by Mykonos. Maybe going on to try the .htpasswd file will let you download a file with encrypted passwords in it. A good hacker will attempt to decrypt the passwords and maybe match one or two. If they they try to log in with those credentials, a) it won’t work, and b) Mykonos now knows that you are a step up from a Saturday night script kiddie.

Super Cookies

In order to try and track repeated hack attempts by the same individual, Mykonos also injects what they describe as a Super Cookie on the client browser. They do this by trying to set a cookie using any and every method and plugin they can that provides persistent storage on the client. Even if the client clears their cookies, they may not catch all storage methods. This apparently fits with the EU directive’s definition of a cookie that’s necessary for the site to operate (like a session cookie), although in the room we all expressed concerns about the tracking nature of the cookie. However, ethical concerns aside for a moment, the ability to track a user via a cookie means that Mykonos can spot the same person coming back, whether they’ve changed IP address, or are using a different proxy. Similarly it helps identify a specific user, even if there are many users hitting a site from behind the same proxy, and allows action to be taken against an individual computer, rather than affecting an entire IP address which could affect innocent users.

Building a Profile

Each user (i.e. super cookie recipient) gets assigned a name in the database (e.g. “Frank 1022”) and their activities are tracked and logged so that a profile of that user’s behavior can be built up, and their level of risk assessed. Mykonos tries to recognize human hackers, botnets, targeted scans, IP scans and scripted exploits, and suggests responses based on the categorization.

Attack Response

So having spotted a hacker, what do you do? Cut them off? Myknonos says not necessarily, and instead takes a rather more playful attitude towards the would be hackers. Some possible responses might include:

• Requiring a CAPTCHA
• Blocking the user
• Slowing down their connection (delaying page response times)
• Pretending the application is broken
• Forcing a log out (e.g. clearing the session cookie being passed to the server)
• Warning the attacker that you know what they’re doing

The suggested responses to each attack type are listed here (click to enlarge):

For example, somebody just playing with the URL string can quite probably be deterred by warning them that you know what they’re up to, and they need to stop it. A popup is injected in the page stream to display the warning to the user. Forcing a timed CAPTCHA (respond within 15 seconds or similar) can protect against scripted attacks by effectively blocking the tools from operating. Slowing the connection is a beautiful and subtle way to deter. A page response goes from being fast to maybe taking an additional second, then maybe a few more seconds, and onwards up to a maximum duration you can configure. Pages served to you by the sites become so unusably delayed, your best bet is to move on and try somewhere else. Forcing log out can be a simple but effective tool if, say, you allow a hacker to work through a whole sequence of steps that they believe will allow them to successfully attack a system, then at the last minute drop their session cookie so that any work they did is lost. Do this at the end of a long sequence of attack steps, and it rapidly becomes an undesirable site to hack.

My favorite warning response (disabled by default) is this popup, with apologies for the quality of the capture:

A little smug perhaps, but for the geek in you, a very funny concept.

Eating The Dog Food

I have not yet tried to find out whether http://www.mykonossoftware.com/ is protected by Mykonos web security. I have to feel it must be, but I’m hesitant to find out!

Demonstration

A great guy called Kyle presented Mykonos to us, and did a live demo. I should note that the demonstration worked, which could not be said for every demo I saw this week. We saw the CAPTCHA responses, slowed site, and warnings being effected real time as he attempted to hack the site in front of us. The management console seemed pretty simple, allowing us to find our hack profie and see the attacks that had been detected.

Redundancy and Scalability

Having a single box inline is a concern for obvious reasons. Mykonos can be deployed with multiple inline proxies all feeding data back to a central profiling server that ensures that data is centrally synchronized so that an attack through any of the inline traffic servers will be associated with all other, and previous attacks from the same user. You would typically want to deploy your own load balancer to do this though; reading between the lines a bit, I don’t think the load balancing available from Mykonos itself is going to be as functional or reliable.

Conclusions

Like the Statseeker product, Mykonos is not going to solve all your problems, but it seems to do what it does pretty well. It isn’t a firewall, it doesn’t protect your actual applications or validate submitted data, and it is certainly not a replacement for IDS/IPS/IDP, nor for validating that your applications are written securely in the first place. I love the idea that a potential hacker is not entirely clear whether what what they’re doing is real – and could be wasting hours on a wild goose chase.

It’s odd in some ways to have a product that rather than blocking attacks, seems to encourage them – but that is on its own terms, and it was expressed that if you outright block something, it simply becomes a challenge for the hacker to work around, and they might succeed. Make it frustrating on the other hand, and hopefully most hackers will move on to a target that is easier. This is the same reason why we put expensive locks on our doors and buy alarm systems, despite the fact that we have glass windows all around the house that an intruder could easily use to gain access. The bottom line is that an intruder wants to sneak in quickly and quietly, and smashing a large window is neither. So despite the fact that every house has glazing vulnerabilities, the likelihood is that an burglar will break into a house with no alarm and a lame lock on the door rather than go through the pain of picking your lock and disabling your alarm.

As part of a defense in depth strategy, I really like this product. I’d like to see it on a test site to better gauge the latency it introduces (I think they told us, and it was small, but doing your own testing is the best way). It’s unclear exactly how well Mykonos might work with more distributed systems, although there was mention of “cloud” support, and I suspect this is an area where we’ll see development in the future. I have concerns that it will become possible to detect what is fake and what isn’t, but with sufficient randomization of terms it may be able to hide well enough to catch most people out.

Over all, a great presentation (strongly encourage you to watch it), and a very interesting and I believe unique approach to (one part of) web application security. Having a product that sits inline will worry some people, but the minimal configuration required and not needing to update attack signatures will be a bonus. I’ll be watching this product with interest.

Watch The Presentation from NFD4

Don’t just take my word for it, watch the presentation from NFD4 for yourself.

Presentation

Demonstration

Get Some Other Points of View

Here are some blog posts from other NFD4 delegates so you can get their take on Mykonos:

• Mykonos – WAF With An Attitude (@packetu)
• Tar Covered Clouds (@pandom_)
• Juniper Networks at NFD4 (@networkstatic)
• Juniper – Land of Unicorns and Broccoli (@networkingnerd)

I’ll update this list as I become aware of other posts, and these are good blogs to subscribe to even if Mykonos isn’t your primary interest!

Disclosure

Juniper (Mykonos) was a presenter at Networking Field Day 4, and while I received no compensation for my attendance at this event, my travel, accommodation and meals were provided. I was explicitly not required or obligated to blog, tweet, or otherwise write about or endorse the sponsors, but if I choose to do so I am free to give my honest opinions about the vendors and their products, whether positive or negative.

Please see my Disclosures page for more information.