CXSecurity WLB-2015040034 6kbbs v8.0 Multiple CSRF (Cross-Site Request Forgery) Web Security Vulnerabilities


CXSecurity WLB-2015040034 6kbbs v8.0 Multiple CSRF (Cross-Site Request Forgery) Web Security Vulnerabilities


Exploit Title: 6kbbs Multiple CSRF (Cross-Site Request Forgery) Security Vulnerabilities

Vendor: 6kbbs

Product: 6kbbs

Vulnerable Versions: v7.1 v8.0

Tested Version: v7.1 v8.0

Advisory Publication: April 02, 2015

Latest Update: April 02, 2015

Vulnerability Type: Cross-Site Request Forgery (CSRF) [CWE-352]

CVE Reference: *

CXSecurity Reference: WLB-2015040034

Impact CVSS Severity (version 2.0):

CVSS v2 Base Score: 6.8 (MEDIUM) (AV:N/AC:M/Au:N/C:P/I:P/A:P) (legend)

Impact Subscore: 6.4

Exploitability Subscore: 8.6

CVSS Version 2 Metrics:

Access Vector: Network exploitable; Victim must voluntarily interact with attack mechanism

Access Complexity: Medium

Authentication: Not required to exploit

Impact Type: Allows unauthorized disclosure of information; Allows unauthorized modification; Allows disruption of service

Writer and Reporter: Jing Wang, Division of Mathematical Sciences (MAS), School of Physical and Mathematical Sciences (SPMS), Nanyang Technological University (NTU), Singapore. (@justqdjing)




Suggestion Details:

(1) Vendor & Product Description:




Product & Vulnerable Versions:





Vendor URL & download:

6kbbs can be gain from here,


Product Introduction Overview:

“6kbbs V8.0 is a PHP + MySQL built using high-performance forum, has the code simple, easy to use, powerful, fast and so on. It is an excellent community forum program. The program is simple but not simple; fast, small; Interface generous and good scalability; functional and practical pursuing superior performance, good interface, the user’s preferred utility functions.”

“1, using XHTML + CSS architecture, so that the structure of the page, saving transmission static page code, but also easy to modify the interface, more in line with WEB standards; 2, the Forum adopted Cookies, Session, Application and other technical data cache on the forum, reducing access to the database to improve the performance of the Forum. Can carry more users simultaneously access; 3, the data points table function, reduce the burden on the amount of data when accessing the database; 4, support for multi-skin style switching function; 5, the use of RSS technology to support subscriptions forum posts, recent posts, user’s posts; 6, the display frame mode + tablet mode, the user can choose according to their own preferences to; 7. forum page optimization keyword search, so the forum more easily indexed by search engines; 8, extension, for our friends to provide a forum for a broad expansion of space services; 9, webmasters can add different top and bottom of the ad, depending on the layout; 10, post using HTML + UBB way the two editors, mutual conversion, compatible with each other; …”




(2) Vulnerability Details:

6kbbs web application has a computer cyber security bug problem. It can be exploited by CSRF (Cross-Site Request Forgery) attacks. This may allow an attacker to trick the victim into clicking on the image to take advantage of the trust relationship between the authenticated victim and the application. Such an attack could trick the victim into creating files that may then be called via a separate CSRF attack or possibly other means, and executed in the context of their session with the application, without further prompting or verification.

Several 6kbbs products 0-day vulnerabilities have been found by some other bug hunter researchers before. 6kbbs has patched some of them. Open Sourced Vulnerability Database (OSVDB) is an independent and open-sourced database. The goal of the project is to provide accurate, detailed, current, and unbiased technical information on security vulnerabilities. The project promotes greater, open collaboration between companies and individuals. It has published suggestions, advisories, solutions details related to csrf vulnerabilities.


(2.1) The first code programming flaw occurs at “/portalchannel_ajax.php?” page with “&id” and &code” parameters in HTTP $POST.

(2.2) The second code programming flaw occurs at “/admin.php?” page with “&fileids” parameter in HTTP $POST.





Related Articles:




OSVDB 120807 NetCat CMS 3.12 HTML Injection Web Security Vulnerabilities



OSVDB 120807 NetCat CMS 3.12 HTML Injection Web Security Vulnerabilities


Exploit Title: NetCat CMS 3.12 /catalog/search.php? q Parameter HTML Injection Web Security Vulnerabilities

Product: NetCat CMS (Content Management System)

Vendor: NetCat

Vulnerable Versions: 3.12 3.0 2.4 2.3 2.2 2.1 2.0 1.1

Tested Version: 3.12

Advisory Publication: April 15, 2015

Latest Update: April 15, 2015

Vulnerability Type: Improper Input Validation [CWE-20]

CVE Reference: *

OSVDB Reference: 120807

CVSS Severity (version 2.0):

CVSS v2 Base Score: 4.3 (MEDIUM) (AV:N/AC:M/Au:N/C:N/I:P/A:N) (legend)

Impact Subscore: 2.9

Exploitability Subscore: 8.6

Access Vector: Network exploitable; Victim must voluntarily interact with attack mechanism
Access Complexity: Medium
Authentication: Not required to exploit
Impact Type: Allows unauthorized modification

Discover and Reporter: Wang Jing, Division of Mathematical Sciences (MAS), School of Physical and Mathematical Sciences (SPMS), Nanyang Technological University (NTU), Singapore. (@justqdjing)




Advisory Details:

(1) Vendor & Product Description:




Product & Vulnerable Version:


3.12 3.0 2.4 2.3 2.2 2.1 2.0 1.1


Vendor URL & Download:

NetCat can be downloaded from here,


Product Introduction Overview: is russian local company. “NetCat designed to create an absolute majority of the types of sites: from simple “business card” with a minimum content to complex web-based systems, from corporate offices to online stores, libraries or media data – in other words, projects completely different directions and at any level of complexity. View examples of sites running on NetCat CMS can be in a special section.”

“Manage the site on the basis of NetCat can even inexperienced user, because it does not require knowledge of Internet technologies, programming and markup languages. NetCat constantly improving, adds new features. In the process of finalizing necessarily take into account the wishes of our partners and clients, as well as trends in Internet development. More than 2,000 studios and private web developers have chosen for their projects is NetCat, and in 2013 sites, successfully working on our CMS, created more than 18,000.”




(2) Vulnerability Details:

NetCat web application has a computer security bug problem. It can be exploited by HTML Injection attacks. Hypertext Markup Language (HTML) injection, also sometimes referred to as virtual defacement, is an attack on a user made possible by an injection vulnerability in a web application. When an application does not properly handle user supplied data, an attacker can supply valid HTML, typically via a parameter value, and inject their own content into the page. This attack is typically used in conjunction with some form of social engineering, as the attack is exploiting a code-based vulnerability and a user’s trust.

Several NetCat products 0-day vulnerabilities have been found by some other bug hunter researchers before. NetCat has patched some of them. Web Security Watch is an aggregator of security reports coming from various sources. It aims to provide a single point of tracking for all publicly disclosed security issues that matter. “Its unique tagging system enables you to see a relevant set of tags associated with each security alert for a quick overview of the affected products. What’s more, you can now subscribe to an RSS feed containing the specific tags that you are interested in – you will then only receive alerts related to those tags.” It has published suggestions, advisories, solutions details related to cyber security vulnerabilities.


(2.1) The programming code flaw occurs at “/catalog/search.php?” page with “&q” parameter.





Related Articles:




Alle Links zu New York Times Artikel Vor 2013 anfällig für XSS-Angriffe

Alle Links zu New York Times Artikel Vor 2013 anfällig für XSS-Angriffe


URLs, um Artikel in der New York Times (NYT) vor 2013 veröffentlicht wurden gefunden anfällig für einen XSS (Cross-Site Scripting) Angriff der Lage ist, Code im Kontext des Web-Browsers ausgeführt werden zu können.



Basierend auf nytimes die Gestaltung, fast alle URLs vor 2013 sind betroffen (Alle Seiten von Artikeln). In der Tat, alle Artikel Seiten, die Schaltfläche “Drucken”, “Jede Seite” Taste enthalten, werden “Seite *” Taste “NEXT PAGE” -Taste beeinflusst.


Nytimes geändert diesen Mechanismus seit 2013. Es decodiert die URLs, seine Server gesendet. Dadurch ist der Mechanismus nun viel sicherer.


Jedoch werden alle URLs vor 2013 immer noch mit dem alten Mechanismus. Das bedeutet fast allen Artikelseiten vor 2013 sind immer noch anfällig für XSS-Angriffe. Ich denke, der Grund, nytimes keine URLs filtern, bevor die Kosten. Es kostet zu viel (Geld und Humankapital), um in der Datenbank nach Artikel gepostet, bevor ändern.


Die Sicherheitslücke wurde von einem Mathematik Doktorand Wang Jing von der Schule für Physikalische und Mathematische Wissenschaften (SPMS), Nanyang Technological University, Singapur.


POC und Blog Erklärung von Wang gegeben,


Unterdessen sagte Wang: “Die New York Times hat einen neuen Mechanismus jetzt angenommen. Dies ist eine bessere Schutzmechanismus.”



Auch wenn die Artikel sind alt, sind die Seiten noch relevant
Ein Angriff auf neueren Artikel würde auf jeden Fall haben erhebliche Auswirkungen gehabt, aber Artikeln von 2012 oder sogar noch älter sind alles andere als überholt. Es wäre immer noch im Rahmen eines Angriffs von Bedeutung sein.


Cyberkriminelle können verschiedene Möglichkeiten, um den Link, um potenzielle Opfer zu senden und aufzuzeichnen hohen Erfolgsraten, alle mit mehr gezielte Angriffe zu entwickeln.



Was ist XSS?
Cross-Site Scripting (XSS) ist eine Art von Computer-Sicherheitslücke in der Regel in Web-Anwendungen gefunden. XSS ermöglicht es Angreifern, clientseitige Skript in Webseiten, die von anderen Benutzern eingesehen zu injizieren. Eine Cross-Site-Scripting-Schwachstelle kann von Angreifern wie der Same Origin Policy verwendet werden, um Zugangskontrollen zu umgehen. Cross-Site Scripting auf Webseiten durchgeführt entfielen rund 84% aller Sicherheitslücken von Symantec ab 2007 dokumentiert (Wikipedia)





Tous les liens vers les articles du New York Times Avant 2013 vulnérable aux attaques XSS

Tous les liens vers les articles du New York Times Avant 2013 vulnérable aux attaques XSS


URL vers des articles dans le New York Times (NYT) publiés avant 2013 ont été trouvés à être vulnérables à un (cross-site scripting) attaque XSS capable de fournir le code doit être exécuté dans le contexte du navigateur web.


Basé sur la conception de NYTimes, Presque toutes les URL avant 2013 sont affectés (Toutes les pages d’articles). En fait, toutes les pages d’articles qui contiennent bouton “Imprimer”, “PAGE SINGLE” bouton “page *” bouton, le bouton “Page suivante” sont touchés.


Nytimes changé ce mécanisme depuis 2013. Il décode les URL envoyées à son serveur. Cela rend le mécanisme beaucoup plus en sécurité maintenant.


Cependant, toutes les URL avant 2013 utilisent encore l’ancien mécanisme. Cela signifie presque toutes les pages de l’article avant 2013 sont encore vulnérables à des attaques XSS. Je suppose que la raison NYTimes ne filtre pas avant URL est le coût. Ça coûte trop cher (de l’argent et le capital humain) pour changer la base de données de tous les articles publiés auparavant.




La vulnérabilité a été trouvé par un étudiant de doctorat en mathématiques Wang Jing de l’École de sciences physiques et mathématiques (SPMS), Université technologique de Nanyang, à Singapour.


POC et Blog explication donnée par Wang,


Pendant ce temps, Wang a dit que “Le New York Times a adopté un nouveau mécanisme maintenant. Ce est un meilleur mécanisme de protection.”



Même si les articles sont vieux, les pages sont toujours d’actualité
Une attaque sur les articles les plus récents aurait certainement eu un impact significatif, mais les articles de 2012 ou même plus sont loin d’être obsolète. Ils seraient toujours pertinente dans le contexte d’une attaque.


Les cybercriminels peuvent concevoir plusieurs façons d’envoyer le lien aux victimes potentielles et d’enregistrer des taux de réussite élevés, toutes les attaques ciblées plus avec.

Quel est XSS?
Cross-site scripting (XSS) est un type de vulnérabilité de la sécurité informatique trouve généralement dans les applications Web. XSS permet aux pirates d’injecter un script côté client dans des pages Web consultées par les autres utilisateurs. Un cross-site scripting vulnérabilité peut être utilisée par des attaquants afin de contourner les contrôles d’accès tels que la politique de même origine. Cross-site scripting effectué sur des sites Web a représenté environ 84% de toutes les vulnérabilités de sécurité documentés par Symantec à partir de 2007. (Wikipedia)







Des vulnérabilités pour les boutons types « S’identifier avec Facebook »

Quelques semaines seulement après la découverte du bug Heartbleed, les utilisateurs moyens comme vous et moi pourraient s’inquiéter d’un autre problème très répandu qui ne sera pas facile à réparer. Il s’agit du bug « Covert Redirect » récemment révélé par Wang Jing, un étudiant en doctorat de mathématiques à l’université de technologie de Nanyang à Singapour. Le problème a été détecté au sein des célèbres protocoles Internet OpenID et OAuth. Le premier est utilisé quand vous vous identifiez dans des sites qui utilisent vos profils Google, Facebook, LinkedIn, etc. Le deuxième est utilisé quand vous vous autorisez des sites, des applications ou des services avec Facebook/G+/etc., sans révéler pour autant votre mot de passe à ces sites externes. Ces deux protocoles sont utilisés ensemble et vous pourriez bien être en train de communiquer vos informations aux mauvaises personnes.


Facebook Hacker received reward for Remote code execution vulnerability

La menace

Nos amis de Threatpost ont une explication du problème plus technique ainsi qu’un lien vers la recherche originale, mais nous vous épargnerons les détails inutiles et allons vous décrire le possible scénario d’attaque et ces conséquences. Premièrement, dans le cas où un utilisateur visiterait un site d’hameçonnage qui utilise le bouton « S’identifier avec Facebook ». Un site peut ressembler de prêt à un service populaire ou se faire passer pour un tout nouveau service. Ensuite, une vraie fenêtre Facebook/G+/LinkedIn s’ouvrira, demandant à l’utilisateur de rentrer son nom d’utilisateur et son mot de passe afin d’autoriser le service à accéder au profil de l’utilisateur. Enfin, l’autorisation d’utiliser le profil est envoyée au mauvais site (d’hameçonnage) en utilisant une redirection incorrecte.


Une vraie fenêtre Facebook/G+/LinkedIn s’ouvrira, demandant à l’utilisateur de rentrer son nom d’utilisateur et son mot de passe afin d’autoriser le service à accéder au profil de l’utilisateur.


En fin de compte, un cybercriminel reçoit l’autorisation d’accéder au profil de la victime (jeton OAuth) avec toutes les permissions que les applications ont en général, et dans le pire des cas, avec l’habilité d’accéder aux contacts de l’utilisateur, d’envoyer des messages, etc.

Est-ce réparé ? Pas vraiment.

Cette menace ne disparaîtra pas de si tôt, car la réparation devra être aussi bien réalisée du côté du fournisseur (Facebook, LinkedIn, Google, etc.) que du côté du client (le service ou l’application externe). Le protocole OAuth est toujours en version Beta et plusieurs fournisseurs utilisent différentes mises en place qui varient selon leur habilité de contre-attaquer l’attaque mentionnée précédemment. LinkedIn est mieux positionné pour mettre en place la réparation et gère les choses de manière plus stricte en exigeant que le développeur du service externe fournisse une « liste blanche » des redirections correctes. Pour le moment, chaque application qui utilise une autorisation LinkedIn est soit sécurisée soit non fonctionnelle. Les choses sont différentes pour Facebook qui dispose malheureusement d’un très grand nombre d’applications externes et peut-être d’une version de OAuth plus ancienne. C’est pourquoi les porte-paroles de Facebook ont informé Jing que la création d’une liste blanche « n’est pas quelque chose qui pourra être mis en place à court terme ».

Il existe de nombreux autres fournisseurs qui semblent être vulnérables (regardez la photo), donc si vous vous identifiez dans certains sites en utilisant ces services, vous devez prendre des mesures.

Votre plan d’action

Pour les plus prudents, la solution infaillible serait d’abandonner l’utilisation d’OpenID et ces fameux boutons « S’identifier avec… » pendant quelques mois. Cela vous permettra peut-être également de renforcer votre confidentialité, car autoriser ces identifications sur des réseaux sociaux rend votre activité en ligne plus facile à suivre et permet à de plus en plus de sites de lire vos données démographiques de base. Pour éviter d’avoir à mémoriser différents identifiants sur tous ces sites, commencez à utiliser un gestionnaire de mots de passe efficace. La plupart des services, de nos jours, sont équipés de clients multiplateformes et de synchronisation avec le Cloud afin de garantir un accès à vos mots de passe sur tous les ordinateurs que vous possédez.


Néanmoins, si vous avez l’intention de continuer à utiliser l’autorisation OpenID, il n’y a pas de danger immédiat. Vous devez juste faire attention et éviter les arnaques d’hameçonnage qui commencent typiquement par un message étrange dans votre boîte de réception ou par un lien provocateur sur Facebook et autres réseaux sociaux. Si vous vous authentifiez dans un service utilisant Facebook/Google/etc., assurez-vous que vous accédez au site de ce service en tapant l’adresse manuellement ou en utilisant un marque page, et non pas le lien contenu dans vos e-mails ou votre messagerie. Vérifiez bien la barre d’adresse afin de ne pas vous rendre sur des sites louches et ne souscrivez pas de nouveaux services avec OpenID, sauf si vous êtes certain à 100% que le service est réputé et qu’il s’agit bien du bon site. De plus, nous vous conseillons d’utiliser une solution de navigation sécurisée telle que Kaspersky Internet Security – Multi-Device qui empêchera votre navigateur de visiter des endroits dangereux tels que des sites d’hameçonnage.

Il s’agit juste de mesures de précaution, que tous les utilisateurs Internet devraient prendre chaque jour, car les menaces d’hameçonnage sont très répandues et efficaces et peuvent mener à toutes sortes de pertes numériques, y compris à la perte de numéros de carte bancaire, d’identifiants de messagerie, etc. Le bug « Covert Redirect » dans OpenID et OAuth n’est qu’une raison supplémentaire de les suivre, et ce, sans exception.




Articles Liés:






Continúan los problemas: OAuth y OpenID también son vulnerables

Un nuevo fallo de seguridad amenaza Internet. En este caso se trata de Covert Redirect y ha sido descubierto por un estudiante chino en Singapur. Las empresas tienen en sus manos solucionar este problema.




Cuando aún resuenan los ecos de Heartbleed y el terremoto que sacudió la red, nos acabamos de enterar que otra brecha de seguridad compromete Internet. En este caso se trata de un fallo que afecta a páginas como Google, Facebook, Microsoft, Linkedin, Yahoo, PayPal, GitHub o que usan estas herramientas de código abierto para autenticar a sus usuarios.


Este error permitiría a un atacante haga creer a un usuario que una nueva ventana que redirija a Facebook es segura cuando en realidad no lo es. Hasta aquí la técnica se parece al phishing pero lo que hace lo hace diferente es que Covert Redirect, que así se llama el nuevo exploit, usa el dominio real pero hace un bypass del servidor para conseguir la info. Lo mejor que podemos hacer cuando estemos navegando y pulsemos en un sitio que abre un pop up que nos pide logearnos en Facebook o Google es cerrar esa ventana para evitar que nos redirija a sitios sospechosos.


Wang Jing, estudiante de doctorado en la Universidad Técnica de Nanyang (Singapur), es quien ha descubierto la vulnerabilidad y le ha puesto nombre. El problema, según Jing, es que ni el proveedor ni la compañía quieren responsabilizarse de esta brecha ya que costaría mucho tiempo y dinero. Seguramente, ahora que se conoce el caso, las compañías se pondrán manos a la obra.




Artículos Relacionados:

Falha de segurança afeta logins de Facebook, Google e Microsoft

internet connection concept, 3d generated image

Um estudante de PHD de Singapura, Wang Jing, identificou a falha, chamada de “Covert Redirect”, que consegue usar domínios reais de sites para verificação de páginas de login falsas, enganando os internautas.


Os cibercriminosos podem criar links maliciosos para abrir janelas pop-up do Facebook pedindo que o tal aplicativo seja autorizado. Caso seja realizada esta sincronização, os dados pessoais dos usuários serão passados para os hackers.


Wang afirma que já entrou em contato com o Facebook, porém recebeu uma resposta de que “entende os riscos de estar associado ao OAuth 2.0″ e que corrigir a falha “é algo que não pode ser feito por enquanto”.


O Google afirmou que o problema está sendo rastreado, o LinkedIn publicou nota em que garante que já tomou medidas para evitar que a falha seja explorada, e a Microsoft negou que houvesse vulnerabilidade em suas páginas, apenas nas de terceiros.


A recomendação do descobridor da falha para os internautas é que evitem fazer o login com dados de confirmação de Facebook, Google ou qualquer outro serviço sem terem total certeza de que estão em um ambiente seguro.



Especialistas: erro é difícil de corrigir

O site CNET ouviu dois especialistas em segurança virtual sobre o assunto. Segundo Jeremiah Grossman, fundador e CEO interino da WhiteHat Security, afirma que a falha “não é fácil de corrigir”. Segundo Chris Wysopal, diretor da Veracode, a falha pode enganar muita gente.


“A confiança que os usuários dão ao Facebook e outros serviços que usam OAuth pode tornar mais fácil para os hackers enganarem as pessoas para que elas acabem dando suas informações pessoais a ele”, afirma Wsyopal.




notícias relacionadas:

하트블리드 이어 ‘오픈ID’와 ‘오쓰(OAuth)’서도 심각한 보안 결함


‘하트블리드(Heartbleed)’ 버그에 이어 가입자 인증 및 보안용 오픈소스 SW인 ‘오픈ID’와‘오쓰(OAuth)’에도 심각한 결함이 발견됐다고 씨넷, 벤처비트 등 매체들이 보도했다.


싱 가폴난양대학교에 재학중인 ‘왕 징(Wang Jing)’ 박사는 수 많은 웹사이트와 구글, 페이스북, 링크드인, MS, 페이팔 등에서 사용하고 있는 로그인 툴인 ‘OAuth’와‘오픈ID’에 치명적인 결함이 발견됐다고 밝혔다. ‘코버트리디렉트(Covert Redirect)’라고 일컬어지는 이 결함은 감염된 도메인의 로그인 팝업을 통해 해킹이 이뤄진다.


가 령 인터넷 사용자들이 악의적인 피싱 사이트를 클릭하면 가입자 인증을 위해 페이스북 팝업 윈도가 뜨는데 가입자를 속이 기위해 가짜 도메인 이름을 사용하는 것이 아니라 진짜 사이트의 도메인을 활용한다고 한다. 만일 가입자가 로그인을 하면 합법적인 사이트가 아니라 피싱사이트로 e메일 주소, 생일, 연락처 등 개인 정보들이 흘러들어간다.


왕 은 페이스북 등 업체에 이 같은 결함을 알렸으며 페이스북은 결함이 OAuth 2.0가 연관된 것으로 인식하고 있지만 짧은 시간내 해결될 수는 없을 것이란 답을 얻은 것으로 알려졌다. 왕은 이번 결함이 구글, 링크드인, 마이크로소프트, 페이스북, 페이팔 등 다수의 오픈ID와 OAuth를 활용하는 기업들이 영향을 받을 것으로 예상했다.


왕 은 “제3의 애플리케이션 개발자들이 화이트리스트를 엄격하게 적용하면 해커 공격의 빌미를 제공하지 않을 것”이라고 말했다. 하지만 “실제로 많은 애플리케이션 개발자들이 여러가지 이유로 이런 조치를 취하지않고 있다는 게 OAuth 2.0과 오픈ID의 결함 문제를 심각하게 만들고 있다”고 덧붙였다.




Sicherheitslücke in OAuth 2.0 und OpenID gefunden


Wang Jing, Student an der Nanyang Technological University in Singapur, hat nach dem Bekanntwerden des OpenSSL-Heartbleed-Lecks, eine weitere schwere Sicherheitslücke entdeckt, diesmal in den Authentifizierungsmethoden OAuth 2.0 und OpenID. Die als “Covert Redirect” (“Heimliche Umleitung”) benannte Sicherheitslücke ermöglicht es Angreifern, dem Nutzer einen echt aussehenden Login-Screen unterzujubeln und sich so Zugriff auf die bereitgestellten Daten zu verschaffen. Das gefährliche daran: Die Sicherheitslücke besitzt – anders als bisher bekannte Fishing-Versuche – eine legitime Domainadresse, kann also über einen Blick in die URL-Zeile des Browsers nicht oder nur sehr schwer entlarvt werden. Auf OAuth 2.0 und OpenID bieten inzwischen zahlreiche Webdienste um einen direkten Login in andere Dienste und Apps zu ermöglichen, darunter auch Google, Facebook, Microsoft und Co.


So ist es möglich, dem Nutzer eine Mail mit einem speziell präparierten Link zukommen zu lassen, ein Klick auf diesen öffnet eben wie gesagt eine legitime Adresse samt entsprechendem Logo. Autorisiert der Nutzer dann diese Anfrage und loggt sich in den Dienst ein, so werden die Daten nicht an die vermeintliche App weitergeleitet, sondern gelangen eben in den Besitz des Angreifers. Je nachdem, welche Daten abfragt werden, bekommt dieser somit also E-Mail-Adresse, Geburtsdatum, Kontaktlisten und dergleichen. Ebenso ist es möglich, den Nutzer nach dem Login auf eine beliebige Webseite, welche unter Umständen Malware verbreitet, weiterzuleiten.




Die Lösung des Problems könnte aber – wenn es überhaupt einmal eine geben sollte – eine langwierige Sache sein. Wang Jing hat bereits etliche größere Anbieter der Loginmethoden angeschrieben und über die gefundene Sicherheitslücke aufgeklärt, hierbei gab es jedoch unterschiedliche Aussagen. Im Hause Google beobachtet man das Problem, Microsoft ist sich keiner Schuld bewusst und schiebt die Sicherheitslücke an Drittanbieter ab. Lediglich Facebook scheint hier ehrlich zu sein und gibt an, dass es sich dabei um ein grundsätzliches Problem von OAuth 2.0 und OpenID handelt – möchte man nicht eine umfangreiche Whitelist mit sämtlichen nicht-schädlichen Apps pflegen, ist die Sicherheitslücke nicht “mal eben so” zu beheben. Im Grunde dürften sich sämtliche Gegenmaßnahmen negativ auf die Nutzererfahrung auswirken, was natürlich keiner der Dienste in Kauf nehmen möchte – und so bleibt es hierbei scheinbar beim “kleineren Übel” für die Anbieter.

So bleibt eigentlich nur die Möglichkeit, auf OAuth 2.0 oder OpenID als Login-Methode für Drittanbieter Dienste und Apps zu verzichten oder genauestens darauf zu achten, auf was man klickt. Hat man keine explizite Autorisierung angestoßen, sollte man die geöffneten Tabs umgehend schließen und darauf hoffen, dass sich nicht doch irgendwo ein falscher Link eingepfercht hat.


Сингапурский студент обнаружил серьезную уязвимость в OAuth и OpenID

OAuth и OpenID — очень популярные протоколы, которые совместно используются для авторизации и аутентификации. Приложение OAuth генерирует токены для клиентов, а OpenID предоставляет возможность децентрализованной аутентификации на сторонних сайтах, раскрывая персональные данные пользователей.

Студент Ван Цзин (Wang Jing) с факультета математики Наньянского технологического университета в Сингапуре нашел способ, как злоумышленник может перехватить персональные данные пользователей, перенаправив их на вредоносный сайт после авторизации. Речь идет об уязвимости типа скрытого редиректа (covert redirect), по аналогии с известной атакой open redirect.


В этом случае провайдер (Facebook, Google и проч.) видит, что информацию запрашивает нормальное приложение, но на самом деле пользователя скрыто направляют на другой сайт, заменив значение redirect_uri в URL.


Уязвимость затрагивает множество крупных сайтов, такие как Facebook, Google, Yahoo, LinkedIn, Microsoft, VK, Mail.Ru, PayPal, GitHub и другие. Все они выдают по запросу злоумышленника персональные данные пользователя. В случае Facebook это может быть имя, фамилия, почтовый адрес, возраст, место жительства, место работы и проч.


Кстати, open redirect входит в число 10 главных атак за 2013 год по версии OWASP.

Ван Цзин опубликовал видеоролик, в котором показывает способ эксплуатации уязвимости, на примере Facebook OAuth 2.0. По его словам, защититься от таких атак можно только с помощью «белого списка» сайтов для редиректа.