%41%43%45%20%54%65%61%6d : security

HelloSecureWorld.com Launched

techjunkie — Fri, 01 Feb 2008 08:55:00 GMT

Discover the New HelloSecureWorld Security Resource

www.HelloSecureWorld.com provides a powerful experience for promoting security awareness and education in the developer community by surfacing existing content as well as new.

Well, If you like learning while having FUN then hellosecureworld.com is the resource for you. It brings non traditional ways to provide security awareness and education among the developer community - Virtual lab environment, hands on labs, tutorials, videos, play attack defender games and much more.

Happy Learning !!

- Anmol Malhotra

Some technical details on how XSSDetect does Dataflow Analysis

techjunkie — Wed, 24 Oct 2007 09:41:00 GMT

Hi, my name is Hassan Khan. I work for the ACE Engineering Team, which is a part of the ACE (Application Consulting & Engineering) Team. We develop tools and solutions to help secure Microsoft Line of Business applications, websites and also work with Microsoft’s enterprise customers. ACE Engineering is also responsible for developing and delivering security courses and workshops that were originally targeted at IT application teams at Microsoft and which we also now deliver externally. The XSSDetect tool, the Threat modeling and Analysis Tool and the Anti-XSS Library are some of the tools developed by ACE Engineering which have been made available for free on the Internet. As one of the developers of XSSDetect, I wanted to share some of the technical details of this tool in this blog entry.

There are two types of web application vulnerability scanners: dynamic and static. Dynamic analysis tools are also called penetration testing tools. You point such a tool at a live application; the tool begins crawling the web pages in the application and throws test strings at each of them. The effectiveness of a penetration testing tool is therefore dependent on its ability to go through all the use cases in the application. Most tools in the market, if not all, are not very good at it. Static analysis tools on the other hand scan the application source code or binaries to detect programming errors. Consequently, they offer 100% coverage and are able to identify many more vulnerabilities than penetration testing tools. XSSDetect is a static analysis tool.

The reason there are so few static analysis tools available is that they are complex and hard to implement. XSSDetect analyzes .NET Intermediate Language (IL) read directly from the compiled binaries. It takes apart all assemblies, modules, classes and methods down to each instruction. It then identifies statements where untrusted user data enters the application and where dangerous methods are called. These form the two sets of statements (sources and sinks) between which XSSDetect then finds dataflow paths. This is the same algorithm that is employed when an application is code reviewed manually by an experienced security analyst.

Even though XSSDetect comes with hardcoded sources and sinks that help identify only XSS vulnerabilities, this approach can be used to identify any vulnerability that can be expressed in terms of sources, sinks and the dataflow between them. These include SQL, LDAP, XPATH, and XML data Injection vulnerabilities. Once you have dataflow analysis capabilities, it can indeed be very powerful.

The example below shows data is traced from Request.Querystring to Response.Write to establish the fact that a XSS vulnerability exists in the application. It is a simple example here data is only assigned to a variable before being echoed. In reality, before user input is passed to dangerous functions, it can be passed around in different assemblies, methods and assigned to object fields. It can also be stored in a database before being used! All these challenges had to be overcome to make this tool more accurate. Additionally, XSSDetect had to identify encoding and sanitizing functions in dataflow paths to reduce the number of false positives.

I will continue to share more details on XSSDetect in the future. For now, feel free to share with us your experience of using this tool. If you come across any vulnerable code fragments which XSSDetect fails to detect, please let us know and we will try to improve the accuracy of this tool. You can contact the ACE team by going to the ACE Team blog and clicking on 'Email'.

To download the tool and see a screenshot, check out the ACE Team blog here:

http://blogs.msdn.com/ace_team/archive/2007/10/22/xssdetect-public-beta-now-available.aspx

First Line of Defense for Web Applications – Part 2

techjunkie — Tue, 23 Oct 2007 07:02:18 GMT

Hello everyone, as promised I am back with the next post on input validation series for web applications. Knowledge is power right :). So knowing what all things to validate when you start your web project can save you a lot of headache down the road. So here are some of most important aspects on input validation every developer should be aware of.

What should you validate?

All user controlled input should be treated malicious unless proven otherwise. There are three major categories you must validate to protect your web application.

1. Request object

This is the biggest and most important category of things to validate. When an HTTP request is made, the Request object retrieves all the values from the client browser. These are passed to the server. All of the following collections should be validated by the application on server side before consuming the information. Members of these collections are 100% user controlled.

Request.Cookies	The values of cookies sent in the HTTP request
Request.Form	The values of form elements in the HTTP request body
Request.QueryString	The values of variables in the HTTP query string

The members of Request.ServerVariables are not completely user controlled, but some items in this collection take user input. This collection retrieves the values of predetermined environment variables and request header information. These are the variables which take in some degree of user input, presenting potential vulnerabilities:

Request.ServerVariables

The values of predetermined environment variables

Request.ServerVariables

· HTTP_<HeaderName>

· SERVER_NAME

· URL

· REMOTE_ADDR

· REMOTE_HOST

· REMOTE_USER

For example, Request.ServerVariables ("HTTP_REFERER") is used many times by attackers for spoofing. Applications consuming this variable without validation may fall into a trap and process a malicious request that appears to originate from a trusted URL.

2. Registry entries

Many applications use the registry to store configuration and sensitive application data. Registry contents should always be treated as untrusted, user-modifiable data; the contents should always be validated before use. In fact, an application should perform input validation whenever data is being read or written to the registry.

3. Assemblies

Consider this simple scenario: One assembly, A, references and calls another assembly, B.

How can you ensure that, at run time, assembly A calls the original assembly B and not a malicious Trojan horse assembly named as “B” by an attacker? You need a way to verify the assemblies that are called within the application. The answer to this problem is “Strong Naming”. If you assign a public key to your assembly, it is considered "strongly named." Other assemblies that reference yours will use the “stronger” four-part name of your assembly. The strong name for assembly B would look like this:

<%@assembly name='B, Version=1.0.0.0, Culture=neutral,PublicKeyToken=2d7adc3047e7238d'%>

You should refer to assemblies using a "public key token," not the full public key. This token is like a thumbprint of the public key.

At load time, besides the normal signature checks designed to watch for unauthorized modification of the assembly's binaries, the loader will ensure that the public key in B.DLL matches the one recorded in A.DLL. This protects the links between the assemblies to ensure that B is B. An attacker now needs to discover the private key part of the RSA key pair that the original author used to sign the assemblies.

In the next post, I will talk about a very interesting way of exploiting a weakly coded web application and also we will explore different input validation strategies from a development perspective.

So stay tuned………

Cheers,
Anmol Malhotra
Security Consultant, ACE Services
http://blogs.msdn.com/anmolm

Weekend Security Reading Round up Links - 10/20/07

techjunkie — Sat, 20 Oct 2007 11:40:00 GMT

Inside the Matrix for Mobiles

A pretty interesting concept: hack together a platform for connecting the innards of over one hundred different types of cell phones and then connect them to servers allowing virtual access for testing purposes over the Internet.

Nigerian Space Program Isn't a 419 Scam

No, really.

Eric Traut talks (and demos) Windows 7 and MinWin

What do you guys think of the ASCII Windows Logo? Stay tuned for more... ASCII goodness!

Comcast Blocks Some Internet Traffic

The interesting thing is how they're doing it, and to what. Its not to all torrent traffic, they just don't want you to initially seed content or continue seeding after a download completes.

Online poker cheating blamed on employee

Well so that's a non-good way of proving your point ...eh?

Yahoo's "hackerwire" news coverage

ASP.NET ValidateRequest does not mitigate XSS completely

ACE Team's Eugene Siu has a brief post about why ValidateRequest isn't enough

Little Bobby Tables (from XKCD.com)

This is really hilarious... thanks to Spencer Low for forwarding it to me.

Mark's Blog - Mark Russinovich's blog is required reading. Its just amazing how he'll logically walk through common problems normal users just ignore or get frustrated by and finds the root cause of really common problems like freezing gadgets, files not copying or folders not compressing.

I've been reading Mark since High School when I used to pick up Windows NT Magazine, great stuff!

-techjunkie

First Line of Defense for Web Applications – Part 1

techjunkie — Sat, 13 Oct 2007 09:27:00 GMT

Hi folks, I am Anmol Malhotra and I work with ACE Services Team as a security consultant.

There are lots of security principles which one should be aware of while developing software but at the heart of any secure application, there should be a first line of defense – and the mother of all defenses is: Input Validation!

There is so much buzz around for how hackers hack and what offensive techniques do they use to break in, but at the core it is the mitigation strategy which matters to me and many of my customers. Lack of input validation is one of the _core_ vulnerabilities for almost all web attacks. If we can get this thing right, we can save lot of $(s) down the road. This series of blogs will talk in detail about Input validation strategies for web applications. We will also take a look at some interesting top Validation bloopers.

Let’s start with some basics today on Input validation.

Why Bother?

Would you let a stranger in your home? Probably not, unless he’s been thoroughly vetted and screened. But developers often let strange users inject data into their application without any sort of checking.

Sometimes developers assume no strangers will try to enter their house –they think that only their client software will communicate with their server software. This problem is not limited to thin web applications; in fact, it becomes even more severe in thick client designs. Wherever you give the user the ability to provide some input for processing, you also give him the ability to inject malicious data. Input validation is an application’s screening and vetting process that attempts to block as much malicious data as possible. For example, the application may limit input by length, type, or character. Without proper validation, malicious input will be processed by the application and can result in any number of security breaches.

Web applications designed today are heavily data driven and they exist because of a specific business need. Much of this data is provided by the users of the web application. Failure to validate this data in the application is asking for trouble. Consider an example of SQL injection attack, one of the key vulnerability required to achieve a successful SQL injection exploit is poor or no validation controls in the application.

Name any known web application attack and you will find that one of the core vulnerability is lack of input validation in the application itself. For example:

· Buffer overrun conditions

· Cross site scripting

· SQL injection

· XML injection

· LDAP injection

· Canonicalization issues

· Integer Overflow/Underflow

· Response Splitting

· Data Tampering

The list goes on and on. As it is clearly depicted from the list above many web application attacks exploit lack of input validation in the application. From an attackers prospective, this opens a huge door of opportunity to inject malicious data with the intent to make the application react in a way which is it is not supposed to be doing at all.

Cheers (stay tuned, more to come)

- Anmol Malhotra - http://blogs.msdn.com/anmolm

Weekend Security Reading Round up Links - 10/12/07

techjunkie — Sat, 13 Oct 2007 08:55:00 GMT

All about the data: IT security starts with a data-centric worldview

ACE Team's Roger A. Grimes has posted a great summary of the importance of having a data-centric way of looking at things for computer/information security to work in an IT environment.

1st CTP of the SQL Server 2005 Driver for PHP available

Bill Staples announced the imminent release of the October 2007 Community Technology Preview of the SQL Server 2005 Driver for PHP which is now available for download. This is an early CTP release and designed to gather feedback from the community to help refine the design of the API, the feature set, and the target scenarios.

Inside MSRC: Microsoft SharePoint flaw explained

Top Ten least-known features of Windows Server 2008

WinRS (Windows Remote Shell) looks very interesting. You can read more about it here:

First Look: WinRM & WinRS: Two new tools from Microosft that can drastically help server and workstation management

How to prove your Digital Identity

ACE Team's Anmol Malhotra has a short post on his blog about digital identities. Anmol's also contributed a great whitepaper on Input Validation for Application Security which we'll be syndicating on this blog very soon, thanks Anmol!

Securing the Gateway to Your Enterprise: Web Services

techjunkie — Sat, 13 Oct 2007 08:04:00 GMT

Eugene Siu, a Senior Security Consultant on the ACE Team has just published a great article summarizing some of the pitfalls and issues around web services security. You can read the whole article here.

-techjunkie

Weekend Security Reading Round up Links - 10/5/07

techjunkie — Fri, 05 Oct 2007 21:37:00 GMT

What's hot in Microsoft security: White lists; Blue hats

A discussion on Symantec’s proposal to whitelist everything on a Windows box as well as a summary of Microsoft’s Bluehat

10 Microsoft Security Links to Blow Your Mind

Pretty self explanatory, no? :)

More eyeballs for .Net Framework code

Our own Eugene Siu talks about Microsoft’s decision to open up the .NET framework for review by developers under a shared source license

ASP.NET File Upload: How to prevent network clogging

Varun from ACE has posted a great little post developers accepting file uploads should take a look at

ARCast.TV - Security Chat from Slovenia

Channel 9 has a great video conversation on security recorded in Slovenia earlier in the year but just now posted up

Silverlight Security Series

Shawn Farkas has a great series of posts on Silverlight security starting from part I, then going on to part II and finally, part III! And of course, the obligatory cheatsheet as well :)

Updated: Removed some of the HTML gunk, oops.

The difference between pentesting and an application development security process Part I

techjunkie — Fri, 05 Oct 2007 08:13:00 GMT

Many times when we’re speaking with a customer or reviewing material from security vendors, the inclination we’ve seen is to rely on penetration testing or code analysis/scanning tools and other solutions to make up for the fact that there is no comprehensive security process in place during development. Microsoft IT runs thousands of applications in our data centers and we’ve realized over the years that even if you spend large amounts of resources (both time and dollars) on penetration testing or automated scanning tools or other activities touted by some security vendors in a vacuum, you will never get the results you need. This is simply because you’re addressing a symptom and not the root cause of the issue. The root cause, of course, being that developers are writing code and deploying applications without following a standardized security process that enforces industry best practices when it comes to security code quality. What we’ve also learned is that developing and maintaining a solid application development security process is hard to do: it takes time, effort, support from senior leadership and a constant willingness to test assumptions and continuously improve what we’re doing. Cost is also a significant factor, something I intend to blog about in some more depth separately.

So what kind of security process do you need? It used to be that a lot of the security processes organizations developed and followed were based on their specific vertical or budgetary constraints, so for example the banking industry tended to do the same thing or the retail industry might do things in a certain way. What’s happened over the last several years however, and no doubt this has been significantly impacted by nearly everyone doing some kind of business online, is that processes, needs and requirements have started to merge. To a significant degree, it no longer makes any difference if you’re in banking or retail, you still need to protect consumer data from exposure just as much.

More to come in part II.

-techjunkie

Update

techjunkie — Sat, 15 Sep 2007 22:44:00 GMT

Thank you all for the tremendous response and support. I've gotten so many of your messages that I've not been able to respond to them all individually. We are working through some logistical issues but look forward to getting things going very soon. Please continue watching this space or subscribe!

Thanks,

techjunkie - 9/15/07

welcome to a different kind of blog from microsoft

techjunkie — Sun, 26 Aug 2007 09:31:00 GMT

Hello world.

Welcome to a new blog from Microsoft. The focus of this blog is likely to be a little different from most other blogs you'll see on blogs.msdn.com. Microsoft employs some of the best hackers in the world and actively recruits them and develops them. They work on all kinds of projects, whether it be in development, research, testing, management and of course security. Of course, there is controversy even in the word "hacker" but I don't think that should stop us from using it in the manner I think is the most appropriate. At his or her core, a true hacker is someone who is curious and wants to learn how systems work. This can and of course at Microsoft is done in an ethical, legal manner. We employ "white hat hackers" who spend their time pentesting and code reviewing applications and software looking for weaknesses and vulnerabilities so that others don't once we've released that code into the wild. We employ many many smart testers who know more about some of our software then perhaps the architects who designed it. We also employ some of the top researchers in their industry, dedicated people working on the bleeding edge of whats going to be common place in the next 5 or 10 years of computing. So yes, Microsoft does have hackers, and its time to introduce you to some of them and show you what it is, exactly that they do.

Generally most of the content you'll read and people you'll meet on this blog will be somehow related to security but not all by any stretch.

-techjunkie