News for hackers. Stuff that matters.

hkr_mag

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...
This is a list of what you can do for application security with Nginx (mostly with open source tools): https://github.com/wallarm/awesome-nginx-security

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.

Awesome job, guys! We have several team members (mostly sales) using Polymail as a default email client.
Re:Scale API (S16) helps engineers outsource microtasks on Tuesday May 23, 2017 @01:20AM (#14398969)
One of the most promising companies among the whole S16 batch. Congatz!
Re:Api.ai is joining Google on Monday September 19, 2016 @07:51PM (#12535729)
+1. Success factor, API.ai, Evernote — three logos from my memory
The main idea about Wallarm is to get inner knowledge of how the application works and how users use it. Based on this data, we craft dynamic rules for every single applications or API.

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.

Thanks!
Thanks Jason! Will be at DEFCON this year? It'll be great to meet there.
Hackerone and Bugcrowd do a great job. And we recommmend to run bug-bounty programs all the time.

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.

Thanks for feedback!

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.

Hey there. Stepan, co-founder of Wallarm, here. Feel free to ask any questions.
It's because all the security guys (as we're) troll a lot and always skeptical (reasonably!) about blackboxes
It absolutely has. The vulnerability was detected with a vulnerability scanner built in Wallarm. As for detection of attacks, in many cases, it's much easier to identify the attacker when he runs several requests than to stop only one request with a ready-to-use 0day exploit. And what's even more important, you need help to fix vulnerability unless attacker discovers it and find the way to evade WAF
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

Cool. Let's catch up for a coffee than
Signal Sciences launched a bit after us. The main difference is in the result: - Guys are helping to detect anomalies and attacks, and I believe they're doing this better than regular WAF does. - Wallarm helps to discover exploitable security flaws and incidents (vulnerabilities exploitation) within attacks/anomalies which it detects.

There is still lack of technical details on Signal Sciences website. And no public demo. Hey, guys, give us a try :)

What we have already published to open-source is libdetection (https://github.com/wallarm/libdetection), a library implementing a completely new way to detect attacks. This approach allows us to implement attack detection without having to specify precedents of attacks. I mean it doesn't require attacks samples to learn at all. Instead, formal models are used.

And it is already one of the approaches Wallarm uses to detect malicious requests.

# Why it's different

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.

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

BTW, here is the link to Ivan's presentation about WAF evasion techniques — http://www.slideshare.net/d0znpp/lie-tomephd2013. Lots of them are still valid for old-fashioned security vendors
Thanks! Asked mates to figure it out.

Older »