Building an Infosec Career with an Internship

How do you get started in infosec? It’s a question that gets asked a lot and there’s often a talk about it at every conference. Someone’s got advice on how they got started and how it could help someone else. Heck, I even did one myself at BSides Rhode Island (link).

I organize my local OWASP chapter in Rhode Island and I get speakers each month on the various web application security topics. In August 2012, I had a friend in the profession, Paul “pauldotcom” Asadoorian come speak at the monthly meeting. During the normal course of conversation, I mentioned to Paul how that I was trying to make a full conversion from an application developer to a web application security professional. I’d been to a couple SANS classes, I attend conferences when I can and I tinker on the side trying to learn. However, without a mentor or having someone nearby to bounce ideas off of or ask questions or push me to learn new things. How do you learn when you don’t know *what* to learn?

I had also been tinkering with an idea with my employer to create a “staff sabbatical” where professional staff could go off and do some hands-on learning for a period of time. My suggestion was the equivalent of three months, full time. That could be spread out over a longer period or just go do it, cold-turkey and then return to the job. I told Paul that if I got my employer to agree to this kind of arrangement that I’d then be looking for a company to mentor with. Paul immediately perked right up, “How about with me!” I thought the idea was perfect. I brought the idea to my employer and they agreed, but it would only be for the equivalent of two months. I would work with Paul for 2-3 days a week and keep track of the days. I’d work for 30 days as an intern to Paul but then another 10 days, I would still work with Paul but I had to work on something related to web security for my employer. Done deal.

I started with at beginning of the new year, 2013.

On day one, Paul gave me my first two assignments. One was to “learn everything about CSRF (cross-site request forgery), build a demo and create a presentation for the PaulDotCom Security Weekly podcast.”

The second was to catalog every show he had ever done, into a wiki, specifically the technical segments and the guest interviews. At that point, he had done about 315 episodes. With not really knowing what CSRF was exactly and with that much grunt work ahead, I knew I’d be busy. But I’d learn a lot.

I alternated between the tasks as I thought the cataloging would be pretty mindless. Just going through the show notes, finding the guest interviewed, finding a copy of the video, if that was available and making a new entry in the wiki. In addition for each show that had a technical segment, I’d make an entry in the wiki for the person doing the segment, the topic and link to the video and slides, if those were available. As I started going through the interviews and especially the technical segments, I was amazed at how much was there. It seemed the show had talked to every well-respected expert in the field and it also seemed every topic had a technical segment on it done as well. Instead of simply cataloging all the segments, I started watching them. And learning! That wiki is an amazing treasure trove of information.

It didn’t take long to complete the catalog and dig deep into CSRF. First figuring out how it works, then setting up and playing with a vulnerable app (I chose a 5+ year old version of Drupal, 4.7.0) and then start writing my own attack for it. I got to figure out how it worked from trial and error and got to do the happy dance when it did. I wrote it up and presented a “CSRF Primer” for the podcast.

When I was looking for my next task, I would watch Twitter for various tips and came across Adrian Crenshaw’s Irongeek web site. It contains videos from the many conferences, meetups and training sessions that he has attended. I watched a video by Jeremy Druin, on sqlmap and saw just how easy it is to use. From there, I started simply digging into the various switches/flags that can be used with it and decided to dig deep into one of those.

Rinse, lather repeat.

My interest is mainly in application security. So I use the OWASP Top 10 as my checklist. Try to become proficient at one and then move on to the next. I also have a philosophy of learning that it helps to “learn, do, teach.” Each time I learn something new and think I have a solid understanding of it, I look for an opportunity to present it to someone else or a group. A local OWASP meeting group is great for this as meeting organizers are always looking for presenters.

What I’ve tried to do here is just explain one experience toward getting started in the field of infosec. Because in the end, it worked. I did make the full conversion from a programmer to being offered a job on a major technology company’s incident response team, focusing on web application attacks. It was everything I’d been working toward for years.

If you’re looking to get started in infosec or looking for advice to give others, some of the best that I got included to do it yourself, start a blog and focus. I hear people say they want to “do security stuff” but it’s not in their job description. I tell them to do it at home, at night, in their own labs. If it’s something you really want to do, you’ll find a way to make this happen. Then as you’re learning, document it all in a blog. This helps you to really think things through and may point out holes in your understanding, and serve as a place for you to go back months later when confronting a similar situation. Even better, when you’re looking for a job you can point them to your blog to show the work you’ve done. Lastly, people think they want to simply “work in security.” That’s great but it’s also like saying you want to be a doctor. When someone says they’re a doctor, usually the next question is what they specialize in. It’s the same thing with infosec. The field is way too big to know about everything. So specialize. Figure out what you like and what you want to be an expert on. Don’t get distracted by shiny objects in other areas outside of your interest.

That’s about it. If you want to get into the field, just do it, and even better if you can find a way to do an internship with a security company. Do everything they want you to do, even if it isn’t exactly what you’re interested in, as you never know where it could lead.

Video: Learning Security on the Cheap at BSidesRI

You might need to jump to about 1 min, 10 seconds in for the start of my talk.

Learning Security on the Cheap

Here’s an article I wrote for the Summer 2013 edition of the Brown University SecureIT newsletter. It’s for IT people but not necessarily people in the security field.


When I was first learning about IT security, I thought the way you learn is the same way we learn most things. You take classes. The first reaction is then to look for classes in a particular area. I did and was disappointed by either the lack of offerings in computer security, or the cost. It’s very easy to find classes that can cost as much as $4,000 a week and if you have to travel, the costs go up from there.

Fortunately, we have much more economical ways to learn and develop. Social media is a great way to get started. If you’re not keyed in to Twitter yet, you really should be. Don’t worry if you have nothing to contribute, that’s not the point, in the same way that you buy a newspaper without writing articles for it. Once you start following people in the field on Twitter, you start getting keyed in to the specific areas that interest you. Check out who they follow and add them to your list. These people will tweet out their ideas and even better, often tweet out links to relevant articles that can be a huge help.

How about this little thing called the internet? You can find all kinds of useful information for learning there, whether it is online courses for free (i.e. Coursera), or finding various blogs that are frequently updated and have good information, or searching around YouTube for presentations in the area of your interest. You can find videos ranging from two minute tutorials to even hours long demonstrations and lectures. One great site to find these videos (other than the obvious YouTube) is The site is maintained by Adrian Crenshaw who offers a service to security conferences where he records their talks and makes the video available through his web site. Podcasts (internet mini shows via audio and/or video) are also a great option. Some of the recommended podcasts include PaulDotcom Security Weekly, Exotic Liability and the show. These are all great ways to stay up on the latest happenings in the world of computer security.

Speaking of security conferences and meet-ups, these can be one of the best and most personal ways to learn about computer security. Various meet-up groups exist in the area from the OWASP web application security groups here in Providence and in Boston or the NAISG meeting group in Boston. Providence also has its own Def Con group that meets from time to time with discussions on various security topics. One of the best places to meet other security practitioners is through conferences. Boston has had various security conferences through the year from Source to BSides to SANS and other specific vendor conferences. If you’re looking for an upcoming security conference, one will be happening right here in Providence. On June 14th and 15th, Security BSides will be holding a security conference here on Brown’s campus. Experts from throughout the field will be in Providence for two days to talk about various topics in the area of computer security. Talks will range from the complete beginner to the general overview and to the extremely technical. If you’d like to get more information about this conference, please see

Good luck and happy hunting for more low-cost security training solutions.

Are You Worried About Java’s Security?

Here’s an article I wrote for the Summer 2013 edition of the Brown University SecureIT newsletter. It’s for IT people but not necessarily people in the security field.


We hear a lot recently about the security of Java. Lots of vulnerabilities are being found and new patches being issued constantly. Why can’t a company get this right for a language and platform that’s been available for nearly twenty years? Let’s take a look.

First, what is Java? It’s an object-oriented language that was created by a programmer at Sun Microsystems, back in mid-1990s. Why is it named Java? Well, first it was going to be named “Oak” simply because the programmer was looking for a name and saw an oak tree in his yard. But there already was a language named Oak. Plan B, look down at that cup of coffee. So why not. In spite of some people spelling it with all uppercase, it is not an acronym and certainly doesn’t mean “Just Another Vague Acronym”, my personal favorite.

Java also has zero relationship to javascript, other than the fact both are computer programming languages. Javascript was created by developers at Netscape and wanted to jump on Java’s hype train, so they chose the javascript name. The differences from there get even bigger. While javascript is primarily intended to run in a browser on web pages, Java is a full-featured programming language that needs a compiler and a runtime environment. Sun also touted Java as “write-once, run anywhere”, which meant Java could be run on any platform, Windows, Mac or Linux.

Back to the security part of this. In 2009, Oracle purchased ownership of Java from Sun Microsystems. Since then, we’ve seen the large influx of security issues. One researcher at Kaspersky Labs, believes the reason is because Java was Sun’s main offering, but Oracle has not given the platform the same level of attention..

“I think the current state of Java security is due to the fact that Sun pushed Java very strongly when they still owned it,” said Costin Raiu, director of the global research and analysis team at Kaspersky Lab, via email. “After Oracle purchased Java, perhaps little interest went into this project.” (PCWorld Magazine)

When you have lessened focus on security and add to that the fact that Java runs on more than one billion desktops and three billion mobile devices worldwide, it’s an attractive target. Attackers are able to either compromise a popular known web site or create one of their own and draw vulnerable users to it (also known as a “watering hole attack”). Once users visit a compromised web site, their computer can be loaded with malware or install backdoor access for attackers. If the user has a privileged level of access at a big company, like Microsoft, Apple or Facebook, the payoff can be huge.

Should you run Java? Only if you need to. The way I figured out whether I needed to was to turn it off and wait to see what happens. Wait to see what breaks. It’s really just another plugin in your browser. Or if you need access to internal applications that are Java-based, you will definitely need to have Java installed. One option that is available in Java is to set the security settings to “High”. This means you will be notified every time that Java needs to run. This is one of those tradeoffs between security and usability. If know you use Java all the time, the notification will become an annoyance and you’ll want to lower the setting. Of course, this will leave you vulnerable to the watering hole type of attack.

Java is nice and can be helpful when used properly. But like any other plugin or extension, if you don’t need it, don’t leave it installed. And if you do have it installed, as always, be careful of what you click on.

Site Defacement Investigation

Paul recently called and asked if I’d ever heard of a particular hacking group. I hadn’t heard of that one, but asked why. He was contacted by a web site owner whose site had been defaced the night before. As soon as Paul said the site was running Joomla, my heart sunk. Once you start adding in third party plugins to these frameworks, anything can happen. Making matters worse, the site was on one of those $5 a month shared hosts. The site owner was able to restore the site after everything had been lost. Then we got to dig in and find what caused the hack.

First thought was to check out other sites on the same server. Maybe the host had been compromised and multiple sites were defaced together. So I used the reverse lookup, putting the site’s ip address using the “ip:” in the search header. This returned more than 200 different sites. Some random clicking around didn’t show any similar defacement. Cross that one off.

Next, in spite of having a list of the plugins used on the site and knowing the version of Joomla (out of date by about 15 versions), we decided this would be a true black box test. But first, we looked up the plugins on the list of vulnerable plugins/extensions. Nothing on the list.

But this has to be sql injection. Sure, it could be XSS, but I don’t see a place to inject code to overwrite the site and this type of defacement is one of those “hit and run” type of hacks where the group defaces literally thousands of sites in a night. They’re not bothering to load a cookie stealer or key logger, get the admin password and log in through the front door and make the changes. This is something that can be easily found via Google and easily scripted to make the change.

Back to the site and poke away at it. It seemed to have some variables in the URLs. Of course, switching these to other valid values works just fine but dropping in an apostrophe or ‘ or ‘1’=’1 was handled properly by the site as well. But all the URLs also seemed just a little “too clean.” They looked like they were being rewritten so I started digging to find out if there was more to it, plus I always like to view the source of a page just to see what’s hiding in there. Lots of .css and .js files but also this link: “/?format=feed&type=rss”. When I opened that up in the browser, I saw those previously re-written urls being extended. Things like: “/index.php?option=com_content&view=article&id=17:file-name&catid=2:uncategorised” and “/index.php?option=com_content&view=article&id=18:page-topid&catid=2:uncategorised”. Now we have some things that look like they might be injectable. Changing that id to an apostrophe ends up in a 404 page and a weird re-written url. Changing the catid to an apostrophe properly redirects to the page and the URL is rewritten. Changing the option parameter gives a non-standard looking 404/error page. Is this evidence of blind SQL injection? Maybe.

At this point, instead of poking around manually trying to figure out if this is vulnerable to blind SQL injection, we decide to throw the scanners at it. Nessus, Burp and sqlmap. All of them time out. No good responses from them and nothing even close to finding SQL injection. At this point, we’re getting pretty frustrated. If I can’t find a way in after digging and poking for hours, how and what did this defacement group find so easily?

I decided to take a step back and start at square one. I Googled “joomla site defacement” and found links for mass joomla site defacement scripts as well as some nice tutorials on YouTube. We decided to download one, this “jowp.php” script and read its source. It can actually deface Joomla or WordPress sites from what looks like a typical interactive web shell. Even better, it can deface many sites at once. The video tutorial shows a list of URLs in a browser and shows the status of each being updated as to whether it was defaced or not.

We started digging into the code and we see that it grabs the configuration file for either Joomla or WordPress. But those are php files, so they’re pretty well protected. If you pull them up in a browser, the server simply parses the PHP code and you get a blank white screen. That’s not helpful. Attempts at curl fail as does another quick attempt to find SQL injection in an attempt to get a php shell on the server. That’s when Paul finds it. He does some quick Googling and shows me a page detailing a SymLink Bypass. If you can get access to the server through one site, you can potentially access every site on that server. If any one site can be compromised and the attacker can get access to the server, it’s game over. With that one vector, he can figure out the web root and install this mass defacing script. The script then loops through all the web roots on the server, attempting to pull the joomla configuration.php file or the WordPress wp-config.php file and does a file_get_contents() from some other server, grabbing the defacement content and overwriting the local index file. For good measure, some of them delete all the other flles and add an .htaccess that redirects all requests back to the index page.

Two lessons learned here. Remember, my very first thought was to look at the environment. I’d wondered about the shared host and how vulnerable that was. But I didn’t dig deep enough there and gave up on that too early. Just because other sites that I checked out hadn’t been defaced, I figured this was a one-off problem. The other thing we learned, if your site is critical to your business, don’t go with one of those $5 a month shared hosting services. Maybe the host is going to put protections in place to protect you, but why not invest in your site to protect yourself? Your front door can be locked down and have zero vulnerabilities in your own site, but if the host is going to let people walk in through the back, you’re completely unprotected.


I submitted to the MassHackers CFP for BeaCon. I submitted my talk I did at the Boston College Security Camp on using SQL injection to install web shells on a server. The conference is being held on April 20, aligning with SourceBoston. Looking forward to hearing back from the group.

A Joke That Aligns with Security/Pentesting

A man came to cross the border into the US on his bicycle carrying two large bags. The border agent stopped him and asked “What do you have in those bags?” The man answered “Sand.” The border agent said “We’ll see about that.” While the man was detained, the labs did extensive testing on the substance and affirmed that it truly was only sand. The guard packaged the sand back up in bags for the man and sent him on his way.

The next day, the man came pedaling back with his two bags. Again, he stated he only had sand in the bags. Again they were tested and confirmed and the man went on his way. This continued for months, checking out every single time.

Finally, one night while off-duty, the border agent saw the man in a bar. The agent bought the man a beer and asked him, “Just between you and me, I know you’re smuggling something, but I can’t quite figure it out. What are you smuggling?”

The man smiled and answered simply “Bicycles.”

Moral of the story, don’t get too locked in on one thing. Try to see the whole picture and what else is in front of you.

BSides Rhode Island

Additionally, I’m co-hosting/co-organizing and presenting at the first ever Security BSides Rhode Island conference this summer, June 15 in Providence. I’m co-hosting this with Paul (PaulDotCom) Asadoorian. For more information, check out our awesome speaker lineup or get a ticket at

Hands on Hacking

I have a busy week, presenter-wise. I’ll also be presenting on Monday, March 4 at OWASP Rhode Island. The topic of the meeting is “Hands on Hacking” where I’ll go over topics like SQL Injection and Cross Site Scripting. Things like what can be achieved with it and more importantly, how to prevent them. We’ll have a mini-lab set up in the room running Mutillidae along with a few different challenges for the attendees.

More information is up on the OWASP RI web site.

Boston College Security Camp

Hooray! I’ll be presenting at Boston College Security Camp for the second straight year. In 2012, I talked about a pharmaspam and php shell infection we cleaned up. This year, I’ll talk about one vector that the files can get on to a web server, via SQL injection.

It’s a great one day conference for high ed security professionals (and me).


Slides available after March 8.


Patrick Laverty's Travels into Web Security

The Blog

The latest news on and the WordPress community.