Rediff XSS, the redux

It seems like my praise for Rediff was too quick. I had not tested out the Rediff search site exhaustively. This was brought to my attention by an OWASP Delhi member. Apparently, our friends at Rediff have not "fixed" the XSS Vulnerability in the search area. My attempts at performing a rudimentary XSS were thwarted, but I hadnt explored the possibility of encoding my payload using Javascript escape(), so this time, I tried and came up with this:













Apparently, the folks at Rediff have performed some very poor input validation and have probably only filtered the "<" and ">".

Rediff Redressal.....

My good deed was done for the week. Everytime one does something good for something or someone, one tends to feel good about it, sometimes even gloat about it.

I was surfing the Rediff Site yesterday, yes, the same one which I had eviscerated previously and entered the vile xss script and expected another tirade of scripts to rain down, but to my surprise discovered that it had been fixed. No more output encoding issues and the malicious payload seemed to have been encoded to prevent malicious XSS payload

Here is the screenshot.














But unfortunately, Rediff has not fixed a small pothole, whereas a large patch of road still remains undone. Several other Rediff sites (Rediff Products) are still vulnerable to XSS.

Screenshot:

OWASP Chennai Meet - 17 May 2009

The OWASP Chennai Chapter meet was held on the 17th of May 2009 at Chennai. It was very nice to see some dynamism from the OWASP Community in India. I am happy to see great steps being taken by the Chennai OWASP Team (Chandrasekar and the rest) in taking initiative.

The talks scheduled for the day were on Globalization and its role in Information Security and Mobile Crimes

I was invited to speak and I spoke on Application Security Risk, in a talk entitled "Application Security Risk - The Full Circle"

Here's the presentation:

OWASP Chennai Talk - Application Security Risk - The Full Circle

View more presentations from abhaybhargav.

This presentation highlights the importance of Application Security Risk and how to perform effective and comprehensive Risk Assessments for Web Applications to provide for a robust protection strategy. It highlights how an effective Application Security Risk Assessment can result in the development of a secure SDLC, feed the Security Testing area with threat modeling and the development of "Abuse Cases" and become the foundation for a strong and secure web application.

Google Hacking with Webex - Cool Recon tool

The idea for this actually sprang from a webex conference I was involved in recently. Before what turned out to be an eventually boring conference, with esoteric Powerpoint slides being shoved into my screen. I received an email from the organization that was hosting the meeting. Upon clicking the link to join the meeting, I was directed to the organization's WebEx Enterprise Site page. where I signed in using a Conference ID and a meeting password. Simple enough.

After the odious meeting I attended, as I signed out of the conference, a feedback form was thrown at me asking me how the meeting went, which I duly ignored and went about my business. This idea actually sprung in my head when I was sitting through the conference and thought about using WebEx to perform some initial reconnaissance activity for a Pen test. I noticed, before signing in that the organization had planned some more sales meetings with what looked like their prospective customers, which intrigued me.

I then put my Google Hacking Hat on and wrote a simple Google query intitle:"WebEx Enterprise Site" based on the title I had seen in the organization's WebEx site. Not surprisingly, several organization's WebEx links popped up in the Google Search results. As I started exploring around, I noticed some very confidential information up for grabs in several sites. Not only could I gain some valuable information about some sales meetings and internal group meetings they had lined up with their prospective clients or already-existing clients, not to mention internal organization members, but also some of them had recorded their conferences and these recordings were available for me to view.

While this is not a "Security Vulnerability" in the traditional, technological sense. It is a way for competitors to get some valuable info about your potential clients or your new offerings to the market (some internal meetings had the names of the products or projects these organizations were currently working on). This, is also an excellent way to perform an all-round Penetration Tests. While the ordinary Pen-test involves performing garden variety Network and App layer exercises, these methods can add significant value to a pen test and provide a bit of the old "Out of the Box" information.

Who's got the last laugh now. The Blogger XSS Vulnerability

I guess I was asking for punishment. I go looking for Web App Vulnerabilities all over the world, and sure as hell, this is what I will get.

I discovered that once I posted my Rediff Search Engine XSS Vulnerability on Blogger, I noticed something I had seen all too often, the Javascript alert with the rudimentary XSS, and this time, it was on my blog. I was not to happy about it to say the least. I thought "Some Smart Alec must have written up a comment causing the XSS alert, but I was quite sure that couldnt happen because Blogger had some sort of a filter on the comments. I then realized that the XSS alerts were popping up because of the XSS vectors in my Rediff post.

Surprisingly Blogger does not do any kind of validation or output encoding to prevent against these attacks in the posts section. So the blog-author can potentially be serving up XSS on his/her blog and potentially be exposing all the visitor's accounts with that, and since Blogger is a Google service, my session credentials are good for any Google Website. Mail, docs, everything.

But its ok now folks, the bitter pill of my own medicine has been swallowed................ or has it?

Rediff Search Engine XSS Vulnerability

This was something which was quite shocking as the series of events unfolded. I was researching up on output encoding methods to prevent against Cross Site Scripting and I experienced the full blown effect of the evils of bad/no output encoding and of course, no Input validation.

This was something I discovered on Rediff.com's search engine. When I typed in "search:followed by the Javascript alert, I received the infamous Javascript alert with simple 'XSS' written all over it. I was a little perturbed, because my NoScript said that it blocked a cross site scripting attack against taking place, but why was the alert still popping up? Then I was sure that the site was vulnerable to cross site scripting and decided to write about it. When I clicked the "Ok" on the Javascript alert box, another one popped up. This was definitely odd, I hadnt configured the alert for more than once. Then I clicked OK once more to find that there were more Javascript alerts to arrive with things like "XSS", session cookie details, "try_xss" and other alerts which I hadn't written. I then realized that rediff's search engine is scouring the web for pages with the XSS variants was executing that script on the rediff site, which was, beyond imagination and quite horrible. As I was clicking "OK" on the Javascript alert boxes new search results kept showing up and new alerts kept popping. The alerts only stopped with the end of the page.

Not only is Rediff vulnerable to XSS, Rediff has failed to encode their outputs from the search engine and is serving the xss, fresh from other websites, which have ironically, encoded their outputs.


I tried this out on a Google page, but it didn't work .

Anyone want to play around with the Search string try and enter your regular XSS reflected XSS tags check it out.

I have informed Rediff about the vulnerability, hopefully, they should rectify it soon.


Here are the series of screenshots of the xss alerts and the search results expanding each time.

The Berkeley Data Theft

I just received word that the University of Berkeley has had a major security incident.

The Campus Health Services Center databases have been hacked (supposedly by foreign hackers) and over 160,000 records of PII (Personally Identifiable Information) have been exposed and may have been stolen.

According to the university, the databases contained individuals' Social Security numbers, health insurance information and non-treatment medical information, such as immunization records and names of some of the physicians they may have seen for diagnoses or treatment.

It is believed that the breach began sometime in the month of October 2008 and continued till April 9th 2009, when the campus administrators discovered the breach. The University has said "The attackers accessed a public Web site and subsequently bypassed additional secured databases stored on the same server."

This seems like another Web Application attack, where the attackers have been able to gain access to Databases using the Web applications and cause the breach. It might be a case of SQL injection coupled with various other types of attacks.

This is a "wake up call" for universities all around the world. Universities are perhaps the largest repositories of data (student data) and they have access to sensitive information about the students. Such breaches can cause massive instances of identity theft.

I find this even more alarming thinking about the Indian state of affairs. India's universities have recently taken to computerization and the number of students in Indian universities is a mind-boggling number of something like 8-10 million. Such security incidents put all that data at risk.

Incredulous Interactions with Web Application Developers: 2 of Many

Here's wishing that all of you have a good weekend. I left early from the office today to attend to some household duties. While I was sitting and watching TV, I came up with a concept, which resulted in this title. I interact with several application developers over the past few years and now as I steeped in AppSec, I have been interacting with a lot of Web Application Developers during my application assessments. Normally, they are a nice bunch, who are quite convinced about the authenticity of my claims of having their applications torn apart on the internet. But, everytime I discuss security, there are always this few developers who end up astounding me or completely disarming my constant efforts to bring about change in the way they think (or don't think) about Web Application Security . I thought, "Why not chronicle my interactions with these people, for the benefit of the community, and for a few laughs (or atleast a smile) in the normally tense lives of security folk?", and so, I present to you, the second in the series of "Incredulous interactions with Web Application Developers". You might be wondering what happened to the first of the series. It is the first entry in this blog, but has not been grouped under this title. Anyway here it goes....

It was at the end of the day, and I had almost finished assessing this application. The application was being developed by a small group of developers working for a small company. Their product claimed to be the only one of its kind and one of their potential clients wanted the application to reviewed for security.

I had reviewed the Application for over 2 days. I had spent some time interacting with the project manager and the developers, and had performed a combination of black and white-box tests on the application. The application had some serious issues, there was almost no validation and whatever little validation it had, it was on the client-side, utilizing trusty old Javascript. I knew it was a problem. The developers were quite sold when I showed them a Cross Site scripting PoC as well as a Embedded Flash injection PoC. The only problem was getting through to the Project Manager. He was not convinced, and a conversation on the following lines ensued.

I used Burp proxy to perform my scripting attacks and he said this. "This application is going to be used only by the Company employees. why will they want to steal this data from the company?", for which I gave him standard insider threat lecture, statistics, et all. I tried explaining to him the fact, that this application stored extremely sensitive data (which it did) and an insider would also have a clear motivation to break into the application to steal information, not to mention disgruntled employees, or other employees with malicious intent. I also explained to him the CSRF angle, where this site might be attacked by another site violating the same origin policy.

He was yet unconvinced and he said, trying desperately to prove a point, "I have worked for over 12 years in Software development and have developed dozens of applications, never before has a client asked me for all the security features you are asking me for, it seems that you just want to prove a point." I burst out laughing at this and told him that if he believed that his potential clients weren't concerned about security, then they wouldn't have engaged my services to perform the assessment. I also had to tell him, that the way he or anyone else has been developing web apps in the cavalier manner that they have been all these years, does not make it right. Quantity is not quality, I told him and I also informed him of the fact, that awareness has been rising in the community about the effects of web application attacks, which is the reason why, if he wants his product to remain competitive and viable in any market, he would have to do "complicated things" like input validation based on a whitelist of "known good" characters to prevent against a smorgasbord of attacks. I told him finally that it would be for the benefit of the application and the data it holds as all these measures would prevent against any untoward incidents and not result in loss of reputation for his company. The man finally backed down after that and we discussed some implementation strategies for input validation across his web app.

This got me thinking, that developers have churned out several thousands of web applications which are working all over the internet and organizational intranets over the years. This was a single project manager from a single small company, who had himself been involved in the development of over 20 applications in his career. It would be quite scary to think of other developers over the years who would have developed similar applications with similar if not worse vulnerabilities.........

Overreliance on Javascript: Pen-tester's pet

I am sure all of you have been acquainted with the input validation situation where the developer validates all his input on the client-side using some poorly written Javascript to boot. Well, I recently experienced a new high in Javascript overreliance, and this was precious!!

I came across an application which relied heavily on Role Based Access Control. The Application is an Enterprise Application which has several types of users and several different "screens" that each user can access, thereby restricting the user's access based on the user's role. Well, this is how a traditional access control system works.

So, what would one do to ordinarily circumvent these controls? The first thing I tried was the URL route, where I scanned the app for URLs and entered these URLs to elevate my privileges. I was easily able to do this and the pages that clearly weren't meant for my user role kept appearing. When I tried to input some data and submit the form, the server threw me a big fat Javascript alert, "Access Denied".

Then I revoked the temporary permissions on my NoScript and the entire application fell apart. The Application so heavily relied on Javascript that the access to the links was controlled using Javascript only.

The code went something like this:

function Menu()
 {
 var UserRole=document.getElementById('userRole').value;

 switch(UserRole)
 {
 case 'elevatedPrivUser':      
  document.getElementById('thisScreen').style.display='none'; 
  break;
 case  'lowerPrivUser':       
  document.getElementById('someOtherScreen').style.display='none';
  break;
 case 'evenLowerPrivUser':
  document.getElementById('yetAnotherScreen').style.display='none';
  break;

As you can see here the Developer had left this brilliant bit of Javascript on each and every page. This was the basis of the Role Based Access Control System of the Application. Then I thought, surely, even if I accessed any one of these pages and tried to submit a request, the server would stonewall me and throw me out. I tried it out. Guess what?....More Javascript. Luckily, the Javascript wasnt available on plain view in that page, but clearly Javascript was the only validation which had been provided to validate user role and by disabling Javascript, I was able to pass my request over to the server which was accepted instantaneously.

So, the next time I go try to test an app for elevation of privileges, I will not bother with the session hijacking or the sniffing. I will just ask my NoScript to do the job and I will check whether the developer believes that "Client-side Scripting is the best!!!!"