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.