Miscellaneous Security

Reading time: 3 – 4 minutes

BsidesSF was an amazing event, and I congratulate Mike Dahn for putting together an event that ran super smooth.

All of the presentations at BsidesSF were cutting edge and highly informational. There were two presentations, that in my opinion, clearly stood out.

Gunter Ollman – Your Computer is Worth 30 Cents

Gunter Ollman’s presentation explained how botnets and malware has changed the state of penetration tests.

Penetration tests are sometimes misunderstood and it is important to understand what a “real” penetration test is. Pen tests are supposed to replicate real attacks that an attacker would use to penetrate your network.

Gunter explains how these penetration tests have evolved over time:

In 2000, the easiest way to break into a network was to submit a job application, get the job, plug into the network, own it, and never show up the next day.

In 2005, the easiest way was to hand out USB drives in the parking lot that called home.

Now, the easiest way is to purchase machines inside of the corporation that already belong to a botnet.

I think this was a very eye opening presentation and although we have seen startup companies focused on  protecting your corporate assets from becoming part of these botnets, I think we will begin to see startup companies focused on removing your corporate assets from botnets.

Tim Keanini – Computing Risk without Numbers: A Semantic Approach to Risk Metrics

The other talk that was very ground-breaking was presented by Tim Keanini, CTO of Ncircle. TK presented on identifying risk through the use of semantic language. This is an alternative and interesting approach to risk management, that uses semantic language to rate the risk of assets to a network.

After the presentation most people explained they would need to watch TK’s presentation three or four times to extract all of the information out of it. I completely agree and am thankful that all of the presentations have been archived.

Reading time: 2 – 2 minutes

Photo: Brajeshwar

If you are a developer, I guarantee that you have written insecure code. Universities train people to write code, but very little time is taken to help them focus on writing secure code.

As with anything, being able to identify security vulnerabilities and writing code securely takes practice. But how does a developer, who is already overburdened with enough work, find the time or resources to help him identify security vulnerabilities?

This is where spot spotthevuln.com comes in.

The purpose of the project is two fold, help developers write better code by enabling them to identify insecure code and hopefully work the project into teaching curriculum’s at colleges and universities in order to help new developers write more secure code.

Here is how the site works. On Monday at 8:00am PST, a piece of vulnerable code is posted. An business week is given to people in order to attempt to identify the vulnerability in the code. On Friday at 8:00am PST, the code fix is shown with a description of what was wrong with the code. All of the vulnerabilities are taken out of open source projects in order to show developers “real-life” scenarios. The fixes are the fixes that were actually deployed.

The whole point of spotthevuln.com is to help developers identify poor development choices when programming. What are your thoughts? Do you think this will help developers? If you are an instructor and would like to work spotthevuln.com into your curriculum, I suggest for you to reach out to spotthevuln.com.

The more developers know about security, the better off we all are.

Reading time: 3 – 4 minutes

Photo: B.G. Lewandowski

Why did you just click that link? Most likely you have came to this site by clicking a link from another site. Why did you do that? Did you trust the person who sent you the link? Did you click a link from Twitter, Facebook, or an email someone sent you?

When you click a link, you are telling your browser, “I trust this person.” However, this is not the way we use the Internet. We click on links all the time. We click on links from “untrusted” sources. We click links from people we don’t know and we even click on URL’s that have been modified. On Twitter, a person is much more inclined to click the shortened link http://bit.ly/5hXRW then they are to click http://somewherebank.com/transfer.jsp?amount=1000&to_account=56777564. Even though the shortened link could redirect to the somwherebank.com site.

But, why would someone trick you into clicking a cleverly disguised link? The site that you are redirected to may seem harmless. It could also be extremely malicious.

What happens if this page, (the one you are currently viewing), was filled with Cross-Site Request Forgery (CSRF) links? This web page could be setup with all types of malicious intent. However, you didn’t know that when clicking the link. Now, it is too late.

If this site did have Cross-Site Requests, I could do things such as:

• Change the password on your Facebook account
• Transfer the money from your on-line bank account to another account
• Enact trades from a financial institution such as E*Trade

The sites that I exploit would have to be vulnerable to CSRF. But researchers, such as Mike Bailey and Russ McRee, are constantly finding CSRF vulnerabilities in web applications.

An example of how clicking links from untrusted sources is never good was demonstrated in Billy Rios and Nitesh Dhanjani, Bad Sushi talk. In their presentation they described sending phishers a word document stating their account numbers were inside. They sent this email to 25 known phishers. 10 of the phishers opened the word document and were presented with this. In addition, there was another link that said, “Actually, my account information is here.” 3 of the 10 clicked on that link. Even the phishers click links they shouldn’t.

What should be done? Who knows. It is human nature to trust people and we can’t get things done if every time someone sends us a link we open up a VMware image to view a link. So continue using the Internet the way you have been and remember, “These aren’t the droids your looking for.”