Ohhh man, the headaches I could have inflicted by changing some simple settings, not to mention the potentially dangerous security breaches I could have caused to anyone accessing the Internet connected to this router either wired or wirelessly.  It’s good for them that I’m a WhiteHat. Some people just have no clue!!!

“In cryptography and computer security, Security through Obscurity (sometimes, Security by Obscurity) is a principle in security engineering, which attempts to use secrecy (of design, implementation, etc.) to provide security.  A system relying on security through obscurity may have theoretical or actual security vulnerabilities, but its owners or designers believe that the flaws are not known, and that attackers are unlikely to find them.”

In other words, STO is the attempt to strengthen security by adding in design complexity or making certain aspects of the system secret.  Here’s an example.  It is common practice for web-masters to modify the banner strings of their HTTP server.  The  banner tells the client which flavor and version of the Webserver that is running.  The Webserver flavor may be Apache, Lighttpd, or IIS, for example.  This information can be useful to an attacker and, therefore, it is recommended for banners to be silenced or even display incorrect information.  Now let’s take a look at this practice  of changing your banner on your Webserver. Does this make it less likely to be attacked?  Some folk might say yes, though everyone would agree that it doesn’t actually secure your Webserver in any way.  Perhaps an attacker is looking for a particularly vulnerable site and passes by yours since he can’t verify which Webserver and version you are running.  This is STO.  You obscured certain details of your system in an attempt to add in security; this is Security by Obscurity.

OK, now to the coding example I stumbled upon over at the iPhone Development blog.  Here is a snippet of code in the Objective-C programming language (the language used to create MAC and iPhone applications).

NSString *credentials = @"user:password";

In the line above the author defines an NSString Object called credentials that contains a user-name and password necessary for authentication at some other point in the program.  Now, once the program is compiled and ready to be deployed, the user-name/password text can be found fairly easily in the binary.  Here is how the author obscures this line of code:

NSString *credentials = [NSString stringWithFormat:@”%c%s%@%c%c%s%@”, ‘u’, “ser:”, @”pas”, ’s’, ‘w’, “ord”, @”@”];

In the above line,  the credentials NString has now obfuscated the user/password, which makes the user-name/password harder to find in the binary but not impossible.   A tenacious hacker with a lot of time on their hands  will figure it out eventually.  STO isn’t “real” security, but, depending upon your security requirements, STO might be all that is needed.  It certainly should not be confused with true information security.

How many of us actually backup our systems regularly?  Today, more than ever, in our ever-expanding digital world, having a proper backup solution is absolutely imperative!   We all have files we can’t afford to lose.  I was browsing through my vast library of photos I’ve taken over the years of the family, viewing precious pictures that cannot be replaced.  My wife, a freelance graphic designer, has a vast collection of files that she’s created throughout the years and files she’s been working on recently for various projects.  We also have financial data, music that we ripped and don’t have the CD’s, videos of our kids and other assorted types of files.  Apple recognized the need for a backup solution built into the OS and introduced Time Machine in OS X Leopard.  I upgraded our Mac to Leopard back in November of 2007 and have  been using Time Machine ever since.  Time Machine is an incredible solution for Mac users, and be ashamed if you’re running a Mac without Time Machine.  All you have to do is get an external hard drive, plug it in and Time Machine will ask you if you want to use this external drive as a Time Machine backup.  Click yes and your entire system starts backing up behind the scenes.  Apple made Time machine very easy to setup so it becomes a set-and-forget solution.  What’s really cool about Time Machine is that you can actually go back in time and retrieve previous versions of a file you were working on, or if you look in your documents folder and don’t see a file, you fire up Time Machine and view your documents folder back in time.  Then you will find the file that you accidentally deleted, click on it and put it back in your documents folder!  Check out the screen shot below:

A Time Machine backup  or a similar Windows type of external hard drive backup solution is just not enough.  We need the second part of the two-part solution.  Unfortunately, our PC’s are vulnerable to theft, natural disasters, floods and on and on, Heaven forbid.   That’s why a  good backup plan should also include off-site storage.  That’s where Jungle Disk comes in.  Amazon S3 (Simple Storage Service) is a service offered by Amazon.  It is also called “In The Cloud” storage, the “cloud” being out on the internet so the infrastructure is “cloud-like”.  Services such as these are becoming more and more popular.  Amazon S3 service is used primarily by businesses since it’s really wholesale storage and doesn’t offer any direct solutions for the home user.  Jungle disk is a nice program that you can download for just $20 and utilizes the Amazon S3 storage service.  You will need an Amazon S3 account where you provide a credit card so they can bill you monthly for the storage you use.  I’m using approximately 10 gigs of storage and I pay only $2 per month.  Pricing details can be found here. I use Jungle Disk as a worst-case-scenario, since you pay for the space, you may not want to put your entire hard-drive in the cloud. You can configure Jungle Disk to backup only certain folders and you can also include or exclude certain types of files. Let’s say your backing up a folder with mostly pictures you might want to just backup *.jpg files or exclude *.mov files. You can also schedule backups so they happen automatically say daily or weekly, whatever your needs require and what you feel comfortable with. For now, I chose a weekly backup of all our family’s pictures and all of my wife’s files, which total roughly 10 gigs.

When you run the Jungle Disk backup for the first time it will take a while, depending on your upload speeds, but subsequent backups will only upload files that you’ve changed or added. Some people will ask, how can I trust Amazon S3 with my files. The answer is you don’t have to trust anyone. Jungle Disk gives you the option to encrypt your data locally (on your PC) prior to uploading your files so that anything stored on Amazon S3 is “gobbely-gook” to anyone without your pass code.

When you purchace a Jungle Disk license you can run the software on all the computers in your home. Our Mac and Vista laptop have Jungle Disk running. Now that I’ve shared my backup plan that saved our bacon, I would love to hear others share what their backup plans are.

So what is Sandboxie? A while back we talked a little bit about a Virtual Machine and how I was able to run Windows on my Mac using Parallels. With Parallels you need to set aside memory and actually install the OS you want to run in the VM so that you essentially have two systems on one computer. Sandboxie is a “lightweight” VM that doesn’t actually need a separate OS to run; it runs as a program on Windows. Sandboxie allows you to run any program within a “contained environment”. Within that environment no permanent changes or modifications can be made to your system. So which programs do I run in Sandboxie? I have two programs that are the most likely vectors for something malicious getting into my system. These are my web-browser FireFox and my email client Thunderbird. I, therefore, ran these programs within Sandboxie before I wrote this post. They are running in their separate space and can’t harm my system. I’m a careful user of the Internet and follow some best practices, such as never downloading anything that is not reputable or clicking on a link in an email from someone I don’t know. However, even the most savvy user can be vulnerable; the bad guys are getting smarter and smarter. So what happens if I suspect I may have accidentally clicked on an unsavory link or downloaded a dangerous file? I wipe my sandbox clean and start fresh. Any malicious files or potential mal-ware is contained in the sandbox never able to harm any part of my system outside of the sandbox. How cool is that? Keep in mind that you must start using Sandboxie on a computer that is in a healthy state, otherwise Sandboxie is useless and all bets are off. Reformat your hard drive and install Windows fresh or start with a new computer.

This is all nice and I can see how Sandboxie can be a very useful tool for running programs in isolation but there are times were I would need my program to make changes to my system. Here’s a good example. I’m browsing on the web using FireFox “sandboxed” and then I go to the popular networking site, Facebook, where there is a picture of me posted by a friend that I would like to download, save and share with others. So I click “save picture” and I proceed to save it to My documents and here is the pop-up that appears from Sandboxie:

What’s happening here is that your “sandboxed” Firefox wants to save a file to your documents folder, which is outside the sandbox. If you click “close” the file will be saved - actually saved - in a directory tree under Sandbox C:\Sandbox\goodbin\DefaultBox where “DefaultBox” is your default sandbox (Sandboxie allows you to create different Sandboxes that behave differently for different uses). If you click on the recover box then you are giving Sandboxie permission to save this file to your Documents folder. If you clicked on close and save the file to your “sandboxed” documents folder then you can open your Windows Explorer in “sandboxed” mode and you’ll see the files. See the screen shot below with 2 different Windows Explorers; one in “sandboxed” mode shows [#] the files while the Windows Explorer not “sandboxed” does not show the files

When you download in Sandboxie, it writes all those new files and system modifications (unless you say it’s OK to save outside the sandbox) into the sandbox “C: location” or C:\Sandbox. Remember, nothing changed outside the sandboxed environment.  That means if you downloaded some changes to your “money management” program using Sandbox, you will see those changes only if you run your money program from Sandbox.  If you run it from it’s regular icon, no changes will have taken effect.  For the more technical users this can come in handy if you want to see how a program behaves when it runs on your system.  You run the program sandboxed and then go into the C:\Sandbox directory to see which system files where changed or which new ones were created.  Perhaps you are auditing a program or are curious to see what the change is so that you can feel safe about modifying your system files “unsandboxed”. See the screenshot below showing C:\Sandbox tree.  Notice the different program directories for Thunderbird and Mozilla.

So far, my experience with Sandboxie has been very positive. The interview on the Security Now podcast with the author of Sandboxie, Ronan Tzur from Israel, was very interesting. Sandboxie is a great addition to your security toolbox. Remember, there is no silver bullet security solution and depending on your level of paranoia is how often you clean out your sandbox.

So what is Clickjacking?   Clickjacking is an interesting exploit since it is not a bug or defect in the browser software, but rather,  a design flaw which will get clearer as we go on. Clickjacking, as it’s name alludes to, is about getting a user to click on something they didn’t intend to click on and are not even aware they are clicking on it.  This is accomplished by loading a web page that has a hidden page or multiple pages behind the web page you are actually seeing.  The way this is done is by placing a “click here” button that looks perfectly fine but “underneath” the button is where a malicious site would place something that might be harmful.  There is a great demo here on the topic of clickjacking where you can see the  hidden page behind the one with the buttons that say “click here”.  They say a picture is worth a thousand words - it’s one thing for me to explain it and another to actually see the hidden page appear.   

One of Robert and Jeremiah’s  examples to demonstrate Clickjacking used Adobe Flash player.  They showed how easy it was to have a user click on something benign that turned on your computers’ video camera (if you had one).  It is a real scary thing for a malicious site to be able to turn on your video camera without your knowledge!  Robert and Jeremiah postponed their talk and Adobe has since taken responsibility and fixed the Clickjacking issue only when Flash-player is the avenue of a Clickjacking attack.  Clickjacking is an issue for all browsers with or without Javascript enabled, since Clickjacking can be accomplished with CSS and DHTML alone.  This exploit, however,  must be viewed within the larger picture.  It isn’t a flaw or a browser software bug but, rather, a complex vulnerability that became real due to the way we’ve evolved with the Internet.   Our browsers have become  more and more complex, which creates an environment where sophisticated exploits can breed and grow and become a reality.  It turns out that the concept behind this exploit was documented as far back as 2002.  However, back in 2002 the internet was a much simpler place and the idea of clickjacking wasn’t much of a threat.  We live in a much different 2.0 Internet world now. 

• Understand the Potential Sources of Vulnerability
Many developers assume that all attacks will come from outside of a network firewall, but this leaves open a potential attack from inside. Make sure that all data is guarded from unauthorized access by several layers of security,ensuring that lower-level employees, and others who might work in the office,do not have access to valuable code data. Internal attacks can come in any forms, all of which can be avoided by working to secure all levels of the application.

• Utilize Multiple Layers of Security for Your Application.
Often times, IT professionals will rely solely upon an external firewall in order to protect a web application. In order to truly get a high level of security,however, one must cover all the bases. In practice, this means having an effective network virus scanner that operates in real time as well as a comprehensive network traffic tool to keep up with data movement across the network and potential breaches.

• Integrate Security Concerns Into Your Development Cycle
When planning out the stages of development,whether you work on an agile process or a standard model, you’ll need to consider the security implications of each part of your application. Starting from the earliest conversations about requirements and design all the way to the final testing phase,security concerns should be at the forefront of your thought process from the very beginning. In particular, security testing should be as important as usability testing.

• Be aware of the security implications of your coding conventions
Even simple coding conventions such as file locations can have large implications in terms of the security of a given file. While you attempt to create a stable code base by integrating standard practices such as basic password protection,make sure that you block all routes to sensitive files,not just standard ones.

• Test for major, known sources of hacking
While there will always be unknown vulnerabilities that will require major testing and upgrades, you should always protect against the well-know, major holes that often arise in web applications,In particular,design your application to withstand SQL injections, remote code calls, format string weaknesses as well as XSS (Cross Site Scripting.)

This post was written by Maya Richard, who primarily writes about high speed internet deals . She can be reached with feedback by combining her name and gmail.com

Application security is a big deal and that is why it is at the heart of the Payment Card Industry (PCI) security standards and requirements.

Requirement 6.6 became mandatory in June and requires the validated security of web-based applications. Requirement 6.6 requires organizations that process credit card transactions to address the security of web applications, either via manual or automated source code reviews or vulnerability scans, or via the installation of a web application firewall between a client and application. In the US alone, there are a huge amount of merchants that not must deal with application security, something many of them have never thought of until PCI made them wake up from their slumber.

There is a plethora of information available on the web regarding 6.6, so it is not necessary to fully repeat that here. But in a nutshell, the application code review requirement mandates organizations to meet this requirement 6.6 via an application code review or automated vulnerability scanning tool to identify application security issues.

The requirement to have a web application firewalls in front of web applications are to ensure that attacks can be blocked before credit card data is compromised. A web application firewall can also mitigate the risk of an insure application, in that it can detect and block attacks before an attack can occur.

Its been known for decades that the basis of nearly every software vulnerability is insecure or poorly written code. Yet for decades, application security has been ignored. PCI 6.6 is the long-awaited wake-up call for application security. Go get your kicks.

Ben Rothke is a security consultant and author of Computer Security: 20 Things Every Employee Should Know.

]]> http://www.itsecpackets.com/blog/2008/10/29/get-your-kicks-with-pci-66/feed/ http://www.itsecpackets.com/blog/2008/10/06/owasp-2008-and-fortify/ http://www.itsecpackets.com/blog/2008/10/06/owasp-2008-and-fortify/#comments Mon, 06 Oct 2008 13:26:17 +0000 Ron http://itsecpackets.com/blog/?p=59 I was fortunate to attend this year’s OWASP  Web Application Security conference in New York city.   It was a fantastic experience where  I networked with some really interesting and nice people, participated in intriguing talks about application security and was introduced to some security vendors who captured my attention.  I chatted with Jeremiah Grossman from Whitehat security.  Jeremiah has contributed greatly to the world of web application security and is well known in the community.  You can visit his blog here.  OWASP, which stands for Open Web Application Security Projects, is an outstanding organization whose mission is to educate organizations and individuals around the world about Web application security through various means including articles, methodologies and tools.  OWASP set an industry standard with their OWASP Top 10 Web application security vulnerabilities.  In a previous post I talked about WebGoat which is created and maintained by OWASP.   In that post I discussed SQL injection, which is one the of the OWASP top ten “vulns” (vulnerabilities).

Fortify was one of the vendors I met.  I had a nice talk with Erik about Fortify and the solutions they offer companies.  As it turns out, unbeknown to me, my company has an enterprise site license from Fortify.  The suite of products is called Fortify 360 and one of the features allows organizations to conduct static analysis of an application’s source code.  Later in the conference I met someone from my organization who also mentioned that we have a site license and told me how to go about getting the Fortify source code analyzer installed on my machine at work.  He also gave me a demo of the product.  I really appreciate his involvement in assisting me with Fortify.  Getting my security fix at work is a big milestone for me.

I wanted to share my initial experience with Fortify’s audit workbench (code scanning product).  My first code scan using this product was WebGoat application.  What better way to prove that a code analyzer is up to snuff than to use it on a web application replete with known vulnerabilities.  It turns out WebGoat is a demo application included with the Fortify product.  I pointed the Audit Workbench to the directory where the WebGoat source code resided on my PC and it started it’s thing.   Below is a screen shot as the scan is taking place:

Ok , here is the summary of issues that Fortify found after the scan completed.

Notice how the issues are broken down by Hot, Warning and Info.  The Hot issues are known vulnerabilities that are considered critical and can be exploited.  You can see the different classes in the left upper corner; Command Injection, Cross-Site Scripting etc.  We discussed SQL injection in the WebGoat application on a previous post so I thought it would be cool to show you what Fortify found for this class of vulnerablity.  I  drilled down into the SQL Injection section and whala! take a look at this!!

Remember that I wrote, “SQL injection vulnerabilities are remedied by sanitizing the user supplied input. “  Fortify found that exact problem in the code; sanitizing user  input was not occurring.  Just in case you can’t read it in the Details section,  it says, “On line 166 of Login.java, the method login_BACKUP() invokes a SQL query build using unvalidated input. This call could allow an attacker to modify the statement’s meaning or to execute  arbitrary SQL commands”.  Exactly what we demonstrated in the SQL Injection post was possible!

Here is another “Hot” issue that Fortify uncovered that I want to share.  Take a look at the  screen shot below:

This is more stupidity than an explicit vulnerability.  In the highlighted  line of code there is a Database connection being made and the username/password is hardcoded.   The reason why this isn’t smart is that usernames/passwords can change often and each time changed would necessitate a programming modification.   I know from experience as a Developer that where, applicable, one should always put config values like these username/passwords in config files.

So far, my experience with the Fortify product has been very positive.  I plan in the future to use the analyzer against my own code to ascertain the vulnerabilities in the code that I write.  As a developer, it is a challenge to meet deadlines and write securely by thinking like an attacker.  Fortify is a good tool to make this possible.

The test checked all the service ports 0 - 1055.  As you can see in the screenshot,  I recieved almost all blue boxes (representing ports)  with a few green and a “FAILED” rating.  What do the colors blue, green and red mean ?  OK, red means the port is open and listening for incoming connections and ready to serve, which, remember isn’t a bad thing necessarily, it’s only  bad if you aren’t aware of any services that should be running.  Blue means that the port is actually closed and no service is running on that port, which means that no connections can be made. That’s good.  Green is “stealth”, a term Steve Gibson coined.  A port is “stealthed” if, when probing the port  on the remote computer or router, there is no response at all. There  is complete silence on the wire.  There is  a debate in the TCP/IP Internet world regarding the notion of “stealth” vs. closed ports.  Steve felt that a TCP/IP port shouldn’t respond but rather drop the request completely.  In his opinion a “Stealthed” port is better than a closed port.  If a port responds that it is closed that, in itself, tells the remote machine that there was a system on the other end that exists and is “out there”.   If your system is completely “Stealthed” a hacker wouldn’t  even know if your system was actually connected to the Internet.  Steve feels that this added layer of privacy makes it more secure.  The “FAILED” message that I received is indicative to Gibson’s “True Stealth Analysis” which is why I recieved a failed rating from this tool. 

I did some further reading into the MAC firewall and was surprised to learn that the Leopard OS firewall is turned off by default.  Again, if you’re behind a Router (which I was before Cablevision),  there is no need for concern since the router is a firewall.  However, if you have a laptop and connect to the internet in potentially hostile environments it would be a wise thing to turn on your MAC firewall.  It is surprising that Apple, of all companies who toot their horns about security, would ship Leopard’s firewall off by default.  So, the analysis done in the screen shot above is  my MAC connected directly to the internet with no firewall running.  If there were any services running on my computer the ports would have displayed red for open.  Why the few green “Stealthed” ports?  Good question.  It turns out that these ports are actually shut down (”Stealthed”)  by my cable provider Cablevision and one of the ports is 80  - yup, I can’t run a Webserver on my MAC unless I use a router and go through some hoops to properly configure it.

Here is a screen shot of the ShieldsUp test performed on  my Ipod touch mobile browser after configuring my router.  Now, with a router in between the Internet and my the computers on my network I’m fully “Stealthed”.

Databases are typically used as the back end to web applications. SQL is a query language that is used to interact with the database. SQL Injection is a common web application “vulnerability” that allows an attacker to send data to the back end database. This “string” is then inserted into an SQL query within the application code and executed in the database. If an SQL injection vulnerability exists, then the application may be severely compromised. In some cases an SQL Injection flaw may even allow an attacker to bypass authentication schemes.  In the below WebGoat lesson the student, acting as the attacker, needs to craft some “string” that, when submitted as the “password”, allows access.

 In order to proceed with the hack we will need to alter the HTML or submit the form and intercept the request in order to modify the password field. We can alter the HTML file locally on our computer and then modify the HTML code. We will change the password field to type=’text’ in order for us to see what we type. We will also change the size of the input field (currently it’s only allows 8 characters). A quicker way I found to do this was to use an awesome “Plugin” to Firefox called Firebug that allowed me to modify the HTML on the fly. The other way to proceed with the hack would be to use a tool called WebScarab to manipulate the data passed back to the server. Notice in the screen shot below that you can now see what I typed in the password field instead of asterisks. Also, my password field now allows 30 characters. 

Here is the altered HTML in case you can’t see it :

<input type=”text” maxlength=”30” size=”30” name=”password”/>.

Why did the “password” I used admin or ‘1′=’1 allow me to logon and bypass the authentication? We need a little background first on basic authentication for websites. The “password” supplied by the user needs to be verified that. indeed, it is the correct password for this user and whoever is logging on is who they say they are. This is done by querying the database and passing the supplied “password” as a parameter to the query. Here is a simple SQL statement that might be constructed in a web application:

SELECT * FROM user_data WHERE password = ‘?’ and username=’admin’

If the query returns the record from the user_data table then we have a match on the user’s supplied password. If there is no match, then the authentication should fail and a message should be sent back to the user as “Login Failed”.

Now let’s substitute the “password” I supplied into the query:

SELECT * FROM user_data WHERE password = ‘admin’ or ‘1′=’1′ and username=’admin’

The or ‘1′ = ‘1′ makes the entire query true, which returns the user admin record and bypasses the logon scheme. With this crafty string we have successfully exploited the SQL injection vulnerability. SQL injection vulnerabilities are remedied by sanitizing the user supplied input. In the above example, if the server side code had some kind of logic to reject the single quote, our method of attack would have been foiled. In fact, there should be a series of validations for the characters that are white-listed versus those that are not allowed and in this way, an invalid character would be stripped out. The fundamental concept here is that only server side code can thwart attacks such as the SQL injection since, as we demonstrated, the client side code can be easily modified. That’s why it is essential that all input validation is performed on the server side. With some knowledge of these types of attacks and diligence at the development phase, SQL injection vulnerabilities can be avoided.