[Owasp-leaders] https://www.owasp.org/index.php/Credential_stuffing

Segal, Ory orsegal at akamai.com
Wed Sep 21 18:47:54 UTC 2016


Hi,

Chiming in...

It seems that the default suggestion for mitigating credential stuffing is to use some sort of Anti-Automation - either through nonce/tokens, or by using some sort of client-side challenge (e.g. CAPTCHA, JS-challenges, etc.).

While these might work for standard web applications, it is oftentimes impossible to use them when the login request is an API call, such as a login performed from a mobile application that does not render/execute HTML directly.

In fact, Akamai is seeing massive credential stuffing campaigns targeting login APIs, and it seems that malicious users figured out that it's much easier to perform such campaigns over APIs that are harder to protect and monitor.

-Ory



From: Ryan Barnett <ryan.barnett at owasp.org>
Date: Wednesday, September 21, 2016 at 3:57 AM
To: "bradcausey at owasp.org" <bradcausey at owasp.org>, Michael Coates <michael.coates at owasp.org>
Cc: OWASP Leaders <owasp-leaders at lists.owasp.org>
Subject: Re: [Owasp-leaders] https://www.owasp.org/index.php/Credential_stuffing

We see account stuffing attacks all the time and they are a huge problem.  See my blog post here to get an example of the size/scope of attacks - https://blogs.akamai.com/2016/06/web-application-defenders-field-report-account-takeover-campaigns-spotlight.html

We are talking millions of participating IP addresses…

-Ryan


From: <owasp-leaders-bounces at lists.owasp.org> on behalf of Brad Causey <bradcausey at owasp.org>
Reply-To: <bradcausey at owasp.org>
Date: Tuesday, September 20, 2016 at 8:34 PM
To: Michael Coates <michael.coates at owasp.org>
Cc: OWASP Leaders <owasp-leaders at lists.owasp.org>
Subject: Re: [Owasp-leaders] https://www.owasp.org/index.php/Credential_stuffing

Good stuff Michael.

Part of what makes this interesting is that these attacks evolve as the defenses evolve.

When we first started defending against this, we called it "credential reuse" and we were able to defeat it by using two step authentication combined with something similar to CSRF protection(basically just have a server variable ensure that a browser was rendering the first step). At the time, most secure sites included the username and password on the same page, and used a single form submission to evaluate the validity of credentials. Every reuse attempt was scripted using simple python or perl, and came from a single IP address, so it was easy to identify by watching the web server logs closely.

Things have evolved a bit more, but not much from what I've seen. At this point, we are seeing attempts migrate from one IP to another slowly. For example, 1000 attempts from one IP, then 1000 from another, etc.

If there are highly sophisticated attacks out there, I haven't seen one. Of course, my experience is anecdotal. What we really need is examples of these attacks using whatever advanced methods they are using. Even if it's just log files.

Has anyone seen a more evolved version of this?

By my estimation, MFA plus behavior and device analysis will be the only way to prevent this in it's final stage of evolution.






-Brad Causey
CISSP, MCSE, C|EH, CIFI, CGSP

http://www.owasp.org<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.owasp.org&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=J84kMEXikP18x1Y4vDE7ejb9JEu1zynsR7NgHrn8Mk8&m=dGVxP13UJi9ADugfIUKWOCi2J4X4NNIRgfpCnjwqByw&s=rxVpbHfZvFbbDjxSZIbpixGbZsjDSLQQQJBgT4Zl7Cw&e=>
--
"Si vis pacem, para bellum"
--

On Tue, Sep 20, 2016 at 6:14 PM, Michael Coates <michael.coates at owasp.org<mailto:michael.coates at owasp.org>> wrote:

"For example, lets say that multi-step login caused 90% of the current Credential Stuffing attacks to go away, wouldn't that be worth it?"

I think we need to be very careful because, without data, we're just speculating on how easy it is to bypass a "basic defense". For consideration a comparable example would be to strip <script> in order to prevent XSS attacks. It may prevent X% of basic XSS attacks, but we all agree it's counterproductive to even suggest this.

Another example for consideration is multi-submit CSRF attacks. Would we consider a two page form a recommended defense against CSRF attacks? It is slightly more difficult, but not really.

Lastly, the economics of the attacker market does not require every attacker to recreate the offensive attack wheel. Instead one attacker builds a tool and resells it to many. This is particularly true with credential stuffing attacks see Sentry MBA tool (http://www.csoonline.com/article/3045247/cyber-attacks-espionage/sentry-mba-makes-credential-stuffing-attacks-easy-and-cheap.html<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.csoonline.com_article_3045247_cyber-2Dattacks-2Despionage_sentry-2Dmba-2Dmakes-2Dcredential-2Dstuffing-2Dattacks-2Deasy-2Dand-2Dcheap.html&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=J84kMEXikP18x1Y4vDE7ejb9JEu1zynsR7NgHrn8Mk8&m=dGVxP13UJi9ADugfIUKWOCi2J4X4NNIRgfpCnjwqByw&s=JgodK7wgkVHfY_aeif_WKnwKURVHt3OVrFoQzPQC-gw&e=>). At the end the inclusion of an easy to bypass defense would just lead to a false sense of security.

What to do?

Recognize this is hard and have a factual discussion that outlines the good defenses (even if they are hard). There are several that are good defenses already included in the cheat sheet. Hopefully the collective focus with a solid understanding of the problem space will lead to additional research and easier defenses.

Thanks! I'm well aware this is a tough area and excited to see an exploration of the issue.


--
Michael Coates | @_mwc<https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_intent_user-3Fscreen-5Fname-3D-5Fmwc&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=J84kMEXikP18x1Y4vDE7ejb9JEu1zynsR7NgHrn8Mk8&m=dGVxP13UJi9ADugfIUKWOCi2J4X4NNIRgfpCnjwqByw&s=cP3OWddXpH7i0O5QaSHkwwp4OhGJWKKhb0NIDpbwicY&e=>
OWASP Global Board




On Tue, Sep 20, 2016 at 10:56 AM, Dave Wichers <dave.wichers at owasp.org<mailto:dave.wichers at owasp.org>> wrote:
Michael,
I'm not so sure we should drop basic defenses yet, since this problem is so new. I think we should be VERY clear, that we understand certain defenses can be bypassed when they can.
For example, lets say that multi-step login caused 90% of the current Credential Stuffing attacks to go away, wouldn't that be worth it? We all understand this is an arms race, so it will keep getting harder and harder, but I don't think that relatively simple defenses that work today should be discarded. And if that's simply step 1 in your defense, and you plan to add additional layers of defense, then I don't think discarding step 1 is necessary/appropriate.
-Dave

On Tue, Sep 20, 2016 at 1:46 PM, Michael Coates <michael.coates at owasp.org<mailto:michael.coates at owasp.org>> wrote:
Brad,

Thanks for kickstarting this cheat sheet. My initial feedback is that we should scrap 3.2 Defense Option 2: Multi-Step Login Process and 3.3 Defense Option 3: IP blacklists. These defenses just don't work against this type of attack. Even if they provide some defense against the most basic attacks I feel it's misleading since it's trivial for an attacker to bypass these defenses and real world attacks show that they regularly do.

Not meant as a bash on the overall cheat sheet. In fact I think I kicked off this thread and am a big supporter of discussion here. But I think it's good for us to avoid partial solutions that could give a false sense of security.

I like the other defenses. I think we also can add a few others which are "additional identify verification" and "anti automation.


--
Michael Coates | @_mwc<https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_intent_user-3Fscreen-5Fname-3D-5Fmwc&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=J84kMEXikP18x1Y4vDE7ejb9JEu1zynsR7NgHrn8Mk8&m=dGVxP13UJi9ADugfIUKWOCi2J4X4NNIRgfpCnjwqByw&s=cP3OWddXpH7i0O5QaSHkwwp4OhGJWKKhb0NIDpbwicY&e=>
OWASP Global Board




On Tue, Sep 20, 2016 at 9:39 AM, Brad Causey <bradcausey at owasp.org<mailto:bradcausey at owasp.org>> wrote:
Great discussion so far.

Would you folks mind taking a look over this and providing feedback?

I intend to provide more detail on each subject, but first I figured we could agree on the primary defenses.

https://www.owasp.org/index.php/Credential_Stuffing_Prevention_Cheat_Sheet<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.owasp.org_index.php_Credential-5FStuffing-5FPrevention-5FCheat-5FSheet&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=J84kMEXikP18x1Y4vDE7ejb9JEu1zynsR7NgHrn8Mk8&m=dGVxP13UJi9ADugfIUKWOCi2J4X4NNIRgfpCnjwqByw&s=jo2DXmCtKOwdzwdqPmlYX4AfsKojCyMqlH0OUD3WbjQ&e=>



_______________________________________________
OWASP-Leaders mailing list
OWASP-Leaders at lists.owasp.org<mailto:OWASP-Leaders at lists.owasp.org>
https://lists.owasp.org/mailman/listinfo/owasp-leaders<https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.owasp.org_mailman_listinfo_owasp-2Dleaders&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=J84kMEXikP18x1Y4vDE7ejb9JEu1zynsR7NgHrn8Mk8&m=dGVxP13UJi9ADugfIUKWOCi2J4X4NNIRgfpCnjwqByw&s=nd_YPJuK6eyzjHX1rUzqJGxyW4YDCESusCrjRGLXeOw&e=>


_______________________________________________
OWASP-Leaders mailing list
OWASP-Leaders at lists.owasp.org<mailto:OWASP-Leaders at lists.owasp.org>
https://lists.owasp.org/mailman/listinfo/owasp-leaders<https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.owasp.org_mailman_listinfo_owasp-2Dleaders&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=J84kMEXikP18x1Y4vDE7ejb9JEu1zynsR7NgHrn8Mk8&m=dGVxP13UJi9ADugfIUKWOCi2J4X4NNIRgfpCnjwqByw&s=nd_YPJuK6eyzjHX1rUzqJGxyW4YDCESusCrjRGLXeOw&e=>



_______________________________________________ OWASP-Leaders mailing list OWASP-Leaders at lists.owasp.org https://lists.owasp.org/mailman/listinfo/owasp-leaders
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-leaders/attachments/20160921/2db55045/attachment-0001.html>


More information about the OWASP-Leaders mailing list