For those who is new to the world of SSRF vulnerabilities, check the SSRF Bible (full disclaimer: I'm with Wallarm): https://docs.google.com/document/d/1v1TkWZtrhzRLy0bYXBcdLUed...
204 karma · joined November 20, 2013
My talk from Nginx conference: https://www.nginx.com/blog/build-application-security-shield...
Important note. Care about vulnerabilities. Not about attacks. Buy Burp license. Run appsec training for all of your developers; it's easy while you're small.
Disclaimer: I am a co-founder of Wallarm mentioned in preso.
The simplest example is what data transmitted in different parameters of the form field or API calls. For example, it's OK if someone put an SQL Injection payload at Stack-overflow site in the form writing a security-related article. It can be a normal behavior. Meanwhile, SQL injection payload is probably a malicious thing for a login form at your bank website.
We wouldn't ban request only if it is sent with curl. There is a set of different factors and statistics that are taken into the account. E.g. if you run this requests too quickly and it is sent with curl, it can be considered as a malicious activity.
But companies which run fast and deploy code everyday with CI/CD (or several times a day) it's almost impossible not to introduce new vulnerabilities. This is where solutions for continuous security are incredibly helpful.
1. Customers analyze traffic with locally installed NGINX-based instances (there is not DNS take-over). They send applications/traffic statistics to Wallarm Cloud so we can run machine-learning stuff. We had a lot of work done for initial training of the system using our own experience in web app security (more than 250+ pentests for top-tier companies + a lot of researches done by our team like SSRF bible). We also use different honeypots and now statistics of customers with a high volume traffic.
2. There are some details about ML technique covered by Ivan for another comment
3. We have different tasks with SiftScience. SiftScience provides a fraud-detection. Wallarm protects web apps and APIs against data breaches. But these tasks are related for some of our customers.
And, no one asked to pay anything until getting proper results while 30 days free pilot (it could be extended). Give it a try
There is still lack of technical details on Signal Sciences website. And no public demo. Hey, guys, give us a try :)
And it is already one of the approaches Wallarm uses to detect malicious requests.
1. Vulnerability and data breach detection.
Regular WAF just detects attacks. Thousands of attacks. And what to do with this knowledge? In a case of a traditional security solution, it's never clear — if an attack is just scanning with no harm or someone already downloading database over SQL injection vulnerability. You need to analyze all your events manually
Wallarm does more. It discovers which of the attacks are in fact targeting vulnerabilities.
This became possible because of combination defensive and offensive techniques (NGWAF + vulnerability scanner in one core).
2. Attacks/anomalies detection driven by machine learning
It's all about statistics and understanding the structure of the application and its users' behavior. Wallarm Nodes send a lot of statistical (impersonate) data to Wallarm Cloud, so we can get a set of facts about application: - here is the SOAP API; - here is XML API; - here are JPG uploads are allowed - here is field of the form, with CC number (16 bytes, digits only)
There are general ruleset to detect attacks without learning at all. But when we have an understanding of inner knowledge of the application, we can apply this set of facts of application to the general ruleset and get dynamic ruleset for every application. Wallarm Nodes get dynamic ruleset every 15 minutes from the Wallarm cloud.
As a result, it makes possible to protect APIs and apps with frequent code deployments and not to worry about false positives (we saw this many time: in the case of traditional solutions security team is usually required to reconfigure rules after major application updates manually or semi-manually. Hours of useless work. An enormous obstacle for CI/CD. And here what we see all the time: no one wants to get this work done, so security solution works just in monitoring mode WITHOUT actual blocking of attacks).
3. Performance and scalability for DevOps
Signature-less filters are very fast (we have Badoo social network/dating site with 200+ million users running their performance test for their PHP-stack application and they don't see performance degradation). Everybody already knows how to deploy/monitor NGINX with favorite orchestration tools. Wallarm is just a module for NGINX. Now, with the support of dynamic module by NGINX you can even use your existing NGINX instances.
I argue that it is a complete black-box for the customer. What blackbox is full proprietary hardware boxes or virtual appliances with operation system inside from old-fashioned vendors like F5 (no offense) or iMperva (again, no offense). Or entirely cloud solutions which take all your traffic. In a case of Wallarm, you work with your Linux environment; you can see all the Wallarm scripts and content of an in-memory database. And we share the source codes of Wallarm Node with our customers. Yes, have not yet published them in open-source, though.
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
We started as a team of white hat hackers. Ivan (CEO) is a respected researcher known for his articles and talks at international security conferences (BlackHat, Hack In the Box, etc) on web application security.
Everything started with boutique security consulting company founded by Ivan in 2009 which with time became a synonym for the "best security audits for web applications". After each security audit had carried out we got a simple question "Good job, guys, but what's next now? We've fixed all the vulnerabilities you found. The only problem that we deploy code five times a week — and each (!) update might have new security flaws. We could be hacked again anytime!"
So "What's next?" We didn't know and were looking for the answer evaluating different products pretending to secure modern web — with orchestration by DevOps teams, continuous integration (CI) with frequent code updates right on production systems, complex Single-Page Applications and REST APIs, etc. And we failed. Every solution was broken for the same reasons.
1. They are not ready for continuous integration. Frequent code updates results in false positives when legitimate users got banned. The only way to avoid this is manual/semi-manual reconfiguration after each code release.
2. They don't scale well and are not ready for orchestration by popular DevOps tools (making themselves enemies for DevOps teams).
3. They overwhelm users with senseless notifications about thousands of attacks (that obviously has every website!) — without saying which of them are in fact dangerous and targeting security flaws of protected application.
4. Finally, none of them help to find vulnerabilities which are the real reason of data breaches.
So we ran different experiments by ourselves and step by step came to the idea of the product that we wanted to see on the market and recommend to our customers. We started working on it, released first MVP and instantly got positive feedback from all those security teams.
In fact, Wallarm Node is much less black-box than most of the commercial security products (with their own operation system you don't have access to, updates no one knows what inside is, etc.). It is predictable in configuration (just new directives in nginx.conf). Scripts, which come with the Wallarm Node, are free to review. In-memory storage (used for fast local analytics) is accessible. You can watch what the data is exchanged between Wallarm Nodes and Wallarm Cloud. And you use operation system you know.
With our customers, it's OK for us to share source codes.
If you need more than four nodes, the price is more than flexible. Also, we always try to understand better customer infrastructure and, case by case, give node free of charge at all—to cover all the customer's network perimeter. Don't want them to sacrifice part of the infrastructure because of stupid license/price limitations.
I am pretty sure that it's a kind of good option for some enterprises. But most of our customer has high volume applications deployed in several datacenters, with CI/CD and DevOps approaches used. For them, hardware security boxes are almost impossible to use. What they are looking for is DevOps friendly tools that scale and orchestrated well with their application. That is why we're partners with NGINX to provide all the flexibility of our filter nodes.
Moreover, IBM thing will not help you to figure out security flaws in your apps and network perimeter. It will not provide you with details which of millions of malicious request you really need to care about as they are targeting existing security flaws.
I would like to get your feedback about this IBM product. Do you use for some time? It's not that popular among security community (at least, that part we usually talk with). If you give you access to test it, we'll show you some bypasses — unfortunately, there are dozens of them for almost all old-fashioned security solutions like this.
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.
But mod_security provide a very basic approach based on signatures (regular expressions) which: - very hard to maintain and tune, especially if you have applications with a lot of updates (if you don't tune you'll get false-positives); - they don't cover all the attacks; - it not that fast because you need to match each request to the signature database (it's possible to make fast though as CloudFlare did with LuaJIT and OpenResty).
There are no learning capabilities in mod_security, so you need to dedicate engineers time to tune it. There is a lack of analytics. It will detect thousands and millions of malicious request but never says which of them are targeting real vulnerabilities in your apps.
Anyway, mod_security is just another product. It's plain WAF, with a great community and good CRS (signature ruleset).
Could you elaborate on this. What details do we need to add the website to make it less blackboxy? BTW, did you have a look at docs.wallarm.com?