HP Security Products Blog
From applications to infrastructure, enterprises and governments alike face a constant barrage of digital attacks designed to steal data, cripple networks, damage brands, and perform a host of other malicious intents. HP Enterprise Security Products offers products and services that help organizations meet the security demands of a rapidly changing and more dangerous world. HP ESP enables businesses and institutions to take a proactive approach to security that integrates information correlation, deep application analysis and network-level defense mechanisms—unifying the components of a complete security program and reducing risk across your enterprise. In this blog, we will announce the latest offerings from HP ESP, discuss current trends in vulnerability research and technology, reveal new HP ESP security initiatives and promote our upcoming appearances and speaking engagements.

Top Five Web Application Vulnerabilities 8/17/09 - 8/30/09

1) Adobe Flex SDK 'index.template.html' Cross Site Scripting Vulnerability


Adobe Flex SDK is susceptible to a Cross-Site Scripting vulnerability. This can be exploited to execute code in the browser of an unsuspecting user and steal cookie-based authentication credentials in context of a web application built using the SDK. Updates which resolve this issue are available. Contact the vendor for additional information.


http://www.securityfocus.com/bid/36087


2)Adobe ColdFusion Multiple Vulnerabilities


Adobe ColdFusion is susceptible to multiple vulnerabilities including instances of Cross-Site Scripting, HTML Injection, session fixation, and information disclosure. Victims can have their session hijacked and give an attacker unauthorized access to the application. Other possible attacks include having content added into a web server’s response, which can then be used to steal cookie-based authentication credentials, execute arbitrary code in context of the site, or simply alter how the site appears. The information disclosure vulnerability could also reveal sensitive information which could  lead to more damaging attacks. Updates which address each of these vulnerabilities are available. Contact the vendor for more information.


http://www.securityfocus.com/bid/36046 (HTML Injection)
http://www.securityfocus.com/bid/36096  (Double-Encoded NULL Character Information Disclosure)
http://www.securityfocus.com/bid/36056  (Cross Site Scripting)
http://www.securityfocus.com/bid/36053 (Multiple Cross-Site Scripting)
http://www.securityfocus.com/bid/36054 (Session Fixation)


3) Adobe JRun Multiple Unspecified Cross-Site Scripting Vulnerabilities


Adobe Jrun is susceptible to multiple instances of Cross-Site Scripting. If successful, Cross-Site Scripting can be exploited to manipulate or steal cookies, create requests that can be mistaken for those of a valid user, compromise confidential information, or execute malicious code on end user systems. Updates which resolve this issue are available. Contact the vendor for more details.


http://www.securityfocus.com/bid/36050


4)  IBM WebSphere Commerce Unspecified Information Disclosure Vulnerability


IBM WebSphere Commerce is susceptible to an information disclosure vulnerability.  An attacker can gather sensitive information, possibly leading to brute-force attacks against user accounts. Updates which resolve this vulnerability are available. Contact the vendor for further information.


http://www.securityfocus.com/bid/36151


5) Xerox WorkCentre Web Services Extensible Interface Platform Unauthorized Access Vulnerability


Xerox WorkCentre is susceptible to a unauthorized access vulnerability. An attacker can leverage this vulnerability to access the device’s configuration settings and possibly acquire customer passwords. An advisory and patch which resolves this issue have been released. Contact the vendor for additional details.


http://www.securityfocus.com/bid/36177

Top Five Web Application Vulnerabilities 7/20/09- 8/2/09

1) Hitachi Multiple Business Logic Products Unspecified Cross-Site Scripting Vulnerability


Multiple Hitachi Business Logic products are susceptible to a Cross-Site Scripting vulnerability. If successful, Cross-Site Scripting can be exploited to manipulate or steal cookies, create requests that can be mistaken for those of a valid user, compromise confidential information, or execute malicious code on end user systems. An advisory and updates which address this issue have been released. Contact the vendor for additional information.


http://www.securityfocus.com/bid/35793


2) IBM Tivoli Identity Manager Session Fixation Vulnerability


IBM Tivoli Identity Manager is susceptible to a session fixation vulnerability.  Victims who are enticed into visiting a malicious URI can have their session hijacked and give an attacker unauthorized access to the application. A fix has been released. Contact the vendor for further details.


http://www.securityfocus.com/bid/35779


3) Apache HTTP Server HTTP-Basic Authentication Bypass Vulnerability


Apache HTTP Server is susceptible to an HTTP-Basic authentication bypass vulnerability.  Successful exploitation will give an attacker access to protected resources, likely leading to more damaging attacks.  A fix has not yet been released. Contact the vendor more information.


http://www.securityfocus.com/bid/35840


4) WordPress Multiple Cross-Site Scripting Vulnerabilities


WordPress is susceptible to multiple instances of Cross-Site Scripting. These vulnerabilities can be exploited to execute code in the browser of an unsuspecting user and steal cookie-based authentication credentials.   A fix has not yet been released for the 'wp-comments-post.php' issue, while a patch that resolves the Comment Author URI issue is available. Contact the vendor for additional information.


http://www.securityfocus.com/bid/35797
http://www.securityfocus.com/bid/35755


5) Bugzilla 'show_bug.cgi' Information Disclosure Vulnerability


Bugzilla is susceptible to an information disclosure vulnerability. Successful exploitation would give an authenticated attacker access to sensitive information, and would likely lead to more damaging attacks.  A fix has been released. Contact the vendor for more details.


http://www.securityfocus.com/bid/35916

Top Five Web Application Vulnerabilities 6/08/09 - 6/23/09

1) F5 Networks FirePass SSL VPN Unspecified Cross-Site Scripting Vulnerability


F5 Networks FirePass SSL VPN is susceptible to a Cross-Site Scripting vulnerability.  If successful, Cross-Site Scripting can be exploited to manipulate or steal cookies, create requests that can be mistaken for those of a valid user, compromise confidential information, or execute malicious code on end user systems. An update which resolves this issue has been released. Contact the vendor for more details.


http://www.securityfocus.com/bid/35312


2) ModSecurity SQL Injection Rule Security Bypass Vulnerability


ModSecurity is susceptible to a SQL Injection rule security bypass vulnerability due to improper validation of user-supplied input.  An attacker can leverage this to bypass security restrictions and perform a number of web-application attacks.  A fix has not yet been released. Contact the vendor for additional information.


http://www.securityfocus.com/bid/35323


3) Apache Tomcat 'RequestDispatcher' Information Disclosure Vulnerability


Apache Tomcat is susceptible to an information disclosure vulnerability. Successful exploitation would give an attacker access to sensitive information which could likely be used to conduct more damaging attacks. Updates which resolve this issue have been released. Contact the vendor for further information.


http://www.securityfocus.com/bid/35263


4) FireStats 'firestats-wordpress.php' Remote File Include Vulnerability


FireStats is susceptible to a remote file include vulnerability due to improper validation of user-supplied input. Successful exploitation could lead to a complete compromise of the application and underlying system.  The latest version (1.6.2) resolves this issue. Contact the vendor for more information.


http://www.securityfocus.com/bid/35367


5) Kerio MailServer WebMail Cross Site Scripting Vulnerability


Kerio MailServer WebMail is susceptible to a Cross-Site Scripting vulnerability. Cross-Site Scripting occurs when dynamically generated web pages display user input, such as login information, that is not properly validated, allowing an attacker to embed malicious scripts into the generated page and then execute the script on the machine of any user that views the site.  Updates which resolve this issue have been released. Contact the vendor for further details.


http://www.securityfocus.com/bid/35264


 


 


 

Educating the Massess About Security

In my last post I talked about zombies and warnings and such (and, ok, a little bit about security). I'm not too surprised at the press the sign changing is getting, since traffic and driving are things the vast majority of us deal with. However, I'm disappointed that very few people in the mainstream media are taking the opportunity to talk about broader security issues.


I searched, and did not find one interview with a sign manufacturer to talk about how physical or keypad/password security will be improved in the future, or with DOT management about purchasing better locks and changing default passwords. Sadly, there are tons of articles talking about the applicable laws and crimes a person could be charged with if caught tampering with these devices.


Additionally, some of the reports are talking about removing information from the internet. Take this Associated Press article:



Some Web sites, such as Jalopnik.com, have published tutorials titled "How to Hack an Electronic Road Sign" as a way to alert security holes to traffic-safety officials. Wert said he had no immediate plans to take down Jalopnik's how-to guide.


Has removing information from the internet ever actually succeeded in either keeping that information private or protecting a resource? There have been a few cases where it was a complete and notable failure (DECSS T-Shirt, anyone?). Kudos to Mr. Wert for keeping the information on the web site--it's already in several other places already. The horse is already out of the bag.


Mitch Wagner over at InformationWeek wrote:



It's easy to scold those government agencies for failing to take basic safety measures, and I suppose it's justified -- but, still, road departments have other things to do. Like, y'know, taking care of the roads.


No! No! No! It is completely justified to "scold" them, and it is absolutely their responsibility (and the manufacturer's) to secure their equipment and job sites. Mr Wagner says their job is "taking care of the roads," which implies keeping them safe, which means keeping hooligans from changing road signs. It's not a giant leap.


It's everyone's job to take basic security precautions. How different would this story would be if the first widespread misuse of this information was as part of a terrorist attack?


 

Your online persona –trouble for you?

I keep reading in articles (which are generally meant to scare “regular people”) about how you should limit the personal information you reveal to websites like Facebook, LinkedIn, etc. A friend of mine, when job hunting, even password protected his website and requested cached pages be removed from various engines.

 

Couple this with some recent posts I’ve seen about people search engines (which love to say they search the “deep web”) getting better at aggregating this information, I decided it was the time to see what was out there about me.

 

So armed with my name, an email address, and the name of the town I live in (none of which is too hard to track down), I decided to see what I could find out about myself out there on the tubes. The results surprised me.

 

My first stop was pipl.com, which can search by email, name (with city/state), username or phone. Pipl searches various social networking sites, as well as common web resources. From MySpace, it claimed that I live in Cranston, RI (not true—and I told it so in my search) and that I am a serious Goth who is a Guitar Hero fanboy (not true. OK, I do enjoy a little Guitar Hero). It pulled up my LinkedIn profile accurately enough, and some other true info.

 

When I searched Pipl by email address, oddly, I got back an error that said “No results found for <redacted>@comcast.net.” The interesting thing is that the comcast.net address isn’t remotely close to what I typed in. So I tried it again, and this time it found no results for “Masongeary.”  Apparently, this is what others are searching on (I contacted Pipl and within the hour they responded that the issue was resolved). The third time, it actually pulled up some old mail list posts that were mine. They can’t even keep your search query straight, let alone the info about you.

 

Next up, I tried 123people.com. This one pulls back pictures of “me”… interesting:


Pictures of Chris Sullo?

Think I’m in there? Think again (though one of those faces looks oddly familiar…hmmm...).  They also got some info correct, but added to my online persona that I’m an indoor track runner (nope, sorry) and a soccer player (nope, sorry again). Apparently, I like to upload videos to YouTube (which I’ve never done).

 

Next up was Spokeo. This site has a special section for HR Recruiters… interesting. It claims I have three social networks, and I can tell that one of them is correct—but the other two I’m not sure about. It wants greenbacks to tell me for sure, so there’s where my experiment ends with this site.

 

I tried several others. Zoominfo.com says I worked at “Massachusetts Maritime.” Isearch.com thinks I may live in Nashville, Los Angeles, or perhaps my name is actually “Lil Chris.” Spock.com suggests I own a spa or maybe a law firm.

 

And The Google?  Well, it makes some of those same mistakes… and the image search is no better than 123people.com’s (it pulled up a bunch of other guys, including a high-jumper—yeah right!).

 

So what’s the point of all this? Good question. Some of the information I found out about me is true, and some of it I never knew—I’m actually beginning to feel a little like Ed Norton in Fight Club. Armed with my email address and/or name, what would a recruiter or hiring manager think they found out about me?  It’s not news to me that there is a high concentration of the “Sullo” surname in New England (where I am also from), so confusion seems highly likely. As a matter of fact, I once unexpectedly found myself on a conference call with another Chris Sullo (from NY) who also works in security, if you can believe it. Could some other “Chris Sullo” have an impact on a future job prospect? Could I have a negative impact on him (this seems more likely)? 

 

What about identity theft? Sure, some breaches only have a tiny bit of info, but… how much more do they need when your address is out there, your mom’s maiden name is on Geni, and your date of birth and names of y our kid/dog are proudly displayed on Facebook?

 

The privacy advocate in me (which generally rules the roost) is thrilled there is a bunch of confusion. However, as the web gets “deeper” and more information moves online (President Obama’s digital healthcare initiative, anyone?), this is going to be a larger and larger problem.  If we’re not careful about the data we give out to public sources, it will be relatively easy for someone to gather enough information to commit fraud or, at the least, impact decisions on jobs and security clearances.

 

Maybe it’s time I start using a different email address for each web site? A service to do this sort of thing (with less pain than doing it manually) and aggregate my mail would be nifty.

 

For now, I’m just going to change my bio to read: Chris Sullo, the high-jumping, soccer playing, track running, spa and law firm owning, Guitar Hero loving Goth who goes by “Lil Chris” and may or may not live in Los Angeles, Cranston or Nashville, and could work at either Massachusetts Maritime or Hewlett-Packard.

JavaScript strings immutable in Rhino???

Update: Hmmm. I think I'm looking at the wrong thing. This needs more testing/tracing to see exactly whats going on.

Just a quick update from yesterday's post. It appears that Mozilla Rhino (a JavaScript interpreter written in Java) uses Java's String object to represent JavaScript strings inside of the engine. Here is the constructor from /js/src/org/mozilla/javascript/NativeString.java:

 69     private NativeString(String s) {
 70         string = s;
 71     }

This could be bad, depending on what people are storing in JavaScript strings (which are represented as Java String objects). Strings are immutable in Java (and many other languages). You as a developer cannot easily clear out the contents of the String object. As you manipulate a string, mulitple copies are made of its contents. For example consider this Java code:

String foo = "p@$$w0rd";

System.out.print("Your password in upper case is:");

System.out.println(foo.toUpperCase());

There are now two copies of the password string in memory, "p@$$w0rd" and "P@$$W0RD." Noted security expert John Viega has discussed disclosing sensitive data in memory in length.

Why is all of this an issue? Because the JavaScript language spec doesn't provide an information/warnings/guidance about what you should and should not store in JavaScript strings (and really they shouldn't). It's up the designers and implementors of JavaScript interpreters to explain how their interpreter handles data. However I don't now of a single JavaScript interpreter that does this. Rhino certainly contains no warnings that sensitive data should not be stored in JavaScript strings. To make matters more concerning, Rhino is not typically embedded in a web browser where client-side JavaScript strings shouldn't contain sensitive information anyway (yes, I know that web security readers just let out a laugh). Rhino embedded in other programs/projects where the types of data it could be processing are far more diverse than in a web browser and the probability that sensitive data will be present in JavaScript (and thus Java) strings is higher.

All and all, the Mozilla folks should probably modify Rhino so that it uses a StringBuilder Object instead of a String object to represent JavaScript strings. I haven't dug into SpiderMonkey, but hopefully they are clobbering character arrays with junk before freeing it. Interestingly, I just found this article describing situations where compilers will "optimize" memset() calls to override sensitive sting data. Its possible SpiderMonkey leaves sensitive data lying around as well even if they are trying not to!

[snarfs coffee]... wait, What are you doing?


While reading through an article about Firefox 3 on Security Focus today I snarfed my drink when I read the following passage:



The group also rewrote the Password Manager in JavaScript from C++ to eliminate memory errors, Schroepfer said.



Digging a little deeper I find an article talking about how OS keychain tools can interact with Firefox 3's JavaScript password manager. In the comments of the article is the following tidbit:



The JS portions mostly handle DOM interaction and file IO for
signons2.txt. The two main reasons for switching to JS are simpler code
and increased security (eg, no buffer overflows possible)
. Most of the
Firefox frontend is already JS, so this isn’t exactly a radical change.
But, in any case, the actual encryption of logins continues to be done
be a C++ component (using Triple-DES).




 There are numerous things about this that concern me:



  1. JavaScript code is *not* simple. It is highly dynamic, loosely typed, with late bindings. This means short of a syntax error, all your errors are runtime errors. Not fun to debug regardless of how awesome Firebug is. In fact, we have an entire chapter in our  Ajax Security book about nuances of JavaScript (variable scoping and declaration, oddly performing functions, deadlocks/race conditions/live locks with no mutexs, etc) that make it tricky to develop JavaScript. Dumping one language for another solely to improve readability of your code is admitting you are a poor software architect and, frankly, rather of lame.


  2. Moving to JavaScript because most of Firefox/chrome is JavaScript kind of makes sense. Moving to JavaScript from C++ to "fix" buffer overflows and memory problems is a horrible reason. You are admitting you are incapable of solving a very well known problem and the only solution was to move to a language/runtime that removed the problem for you.

  3. Is this JavaScript interface accessible from plugins or other chrome controls? Please don't tell me you just increased what can be done with Cross Zone Scripting attacks.

  4. As is pointed out in the comments of the second article, programs must be very careful when freeing memory that contains passwords. In C you can blast the buffer with junk before a free(). You have to be extremely careful with passwords in memory for managed languages like C# or Java where strings are immutable. JavaScript? No control what-so-ever over how string data is stored and destroyed. Does Spidermoney or Rhino handle JavaScript strings securely? Hmmmm...



All and all, this is a scary jolt first thing in the morning.
Search
Showing results for 
Search instead for 
Do you mean 
About the Author(s)
HP Blog

HP Software Solutions Blog

Featured


Follow Us
Labels
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.