So, you wanna social network?

Hey everyone, Merry Christmas! I'm off from grad school for the semester and need to study for my Master's comp exams in March but I'm doing some research in a few different areas and thought I would post a few thoughts.

I've been reading the book Hacking the Next Generation by Dhanjani, Rios and Hardin and that got me to thinking.... The authors explain in the chapter "Intelligence gathering" that in order to execute a successful attack against a target, the attacker must gain as much intelligence about the target as possible.

What are some of the ways the authors suggest to gather intelligence? The Internet of course. I used my former company as an example target. What if I was a disgruntled former employee bent on vengeance against either the company as a whole or just the former CIO? Both are ripe for the plucking.

1) Gathering information on company technical infrastructure - an attacker needs to know as much about the target's computer systems and infrastructure. One way to do this is to use a search engine and look for keywords such as the company's domain address. The reason I chose this was that, as a programmer, I am always searching forums and other source of information on problems that I may be having. So, I search for my former company's email address on Google.

I see some very interesting information. I come across some postings from software developers on the SpringSource developer forums. I know they are from my former company since the posters are using the company's email address in their profiles. From these postings I gather the team is using Spring framework for their MVC layer. If I wanted to attack some of the systems, I can find vulnerabilities in the Spring framework that I can utilize. I also see that one of the developers posted a URL of one of the development servers where others can test his theories. I can also use this URL as the attack target since it is accessible to the outside world. And since this was a development server, it is possible the perimeter defenses aren't as formidable as those on the production servers.

2) Using Google hacking as an intelligence source - Google is a well known vehicle for intelligence gathering. JohnnyIHackStuff has a great Google hacking database on his site. I first try a few searches using "filetype:doc companyname" as a start. Hello! in the first 10 hits I find the online resume of a former developer. The "Skills" and "Projects" section of this resume gives me some very critical information.

First of all, I see Websphere server experience. I now know that this company is using IBM's Websphere as a webserver. I make a note of this. In the experience section, I also see that this developer worked on a Single Sign On application for this company. If I can find a user id and password for the SSO application, it is possible that I can get access to many of the company's critical web applications. I also find it interesting the SSO is a homegrown SSO type of application. Very good news for me since commercial brand SSO's traditionally have had security holes. What kind of holes does a homegrown SSO have? Lot's, I'm sure.

The developer mentioned that he/she built a JAAS authentication model that users of the SSO use. The developer also put in that he/she built an developer SSO hack so developers can bypass SSO on developer machines. I wonder if the hack made it into production? Probably so. I also wonder if this developer (whom so nicely put contact information in the resume for me) is as disgruntled as I am? It may be worth a few beers to talk with this developer about his experience at the former company. Maybe $1000 would interest him for some details about his SSO experience?

That's it for now. It literally took me 15 minutes to get this amount of information.

Next up will be a post on intelligence gathering targeting the former CIO of this former company.

Mysterious testing tools revolving around Sans Top 25 error list

I missed this blurb on the SANS website earlier but while I was re-reading it caught my eye.

According to http://www.sans.org/top25errors/#s2 , "one of the leading software testing vendors is announcing that its software will be able to test for and report on the presence of a large fraction of the Top 25 Errors."

Mike Fratto from Information Week says here: http://www.informationweek.com/blog/main/archives/2009/01/cwesans_top_25.html that even if such tools exist, a programmer will not run them due to the complexity of running such tools.

I for one applaud any extra testing tools, as I mentioned in my first post. All they need to do to make it easier is to develop an Eclipse plug in that a developer could right click on and say "Run". Or build it into CodePro.

Top 25 Programming list Thoughts and Notes.

Welcome everyone from East Carolina and OWASP - NC! I am putting together something for a joint meeting between OWASP and ISSA in Raleigh that revolves around the recent SANS Top 25 Programming errors that came out in early January 2009 : http://www.sans.org/top25errors/.

SANS worked with the MITRE organization whose Common Weakness Enumeration (CWE) details over 700 additional programming and architecture errors and recommendations on how to avoid and mitigate them.

The main goal of the Top 25 list is to "Stop vulnerabilities at the source by educating programmers on how to eliminate all-too-common mistakes before software is even shipped. The list will be a tool for education and awareness that will help programmers to prevent the kinds of vulnerabilities that plague the software industry. Software consumers could use the same list to help them to ask for more secure software. Finally, software managers and CIOs can use the Top 25 list as a measuring stick of progress in their efforts to secure their software."

Here are some notes:

1. Programming errors in this list relate mostly to security

2. Could also be renamed to Top 25 Web Programming errors since many of the items on the list are not applicable to non web programmers. However at least all but 2 of the 25 relates to any software if not all of them.

• Web applications are starting to dominate mainstream computing.


• Web applications are accessible from anywhere in the world whereas desktop applications mostly require physical presence to interact.

3. How does this list compare, duplicate, enhance other similar type lists?

• Michael Howard’s “19 Deadly sins of software security” - 19 Deadly Sins of Software Security (Security One-off)
  


• Steve McConnell’s – Classic Development Process mistakes - http://www.stevemcconnell.com/rdenum.htm and accompanying case study - http://www.stevemcconnell.com/rdmistak.htm
  

4. Old software proverb: “The first 90 % of the work takes 10% of the time and the other 10% takes 90% of the time”.

• Security sadly is not at the forefront of development cycle and therefore is relegated to the last 10% of the time. Therefore, a lot of the times, security is not gotten around to implement.


• Succeeding in software is more of getting EVERYTHING right and less of not doing a few things wrong. One bug especially those found by the customer can fail a project.


• You can help your project success along the way by simply recognizing what errors you can make and that is where lists like these can help your project success rate.

5. Can these 25 items be reduced to 12?

• Improper Input Validation ... path , user input, download without integrity check
  
• Untrusted Source ... similar data validation, but checks on more "human" level, untrusted seach path
  
• Failure to Fullfil Constrains ... buffer overflow


• Improper Initialization or Relase of Resource .... unitialized data,


• Failure to Preserve Proper Structure ... encoding or escaping of textual data, SQL, html, control generation of code


• Client-Side Enforcement of Server Side Security


• Revealing Potentially Misused Infromation .... os calls in text file, cleartext transmission of sensitive data - hard coded passwords, error message information leak


• Giving Privilegies to Access Potentially Misused Information (& their executing)... data critical to keep valid state of program, external file names,


• Race Condition


• Incorrect Calculation


• Insufficent Random Values


• Use of Weak Cryptographic Algorightms

6. Or maybe the list can be boiled down into 3 categories?:

• Insecure Interaction Between Components (9 errors)


• Risky Resource Management (9 errors)


• Porous Defenses (7 errors)

7. A good idea for a hands on project would be to build a website that demonstrates a use and example for each error in the list for reference.

8. What is a “Race condition”? – a race condition is merely a synch issue where properly timed inputs and program execution can lead to unexpected state of the program.

9. Can a tool like Codepro be modified to check against this list? It would be much better to have a best practice of “I ran my code against this tool and it came back clean” rather than nothing at all.

10.Amazing thing is that people are noticing and reacting to this list where these issues have been around and noted for awhile.

11.Will some kind of regulations or government action result in this list? Think Sarbanes Oxley.

12.A lot of the items on the list are programming “errors” per se. They could be considered exploitable loopholes. The fact is that software will work fine in a world without hackers

13.Website with 25 errors categorized: http://naveedslote.blogspot.com/2009/01/top-25-most-dangerous-programming_13.html

More to come later - Fred