Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Just a few examples of the attacks that other security products can't catch.

1. A very complicated things going through XML/JSON APIs. Wallarm really parse XML, understand the structure and catch even complicated exploitation attempt like this:

<?xml version="1.0" encoding="UTF-8"?> <!ENTITY a "UNION"> <!ENTITY b "SELECT"> <!ENTITY c "passwd"> <!ENTITY d "FROM"> <!ENTITY e "admins"> <!ENTITY f "WHERE"> <authorid>-1 &a; &b; &c; &d; &e; &f; id=1</authorid>

2. Every vector that exploits vulnerabilities over WebSockets. Some product doesn't support WebSocket at all. Some just proxy data without analysis of it. Wallarm detects malicious behaviour in WebSocket messages.

3. All the attacks with massive evasion techniques. We run thousands of tests to check if attacker can bypass attacks engine. Soon, we'll publish bug-bounty program and we'll pay money for those who will find by-passes.



4. Another great example is detecting exploitation of Java Unserialize vulnerabilities (https://foxglovesecurity.com/2015/11/06/what-do-weblogic-web...).

WebSphere takes payload in Base64 inside the XML. To parse everything (and do it fast), unfold the structure and detect the attacks is still almost impossible thing for most of the WAFs


A security company citing another security company blog to describe a vulnerability.

I <3 it!

--

BTW, in order to use Wallarm one needs to pay upwards of $1000 pm. In order to pacify themselves that it works, one either need to write poor code that exhibits XEE or pay further to use WebSphere. Nice.


Pity you get it in this way. Exploit for WebSphere is just an example of a complicated case with Base64 inside XML where Wallarm can detect malicious request other WAF usually fails.

And, no one asked to pay anything until getting proper results while 30 days free pilot (it could be extended). Give it a try


Just easiest way to test your WAF right here and right now is:

hXXp://defended-site/?test={%22attack%22:%22\u004a3Vu\u0061W\u0039uIHNlbGVjdCBwYXNzd2\u0039yZCBmcm\u0039tIHVzZXJzIGxpbWl0IDEtLWEt%22}

Let's explain payload processing in details: 1. URL-decode {"attack":"\u004a3Vu\u0061W\u0039uIHNlbGVjdCBwYXNzd2\u0039yZCBmcm\u0039tIHVzZXJzIGxpbWl0IDEtLWEt"}

2. JSON unicode chars decode: J3VuaW9uIHNlbGVjdCBwYXNzd29yZCBmcm9tIHVzZXJzIGxpbWl0IDEtLWEt

3. BASE64 decode: 'union select password from users limit 1--a-

Wallarm can process this w/o any manual tuning out of the box.


Thought that you might have other than XEE to showcase.

Showcasing something that started being exploited more than a decade back and has pretty well known defenses doesn't inspire much confidence.


Aren't you claiming that you don't need to terminate SSL?


No magic here :) Sure, we need to terminate SSL. Either before traffic is going to Wallarm proxy node, either by Wallarm Node itself.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: