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

Brad Causey bradcausey at owasp.org
Wed Sep 21 17:24:34 UTC 2016


That mirrors what we have done - and had great success.

Thanks Eoin.



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

http://www.owasp.org
--
"Si vis pacem, para bellum"
--

On Wed, Sep 21, 2016 at 12:23 PM, Eoin Keary <eoin.keary at owasp.org> wrote:

> Hey,
> We've had some clients who have undergone cred stuffing attacks. They want
> to avoid 2FA, CAPTCHA given the line of business they are in, clients would
> not use the app...
>
> so to make it more difficult CSRF tokens are embedded in various parts of
> the html.
> They are per request and tied to session.
> Pages need to be reloaded before every Auth request which slows the brute
> force by require extra page loads. Tied to session protects against
> parallel requests and also slows rate of brute force request.
>
> The tokens are selected at random from the page so it's not so simple for
> the attacker to simply script one element value as any of the many tokens
> could be selected and one false move results in failure/temp IP blocking or
> whatever countermeasure is required.
> This is all invisible to the legitimate user and only kicks in when tokens
> are incorrect.
>
>
>
> Eoin Keary
> OWASP Volunteer
> @eoinkeary
>
>
>
> On 21 Sep 2016, at 01:34, Brad Causey <bradcausey at owasp.org> wrote:
>
> 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
> --
> "Si vis pacem, para bellum"
> --
>
> On Tue, Sep 20, 2016 at 6:14 PM, Michael Coates <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-espi
>> onage/sentry-mba-makes-credential-stuffing-attacks-easy-and-cheap.html).
>> 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://twitter.com/intent/user?screen_name=_mwc>
>> OWASP Global Board
>>
>>
>>
>>
>>
>> On Tue, Sep 20, 2016 at 10:56 AM, Dave Wichers <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> 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://twitter.com/intent/user?screen_name=_mwc>
>>>> OWASP Global Board
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Tue, Sep 20, 2016 at 9:39 AM, Brad Causey <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_Preventi
>>>>> on_Cheat_Sheet
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> OWASP-Leaders mailing list
>>>>> OWASP-Leaders at lists.owasp.org
>>>>> https://lists.owasp.org/mailman/listinfo/owasp-leaders
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> OWASP-Leaders mailing list
>>>> OWASP-Leaders at lists.owasp.org
>>>> https://lists.owasp.org/mailman/listinfo/owasp-leaders
>>>>
>>>>
>>>
>>
> _______________________________________________
> 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/fc3d42be/attachment-0001.html>


More information about the OWASP-Leaders mailing list