4Chan, a group of immature script-kiddies that anonymously post online and organize “attacks” against various groups, organizations, and websites, are it again. This time, it’s not the Church of Scientology they’re attacking, but innocent children. As the BBC reports, members of 4Chan have been uploading videos containing explicit sexual content in droves to YouTube today, specifically targeting children.

The videos uploaded by members of 4Chan consisted of children’s clips that start off innocently enough, showing cartoons and other rated-G material usually targeted at children around 5 years old, but soon enough change to videos of adults engaged in sexual activity. 4Chan has the uncanny ability to strike a nerve, driving even the most liberal of internet users to condemn their behavior as pure evil. The problem is, the anonymous 4Chan members are perversely motivated by this sort of response, and cannot be shamed into bringing an end to their disgusting activities.

This isn’t the first time 4Chan does something that can only be described as pure evil. In March of 2008, 4Chan members flooded an internet board for victims of epilepsy with fast-moving and colorful images intending – and succeeding – in bringing about photosensitive seizures in visitors to the site. The last attack was carefully planned to occur just over the Easter weekend, guaranteeing less moderator activity on the forum and giving the attackers a bigger window of opportunity to maximize their damage.

The difference between the behavior that 4Chan engages in and what just about every other script kiddy organization on the web does is that 4Chan doesn’t do it to prove a point. They don’t do it just to prove they can, they do it to hurt. And the malicious intent makes all the difference. The internet isn’t the best place to pride yourself in holding the moral high ground, but in cases like this, it’s near impossible to understand just what it is that makes people like this tick.

Obviously there is no clear solution to bringing about the end of groups like 4Chan, but someone needs to do something, or else we’re all guilty of standing by and letting evil go.

Facebook recently conducted a poll which showed up on the homepage newsfeed, and asked Facebook members just how exactly did they think Facebook’s “friend finder” worked when it prompted them for their email address & password in order to get a list of contacts. The numbers pretty much speak for themselves, here’s what they looked like near the end of the campaign:

Now ignore the dark blue bar: it’s a red herring and doesn’t contain any interesting info. The real juicy bit is the “Yes” option, and its 20% response.

20% of Facebook’s 80 Million active users (give or take) believe that the passwords for their email addresses are being stored when they use the Friend Finder…. and that doesn’t bother them in the least. That’s sixteen million people who don’t give a damn about their privacy, the contents of their email, or who has control of their entire online personas.

This is a subject that’s been chewed half to death already countless times by people far more in the know than myself; Jeff Atwood’s excellent article on the topic covers the dangers of sites asking for users’ email addresses & passwords, and – far more importantly – presents several more secure alternatives for web application developers looking to expand their social networks.

To put things in perspective, take a look at this downright horrifying tale on ReadWriteWeb about software that prompted users for their email addresses & passwords, then proceeded to save them for malicious use… then realize that 16 million Facebook users out there don’t care if this happens to them. Think about all the private, sensitive, confidential information available on your email account and just how truly terrible it would be for that info to fall in the wrong hands.

Of course all this begs the question: who’s to blame for this bout of end-user stupidity (for lack of a more politically-correct term)? Is it naïveté/trust in the goodwill of others that gets users to give out such sensitive data to people (Facebook has 500 employees!) they don’t know from Adam? Or is it that they just don’t get how dangerous it can be (see the ReadWriteWeb article for proof)? Or is it, maybe, that they’ve simply gotten accustomed to being asked for their email address and corresponding password by “trusted” sites they love to visit, too caught up in the “gather as many friends as you can” game to give a second thought to identity theft and fraud?

Personally, I can recall a time when most “normal people” I know would refuse flat-out to share such sensitive data with a site (phishing, tech support, etc. obviously excluded); but in the wake of “Web 2.0” it’s become so normal to ask for email addresses and passwords that no one ever gives it a second thought.

And it’s not just Facebook. To be totally frank, even if Facebook were to store end users’ passwords in their database, the access to that info would probably be very highly guarded… but when every new social network on the block is suddenly doing the same thing – you can get a good picture of just how easy it would be to steal users’ passwords.

MQ’s 3 Steps for World Domination

1. Send out an email purporting to be from “the hottest new social network around” informing the recipient that their “friends” want them to join: “Click here to show Peter you’re a real friend!”
2. Get the user to register a new account – make the procedure as pain-free and simple as possible… and right then and there on the registration page ask for the user’s email address and password so as to “make it easy to tell all your friends you care and get popular really fast…”
3. Profit.

As soon as it’s OK for one person to do it, it’ll be OK for everyone to… and then we’ll be in too deep to do anything about it.

So why does Facebook – after polling their end users and seeing just how dire the situation is – continue to use the same flawed mechanism of harvesting email addresses… especially when better, safer alternatives exist?

It would seem that between the way Gmail saves and retrieves sessions, existing sessions are authenticated, and views are cached there are one or more loopholes that allow data from a different account (that has nothing to do with yours) to be served instead of the correct data.

I don’t know why, but here’s the how:

• Firefox 3 opened to Gmail on Ubuntu.
• Session accidentally reset with ctrl+alt+bkspc
• Upon reboot & restarting of Firefox, Firefox requested the URIs that were previously open before the crash, partially loading data from local cache and the rest dynamically from the web (because of the AJAX portions of the Gmail interface).

The result:

• Gmail loaded up the email account of a user I’d never contacted before, never heard of, and never knew existed.
• I could see the front page of this user’s inbox, including the people he’d recently contacted, the brief summary of all messages, the total number of messages in the inbox, the number of unread messages in other folders, the dates of all correspondences, and a number of contacts (again, none that I have had contact with) in the sidebar.
• The number of remaining Gmail invites, the amount of space used, and other status values also reflected this mysterious individual’s account.
• I couldn’t browse deeper than the main page of the inbox. Emails couldn’t be opened, nothing past the first 50 correspondences could be seen, and I couldn’t switch to another folder.
• Attempts to do any of the above resulted in Gmail’s “Oops… the system encountered a problem (#102) – Retrying in XXs… <Retry Now>”

Parts of the Gmail interface contained values pertaining to my own account (for instance, the online status indicator) while others referred to this other individual’s account instead.

It’s very bizarre. I don’t know if it can be readily reproduced, but I’d imagine if you forced an exit of Firefox 3 and kept on firing it back up at some point or another you’d see similar behavior. Of course, a deeper analysis of what data Firefox 3 requests from Gmail’s servers verses what’s served from the local session cache may yield further information that could possibly be used to actively take advantage of this data leak.

It seems that Firefox requests a cached session complete with cookies and all from the Gmail URI, which in turn loads the Gmail javascript files that are responsible for retrieving the data associated with a particular email account via AJAX. At this point, either the session key is associated with another account and so Gmail retrieves the information assumming the session to be properly authenticated or else the expired session somehow causes Gmail to get data from elsewhere…

Screenshots of this behavior:

Gmail displaying the other user’s information:

Searching for this user in my own account yields no results:

As we’ve previously mentioned, NeoSmart Technologies is a big proponent of Full Disclosure. We’ve contacted the security department at Google and will post their reply if/when it’s available. We’ve also taken what we feel are the appropriate steps in this case with regards to the screenshots above in terms of what’s been made visible and what’s been blanked out for privacy concerns.

Update

The Google Security Team sent a reply to our inquiry. According to them, this behavior might be caused by broken ISP proxying, pending further investigation. This post will be further updated as soon as new information becomes available.

Update

Google has confirmed that was the result of an ISP caching/proxing problem, and that it’s been known to happen. It seems some ISPs are over zealous in their caching attempts (probably to save some money) – and you can add Cyberia to that list. Much thanks to Chris Evans of the Google Security Team for his feedback on the issue and prompt responses – that’s the way security is supposed to be handled!

This morning I came across such an event that penetrated that virtual suite of armor when I read this Wired.com article about a recent script-kiddy attack on a web forum run by The Epilepsy Foundation – the news is so bad it makes one’s blood boil. A group of crackers launched a bone-chillingly cold-blooded and thoughtless attack on the members of the epilepsy forum. They weren’t looking for money, private info, fame, or acknowledgement — they were merely searching for a way to cause as much physical and mental harm as possible.

Epilepsy, as defined by Wikipedia:

Epilepsy is a common chronic neurological disorder that is characterized by recurrent unprovoked seizures. These seizures are transient signs and/or symptoms due to abnormal, excessive or synchronous neuronal activity in the brain. About 50 million people worldwide have epilepsy at any one time.

This particular attack focused on hacking the forum to display images that triggered epileptic attacks in visitors; invoked by a series of images flashing at pre-determined intervals showing certain shapes and patterns that are known to cause seizures to people suffering from epilepsy.

Everyone has seen the photosensitive seizure warning on video games at one point in time or the other – they’re there for a reason. Epileptic attacks are not a joke, and purposely invoking such an attack on innocent website visitors as some sick person or persons’ sick idea of a joke must not be tolerated.

What’s even worse is that the first round of attack was not enough for the perpetrators. Instead, a second attack followed which used javascript exploits to redirect visitors to more-complex images and animations; affecting even more people.

The compromised forum posts and code were available for approximately 12 hours:

But she’s satisfied with the Epilepsy Foundation’s relatively fast response to the attack, about 12 hours after it began on Easter weekend. "We all really appreciate them for giving us this forum and giving us this place to find each other," she says.

While that may not seem like too long of a time, if you consider the fact that these are human beings being attacked and not machines or web-browsers then 12 hours turns into a lifetime – after all, for some people this really is a matter of life or death.

At the moment evidence suggests that "Anonymous," a group of crackers recently come to fame for their web-cracking endeavors; the true identity of the perpetrator(s) remains unknown. But whoever it is, this kind of ridiculous, immature, and down-right evil attacks most not be tolerated by the tech community at large.

Most people take a look at these three facts, and instantly come to a conclusion.. the wrong conclusion: you can’t properly manage a Windows server because it’s inherently lacking in the shell scripting department.

But that’s not true… Because here’s another fact for you:

Perl scripts are a drop-in replacement for 99% ((We admit, that’s a made up statistic, give us a break though, will ya?)) of all shell scripting needs.

And another fact:

Perl (unlike PHP) runs great (awesome, in fact) on Windows.

Now with these two facts in mind, you can now make a proper conclusion: Shell scripting on Windows doesn’t have to be difficult, limiting, or in any way inferior than on Linux.

Perl is an awesome language. Between the online Perl community and the millions of Perl-scripting samples across the web, it’s quite the well-documented language and no sysadmin has an excuse not to use it. The Perl modules are an extensive array of easy-to-use pluggable scripts that you just reference and run.

Perl was created for stuff like this. It’s the language of choice for hacking quick scripts that get the job done, easily, quickly, and with little pain or effort. A Perl script made to run on Linux will likely run on Windows too, with little to no hacking necessary for most of the stuff out there.

With Perl, you can easily do things like manage (prune, grep, or sort) log files, backup and FTP or email database server dumps, schedule webserver maintenance, and more.

Shell scripting with Perl is even easier than shell scripting in Bash – simply because of the huge libraries available that make even the most mundane and PITA tasks quite easy. It takes all of 6 statements (we’re purposely refraining from counting lines because this is Perl we’re talking about) to compose an email with your MySQL dumps as a GZIP’d attachment.

You can easily schedule Perl scripts to run at regular intervals with the Task Scheduler – but that’s about all you’ll ever need to interact with Windows for.

A quick Google search will reveal millions of results for “Perl server management scripts.” Take your pick, hack it, and run.

Here’s our 5-step guide to managing your server with Perl scripts:

1. Download and install Perl for Windows (ActivePerl, free).
2. Read the Perl FAQs and get familiar with the syntax. It’s nothing too complicated, and very simple to code in (though reading someone else’s code is another story). You absolutely don’t need anything more than the basic syntax, stuff like classes and functions are completely unnecessary for shell scripting – it’s too easy to even be considered programming!
3. Write your Perl script. Use a real text editor like Notepad++.
4. Test it by running it from the command line and ensuring it does what you need. Repeat step 3 as needed.
5. Open up Scheduled Tasks in the Control Panel and set up a new task to run your Perl script however often you like.

Sure, maybe it’s not as easy it looks and it’ll probably take you a day or so to go from absolute zero to cranking your first Perl-based shell script; but soon enough you’ll be doing it blindfolded and with both your hands behind your back. And it’ll only be one line long, too!

The most important thing to realize is, you don’t need to be a programmer (or become one) in order to shell script in Perl.

Just pretend your Perl script is a batch file (yuck!). The Perl processor will run it from top to bottom, in a very straight-forward manner. Put one task/command per-line, stick loops where needed, and test constantly. You don’t need classes, you don’t need data structures, you don’t need object orientation, and you don’t even really need to use variables if you don’t want to!

We’ll be posting more details, guides, sample shell scripts, and how-to’s on Perl-based shell scripting in the weeks and months to come. Don’t give up just because it involves learning something new, this is in an investment that’ll last a lifetime. If you can shell script in Perl on Windows, you can do the same on Linux and OS X with ease. If you can shell script in Perl, you can do anything!

View all articles in the “Shell Scripting with Perl” category.

This sound isn’t the one you get on startup (which is still there, just like in previous versions of Windows), but rather the one that plays right when Windows finishes loading – and you can’t do a thing about it. In our opinion, it’s a quite nice sound, but unfortunately you don’t get to hear it (most of the time) if you have a analog/digital sound card with analog being the default. At any rate, for those of you that don’t like it, chin up: it can be changed!

1. Grab reshacker (or XN Resource Editor, if you prefer), they’re both invaluable utilities that you should always keep at your side when you want to hack just about any program or feature on Windows.
2. Copy C:\Windows\System32\imageres.dll to another location, and open it with reshacker.
3. Open the WAVE subfolder, and select the appropriate localized resource as follows:
4. If you’re using XN Resource Editor, you don’t need to worry about this step: skip on to number 5. Each language has a different code in Windows; in this example, we’re working on a United States English copy of Vista, which has language code 1033. Referring to the list of language codes, German would be 1031, and Spanish is 1034. Open the subfolder pertaining to your particular language code.
5. You need to replace resource name (number?) 5051 with a Wave file of your own – resource 5051 is the default Windows Vista startup sound, and you’re going to replace it with your own custom (wave!) file.
6. Save and exit.
7. Backup the original \Windows\System32\imageres.dll file, replace the existing one with your newly-modified uber-cool version, and reboot to check it out.

The attack lasted around 3 hours, the recovery process another hour or so. We’re sorry for this downtime and are implementing failsafes that will hopefully protect against data corruption in the future. Luckily, our other data is stored on PostgreSQL (with the exception of this blog, which miraculously survived the ordeal unscathed) which is less prone to data corruption in our experience.

We urge anyone with any information about this attack to come forth, and remind the perpetrators that this is a felony punishable under law.

But at NeoSmart Technologies, we always do try to make the best out of whatever situation we’re in, so we took advantage of the downtime to do some server upgrades we’d been planning for a while:

• Apache Tomcat (for the Wiki and Bug Tracker) was upgraded to version 6
• MySQL was upgraded from version 5.1 to version 6.0
• We upgraded PHP from 5.2.1 to 5.2.3
• The IIS rewrite module was re-compiled and upgraded
• Installed an XMPP/Jabber Server
• Several other script changes

At any rate, hopefully this is like lightning and doesn’t strike the same place twice! We’re still here, and we will be for a very long time to come, God willing of course.

Once more, sorry for the downtime, and to those people who unfortunately had their posts vanished in the forums: our deepest apologies.

Anyone using Symantec’s anti-virus software from 2006 and hasn’t updated it is vulnerable to a very powerful complete remote control vulnerability. What does Symantec have to say about it?

Users of Symantec AntiVirus Corporate Edition and Symantec Client Security should apply the appropriate update as soon as possible, Vincent Weafer, a senior director at Symantec Security Response, said Tuesday. However, because there are no known attacks that exploit the flaw, the need to patch is not urgent, he added.

That’s an excerpt from a c|net article dating all the way back to May of 2006 – a year ago now. Thanks to Symantec’s non-chalance and Turner Broadcasting Systems’ (the owners of CNN) complete disregard for standard IT procedures, they were infected earlier today by Rinbot.

Rinbot’s nothing new, it’s an ancient virus that has found a new way of entering your PC: through Symantec’s software. Instead of viruses attacking Microsoft from left, right, top, and under for no truly good reason, here’s a virus that does some good in the world: it brings attention to a billion-dollar monopoly that has been gambling with the security of its users for years now.

What kind of anti-virus product only updates once a week (on Wednesdays). What kind of company labels a complete remote control vulnerability as “unimportant?” And most importantly, what kind of security company lets its product remain installed without updating?

Shame on Time Warner for hiring IT Guys that don’t know how to pick a decent anti-virus solution, and for being too thick to realize they need to manually update Symantec’s software. And shame on Symantec for doing this to its customers. Wake up people, Symantec’s not in it for your security, only your money.

Earlier this week, Symantec released a public press statement that they were ”confident users would see beyond the price” of their new 360 system protection software…. 2 days later: Symantec labels Yahoo! Desktop as a virus – an “honest mistake.”

“There will definitely be some price sensitivity” on the part of users, said Mark Kanok, 360’s product marketing manager. “But the breadth and execution of Norton 360’s functionality is greater [than OneCare's]. And I don’t think anyone should undersell the intelligence of users.”

If anyone is underselling the intelligence of users, it’s Symantec. Can they really believe that people will forever remain enchanted by their flourescent yellow coloring and not immediately switch to better alternatives, chief of which is NOD32? ((NeoSmart Technologies recommends NOD32 for all home and business users’ AV protection needs. It really works.))

Anyone willing to bet how long the big yellow bubble grows until it pops? Or has it already?

Update: According to CNN, the authors of Rinbot don’t want it called that, but we have no idea what they would like, so that’s why we’re using that name here.

WPA2 seems to be the answer. Instead of WPA’s default (and vulnerable) TKIP packet encryption, it uses AES, ((AES was only optional in the original WPA setup)) with mandatory CCMP support. ((CCMP support was made mandatory by the Wi-Fi Alliance in March of 2006)) Without going into detail, suffice to say that CCMP is, to date, secure and uncrackable.

The only problem? Windows XP isn’t compatible with WPA2-secured networks without a special update for WPA2 encryption support. That’s understandable, after all, WPA2 didn’t come out until after Windows XP SP2. But the problem is, it’s not even on Windows Update! Windows Update, always quick on the mark with the monthly Malicious Software Removal tool and other recommended updates surprised us by not showing the littlest inkling that there was an update as important to security as WPA2 available for download. It’s been available for manual download – only with Genuine Advantage validation – from Microsoft since May 2005… That’s a long time to be waiting! ((Direct Download Link: KB893357))

To complicate matters further, if you’re on Windows XP x64 Edition, you can’t even use WPA2!! So for the companies out there that are trying to protect their Wireless networks from intruders and looking to stay on the bleeding edge with 64-bit versions of Microsoft Windows — You can’t.

There may be a workaround however, for those so inclined. By using the proprietary Intel and Cisco utilities available for connecting to wireless networks, you may be able to get Windows to connect to WPA2-encrypted networks without installing any updates or formatting your PC to get the x86 edition installed.

The bottom line is, we know Microsoft is serious about security and they don’t appreciate the lack of it on Windows any more than we do, but it’s things like this that make people wonder. How hard would it be to label this as a recommended download via Windows Update for all x86 users – and to roll out a version with x64 support before Windows XP x64 SP2 comes out, years from now?

Originally, the WordPress team had refused to patch the WordPress 2.0.6 FeedBurner Bug on the premise that it was too soon to release another version of WordPress for a “minor” bug – which we disagreed with. However, you can now download WordPress 2.0.7 and hopefully this time there aren’t any surprise bugs that need immediate patching. We highly recommend everyone goes and downloads WordPress 2.0.7 immediately in order to avoid anyone compromising their blog/site via the security hole in WordPress 2.0.6.

Correction: WordPress is released and maintained independant from Automattic

Are we the only ones that how that every single MP3/Audio player to date has been successfully stripped of its firmware, souped-up, then published as a how-to on the web? But all that is besides the point: there is no evidence right now that indicates the need for anything as drastic.

First, let’s get one thing clear here: It’s not in Microsoft’s favor to have DRM. Any of it. Microsoft isn’t the author of the media nor does it own RIAA; Microsoft’s concerns are almost assuredly focused solely on maximizing profit and keeping their users happy. That’s the way the business world works. So the only reason DRM is in the Zune in the first place is just because it has to be there: legal reasons, politics, etc.

What that tells us is that Microsoft won’t be going out of its way to make your media-playing experience comparable to a week in the slammer (sorry Michael!). It means that wherever possible, the best-case-scenario is most likely. And it means that whatever DRM is implemented in the Zune, it can’t possibly be so bad as to make this product a big no-no. That’s not Microsoft, Michael Robertson, or us speaking: it’s pure business.

That said, there is undeniably something going on with the wi-fi. No one is really sure right now which media is subject to 3 days/3 plays rule – but that rule is definitely there, and not many like it. But before you scream, think about this: you can’t even share songs on an iPod. i Pods don’t have wi-fi, and until they do, you can’t really compare the two. It’s not a nice rule, we don’t like it any more than you do, but that’s life.

The best you can hope for is that it doesn’t apply to non-Microsoft-downloaded media files, and more importantly, that next-generation Zunes will be able to download songs and media off the net.

But Zune’s DRM isn’t Viral. Never has been, and if the laws of business don’t suddenly change, never will. We’re not to sure who came up with this BS, but it has no sources, and it’s been officially debunked anyhow. Just remember, Microsoft has never pushed the boundaries of DRM, and were against Blu-Ray for that very reason.

What matters in the end is hardware quality, style, price, and us. Just use some common sense, don’t believe every rumor you hear, and remember: worst comes to worst, in a week or less Zune will be running Linux as some hackers celebrate and prepare to release it to the public.

When a person, group, or company discovers a security flaw in a product or service, they have a range of means to communicate this flaw to the outside world. On one side of the scale, most companies explicitly ask that such discoveries be treated with the utmost confidence and not spoken of until they have released a patch. Then you have Full Disclosure wherein the finders reveal any and all associated information, exploits, fixes, and workarounds. At the the very other end are the self-beneficiaries that attempt to sell or else use the exploits for their own self-aggrandizement.

The first option has its obvious merits: when a security hole has been in existence for __ long, it’s a good idea that the company should get a chance to patch their product and set matters straight before the public finds out; lest wily souls get their hands on it and take advantage innocents around the web. But then what’s to guarantee that this kind of thing doesn’t happen again and again? A couple of months ago there was a similar story with MSN and Yahoo! – they’re warned, but it’s easier to just sit around and wait.

Just last week, “hackers” claimed they’d found critical security flaws in Firefox that allow for complete remote control of users’ PCs from afar. Two days later they backed down and confessed it was a hoax — after creating chaos everywhere. Even if it wasn’t a hoax, their original intent of manipulating this security hole for their own “malicious” (Hacker communication network!) purposes could hardly be considered any better.

No matter who finds a bug or what software/product it’s in, Full Disclosure is the only method that can ensure that the right people know about it without too much hassle. With Full Disclosure,

• The holes get fixed. Isn’t that what it’s all about?
• Such vulnerabilities can’t be abused by morally-challenged people.
• It allows end-users a chance to backup their databases and take preliminary steps to securing their sites.
• It provides the affected companies with a solution. If the exact bug and the associated steps of reproduction, the affected files/code, and the extent of damage are reported there really isn’t anything much left.
• It embarrasses the company into taking immediate action and better care.
• You get the credit you deserve for finding the flaw!

When all that is said and done, nothing is perfect. Full Disclosure most certainly can be used and manipulated by people with malicious intent, and the more popular the application, the more potent Full Disclosure becomes.

But Full Disclosure isn’t a strict way of releasing information, it’s just a guideline of sorts. It doesn’t say you can’t warn the originating company a day before and give them a deadline upon which to act. It doesn’t mean you have to tell everyone immediately, nor does it mean you agree to keep mum for a set amount of time. All it means is that, sooner or later, you tell everyone everything, for the good of the general public.

XSS is short for “cross-site scripting” which it really isn’t – but that’s a whole ‘nother story. Basically, in XSS “vulnerabilities” scripts on a page are used to “steal” information from other open browser windows or tabs. XSS refers to scripts embedded in a page that when activated on an end-users system can (but not necessarily) result in a leak of sensitive information.

The problem isn’t so much in the attack itself as much as it is in the usage of the term. XSS is not a real security vulnerability in a product or script since it does not directly result in the loss of data integrity, but rather can be used as a tool in social engineering attacks and can never compromise the security of a server/host under any conditions nor that of an end-user on its own.

XSS is not the problem in and of its own. JavaScript is (largely) the cause, and XSS is but a result of the (many) inherint security holes in client-side scripting languages, specifically JavaScript due to it’s all-encompassing nature and it’s lax code (by nature) and not in the package itself. XSS itself is a tool like mentioned before, nothing more nothing less. But that fact has implications that render the entire foundation of XSS “insecurities” much less worthy of attention than they’re made out to be.

Sites with XSS vulnerabilities aren’t truly insecure. For the most part, they’re absoloutely no different than any other site – except that a user can manipulate the way content displays on an “insecure” page (usually by appending something to the URL or submitting a comment or other user-generated content on the page in question) and make it pose a possible risk to viewers. But it is of course of relevance when a major site presents even the smallest of vulnerabilities. However it is of the utmost importance to note that a page that has an “XSS vulnerablity” is no more dangerous to end users in practice than visiting a random result generated by a Google search – something that most users do all the time.

Sites that have been modified to pose such a risk can only be as dangerous as the scripting language used allows them to be – and as lethal as the browser being used lets them be. When a page has a potential XSS vulnerability, that means nothing. Such a page needs to be first manipulated in a way that embeds a script that can “steal” content from the end-users PC, then it must be sent to the user and by means of social engineering convince the user to open the URI. After that, the attacker has to rely on the user having the information he or she would like to “steal” available, and that the browser doesn’t block such an attack.

What matters in the end is that these products aren’t “defective” and not even truly insecure. They’ve been modified the way the language allows for them to be modified, no more no less.

Even that is inconsequential however, because today all modern browsers protect against XSS attacks in one form or the other. To test that, our testers headed off to OSVDB and searched for “XSS” “pops cookie” and “document.cookie,” which are the words most often associated with XSS vulnerabilities. Although the results varied from one browser to the other and from one build to the next, on average 60% – 70% of the XSS vulnerablities that were present and “functional” in the “last generation” of browsers (Firefox < = 1.0, Opera 8, Internet Explorer 6) didn't work in the "new generation" of browsers (Firefox 2.0-3.0 builds, Opera 9, Internet Explorer 7).

In the end, XSS as a vulnerability rating is abused and thrown around without consequence. It isn’t something new, it isn’t something special, it isn’t (necessarily) a sign of bad code, and it most certainly isn’t an excuse to rip an otherwise excellent product to shreds over security issues that don’t exist. XSS is a security hole and possible cause-of-headache, but beyond that, it isn’t worthy of the attention it gets and pales drastically when compared to the far more dangerous and more worthy security vulnerabilities that plague the web today.

[followup on this article's purpose and impact]

But if this isn’t news worthy, you’re probably wondering why I’m bothering to post about it? Good question, and here are two answers that should provide reason enough…

• NeoSmart Technologies is the original finder of these security holes;
• This may come in conjunction with a IPB 0-Day vulnerability… which is a bit more interesting, and makes it possible for me to post about the phpBB hole.

That said, our team is hard at work verifying the vulnerablities, and you should hear from us before the end of the day. There is most certainly a phpBB vulnerablity, and the same may exist in IPB, but we’re not 100% certain yet.

EDIT:
Please see the forum entry for more details about the phpBB, IPB, and vBulletin bugs. There is a security bulletin up for download, and we urge all phpBB users to follow our suggested workaround immediately!