Apache Tomcat 5.5.25 Deploy/Undeploy/Start/Stop Applications

I and my friend Gianmarco Pirozzi discovered new vulnerabilities affecting Apache Tomcat which allow to perform the following malicious activities:

  • Undeploy an existing application
  • Deploy a new application
  • Stop an application
  • Start an application

For more details you can read our Original Advisory:
Apache Tomcat 5.5.25 Start/Stop/Deploy/Undeploy Application | CSRF Vulnerabilities

MITRE CVE Numbering Authority assigned me CVE-2013-6357 for these vulnerabilities.

My Advisory has been also published in the following web sites:
http://www.securityfocus.com/bid/63515
http://osvdb.org/show/osvdb/99375
http://packetstormsecurity.com/files/123894/Apache-Tomcat-5.5.25-Cross-Site-Request-Forgery.html
http://www.exploit-db.com/exploits/29435/
http://1337day.com/exploits/21455
http://www.scip.ch/en/?vuldb.11098
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-6357
https://bugzilla.redhat.com/show_bug.cgi?id=1030090
http://www.cvedetails.com/cve/CVE-2013-6357/
http://xforce.iss.net/xforce/xfdb/88471
http://en.securitylab.ru/nvd/447679.php
http://www.us-cert.gov/ncas/bulletins/SB13-322
http://www.cvedetails.com/cve/CVE-2013-6357/

D-Link DSL-2740B Multiple CSRF Vulnerabilities | CVE-2013-5730

I’ve discovered new multiple CSRF vulnerabilities affecting D-Link DSL-2740B ADSL router allowing an attacker to carry out malicious activities, as:

  • Disable/Enable Wireless MAC Address Filter.
  • Disable/Enable all the Firewall protections (Both “SPI” and “DOS and Portscan Protection”).
  • Enable/Disable Remote Management (in my exploit I enabled remote management via http – tcp port 80 – and ssh – tcp port 22 -).

Many other changes can be performed.

For more details please read my Original Advisory:
D-Link DSL-2740B Multiple CSRF Vulnerabilities

MITRE CVE Numbering Authority assigned me CVE-2013-5730 for these vulnerabilities.

The vendor (D-Link) confirmed this vulnerability and  is pending a new firmware release that fixes this security issue:
http://securityadvisories.dlink.com/security/publication.aspx?name=SAP10004

My Advisory has been also published in the following web sites:
http://www.securityfocus.com/bid/62356/
http://secunia.com/advisories/54795
http://www.exploit-db.com/exploits/28239/
http://1337day.com/exploits/21225
http://osvdb.org/show/osvdb/97278
http://xforce.iss.net/xforce/xfdb/87036
http://packetstormsecurity.com/files/123200/D-Link-DSL-2740B-Cross-Site-Request-Forgery.html
http://www.securelist.com/en/advisories/54795
http://www.scip.ch/en/?vuldb.10296
http://securityadvisories.dlink.com/security/publication.aspx?name=SAP10004
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-5730
http://cert-mu.gov.mu/English/Pages/Vulnerability%20Notes/2013/VN-2013-220.aspx
http://en.securitylab.ru/nvd/447902.php
Japan CERT (Computer Emergency Response Team)

Update on Google Translate CSRF Vulnerability | Google is fixing the issue

Hey there,
some days ago – 15th of August (2013) – I received the following email from Google Security Team about my latest Google Translate vulnerability:

Hello,
This issue has been fixed and verified by a security engineer – feel free to test and see if we’ve missed anything.
Thanks for all your help!
Regards,
Google Security Team

I cannot hide that, considering what happened in the previous months (read my previous post on this topic),  I have been surprised and happy – I have to admit it :) – to receive an email from Google Security Team in order to inform me that they fixed this vulnerability, independently from the reward that I did not receive.

In the above email they proposed me to test again the vulnerability in order to establish if their fixing activities have been performed correctly.

Yesterday (1st September 2013) I carried out new tests and – unfortunately –  I’ve verified that the vulnerability I discovered is still affecting Google Translate. After the analysis I’ve quickly contacted Google Security team in order to share the results of my tests with the purpose to patch as soon as possible this security issue.

I guess that I will share soon new information about this vulnerability.

Stay tuned!

Translate.google.com | CSRF Vulnerability

I  have discovered a new CSRF vulnerability on translate.google.com web site which could allow an attacker to insert items (Words/Phrases/Urls and related translations) into the user’s Phrasebook. Furthermore an attacker could also insert a potentially malicious Urls – into the above mentioned Phrasebook – towards which the victim could be redirected simply clicking on the “Go to <website>” right-click option on translate.google.com.
The vulnerability is related to a problem into the generation of “xt” anti-CSRF token which is not correctly associated with the user session, allowing an attacker to use any previous generated anti-CSRF parameter – for that specific user- in order to carry out this attack.

For more details, please read my original Advisory:
CSRF Vulnerability on translate.google.com

My research has been also published on PacketStorm:
Google Translate Cross Site Request Forgery

Update (15 August, 2013): I received an email by Google Security Team:

Hello,
This issue has been fixed and verified by a security engineer – feel free to test and see if we’ve missed anything.
Thanks for all your help!

Regards,
Google Security Team

>Google as Web Proxy

>

The simplest  method used to bypass proxy blacklist filter (implemented for example on proxy squid) is to use Google Translate service which can simply become a web proxy. Let’s see how this can be done:
suppose that you would like to go to ivanobinetti.com web site which is blocked by proxy blacklist. You only have to go to:

translate.google.com/translate?u=http://www.ivanobinetti.com

Be careful to select a destination language (that one in which you want to translate) different than original language. For example, if you have a english site you can select italian as destination language and, in general, you can select any language except english (which is original language).
Enjoy your new and always available web proxy.