DevSummit07:Security Checkup for Nonprofit Software Developers

Facilitated by Jacob Appelbaum, Appelbaum Consulting

Nonprofit software development projects are almost by their nature resource-challenged. And when resources are constrained, security considerations all too often fall off the bottom of the "hard requirements" list.

Jacob will lead a highly interactive discussion on vulnerability patterns he sees in his work as a security auditor for various nonprofit and NGO software initiatives. The goal will be to tease out a reasonable-size checklist of security issues, with a particular focus on web applications that store member and other privacy-sensitive data. Jacob discuss straightforward steps to making applications more secure, and best practices for encrypting and protecting application data.

Session Minutes:

Security Session

Go-round - who's here, what security concerns do you have :

• x-site scripting
• scammers
• spam
• how to secure sensitive data
• how to work at a wireless cafe
• dealing with e-commerce
• server side application security
• desktop java applications
• human rights reporting application security

When implementing code

• how to deply - mod_security is a good way to deploy code you didn't write
• drupal - difficult to determine how secure since you didn't write it, could use an IDS - Intrusion Detection System which can monitor files, network, etc... used to protect from attacks, searches for strings

As an implementer or developer, you are the first line of defense - determine what you are trying to get from the user - make sane defaults

Example - credit card donation - any one that causes an error doesn't need to see the error, so suppress the error message (i.e. php level error), so use 'user error' - if they see the actual error, then an attacker can find database connection strings, etc.

You as the developer can control how errors are generated.

Get request - is a file, so you can tell from error messages if they are searching for ../../../ you can tell your application didn't create this

Example vulneralbe app - if you have to write to the database, don't have to pull also

Wordpress - is vulnerable. The more you have everything under one user, the more vulnerable it is. It's good to segment the application into different departments, so compartmentalize.

Block everything by default, only let in specific things .

Database example - one database user accesses both credit card information (submission section) and portal to submit content (forum)

Solution is to have either separate databses, seperate users.

If an attacker gains shell access - then different databases doesn't help, if they can run as the www user on the box, then they can get everything.

1 db user, php on apache - most problamatic, php is worrisome

Need to run IDS to find out if you are being compromised.

In california - if your credit card information is compromised, you have to report it.

Examples of IDS - trip wire - useful piece of software, open source and paid version, runs on most linux, unix flavors

Aide - http://sourceforge.net/projects/aide

- checksum, load, cpu, memory, easy to detect that it's there, and attacker can run code in memory, but not write to the filesystem, wait, sniff network, can find valid email, and can intercept aide message, learn how it is configured without touching aide config file, once you are in, can send the email yourself (as the attacker)

Samhain - http://www.la-samhna.de/samhain/

- like trip wire, can be hidden as a kernel module, can log to image files, it signs messages, so isn't vulnerable like aide, md5

Allows for emails to be verified (signature key)

Tripwire - http://www.tripwire.com/products/enterprise/ost/

- between samhaine and aide - runs all the time, centralized agents, problems are well known and attacker can see that it's there

Samhain - difficult to detect that it's there

It's rare that attacks don't write to the file system

Group of security researchers have a 'hate' for apple - apple threatened to sue researchers that discovered airport vulnerability - they spoke at torcon. They showed that Mac has much less security than previously thought.

January was the month of apple bugs. A new vulnerability every day, and some of them were realy good. (Search for MOAB, not on an OSX machine, and speakers down/off.) PHRACK, hacker group.

Month of php bugs - http://developers.slashdot.org/developers/07/02/20/0144218.shtml

- the problem is the php as team is failing in security, the person doing the month of php knows php better than anyone. There is not a lot that you can do, unless you really carefully design your constraints. March 1st. The bugs may be so complex that every version of php will be compromised. "php is an epidemic on the internet" "ruby on the other hand, everything's an object, how can you object"

Month of browser bugs

Bugtraq mailing list. A lot of web app bugs, php, ruby scripts with really obvious problems. Full Disclosure mailing list. Too much noise, unmoderated. MARC + Bugtraq, every mailing list sorted nicely

Defense in depth if you secure your applications outside of the realm of php, you will get so much more than anything else. Read your logs, learn what is supposed to be there. Log injection is also a problem.

tail -f 'ing logs is a terrible idea. Most apps don't suspect data, they just stuff it into logs. It ties up the app / detection so and creates a perfect opportunity for an attack. Logs need to be cleaned up the same way that data needs to be cleaned before it goes into the database. Cleaning logs: make sure that the log is getting what you expect, and you can throw a seperate error saying: "funky data detected but stripped".

Failing closed. When something happens make sure that important information doesn't exception catching. Catch the exception then stop processing. You know whats supposed to happen, and you check it, and if you can ensure that is the case,

Is there a paradigm of security testing? Know what you're trying to do. No assumtions you can't prove or check. Bugs are caused by assumptions.

Vloggies. Voting systems written on rails. Voting was all done through the url, and it changed the vote. What if the url was posted as an image tag on a high traffic website. Friendster allowed you to add/remove people as friends by allowing you to submit a get request and change data on the server. NEVER DO THIS.

A log in page will only stop people from doing very specific things.

Spam. Captcha is the short answer. The person submitting something to a form is a human, describe something in a picture. Dorkbot event, strange things with electricity. Captcha that uses pictures of grafiti. OCR or farms of humans doing it. In exchange for free porn, tell me what that captcha image is. Stasticical analysis to determine letters. Pwntcha Pwn?

http://sam.zoy.org/pwntcha/

Rating how good different Captchas are, show how captchas have been broken, and how they've been broken. Graffiti plugin for wordpress, done by someone at internet archive.

Tie the captcah to the login to the IP address. But that wouldn't help out in terms of farming. You have to look at it in terms of the attacker system.

Visual captchas discriminate against users with reduced sight. Alternate captchas such as audio. But the alternative captchas are very common ways to attack. There are other issues of cultural selection with different captchas.

Math Captchas. Computers are kind of good at that.

Human moderation can be very useful. But you need a community that is dedicated to using it.

The other thing is doing nothing.

Form moderation out to the porn farms.

Don't use an internet cafe unless you have an internet cafe. Connect to localhost instead. Port forwarding. You don't need a vpn. ssh -v -n -L local port number host remote port number -D 8000 dynamic tunnel, remote DNS queries. If this fails, the email will fail closed. Always forward port 25.

Web dev. Tor.eff.org is useful to have the outbound session encrypted. deniability between yo uand a site. The exit node is the problem. You can sniff it like a LAN. Hushmail. encrypted access to email

Use keys instead of passwords, there are ways to analyze the timing between each keystroke. You can have a script that launches

Good tutorial on how to setup an SSH tunnel on Linux:

http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/custom-guide/s1-openssh-client-config.html