The Personal Data Protection and Breach Accountability Act, sponsored by Democrat Richard Blumenthal of Connecticut, would enable the Justice Department to fine businesses with more than 10,000 customers $5,000 per violation per day, with a maximum of $20 million per violation, according to The Hill.

It seems that the core of the legislation is designed to counter the sort of recent high-profile attacks on online sites that held significant consumer data. The bill would fight delays in informing the public when their data has been compromised and eradicate filters to transparency, which would allow the public to know more about how their data is being used and what threats have recently threatened it.

"The amount of time should be measured in hours, not days, at most in days, not weeks," Blumenthal told The Hill.

Photo by WildFire Effects

In 2009, security company Symantec noticed a particularly complex malware code infecting users' computers. At first the company did not think much of it outside of the fact that is was unusually complicated. The company wrote detection and repair codes for it. Once detected, malware usually shrivels and dies. Yet, the malicious code, known as W32.Xpaj.B, did not go away. It morphed and evolved, allowing one group of cyber criminals to use it for years to perpetrate a search engine click-fraud scheme that netted the hackers an easy $62,000 from unwitting advertisers.

Symantec was able to track down the command and control servers that were running W32.Xpaj.B and did a full breakdown on how the scam worked. The results were surprising - a complex code working on top of a simple infrastructure - and showed how easy it is for criminals to set up malware workshops and watch the money roll in.

Symantec wrote a white paper on their findings on W32.Xpaj.B. The virus itself is a classic file that injects itself into other executable files in an attempt to spread through the computer. It has clever bits where it tries to hide detection by using a code mingling approach to obfuscate its signature from the entry point to a file. See picture right.

Once in a computer, the virus will check if it wants to stay there. If part of the code detects a .mil, .gov or int hostname, it will exit the system. Also, the virus will check the host country of the infected device and will exit if it finds it is in one of seven Eastern European countries: Russia, Uzbekistan, Belarus, Kazakhstan, Krygztan, Ukraine or Tatar. Symantec tracked the C&C servers to the Kiev, Ukraine and believe the programmers told the virus to exit those countries to avoid detection by local law enforcement.

Working the Ad Model

W32.Xpaj.B works in the pay-per-click advertising structure. It hijacks users' search queries and clicks through to a fake search engine with results returned that are actually advertisements, not legitimate results. It then makes money when the user clicks on those links.

Sound simple? It is. Also, it is not.

Computers infected with W32.Xpaj.B will effectively add several layers to what is a normal search query. Those first steps are easy.

It is after that point where things gets more complex as the query and the users' computer are redirected several times to reach the fake search engine, which will eventually send it advertisements the programmers want the user to click. The C&C servers contain PHP apps whose script will parse the POST (search) request from the DLL client. If the search term goes through the process clean (and is not bounced out of the process through various IP address associated with search engines) then it is decrypted and extracted. The search term is then submitted to par-per-click ad sites.

It is not done yet, though. The results are sent to the user's computer and the one of the programmer's servers passing through a referrer page. For the user and the advertiser it looks like a click was made from a legitimate transaction. Yet, the programmer has defrauded the advertiser.

Low Barrier For Entry

Through this process, over a period of Sept. 27, 2010 to June 27, 2011, the programmers made on average $170 per day (ranging for $43 to $450) with the cycle of money gradually declining as the virus was eliminated from more computers.

Symantec shows the example of W32.Xpaj.B as how the barrier for criminal fraud on the Internet has been set alarmingly low.

The threat and associated infrastructure, in relative terms, are not complicated. The scheme involving referrer values and redirects in an effort to avoid fraud detection is complex, but the technology used is quite basic. There are several versions of the Web applications on the servers and while the code is growing more sophisticated, it is still very basic. It was only the most recent iteration that utilized an SQL server and even that is done in a primitive manner. The database is effectively used as a flat file format, with no normalization of the schema or database optimization. This simplicity is in stark contrast with the complexity of W32.Xpaj.B, the initial reason for this research.

This is an overview of the findings from Symantec's white paper. If you're interested in further information, check out the company's blog for more details.

Apparently there is no omerta between hackers. The Guardian says that the FBI has so thoroughly infiltrated the hacker community "that it is now riddle with paranoia and mistrust." Arrested hackers often turn into moles for the FBI, acting on behalf of the agency as informants in underground chat rooms and forums to sniff out other hackers susceptible to arrest. Hackers of the world: how likely are you to become a snitch for the U.S. government if you are arrested?

"The good of the many outweighed the good of the one. There were no winners here. I had two options and I took the one that was less wrong," Lamo said of turning in Manning. He said he was sad to see his friend Manning behind bars but viewed him as "any of his friends that has done something reprehensible."

According to The Guardian, Lamo's attitude is probably not shared by the rest of the hacker community. The Guardian interviewed Eric Corley, publisher of hacker publication 2600 who said that, "owing to the harsh penalties involved and the relative inexperience with the law that many hackers have, they are rather susceptible to intimidation." So, unlike Lamo, they are not acting out of some altruistic sense of obligation but rather for fear of hard time. It is the same tactic that local law enforcement has used with petty drug dealers for years in order to climb the ladder to major traffickers.

Next On The Hit List: Hacker Communities

Individual hackers are one type of problem, infiltrating and picking apart hacker collectives like Anonymous or the newly arisen Lulz Security (if it is indeed a separate group of hackers) is another. To a certain extent, there is safety and anonymity in numbers. The way that hacker groups function is not like some normal type of organized crime group either. Anonymous is a global network of hackers working together, many of which (rightfully so) do not trust each other. The way to break up an amorphous collective is to break it into its constituent parts, isolate them and work up the chain of command. Given the distrust already within the hacker community, that may not be as hard as it seems.

The new procedure aims to cut down on the number of rogue applications created by hackers and spammers by forcing developers to share personally identifiable information. Unfortunately, say multiple security researchers, verification alone is not enough to stop these malicious apps.

Last week, we began to wonder if Facebook needed to implement its own anti-malware service after an especially busy weekend where thousands of user accounts were compromised by rogue applications promising tantalizing videos to anyone who was willing to click here. Not surprisingly, many did just that, and ended up on an off-site Web page where malware was installed on their PCs.

On May 15, security firm AVG reported its anti-malware service had blocked more than 30,000 rogue Facebook applications - a number so large, the company's chief researcher officer, Roger Thompson, called it "stunning."

But will the new verification measures actually make dangerous applications a thing of the past? Probably not. Adept spammers will quickly figure out how to bypass the security procedures using stolen credit cards or disposable mobile phones.

Security Researchers Response: It's Not Enough

We asked several security researchers what they thought about the new procedures and none believed the new program was anywhere near strong enough to thwart the onslaught of rogue apps on Facebook.

According to security expert Graham Cluley of Sophos, cybercriminals won't find that bypassing the measures will be very difficult at all, and will likely use stolen credit cards and pay-as-you-go throwaway mobile phone numbers to get their apps verified. He encourages Facebook to do more than the new measures. "As these applications are being made available to an estimated 500 million users, Facebook would be doing its users a real service if they put in place stronger controls over application developers," Cluley says. "After all, what legitimate application developer is going to complain?"

Rik Ferguson, senior security advisor at Trend Micro, calls the new program a small step in the right direction, but also feels better application approval methods are in order. "Facebook will find themselves playing the same old game of whack-a-mole unless they institute some form of application approvals process as is already the case on competitor networks," he warns, again reiterating that neither of the new measures are enough to stop real criminals.

Security Evangelist Ryan Naraine of Kaspersky, agrees, saying the only way Facebook can really fix things is to "implement some form of code signing or code inspections when the app is submitted." However, Naraine admits the new program is at least "a step in the right direction."

Black-hat hackers got into an unnamed website hosted on Amazon's servers then proceeded to install an illegal command and control infrastructure. Named America's number one most wanted botnet, Zeus was discovered on Amazon's Elastic Compute Cloud (EC2) by security researchers yesterday.

Although we don't yet have details on exactly how the website in question was hacked, we have learned that the software has been removed from the Amazon cloud. This incident is the first example of malware being found on AWS' infrastructure.

As we were warned by black hats in April this year, cloud computing carries certain risks and opportunities for exploitation. Our own Sarah Perez wrote:

In another part of the Sensepost presentation, they looked specifically at vulnerabilities of Amazon's Web Services. To start off, they detailed the process involved in setting up a new instance on EC2... While Amazon has provided 47 machine images they built themselves, the remaining 2721 images were build by other EC2 users. Can you really believe that all of these images were built securely? Basically, the template directory is just a big archive of user-generated content. And you know what user-gen content is like... risky.

As John Pescatore told the Financial Times, "The security of these cloud-based infrastructure services is like Windows in 1999. It's being widely used and nothing tremendously bad has happened yet. But it's just in early stages of getting exposed to the Internet, and you know bad things are coming."

Will hackers continue to employ web services to carry out their schemes in 2010? Twitter, Facebook, Google Apps, and now Amazon Web Services have all been used for evil this year. How can websites, corporations, and end users be smarter about online security to avoid personal and financial loss next year? Let us know what you think in the comments.

In other words, if you're the owner of a jailbroken phone, you should now be concerned.

Unlike the relatively innocuous iKee worm which the creator designed more as a "public service" to alert users to the potential for malware on the iPhone, the new hacker tool, dubbed "iPhone/Privacy.A," is the real deal. Where iKee simply switched the iPhone wallpaper to display a photo of singer Rick Astley (a nod to the internet meme of rickrolling), Privacy.A gives the user no indication that it is running on the device.

The new hacker tool also operates a bit differently than iKee does, as it doesn't have to sit on the iPhone itself in order to inflect its damage or spread. The hacker can either load the worm onto their personal device and then monitor the network for jailbroken devices to attack or they can load the malicious program onto a computer. As Intego points out in their post, this computer could be on a public network at an Internet cafe or retail store. In that scenario, the tool would then scan for any other jailbroken iPhones that came within range of the Wi-Fi network and attack them.

How to Secure your iPhone

Although many jailbreakers are tech-savvy enough to know how to lock down their devices to protect themselves from attack, there are quite a few who have simply followed online instructions such as these to perform the jailbreak. This group, while arguably somewhat tech-savvy, doesn't necessarily know all the nitty-gritty details about the iPhone filesystem or its security mechanisms.

To make it easy on these users, we've provided steps on how to change your iPhone's root password - the common denominator required in order for the malware to gain access to your device.

While some may argue there's no need to change your root password if you haven't also installed the SSH program, another necessary element for these attacks to work, we think that's a little short-sighted. It would be easy enough for a malicious hacker to trick jailbreakers into installing SSH by bundling it with some other third-party application offered through underground App Stores like Cydida or Icy. By masquerading as something innocent like a wallpaper-changer or ringtone bundle, a hacker could easily set up a number of jailbreakers with SSH without the victims even being aware that it has been installed. Although we haven't heard of anything like this happening yet, if we thought of it then you can bet that the hackers out there have thought of it too.

Changing the Root Password

The best protection is to simply change your iPhone root password. That will keep you safe from the current iPhone malware...as least for now. Here's how:

1. Install the MobileTerminal application from Cydia.
2. Reboot your iPhone.
3. Launch MobileTerminal and type in the command: passwd
4. At the prompt which asks for the "Old Password," type in: alpine
5. At the new password prompt, type in a new password of your choosing, making sure to pick something strong.
6. Re-enter the password to confirm.
7. You'll then be returned to the Mobile$ prompt which means the change was successful.
8. Now you'll need to change the password for the secondary admin. Type in the command login root.
9. Again, you're prompted for the old password. Type in alpine.
10. Now type in the command passwd
11. You'll then go through the change password routine a second time, entering in alpine as the old password, creating a new password and then re-entering it to confirm.
12. When you are finished, close the application.

Note: these instructions assume you are running iPhone OS 3.0 or higher.

While this incident alone wouldn't generate much excitement given the low-profile nature of the applications affected, it's not the only example of unsafe applications on Facebook. Another researcher just spent an entire month scouring Facebook apps for security vulnerabilities and what he found is disturbing: six of the hacked apps were in the top ten, 9700 applications were affected, and the potential victims totaled 218 million users.

In the case of the hacked Facebook apps found by AVG, the apps had been compromised by the use of "iframes," which are bits of code embedded in the applications themselves. The iframes were able to load content from malicious websites into the applications' pages on Facebook.com, directing app users to install software on their computers by purporting to be an update for an out-of-date Adobe Reader product.

At first, Thompson thought the apps had been hacked by the developers, but as it turned out, it was the developers who were the victims. After looking at the source code for the apps in question, Thompson found that the iframes had been injected into the apps' code due to infected software on the developers' PCs.

Facebook quickly reacted to the situation and took down the compromised apps while also contacted the developers to warn them of the issue.

Thousands of Apps Vulnerable to Attacks

While hacked Facebook apps may still be a bit of a rarity today on the popular social network, security vulnerabilities that could lead to malicious attacks are not. After spending a month on Facebook looking for application bugs, another security researcher made some disturbing findings.

Specifically, the researcher, who goes only by the handle "theharmonyguy" online, was looking for a specific vulnerability he referred to as a "FAXX Hack." FAXX stands for "Facebook Application + XSS + XSRF" or, in other words, a cross-site scripting vulnerability - a certain type of security hole that could allow a hacker to access profile information, including personal details, status updates, and photos of a victimized user and their friends.

The findings showed that many Facebook applications, even those that were widely used and considered trustworthy, lacked basic security precautions. There were some 9700 Facebook applications which were affected by vulnerabilities and nineteen of the applications in question had passed through Facebook's "Verified Application" program, a sort of "stamp of approval" designed to assure Facebook users of an app's general trustworthiness. Among the apps, six were ranked in the top ten by monthly active users including FarmVille, Causes, LivingSocial, Movies, Farm Town, and YoVille. The collective monthly active users counts for all the hacked apps totaled 218 million. However, that previous figure does include overlaps. Also, seven of the top ten application developers on Facebook were found to host at least one vulnerable app. (Note: the 9700 number may seem large but that's due to one vulnerability found in the "Make a Gift!" application. Make a Gift! lets users create their own custom applications for sending gifts, and the myriad of resulting applications are all hosted from the same server.)

While discovering the bugs, the researcher contacted each application developer to make him or her aware of the hole. For the most part, developers responded quickly and took the situation seriously. However, several developers took a while longer to respond. Nine took over a week to patch their application and one even took two weeks. And those delays were not due to the complexity of the required patches - these were, in terms of coding, simple fixes.

What's most concerning about these findings is how widespread the problem was. Unlike the apps AVG discovered, this wasn't a minor, isolated incident affecting a small handful of users. Although the apps in question here were just vulnerable to attacks as opposed to being comprised themselves, it shows how risky it is to use any application, Facebook Verified or not.

Is Any App Safe?

On top of all these security issues, in August many Facebook users were surprised to discover the vast amounts of personal information they were revealing by their use of Facebook quizzes. Even if you limit access to your profile through privacy settings, Facebook quiz applications can see everything on your profile page when you take a quiz...or even when your friend takes one. To make matters worse, Facebook does not screen developers for trustworthiness nor do they require developers to comply with a privacy policy.

With hacked apps, security vulnerabilities, lack of privacy policies, and apps that can read your private profile information, one has to wonder if using any Facebook application is appropriate and safe these days.

Update: Facebook's response: "Developers on Facebook Platform must comply with Platform Policy Guidelines, which require that applications provide a trustworthy user experience. Similarly, applications must post their own privacy policy if they collect any user information. We enforce these guidelines through spot checks and have disabled thousands of apps that we found in violation. We also encourage users to report suspicious apps and practice caution with all of their online activity."

Mitnick is probably a formidable security expert, but the simple fact of the matter is that one man, let alone one company, is unlikely to be able to defend against multiple and persistent attackers. While Mitnick spends up to $20,000 per year on his phone bill, companies are likely spending at least twice that to protect his accounts.

Said Mitnick, "You'd think they'd like to talk to me and say 'how do you think these guys are getting in?" Despite the fact that Mitnick has turned over a new leaf, one might understand why a company like AT&T would rather wash its hands of Mitnick as a client, rather than taking advice from him. After all, Mitnick's combination of hacking and "social engineering" once gave him illegal access to computer systems at Motorola, Nokia, Siemens and allegedly the Pacific Bell Telephone Company - better known as AT&T California.

Today, it appears that Twitter is starting to do something about the problem. According to security firm f-secure, Twitter is now blocking malicious URLs from being posted to their service.

Since the company has not made any official announcement about the new protection, it's unknown at this time if Twitter is using a particular service to provide the lookup capabilities for the malicious URL identification or if they are managing this process in-house. If we had to bet, though, we would go with the former. Maintaining a current "block list" for malicious websites would be a major undertaking for the startup. It's more likely they've partnered with a security company of some sort to provide this service or are using a publicly available API, such as Google's Safe Browsing API, which checks URLs against Google's blacklist.

The need for this type of protection on Twitter is more than apparent. As of late, the service has been overrun by those wanting to use it for their own nefarious purposes. Besides just getting their links posted to Twitter itself, hackers have managed to get their malware links into Twitter's trending topics, too. There have also been instances where the Twitter accounts of high-profile users, like Guy Kawasaki for instance, have been hacked and have then been used to push malware links out to their unsuspecting followers.

Good, But Not Good Enough

Unfortunately, there's a major issue with how Twitter is blocking malicious URLs. They're not parsing shortened links. Because of Twitter's 140-character limit, URL-shortening services have become the de facto standard for link sharing on Twitter. This functionality is built into numerous third-party client applications as well as into the Twitter web interface itself. Shortening a malicious link would be by far the easiest way to post a dangerous malware-laden link to Twitter - and likely the method hackers would use anyway. If Twitter does not parse all the shortened links users attempt to post, then they don't really have a good shot at keeping malware links off their service.

Luckily for Twitter end users, the default URL-shortening service, Bit.ly, began warning users of malware last month. Although it still permits users to shorten and post links to malicious sites using Twitter, anyone clicking on the link will receive a message: "Warning - this site has been flagged and may contain unsolicited content. The content of this web page appears to contain spam, or links to unsolicited or undesired sites."

Well, at least that's something.

While we're glad to see Twitter taking steps to make their service a more secure place for sharing links, we hope they'll soon start parsing URLs, too. Otherwise, this new protection won't be that much help in the end.

The attack, posted online here, first displays a warning message and then posts Secure Science's test code "@XSSExploits I just got owned!" to the victim's profile. But if a hacker wanted to use this technique to compromise users' PCs, they could remove the warning screen and combine the link with a sensational message which users couldn't help but click. Add in some browser attack code, and before you know it, clicking a Twitter link could allow a hacker access to your computer. This, says James, "would just tear the cr*p out of Twitter." He adds, "I'm holding my breath, hoping no one does something stupid at this moment."

According to Secure Science researchers, this particular bug can be eliminated by fixing the cross-site scripting flaw, but if another similar bug were to show up on the site, users would soon face the same problem all over again.

Still, one has to wonder, why are they publishing this information publicly instead of alerting Twitter directly? Apparently, it's because the research company is concerned Twitter is not taking security seriously enough. James says he hopes this demonstration will push Twitter into making it more of a priority.

The State of Twitter Security

It's easy to see why security professionals may be worrying about the state of security at Twitter - the company has had some rather high-profile incidents as of late. Only last month, a second clickjacking attack was revealed after the company had just finished patching one that was unveiled in January. Also in January, the accounts of 33 high profile Twitter users including Britney Spears, CNN news reporter Rick Sanchez, and Barack Obama, were compromised by hackers who defaced their accounts with embarrassing and offensive messages.

At the time, Graham Cluley, senior technology consultant at Sophos advised Twitter "to take a long hard look at its security to ensure that this never happens again, and regain the confidence of its members." Yet since then, more potential attack vectors have been revealed.

Staying Safe on Twitter Keeps Getting Harder

If Twitter is indeed replacing, or at the very least, augmenting email for interpersonal communications, then perhaps it's time for us to apply those same age-old rules that once applied to email - be careful what you click. Now that it's finally been drilled into people's heads that email attachments aren't always safe, it seems like we have to start again educating Twitter users that the same goes for links.

But when a service goes mainstream - like Twitter is doing now - it's going to become filled with people who won't give a second thought to security concerns such as these. Instead, without intervention on the part of Twitter to address these issues, consumers are going to end up learning "the hard way" - by becoming victims.

The security problem only gets worse when you think about how easy it is for people to create fake celebrity accounts not to mention how easy it is for Twitter spammers to join the service. Since Twitter doesn't authenticate new accounts via email, anyone can post any message from any address, real or fake. There are even opt-in services that Twitter spammers can join to quickly accumulate large numbers of followers quickly in an attempt to appear more legit.

Although Twitter is attempting to fight spam on several fronts (they're now disabling accounts that automate re-following for instance), it seems as if more and more Twitter spammers are creating accounts every day. (How many of those SEO advisors and 'life coaches' are for real, I wonder?)

As Twitter explodes into the mainstream, it may be time for them to work on addressing some of these issues before they focus on enhancements to the site like the relatively new "suggested users" section or the in-house ads - features which a few folks suspect may have something to do with Twitter's supposedly soon-to-be-revealed business model. While we understand the service needs to develop their business plan, they recently closed a $35-million financing round, which added even more cash to their previous round ($15 million). Given that they only have 20 employees, they're (in theory) only burning through around $5 million a year. We're not sure what Twitter is doing with all that money, but we would like to suggest that they use some of it to hire security professionals to help make the service safer...before it's too late. 

Ben Chatelain is the software engineer behind the Full Screen Web Browser application which was released in the iPhone App Store on February 12th, 2009. It soon became fairly popular, having now been downloaded over 66,000 times and ranking in the Top 100 Paid Apps lists in ten countries. In the U.S. and nine other countries, it also ranks in the Top 20 Utilities list.

However, within four days of the initial release, Ben received a Google Alert informing him that a cracked version of the application had been made public on Appulo.us - a site that supposedly provides the "try before you buy" functionality that's currently missing from iTunes. In theory, users can download and evaluate applications using Appulo.us, but in reality it mostly serves as a way to download pirated copies of paid iPhone applications for free.

Upset to find his application pirated, Ben began to investigate ways to detect the cracked apps in order to do something to the pirated copies out there, like shutting them down remotely or causing them to self-destruct. Still, he didn't want to do anything that would affect legitimate users of the app or cause problems with Apple that could lead to his app being pulled from their store.

Instead, Ben developed a server callback mechanism that alerted him when a copy of his application was cracked. The data sent back to him included the app's unique device identifier (UDID). For those applications registered as cracked, the server will now control a demo period. After 10 runs, a message is presented to those running the bootlegged copy, encouraging them to purchase the Full Screen Web Browser page in the App Store. The only other option provided is to exit the application.

In addition to the warning message, Ben also cleverly adds a "guilt trip" to the message, informing the users of the pirated copies that purchasing the application legally will help him feed his 1-year-old baby. (He decided against his wife's suggestion of actually putting a photo of the baby in the message.)

Says Ben, one of his main motivators for choosing the server-controlled demo option was because with iPhone applications, there's no way to save data outside the tightly-controlled sandbox in which they run. That means that demo periods could easily be reset by simply reinstalling the application. His method, which uses a web service instead, lets him control applications from outside the app's sandbox.

Piracy Troubles

Since the announcement of Crackulous, a program for pirating applications from the iPhone App Store, a lot of developers have been discussing what they can do to prevent their applications from becoming compromised. Some game developers have considered using server-based tracking methods to separate the high scores of the pirates from those of the paid users, but to our knowledge, no one has yet implemented anything like this yet.

Other developers are turning to solutions like Kali's Anti-Piracy service, which is installed as an additional layer of protection on top of the application itself. Although not entirely foolproof, it does make it more difficult for hackers to crack an application. Hackers attempting to crack Kali-protected apps will end up with non-functional copies, says the company.

But unlike other anti-piracy methods, Ben's server-controlled method, inspired by John Gruber's article on Daring Fireball, allows for the possibility of converting pirated copies into paid versions. Since the introduction of his new anti-piracy measures only two days ago, 23 of the pirated users have seen the "crack detected" message. One of the 23 ended up purchasing a legal copy. Ben reports that the current rate of pirated users is around 9.1% (758 pirates out of 8241 users who have run the app since the crack appeared). For applications whose install base is even larger, turning pirates into customers in this manner could have even a greater impact. This method could be especially useful to iPhone game developers, who, according to a game developer quoted by Gruber, are the most affected by piracy. For example, two out of three users of that particular game ran bootleg copies of the application.

The server-based tracking method implemented in the Full Screen Web Browser represents what is likely to be only one of many future attempts by iPhone developers to prevent their apps from being cracked and pirated. Expect to see more of the same soon.

Update 2: Here is Twitter's reaction. Apparently, about 750 accounts were compromised in this attack. Twitter has reset these users' passwords and deleted the webcam tweets. Still no news about how the hackers got a hold of the passwords.

For now, we recommend that you check your updates to see if this message appears in your stream. If it does, you'll probably want to change your password immediately.

Twitter itself has a decent track record when it comes to security (though some celebrities' accounts were hacked a while back), so we assume that this hack originated somewhere else, but for now, it is not clear how these hackers managed to get a hold of all of these users' accounts.

The last Twitter 'hack' turned out to be relatively benign and just exploited a well-known security hole but didn't actually steal users' passwords or direct them to an adult site. Until Twitter's oAuth implementation goes fully live however (Twitter is testing it with a select group of developers right now), users have to hand over their full Twitter credentials to every third-party Twitter service, which could allow a malevolent programmer to easily create a huge database of logins and passwords.

Update 3: looking a bit more into this, it seems like the same scam has appeared on IM services like MSN Messnger and also on Facebook.]]> Discuss]]> http://www.readwriteweb.com/archives/breaking_another_twitter_hack_in_the_wild.php http://www.readwriteweb.com/archives/breaking_another_twitter_hack_in_the_wild.php News Fri, 06 Mar 2009 13:17:54 -0800 Frederic Lardinois Phishing, the highly illegal scam of tricking people into revealing their logins and passwords by creating fake emails, Twitter messages, and/or websites, does not actually make phishers a lot of money. A new paper (PDF) by Cormac Herley and Dinei Florencio from Microsoft Research argues that the basic laws of economics still apply to phishing. As phishing becomes easier, and as 'phishing kits' are being sold for less than $100, the actual income for each individual phisher has to come down. Phishing has become a "low-skill, low-reward business."

Phishers typically sell the logins and passwords they have harvested through their scams to other criminals online, who can then easily commit identity theft.

Losses from Phishing Have Been Exaggerated

The authors also argue that the economic losses from phishing have been greatly overstated. Herley and Florencio argue that the numbers don't 'survive basic sanity checks,' yet are widely quoted. At the same time, these mythical numbers lead more phishers into the business, which then depresses the per person income even more. According to PayPal's chief information security officer Michael Barrett, phishing "is not even in the top five threats" that could cause losses at PayPal.

Why Phishing Will Continue

The paper, however, also points out that this lack of revenue does not mean the end of phishing. Phishers, the authors argue, are not necessarily making rational economic decisions. Instead, their vision is clouded by by hopes of 'hitting the jackpot' (even when revenue is going down), and a constant barrage of reports of 'easy money' that will lead phishers to believe that revenue will go up again. Also, because phishing is generally considered to be very 'easy,' a constant stream of newcomers will replace the retired phishermen. The authors note that this cycle can only be broken through providing better information about the economic reality of the phishing business to potential phishers.

(hat tip to Steve Ragan at the Tech Herald)

CC-licensed image courtesy of Flickr user ToastyKen

For many users of Google Docs, that answer is "no." According to Google's Help Topic on SSL as well as their Google Apps Edition comparison guide, SSL is a feature only made available to users of Google Apps Premier and Education Editions. However, in some informal testing on our part, it appears that users of Google Apps for Your Domain were given that option as well, despite the fact that their Google Apps edition clearly reads "Standard." For everyone else, though, Google Docs remains an unencrypted HTTP session.

In a business or educational setting where Google Docs is being used, your I.T. admin has probably turned on SSL for you by activating the feature that forces SSL sessions for all users. If they have not, though, you can still switch on SSL for yourself, says Google, but their help documentation fails to explain how that can be done. All the documentation says is that "your users can enable HTTPS when necessary."

What they probably mean is that anyone can type in "https" when entering in the URL for a Google Apps service in the address bar of their browser. Since your average internet user doesn't think about these sorts of things, though, that's probably not the best solution in terms of security.

While we hope that any I.T. admin in a corporate setting knows well enough how to enable a basic security feature such as this, it would still make us more comfortable if these sorts of things were enabled by default. The only reason to not enable SSL is because it can slow down your connection to Google services. Still, in the event of network issues, I.T. admins could temporarily disable this feature to speed up access for their users. But Google hasn't chosen to make security the default - they've chosen speed.

Outside of Google Apps, everyday users of Google Docs don't have an option in their Google Docs settings to force the service to always use SSL. Like those with a neglectful I.T. admin, these Docs users would have to remember to type in the "https" prefix if they want to use a secure connection.

SSL Implemented Haphazardly

Manually typing in "https" is all well and good, but let's face it - most users won't ever know to do this and those of us who do know won't remember. Not only is this process laborious, it's inefficient, too. For example, those who want to take advantage of the Gmail Calendar and Docs widgets, which allow for one-click access to other Google services from within Gmail, would have to forfeit a secure connection in order to do so. The only recourse would be to not use the widgets at all, and that certainly disrupts our workflow.

However, if you've enabled SSL within your Gmail settings, connections to your other Google services will also be encrypted if you use the navigation bar at the top left of your Gmail...but only if you use the navigation bar. Even when signed into your Google account, typing in "docs.google.com," "calendar.google.com," or using the Gmail widgets will still take you to the HTTP site.

At Least They Have SSL...

What's really unfortunate about this potential security issue is the fact that Google is actually leading the way among webmail and web app providers when it comes to offering SSL to its users. Although other free webmail services from Yahoo, Microsoft, and AOL, for example, may authenticate you upon login via HTTPS, they drop down to unencrypted mode immediately after the authentication is completed.

However, it could be argued that those other services are not claiming to be a secure replacements for business use. Since Google promotes Apps as a web-based alternative to expensive desktop software, many people mistakenly assume that means Google services are, in general, "pretty much" secure for personal use, too. Apparently, that's only true to a point.

It's also worth pointing out that nothing, not even SSL, can keep a determined hacker out of your account. As ZDNet reported at the beginning of the year, even SSL can't keep blackhats from hijacking your session through the use of "sidejacking," a trick that enables hackers to take control of any Web 2.0 app that relies on saved cookie information. (There have also been other reports of Google Docs security issues, but we couldn't reproduce the problem.)

Providing SSL to everyone is the least Google could do. And to the other webmail/web app providers out there: it's time you followed suit.