Nitesh Dhanjani

Microsoft BlueHat + Seattle

2008-05-15T16:56:42Z

I presented "Bad Sushi: Beating Phishers at their Own Game" with Billy at the Microsoft Blue Hat 2008 conference. It was a great opportunity to get to know the Microsoft security and product teams. I'd like to thank Billy Rios, Andrew Cushman, Katie Moussouris, Sarah Blankinship, Celene Temkin, Dana Hehl, and the rest of the Blue Hat team for inviting me. Speaking of Microsoft, I'm moving to Seattle tomorrow. I'm looking forward to getting in touch with a lot of old friends there so that should be good. If you are in the area, just let me know - it will be good to catch up.

Safari Carpet Bomb

2008-05-15T05:00:36Z

I recently communicated 3 security issues in the Safari browser to Apple. Apple let me know that they will fix 1 of the issues I reported. I will not discuss the vulnerability Apple has promised to fix until they release the fix because it is a high risk issue affecting Safari on OSX and Windows. I let Apple know that I'd like to discuss the 2 issues they won't be fixing with the security community and they let me know they are fine with it. A quote from my last email to Apple: ...since you do not consider issue 1 and 2 to be security related, I will feel free to discuss my thoughts within the information security community. Just let me know if you would like me to wait for some amount of time before I do this. Response from Apple: We understand if you want to discuss these in the security community. Before I get to the details, I want to make it extremely clear that the Apple security team has been a pleasure to communicate with. I sent them a couple of emails asking for clarifications, and they responded quickly and courteously every time. I want to publicly acknowledge that I appreciate this very much. Here are the issues I reported: 1. Safari Carpet Bomb. It is possible for a rogue website to litter the user's Desktop (Windows) or Downloads directory (~/Downloads/ in OSX). This can happen because the Safari browser cannot be configured to obtain the user's permission before it downloads a resource. Safari downloads the resource without the user's consent and places it in a default location (unless changed). Assume you visit a malicious site, http://malicious.example.com/, that serves the following HTML:






...
...
...
...

Now assume that http://malicious.example.com/cgi-bin/carpet_bomb.cgi is the following:


#!/usr/bin/perl
print "Content-type: blah/blah\n\n"

Since Safari does not know how to render content-type of blah/blah, it will automatically start downloading carpet_bomb.cgi every time it is served. If you are using Safari in Windows, this is what will happen to your desktop once you visit http://malicious.example.com/ : The implication of this is obvious: Malware downloaded to the user's desktop without the user's consent. Apple does not feel this is a issue they want to tackle at this time. In my most recent email to Apple, I suggested that they incorporate an option in Safari so the browser can be configured to ask the user before anything is downloaded to the local file system. Apple agreed it was a good suggestion: ...the ability to have a preference to "Ask me before downloading anything" is a good suggestion. We can file that as an enhancement request for the Safari team. Please note that we are not treating this as a security issue, but a further measure to raise the bar against unwanted downloads. This will require a review with the Human Interface team. We want to set your expectations that this could take quite a while, if it ever gets incorporated. [credit to BK have-it-your-way Rios for suggesting the term "Carpet Bomb" to describe this issue]. 2. Sandbox not Applied to Local Resources. This issue is more of a feature set request than a vulnerability. For example, Internet Explorer warns users when a local resource such as an HTML file attempts to invoke client side scripting. I feel this is an important security feature because of user expectations: even the most sophisticated users differentiate between the risk of clicking on an executable they have downloaded (risk perceived to be higher) to clicking on a HTML file they have downloaded (risk perceived to be lower). Apple's response was positive: ...we have been investigating the potential for a "safe" mode for local HTML. This is an area that requires a fairly deep investigation to address compatibility issues, and to determine the proper operation. Please understand that when we label this as a security hardening measure, we are not discounting the benefits that this could have. 3. [Undisclosed]. The third issue I reported to Apple is a high risk vulnerability in Safari that can be used to remotely steal local files from the user's file system. Apple responded positively and let me know that they are actively working to resolve the issue and issue a patch. I will post an update if I hear back from them. I'd like to thank the Apple security team for their timely responses and for letting me discuss these issues with the security community.

Amazon's Elastic Compute Cloud [EC2]: Initial Thoughts on Security Implications

2008-04-28T05:24:51Z

The Cloud Computing buzz is everywhere. The concept of grid computing on the Internet to provide elasticity and virtualization of resources is quite appealing, and hence there has been a lot of academic brain-storming going on recently that has given rise to abstract ideas on how cloud computing is destined to change the way technology resources are deployed and used. Amazon's EC2 isn't abstract - it's real. And it's very impressive. Q: What can developers now do that they could not before? Until now, small developers did not have the capital to acquire massive compute resources and insure they had the capacity they needed to handle unexpected spikes in load. Amazon EC2 enables any developer to leverage Amazon's own benefits of massive scale with no up-front investment or performance compromises. Developers are now free to innovate knowing that no matter how successful their businesses become, it will be inexpensive and simple to ensure they have the compute capacity they need to meet their business requirements. The "Elastic" nature of the service allows developers to instantly scale to meet spikes in traffic or demand. When computing requirements unexpectedly change (up or down), Amazon EC2 can instantly respond, meaning that developers have the ability to control how many resources are in use at any given point in time. In contrast, traditional hosting services generally provide a fixed number of resources for a fixed amount of time, meaning that users have a limited ability to easily respond when their usage is rapidly changing, unpredictable, or is known to experience large peaks at various intervals. I was able to go through the Getting Started Guide and I had myself a Linux environment in the Amazon cloud in no time: Amazon EC2 presents a true virtual computing environment, allowing you to use web service interfaces to requisition machines for use, load them with your custom application environment, manage your network's access permissions, and run your image using as many or few systems as you desire. To use Amazon EC2, you simply: * Create an Amazon Machine Image (AMI) containing your applications, libraries, data and associated configuration settings. Or use pre-configured, templated images to get up and running immediately. * Upload the AMI into Amazon S3. Amazon EC2 provides tools that make storing the AMI simple. Amazon S3 provides a safe, reliable and fast repository to store your images. * Use Amazon EC2 web service to configure security and network access. * Start, terminate, and monitor as many instances of your AMI as needed, using the web service APIs. * Pay only for the resources that you actually consume, like instance-hours or data transfer. Based on my recent experience, here are some initial thoughts (with bias on security): Pre-pwned Images. Amazon lets you select from a list of AMIs (Amazon Machine Image) to kick start your virtual environment. They even let you submit your own AMIs to share with other EC2 users: To add your AMI: 1. Make sure you're logged in to the site. 2. Click the "Add a Document" link in the Tools box to the right. 3. Enter as much information as possible in the form, then click Preview. (Tip: You can use HTML in the listing body.) 4. If everything looks good, click Submit. Otherwise, click "Go Back/Edit" and make your corrections. Important: Your listing will show up on the site after a quick review by AWS. Interesting. I wonder what the "quick review" entails. What if someone submits an AMI with a back-door installed? Does the Amazon team have the resources and processes to identify malicious AMIs before sharing them with their customers? Keys to the Cloud. The Amazon services are based upon a key-based approach (you get your own key-pair to authenticate to Amazon and to sign your own AMIs) - this is good. There is the burden of key management, but it is still a better approach than implementing a static password based system. Firewall. Instances initially boot in a firewalled environment where you have to explicitly open up ports to allow inbound access. This is a good approach as well. Dude, Where's My Data? Data in the virtual instance only persists as long as the instance is running. From Amazon's FAQ: Q: What happens to my data when a system terminates? The data stored on a specific instance persists only as long as that instance is alive. You have several options to persist your data: 1. Prior to terminating an instance, backup the data to persistent storage, either over the Internet, or to Amazon S3. 2. Run a redundant set of systems with replication of the data between them. We recommend you should not rely on a single instance to provide reliability for your data. This means that existing applications and systems need to be re-engineered to persist data in the cloud (outside of the virtual environment). Makes sense, in order to take advantage of the elasticity of cloud computing, your data has got to be 'in the cloud' and not tied to a single virtual instance. This may have some legal implications, and it may make some organizations (initially) uncomfortable to come to terms with the idea that their live data does not persist on their own hardware. I'm afraid we are likely to see cases of security issues arising from badly re-engineered application code as developers attempt to code their applications to persist data using services like S3 instead of local data stores. Risk Based on Data. Most often, organizations fail to risk inventory their assets based on the type of data the system reads and writes. The cloud computing paradigm will force organizations to think of data foremost when building a risk inventory. This is a good thing. Security Principles. Obvious and well known security principles apply to cloud based services like EC2. You've got to ensure that your VMs are configured securely, that your applications are developed securely, and that you communicate securely - think about authentication, authorization, access control, cryptography, and monitoring on all layers and tiers of the system. The Threat of Mono-culture. I'm reminded of Dan Geer's words on the threat of mono-culture. If you start up hundreds of instances of a virtual image, a vulnerability in one instance will apply to all other instances of the same image. Imagine a situation where a remotely exploitable vulnerability is found in the generic kick start image Amazon recommends to its customers - suddenly, the security of a considerable amount of resources and data within the cloud will be at stake. Cloud Insecurity. Security issues within the Amazon web services will have an extremely high impact on EC2 customers. For example, suppose a malicious user is able to invoke the services behind ec2-terminate-instances to terminate instances outside of his or her role. Such a vulnerability could be abused to black-out the Amazon cloud. Perimeter? What Perimeter? The concept of relying on a network based parameter has been losing steady ground. Cloud computing services like EC2 will be a catalyst to this recommendation - data and resources will be distributed in a shared cloud space. The concept of network based perimeter will no longer apply. Instead, security controls will need to be assured on all layers and tiers of the architecture. However, there are bound to be cases where organizations will try to build trust within the cloud to construct a virtual perimeter to imitate legacy designs. Service Provider Liability. As the concept of cloud computing gains ground, it is likely that the service providers will seek to implement technical solutions that will allow them to provide resources in the cloud without the legal liability of hosting and computing secret or illegal data. For example, a consumer or legal requirement may warrant the customer of the cloud to have the ability to compute or store data in the cloud without exposing the computation result or data to the provider. This may facilitate tangible products to arise from academic concepts of zero knowledge based solutions. Single Point of Failure. Amazon provides the concept of Zones and Regions (currently limited to 1 region): Amazon EC2 now provides the ability to place instances in multiple locations. Amazon EC2 locations are composed of regions and availability zones. Regions are geographically dispersed and will be in separate geographic areas or countries. Currently, Amazon EC2 exposes only a single region. Availability zones are distinct locations that are engineered to be insulated from failures in other availability zones and provide inexpensive, low latency network connectivity to other availability zones in the same region. Regions consist of one or more availability zones. By launching instances in separate availability zones, you can protect your applications from failure of a single location. This is good - Amazon allows for instances to be booted in different zones to prevent impact from the failure of a particular location. But what about Amazon as a whole as the single point of failure? The concept of resources being distributed geographically makes this scenario less probable. As cloud offerings from other companies emerge, it may make sense for larger organizations to host on other cloud service offerings to further decrease the single point of failure scenario. Doing so could be a little difficult since competing services may require adherence to specific programming languages and environments. For example, the Google App Engine SDK is currently limited to Python and is not based on the concept of allowing users to configure full blown virtual environments. Perhaps I'll write my thoughts on the Google App Engine in the near future. I'm excited about the concept of cloud based computing. It's the future, and Amazon has done a good job of turning the hype into reality. I'll be interested to see how Google's offerings mature, and what Microsoft and IBM have up their sleeves. These are just my initial thoughts on security implications of the emerging cloud computing paradigm. I'll continue to post updates as I have time to think about it some more. If you'd like to share some ideas, I'd be interested to hear them.

Interview With [IN]Secure Magazine

2008-04-22T23:19:46Z

Issue 16 of [IN]Secure Magazine is available. Mirko Zorz interviewed me in this edition (Page 41). If you decide to read it, I'd be delighted to hear your thoughts and feedback. The magazine edition of the interview is much better looking and highly recommended (as are the other articles), but for the sake of convenience, the interview session is below. Enterprises need to formulate high-level goals for application security efforts before implementing specific service lines. What are the key areas they have to cover in order to make their endeavor successful? I agree. You've got to strategize high-level goals before deciding on specifics. Most businesses are not in the business of being secure. They are in the business of generating revenue, protecting their brand, and their intellectual property. Application security goals must derive from and support these business goals to promise risk reduction across the enterprise cheaply and effectively. Such promises in turn require specific implementations and processes such as hiring the right talent, laying the right framework, hooking security into the development lifecycles, training, metrics, and executive support. Despite owning a plethora of software and hardware solutions, the critical asset to an organization is still the security professional who works with those acquisitions. How exactly important is the security team? Talent is key. What good is an application scanner or code analyzer if you don't have professionals in your team who actually understand the results? The fastest way to lose credibility with the business is to employ individuals who cannot go beyond running assessment tools and exporting reports. The job of a security team in any organization is not to hire people who can point and click their way into running assessment tools, but to establish a world-class effort that serves the needs of the business. You do that by hiring subject matter experts. You do that by hiring talent that can impress the business and demonstrate tangible value and progress. With the threat landscape constantly evolving and old issues still not resolved, the organization has to battle problems such as a lack of security awareness that bring in a myriad of complications. What is the right approach to take in order to battle difficulties one can't completely protect against? That's a two-part question: how to deal with known issues, and how to keep up with the latest attack vectors. First, you've got to establish a process that aims to remove security gaps at the root. Training and awareness offers the best ROI in this regard: bugs that don't get created in the first place - imagine that! It is also vital to embed security into the development lifecycles of applications. However many organizations have trouble deciding where to begin. The solution is to assign efforts based on risk. Start by understanding what applications you own and what their business impact is. What type of data do these applications read and write? What is the business criticality of these applications? Once you have a good understanding of your application portfolio, it will be much easier to assign effort so you can focus clearly. As for the second part of the question, the solution is to invest effort into research and development so you continue to understand how the latest attack vectors may target your software. Yet again, training and awareness wins in this regard. Set aside a budget to send your team to information security conferences and training programs so they can soak up new knowledge. Allow analysts to take some time out to investigate the latest attack techniques. Most hands on security professionals are scientists at heart - understand what makes them thrive and support their talent. Support their desire to learn new ways to break security controls. Finally, capture and communicate this knowledge to the business. For example, ensure your threat modeling attack libraries are up to date and reflect the latest attack vectors, that your code review and assessment methodologies are bleeding edge, and that you take time out to brief the architects and developers on what they need to know to keep up. Although applications have the largest attack vector today, CSOs don't take this into account when strategizing security spending. What kind of issues can this bring in the near future? I overwhelmingly agree - the security spend of many organizations is out of whack with the real threat landscape. I feel there are multiple reasons behind this situation, the most common reason being, in my personal opinion, that many individuals who have been hands on in the past remember and hold on to the notion of the network layer being the only big thing to worry about. I can sympathize with that view - if you rewind a couple of years, majority of the high impact attacks could be identified and blocked via network controls because the attack surface of applications was low compared to today's scenario where a typical enterprise level web application is comprised of millions of lines of custom code. Perhaps another reasoning for this situation is that solutions around application security do not provide the instant gratification of throwing in a few appliances to solve problems. Well, perhaps, I should take that back, there are a few web application firewall solutions in the form of appliances that are starting to be marketed that way, but that's the nature of marketing and I'll save my rant for another forum. Also, quite unfortunately, there are going to be more situations in the coming future where many security efforts will align with reality after learning the hard way - i.e. after an application related exposure has already taken place. That said, the onus is still on the security professionals and researchers - we need to do an even better job of demonstrating impact and educating decision makers on why a solid application security strategy is vital to any organization's overall security effort. While having consultants come in and perform black box penetration audits of applications every year is more costly than investing in a solid SDLC process, many organizations still believe it to be the proper strategy. What should they take into consideration when making this decision? Black-box penetration tests are useful, yet they are extremely expensive and ineffective when relied upon as an exclusive solution. Paraphrasing a colleague of mine, "Companies that solely on black-box assessments to guide their security efforts do something similar to having consultants come in, throw a grenade at them, and have the consultants close the door on their way out". Gary McGraw likens this situation to what he calls a "Badnessometer". Black-box assessments correlate to symptoms that reflect the level of trouble you may be in. The response shouldn't be to just fix the black-box assessment results, but to respond to the situation strategically, and ensure you are responding to and eliminating the root cause of your problems to make sure they do not re-occur. The solution is to "push left". The ingredients of a typical application development cycle, from left to right, includes the requirements phase, followed by design, then implementation, test, and production. The more effort you put into implementing the right security controls at an earlier tollgate, the lesser it will cost you. For example, assume that a review of security controls during the design phase results in an architect having to re-engineer the authentication mechanism. Now, imagine if this issue was not caught during the design phase, but uncovered during an attack & penetration assessment after the application is in production. It is not trivial to re-engineer a product that is already in production. And it is extremely costly - multiple times costlier. Black-box assessments, coupled with the right strategy, do have their place. Going back to Gary McGraw's point, they help uncover symptoms. These assessments can be used to further augment and enhance an existing security SDLC process. For example, if you are finding too many issues via black-box assessments during pre-production that you missed to uncover during design and test, then it is time to re-evaluate your SDLC process and approach. Besides having an excellent technical background, the CSO has to be good at demonstrating a tangible impact of his actions to the management in order to justify security spending. This ability is becoming increasingly important and can take the focus off the main areas of security he should be working on. How can the CSO lighten this load? Justifying security spend for application security is not difficult. In addition, application security efforts can have positive political side effects for the CSO and the security team. I'll tackle these two points separately. First, application security must tie into the overall IT risk strategy. Start with asking what the company's business goals are, and how you want to demonstrate value. Map these goals to efforts based on risk that will flow into specific tactics that can demonstrate ROI. For example, if your organization currently relies on yearly black-box assessments, calculate the cost of performing the assessments in addition to the cost of remediation. Compare the cost with progress you've made by evaluating the last two assessment results for the same application. Most likely, you will find that you have made little tangible progress in the form of risk reduction and that the remediation cost has been high. Now calculate the cost of investing in a "push left" scenario. Put these two scenarios side by side, and you'll have a solid case for ROI. The returns for a good application strategy are tremendous. The important thing is to continue to measure returns by formulating a good metrics program. Keep track of how security is helping business and technology improve, measure the drop of defects per lines of code, measure the amount of risk reduction. Show value. Demonstrate how your program is embedding security into the organization's DNA. To my second point, a well thought out application security strategy can help the CSO politically. If you hire the right talent, and approach business and technology with the right attitude, i.e. to enable and not disable, you'll make a lot of new friends. Security departments often complain that the revenue generating business units view them with disapproval, yet the quest for application security is a fantastic opportunity for the security team to work closely with business. Do it right, and the business will love you for it. You will win their credibility and gratitude. How important is threat modeling? If you want to do application security right, you've got to invest in threat modeling. The goal of a threat model is to enumerate the malicious entity's goals even if the threats being enumerated have been mitigated. This helps the business, developers, architects, and security analysts understand the real world threats to their applications. Threat modeling should be initiated during the design phase of the application and it should be treated as a living document. As the application development process progresses, the threat model can be further enhanced so it is increasingly valuable. For example, a threat model created during the design phase can be further augmented to map to actual code review results to help developers and architects understand areas they need to improve on and areas where they are doing a good job. Threat modeling is a core component of the push-left strategy, so you eliminate defects as early as possible. What recommendations would you give to a new organization that is just starting to build an application security strategy? Once you've derived from your overall business and security goals, it's time to list specifics. 1. Talent and Framework. Hire the right talent and lay the framework: policies, requirements, best practices, and methodologies. 2. Kick start efforts on critical applications. Kick start your efforts on your critical applications: work with business and technology to help them understand the risks to their applications and what they can do to eliminate them as early as possible. Help them invest their by offering advise on their architecture level security controls and threat modeling. Give the development teams guidance on secure coding policies. Assess the code for security defects, followed by a penetration test before the application is turned over to production. Ensure proper application logging mechanisms are built in and monitored. 3. Application portfolio. Come up with a formula to calculate business impact of an application based on key questions. Rank the applications by impact, and assign effort. At this point, you may want to take regulatory requirements into account, most often based on the type of data handled. 4. Invest in training and awareness. The security team, business, and technology must have access to continuous security training. Calculate metrics from code review results to target security training to certain business units. After a code review assessment, get a few of the developers into a room and show them the impact of the vulnerabilities found. Work together to enhance the threat model and possibly fixing the defects. The goal is training, awareness, and knowledge transfer. 5. Metrics. Demonstrate value, for example, a graph showing defects per lines of code decrease within the span of the last few months. Demonstrate risk reduction per business unit which often leads to some healthy competition, and that's a good thing. Overall, you've got to show application risk reduction across the enterprise. 6. Stay cutting edge. Retain talent. Treat your team well. Understand the latest attack vectors. Invest in research. Communicate and support the business - they are your clients and they need your help.

Be Secure, and You'll be Compliant

2008-04-17T06:07:53Z

There's been some recent chatter and speculation on the upcoming enhancement to the PCI standard. Among the discussions, I'd like to publicize my opinion on one argument I've heard multiple times during the last few days. The argument goes something like this: The cost of performing security code reviews is too high, but the cost of performing black box reviews and/or implementing web application firewalls is lower. Therefore, the solution is to recommend that organizations rely on penetration assessments and/or web application firewalls. Three points: First, no company should ever strategize their overall security efforts based on a 3rd party requirement. A company's strategy should be based on its specific business goals that should be used to drive the security strategy. Tony Spinelli, CSO of Equifax, has articulated this point very well. He says: Most companies and [their] security leaders are getting lost because of [having to be] compliant -- regulations saying you have to do X or Y.... A lot of people are letting compliance drive security, and that's as wrong as you can get....You have to become secure to be compliant; otherwise, you respond and react and reinvest without leverage. Second, it is not true that security code reviews are overwhelmingly more expensive than black box reviews. The entire purpose of a security code review is to combine it with a solid security SDLC process, with the aim to push left, and the goal to find and remediate security vulnerabilities earlier on in the development cycle - the overall costs of which is likely to be lower than the cost of relying upon black-box penetration assessments. Run, don't walk, from any vendor that tells you to base your application security strategy on black-box penetration assessments because anything else is too expensive - you'll end up paying through your nose while failing to fix the root cause of what's ailing your development efforts. Third, web application firewalls can be useful, yet the most terrible band-aids when applied for the wrong reasons. Just because a 3rd party standard may require it doesn't mean it's the only thing you need to do. In summary, please do not let a requirement like PCI drive your overall strategy. Understand your goals and needs, aim to be secure, and you will be compliant. Try the formula the other way around, and your strategy will be flawed, your security budget won't be big enough, you will struggle to keep up with requirements & regulations, and you will fail to demonstrate risk reduction to your organization.

RSA 2008...Yawn

2008-04-16T23:30:23Z

I presented "Breaking and Securing Web Applications" at RSA 2008 last week. The best part was the enthusiasm exhibited by the questions people came up to me with after the talk. I owe a few people the updated slide-deck, I'll get around to that shortly. The conference was quite uneventful and predictable. It was a good opportunity to catch up with old friends though. The high point of my stay at San Francisco was when I ran into the Hippy Hacker; obligatory photo below.

Black Hat Europe 2008

2008-03-31T10:23:55Z

I presented Bad Sushi: Beating Phishers at their Own Game (with Billy) at Blackhat Europe (Amsterdam) 2008 last week. I always enjoy doing this talk, and the feedback was quite positive. For more information, check out Nate's coverage of the conference over at ZDNet's Zero Day. I'll be presenting the Bad Sushi talk at Microsoft's BlueHat conference in May this year. I'll be apartment hunting and visiting friends in the Seattle area the last week of April, right before the conference, so if you happen to be in Seattle at that time just let me know!

The iPhone SDK Press Conference

2008-03-10T05:11:48Z

A quote from Steve Jobs during the iPhone SDK Press Conference last week: If they write a malicious application we [will] track them down and tell their parents. In other words, the iPhone applications will need to be digitally signed by Apple, and the developers will be required to register with Apple. It will be interesting to see what kind of information developers will be required to provide to Apple to register. Will they ask for the developer's credit card number? How will the developers authenticate their identity with Apple before they are allowed to submit their applications to be included in the store inventory? Jobs also displayed the following slide to illustrate what types of applications will not be allowed on the iPhone: Three points:

Apple may have a difficult time auditing applications to ensure they meet their criteria. What is the absolute definition of malicious in the given context? Malicious to whom? The end user, Apple, or AT&T? Perhaps all of the above. Now, how does Apple go about obtaining assurance whether a given application is malicious or not? Will someone try out every application that is submitted? Will someone at Apple review the source code of every application to ensure it does not invoke any malicious operations and only calls published APIs?
Applications may not run in the background. This is quite likely to be a decision based upon processing resource constraints. Note that Apple's own iPhone applications such as Mail, iPod, and SMS do run in the background.
The Unforeseen clause means that Apple reserves the right to ban any application at any time. Will they be reasonable with the developers? I don't see why they wouldn't be as long as it doesn't hurt their bottom line, for example: 11:32AM - We asked: Will SIM unlock software be considered software not allowed in the app store? A: Steve: (pause) "... yes." Laughter.

A video of the iPhone SDK presentation is available.

Black Hat Briefings 2008 (Washington DC)

2008-02-27T04:06:58Z

I presented Bad Sushi: Beating Phishers at their Own Game with Billy Rios last week at the Black Hat Briefings in DC. The best part of the experience was the opportunity to talk to people in the audience after the presentation, and to hear their perspectives on the subject. Here is what others have to say about the presentation: Black Hat Lifts the Cover Off ID Theft Phishing Networks [eWeek] The myth of the Ninja Hacker [CNET] Black Hat D.C. wraps up [CNET] Black Hat, Day 1: Cracking GSM and skimming ATMs [ZDNet, thanks Nate] Black Hat: Honor Among Thieves? Here is some additional coverage: Bank scammers scammed, says security researcher [The Register] World of Phishing Exposed (podcast) Researchers Expose "Stupid Phisher Tricks" [Dark Reading] How phishers work -- the inside story [Guardian] Most Phishers Clueless, Say Researchers If you were unable to attend the presentation, but would like to get a glimpse of the material, please read the on-line interview with Billy and me that I linked to earlier: Interview with Nitesh Dhanjani and Billy Rios, Spies in the Phishing Underground. Since the presentation, Billy and I have discussed new material applicable to this presentation, and so I think we will be continue to present updated versions of this talk at future security conferences.

Bad Sushi: Beating Phishers at their Own Game

2008-01-28T08:53:53Z

Help Net Security has posted an interview with me and Billy Rios titled Spies in the Phishing Underground. If you enjoyed the interview, and if you want more details and screen-shots, check out our talk at the Federal Black Hat Briefings 2008 [February 20]. The title of the talk is Bad Sushi: Beating Phishers at their Own Game. Following is a brief description: This talk will expose the tools and tactics used by the phishing underground. Follow us as we track real life phishers hiding in the shadiest corners of the Internet, analyze the tools used by phishers, and discover the sites where real life identities are being bought and sold. The specific topics covered by this talk will include: how phishers set up a phishing site, a look at the back-doors and phishing kits used by phishers, determining how phishers steal identities, and a detailed look at the forums used to buy and sell the stolen identities. We are excited about all our discoveries and we looking forward to the conference. We are also concerned about all the information we have discovered, and we are already sharing this information with the authorities. Also, Billy does a fantastic job of summing up our enthusiasm and concerns in his blog.

What Have You Changed Your Mind About? Why?

2008-01-21T05:12:32Z

I think it is extremely important for an organization to account for the reality of doing business (Risk based approach compared to the purist mentality of securing everything) when strategizing an information security plan. It is true that an individual who has a habit of perceiving security issues as purely a technology problem without understanding the business reality is likely to make bad security decisions. However, I think some people in corporate security take this argument too far and end up awarding critical roles to individuals that do not have the appropriate skill-set and mind-set. More often that not, this happens when organizations responsible for information security misunderstand the argument to mean that you only need to probe for the understanding of business fundamentals and process management when recruiting for talent. Depending upon the criticality of the role awarded, this can deem disaster. It is my opinion that, in order to construct a talented security team, it is most important to select leaders that have a genuine passion for the technology aspects of information security, yet understand business reality enough in order to serve as liaison between technology and business. I believe that genuine passion for information security derives from passion for technology, which in turn derives from passion for science. One does not need a degree in science to satisfy this requirement, but only the tendency to indulge into scientific discourse. The following is therefore one of my favorite questions to ask individuals that have progressed in their career in information security: What have you changed your mind about? Why? John Brockman has posed this question at http://www.edge.org/q2008/q08_index.html. Richard Dawkins does a fantastic job of explaining why this is such an important question: When a politician changes his mind, he is a 'flip-flopper.' Politicians will do almost anything to disown the virtue - as some of us might see it - of flexibility.... Leading Democratic Presidential candidates, whose original decision to vote in favour of invading Iraq had been based on information believed in good faith but now known to be false, still stand by their earlier error for fear of the dread accusation: 'flip-flopper'. How very different is the world of science. Scientists actually gain kudos through changing their minds. If a scientist cannot come up with an example where he has changed his mind during his career, he feels the need to apologize. He is suspected of betraying the spirit of science. He is hidebound, rigid, inflexible, dogmatic! It is not really all that paradoxical, when you think about it, that prestige in politics and science should push in opposite directions. I'll take it no further than just to point it out, with a whiff of irony. Now that I have brought up the importance of this question, it would be fair for you to expect me to answer it. I can come up with a list of things I have changed my mind about, but I'll stick to one within the scope of information security: I used to think that weak security controls and insecure software design are the root-cause for the rise of incidents pertaining to the compromise of PII (Personally Identifiable Information; think Social Security Numbers, etc) and other financial details (Credit Card numbers, bank account numbers, etc) that ultimately leads to the compromise of people's identities (via stolen or lost laptops, phishing, web-site compromise, etc). Of-course, weak security controls are no excuse: every effort must be made to securely configure systems and to ensure that secure software design efforts are in place. In other words, insecure system and application implementations obviously facilitate the problem but I no longer believe that they are the root-cause. I believe that the root-cause for the reason why people's identities are being compromised at an alarmingly increasing rate (data leakage) is that the financial institutions authenticate transactions based on a static identifiers. To put it another way, think of a scenario where you are given an identifier such as the following: 1R3D1D9JJBKDD2ADCDB09234. You are then told that your identifier is your identity, and it can never be replaced. Having heard this, you do your best to protect its secrecy. However, you are also told that you need to disclose the identifier in order to commit any financial transaction. In other words, you must disclose it every time you apply for a loan, open a bank account, sign a cell phone contract, sign up for cable TV, obtain employment, and so on. After a few years, your identifier is likely to be found persisted on hundreds of databases across the world: your employer, your bank, your cable TV company, and any other organization you have committed a financial transaction with is likely to have a copy of it. The companies you give this information to promise to perform routine security audits to ensure that your identifier is secure. Here's another scenario. Let's assume you live in a world where your email address is also the password used to access your email. You are therefore instructed to only share your email address with people you trust. Your web-based email provider promises to perform routine audits on its applications to give you assurance that they are free of security vulnerabilities. The examples sound absurd, don't they? Well, they are good examples of how Social Security Numbers (SSNs) work, and exactly how Credit Card numbers work. You take care not to blurt out your SSN to anyone on the street, yet it is likely to be stored on hundreds of corporate databases. You take care not to expose your Credit Card number, but you must hand it over to people you don't know at retail stores if you want to use it. We aren't going to solve the problem of online PII compromise and identify theft just by writing even more secure code (although it certainly helps), or by continuing to play whack-a-mole with phishers. The system of relying on static identifiers to commit financial transactions needs to be rethought. Commercial financial institutions such as credit card companies and banks realize that the cost of implementing a new system that does not merely rely on static identifiers is higher than the fraud committed, so they decide to accept the cost. This is the reason why the system has not changed. Unfortunately, financial institutions only take into account their cost when making this decision, but it also ends up affecting the lives of millions of people who have to pay with their identities when such fraud is committed (this cost is also shared by other companies that want to have the capacity to process transactions. The PCI standard is a good example of this situation). For the next few years, we are going to continue to apply Band-Aids around the problem of data leakage, and continue to play whack-a-mole with the phishers without solving the actual problem at hand. In order to make any significant progress, we must come up with a brand new system that does away with depending on static identifiers. We will know we've accomplished this when we will be able to publish our credit reports publicly without compromising our identities. What have you changed your mind about? Feel free to comment on my O'Reilly blog. [In the spirit of science, I'd like to conclude with a video clip from the TED conference that delights me every time I watch it]:

DeepSec 2007 @ Vienna, Austria

2007-11-19T05:17:19Z

I'll be speaking at the DeepSec 2007 conference this week. More information at the conference website.

Illogical Arguments in the Name of Alan Turing

2007-11-13T04:55:44Z

The Halting Problem described by Alan Turing in 1936 states that is impossible to come up with a general algorithm that can compute if a given algorithm will terminate (for all possible input pairs). In other words, the only way to generally determine how a program will behave is to execute it, and this may not give you a definite decision either (just because an algorithm seems to be in a loop for example, doesn't automatically imply that it will never terminate at a later stage). The keyword here is general (it may be possible to tell if a particular instance of an algorithm will terminate). The case of the Halting Problem is often brought up to suggest that it is impossible to write perfect application security assessment tools. While this is formally true, take the limitations posed upon the abilities of static code analysis tools for example (true, but static code analysis tools are useful regardless, more on this below), I've come across numerous situations where people invoke the Halting Problem to form irrational arguments. The conclusions reached in these situations may end up being true, but the arguments are themselves illogical if the premises and inference do not flow into the conclusion. Here are two examples of bad arguments I've heard people make in the name of the Halting Problem: Static Code Analyzers are not useful at all because they are limited by the halting problem. Response: It is true that a code analyzer cannot include a general signature that can solve the halting problem. However, code analyzers are extremely useful regardless of this limitation. They have the ability to parse source code for known patterns of vulnerabilities with a reasonable degree of assurance. Most (think 80-20 rule) High risk vulnerabilities affecting web applications are often found to be instances of popular classes of defects, many variants of which are not limited by the halting problem. Therefore, static code analyzers are useful to information security regardless of the halting problem. Logic flaws (that give rise to security vulnerabilities) in applications can never (ever!) be found by an application assessment tool because of the halting problem. Response: Assessment tools could have indeed been a lot more useful in automatically finding logic issues had there been a solution to the halting problem. However, this limitation does not imply that assessment tools can never be programmed to find logic issues that have security implications: it is possible to deduce some defects that appear to be 'logic only issues' into known patterns that may be automatically parsable with a reasonable amount of certainty. Therefore, it is not true that *all* logic flaws are impossible to detect via automated analysis. I've noticed that marketing departments of some information security companies like to throw around the limitations of Turing's problem to sell their consulting services. I agree that a human brain must always be involved during security assessments (a fool with a tool is still a fool), so much so that I consider assessment tools to only be a first-pass sweep for vulnerabilities during any security assessment. This is because security assessment tools are limited in their ability to find many classes of security issues - however their limitations arise from factors that are in addition to the undecidable problem proposed by Turing. Furthermore, as I stated above, certain problems, that may at first glance seem to be purely logical in nature can be deduced to specific patterns based upon probability and frequency. I've also noticed that some security tool vendors like to use the halting problem as an excuse for why their commercial tools lack the ability to test for certain classes of vulnerabilities, even when the feature set being requested is not bound by the halting problem. It is possible to arrive at true conclusions based on flawed premises and inferences. However, such arguments are inherently flawed because, for an argument to be logical and rational, the premises and inferences must deduce to the conclusion. I hope you will keep this in mind the next time anyone postulates Turing during a discussion.

hack.lu 2007

2007-10-15T03:51:03Z

I'll be speaking at the hack.lu 2007 security conference in Luxembourg on October 20, 2007. My talk is titled Breaking and Securing Web Applications. The conference agenda is here.

Yahoo! Susceptible to Cross Site Request Forgery (XSRF) Attacks

2007-10-11T04:07:35Z

UPDATE:Yahoo! just let me know that these issues have been fixed. Many organizations offer Mobile and WAP enabled flavors of their web applications. These applications may appear to have restricted functionality, but a security vulnerability in these applications can allow malicious users to launch attacks whose implications may propagate to the main applications. For example, a persistent XSS issue that may be present in the mobile version is likely to show up in the full-fledged version of the application (Cross-Application-XSS). Businesses seem to derive a false sense of security from the fact that these "mobile" web-sites execute lower amount of transactions than the full-fledged version: it is thus incorrectly assumed that the security risk posed by the mobile version is lower. This is an incorrect assumption because vulnerabilities present in the mobile version of the application can easily propagate to the main application. Consequently, these applications are not held up to reasonable security standards causing the business and it's customers' data to be at risk. This seems to be the case with Yahoo! Their "mobile" version is available at http://us.m.yahoo.com/. The Yahoo IM service and the Calendar service exposed at this location are vulnerable to XSRF (Cross Site Request Forgery). Yahoo IM. Assuming that a Yahoo! user has logged onto his or her account using a web browser (Yahoo! sessions usually stay active for a couple of hours so this assumption doesn't lower the probability much), it is possible for a rogue website to kick the user out of his or her Yahoo! IM session by embedding the following GET request into the HTML served up by the malicious page:
Yahoo Calendar. It is possible for malicious sites to add or delete arbitrary Yahoo! calendar entries. The following HTML on a malicious site will add a Task and Event to the victim's Yahoo! calendar. This can be abused by social engineers, phishers, and pranksters.

Demonstration. I have informed Yahoo! of these issues. I hope they fix them soon.