Do not trust me: Using ma­li­cious IdPs for ana­ly­zing and at­ta­cking Sin­gle Sign-On

Chris­ti­an Main­ka, Vla­dis­lav Mla­de­nov, Jörg Schwenk

IEEE Eu­ropean Sym­po­si­um on Se­cu­ri­ty and Pri­va­cy (EuroS&P 2016)

Ab­stract

Sin­gle Sign-On (SSO) sys­tems sim­pli­fy login pro­ce­du­res by using an Iden­ti­ty Pro­vi­der (IdP) to issue au­then­ti­ca­ti­on to­kens which can be con­su­med by Ser­vice Pro­vi­ders (SPs). Tra­di­tio­nal­ly, IdPs are mo­de­led as trusted third par­ties. This is re­a­sonable for cen­tra­li­zed SSO sys­tems like Ker­be­ros, where each SP ex­pli­ci­te­ly spe­ci­fies which sin­gle IdP it trusts. Howe­ver, a ty­pi­cal use case for SPs like Sa­les­force is that each cust­o­m­er is al­lo­wed to con­fi­gu­re his own IdP. A ma­li­cious IdP should howe­ver only be able to com­pro­mi­se the se­cu­ri­ty of those ac­counts on the SP for which it was con­fi­gu­red. If dif­fe­rent ac­counts can be com­pro­mi­sed, this must be con­s­i­de­red as a se­rious at­tack.

Ad­di­tio­nal­ly, in open sys­tems like Open­ID and Open­ID Con­nect, the IdP for each cust­o­m­er ac­count is dy­na­mi­cal­ly de­tec­ted in a dis­co­very phase. Our re­se­arch goal was to test if this phase can be used to trick a SP into using a ma­li­cious IdP for le­gi­ti­ma­te user ac­counts. Thus, by in­tro­du­cing a ma­li­cious IdP we eva­lua­te in de­tail the po­pu­lar and wi­de­ly de­ploy­ed SSO pro­to­col Open­ID. We found two novel clas­ses of at­tacks, ID Spoo­fing (IDS) and Key Con­fu­si­on (KC), on Open­ID, which were not co­ver­ed by pre­vious re­se­arch. Both at­tack clas­ses allow com­pro­mi­sing the se­cu­ri­ty of all ac­counts on a vul­nerable SP, even if those ac­counts were not al­lo­wed to use the ma­li­cious IdP.

As a re­sult, we were able to com­pro­mi­se 12 out the most po­pu­lar 17 exis­ting Open­ID im­ple­men­ta­ti­ons, in­clu­ding Source­for­ge, Dru­pal, own­Cloud and JIRA. We de­ve­lo­ped an open sour­ce tool Open­ID At­ta­cker, which enables the fully au­to­ma­ted and fine gra­nu­lar tes­ting of Open­ID im­ple­men­ta tions. Our re­se­arch helps to bet­ter un­der­stand the mes­sa­ge flow in the Open­ID pro­to­col, the trust as­sump­ti­ons in the dif­fe­rent com­po­n­ents of the sys­tem, and im­ple­men­ta­ti­on is­su­es in Open­ID com­po­n­ents. All Open­ID im­ple­men­ta­ti­ons have been in­for­med about their vul­nerabi­li­ties and we sup­por­ted them in fi­xing the is­su­es. One year after our re­ports, we have eva­lua­ted 70 on­line web­sites. Some of them have up­graded their li­b­ra­ries and were safe from our at­tacks, but 26% were still vul­nerable.

Tags: