Tag Archives: #MiSec

Installing Kali and Metasploitable on VirtualBox

Have you ever wanted to be a 1337 hacker like you see in the movies? Metasploit automates some of the harder tasks related to penetration testing. This blog post is quick setup to install two virtual machines that will allow you to explore how to use Metasploit.

Step 1: Get files needed to create the VMs

Step 2: Setup Kali

Open VirtualBox, click File > Import Appliance. Choose the kali.ova file that you downloaded from the link above. Click continue to review the VM settings. Hit import, none of the settings should require changing. The import will take a few minutes to complete depending on your machine.

If the VM fails to start after import, read the details of the failure. If it’s related to USB emulation then change the settings. Open the VM settings by right clicking the VM. Click settings. Find the ports tab and click USB. Change the emulation from 2.0 to 1.1 and everything will be good to go.

The default credentials are u: root / p: toor to log in. To use Metasploit for the first time there’s some setup required. Using terminal, start a postgres database by running service postgressql start. Initalize the database by running msfdb init. Check Metasploit by running msfconsole.

Step 3: Setup Metasploitable2

We will need to create a linux machine and use the virtual hard drive from the .zip folder that was downloaded earlier. First step is to unzip the folder and find the Metasploitable.vmdk file.

Next go to VirtualBox and create a new 64bit ubuntu machine. Name it whatever you’ll remember. I used Metasploitable2. Click continue once everything looks correct.

Change the memory size to at least 512mb and click next. There select “Use existing hard drive” and select the .vmdk file we found earlier. Last step is to click create.

Start the box and confirm everything is working as expected. The default credentials are msfadmin/msfadmin. Type ifconfig to see what the boxes IP address is. This will come in handy when trying to scan for the machine from Kali. My machine is at 10.0.2.15.

Step 4: Double check networking

Metasploitable is one of those VMs that are intentionally vulnerable for you to attack. To ensure that no one else attacks your box, make sure it can’t access the internet by confirming in VirtualBox that the network type is set to NAT.

Host-Only would work if we weren’t using another VM to use Metasploit. This is still an option if you want to install Metasploit on your base host and skip the Kali install.

Step 5: Attack

Now play around with Metasploit! Get on Kali, ping the Metasploitable2 machine to make sure it’s in reach. Run msfconsole for a CLI interface or open armitage for a GUI. A lot of walkthroughs are online that can be a good place to start playing with Metasploit.

More info

For more information on how to use Metasploit, check out Offensive Security’s free course. Look for some articles such as the series from null-byte. Read a book about it, buy now from No Starch Press. My motive for posting this is a lightning talk I gave at #misec this month. The IntroToMSF slides are hosted here for those who are interested.

Converge 2017

May 11-12th was the Converge conference. If you’re in Michigan and are curious about information security, then I suggest you look at attending next year. For those that missed this year, Irongeek recorded all the talks and posted them online for you! Watch some of the talks and then put an alert on your phone to buy tickets for next year.

Converge is a great conference. I’ll admit I’m partial because it’s in my backyard. However that isn’t the only reason I like it. The talks cover great content, the speakers are friendly, and it’s not so big that guests feel like they’re lost in a see of other attendees.

Volunteering

On Thursday, I spent the morning volunteering with Irongeek recording talks for track 2. Helping with A/V is great because I get to volunteer and watch talks with a front row seat. In the afternoon I networked with people in the halls, after all that’s the most important part of a conference, right?

Friday was a lot of fun. I started off by playing with a new toy. A nexus phone loaded with Kali NetHunter. I’m still exploring the tools on it but one of them is called the Mana wireless toolkit that allows me to broadcast a wireless network. This makes for excellent trolling, especially for those who get the inside joke.. There was some evidence at GrrCON a few years ago.

I know at least one person noticed because they had a screenshot for me to share!

Learning how to pen test

The rest of the day, I was in training for web application pen testing. Kevin Johnson from SecureIdeas offered a 1 day version of his week long training course. We went over a lot of great topics, like his recommended methodology and the tools that pen testers can use.

While the training was amazing, it’s still something that Kevin offers others, so I don’t want to spill too many secrets. I do suggest that if you’re interested that you take a look at his site, secretideas.com.

I’ve said it before on these blog posts and I’ll say it again. Conferences are a great center for networking, learning, and growing if you’re looking at getting into the information security industry. Hopefully my stories from this year’s Converge has convinced you to attend the next conference in your area!

Building a community

At the #misec meeting I attended in mid April there was a panel on building a infosec community… so I’m borrowing their title for a post and giving my two cents in order to spread the topic!

I won’t give a huge synopsis of who said what like I did in my last post about a #misec panel. Instead, please watch #misec’s video on youtube if you’re interested in what was shared.

Community?

There were two general categories of discussion at the panel; meetups like #misec or BurbSec, and conferences like Converge or Thotcon. Your community is probably a collection of both. For instance, #misec was born from Bsides Detroit members who wanted more and created monthly meetings to have a smaller (more frequent) version of a Bsides conference. Two aspects are required to start or build a community; networking and attendance.

In order to have a community, people need to attend and contribute. In order for people to know where to show up, there needs to be some kind of networking and outreach. “Grabbing people” is a good way to start a meetup. Find people at a conference, ask around, and tweet to see what the interest is. Welcome everyone and follow up with people and the rest will fall into place. A conference works in the same way as there is a dependency on people. Volunteering, speaking, and attending is the core of networking.

Why me?

Meeting people and networking is a two way street. You get chances to volunteer at conferences, speak out about your interests and get feedback from others in the industry, and there are usually job offers and professional networking involved as well. Even if you’re an introvert and it’s stressful, making a name for yourself and showing people what you’re made of is huge in this industry and there’s a lot of great connections to be made through these communities.

Be involved. It keeps you busy. There are many ways to grow, whether through volunteering at a conference or stumbling through your first talk at a meeting. Being able to inspire others and help them grow is also an awesome part of being in a infosec community. A community is nothing without people, and you are one of those people.

Summary

To keep it short and sweet, try to use the following checklist:

  1. Go to conferences
    • Volunteer if it’s too expensive
    • Volunteer if it’s local and you want to contribute
    • Respond to the CFP or call for papers if you have something fun to share
  2. Join twitter and ask for help
  3. Find the closest city meeting and go
    • Start your own if the closest isn’t close enough
  4. Wash, rinse, and repeat

2016 in review

2016 has been a crazy year, and I’m not talking about celebrities, politics or world news. A lot of security related things have happened for me personally. I wanted to base this post chronologically on what I’ve done.

One of the first screenshots from 2016 is a constant reminder for me. What’s the first rule of infosec? Troll first, work later. I’ve come to realize that Twitter is the diving platform everyone needs. Twitter allows us to get lost in the world of meme’s, jokes, and sometimes useful rant’s from infosec’s favorite rockstars.

We had fun hacking Queen lyrics

Bsides Indy

Bsides Indy was a lot of fun. I got to meet some great people and attempted a CTF. Even if the CTF bombed hard, the team I was on had fun trying to attempt to play. The takeaway that I remembered most is networking. I met a lot of people I had only seen mentioned on Twitter feeds before. I took some of the stuff I learned at Bsides and messed around at Spartan Hacker’s SpartaHack hackathon.

For most of the conferences I’ve been to, I’ll say networking is the most important. The people I meet, the conversations we have, and the advice I get are invaluable to me. Networking is the main reason to continue to attending conferences.

Circle City Con

This conference was my first attempt at volunteering for a security team. Circle City was good experience. I learned a lot while on the job and met some great people. However at the same time, it was at this conference I learned that it’s not always best to volunteer for every shift you can make. After Circle City, I started shifting from a “ALL THE SHIFTS!” mindset to “I’ll fill a shift or two”. Circle City is a fun conference and a lot of stuff happens, I’ll be happy to get to go next year without being “on the job” for the entire conference.

My wall of badges after circle city con

Over the wire

Jayson from CBI introduced me to the Over the Wire challenges this year as well. It’s great training and proof that basic linux commands is all you need to be a 1337 H4CK3R. I learned a lot and that information helps me to gain a competitive edge in CTFs and during ethical hacking exercises at work. So far I’ve tackled Bandit with Jayson and friends, and also Leviathan by myself. Check out those posts if you want to know more about Over the Wire.

Converge Detroit

Pokemon Go was proof I was there!

The conference that started MiSec. I was happy to volunteer at this conference in our own backyard. There was a lot of great talks, I got to network with a lot of my favorite people and help out with Hak4Kidz all day Saturday.

 

 

 

I was lucky to get to play Jayon’s CTF-NG. Jayson has done an amazing job creating a new style of CTF. It’s far above any other CTF I’ve attempted. The point of the game is to get cards and use them to beat other players. Cards are distributed across customized VMs inside the game’s network. I was able to get into a few machines and find some annoyance cards. Not bad for my first attempt at the game. Since playing I’ve learned there’s a lot of networking and basic linux commands that I need to master.

At least I can prove I was really annoying!

Since my first attempt at Jayson’s CTF, I’ve had a few more chances to redeem myself. I’ve had a couple helpful hints. There’s been improvement in my network analysis and tool usage. In the latest attempt, I was able to find a legendary card.

School’s out for summer!

In May I graduated from MSU with a major in Media and information and a minor in Computer Science. I continue to learn what I can about information security, but I’m hesitant to sign up for more another degree. At the same time I moved from an internship to a full time position at Vertafore where I get to work with application security and vulnerability management.

Misec Panel – Path to the dark side

MiSec had a really cool panel in May where some experienced infosec professionals shared their journey of getting to where they are today. There was a lot of great tips and live tweeting so check out the post I did to follow up on that.

TLS research & talks

One of the first projects I did while working full time at Vertafore was researching TLS. The goal was to find how it worked, why it was required and what standards are the most important to secure connections. I drafted some standards, locked down this website by using Let’s Encrypt, and gave a lightning talk at MiSec Jackson about some of my research.

Hacker Summer Camp

Hackers and DefCon go together like PB&J. Add BsidesLV, guns, and black hat parties and there’s a whole week of fun, training, and more in Vegas. I met so many people while volunteering, standing in lines for talks, or visiting work shops. Hacker summer camp was a great experience and I’m pumped for 2017. DefCon 25 is going to be huge, being the 25th anniversary of the original DefCon means they’re going all out. A new location, more villages and workshops, there’s going to be something for everyone. I hope to see you there!

Defcon Smiley

HPKP research

The next research project I worked on at work that I also brought over into my personal websites was enabling Public Key Pinning. It’s a header that compares the TLS certificate to a pin that client’s browsers saves after the first visit to a website. I wrote a post about it and if you frequently visit this blog, you may have had a issue when my TLS certificate expired and I failed to correctly renew it. A few readers were blocked from seeing the blog because the HPKP pins didn’t match. I’m just happy I learned this lesson (and what’s required to fix it) on my personal websites and not while one of work’s applications!

I’ve done a little more for work that was based in application authentication. Specifically, I looked at 2FA, salted hashes, and other factors that goes into a securing login process. There’s blog posts on that research but those posts haven’t moved from drafts to something publishable. There will be a few time traveling posts appearing in 2016 next year.

Misec Lansing

September 14th was the first meeting of a new chapter of MiSec. Tek Systems hosted the first meeting in Lansing for MiSec and we have since moved on campus so students have a better chance of attending. It’d be great to have students and infosec professionals working together to improve the community.

Kyle and I had the idea to start another location. Since Kyle organizes the Jackson meetings, I’m the coordinator for the Lansing chapter. I get to be the guy that finds speakers for each month and organizes other events in the area. If anyone wants to give a talk or is interested in another event for MiSec Lansing, please reach out to me about it.

Other MiSec projects I contributed to this year is the MiSec slack channel and the wordpress redesign for the website. If you want to join us on slack, there’s an invite app that just requires an email. The wordpress redesign is something @taco_pirate and I worked on.

GrrCon

GrrCon 2015 was one of the jumping points of my security career. I can’t believe it’s already been a year since then. Going back to GrrCon, (having my employer pay for it), was really different this year. I wasn’t working behind the scenes but the organizers and team leads remembered me from last year. I played hacker Jeopardy (and somehow survived the aftermath), I was able to attend talks and still got a chance to network.

My journey into infosec is still just beginning and I’m excited to see where it goes from here! I plan on attending more conferences, be active in the community and continue to learn as much as I can. I hope you’ll join me!

Setting up Slack for MiSec

Some time last year, I wrote a post about setting up an IRC client on my VM. The idea was that since it’s always online, I’d always have the chat history for the #misec IRC channel. That way I’d never miss a mention or interesting conversation.

Since then, a lot has changed and I don’t connect to that machine as much as I used to.  I had to restart it a few times so the “always online” theory quickly fizzled out as well. I found that a majority of my MiSec conversations were on twitter or in person.

Why Slack?

At the RuCTF, we used misecredteam.slack.com to transfer notes and share files. For those that don’t know about Slack, it’s a modern chat client. While it may be just another messaging app to some people. I’ve used it through college, at work, and for groups like MiSec and lansing.codes. There’s been talk about trying to get an official MiSec slack channel.

During the November Lansing social, we did just that and misecgroup.slack.com was created. Later that night I found a project on Github that had a “push button” solution for creating a auto-invite application on heroku.com. Shortly after setting that up, I was able to tweet out the URL and people starting joining the new channel. If you’d like to set up a similar invitation application, then read the Github description and press either the Heroku or Azure deploy buttons based on what service you want to use to deploy the application.

How it works

The app works great. Heroku even took care of a lot of the hosting details, like handling TLS. Within a day, the channel had 30 members and I didn’t have to manually invite anyone. The only change I made to the app was cosmetic. I didn’t like the gradient background so I replaced it with a more “cyber” background. In order to change the application, I had to fork the github repository and connect it to my Heroku app. I used git and the Heroku CLI to do the heavy lifting. To change the background I simply replaced the bg.jpg in the images directory and redeployed the app.

IRC or death

A lot of MiSec members prefer to stay on IRC. In an attempt to accommodate their preferences, I opened an IRC gateway to connect to the channel from their favorite IRC client. However that still requires to be on the #misec IRC channel and the irc channel for MiSec slack… The only thing more annoying than having to be in multiple chats is being in multiple chats for the same reason.

So I found an alternative with the help of some MiSec friends. Another Github project called slack-irc.  The bot uses nodeJS to run, so hopefully anyone attempting this themselves have some experience with npm. Slack-irc made it possible to set up a slack bot that integrates with another IRC channel. So now #misec is in misec.slack.com’s #general channel and vice versa.

Demo from GitHub, show's how it looks for each client.
Demo from GitHub, show’s how it looks for each client.

Becoming a Slacker

If you’re interested in joining the MiSec slack channel, follow the steps below:

  1. Get an invite by going to misec.herokuapp.com and entering your email address you’d like to use for the account
  2. Finish creating an account for the channel
    (Please note the team URL is misec.slack.com)
  3. Sign in from a Slack application on whatever device you prefer if you don’t want to use the web client.
  4. Optional: Go to https://misec.slack.com/account/gateways for instructions on connecting over IRC

Path to the dark side

On Saturday, May 21st. The first career panel in #Misec history was held. Put on by the brave @chaoticflaws, @vajkat, and @ZenM0de, it was highly successful. The panel included @jwgoerlich, @jeremynielson, @jim_beechy, @D0Xt0rZ3r0, and a infosec recruiter from @TEKsystems (Sorry, I didn’t find his handle). It was five glorious hours of Q/A related to getting a head start in infosec and what really matters in the field. Here’s a recap of what was discussed from the panel.

Disclaimer:
Please realize that whatever I was able to scribble down does not include everything that was said. To help me try to get “the important points” I “borrowed” a few tweets from our panelists and avid listeners from the crowd (cough, cough, @TeaPartyTechie). A lot of my quoted references are paraphrased and are my adaptations of their wise words. I grabbed the tweets after the event so they’re out of order, but I tried to make it as chronological as possible. Feel free to take it with a grain of salt. Also if you’re one of the panelists and don’t like something you read, please let me know and I’ll work with you to fix it!

Screen Shot 2016-05-21 at 4.31.34 PM

Rule #1:
The golden rule was mentioned in the first question of the panel, and it was was don’t be a dick. Whether you’re talking about security exercises inside your company, hacking someone, talking to other infosec people, mentoring people… “Don’t be a d1ck” can be applied to thousands of situations. In #Misec especially, we are all here to help each other, so play nice. It can get dirty, but it’s all in good fun.

Trololol

While we aren’t dicks, we do love our trolls. The first open question to start the panel was about trolling employees. How do you handle security exercises like leaving bad usb drives, phishing, and more at your job? There’s a lot of ways to run these exercises. The point is to improve the culture to increase security and not to get someone in trouble. If you’re going to troll your coworkers, do it because you want them to be safe not because you want them to get fired.

If you’re doing anything for a company, track the results. The numbers at the end of the exercise are what’s going to prove to the higher-ups that the trolls; while “mean”; were worth it.

When you’re looking for an infosec job, a degree isn’t the most important thing. Some companies will demand the traditional Computer Science degree, others are willing to see what you bring to an interview. The important part is that you can explain your position and why you should get the job using a thoughtful story. Tell an interviewer why you belong.

If you’re looking at people in the industry, and they give you advice on what to do, follow it. If you take action on what they suggest, you’ll be 1 out of 10 people who talked to that person that did something with that information -wolf.

You want to continue to grow even after your finish school or get a job. I’ve said the following in at least three other blog posts, but you really need to find a community. Once I found Misec, my infosec network literally exploded. Networking was repeatedly brought up throughout the panel. I starred it in my notes three times. It’s important to reach out to as many people as you can so you can surround yourself with successful people that have been in the same boat.

Try to find a mentor. Someone who isn’t at your current company, but someone who has done what you want to do. They’ll be able to guide you in the right direction and make sure you do need to in order to get you where you want to go. A mentor is someone who you can bounce ideas off of and will navigate you down the best path possible. Have goals and share them with your mentor.

Screen Shot 2016-05-21 at 4.32.20 PM

There was a lot of discussion around how to become an expert. Really there’s only one way to become an expert and that’s practice, practice, practice. You’ll never be perfect and there’s probably someone more knowledgable, but you can always improve.

Being a leader

There will come a time, after you’ve found your niche in the infosec world when you are more knowledgable then most. No one is going to walk up and say “Congratulations, here’s your expertise certification”. If you feel you’re an expert, then say so. Just be prepared for what that entitles, interviewers will ask you the tougher questions, people will come to you for help, and there will be higher expectations. Only you can decided when you’re ready for that kind of title.

Screen Shot 2016-05-21 at 4.31.06 PMIn regards to “technical know-how VS social, economical, political know-how”. It was pretty well decided that it was important to be technical but still be aware of your surroundings. Keep up to date on the practices related to your field. Know the products involved and the processes in place and what might be coming in the future.

Screen Shot 2016-05-21 at 4.32.46 PM

The first 90 days on the job can be the most important. A few tips were given by the panel. Wolf said to focus on competence, perception, relationships, and getting results. That’s where the Red Baron reference was applied. Jeremy mentioned doing anything and everything that was asked or offered. Even if you’re a just an admin, help out to unpack the new machines. Jim said that for the first few years, get experience, you don’t have to narrow it down as soon as you get a job. Just get some knowledge first. The idea here is to be productive, work hard to get where you want to be.

A good thing that was pointed out here during a follow up question is that everyone fails. From the interns to the rock stars. Good guys will own up to their mistakes and try to fix them. Others will try to hide them.

Screen Shot 2016-05-21 at 4.30.12 PM
Contribute back, a lot of people new to the community will think “I’m not experienced enough” or “I’m just a student” or something similar to that. I can tell you first hand just how valuable it is to contribute as a noob. I write these blog posts as I learn, so I can look back and  see how far I’ve come and so that you can learn as well. I give talks about the research I’ve done for classes or as an intern and I plan on giving a talk about what I do as a full time employee. Well, mostly what I do, (just come to the talk and find out). Get involved and give a talk, even if it’s a recap of one of your classes. You don’t have to be “all knowing” to give back. Hey, at the very least, you should start a security blog of your own 😉

 

 

Screen Shot 2016-05-21 at 4.29.54 PM

Just another reason to contribute. You’ll become more of an expert by being involved. Give back to the community, volunteer at cons, network, give talks, go to panels. I can’t stress it enough how many times this was mentioned and how invaluable it really is.

Another option to give back is to mentor. Even if you’re not the #1 person in the field, you can still try to mentor someone. Help others so others want to help you. If you’re contributing, other’s will find you. Trust me.

Screen Shot 2016-05-21 at 4.29.08 PM

People asked about what was the most overrated and underrated skills in infosec. Being the top dog, knowing a vulnerability by the first sight of an indicator, and partying hard are all things that are overrated. 80% of the value comes from the last 20% of the work. That doesn’t mean that the first 80% of the work isn’t important. Put your time in, get the research, do it right. “Partying is pretty well tied into the infosec community. It’s big at cons, but it’s not a requirement. Be safe and have fun” -Jim.

The underrated skills that were mentioned were writing reports and monitoring performance. Red team writes 2:1 compared to hacking. It’s important to be able to clearly describe the issue and suggest a technical fix to non-technical people. Monitoring performance is also really important. Going back to the trolls, if you run a phishing exercise, it’s good to show by how much the click through rate has decreased on malicious emails.

Another question was how to get kids involved in infosec. The resounding answer was “don’t”. Thanks wolf. What is really important is allowing your kids to be curious and explore what they are interested in. If the kids are really into infosec, show them the ethical side of hacking. Always try to inspire them to be the best they can be. Also, a good way to allow kids to grow into hackers is Hak4kidz.

Finally I want to finish with a list of other points that I know are important but I can’t remember where in the Q/A they belong. Probably because they were important and were repeated 3-4 times. Hope you like them:

  • Be comfortable being uncomfortable (we’re all uncomfortable)
  • Build relationships <3 NETWORK!
  • Join Misec! (or your local infosec group)

Thanks to TEKsystems for hosting us for the event. Thanks to all the panelists that joined us, Thanks to @chaoticflaws, @vajkat, and @ZenM0de for planning all of this. It was really a great event and I learned a lot. Oh! and I won a RTFM in a raffle, it’s a great resource.

 

OverTheWire: Bandit

Hey everyone, this post about Bandit is NOT a walkthrough of the greatest (only) “learn bash hacking” programs I’ve completed. This is NOT going to give you an advantage if you’re looking for cheat codes. This post will hopefully make you click on OverTheWire and want to try it out for yourself.

Why you should try Bandit

Do you work with Linux, bash shells, scripts, or ever have to deal with the command line? If you are a developer, network admin, forensic analyst, incident responser, pentester… or any other IT job, the answer is most likely yes (unless you have some serious automation or “a guy” for that). Whether you’re entering into a new field or you need a refresher course, Bandit is the first of many war games offered by the good looking hackers of OverTheWire. Start at Lesson 0 and work your way through them all.

Last night, I met up with a group of fellow hackers from #Misec and we tackled it. We went from 4pm to 12am, only stopping for a taco/wings run. We had a wide range of skill levels from 15 years of experience to a recent college grad, but we were able to go through the tasks at a pretty even pace. Doing this training in a open group where everyone discusses their tactics was really cool because there are multiple ways to do the same lesson, there’s never one right answer. I highly suggest you do the same. Get a group of 4-10 people, grab a six-pack and hunker down somewhere.

Helpful Hints

By the end of the night, I had expanded on the bash commands I already knew like ls, cat, chmod, mkdir, touch, openssl, and vi/nano/vim. I looked at the man page (help documentation) for the first time for other commands I heard of but didn’t use: grep, file, diff, gzip, tar, and so much more. Seriously guys and gals, you will not complete this course unless you type <cmd> –help or man <cmd>.

There was only really tricky lesson in Bandit for those unfamiliar with development or python. So to assist but not give the answer away, I’d like to point a few things out about python. Please note this is one specific way to beat this level, @jadedtreebeard found a faster way to beat this level without even touching python.

  • Run python scripts by writing: python filename.py
  • Variables have type, so numbers (30002) are integers and words are strings (“words”)
    • Change integers to strings: str(myVariable)
    • Change strings to integers: int(myString)
  • Importing packages are the first thing to do in a .py file
    • I suggest you look at socket *COUGH COUGH*
  • range(x, y) will give you a list starting at x going to y
  • For loops will loop through every object in a list
    • Syntax: for something in list:
    • Indent under that line and it’ll be included in the list
  • If statements are powerful
    • What would happen if you only did something when a variable contained a certain substring
      • if only “Correct” was in someString: then I could print someString only when it has the right values instead of every incorrect one as well… 😉

There are 27 lessons in Bandit, it took our group 8 hours to casually and thoroughly go through every lesson. A few are very tricky. I suggest you a) read cmd manuals b) read the associated links from OverTheWire for each lesson c) brainstorm and bounce ideas around your group. The only thing you should not do is google the answer, this is a public activity and other people have already done this. I suggest you stay away from googling “how to complete Bandit”…. It’s not cool, you can learn so much more by following a-c.

Lastly, I want to give a shout out to @Ashioni of @CBI_IT, @JadedTreeBeard, @bigryanb, @EquinchOcha and the other hackers in my group who’s twitter handles I do not know… It’s because of them I had such a fun time instead of pulling my hair out when I got stuck on lesson 28. If you are in the Michigan area, you seriously need to look up #Misec, it’s a great group of people. Reach out to @Ashioni, he is trying to set up a workshop at @CBI_IT to go over these exercises.

After you’ve conquered Bandit, move on to the next level: Leviathan. I suggest trying Bandit in a group with other people, but Leviathan should be pretty tame and is a good way to test your individual skills.

TLS Lightning Talk

Hi everyone, last night I gave a lightning talk at Misec Jackson. It was a quick 15 minute summary of my last blog post on TLS. I summed everything up into 12 slides and threw in some last minute images to make it look better than just bullet points on bullet points.

Other lightning talks from the night

I wasn’t the only talk that night, there was a talk on IPv6 that was pretty insightful. IPv6 is older then windows XP but it’s still not widely used. There’s been a couple hacks and misuse of it’s features already, but I’m sure there’s more to come. Another talk was on “the evil bit“, network packets actually have a bit that can be set if the packet has malicious intent, and any security device should drop those packets immediately. Some website do this, others don’t. A fun idea would be hiding a service by ONLY accepting the inverse of that. The last talk of the night was about RFID tags and stealing card info, the speaker referenced a talk from DefCON 21 (pdf of defcon slides).

My thoughts on my talk

Look! I'm behind the podium!!
Look! I’m finally behind the podium!!

My talk went pretty well, I didn’t have any words on my slides. I had a lot of pictures that I used to replace my talking points and I wrote everything I wanted to talk about. This was my second time giving a presentation for hacking. My first attempt I was talking into a computer the entire night as I did a walk though. I feel like I did a lot better by not putting my words on the screen n reading off the slides, I was able to make more eye contact with the crowd and the words flowed more easily. If I was going to give this talk again, I’d do more research into the technical aspects of TLS MITM attacks, or how TLS is implemented. I had one question from the crowd about how someone would be able to decrypt a  packet and I went into a MITM description… I feel like I might have misunderstood the question and I want to do more research with that before I present on the topic again. Let me know what you think about my slides, feel free to leave me a comment. The notes at the bottom of the google slides were my talking points, and most of those were summarizing my older blog post.

I’m glad to have a second set of slides under my belt. Now I have “Web hacking with the broken web app project” and “TLS: what is it and why it matters”. My next scheduled talk is on web app testing and will be at Misec Southfield in June. I look forward to giving back to the security community and I’m happy to be gain presentation skills as I learn more about information security.

TLS: What is it and why it matters

In my normal fashion, I’m going to start this blog post with a little intro to cover my butt. Recently at work, I’ve been tasked with learning about Transport Layer Security or TLS. This blog post is my own thoughts and is not 100% accurate, but I hope you get the idea as well as I do.

What is TLS?

Well, as I said above, TLS is Transport Layer Security. It’s the encryption used by clients and servers to encrypt messages sent between the two. Some of you may remember SSL, or Secure Socket Layer. That was the predecessor of TLS. Since then, SSL has been proven to be insecure; don’t ask me how, but I do know that one example of abusing SSL is the POODLE attack. Wikipedia says “all block ciphers in SSL; and RC4, the only non-block cipher supported by SSL 3.0, is also feasibly broken”. That’s about as far back as I went with the history of TLS. All I took away from SSL is that it’s deprecated and no one should use it.

TLS encryption is a complex combination of keys, certificates, and ciphers… I’ll try to explain this but don’t punch your screen or write me an angry email if I’m wrong. Before any website traffic is sent between a client and a server, they must agree on a key and a cipher. The cipher encrypts the messages, the key decrypts them. The client and server exchange keys using a fancy algorithm and decide on a cipher that both know how to use. Certificates are like ID’s that prove a TLS connection is valid.

Why does TLS matter?

Have you ever looked at a packet as it goes across your network? If not, I suggest looking at mitmproxy.  A quick rundown for the non-network people. A request over regular unencrypted HTTP traffic is visible to everyone on the network, a hacker can grab all of the information in your request, like your password, user tokens, credit card, email address, etc. An example of a HTTP request is below from shakedos.

Lack of TLS reveals auth token
http://www.shakedos.com/2013/Nov/23/tinder-privacy-issues.html

This is mitmproxy catching a pair of authorization tokens for the Tinder “dating” app. Now that the hacker has your auth token, they can inject it into their own request and gain access to your account. This is one example why it’s dangerous to send sensitive or private information over encrypted channels. So to protect your user’s information, encrypt your traffic! If this was all sent over HTTPS using TLS, then the information would not be decipherable without the client’s key.

Why everyone should use encryption

This isn’t exactly correct… but I agree with the principle. Somewhere, probably twitter, I read a couple articles linked from cryptographers about the point of early cryptography. Spies would email home over encrypted channels. While the message is unreadable, it is still sent out over the network. The only difference is instead of seeing “token: abc123” it’s “W$JT#N:SNV120934”. Network monitors that expect to see unencrypted requests can flag a request with unknown contents and trace the source. aka if our friends, the North Koreans caught an encrypted e-mail and trace it to a coffee shop, chances are they can find our spy. Did that make sense? This is the reason why everyone should encrypt things, so ALL the internet traffic is a jumbled encrypted mess, and that monitors can’t single out a specific source of an encrypted message.

Things to shoot for

There’s a lot of configuration options for TLS, even the keys are complex. The main thing to remember when setting up TLS keys is that it’s important to have a minimum of 128 bits of security. Which means RSA keys with 2048 bits or ECC keys with 224-255 bits. You can also have larger keys, but going larger is pointless if you use Elliptic Curve ciphers (ECC). In order to save time, OpenSSL stores keys on the server from clients that have already shared keys with it. These keys are encrypted using AES128-CBC and that is only as strong as 128 bits of security. Because of this, it’s also good idea to restart your server nightly in order to reset the cache of stored values.

Certificates are also important, the signature should use SHA-256 or better. Use a name that fully represents the name of the domain. Don’t use “www” or “localhost”. Certificates signed with a certain encipherment (or signature) will use the same cipher to encrypt messages, so ECDSA certificates will use ECC ciphers. Server certificates should be X.509 version 3, older ones are deprecated. Use certificates issued by a CA, not self-signed certificates. They publish information that traces a line of authority and that can be used to authenticate the certificates. If your site uses personal identity information (PII), then it’s a good idea to have a EV certificate. It’s a special TLS certificate with your companies name on it to “increase user confidence in that the site is who it claims to be”.

When defining your cipher list, it’s a good idea to only use the latest recommendations from NIST. Thanks to Mozilla, A good example of a modern cipher list is …

ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK

… This cipher list gives priority to the first ones defined, so more secure cipher are used compared to weaker versions. The last line prevents broken or deprecated ciphers from being used. Again, SHA-256 or higher is recommended and SHA-1 shouldn’t be used. It’s important to note that AES-128 is different and I believe it’s ok to use ciphers with that in it’s name. Favor GCM ciphers over CBC ciphers because it is an authenticated encryption with associated data.

Try it out!

You’re probably thinking “putting encryption on my server is hard, and if I’m going off your blog, I have no idea HOW to do it, just why I should”. However setting up TLS on your sever can be really easy thanks to a new software called LetsEncrypt. Depending on your server, it’s either really easy or kinda easy to set up. I have a Ubuntu VM and all I had to do was update Python to 2.7.9, run apt-get-update, clone their github repo, and finally run ./letsencrypt-auto certonly –apache -d blog.greenjam94.me. The software runs through it’s own installation of dependencies, it’ll open a GUI where you submit a email address and choose if you want to use http and https or just https, I suggest just https and being more secure. After that it’s all set up for you. Lets Encrypt sets up all the configuration you need, even for applications like WordPress Blogs. However I did have to change some of my links on each webpage, in a rush I made my connections to some CDNs (hosted code that I borrow) as http and that gave the browser mixed messages.

The downsides to using LetsEncrypt is that it’s a free program that obfuscates your online intentions. However, that also means it’s a free tool for hackers to hide their treasure chests of evil goodies. Google has started to notice this and is flagging some of the LetsEncrypt certificates, so chrome might tell your website visitors that you use a suspicious TLS certificate. I haven’t seen proof of that, but infosec friends warn me of this. It’s also limited to 6 month certificates, they expired pretty fast. All you need to do in order to fix this is re-run the command from above, but it’s still maintenance that needs to be accounted for. I’m sure there’s one or more sysadmins out there that have written a bash script or cron job to do just that.

Testing TLS

There are a few ways to test servers for TLS. You can use free labs provided online, like Qualys SSL labs. Another option is to use tools like OWASP’s O-Saft. If you are a sysadmin or just love to play in the console; bughunter recently blogged about a bash script that uses OpenSSL to check websites for TLS. I’ve used all three and it really comes down to what you’re looking for. All can confirm if you have it installed correctly, Qualys will give you a report card. O-Saft will give you some detailed information. Bughunter’s Bash Script will give you a list of all the available ciphers on that server.

What TLS doesn’t solve

TLS isn’t a cure for cancer, but it is important. While TLS provides connection encryption, it doesn’t equal trust, validation, or security. TLS makes it harder for hackers on the network to see what packets you’re sending, however it’s still possible for them to do a man in the middle (MITM) attack. There are additional ways to prevent that like disabling TLS renegotiation and enforcing HSTS. TLS isn’t a replacement for a good implementation of user authorization or input validation. For example, TLS can’t stop a user from using SQL injection to drop your database tables if they can bypass authentication and impersonate one of your users. Their injections will just be encrypted as it comes flying towards your database. Just because a site has TLS doesn’t mean it should also be automatically trusted. Don’t give a site your SSN or credit card just because you see a lock in the URL window.

TLS Takeaways

Here’s a quick wrap up. SSL is old, don’t use it. TLS encrypts regular website traffic and makes it safer. Everyone should use encryption so the few that need it don’t get singled out. 128 bits of security is ideal. Installing TLS is easy with LetsEncrypt, it’s not a perfect fit and there are downsides but it’s a quick start. Test your TLS make sure it works. I hope you liked this blog post, I really enjoy this topic and will probably be doing a presentation on it at Misec in the coming months. I’ll be learning more and revising this as I do, please reach out to me if you have any advice.

My first CTF: ruCTFe 2015 w/ #Misec

I know there is a lot of different people reading this post; mentors, coworkers, students, friends and family. So I’ll be as thorough as possible to cover all the bases. Mainly because I’m very excited about all of this and I want to write down all of the details before it gets too late. (Feel free to skip a paragraph if it gets too boring)

what’s ruCTFe?

First off, it is capture the flag! Why am I so pumped about a game of capture the flag? It’s the international hacker version of capture the flag!! Imagine this, Russia (the ru part) is the host. They give every team a virtual machine (vm) with a number of applications “ready” to be deployed. Each team is responsible for keeping their apps online as well trying to bring down other teams apps. Our Russian hosts have access to everyone’s apps and are able to “drop” flags throughout them.  Flags are strings like “A23HFK36JG732IE436GHD8OVH1297QUF=” and you know it’s a flag because it’s 32 capital letters and numbers followed by a “=”. Each app has a unique twist that makes the game more interesting. For example, one app was written in Python, another was in C and used .cgi files (WHAT?). Some apps stored data in mysqli and sqllite databases, others used files with JSON. The variety added  complexity that made the game more fun. #Misec (a local hacker group and our team) arranged people into four groups. Red team focused on attacking other apps and searching for flags. Blue team was responsible for defending our apps and hardening the server. Green team was ops, they built and maintained the network. Fuchsia team was our developers  and became jack of all traits because they worked along side red team on code dives while implementing blue team’s defenses.

I was a part of the red team. I really enjoy penetration testing and I knew this would be great experience. Our team lead was Austen. He walked me through a lot of what it means to be on the red team. I’m very thankful for his help. This was my first time implementing a lot of tools on the Kali OS and  I had no idea what I was doing. Last weekend was a prep meeting and I found out that my old Kali box wouldn’t update, so I had to prepare a new one during the week. #Misec was really helpful every time that I got stuck or hard a question during setup.

Walk Through

My day started at 3:30am with a blaring alarm clock. That was probably the worst part of the day, which also means the day would only get better right? I arrived on site around 4:20, just in time to help hang wires and bring in equipment.  As everyone showed up, we brought out our machines, connected everything and got the VMs ready. I worked with Brad (Fuchsia lead) and Austen to reset the root password and config SSH so that I could log in from Kali. Once our environments were set up, the red team started looking for what ports were open and what  services were listening. This was the first time we found what the apps were using. Like I said earlier in the explanation, there was a wide range of databases and languages at our disposal. Brad dumped the databases and passed it around for others to try and understand while Amanda (El Conquistador and Blue team leader) searched for passwords and configurations that needed to be updated. Otherwise other teams could use the default accounts to own us.

Throughout the morning, the green team worked to get the apps online. As they did that, the red & fuchsia  teams searched high and low for vulnerabilities in our VMs that would get us an advantage against other teams. The blue team continued to check our apps and secure them as needed. I spent this time running my VM through Armitage. I wasn’t able to find any exploits right away that the apps were vulnerable to, but that was to be expected. Armitage is very automated and it’s hard to customize exploits to work with specific apps. After that turned out to be unsuccessful I turned my attention towards Burp Suite. However, I wasn’t able to configure it correctly so I turned my attention towards code dives hoping to find something obvious like SQL injection or worse. The apps were all in their own directories under home/ and it was very interesting to look through how our hosts had made the VM. As I was looking around, Austen found one of the apps used the same auth token in a cookie for every user in the app. I helped him confirm that by recreating what he did on my VM. The idea for a exploit was that if we could pick up  a player’s cookies when they dropped flags off to the host, we could get into the apps they were just at.  Austen also found a second vulnerability where for the Python app, the password was “hashed” by turning numbers into their ascii hex equivalent. I wrote a small python script to decode the hashes incase we ever got a hold of another teams JSON files. Just a quick note, this is the first script I’ve written to help break a web app and I was really excited to see how easy it seemed; the development background (and wide range of python libraries) really helped.

The apps go live

Between 11 and noon, the green team was able to bring our app online at full capacity. This was our first time being able to score points and everyone was really excited. However this also brought a new issue, where other teams could now attack us. The plan seems to be working pretty well though, we were earning points for keeping the app alive and no one seemed to be trying to attack the server too badly from the outside. As soon as the red team had access to other teams, we started to poke other teams servers to see what was possible. I tried to find a way to get my python script to work, but first I needed a way to find the json file. I tried calling it directly from the URL, SSH-ing into their application server, and just crawling through the app. This didn’t turn out very well so I tried another tactic. Now that we had real targets, maybe it’d be worth trying Armitage again, other applications might not be as hardened as ours, right? Well, like my VM, it didn’t return any easy results, so I abandoned the idea to return to poking at random teams’ apps, hoping to find a XSS or SQL injection bug somewhere. While I was digging around, my box froze. I have no idea why, but it used to happen all the time when I was running windows7 (I assume it was related to the hardware). I just rebooted Kali and continued my barrage of random attempts to attack other teams.

During my assault, Amanda came over to ask if we had done a game-wide nmap scan to list all of the active teams. The game was a almost 3/4 of the way done and no one on the red team had thought to scan everyone after we had gotten our apps up on the game network. Amanda showed me how to use RAWR, a python wrapper of nmap that allowed us to scan and log more cleanly then just saving nmap output straight to a text file. While Amanda filled me in, she was scanning some of the other teams’ servers. I used Python to create a input file for RAWR that would hit the production box for 254 ip addresses. As I started to run the scanner, Austen found another way to grab flags by recreating auth tokens for users of a Ruby app. He quickly wrote up a Ruby script to loop through different teams and a range of IDs (both were used to create the auth tokens) and distributed the code amongst the red team to try and crack as many teams as possible. He ran the code first and started to find flags on the other teams servers, however when he went to turn them in, the host’s scoreboard server was having connection issues.

Down to the wire

Since there were issues from the host, we tried to hold onto flags until we were able to reconnect to the scoreboard and turn them in.  This was risky because it was going on 2pm and the game was only live for another hour. As soon as Austen found a valid flag, the red team started running his script over different teams trying to get their apps to give up more flags. I made a couple modifications to his script on my box so that instead of going through 100 IDs on a team, then going to another team (and so on), the script would ask me for what team to scan and wouldn’t iterate to a second team. I was able to use this modification to run a few scripts at once and try to grab as many flags as possible. As we were searching, we were able to find a good amount of flags. The second modification I was trying was to add inputs for the starting and ending IDs for the script. I couldn’t get it to work and didn’t know why until after the game ended when I asked Austen to look it over. I was still able to get 6 flags in the last ten minutes of the game and I was very excited to have contributed to increasing the team’s score. It felt amazing. At the end of the game, we were ranked 118th out of over 300 teams and I was proud to have helped and learned so much, especially since we climbed 3 ranks within the last few minutes!

ruCTFe partial scoreboard
Misec beat Batman

Conclusion

I want to give a huge shout out to Misec for pooling some great local talent into an awesome team. Thanks to Steven for organizing this year’s event and to Jason for building our infrastructure/network. Also, if it wasn’t for Austen, Brad, Amanda, Wolf, Ben and everyone else who helped me and made me feel like a member of the team. I wouldn’t have been able to learn as much as I did or have as much fun without you. I can’t wait to see what will happen at ruCTFe 2016!