{"id":119872,"date":"2024-09-19T21:43:01","date_gmt":"2024-09-19T19:43:01","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/uyazvimost-v-ruby-saml-pozvolyayushhaya-obojti-autentifikacziyu-v-gitlab"},"modified":"2024-09-19T21:43:01","modified_gmt":"2024-09-19T19:43:01","slug":"uyazvimost-v-ruby-saml-pozvolyayushhaya-obojti-autentifikacziyu-v-gitlab","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/novosti-interneta\/uyazvimost-v-ruby-saml-pozvolyayushhaya-obojti-autentifikacziyu-v-gitlab","title":{"rendered":"Sicherheitsanf\u00e4lligkeit in Ruby-SAML erm\u00f6glicht Umgehung der Authentifizierung in GitLab","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Korrektur-Updates f\u00fcr die GitLab-Plattform zur Unterst\u00fctzung der kollaborativen Entwicklung wurden ver\u00f6ffentlicht \u2013 17.3.3, 17.2.6 und 17.1.8, in denen eine kritische Schwachstelle behoben wurde, die eine Umgehung der SAML-Authentifizierung (Security Assertion Markup Language) erm\u00f6glicht. Das Problem wurde durch eine Schwachstelle (CVE-2024-45409) in den Ruby-Bibliotheken ruby-saml und omniauth-saml verursacht, die den Client-Teil der SAML-Authentifizierung implementieren. Die Schwachstellen erhielten die h\u00f6chste Gef\u00e4hrdungsstufe von 10 von 10. Das Problem wurde in den Updates der Pakete ruby-saml (1.17.0 und 1.12.3) und omniauth-saml (2.2.0) behoben. <\/p>\n
Die Sicherheitsanf\u00e4lligkeit wird durch eine fehlerhafte Verarbeitung des XPath-Selectors verursacht, die zu einer falschen \u00dcberpr\u00fcfung der XML-Signatur beim Parsen der Antwort vom SAML-Server f\u00fchrt. Ein nicht authentifizierter Angreifer, der Zugriff auf ein beliebiges signiertes SAML-Dokument hat, kann jede SAML-Antwort f\u00fcr beliebige Inhalte f\u00e4lschen, indem er eine typische XSW-Attacke (XML Signature Wrapping) anwendet. <\/p>\n
Das Ziel des Angriffs besteht darin, eine korrekt signierte Nachricht zu nehmen und eine zus\u00e4tzliche gef\u00e4lschte Nachricht in das damit verbundene XML-Dokument einzuf\u00fcgen, wobei dieselbe ID wie bei der ersten Nachricht verwendet wird (diese ID wird beim Parsen der ersten Nachricht verifiziert und aufgrund eines Fehlers als verifiziert auch f\u00fcr die zweite Nachricht angesehen). Im Kontext von Diensten, die SAML f\u00fcr die Authentifizierung verwenden, erm\u00f6glicht die Schwachstelle den Zugriff auf das System als beliebiger Benutzer. \n Quelle: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"