RaiderSec Meeting 05/08/2012

Hey everyone!

I would like to apologize again for having to cancel the meeting this past Tuesday. Unfortunately, a class exam overrode our room reservation. However, you can find the slides to the presentation over lockpicking here. If you ever have any questions regarding the subject, please feel free to let me know either through e-mail or in the comments below.

I'm really looking forward to continuing RaiderSec next semester, and hope to use this summer to publish substantial new and interesting content to the blog. Sometime next week, I will post a list of the different things I'd like to cover next semester, but tentatively my goal is to give more hands on examples, as well as take time to look at unique areas of security. Above all, I want for everyone to enjoy learning about areas of security that interest them. So, if there is a particular subject you would like to see covered next semester, or even a subject that you would like to cover yourself, let me know and we'll make it happen!

I've really enjoyed our meetings, and I hope everyone else has as well. If you're here over the summer and would like to get together to discuss things pertaining to RaiderSec, be sure to let me know! Otherwise, I look forward to seeing everyone next semester!

Have a great summer!

-Jordan

RaiderSec Meeting 04/17/2012

Hey everyone!

I just wanted to thank everyone who made it out to the meeting, and I hope you all enjoyed learning about Cross-Site Scripting (XSS) vulnerabilities and their exploitation. You can find the slides from the last meeting here.

As mentioned in the meeting, next Tuesday (April 24, 2012) Lance will be continuing the topic of input validation vulnerabilities in web applications by going in depth about SQL Injection vulnerabilities. The widespread prevalence and impact SQL Injection vulnerabilities can have will make this a very important and interesting topic.

I look forward to seeing everyone at the meeting!

RaiderSec Meeting 04/10/2012

Hey everyone!

I just want to thank everyone who made it out to the meeting yesterday! I hope everyone enjoyed learning about how social engineering attacks work, as well as why the human element of security is (and very likely always will be) the weakest link in a company's defenses.

As I mentioned in the meeting, next week we will begin covering web application vulnerabilities. Until then, feel free to read up on some of the vulnerabilities listed in OWASP's Top 10 Project Report to get an idea of the vulnerabilities we will be discussing in detail.

Also, you can find the slides for the social engineering presentation here. I look forward to seeing everyone at the next meeting!

-Jordan

Social Engineering - Exploiting the Human Element of Security

Introduction

"Hi, this is Rick from [Internet Service Provider]. We're seeing some unusual traffic from your location. It's most likely nothing to worry about, but we have a field tech on his way to diagnose the problem. Can you make sure he has access to the network to run some quick tests?"

At most, this phone call may take 3-5 minutes, and already the risk for the target being compromised is very high, especially if the individual on the other end of the line agrees to help the "field tech" (very likely the same person who called). This technique is one very specific example of "Social Engineering," and throughout this post, we will see how these techniques are often leveraged by attackers to exploit the human element of security for malicious gain.

RaiderSec Meeting 03/20/2012

Hey everyone!

I want to thank everyone who came to the meeting on Tuesday. I hope everyone enjoyed the introduction to memory corruption (specifically buffer overflow vulnerabilities), and next meeting we will cover how a buffer overflow vulnerability can be leveraged to by an attacker to execute code of his/her choice (our example being to create a shell on the system). As a reminder, our next meeting will be on Tuesday April 3rd, 2012.

Until then, you can find the slides from the last meeting here. I look forward to seeing everyone at the next meeting!

-Jordan

How to setup and configure snort for a Linux (Ubuntu spec.) System

Introduction

Note: This guide is not very stable, use at your own risk, do not go into this without some understanding of *nix, and the ability to solve problems and google and stuff. Also snort was not designed for wireless, this configuration will not work with wireless at all. There are hacky patches you could maybe apply to get snort to work with kismet or something (I didn't look too far into it) but honestly at that point it would much easier to choose a more light weight IDS

This is a post Jordan and myself had been talking about writing since the last meeting. Snort is a wonderful open source Intrusion Detection System (IDS) which is very effective as a first response system when your machine is being attacked, or as a line of defense in computer security related games like Capture the Flag (CTF)

I decided to set it up on my local machine for fun (since it's not very necessary on a machine not running services, but fun to have) as well as give me the ability to step through the process. I'm setting up the Snort IDS utilizing the postgres SQL database (because I already have it setup for metasploit interaction).

Introduction to Metasploit

The Need for Metasploit

As we saw in our first meeting, successful exploitation of a service requires three "parts":

• Vulnerability - A flaw in a system which can be utilized as an avenue of attack.
• Exploit - A program specifically designed to leverage a vulnerability.
• Payload - Code to be run on the system after the vulnerability has been exploited.

Usually, when a vulnerability is found in a service, an exploit is developed that directly contains a payload. For example, it is common that a shell may be produced from the exploited service. This means that when an exploit is used, the penetration tester would have no choice but to use the provided payload, unless he/she wanted to take the time necessary to create their own. This not only takes a substantial amount of time, but also quite a bit of skill. Also, one must consider that both exploits and payloads can be (and usually are) architecture specific, so a payload that works on a Windows machine will most likely not work on a Linux machine.

So, what security testers needed was a centralized framework to mix and match exploits with available payloads. Also, there was a strong need for a central repository of exploits and payloads that can be pre-loaded for quick use. This results in a flexible security testing environment, in which the desired results can be easily achieved.

Metasploit offers this functionality, and much, much more.