CVE-2014-7292 Newtelligence dasBlog Dest Redirect Privilege Escalation Security Vulnerability

Exploit Title: Newtelligence dasBlog Dest Redirect Privilege Escalation Vulnerability
Product: dasBlog
Vendor: Newtelligence
Vulnerable Versions: 2.3 (2.3.9074.18820) 2.2 (2.2.8279.16125) 2.1(2.1.8102.813)
Tested Version: 2.3 (2.3.9074.18820)
Advisory Publication: OCT 15, 2014
Latest Update: OCT 15, 2014
Vulnerability Type: Open Redirect [CWE-601]
CVSS v2 Base Score: 5.8 (MEDIUM) (AV:N/AC:M/Au:N/C:P/I:P/A:N) (legend)
Impact Subscore: 4.9
Exploitability Subscore: 8.6
Exploitability Subscore: 8.6
Credit: Wang Jing [Mathematics, Nanyang Technological University (NTU), Singapore] Advisory Details:

(1) Vendor URL:
https://searchcode.com/codesearch/view/8710666/ https://www.microsoft.com/web/gallery/dasblog.aspx



(2) Vulnerability Description:
“Newtelligence dasBlog ct.ashx is vulnerable to Open Redirect attacks.
dasBlog supports a feature called Click-Through which basically tracks all links clicked inside your blog posts. It’s a nice feature that allows the blogger to stay informed what kind of content readers like. If Click-Through is turned on, all URLs inside blog entries will be replaced with <URL to your blog>/ct.ashx?id=<Blog entry ID>&url=<URL-encoded original URL> which of course breaks WebSnapr previews.”

Web.config code:
<add verb=”*” path=”ct.ashx” type=”newtelligence.DasBlog.Web.Services.ClickThroughHandler, newtelligence.DasBlog.Web.Services”/>

(3) Vulnerability Detail:
Newtelligence dasBlog has a security problem. It is vulnerable to Open Redirect attacks.

(3.1) The vulnerability occurs at “ct.ashx?” page, with “&url” parameter,.
Solutions:
2014-10-15 Public disclosure with self-written patch.

References:

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.

 

thedhruvsoni_1372883880_65


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,
https://www.youtube.com/watch?v=RekCK5tjXWQ
http://tetraph.com/security/xss-vulnerability/new-york-times-nytimes-com-page-design-xss-vulnerability-almost-all-article-pages-are-affected/

 

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)

 

 

 

 

Google Covert Redirect Vulnerability Based on Googleads.g.doubleclick.net

Google Covert Redirect Vulnerability Based on Googleads.g.doubleclick.net

Bypass Google Open Redirect Filter Based on Googleads.g.doubleclick.net
— Google Covert Redirect Vulnerability Based on Googleads.g.doubleclick.net

The vulnerability exists at “Logout?” page with “&continue” parameter, i.e.
The vulnerability can be attacked without user login. Tests were performed on Firefox (26.0) in Ubuntu (12.04) and IE (9.0.15) in Windows 7.

(1) When a user is redirected from Google to another site, Google will check whether the redirected URL belongs to domains in Google’s whitelist (The whitelist usually contains websites belong to Google), e.g.
If this is true, the redirection will be allowed.
However, if the URLs in a redirected domain have open URL redirection  vulnerabilities themselves, a user could be redirected from Google to a vulnerable URL in that domain first and later be redirected from this vulnerable site to a malicious site. This is as if being redirected from Google directly.
One of the vulnerable domain is,
googleads.g.doubleclick.net (Google’s Ad System)

(2) Use one webpage for the following tests. The webpage address is “http://www.inzeed.com/kaleidoscope“. We can suppose that this webpage is malicious.
Vulnerable URL:

POC:

POC Video:
Reporter:
Wang Jing, School of Physical and Mathematical Sciences, Nanyang Technological University, Singapore.
Related Articles:

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.

 

Schermata-02-2456342-alle-15.29.47-Web-Security1-520x290

 

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,
https://www.youtube.com/watch?v=RekCK5tjXWQ
http://tetraph.com/security/xss-vulnerability/new-york-times-nytimes-com-page-design-xss-vulnerability-almost-all-article-pages-are-affected/

 

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)

 

 

 

 

 

références:

Microsoft Live Online Service OAuth 2.0 Covert Redirect Web Security Bugs (Information Leakage & Open Redirect)

logo_msHotmailVertical_web

 

Microsoft Live Online Service OAuth 2.0 Covert Redirect Web Security Bugs (Information Leakage & Open Redirect)




(1) Domain:
live.com

 

 

 

 

(2) Vulnerability Description:

Live web application has a computer security problem. Hacker can exploit it by Covert Redirect cyber attacks.



The vulnerabilities can be attacked without user login. Tests were performed on Microsoft IE (10.0.9200.16750) of Windows 8, Mozilla Firefox (34.0) & Google Chromium 39.0.2171.65-0 ubuntu0.14.04.1.1064 (64-bit) of Ubuntu (14.04),Apple Safari 6.1.6 of Mac OS X Lion 10.7.

 

 


(2.1) Vulnerability Detail:

Live’s OAuth 2.0 system is susceptible to Attacks. More specifically, the authentication of parameter “&redirct_uri” in OAuth 2.0 system is insufficient. It can be misused to design Open Redirect Attacks to Live.

 

It increases the likelihood of successful Open Redirect Attacks to third-party websites, too.

 

The vulnerability was reported to Microsoft. Microsoft replies “We have completed our investigation and concluded that the vulnerability exists in idp.plane.edu.au and not login.live.com. I would recommend reporting this issue to plane.edu.au. We will be closing this case.”

 

 

The vulnerabilities occurs at page “/oauth20_authorize.srf?” with parameter “&redirect_uri”, e.g.
https://login.live.com/oauth20_authorize.srf?client_id=0000000040069047&scope=wl.basic&response_type=code&redirect_uri=http%3A%2F%2Fidp.plane.edu.au%2Fsimplesaml%2Fmodule.php%2Fmultiauth%2Fselectsource.php%3FAuthState%3D_c96d1f2d80c2dd6116e61ac3f08a7fa4c9b4454d4b%253Ahttp%253A%252F%252Fwww.tetraph.com%252Fessayjeans%252Fpoems%252Ffish_water.html [1]

 

 

 

Before acceptance of third-party application:

When a logged-in Live user clicks the URL ([1]) above, he/she will be asked for consent as in whether to allow a third-party website to receive his/her information. If the user clicks OK, he/she will be then redirected to the URL assigned to the parameter “&redirect_uri”.

 

If a user has not logged onto Live and clicks the URL ([1]) above, the same situation will happen upon login.

 

After acceptance of third-party application:

 

A logged-in Live user would no longer be asked for consent and could be redirected to a webpage controlled by the attacker when he/she clicks the URL ([1]).

 

For a user who has not logged in, the attack could still be completed after a pop-up page that prompts him/her to log in.

 

 

 

 

(2.1.1) Live would normally allow all the URLs that belong to the domain of an authorized third-party website. However, these URLs could be prone to manipulation. For example, the “&redirect_uri” parameter in the URLs is supposed to be set by the third-party websites, but an attacker could change its value to make Attacks.

 

Hence, a user could be redirected from Live to a vulnerable URL in that domain first and later be redirected from this vulnerable site to a malicious site unwillingly. This is as if the user is redirected from Live directly. The number of Live’s OAuth 2.0 client websites is so huge that such Attacks could be commonplace.

 

Before acceptance of the third-party application, Live’s OAuth 2.0 system makes the redirects appear more trustworthy and could potentially increase the likelihood of successful Open Redirect Attacks of third-party website.

 

Once the user accepts the application, the attackers could completely bypass Live’s authentication system and attack more easily.

 

It might be of Live’s interest to patch up against such attacks.

 

 

 

(2.2) Used one of webpages for the following tests. The webpage is “http://lifegrey.tumblr.com/“. Can suppose it is malicious.

 

Below is an example of a vulnerable third-party domain:
idp.plane.edu.au

 

 

Vulnerable URL in this domain:
http://idp.plane.edu.au/simplesaml/module.php/multiauth/selectsource.php?AuthState=_c96d1f2d80c2dd6116e61ac3f08a7fa4c9b4454d4b%3Ahttp%3A%2F%2Fwww.tetraph.com%2Fessayjeans%2Fpoems%2Ffish_water.html

 

 

Vulnerable URL from Live that is related to idp.plane.edu.au:
https://login.live.com/oauth20_authorize.srf?client_id=0000000040069047&scope=wl.basic&response_type=code&redirect_uri=http%3A%2F%2Fidp.plane.edu.au

 

 

POC:
https://login.live.com/oauth20_authorize.srf?client_id=0000000040069047&scope=wl.basic&response_type=code&redirect_uri=http%3A%2F%2Fidp.plane.edu.au%2Fsimplesaml%2Fmodule.php%2Fmultiauth%2Fselectsource.php%3FAuthState%3D_c96d1f2d80c2dd6116e61ac3f08a7fa4c9b4454d4b%253Ahttp%253A%252F%252Fwww.tetraph.com%252Fessayjeans%252Fpoems%252Ffish_water.html

 

 

 

(2.3) The following URLs have the same vulnerabilities.
https://oauth.live.com/authorize?client_id=0000000044072822&scope=wl.basic%20wl.offline_access%20wl.signin%20wl.birthday%20wl.emails%20wl.phone_numbers%20wl.postal_addresses%20wl.share%20wl.work_profile&response_type=code&redirect_uri=http://www.denglu.cc/dl_receiver.php&state=31482_windowslive_284401

 


POC Video:
https://www.youtube.com/watch?v=z3Eq6GJsHWI

 

Blog Detail:
http://tetraph.blogspot.com/2014/05/microsoft-lives-oauth-20-covert.html



(3) What is Covert Redirect?

Covert Redirect is a class of security bugs disclosed in May 2014. It is an application that takes a parameter and redirects a user to the parameter value without sufficient validation. This often makes use of Open Redirect and XSS (Cross-site Scripting) vulnerabilities in third-party applications.

 

Covert Redirect is also related to single sign-on. It is known by its influence on OAuth and OpenID. Hacker may use it to steal users’ sensitive information. Almost all OAuth 2.0 and OpenID providers worldwide are affected. Covert Redirect can work together with CSRF (Cross-site Request Forgery) as well. After Covert Redirect was published, it is kept in some common databases such as SCIP, OSVDB, Bugtraq, and X-Force. Its scipID is 13185, while OSVDB reference number is 106567. Bugtraq ID: 67196. X-Force reference number is 93031.

 

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









Related Articles:
http://tetraph.com/security/covert-redirect/microsoft-lives-oauth-2-0-covert-redirect-vulnerablity/
https://twitter.com/tetraphibious/status/559168921534603264
https://tetraph.wordpress.com/2014/09/06/microsoft-live-vulnerability/
http://computerobsess.blogspot.com/2014/07/microsoft-live-exploit.html
http://webcabinet.tumblr.com/post/119496963567/securitypost
http://tetraph.blog.163.com/blog/static/2346030512014440315992/
http://securityrelated.blogspot.com/2014/07/microsoft-live-exploit.html
http://www.inzeed.com/kaleidoscope/covert-redirect/microsoft-lives-oauth-2-0-covert-redirect-vulnerablity/
http://whitehatpost.lofter.com/post/1cc773c8_706b622
https://computertechhut.wordpress.com/2014/09/02/microsoft-live-vulnerability/