Let’s face it. There are a lot of broken web apps and software out there. These web apps and software can oftentimes lead to major security holes being opened up due to their vulnerabilities. You don’t want to be the guy/girl responsible for the next major security breach just because you forgot to sanitize some input, or check that your sessions were secure.

I would love to provide you a great tutorial on how to avoid many of the hardships that developers face, especially in security these days, but I don’t think I could do it better than the people over at the OWASP WebGoat project. It’s a web application that purposefully has many vulnerabilities right out in the open. The site is laid out with exercises for you to complete. It will offer hints, and even a full solution for when you get stuck. It even tracks your progress through a report-card like page showing how many times you’ve attempted an exercise, how many times you got help, and whether it was completed or not. You can grab WebGoat from OWASP.org directly and install it on your own tomcat server, or grab it in a fully enclosed environment through Dojo or OWASP Broken Web App VM. Either way you choose, I’d highly recommend either one. The VM’s provide much more on top of WebGoat but I feel the way the site is laid out and structured, it provides a very good tutorial-based approach to learning what not to do or at least learn what to avoid in your own applications.

Message Authentication Codes (MACs) are special pieces of data used to prove the authenticity and integrity of a message– to show that the message originated from a certain source and that it has not been modified. Consider a scenario in which Alice wants to send Bob an email. Upon receiving the email, Bob would like to be fairly certain that Alice was indeed the author and that the letter hasn’t been changed. When creating her email, Alice needs to have some technique that satisfies Bob’s concerns.

• First, she appends a secret word to the very end of the message. This secret word is only known by Alice and Bob.
• Next, she creates a unique “footprint” of her email by running it through a hash function (along with the secret appended at the end).
• Finally, she sends the original message (sans the secret word) to Bob. She also sends him the digest/hash/footprint.

When Bob gets the message:

• First he adds the secret word to the very end of the message (just like Alice did).
• Then he runs the message + secret through the exact same hash function that Alice did.
• Finally, he compares the resulting “footprint” with the one Alice sent him. If they match, the he can be confident that Alice sent it (since she’s the only other one who knows their secret) and that the message hasn’t been tampered with (since any change in the message would result in a different footprint).

This is almost identical to the way digital signatures work. However, MACs rely on a shared secret and, therefore, aren’t inherently based on public key theory. In addition, digital signatures are able to establish non-repudiation, which is not the case with MACs. In the above example, Bob could create an email from Alice to himself and Alice would not be able to prove she didn’t send it using just the MAC.

For this reason, MACs are most commonly used for inter-system communication. Webservers, specifically, make use of MACs to protect against cross-site request forgery (CSRF) attacks.

However, a common misconception with creating MACs is that any strong hash function alone is sufficient when creating an effective MAC. In reality, MAC-specific algorithms are designed to address some weakness with recklessly using block-level iterative hash functions (MD5, SHA, etc) concatenated to some shared secret. Specifically, the use of a Hash(message || secret) approach is susceptible to attack since someone could use information on known message/hash combinations to construct a new, working message/hash. By using a MAC-specific algorithm, such as HMAC or CMAC, these weaknesses can be mitigated or avoided altogether. So if you’re ever in a situation where you could benefit from a hastily-implemented MAC, be sure to consider both its strengths and weaknesses.

FIPS stands for Federal Information Processing Standards, and is “run” by NIST. It is a set of standards that dictates how information is stored, processed, and managed in the federal government. It’s also leaked into the commercial sector through government contractors and the concept of “If it’s good enough for the government…”

Almost all of the FIPS standards are relevant to security. Ever hear of FIPS 197? It’s AES. A list of all FIPS documents is available through NIST, and if you’ve worked in information security, you’ve likely heard of at least 3-4 of them. The one I hear most often is FIPS 140-2. This is the standard for cryptographic implementation. An entire industry has grown up among independent testing laboratories that test a specific cryptographic implementation for compliance. And to feed that – the government won’t accept a cryptographic implementation unless it’s been certified. NIST issues a “certificate” and everything.

The FIPS 140-2 testing is quite rigorous, and until now was generally accepted as an “all clear to use” signal. There are some implementation problems that have just cropped up, and until someone knows what happened – bad testing, different implementation, etc., we won’t know if the FIPS testing program is broken or if it was just a bad apple.

(probably) Everyone knows that firewalls are a “good thing” to have, but how many people actually know how they work?

Firewalls can have many features that I won’t go into here, but the basic way they work is that there’s a set of rules that someone sets up (or is given) and the firewall follows those rules. How it does this makes us remember our TCP/IP and UDP connection details.

A connection consists of two port/IP pairs – one for the source and one for the destination. A firewall looks at that information (among others) to determine if that packet is “OK” or not. If the packet is OK – based on the rules it’s been given, the “connection” is assigned an ID and the information added to a cache table. The cache table isn’t necessary, but it helps figure things out like “related” connections. It also helps with translation between IP addresses and ports if any NATting or DMZ ability is going on.

In addition to port/IP rules, a firewall can look at any field in the IP packet (and some look at anything in the layer 3 packet as well – including MAC addresses). So, a firewall can filter based on the type of packet it is (for example, not allowing ICMP packets – i.e. ping), what options are being used (like TCP flags), as well as content of the packet – although this is less common.

Firewalls can also alter any field in the IP packet, for example to support quality of service based on the port, or to change the IP address to support NAT.

What about this big cache table thing? Can it be “filled” like we can with ARP packets? Yes, it can, but as the cache is not *necessary* to the fundamental operations of the firewall, most will just not add things to the cache when new connections come in. It’ll imperceptibly slow things down since it has to run through the rules every time, but the firewall will still do its job.

The internet is full of unsavory characters who want to steal your personal information and/or money. This has been widely accepted for quite some time. Recently, some good articles have appeared online regarding what to do if you think you’re being scammed, especially by pop-up ads that look like anti-virus software (http://www.fbi.gov/pressrel/pressrel09/popup121109.htm, http://voices.washingtonpost.com/securityfix/2009/09/what_to_do_when_rogue_anti-vir.html).

While these articles focus on what to do if you’re hit with such an attack, I’d like to present a few rules of thumb that I use whenever I see any type of message that looks suspicious, whether it is from a pop-up ad, e-mail or letter that purports to be from my bank, or even an unexpected phone call from someone claiming to be from a company where I hold an account.

1. Am I being asked for personal details?
   If an incoming message of any type, be it e-mail, pop-up, or phone call, is asking you for personal information or, especially, passwords, then there is a near 0 chance that it is legitimate. Disregard the message immediately.
2. Does the message sender look familiar?
   If you receive a virus notification pop-up that looks like it came from Norton Anti-Virus, and you do not have that product installed on your computer, it’s probably not legitimate. Similarly, if you receive an e-mail from PNC bank and do not have an account there, you can assume the same thing.
3. Is the message informing you of an unexpected change?
   For example, if you receive an e-mail from a financial institution that their web site URL has changed, this is immediately suspect. This is a very rare occurrence, and when it does occur, you will usually be informed by postal mail in a message that conveys the sender’s authenticity. For example, a bank may send you a notice of change that requires no action on your part, and lists your name, address and account number on the letter. If the sender already has information like this, then there would be no need to scam you in the first place.
4. Was I expecting this message, or is the message benign?
   If you receive a message containing expected or benign information, such as a notification that your statement is available, there’s likely no reason to worry. Generally this sort of notification doesn’t even ask for any action on your part.
5. Does the message make you afraid?
   Generally, any unsolicited message that tries to scare you into performing an action you otherwise wouldn’t, such as entering credit card information or revealing a password, by threatening financial loss (in case of phishing) or data loss (in the case of false virus pop-ups), should not be trusted.

   For virus pop-ups, if you are afraid that you have malware installed, disconnect from the internet, shut down and restart your computer, and run a virus scan using anti-virus software that you installed. If you do not have anti-virus software there are plenty of available free options, such as Microsoft Security Essentials. The information in the links above is also quite helpful for this situation.

   For phishing e-mails, do not click on any links in the message. Instead, manually open a browser and navigate to your bank’s web site manually to log in. Alternatively, look up your local branch’s phone number in a phone book and call them during business hours. (Don’t trust any phone numbers listed in the e-mail, either!)

   For suspicious phone calls, do not reveal any information to the caller. Hang up the phone, and call your bank or credit card company using their public phone number and ask to speak to a representative to confirm what you were told.

This is by no means an exhaustive list. These are the top items in my mental checklist for validating unexpected messages I receive through any medium. When in doubt, do not trust the messenger – hang up the phone/close your browser/shut down the computer and verify what you’ve been told in a way that doesn’t rely on the information you’ve just been given.

Feel free to leave some of your own rules in the comments!

You may have heard about the latest SSL vulnerabilities over the last month, but how do they work and what does it mean to you (or your users)?

When I earlier described how SSL works, I glossed over two SSL functions: session resumption and re-negotiation. These two functions allow a client or server to renegotiate an SSL connection if they decide they want to use new keys. Session resumption allows the client to use a previous session ID, and have this happen faster – without renegotiating new keying material.

These optional protocols allow a man-in-the-middle (MITM) attack. The MITM gets authentication information from the client headers (through sniffing, DNS spoofing, etc.) and replays those to the server – asking for renegotiation. The server complies, and now the attacker is the “client” of the server, and the “server” to the client – using the previous client’s authentication information. All implementations have this particular problem.

There is also another attack that depends on the configuration of the server, but is part of the protocol as well. When the server allows different authentication for different paths and one path requires client authentication, a MITM can take advantage of this. The client makes a request, but since the server doesn’t know yet whether client authentication is required, it has to negotiate the connection without client authentication. Once the server determines that the request is for a path requiring client authentication, the server renegotiates the connection – and it uses the client’s original request (GET/POST/etc.) – meaning it can be replayed.

These attacks can allow someone to insert themselves between you and an SSL protected site – like your online bank – without either the client or server knowing. And that little lock on your web browser that says you’re connected to the correct site? Meaningless. This is bad. The good thing about these particular attacks is that the attacker has to have compromised your network (or the server’s) in order to get in the middle, but with recent DNS attacks, that’s no longer impossible.

Each Tuesday, Security Musings features a topic to help educate our readers about security. For more information about Gemini Security Solutions’ security education capabilities, contact us!

Last time in our web app input sanitation series, we looked at unsanitized input as part of an HTML tag or attribute. This entry focuses on sanitizing SQL queries.

Case 3: Sanitizing SQL Query Data

The basic SQL attack takes advantage of improper sanitation to execute its own queries against a database. This can lead to a database being compromised.

(more…)

A lot of computer security deals with risk – what are the risks of doing or not doing something? However, risk is not exclusive to computer security, and there are many papers and treatises on how to determine and how to manage risk – you’ll generally find papers on risk in management literature, most often project management. Project managers have to deal with risk all of the time – what if the weather is bad, what if a key employee quits on the project? There has to be a plan in place for these eventualities. The same is true in computer security.

(more…)

In Part 1 of our web app sanitation series, we looked at unsanitized user-controlled data inserted directly into the HTML response of a web page. This entry focuses on a more specific case: user-controlled data being used within a web app in areas like attributes of HTML tags.

(more…)

Nessus is a vulnerability scanner that has been around for a while and has a mottled history. It began as an open source scanner, and then Tenable Security took the source code and created a fork of nessus after version 2.0. The 2.0 source is still available, and OpenVAS has taken it and kept it open source.
(more…)