Re: [GNAP] Defense protection

Warren Parad <wparad@rhosys.ch> Fri, 28 May 2021 20:03 UTC

Return-Path: <wparad@rhosys.ch>
X-Original-To: txauth@ietfa.amsl.com
Delivered-To: txauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAC893A33F8 for <txauth@ietfa.amsl.com>; Fri, 28 May 2021 13:03:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.088
X-Spam-Level:
X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rhosys.ch
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZLdTzg_d-Pfp for <txauth@ietfa.amsl.com>; Fri, 28 May 2021 13:03:00 -0700 (PDT)
Received: from mail-yb1-xb2f.google.com (mail-yb1-xb2f.google.com [IPv6:2607:f8b0:4864:20::b2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4CCB3A33F6 for <txauth@ietf.org>; Fri, 28 May 2021 13:03:00 -0700 (PDT)
Received: by mail-yb1-xb2f.google.com with SMTP id e10so7092039ybb.7 for <txauth@ietf.org>; Fri, 28 May 2021 13:03:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhosys.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6na7g4CG1FkHa0/5C2ItfYwdJAnyJu4ckZvlkX+H3Os=; b=AJy4nTo0fnZeKm/OG5vZydTlPNwARh+YJnWrChqPdokjnmQ6UPHRQSpL+NrkC02rtb kZF9Wd/CatV3DWQs+/jcrUx6d4Ok6K6INn4vdRLiuWVZgWXSADYgZhdkggdM3Je+DCwH qJsTNRoj2Eu/M85WhX7EX92oIsWMSnhMtxbMieDEgbbhuQC1thuG4z8tp+gUmWVqAAH7 fj6Hm/w6EMfYdOT2ko44cZYkm1LQ8ln21xWoOGggN6ZvMYFVIv3tZ8hguiR24zcbH0TT RkIWnTpKMYtnV5nMoQbXLRtPYnANW+byvObVOXxNem14X5SeIGSUAXysQZGr9JzAk2ZP qeeA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6na7g4CG1FkHa0/5C2ItfYwdJAnyJu4ckZvlkX+H3Os=; b=I+YZOBstdcE1UJf+Xj7ADX+JFW5jI/qB3p6N4yB26RCG7uPX1FEGa9WABF+vaoc1e8 1uBfCe1r/EKJ9SLMYYm6NSoNwtfWjH4i1DT6//nMc7sZ8BjuYD5ECHGdJJT4sS7pG3p8 i1nM1oce9vvhkuTU9o5WLSmU4uxXZG44GE+wXhV9byypWWuaDjUHkKVuzkf5lyhpJqnl w8n2QxZfV45Fqjx+q++hUZ5wSVjHhHwAY70bkhnhxtrbl37lSxrxR9fTMlrfAK9N/lpU 0n/OReGpeC1FYjHCxdPU3doWTIX+6qm2Mz+nU/65tKgpokya9AVi4Gup2k3q0OuM12Ex MRUw==
X-Gm-Message-State: AOAM533clbA7/QhpVS7TL3VBoqkwpAvhCdK4xY+4BGnaTATMu61Hmauy vB3v+7K1w83WxDjefYlm0Cq7dFC3rNmPwXnxv33B
X-Google-Smtp-Source: ABdhPJyA9N4YN5k/+39na+JlO7Oy7yT76Ye4XzV0LGqa0N4M2m1r19VS0C0blMQXoDFls4ZaJ37X3xaO6f9IbTNk1fU=
X-Received: by 2002:a25:a003:: with SMTP id x3mr14851194ybh.182.1622232178077; Fri, 28 May 2021 13:02:58 -0700 (PDT)
MIME-Version: 1.0
References: <CAHbuEH49sZjKvE0JVsa39WuFG83FbBcQQAyXH-V8TNGt-b-wtw@mail.gmail.com> <CANYRo8iiR-ukwWKQzVz2w4_P3wYdokpDecPSL=edfNLnKrEfng@mail.gmail.com> <CAHbuEH7MNvPwK5Yr=Uy=fE5i5-xe5=XyzbTZPZcb6hHA7=TueA@mail.gmail.com>
In-Reply-To: <CAHbuEH7MNvPwK5Yr=Uy=fE5i5-xe5=XyzbTZPZcb6hHA7=TueA@mail.gmail.com>
From: Warren Parad <wparad@rhosys.ch>
Date: Fri, 28 May 2021 22:02:47 +0200
Message-ID: <CAJot-L1GaCo1pUh5mvB=WFJU69vmp2JjT8-ONN1mM159Sc_-Sg@mail.gmail.com>
To: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Cc: Adrian Gropper <agropper@healthurl.com>, GNAP Mailing List <txauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b7c77205c3695ca1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/AgO0cydlrkPJRUbUWsK8rGE7SYQ>
Subject: Re: [GNAP] Defense protection
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: GNAP <txauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/txauth>, <mailto:txauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/txauth/>
List-Post: <mailto:txauth@ietf.org>
List-Help: <mailto:txauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/txauth>, <mailto:txauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 May 2021 20:03:06 -0000

Correct me if I'm mistaken, it sounds like the Golden SAML attack amounts
to getting control of the signer's private key. I'm going to go out on a
limb here and say, I'm not sure any protocol solution would help solve this
problem. But I would love to be mistaken. It's possible to make this harder
by allowing multiparty signers to be required (or at least allowed/enabled)
to prevent single vulnerable issues. There are other issues with that sort
of solution, such as then requiring more nodes to sign each request and
thus providing more physical attack surfaces. It's hard for me to evaluate
the trade off there.

In the case of the OAuth article it seems to suggest, phishing is the
problem. The solution here is preventing the user from entering their
"password" in malicious locations. I'm hoping that browsers will better
support first-class login apis and sanitization for better protection here,
however, nothing first comes to mind about what protocol could do to stop
that. I would say here, browsers need to get better, device OSs need to be
better. Maybe there are better solutions lurking out there.

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.


On Fri, May 28, 2021 at 9:51 PM Kathleen Moriarty <
kathleen.moriarty.ietf@gmail.com> wrote:

> Hi Adrian,
>
> Thanks for your interest!
>
> This is a helpful link that describes how the attackers were able to
> bypass MFA by stealing the signing key for SAML assertions:
>
> https://www.darkreading.com/attacks-breaches/solarwinds-campaign-focuses-attention-on-golden-saml-attack-vector/d/d-id/1339794
>
> https://owasp.org/www-chapter-singapore/assets/presos/Deconstructing_the_Solarwinds_Supply_Chain_Attack_and_Deterring_it_Honing_in_on_the_Golden_SAML_Attack_Technique.pdf
>
> I did read one that was a bit better, but can't find the link at the
> moment.
>
> And one on shared OAuth credentials/token issuance:
>
> https://www.csoonline.com/article/3607348/how-to-defend-against-oauth-enabled-cloud-based-attacks.html
>
> It would be good to think about attack vectors and if not prevention,
> minimally detection.
>
> Best regards,
> Kathleen
>
> On Fri, May 28, 2021 at 3:41 PM Adrian Gropper <agropper@healthurl.com>
> wrote:
>
>> Hi Kathleen,
>>
>> I am not aware of the attacks on SAML and OAuth and would appreciate a
>> link or two.
>>
>> I hope we can provide guidance on how GNAP can facilitate Zero Trust
>> Architecture and believe that includes guidance on how to audit various
>> things as systems use GNAP protocols to separate concerns among independent
>> actors.
>>
>> Count me in for a brainstorming sessio,
>>
>> - Adrian
>>
>>
>> On Fri, May 28, 2021 at 3:29 PM Kathleen Moriarty <
>> kathleen.moriarty.ietf@gmail.com> wrote:
>>
>>> Hello!
>>>
>>> In light of recent attacks against SAML and OAuth, I'd like to see what
>>> defense mechanisms and detection could be built into the spec.  One example
>>> would be from the recent SAML attack.  If there was a detection of
>>> instances of authorization without authentication, the SAML attack used in
>>> SolarWinds might have been detected sooner.
>>>
>>> If you think along the lines of fraud detection, where you detect
>>> unusual events, there may be some specific to GNAP that could enable early
>>> detection of abuse, misuse, or exploits.
>>>
>>> Are there some planned?  Would people like to brainstorm on this?
>>> Thanks!
>>>
>>>
>>> --
>>>
>>> Best regards,
>>> Kathleen
>>> --
>>> TXAuth mailing list
>>> TXAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/txauth
>>>
>>
>
> --
>
> Best regards,
> Kathleen
> --
> TXAuth mailing list
> TXAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
>