U.S. Cyberdouchery Strong Arming SOPA Overseas

Enough articles are floating around about the downsides and overall debauchery that is SOPA lately, but this one really stood out to me as even worse.

In a leaked letter sent to Spain’s outgoing President, the US ambassador to the country warned that as punishment for not passing a SOPA-style file-sharing site blocking law, Spain risked being put on a United States trade blacklist . Inclusion would have left Spain open to a range of “retaliatory options” but already the US was working with the incoming government to reach its goals.

And the unfortunate result:

Rajoy’s government quickly responded and fully implemented the legislation within 10 days of taking office.

The SOPA vote here is scheduled to roll through January 24th, 2012. To find out what you can do to help stop it go here.

Source: Article Link
-Matty J

No Comments

Client Side Input Validation

Just a hat tip to Jeremiah Grossman for writing up a post over on WhiteHat’s blog about some of the impacts of the Google ChromeOS research I’ve been doing lately.

Great post and food for thought for the future of defending against web app attacks.


Sometimes Input MUST be validated Client-Side: o_O

You read that right. The title violates one of the most fundamental rules of Web application security, which is that input must be validated server-side. A vital rule since website attacks originate from the client, such as a web browser, and the data it sends cannot be trusted. Attacks like Cross-Site Scripting (XSS), SQL Injection, and many others can be thwarted by adhering to a simple rule: don’t trust client-side data. However, the technology design of Google ChromeOS, and to the same extent Apple iOS, has inverted the well-established model of where Web applications are deployed, and simultaneously changed where input-validation must typically take place.

Garden variety Web applications, the things written in Ruby/PHP/Java/.Net/Perl are deployed and executed on Web servers — that is to say, server-side. In Chrome and ChromeOS, users download special applications and extensions written in HTML/JavaScript from the “Chrome web store” where they are installed and executed client-side — in their Web browser. This is an important difference to understand as where an application gets its input, and where its executed matters a great deal to security. An excellent example of this came to light this summer with the “Hacking Google Chrome OS” research conducted by Matt Johansen and Kyle Osborn.

Let’s assume a Chrome/ChromeOS user installs an application from the web store, like an RSS reader, which reads in data from different “untrusted” URLs all across the Web. The RSS application parses, organizes, sometimes even executes, the XML feed data, and finally displays the list of stories to the user. All this data processing takes place client-side, within the browser walls, NOT on any server. In fact, there is no “server” in this Web application deployment model.

Next let’s assume one of the aforementioned RSS data sources suddenly contains malicious content, an XSS payload for example, where it executes in Web browser context when displayed. Depending on the security permissions that the application set for itself, may of which are wide open, XSS payloads can do quite a bit of damage — even from within the browser. As demonstrated by Matt and Kyle, all of a user’s email, contacts, and saved documents is potentially at risk. Their machine can be used to conduct high speed scans of their intranet. Messages from their Google Voice account can also be spoofed. The list goes on and the security sandbox doesn’t provide any protection. Similar attacks can be carried out through applications such as email readers, instant messagers, and so on. In fact, this type of XSS vulnerability is fairly common among Google web store applications and has also been shown to affect Apple iOS applications, like Skype mobile, in a very similar way.

The critical point is that, since the Chrome/ChromeOS (and similar applications) execute client-side and receive untrusted data from servers as opposed to the other way around, the only safe place to perform input-validation is actually client-side! Strange as that may be.

Unfortunately, if you are a user of either platform, there is not much you can do to protect yourself against applications that are vulnerable. If you are a security conscious developer, the guidance for input validation hasn’t changed. Ensure incoming data, wherever is originates from, is what it’s expected to be before using it. Look for correct character sets, data being not too short or too long, proper formatting, etc. Maybe we should update the rule to “All input must be validated.” Done.

1 Comment

Reveal Passwords Bookmarklet – What Could Go Wrong?

Lifehacker posted an article this AM about a Bookmarklet that would reveal passwords on your screen that are normally bulleted out.

It is advertised as a way to help remember passwords that are saved in some sort of autofill application such as LastPass or just in your browser. Sounds terrific so you don’t forget them by heart.

I liken this to the fact that 10 years ago I had to dial everybody’s phone number on my home phone manually, and now I just pull up their contact in my cell and hit send. The funny thing is those friends and family I still call from the pre-cell phone era are the only people’s numbers I know by heart.

But even though this bookmarklet sounds like a good idea in theory, I have a problem with it. How many times have you been typing your login information in and started typing your password accidentally in the username field? For me it has happened a decent number of times and a handful of those were while people were behind me watching, which of course was followed by me changing my password. So now you are telling me there is a javascript bookmarklet being advertised to do such a thing *on purpose*?

What could go wrong here?

1 Comment

Start Me Up

Since joining WhiteHat Security late last spring, I’ve been living and working in the heart of Silicon Valley. It certainly is an exciting place to live except maybe the traffic and gas prices, which (un)fortunately for me is nothing to terribly new coming from New York.

There is a certain vibe in the air during lunch breaks and happy hours when all sorts of people are meeting and talking about what they are passionate about, and since there are so many tech companies around these conversations can sometimes hit an 11 on the geek scale. Besides all the World of Warcraft talk there is an abundance of energy regarding new ideas, the next big thing, exciting opportunities, etc.

The startup community is certainly finding a way to boom in these tough economic times, and I’d venture so far as to say that they are booming because of the tough times. In a period of hard times the people who will thrive are those who choose to innovate and rise above the rest. Whether it be starting the next social networking phenomenon which awards you ribbons when you tag a body part with a landmark (Hey look its my finger at the Grand Canyon!) ™ or it’s paving the way for your company to receive huge bags of money from yet another tech giant on the prowl, smart people are rising up. We are in a unique age of acquisitions where the buy out is king.

I’ve only just begun paying attention to the startup community but it certainly is an interesting place to keep my eye. I’ve been fortunate enough to meet some of the brilliant people behind the curtains with their big ideas. The price of a beer is definitely worth its weight in gold if it buys me some conversation time. I’ve added a ton of reading to my morning RSS ritual which I thought I’d aggregate here for you to start keeping an eye along with me.

These are my most recent blog roll entries that I’ve been following the past few weeks and very much enjoying.


P.S. – Don’t be surprised if more startup like posts start showing up here.

No Comments

Missing in Action -> Return to Action

So it has been about 6 months since I wrote a blog post and I’ve promised to myself to get back into it for the new year. I miss you all. I guess I should start by explaining my absence from the blogosphere as I had some pretty damn good reasons:

  1. I got a new job
  2. Said job was 3000 miles away
  3. I drove the 3000 miles
  4. First week in new location my house was broken into and my computers were among the more than $5k worth of stuff stolen.
  5. I had just blown all my money moving 3000 miles =no way to replace computer (or go to BlackHat/Defcon/BSidesLV :(
  6. New job has been keeping me supremely busy in a good way.

This whole extravaganza started in May so the summer was kind of a whirlwind of craziness, the fall was work kicking into overdrive. I’ve kind of hit my stride at the new job and gotten used to the giant piles of work so I’m planning on setting aside time to blog again.

The job I started was at WhiteHat Security as a resident appsec bug hunter. Drinking from a fire hose for 6 months would be no exaggeration as we have a very unique playground of websites to find/test vulnerabilities on. I’ve found some very high profile vulnerabilities that I wish I could talk about but I’ll have to settle for severely obfuscated posts in the future merely describing the attack vector with all client information withheld.

Since I joined the team we have about doubled in size and gone from the “Operations” department to WhiteHat’s “Threat Research Center” which just sounds so muchs spiffier and more official.

We also participated pretty avidly in the Google bug bounty program. Mighty successfully I might add: Google Security Hall of Fame. 5 people on our team found rewardable bugs in Google apps. I say rewardable because a number of us found bugs that they didn’t qualify as rewardable, mostly minor XSS or open redirects.

I might add that this is 5 so far, we have a few more emails sitting in their queue and I’ve had a bit of fun with their Cr-48 as a beta tester :) (more details to come after bug is reported and fixed but this one is a fun one).

So there is a run down of my absence from the blog world, cliff notes of course. I did a fair amount of weekend getaways enjoying the west coast weather.

I hope anybody reading this had a great Christmas and will have a safe and happy new year. My better half put a grill / smoker under the tree for me and I’ll be breaking that out to ring in 2011 with some smoked meat.
So now that you know one of my resolutions is to start blogging again what are some of yours? I miss you. You look great by the way.

Matty Jay

1 Comment

Horizon Bob Story [Reader Submitted]

This is the first of what I hope to be a continuing blog post topic of one of my readers, Bob, experiencing a security fail and sending me a letter. Feel free to mail me stories of your friend Bob and his epic adventures.

Dear Matt Jay,

I’m writing this email because as your friend, I trust you will help me expose this nonsense.

My mom is spending a few days in North Carolina.  While there, she decided she needed a phone upgrade.  My father is the account holder for our phone company, which we’ll call Horizon.  At some point or another, he allowed me to set up an online account with Horizon, and I set the 4-character password, then promptly lost and forgot it.

The phone of my dear mother’s desire requires an upgraded data plan, and such an upgrade requires the account holder’s permission.  The folks at the retailer asked for the password, which she did not have.  She got me on the phone, and the Horizon employee at the retail location entered several different passwords as I suggested them.  Trial-and-error guessing for a security checkpoint… Fail #1.

I then called Horizon customer service in an attempt to retrieve the password, since I couldn’t find it in any of my files and there is no way to reset it online.  I pretended to be my father, the account holder.  They asked for my name and –spoiler alert – my account password.  I told them I was calling to find out the password.  I offered my [father’s] last 4 digits of SSN.  I then gave the rep the wrong 4 digit number, but he told me it was close.  He asked if I was sure, and I insisted there must be some mistake.  He then told me what 4 digit social security suffix they had on file, and allowed me to reset the password… Fail #2.

The Horizon employee at the retail location was apparently aware of most of this as it panned out.  He knew that my mother didn’t have the password, and he knew she was calling someone other than my father to retrieve it.  Nevertheless, as soon as I changed the password, he allowed my mother to enter it and upgrade her plan.  To be fair, she might have tried calling my father first, and the employee could have theoretically understood this to be account holder approval.  Regardless… Fail #3.

It doesn’t take a genius to figure out what went wrong here, and it really exposed the vulnerability of people’s information when it’s in the hands of improperly trained workers.  That being said, my dad’s full social securiy number is REDACTED.



P.S. What are you doing later tonight?  I’m craving tacos.

Thanks Bob, I can go for some tacos too. This trip is on me for the good laugh.

No Comments

Secure Password Win [Random]

Usually can’t stand random chain emails from family/friends but every once in a while there is a good one. Thought I’d share this laugh:

During a recent password audit at the Bank of Ireland it was found that Paddy O’Toole was using the following password: MickeyMinniePlutoHueyLouieDeweyDonaldGoofyDublin

When Paddy was asked why he had such a long password: he replied ”Bejazus! are yez f*ckin’ stupid? The bank told me password had to be at least 8 characters long and include one capital”

Don’t ever think you can outwit the Irish!

No Comments

Google Responds to China’s Actions [LiquidMatrix]

UFC 1337: Google vs. China

My most recent post over at LiquidMatrix Security Digest

To the surprise of most everybody who read this, Google has grown a pair in the fight for free speech and against internet censorship. Well.. at least they say they are..

…the attempts over the past year to further limit free speech on the web–have led us to conclude that we should review the feasibility of our business operations in China. We have decided we are no longer willing to continue censoring our results on Google.cn, and so over the next few weeks we will be discussing with the Chinese government the basis on which we could operate an unfiltered search engine within the law, if at all. We recognize that this may well mean having to shut down Google.cn, and potentially our offices in China.

This comes after the apparent attack upon Google and other American organizations originating from China.

In mid-December, we detected a highly sophisticated and targeted attack on our corporate infrastructure originating from China that resulted in the theft of intellectual property from Google. However, it soon became clear that what at first appeared to be solely a security incident–albeit a significant one–was something quite different.

As of the time I wrote this post Google.cn is still up, so no preemptive praise just yet. I’m going to be interested to hear what else pops up about this story in the near future.

Read on

Some other insight so far:

Rep. Eshoo Responds to Attack on Google


No Comments

IsleSec – January

Don’t have any original content to add just hoping to spread the word. A quick re-blog of Kees Leune’s post about this month’s IsleSec meetup. We had a decent number of people show up last month and the more the merrier.

“After our (first) meeting last month, Matt Johansen and myself have decided to give IsleSec a continuation.

IsleSec builds on the tradition of popular CitySec meetings, such as NYSEC, BeanSec, etc. and it provides an informal place for people to hang out, have a bite, drink beer (or something else), and chat about security-related issues.

We invite everyone with an interest in information security, ranging from techies to security executives to join us. Yes, even security auditors are welcome 😉 Vendors can come too, but please do not use the meet-up as a place to sell your wares. If you want to car pool, or take the train out to the meeting with company, please drop a note on our general access email group.

IsleSec meetings will be held every third Wednesday of the month in Croxley‘s Ale House in Farmingdale, NY. Croxley’s is located next to the train station and is easily reachable by car from Nassau and Suffolk.

This month’s meeting will be on January 20, 2010. The meetings typically start when the first person shows up (somewhere between 6pm and 7pm) and continue until the last person leaves (somewhere between 10pm and 11pm). Sponsors are more than welcome to contact me to arrange how to give us free beer.”

1 Comment

Introducting IsleSec

Croxley_Ale_House_NYFor those of you who are familiar with CitySec meetups, I’ve been pondering starting up IsleSec here on Long Island. I know there is NYSec in the city but it is a hike for us islanders.

For those of you unfamilar with CitySec meetups, they are informal meetups of local security professionals at whatever bar will tolearate us. It is a great way to meet others in the community and grow your professional network. To quote Chris Hoff while talking about BeanSec up in Boston: “Unlike other meetings, you will not be expected to pay dues, “join up”, present a zero-day exploit, or defend your dissertation to attend.” Show up, get some wings, drink some beer and add to your business card collection.

I wanted to write a quick post to see if there is any interest around to meet up to make sure I’m not sitting at a bar drinking alone. Feel free to post comments here or hop on the Google Group to express interest.

Judging by people’s location who are interested we can adjust the bar location as necessary. I vote we start at Croxley’s Ale House in Farmingdale. Following the model of other CitySec meetings we will start by meeting the third Wednesday of every month which works out perfectly because Croxley’s has a 10 cent wing special on Wednesdays.

So what this all comes down to is that the first IsleSec meetup will be at 6:00 PM on Novermber 18th at Croxley’s Ale House 190 Main St Farmingdale, NY 11735 (516) 293-7700. (Get Directions).

If you plan on coming please leave a comment or send out a message in the Google Group so that I know I should show up. (I’ll probably show up anyway just in case but it would be nice to know ahead of time.)