Category Archives: Articles
I recently started playing around with Gliffy, a nice online diagramming tool that has become quite popular. Gliffy makes sharing your diagrams with the world easy. Unfortunately, many Gliffy users do not realize that they are sharing their diagrams with the entire world. Some quick Google searches revealed a number of entertaining diagrams.
This data ranges from boring to concerning. I held back a few that I felt were not responsible to disclose. At any rate, this highlights the dangers of using “cloud services” and not educating employees about the inherent risks this involves. Also, some of this is just plain laziness from those who probably know better.
After assuring Google I was indeed a human about a dozen times, here are the highlights:
- A GitHub Migration Map — Author Unknown
- “esecurity” flow chart
- An org chart with salary information
- The “melvyn” flow chart
- A single sign on app flow
- I don’t even know
- qwest.com current architecture solution
- Lubricant Supply Chain
- “Confidential” Application Design Docs
- Another Org Chart
- A Networking Diagram with Passwords
- UI Mockups
- MyBook General Photo Album Confidential API
- A Really Detailed Internal Business Process
- Marketing Plan With $ Figures
- Some Sort of Business Plan
- Music Studio SEO Strategy
- Facebook Ad Campaign Results
- Fax Numbers in a Payroll Process
- Payroll Email Process – Info Disclose
- Another Org Chart
- Another Internal Network Diagram
- ATM Vendor Proprietary Information
- DoD Stuff
- More DoD Stuff
- Even More DoD Stuff (I hope this stuff isn’t classified)
- Another Internal/External Network Diagram
- Hot Sexy Text Chat Mockup
- Zombie Attack Flow Chart
Gawker, Trapster, now Tripadvisor.
I’m sorry Steve Kaufer, but I don’t think the email you sent is good enough anymore. You said “passwords remain secure”
HOW DO WE KNOW THAT?
- State how you stored the passwords
- Is it a one way hash? If so, state the algorithm
- What about the salt? Did you have one? How many bytes?
- Even better, were you using something strong,with a work factor, like bcrypt or md5crypt?
Here is the email form Tripadvisor’s CEO:
To our travel community:
This past weekend we discovered that an unauthorized third party had stolen part of TripAdvisor’s member email list. We’ve confirmed the source of the vulnerability and shut it down. We’re taking this incident very seriously and are actively pursuing the matter with law enforcement.
How will this affect you? In many cases, it won’t. Only a portion of all member email addresses were taken, and all member passwords remain secure. You may receive some unsolicited emails (spam) as a result of this incident.
The reason we are going directly to you with this news is that we think it’s the right thing to do. As a TripAdvisor member, I would want to know. Unfortunately, this sort of data theft is becoming more common across many industries, and we take it extremely seriously.
I’d also like to reassure you that TripAdvisor does not collect members’ credit card or financial information, and we never sell or rent our member list.
We will continue to take all appropriate measures to keep your personal information secure at TripAdvisor. I sincerely apologize for this incident and appreciate your membership in our travel community.
Co-founder and CEO
The reason why we just can’t accept the two statements I’ve highlighted is because not enough information was provided about the breach. In several other news outlets security experts were speculating this was likely the result of a SQL injection attack. When minds are left to wander, and people go to SQL injection as the likely vulnerability, then someone familiar with SQL injection is left to ask the question,.. “well why weren’t they able to dump the password table too?” Maybe it wasn’t SQL injection. Maybe there was a bug in an accessible CMS. Maybe some development test data was carelessly left somewhere. Maybe some API TripAdvisor exposed to a partner had a weakness that allowed the attacker to pass a userID number and get an email address.
Even though the TripAdvisor email is missing some useful detail, there will be some clues if password hashes were compromised. If they force a password change on returning users, that will tell the real story.
Who really knows? Tripadvisor does. This email sucked. It should have had more detail.
I’m a bit of a CNBC junkie; I stream it all day (so if you want to spear-phish me, send an email about my subscription to pro.cnbc.com expiring, harhar).
While drinking coffee this morning and going through my news feeds, the story about malicious Android applications floated to the top (via finance.yahoo.com):
So who is to blame? Google for not really vetting things before they go to the marketplace? Users for being tricked? Certainly more than one party can share blame, but based on the soundbytes from financial news, Google has been doing exactly what Wall Street wants them to do: MORE APPS!
The yardstick to measure success in the mobile marketplace is the number of handsets/devices AND number of applications. I’m sure Google is aware of that, because nearly every bit of financial news banter is about whether or not Android can gain share from Apple. RIM is acutely aware of this, too. If you see any of their latest ad campaigns (on financial TV) it’s about their Super Apps. What RIM is trying to do is tell the world, “nevermind the fact we dont have a bajillion apps, we have quality apps!”
@Google – I know you know you have a problem here. And I know that you know there isn’t much you can do about it. It’s a difficult dance: you need fast, wide-spread adoption to keep the financial analysts happy. But, if you continue down this reckless path, consumers will lose confidence in your platform and go to iOS because it feels safer. (BTW Google, YOUR Gmail app, written by you, keeps crashing on my phone…nasty error. When consumers see com.android, it hits the same nerve as the blue screen of death.)
The security industry can learn a lot by watching financial news! I’m curious to know what our blog readers think. Will we see a change from Google? How many news stories like this will it take? Maybe Google will stay out of it and let the anti-virus vendors get in to slow down our devices?
p.s. This email came in while this post was in draft:
Good morning! Like many of us, my morning includes a warm cup of coffee, working my way through some E-Mails, and skimming through the blogosphere. About halfway though this ritual I came across one very interesting piece by the Wall Street Journal. To call this article a simple blog post doesn’t do it justice. This story is the result of countless hours of mobile application analysis. The WSJ worked with our friends at Electric Alchemy to perform an in-depth study on how some of the most popular Android and iOS apps
(protect) disregard our privacy. During this study, Electric Alchemy found that you cannot count on mobile applications to “keep your secrets”. It was found that over half the apps tested transmitted data that could uniquely identify your device, a little less then half sent out some form of location data, and a small number even sent out personal information such as name and gender. The WSJ created an interesting and interactive portal to analyze their findings. It’s nice to see a piece like this use so much visualization.
It was also nice to see our tool Mallory was used during part of the analysis. We hope to see more uses of Mallory like this and are committed to keeping it updated and maintained. Once again, our hats off to EA and the WSJ. Well done!
How trustworthy are mobile platforms and devices?
For the maintainers of corporate networks and those charged with protecting sensitive data on those networks this is a very serious question. Corporate users are increasingly utilizing smart phones, tablets and other devices, which facilitate a more mobile and connected workforce. Often times, these devices are personal property of the user, yet users often use them for legitimate business purposes. Users desire the convenience of owning one, personal mobile device that can connect them to to a wide variety of data sources and applications: corporate email, personal email, personal data, personal applications and business applications. Reconciling device ownership and trustworthiness is a very difficult task.
Ultimately, a business has a right to protect its proprietary and sensitive information, even if that information resides on a personal device belonging to the end user. If a user desires to consume business resources and store sensitive information using their phone, then the business has a right to implement reasonable safeguards to protect the data and resources. Though the user owns the device and has the right to do as they please with it, they do not own all of the data on the device if they allow sensitive corporate data onto it.
A reasonable analogy, which approximates this situation, is a personally owned briefcase. For the sake of making an example, let us pretend the user has access to physical keys and sensitive printed documents. The user stores both these keys and documents inside of their briefcase. The user owns the briefcase, but the business still owns whats inside it. The business would expect the owner of the briefcase to take reasonable measures to protect the briefcase, and thus the contents of the briefcase. The same applies to virtually anything a person owns that can “contain” business assets. The problem is this gets much murkier and difficult to deal with in the digital environment, but the need exists and is clear.
Business policy is usually clear and requires that sensitive data must be protected at all times using reasonable measures that provide adequate security. And the subtext for that policy is to use a risk assessment to intelligently decide exactly what “adequate security” really is. Another consideration that goes into “adequate security” is what happens when an employee leaves an organization. What recourse does a business have to ensure their data is protected when the user is no longer an employee and the business cannot legitimately control the user’s device? One option is that the user’s personal device is wiped, no matter what, before it is put into an “unmanaged” mode where the business entity can no longer enforce policy on the device. Another option is to simply ask that the user be responsible and delete all of the data from their phone.
Now comes the fun part – the three major mobile platforms that users will typically wish to use. The three major platforms up for consideration in this article are: iOS (iPhone, iPad and iPod Touch), Android (tablets, smartphones) and BlackBerry (mostly phones). Some of these devices, depending on the version and configuration can meet what I consider “adequate” security. Others cannot. Now that the stage is set, the remainder of this article will explore the features of the three platforms.
First up for consideration are iOS devices (iOS does not stand for anything; it is a standalone entity now). First, one of the major caveats or things to understand about iOS is that every jailbreak out there is exploiting vulnerabilities in the operating system or a critical application on the device. Most observers would call these “security holes”. That said, Apple continually closes the holes and the security of the platform has improved steadily since its inception. Apple provides a robust set of security features for most iOS 4 devices. There are generally two approaches when allowing corporate data onto an iPhone or iPad: Force the device to become “managed” or only allow that data to be consumed inside of a trusted application, such as Good for iOS. Inside of a trusted application, ironclad control can be had on the data as it never leaves the confines of that application’s sandbox, assuming your user has not jailbroken their device. In managed mode it is possible to control many aspects of the device, such as password policy, user accounts and even restrictions on how the device can be used. It is also possible to issue commands to the device, such as remote wipe. Mobile device management servers can also query the device for a variety of information. More on the available device management servers and their features will be covered in an upcoming blog post. The features on iOS 4 rival the features available on the BlackBerry platform. iOS 4 takes the platform well beyond the limited policies available in Exchange ActiveSync. Network administrators have all of the tools they need to enforce policy on a personal user’s device.
BlackBerry has built a strong reputation on the security and corporate friendliness of the devices. Administrators have long relied on the features in the BlackBerry to set up, and enforce, effective information security policy. There are minimal gaps, if any, in the features provided by BlackBerry platform. The situation is thus very similar to that of iOS 4 (though BlackBerry has had these features for a much longer period). BlackBerry devices using a BlackBerry enterprise server can remotely wipe a device, enforce password policy and configure various other security settings remotely on a user’s personal device that should allow most corporate information security policies to be enforced
Android platform security, from a “managed security” standpoint, is not nearly as mature in terms of features provided by the OS. Only as recently as Android 2.2, the latest version of the Android OS, have features like Remote Wipe via Exchange ActiveSync (EAS) become available. There are some third party solutions out there. The more open nature of the Android platform means that third parties can more readily support the Android platform and provide features, such as remote wipe and password policy enforcement (these features are also available through EAS). There are also options, such as Good for Android, which again self contain many of the most common features a user desires.
The elephant in the room for the iOS and Android devices are the words, “jailbroken” and “rooted”. When jailbreaking and or rooting a device the goal is to circumvent or disable the pieces of the OS and platform that keep applications in a sandbox and running with limited privileges. These devices could be difficult, or even impossible, to enforce security policy on as the user can trivially circumvent the policy enforcement without the management servers being aware of it. The solution for this is much less clear and hinges on user’s being aware of the risks associated with jailbreaking and rooting, risks which they often are not aware of when they jailbreak or root their devices.
Overall mobile platforms are reaching a point where it is impossible to ignore that businesses, and users by extension, demand the ability to manage personal user devices (and corporate owned devices). iOS 4 and BlackBerry provide a compelling and rich feature set for device management and Android has turned a keen eye towards platform security. There are also many third party options and applications that aim to solve the problem of device management. Ultimately, the features provided by the vendor and operating system drive the features and provide the possibility for solutions to this problem that businesses can rely upon.
Hopefully this blog post sets the stage for future discussions on this topic. We closely follow this space and welcome opinions, links to other resources, and personal experiences of dealing with this new era of Personal yet Managed mobile devices.
- BES managed blackberry application that pushes data over the carrier IP network
- BES managed blackberry application that can use the WiFi radio in the device
- BIS blackberry where the end-user gets to grant security permissions, data over carrier IP network
- BIS blackberry where the application can use the carrier network
- BIS/BES blackberry that can do its authentication via the carriers LDAP/Radius via a reverse IP look-up
All of these can dramatically change the scope and type of testing we do.
The application security rights management is, — to use one word, awful! — Most applications are requesting rights to portions of the device they don’t need, most are requesting cross-application-communication rights they don’t need, and quite a few are wanting location data when they don’t really need it. — I can see why the enterprise IT manager is concerned about letting employee managed BIS RIM devices into their environment. It’s a mess! and it WILL lead to compromise of sensitive data if RIM doesn’t do something to fix this. The user needs a better way to make informed judgement calls on application rights management, and RIM needs to audit and remove applications from appworld that are requesting egregious permissions.
More about this here:
From Blackberry’s blog: IT Managers: Embracing Personal Employee Smartphones in the Enterprise
So the real problem is all the unmanaged applications,.. more about that later in Part 2.
RIM Security: Application Rights, what a mess – Part 2
Authenticating to a web application is a mutual process. Before a user enters credentials into the application, they validate the web applications credentials: its hostname, content, and SSL certificate (assuming it uses SSL).
Essentially, you validate the web site against what you know to be true (hostname and expected content). The browser validates that a trusted third party signed the web sites public key, and together they vouch for the sites identity by showing you a visual cue.
If the web site passes your personal validation and you decide to provide them, the application will take your credentials and validate them against what it knows to be true: a directory or other repository with user information. If it validates your credentials, it lets you in.
Dan Kaminsky’s DNS flaw makes it possible for attackers to spoof one of the three credentials web servers use to authenticate against users: the host name. The look and feel of a particular web site is already easy to spoof: phishers have been doing this for years. The only remaining credential the web server has that can’t easily be compromised is its SSL certificate, and the signature of a trusted third party (one of the commercial certifcate authorities).
Now that two of the three credentials could be spoofed, I started wondering how hard it would be to spoof the third. If you can get a valid SSL certificate, you can completely steal the identify of a web site. Unfortunately, it is not too dificult, and it is through no technical fault of the SSL protocol.
For me, it required no social engineering, no illicit hacking or ninja skills. In fact, it was kinda scary in its simplicity, and the real fault is in the process of the certificate authority (a big one). Is it that bad? I attempted to get certs for three HUGE Internet sites, and I was successful with one. An interesting application logic problem prevented me from getting another, and the certificate authority basically told me no (over the phone) for the third. The one I did get, however, is a biggie.
A few weeks ago I was looking into writing an application for my iPhone. At some point, I felt compelled to actually give it a shot, and I headed over to Apple’s web site to download XCode and whatever other tools I needed. Of course, I couldn’t remember my Apple developer center password, so I went through their “Forgot Your Password” routine on my Dell laptop.
A few seconds later, an email popped up on my Mac containing their magic link to pull up my change password form. I clicked it and went through the reset process, which ultimately asked me to authenticate with my new password.
Finally, I was redirected to the URL I originally requested . . . on my Dell. Hmm. How did my Mac get to where my Dell originally was?
Turns out Apple was maintaining a session for me on the server which retained my original URL. When you requested a URL that required authentication, Apple 302′d you to the login page with your desired URL contained in a query-string parameter. Once on the login page, you could tamper with the URL before it was stored in the session. You could also then enter your username (or, even better, someone elses’) and initiate the change password process.
When you chose to have Apple send you a link to change your password, the session you started with your original URL persisted via the data contained in the link. After you went through the process of changing your password and you finally authenticated, Apple sent down a small HTML file with a META-REFRESH tag that actually sent you where you originally wanted to go.
It is in this HTML where the badness happened. The original URL Apple stored in the session was being written here without being HTML encoded or properly validated. Apple did prevent you from specifying http://attackersite.com, but they did not validate against iphone.html”><SCRIPT>…</SCRIPT>.
The attack would have been as follows:
1. Tamper with the original URL and inject an XSS attack.
2. Enter someone elses’ username in the logon form, and click “Forgot Your Password”
3. Have Apple send the victim the password reset email.
4. Here is the kinda far fetched part: you need to hope/pray/socially engineer/somehow get the victim to go through the password change process, and authenticate.
5. Once they authenticate, you own their browser.
This attack is interesting to me for a number of reasons. First, it is a persistent XSS attack in a credential management system (ouch!). Second, the injection point is pre-auth, while the payload executes in the victims browser post-auth. Third, it is very easy to target individual users using legitimate emails from Apple: no spoofing required!
Apple was very quick to fix the problem, and even gave us credit here.
Good job Apple!
What is http://port139online.com:139/ ?
- Port139online.com:139/ IS a website
- Port139online.com:139/ IS a protocol
- Port139online.com:139/ IS a service (a service that tells you if your ISP is providing a tampered, filtered, limited, and incomplete service.)
I started port139online.com:139 to annoy the tech support agents at Cox Communications. I subscribed to their business Internet service because the sales rep told me that absolutely NO port filters existed for business customers. I don’t know if the sales rep lied to me on purpose to meet a quota, or if she just didn’t have all the information.
After several phone calls to Cox support, I finally got them to admit which ports they filtered (both inbound and outbound). They offered to reduce my bill by 45 dollars a month, but they would not remove the filters. I’m now a Verizon Business FIOS customer and couldn’t be happier with my pure, unmolested Internet.
“I’m going to say again, on the record in front of this Commission, Comcast does not block any Web site, application, or Web protocol, including peer to peer services. Period. Doesn’t happen.”
Oh really? Well http://port139online.com:139/ IS a website AND an application AND uses a WEB PROTOCOL… and guess what? Comcast IS blocking it.
Read more about it here:
And listen to the MP3 here: http://arstechnica.com/news.media/fcchearing25feb08.mp3
Reference: Comcast does block websites, ports, and protocols: http://taosecurity.blogspot.com/2005/07/what-does-your-isp-block-only-low-cost.html
**** NOTE ****
You can only visit http://port139online.com:139/ from Internet Explorer. Firefox blocks many ports.
I just got back from The Credit Union Information Security Professionals Association 3rd annual National event in Austin Texas where Rohyt and I were talking to the folks about www.PhishMe.com.
I have never attended a CUISPA event before and welcomed the opportunity. It was refreshing to see this industry work together. Credit unions don’t have the budgets larger institutions do and many of their technologists wear multiple hats. Security is a group effort. (as it should be)
Two major takeaways I had from the conference:
1.) Credit Union security professionals have a can-do attitude and value networking with their peers to solve their security woes
2.) Don’t show up to a Credit Union event dressed in New York-Financial attire (unless you enjoy looking like that creepy sales guy)
On the heels of the CUISPA event is a good white paper I saw on BankInfoSecurity.com titled The State of Information Security 2008 – Survey Executive Overview (Free signup)
Tom Field (Editorial Director) did a good job putting the overview together. The top security issues I heard the Credit Union folks discuss are the same ones captured in this survey. (It’s good to see that this paralleled what I saw in person at CUISPA … too often these days a whitepaper is just a synonym for marketing fluff.)
p.s. If you happen to attend my ShmooCon 2008 presentation please be kind with the Shmooballs.