MoTB #04: CSRF in BigTweet

What is BigTweet
“BigTweet was developed by Scott Carter (@scott_carter) as a way to interact more effectively with various networks from the Web. When you click on the BigTweet bookmarklet, a window appears in the middle of your current web page. Use it to post to Twitter or FriendFeed and then return to what you were doing. It doesn’t get any faster.” (BigTweet home page)

Twitter affect
BigTweet can be used to send tweets from any web page by using a bookmarklet.
BigTweet is using Username/Password authentication in order to utilize the Twitter API.

Popularity rate
While Bigtweet is not on any of the top Twitter services lists, it has an easy to integrate bookmarklet interface – 1 twit

Vulnerability: Cross-Site Request Forgery in BigTweet upate.json.
Status: Patched.
Details: The bigtweet update.json web page did not use authenticity code in order to validate that the HTTP post is coming from the bigtweet web application.
Screenshots:

Note: While the proof-of-concept in the screenshots used the “xxx” twitter user, the page will actually send a tweet for the currently logged-in user (in the PoC – @avivra). Any bigtweet.com registered user could have been used instead of xxx.

Vendor response rate
Vulnerability was fully fixed 22 hours after it has been reported.
Scott Carter, the developer of BigTweet, is also the one who came up with the idea of having a security best practices document for API developers. Alex Payne from Twitter has written such document last week. Excellent – 5 twits.

Password Length and Complexity for Social Media Sites

July 1st was “Twittersec” day as coined by @hevnsnt over at I-Hacked.com to designate July 1st as change your Twitter password day. Why? Mostly because July is the “month of Twitter bugs” created by a security researcher in which he will announce a bug in a “3rd party Twitter application” everyday for the month of July to raise awareness on security issues with the Twitter API. Technically, this should be “month of 3rd party” Twitter bugs but whatever. Either way it will raise awareness about some of the security issues of Twitter and 3rd party applications.

ANYWAY, back to my point….I sent out some tweets about changing your Twitter password and now being a good time to use a password manager like Keepass to manage multiple, complex passwords for everything…not just social media sites. One problem though is that each site might have different password length and complexity requirements. This becomes an annoying issue when you choose a randomly generated password like I suggest when using a password manager. You will encounter many sites that have specific requirements and others that do not. Obviously, the longer and more complex the password is the harder it is to crack so I suggest going as long as you can. Sad that there are these limitations on certain sites (blame the site developers) but if you set your random password generator to a very large number (I recommend at least 20 with a mix of everything you can throw at it including white spaces if the site will let you), it’s as good as your going to get.

Keep in mind, some applications even supported by the site (like the Facebook app for BlackBerry and iPhone) might not like passwords over a certain length or even certain special characters…you will know once you use these apps. Also, I mention Keepass as a password manager because you can use it on a BlackBerry or Windows Mobile device as well…an iPhone version is being worked on. So here you go…max password lengths for the major social media sites:

Twitter
None. I tried a 500 character password with everything but white spaces and it worked.

Facebook
None. I tried a 1000 character password with everything but white spaces and it worked.

MySpace
10 characters! Wow…really bad. Now I know another reason MySpace sucks.

LinkedIn
16 characters! This is interesting. LinkedIn truncates the password to 16 characters! Even if you put in a password larger then 16 characters it will only use the first 16, you can actually see this when entering in a password. No user notification, no info about this in the ‘help’ section. Sneaky and evil.

YouTube
None. Your account is tied to your Google account so is kind of a pain to change…but I didn’t find any issues with length or complexity.

On another note…I wonder if Twitter and Facebook truncate the passwords at a certain length and don’t tell you? Not sure…but it would be interesting to find out. This is another bad design as a they could easily just hash the entire password (which is a certain manageable length) and the hash is stored in the database not the large character password. Does this mean that sites like MySpace and LinkedIn are storing passwords in clear text? Also, I have run into other sites (non-social network) that actually truncate the password because when you try to login with an overly complex password…you get denied! Then you enter the cycle of doom…resetting your password thinking you fat fingered that password to begin with over and over. :-/

Are social media password limitations working against you?
Finally, just a quick point on this. Social media sites like MySpace and LinkedIn should NEVER have any limitations on password length or complexity. Certain complexity restrictions (like white space or strange characters) I could understand since you would have to use these passwords on mobile devices and other integrated apps. However, there are no technical limitations of just hashing the passwords to a constant length…and we all know storing passwords in a database in clear text is never a good thing.

Shouldn’t these social media sites that you already give your personal information to be trying to protect you the user as best as they can by letting you set a long and complex password? Let’s hope MySpace and LinkedIn get better at this real soon!


MoTB #03: TwitWall Persistent XSS

What is TwitWall
“TwitWall is the easy-to-use, quick-to-blast-out, instant blog companion for Twitter. With TwitWall, you can embed your favorite videos and widgets, upload your photos, mp3 music or podcasts, – you name it..” (TwitWall home page)

Twitter affect
TwitWall can be used to send tweets and follow/unfollow other Twitter users.
TwitWall is using OAuth authentication token in order to utilize the Twitter API.

Popularity rate
Though it’s here since Summer 2008, it has yet to gain enough user base to get into any of the top twitter services lists – 0.5 twits

Vulnerability: Persistent Cross-Site in TwitWall entry view page.
Status: Patched.
Details: TwitWall allows HTML to be embedded in the wall entries. According to the vendor this was done because “our users with non-malicious intentions enjoy using our html editor”. Unfortunately, the entry view page does not santize scripts and events that came along with the HTML.
This vulnerability could have allowed an attacker to send tweets, follow/unfollow others on behalf of its victims.
Screenshots:

Vendor response rate
Vulnerability was fully fixed 20 hours after it has been reported. Excellent – 5 twits.

MoTB #02: Reflected XSS in HootSuite

What is HootSuite
“HootSuite is the ultimate Twitter toolbox. With HootSuite, you can manage multiple Twitter profiles, add multiple editors, pre-schedule tweets, and measure your success. HootSuite lets you manage your entire Twitter experience from one easy-to-use interface.” (HootSuite about page)

Twitter affect
HootSuite can be used to send tweets, direct messages and follow/unfollow other Twitter users from multiple Twitter accounts.
HootSuite is using Username/Password authentication in order to utilize the Twitter API.

Popularity rate
27th place in the Top 100 Twitter Services, according to “The Museum of Modern Betas” – 3.5 twits

Vulnerability: Reflected Cross-Site in the “add-acount” page.
Status: Patched.
Details: The HootSuite “add-account” page does not encode HTML entities in the “pageMode”
variable, which can allow the injection of scripts.
This vulnerability could allowed an attacker to send tweets, direct messages and to follow/unfollow others on behalf of its victims.
Proof-of-Concept: http://hootsuite.com/twitter/add-account?height=240&width=280&modal=true&pageMode=xxx%22%3E%3Cscript%3Ealert(%22xss%22)%3C/script%3E
Screenshot:

Vendor response rate
Vulnerability was fixed two hours after it has been reported. Excellent – 5 twits.

MoTB #01: Multiple vulnerabilities in bit.ly service

What is bit.ly
“bit.ly allows users to shorten, share, and track links (URLs). Reducing the URL length makes sharing easier. bit.ly can be accessed through our website, bookmarklets and a robust and open API. bit.ly is also integrated into several popular third-party tools such as Tweetdeck.” (bit.ly about page)


Twitter affect
bit.ly can be used to send tweets with the shortened URLs through a form on their website, or a simple GET request.
bit.ly is using the OAuth authentication tokens in order to send tweets via the Twitter API.

Popularity rate
Second most popular URL shortening service in the wild – 4.5 twits

Vulnerabilities
1) Reflected Cross-Site Scripting in the “url” query parameter.
Status: Patched.
Details: This vulnerability was first reported by Mario Heiderich on May 18th 2009, on twitter.
A week later, I found that this vulnerability got fixed. Unfortunately, after playing with it a bit, I figured that it was only partially fixed. Instead of encoding the HTML entities, bit.ly developers have decided to strip the <> characters. E.g. this proof-of-concept would have popup an alert on IE7:
htttp://bit.ly/?url=”%20style=”color:expression(document.body.onload=function()%20{alert(1)})
The following is the screenshot of the PoC:

Several days ago, after a long discussion with Mario, bit.ly has finally fully fixed this vulnerability.

2) Reflected Cross-Site Scripting in the keywords parameter.
Status: Patched.
Details: This vulnerability was reported by Mike Bailey on June 24th 2009. See Mike’s advisory for more details: http://skeptikal.org/2009/06/parsing-quirk-causes-bitly-xss.html
This vulnerability was fixed by bit.ly yesterday.

3) Reflected POST Cross-Site Scripting in the username field of the login page
Status: Patched
Details: This vulnerability was reported by Mario Heiderich. See Mario’s advisory for more details: http://heideri.ch/bit.ly.txt
This vulnerability was fixed by bit.ly yesterday.

4) Persistent Cross-Site Scripting in the content-type field of the URL info page
Status: *Unpatched* Patched.
Details: This vulnerability was submitted by Mike Bailey on June 25th 2009.
Whenever a URL of a website gets shortened by bit.ly service, an information page is created for the URL, with statistics and metadata about the website.
One of the metadata information being stored by bit.ly is the content-type response header of the shortened URL page. This information of-course can be easily changed.
bit.ly fails to encode HTML entities while displaying the content-type information, and therefore allows injection of scripts to the page.
Live proof-of-concept can be found here: http://bit.ly/info/JvH83
Screenshot of the PoC (just in case the live demo will be removed):

Vendor response rate
It took bit.ly a month and a half to fix simple XSS vulnerabilities. Very poor – 0.5 twits.

In conclusion
bit.ly has a large user base (who doesn’t click bit.ly links?). However, with such a poor response rate to security vulnerabilities, and with such a poorly coded website, in terms of security, we can only hope for the best. Please be careful clicking those shortened URLs…

[Update – 3 hours into Month of Twitter Bugs] bit.ly have finally fixed the last vulnerability.

Month of Twitter Bugs

July 2009 will be Month of Twitter Bugs.
This blog will be used for posting the vulnerabilities.
More details here: http://aviv.raffon.net/2009/06/15/MonthOfTwitterBugs.aspx

Establishing your social media presence with security in mind

If you have been using social media or are curious of the security of this emerging technology you may be interesting reading my recently published article in issue 21 of (IN)SECURE Magazine. In my article I discuss why companies are starting to use social media, the benefits/risks and what information may be posted about your company on social media/networking web sites. I also talk about some cost effective tools your company can use to start your own social media monitoring program (without spending a ton of cash) and how to put in place guidelines for employees regarding the use of social media. Yes, even if you block these sites in the workplace employees are going to use social media/network sites outside of work if you like it or not…you had better get used to it and adapt your policies!

This article started from me actually seeing how much information there is about businesses within social networks. Both good and bad! The information I have found has been extremely valuable when conducting penetration tests. In fact, this information can be so valuable that you may be surprised how easy it is to use this information for social engineering or more…the possibilities are endless. As I pointed out in my article, get together with the business leaders in your marketing and/or public relations group and talk about social media and how to use it with a bit of security and privacy in mind. You might be surprised how receptive they are to the input from a security professional!


Potential dangers of BlackBerry Syncing Applications

Syncing dangers?

Do you have a BlackBerry for work and you have a corporate policy pushed down and managed by your corporate IT team? Depending on how locked down the policy is for your corporate BlackBerry deployment you may be syncing sensitive or confidential data to a public web site.

So I recently installed the Facebook Blackberry Application v1.5 on my BlackBerry and noticed two interesting settings. First, you can sync your Facebook calendar with your BlackBerry calendar. Second, you can sync your Facebook contacts with your BlackBerry contacts. As far as I can tell syncing is only one way…sort of. The Facebook application has a disclaimer when you install the application that says:

Facebook will “periodically send copies of your BlackBerry device Contacts to Facebook Inc. to match and connect with your Facebook Friends.”

So does this mean Facebook has a copy of your corporate contacts? They must somewhere to do the proper sync matching. There is another disclaimer at the bottom of the “setup wizard” that says you allow Facebook to do this interaction per the same way applications have access to your profile data in Facebook. Interesting. Again, not a nightmare situation…but if any of your business contacts are sensitive in nature I would be hesitant to enable this feature. Worse case? I couldn’t think of a worse security nightmare then of all your users automatically sending sensitive calendar entries with proprietary data to Facebook! So yeah, one way is good. For now one way sync is all the Facebook application does but I would be willing to bet that this will change in the future. Be careful with this one.

So lets step this up a bit. What about two way syncing applications like Google Sync? Google Sync will sync your Google Calendar/Contacts with your Blackberry Calendar/Contacts…both ways! This might be a real problem if you make your Google Calendar public or share it with a group of friends. Same goes for your business contacts. You may have just given Google (and possibly the world) all your business calendar entries. Well..we know Google isn’t evil, right? :-/

What can we do about this? As a user…opt out of installing any syncing apps on your corporate BlackBerry for starters. But what about blocking syncing on the device via BES policy? As far as I can tell the only way is to block the application from being installed via policy. This will become problematic when Google/Facebook releases new versions for example. Not sustainable. I’m no BES administrator but there might be other ways to prevent the application from being installed or the syncing from happening but it brings up some interesting discussion. By the way, there are some problems when you have the Facebook application and Google Sync installed at the same time. No thanks.

Something else to think about. How does your company handle BlackBerry deployments? Are they company issued and owned? Or do you allow your users to own them and the company pays for the data plan? All of this would have to be considered before blocking or preventing syncing applications (or any third-party application) from being installed. If you have any thoughts or ideas on this, comment below!


1 24 25 26 27 28