|
|
 |
|
 |
|
Archive for the ‘Security Management’ Category
|
|
 |
|
 |
 |
|
 |
|
Thursday, February 7th, 2008
|
|
 |
|
 |
 |
|
 |
|
Wednesday, October 17th, 2007

Here at Intrepidus Group, we do a lot of mobile application security reviews. Much like standard web application reviews, some clients consistently turn out very secure apps. However some apps have a detailed finding list longer then a copy of War and Peace. One trend can often be seen across applications regardless of the client’s understanding of security. Mobile applications, at some point of their process, typically rely only on a phone number and short numeric pin for authentication to a remote server.
We’ve all know that weak passwords are one of the easiest way on to a system. If you let users have the option of choosing a secure or weak password, they will often take the easier to remember, less secure choice. I would say most major web based applications now require users to choose passwords with at least 6 characters, using mixed case and at least one number or special character. Typing in complex passwords with your standard QWERTY keyboard isn’t such a problem, but can you imagine trying to multi-tap some of your complex passwords on a 0-9 keypad? And into a stared out password field? It’s somewhat understandable that most mobile apps only require a numeric pin for authentication.
The problem of course is that most of these server side components can’t be limited to only allowing access from mobile devices (break out your old school User-Agent hacks and give some “.mobi” addresses a try). Limiting access to restricted IP address pools usually don’t help either and typically is a nightmare if client is supporting multiple providers. So in almost all cases, you have to assume an attacker can easily script a brute force attack against some part of the authentication (with mobile apps, it’s typically not just the front door login, but also a web service burried somewhere in the site that will handle authentication).
What’s a mobile vendor to do? CAPTCHAs, you say? Some of these are barely readable on a 22″ monitor. Good luck figuring out that text on your 1.5″ Nokia screen.
Account lockouts seem to be a reasonable recommendations at this point. But even with a low number of attempts (lets say 3 just for fun), I bet I could script something to get into at least 25% of your user base. What are these magic pin numbers?
1234, 5555, 1111
Yup, that’s some 13373 H@x0r shiznit right there. And if I have more login attempts, lets try the last four digits of the mobile number as the pin. Oh, that mega-hurtz now!!! For the sake of security, we need something stronger than an all numeric pin. Maybe it’s in the form of one time token over SMS, or maybe just a decent password multi-tap box for now (I saw this well done on the Blackberry Pearl recently). If you know of any other good solutions to this issue, drop us a line. I’ll be talking about this and more mobile security issues next week at the NJ/NY OWASP meeting.
-b3nn
|
|
 |
|
 |
 |
|
 |
|
Wednesday, October 10th, 2007
If you’ve been noticing a little silence on the blog recently, it’s been because a lot of the ranting has been going into developing what we think is a great anti-phishing user awareness tool. Take a peek at our main site at www.PhishMe.com
Conducting ethical phishing attacks has never been easier. User awareness will be improved, enforced, and for the first time for many users, easy to measure and trend over time. You can sign up for the mailing list right now that will let you know when the full blown service is launched. We will be offering free trial accounts that will allow you to get a taste of the features and test out if a few of your users will bite.
Another key feature of PhishMe is the built in templates to make your job of crafting phishing attacks simple yet effective and modern. How do you think your employees would respond to a message about a “virus outbreak”. Will they just follow the instruction in an email without verifying any of the information? What about a message to update their HealthCare information on a new third party site? The number of people that fall victim to these types of attacks will make you wonder why hackers even bother with anything that isn’t social engineering.
There is more to come in the future but for now, check out www.PhishMe.com
-b3nn
|
|
 |
|
 |
 |
|
 |
|
Monday, September 10th, 2007
A recent survey of over 279 IT Executives indicated that the greatest security challenge they faced was building an effective security awareness program and encouraging their employees to embrace it. Employees, albeit unaware, oblivious or unconcerned, continue to fall prey to conniving social engineers compromising sensitive data protected by millions of dollars worth of technology. The return on investment on building user awareness is apparent and no longer a hard sell for IT security staff. The real problem lies in building an effective program that actually changes the mindset of the employees. In a society where 90% of recovering coronary bypass patients do not change their dietary and lifestyle habits, will an awareness program really change their attitude towards information security?
This year we conducted numerous social engineering exercises for Fortune 500 companies, whose success relies heavily on the protection of intellectual property. These exercises involved scripted telephone calls to the organization’s customer service departments and mass phishing emails targeting a randomly selected set of employees. The objective was to collect sensitive data; the results were astounding. At one organization, 627 of the 1000 people targeted by phishing emails (aimed at pilfering the employees’ corporate VPN credentials) succumbed to the attack and only 4 of the 373 that did not respond reported the issue to information security staff. It’s not so much those statistics that made the results astounding, but the fact that the organization had recently conducted user awareness workshops that addressed the threats posed by social engineers. So where did they go wrong? Are the information security personnel to blame for developing ineffective programs or the employees for their lack of following direction? I believe it’s a combination of both; but the information security staff must assume the onus of taking the initiative of developing innovative user awareness programs that make a lasting impression. The majority of the security awareness sessions I’ve attended whave been unstimulating affairs couching the do’s and don’ts of security. Another approach used involves mandatory computer based training (CBT) programs for employees. At the end of the CBT session the employees had only improved their mouse-click speed. On the other hand, an approach I’ve found to be very successful entails sending out email to all employees (or to a representative sample of them) that mimics a true phishing attack aimed at garnering personal information. If the employees yield, they are immediately presented an informative message explaining the attack and redirected to the corporate awareness materials. This approach has proven to be very effective as the people who are most vulnerable are educated right away, and the next time a real phishing attack comes through, the emulation exercise will probably be the first thing that comes to the employee’s mind. One of our clients experienced a drop in the “hit rate” for such attacks from 67% to 4% over the course of three such phishing exercises!
-Rohyt
|
|
 |
|
 |
 |
|
 |
|
Tuesday, August 28th, 2007
As a security consultant with exposure to many large enterprises I admit I’m biased to RSA SecurID tokens. During penetration tests, our company has cracked tens of thousands of passwords. When I’m standing in front of a customer explaining why their password policies failed, they want to believe that changing this policy will help them. Secretly I know that humans will defeat the spirit of any password policy and that the best approach is to take the responsibility of password composition away from the end user. (When you stare at thousands of clear text passwords you develop a cynicism.)
August2007, you’ve been a good password, but it’s time I move on to owning enterprises with September2007.
The other day a friend asked me if there are any other products like SecurID he should be evaluating for his company as part of their plan to introduce two-factor authentication. Apart from SecurID the only other device that left me thinking “Hey this thing works” is Vasco’s Digipass. Any two factor system worth its weight in salt should provide authentication hooks to the popular services. If you plan to use the solution with custom web applications, you may need to dig a little deeper…maybe a lot deeper. Most solutions have hook-in APIs, but it takes some effort to piece it all together.
If you are evaluating two factor authentication devices make a list of the top services you need authentication for:
- Network devices
- Windows authentication
- Unix authentication
- VPN users
- Wireless user authentication
If a solution can cover 80% of your authentication needs and is cost effective, go with it. 80% coverage is 80% better than letting humans pick passwords; chances are with a little effort and creativity you can put something together to rein in the residual 20%. If you don’t have a two-factor solution, evaluate Vasco with the others.
-higB
|
|
 |
|
 |
 |
|
 |
|
Thursday, June 28th, 2007

Build that trans-continental security bridge!
While pen testing applications for one of my clients, I found that all the security issues I identified had the same 2 or 3 systemic causes. I made “strategic recommendations” – security training for developers and a security-aware SDLC, to name a couple. Months later, I went back to the same company, this time to test a bunch of other applications. The outcome wasn’t too different – same systemic problems. Once again, I emphasized the trend to my client. He told me that the applications were developed offshore, so my strategic recommendations from the last review were “impractical”. What could my client do to fight this negative trend?
Over the years, I’ve had several discussions on this topic with security gurus, software developers working in offshore companies, and some folks at the receiving end of insecure code. The situation is best described by the everybody, somebody, nobody and anybody joke. In short, no one has taken the initiative on the security front. What can everybody do?
Firstly, the outsourcers need to be willing to PAY FOR SECURITY. Yes, security doesn’t come free. This shouldn’t really be an issue given the tremendous savings realized by offshoring. But don’t just pay for security, demand it contractually. Just like you define performance metrics that the applications should meet to be accepted, define and enforce security metrics. Ensure that the terms of the contract are enforceable in a jurisdiction in your country (the outsourcer’s country). Suing the development company in their country will be a frustrating and futile endeavor at best!
Secondly, find out what measures your offshore partner takes to protect your data, to educate their developers on security, and to implement security in the SDLC. Remember, an ISO audit doesn’t cover all these areas.
Now for the offshore development company – use security as a competitive advantage. The last time I said this to some friends of mine who work as developers in India they said “We need VP approval to add even an optional line item in a proposal”. We all know what that means.
If you want to hear more on this topic, you can hear the recording of a webcast I did with Watchfire:
https://www.watchfire.com/securearea/seminararchives.aspx?id=253
-Rohyt
|
|
 |
|
 |
|