Posted by Jason Lam on March 12, 2010 – 10:56 pm
Improper Validation of Array Index (CWE-129) is a flaw related to improper use of user input. Most programming languages has support for array structure. Objects within the array can be indexed by numeric value such as [0] which points to the first object in the array or [5] which points to the 6th object in the array.
When a program allows user input directly or even indirectly to control the array index, there is a chance of array index going out of bound. For example
value = array[UserInput] //UserInput is a value put in by user
If UserInput value in the example isn’t checked first, it can easily be out of bound. What if the value isn’t a number at all? What if the number is a negative number? What if the number is bigger than the size of array?
The value of array index must be validated before use, [...] Continue Reading…
Last year, when we got going with our web honeypot, we quickly found that file PHP file inclusion vulnerabilities are by far the #1 exploit the honeypot was exposed to [1]. In part, this may have been due to us heavily emulating PHP applications. But many of the exploits didn’t match any of the installed applications and obviously got sent blindly. In another blog post, I recently summarized some of the attacks from our isc.sans.org weblogs, and again untargeted, “dumb” remote file inclusion came out ahead. The Top 25 list assigned CWE #98 the rank of 13 [2].
What is PHP file inclusion about? This is a flaw exploiting the unintended use of a particular dangerous PHP feature. A full fatured programing language, like PHP, typically provides a feature to include additional files. This feature is frequently used to include libraries, headers or other pieces of code common to multiple [...] Continue Reading…
Posted by Jason Lam on March 11, 2010 – 3:24 am
Buffer Access with Incorrect Length Value (CWE-805) is in close relationship with Classic buffer overflow (CWE-120). Class buffer overflow is caused by copying buffer without checking for length. Buffer Access with Incorrect Length when length is in consideration but the actual length defined is not sufficient. The end result of this vulnerability is buffer overflow.
The overall strategies to resolve this type of buffer overflow is no different than classic buffer overflow. Strongest defense is to avoid using languages that is vulnerable to buffer overflow, most new generation of languages are mostly immune to the buffer overflow problem. If language selection is not possible, look into safe libraries to replace the unsafe ones, which helps slightly.
Validation using a code scanning is also useful. Code scanner is a great tool for detecting buffer overflow problems, if you don’t get overwhelmed by the massive amount of true vulnerabilities and false positives, especially [...] Continue Reading…
Talking about hard coded credentials to other developers, one of the first questions to come up is “where else to keep them?”. A hard coded credential is usually a password used to obtain administrative access to software, or a password used by this same software to establish outbound connections, for example to connect to a database. Obviously, hard coded credentials (CWE 798) [1] are an important enough and common enough problem to warrant its inclusion as one of the top 25 software flaws.
So, back to the question: Where do you keep your credentials, if not in your code? In my opinion, credentials should be kept in a place that is hard to access for an attacker directly, but easy to access for an administrator to regularly change them. Leaving hard coded credentials littered throughout your file system does not help with either problem.
Finding an acceptable way to store credentials [...] Continue Reading…
In October 2001, the DShield.org site was just about a year old, I was alerted to a flood of reports hitting the site. Looking at the reports in more detail, I found out that most of them are due to blocked ICMP packets being reported to the site. Further investigation revealed that the reports where due to a new worm, later dubbed “Nimda” [1]. The Nimda worm was the latest exploitation of a path traversal in IIS. This particular path traversal was probably the highest impact instance of this basic coding flaw.
What had happened? Path traversal (CWE #22) [2] is a vulnerability allowing an attacker to specify a path outside of a restricted “safe” directory. Typically, this involves the use of “..” to move up in the directory tree outside of the intended location. Lets look at some example pseudo code to illustrate the issue. For example, we use [...] Continue Reading…
Posted by Frank Kim on March 5, 2010 – 5:23 pm
During a code review I came across code that looked like this:
// for testing only
String testId = request.getParameter(“secretId”);
if (testId != null && !testId.equals(“”))
id = testId;
else
id = codeToLookupTheRealId();
This code allows a malicious user to perform an access control bypass attack by simply supplying the “secretId” parameter in the request. As you can tell from the “for testing only” comment, this code was accidentally left in the system by a careless developer who created it for convenience purposes during testing. Normally, the value of the “id”, when properly looked up, prevents unauthorized access to data in other accounts. Here though, relying on untrusted data from the request allows the attacker to completely bypass the access control check. This is the essence of CWE-807 [1].
Historically PHP also suffered from the same issue. In the past, when enabled, PHP’s register_globals directive [2] set all GET, POST, Cookie, Server, [...] Continue Reading…
Posted by Frank Kim on March 4, 2010 – 6:49 pm
Foursquare is a mobile app that lets you “check in” to a location and tell your friends about it. If you check in someplace often enough you can, among other things, become the “mayor” of that location. If you’re the mayor you can even sometimes win free food [1]. Normally, people are supposed to actually visit the physical location to earn a mayorship or associated badges but Jim Bumgardner recently showed how he could, without physically visiting the location in question, become the mayor of various spots all over the world, including the North Pole [2,3,4].
In his case, he used Foursquare’s API to check himself in to various locations by using curl from the command line:
curl -u EMAIL:PASSWORD -d “vid=993842″ http://api.foursquare.com/v1/checkin
As you can see he actually authenticates to Foursquare using a valid email and password. But once authenticated, Foursquare doesn’t validate that you’re at the location itself. Granted, there [...] Continue Reading…
Posted by Jason Lam on March 3, 2010 – 11:02 pm
Cross Site Request Forgery (CWE-352) is one of the more common vulnerabilities in existent today. Although it is relatively common, not all instances of vulnerability provide sufficient incentive for an attacker to exploit the vulnerability.
The vulnerability is based on the fact that the web application assumes any request by the user is a legitimate request intended by the user. This assumption may sound logical but is not always correct. An attacker can craft a web page with a link to the vulnerable page, to the web page that is the victim, there is no indication that the user followed a link or instruction on another site to visit the victim page. When a user visit any web page, the browser automatically follow all the instructions like scripting or grabbing remote images from other sites. While the browser is following instruction, it might have triggered actions on another site without [...] Continue Reading…
Posted by Jason Lam on March 2, 2010 – 11:03 pm
Classic buffer overflow (CWE-120) is a huge problem in programming, we have all seen the damage that can be done by buffer overflow. There were numerous worms that leveraged this vulnerability in the early 2000’s. Starting from the Morris worm early on, extending to the Code Red and SQL Slammer, they are all proof that buffer overflow is serious.
Classic Buffer Overflow is caused by a simple principle – if you fill a cup with too much water, it will overflow. When a programmer copy an object from one place to another and the destination container isn’t big (or long) enough to hold the object, overflow will happen. Computer operations happens in memory, when the overflows happen, the overflowed content leaked into other parts of the memory. Coincidentally, the CPU takes instructions on what to execute from the memory as well, when there are overflow content in the memory space [...] Continue Reading…
Posted by Frank Kim on March 2, 2010 – 6:15 pm
It’s my pleasure to post this guest blog from my colleague and fellow security professional, Khash Kiani, about an interesting design flaw in Yahoo! Mail.
Intent
The ultimate goal of this exercise was to reveal a few fundamental design flaws with the authentication mechanism of Yahoo! Mail, more specifically its password reset scheme.
The exercise also intended to bring awareness to one of the most often used attack vectors of low-tech hacking: find a simple technical flaw in an application and exploit it via manual techniques. This case study illustrates how social engineers play with people’s trust and utilize basic techniques to gain information about individuals; information that would ultimately be leveraged to gain unauthorized access to Yahoo! Mail accounts.
Find the weak link.
The plan for this exercise was to use one of the most fundamental tactics of social engineering: obtaining information that is mostly considered harmless, but can be leveraged to [...] Continue Reading…
