Sunday, December 5, 2010

Social Culture of Hackers



Hacking is seen as an underground group. They are very social in nature. No man is an island in the hacker or security community. Hackers share information very liberally. Sites spring up every day to share tools, techniques, news, and other information to fellow hackers and security professionals. Security professionals need to be embracing joining the hacker community not in order to use the techniques of crackers, but so the techniques are known and defenses can be developed.

A couple of well known hacker underground sites include:
Hackers Center Security: http://forums.hackerscenter.com/index.php, T
he Hacker Community:
http://www.hacker.org/,
The 2600:
http://www.2600.com/
Defcon: http://www.defcon.org/.
Most of the hacker community never meets face-to-face. They hang out on irc, chat sites, and IM.
The only time a person get together are at Defcon and Blackhat security conferences.

Mailing lists and RSS feeds are the lifeblood to the security professional. Within the mailing lists and RSS feeds information is delivered as soon as it is available. If you keep up with the research and
security holes within software packages then you are better able to defend against these weaknesses.

Its a fine line between a criminal cracker and a security professional. They both use the same tools and techniques to defend and attack a computer security system. They both run in the same hacker
community because they are both curious about technology and gadgets. The only way you can tell the difference is by their actions.


Hackers have big egos. They love to talk and in most instance they love to share their secrets. Hacking is not hard. You just have to know what you want to accomplish before you start the hack. You can go to forums and chat sites and discover all sorts of new techniques and procedures to hack.

Friday, December 3, 2010

Personal Information as a Security Vector

Personal information such as SSN, medical records, and academic records are as secure as the knowledge that the staff has gained in order to protect the information. The security team can be well trained in computer and physical security. They can be the expert in the field of cryptography and a firewall or security architect, but if the security team does not train and pass along some of their knowledge then it will not be long before the information that they are trying to protect will be owned by an evil cracker that knows how to get within the company and compromise the integrity of the data.

No matter how good a security policy is companies are always vulnerable to penetration from the outside or even from the inside. Just this past week the employees of my company was told that we could no longer bring USB devices or any other storage devices including personal laptops because one employee was caught bringing company information to his home. Although I was not informed of what information the employee was taking home or why, the fact is that he brought the information home. We used to have a program that was supposed to encrypt the drive and the drive would then only be useful only on the computer that encrypt the drive, so I’m not sure what happened with that security measure. The bad thing is my company deals with social security
numbers and medical information every day, so I know that system and procedure would not be HIPPIA compliant.

Also it would not be hard to gather the username and password of the employees at the company because most of the time the information is on their desk or you can just ask them and they will be happy to give you the information, and most of the time the users do not lock their desktops when they leave their desks. This provides instant access to every SSN in the country and the person that would get called out would be the user because SSA knows who accesses what SSN and when it is accessed.
Remember to go to the training classes when offered. If you don't then you may unknowingly give out personal information that you may not have the right to release.

Thursday, December 2, 2010

Part 2: Cross-Site Scripting (XSS)

Cross-site scripting (XSS) is one of the most common application-layer web attacks. XSS targets scripts which are executed on the web browser rather than on the server-side. Cross-site scripting causes applications to execute in the manner desired by the malicious user. A basic example of XSS is when a malicious user injects a script in a legitimate shopping site URL which in turn redirects a user to a fake but identical page. The page would run a script to capture the cookie of the user browsing the shopping site, and that cookie gets sent to the malicious user who now hijack the legitimate user's session.
As on-line business project cannot afford to lose the trust of its present and future customers simply because nobody has ever stepped forward to prove that their site is really vulnerable to XSS exploits. Exploited XSS is commonly used to achieve the following malicious results:
Identity theft
Accessing sensitive or restricted information
Gaining free access to otherwise paid for content
Spying on user's web browsing habits
Altering browser functionality
Public defamation of an individual or corporation
Web application defacement
Denial of Service attacks
Security flaws in high-profile web sites have allowed hackers to obtain credit card details and user information which allowed them to perform transactions in their name. The major cause of XSS is code validation within the application. A
lot of applications do not validate their input. They don't check to see if the code accepts non-malicious input.

Ways to Prevent Cross-Site Scripting Attacks
1.      Validate Code: Go through your code and test your code. Ask yourself, “If a person enters “code” in the textbox will the code execute.” The only way to discover this is to try to run “code” within the textbox. The most common code is SQL commands and JavaScript commands.
2.      Escaping: Escaping is using special characters as escape characters instead of actual characters such as <,>, &, !, etc.  
For more information on Cross-Site Scripting and other web application security check out OWASP.com at