Security Ripcord

I have only mentioned this to a few people thus far, the number grew at DefCon, because I was waiting for it to actually happen.  When I graduated college I decided that I wanted to move into security because I figured it was a field that would always be necessary.  I knew that people would always be trying to break in and that companies would need people to find out what has happened and need advice on how to respond.  Since starting security with Raytheon I have endeveored to increase my knowledge of technology while mainly focusing on certification, accreditation, and compliance at work.  Now all of my hard work and extra time has paid off.

Today is my last day as a Navy contractor and Monday will be my first day as an incident responder for IBM Internet Security System’s Emergency Response Team.  I will be joining the likes of Harlan Carvey, Cory Altheide, and other well known and highly respected individuals. Some of whom have already written books on Windows and *nix Forensic Analysis, so I figure I am in for a world of learning and progression.  I am getting very excited and cannot wait to start and prove myself to my new team.

All of that said I have to give a shout-out to my current team.  I have had the pleasure of leading thirteen other Navy contracting security professionals.  It has been very challenging to bring an organization without a security group into the world of security.  Fortunately we usually had executive buy-in which helped easy most of the transition.  But my team of raw (from the security stand point) recruits really shown through and proved that they could come together as a team and work openly with their administrative and developer counterparts.  They have had an amazing impact on the organization we work for and I am certain that as they continue forward without my guidance they will prove that they have both the knowledge and drive to learn that will help them get the job done.  I want to tell all of these people  that it has been my pleasure and privilege to lead them during the past ten months.  It is the only down side to moving on and I will miss them all.

So, here is to new beginnings and old friends.  May we all prosper in our collective and individual futures.

Go forth and do good things,

Don C. Weber

Well, I think it is pretty well known now that l@stplace is now being affectionately referred to as 3@stplace after this year’s DefCon Capture The Flag (CTF) competition.  I will not have a detailed write-up like I did last year as most of my time was spent banging my head on LosT’s challenges.  If you want to know more about what happened you should check out @tlas’ recap, swing over to the Daily Dave Archives for input from several team members, or check out the write-up at NOSRUS.  These sources say it better than I ever could.

Some interesting CTF stuff that did happen to me, however, is that I got to speak with Invisigoth again, @tlas for the first time in person, and I actually met Mezzendo on the shuttle ride to the Riv.  Getting to speak with these guys is like somebody from the deep South having a conversation with a NASCAR driver or WWE wrestler.  I try not to get all geeked out by other people because, after all, they are just other people.  But it was great to get to interact with them in person rather than virtually.  They were all very personable and seem glad to talk to me.  Unfortunately, although DefCon is a great place to met these guys, their extra time is definitely limited.  Maybe next year I’ll get into a few of the parties and have a better chance to interact with them.

So, congratulations to Sk3wl0fr00t for their domination of so many outstanding teams.  Of course, from reading @tlas’ recap it looks like they have lit the fire under l@stplace and I’m willing to bet that we have not heard the l@st of them.  I do think, however, that this just means that the competetion is going to become stiffer each year that passes.  This will also put pressure on Kenshoto to keep coming up with outstanding and ground-breaking scenarios for these competitions.

One thing that did catch my eye while I was walking around DefCon was a flier for a $100,000 CTF in South Korea.  For some reason I cannot find the flier now but I guess it is similar to the April competition that was written up on The Dark Visitor back in March.  I have a feeling that we are going to see this turn into big competitions like we have seen with console gaming.  Imagine a circuit where you just do CTF for a living.  It seems like a good way to quickly base and build up your skills.  And, when all is said and done, back to the corporate world for damn fine consulting fees.  Well, we can all dream, right?!!!!

Go forth and do good things,

Don C. Weber

Another DefCon has been completed and, as I suspected, it lived up to its expectation.  I was able to catch up with a bunch of my blogging friends, meet a few new ones, and even have lunch with a few old co-workers.  As usual, the majority of my experience was dominated by The Mystery Box Challenge (MBC) in which I and my team got completely p0wn3d by LosTBoy, which was completely expected.

The weekend started out with ominous undertones as my primary computer (which I was not about to bring to DefCon) suddenly had boot errors.  Of course it didn’t turn out to be a problem such as a bad hard drive as I expected, it was merely GRUB trying to include a removable storage device and erroring out.  This “problem in plain sight” would prove to be the overall trend in the MBC.  I’ll go into the MBC in a following post as I want to provide a few tools to help people understand the solutions.

My first evening in Las Vegas started out like last year.  I met up with Jon Squire and we caught up with his past year and his turbo talk at this years Black Hat.  Although it did have some laptop issues apparently it went very well and was well received by those who attended.  He is doing some scary things with UPnP and vendors should start doing as he suggests by disabling UPnP by default and putting up a BIG RED WARNING label to try and keep them from enabling it.  This won’t help everything but at least it would be a start.

After a few beers with Jon I linked up with Chris Hoff, Alan Shimel (still down as of this typing), Mitchell Ashley, Jennifer Jabbusch, and a few others.  It was good to see Alan and Mitchell again.  I have always liked Alan because he is always helpful, generally happy, and very personable.  It was a same to see that he was subject of a “blog compromise” and I hope all goes well for him.  It was my first opportunity to meet Chris and Jennifer.  Chris and I have had a few conversations so it was good to hook up with him face-to-face.  I don’t think that Jennifer had heard of me before (I guess I have been in the weeds a little too much lately) but we had a good time getting introduced.  The first night ended with a long walk to the Microsoft party where I was promptly denied access since I did not have a pass.  This resulted in a long walk back to the Riv.  No big deal as it was already late in Texas where my body and mind thought we were.

The next three days were just a flurry of activity.  It started off with all of the DefCon Badges getting stuck in US customs.  Apparently they were being shipped disassembled and even when Kingpin got them out of quarantine they still had to be assembled.  After that the MBC started and I was basically consumed until the noon of the last day.  This meant that I couldn’t have dinner, lunch, and even drinks with many of my friends.  To all of you who tried to pull me away, thank you for trying, we’ll definitely get together some time this year.  I did, however, get a chance to met up with my friends Monty McDougal and Jesse.  We had a good time catching up and I even managed to wrangle an interview out of Monty.

That is pretty much the extent of my experience with DefCon.  I’ll have a better write up on MBC and my interview with Monty about his project Windows Forensic Toolchest™ (WFT) in the next few days.

Go forth and do good things,

Don C. Weber

I’m not a funny guy and I am definitely not an artist.  But, in the spirit of Stick Kung Fu, XKCD, and Deep Inspection, I couldn’t help myself.  Everytime I miss the waste basket I am reminded of why I work in this field.

Jeremiah Grossman has a simple but sweet post about what to do on your first day of work when you come on board to a company that has no “no existing web/software security program.” He simply asked, “What is the very first thing do on day 1? [sic]”

The meat of the post is in the comments. Although it started out with some typical guidance on how to technically identify server, applications, vulnerabilities, and the like, the comments quickly transition into focus on the people of the organization. Getting to know the executives, management peers, security and technical administrators, and even support personnel before diving in and trying to find problems and giving orders about how to fix them.

Security Professionals need to remember that there are other people out there. It has often been said that we need to refrain from saying “No,” “Don’t,” “Can’t,” and other negatively connotative words unless absolutely necessary. We often remind ourselves that we are a part of the business unit and that we are, typically, support personnel rather than the front line administrators (and if you are both then your security tasks should take the support model into consideration). So when it all boils down, we are saying that we have to be a helpful and viable part of the business by working with the other employees, no matter the level, rather than being the lonesome cowboy with six-guns drawn. Once we have accomplished this then we can start delving into identify critical physical assets, location of data, mission critical application, and other important technically-related security information. Hopefully, your initial dealings with fellow employees and managers will have already greased the skids to start working with this information, but it will have also provided you with a better understanding of the politics and business necessities surrounding the current state of technical deployment.

I’m not going to repeat my or anybody else’s comments here. Go check out Jeremiah’s post and then put in your two cents. But while you are there, notice some of the names of people who are commenting on getting to know the people and organization first before diving into the technical aspect of the position. You will probably notice many people that you know and respect.

Go forth and do good things,

Don C. Weber

I’m willing to bet a few people I know are going to have opinions about this.

I was Googling something today when I was directed to Wikipedia. As I was reading I noticed the following link for “Portal: Computer Security”.

When I clicked on it I was redirected to a very interesting page full of security links and information. So, I started reviewing what they have included when I got to the “Selected biography” section. Well, the title of the post speaks for itself. Now, the image is a bit large and part of it is hidden. Just click on it and you’ll see the whole thing. Oh, and please feel free to comment

Go forth and do good things,

Don C. Weber

I would like to start off by saying, “You can’t!!” The quicker you come to grips with that the better off you will be in the long run. Politics, or perhaps Micro-Politics since I am talking about intra/inter-office politics, is just a fact of life. Everybody has an agenda whether it is to further themselves, further their family, further the company, or any number of other things. So, get over it because it is just going to happen.

Now, let me tell you how you can control politics. I’m not talking “hand of God” control. I’m talking about making it difficult for politics to adversely (because some politics are good) influence the security of your organization. The answer can be found in my previous post on Organized Security. The answer is “Document Your Processes!” Okay, that is not the full answer, but it is the start. Getting your processes written down and accepted is the first step. The thing that seems to be working the best for my team is to document a process’ flow before writing down the procedure. Understanding the actions, decisions, and touch points of a process before writing the document that details each action and decision point. Here is a simple example pertaining to a user account request. This process flow utilizes “swim lanes” to show different teams or departments.

Once you have created this flowchart it is very hard to justify a deviation from this process. It becomes even more difficult once you detail each box in your procedural documentation. Getting your management and each team or department listed in the “swim lanes” to sign off on their involvement with the process will decrease the deviation possibilities even more. And if all else fails, it will make deviations readily apparent to management and all of the teams or departments involved.

Now, this does not mean that deviations will not happen. It is a fact of life that a situation or event was not taken into consideration during the development of the process. These instances shouldn’t matter in the grand scheme. Once the event has happened and been addressed, the individuals responsible for the process should quickly run through the process to see if any documentation needs to be generated or additional actions taken. After everything has been addressed the team can conduct a lessons learn to determine if the process needs to be updated or if the deviation was just an anomaly that will rarely occur and can be addressed on a case by case basis. Of course, politics can fall into this category. But all of this, as I mentioned, makes the deviation very apparent and the extra work associated with running back through the process and evaluating the overall process should raise questions about the validity of the action.

Once everything is documented and approved there is another very important step. That step is to consistently apply the process. Lack of consistency will leave gaps in all of your processes. Lack of consistency will breed contempt for your system and provide individuals and groups the leverage they need to circumvent the process in question and possibility the other processes developed by your team.

In the end you are not going to solve politics in your organization. You and your team need to learn how to accept it as a part of doing business. Just remember, diligent documentation, repeatable processes, and consistent application will protect you as much as they can.

Go forth and do good things,

Don C. Weber

Well, this week at work was very interesting. Actually, the last two weeks have been extremely busy. As Friday rolled in I looked into the eyes of my team members and I could see the tired, slightly overwhelmed, and, for some, haggled look in their eyes. They had shouldered what our organization decided to throw at them and they pulled through with their heads held high. No small feat when you are talking about a crew with that was built from individuals with very little security background and a manager (me) who is hell-bent on documenting and improving each procedure as they are going through it. I do this not only to help them build a program that is repeatable and lends itself to self-improvement, but so that our customer can “feel-the-pain” when their goals are not being accomplished due to the never ending “high priority” additional tasks (something I, and others, refer to as “firefighting”).

I usually make it a point to congratulate my team members for a job well done. It builds confidence, denotes achievement, and helps give a sense of closure to on-going tasks and issues that never seem to have an “end.” But this week I went a step further. I let them know that when they are working on the “high priority” issues, when the “firefighting” is taking all of their time and effort, that the things they are doing are enough. Just working the task is enough to help secure our environment. Even if they haven’t completed the task or specific issues mean they were not able to address regular duties and other tasks, as long as they worked hard and smart, it is enough.

It has to be enough. No environment is ever going to be 100 percent secure. Security professionals and security cynics can all agree to that statement. But, when you look at it from the other end, no environment is zero percent secure either. Each operating system comes with some controls. So every environment starts a little bit “in the black.” As an organization starts adding personnel and controls they increase their security percentage. Finally, with the addition of security professionals and a well-rounded security approach, an organization sees its greatest jump towards the unobtainable 100 percent secure goal. Just dong things to move towards that endpoint is enough. And I think that sometimes organizations and managers forget that aspect of the big picture.

So, when you get back in the office next week, take a look around. Look at the accomplishments of your team members. Take note of these accomplishments and provide the appropriate praise to the situation. Let them know that their efforts are enough and that because of their actions the overall environment is more secure. Then look at the other individuals in your organization. Look at the system administrators, the desktop support personnel, the help desk operators, and everybody else. Look at their actions and point out their accomplishments as well. Let them know that they are helping secure the environment and that their actions are enough.

If you do this, you are doing enough and you are speeding up your progress towards that unobtainable goal.

Go forth and do good things,

Don C. Weber

I just noticed that my feeds were broken and I apologize to anybody who has missed my valuable contibutions to the security industry . I’m not sure how long this has been going on. I assume since I upgraded to WP 2.5.1. I turns out that either podPress or the Creative Commons plugins is not playing nice. I was getting the following lines concatenated in the feed:

• xmlns:creativeCommons=”http://backend.userland.com/creativeCommonsRssModule”
• xmlns:itunes=”http://www.itunes.com/dtds/podcast-1.0.dtd”

To fix it I added a leading “\n” to the “xmlns:itunes” line in podPress’s podpress_feed_functions.php. This fixed the problem although I do not know if is a podPress bug or a Creative Commons bug. I have jumped on a similar issue at the podPress forums. They are usually very helpful and I should get a response and know more soon.

Welcome back to all.  Please check and make sure you haven’t missed anything.  I have also published a few new pages you should check out.  And don’t forget to respond to the latest Security Ripcord Poll in the left sidebar.

Go forth and do good things,

Don C. Weber

This will show the capture of ping requests to a specific host. This information will be captured using tshark to a pcap file. This pcap file will be edited to cut out the ping reply packets. This file will then be used to replay the ping requests and receive responses.

This should be the first step to many similar replays.

Run tshark to capture

[user@localhost tshark]$ sudo /usr/sbin/tshark -i eth0 -w ping_default.pcap
Password:
Running as user “root” and group “root”. This could be dangerous.
Capturing on eth0
8
[user@localhost tshark]$

Ping remote host

[user@localhost tshark]$ ping -c 4 192.168.2.1
PING 192.168.2.1 (192.168.2.1) 56(84) bytes of data.
64 bytes from 192.168.2.1: icmp_seq=1 ttl=64 time=0.422 ms
64 bytes from 192.168.2.1: icmp_seq=2 ttl=64 time=0.339 ms
64 bytes from 192.168.2.1: icmp_seq=3 ttl=64 time=0.243 ms
64 bytes from 192.168.2.1: icmp_seq=4 ttl=64 time=0.334 ms

— 192.168.2.1 ping statistics —
4 packets transmitted, 4 received, 0% packet loss, time 3001ms
rtt min/avg/max/mdev = 0.243/0.334/0.422/0.065 ms
[user@localhost tshark]$

Read pcap file with tshark

[user@localhost tshark]$ sudo /usr/sbin/tshark -r ping_default.pcap
Running as user “root” and group “root”. This could be dangerous.
1 0.000000 192.168.2.242 -> 192.168.2.1 ICMP Echo (ping) request
2 0.000370 192.168.2.1 -> 192.168.2.242 ICMP Echo (ping) reply
3 1.000509 192.168.2.242 -> 192.168.2.1 ICMP Echo (ping) request
4 1.000783 192.168.2.1 -> 192.168.2.242 ICMP Echo (ping) reply
5 2.001345 192.168.2.242 -> 192.168.2.1 ICMP Echo (ping) request
6 2.001524 192.168.2.1 -> 192.168.2.242 ICMP Echo (ping) reply
7 3.001984 192.168.2.242 -> 192.168.2.1 ICMP Echo (ping) request
8 3.002263 192.168.2.1 -> 192.168.2.242 ICMP Echo (ping) reply
[user@localhost tshark]$

Rip out only the wanted packets

[user@localhost tshark]$ ls
ping_default.pcap
[user@localhost tshark]$ sudo /usr/sbin/editcap ping_default.pcap ping_requests.pcap 1 3 5 7
Password:
Add_Selected: 1
Not inclusive … 1
Add_Selected: 3
Not inclusive … 3
Add_Selected: 5
Not inclusive … 5
Add_Selected: 7
Not inclusive … 7
[user@localhost tshark]$ ll
total 16
-rw——- 1 root root 936 2008-05-17 23:33 ping_default.pcap
-rw-r–r– 1 root root 480 2008-05-17 23:35 ping_requests.pcap
[user@localhost tshark]$

Read pcap file with tshark

[user@localhost tshark]$ sudo /usr/sbin/tshark -r ping_requests.pcap
Running as user “root” and group “root”. This could be dangerous.
1 0.000000 192.168.2.1 -> 192.168.2.242 ICMP Echo (ping) reply
2 1.000413 192.168.2.1 -> 192.168.2.242 ICMP Echo (ping) reply
3 2.001154 192.168.2.1 -> 192.168.2.242 ICMP Echo (ping) reply
4 3.001893 192.168.2.1 -> 192.168.2.242 ICMP Echo (ping) reply
[user@localhost tshark]$

I am not sure why that happened. Grap the right packets with editcap.

[user@localhost tshark]$ sudo /usr/sbin/editcap ping_default.pcap ping_requests.pcap 2 4 6 8
Add_Selected: 2
Not inclusive … 2
Add_Selected: 4
Not inclusive … 4
Add_Selected: 6
Not inclusive … 6
Add_Selected: 8
Not inclusive … 8
[user@localhost tshark]$

Read pcap file with tshark

[user@localhost tshark]$ sudo /usr/sbin/tshark -r ping_requests.pcap
Running as user “root” and group “root”. This could be dangerous.
1 0.000000 192.168.2.242 -> 192.168.2.1 ICMP Echo (ping) request
2 1.000509 192.168.2.242 -> 192.168.2.1 ICMP Echo (ping) request
3 2.001345 192.168.2.242 -> 192.168.2.1 ICMP Echo (ping) request
4 3.001984 192.168.2.242 -> 192.168.2.1 ICMP Echo (ping) request
[user@localhost tshark]$

Replay with TcpReplay

[user@localhost tshark]$ sudo tcpreplay –intf1=eth0 ping_requests.pcap
sending out eth0
processing file: ping_requests.pcap
Actual: 4 packets (392 bytes) sent in 3.10 seconds
Rated: 130.2 bps, 0.00 Mbps/sec, 1.33 pps

Statistics for network device: eth0
Attempted packets: 4
Successful packets: 4
Failed packets: 0
Retried packets: 0
[user@localhost tshark]$

Capture replay with tshark

[userr@localhost tshark]$ sudo /usr/sbin/tshark -i eth0 -w ping_replay.pcap
Running as user “root” and group “root”. This could be dangerous.
Capturing on eth0
8
(process:8719): CaptureChild-INFO (recursed): Signal: Stop capture
aborting…
tshark: Child capture process died: Abort
[user@localhost tshark]$

Review what happened with tshark

[user@localhost tshark]$ sudo /usr/sbin/tshark -r ping_replay.pcap
Running as user “root” and group “root”. This could be dangerous.
1 0.000000 192.168.2.242 -> 192.168.2.1 ICMP Echo (ping) request
2 0.000332 192.168.2.1 -> 192.168.2.242 ICMP Echo (ping) reply
3 1.001619 192.168.2.242 -> 192.168.2.1 ICMP Echo (ping) request
4 1.001905 192.168.2.1 -> 192.168.2.242 ICMP Echo (ping) reply
5 2.002310 192.168.2.242 -> 192.168.2.1 ICMP Echo (ping) request
6 2.002494 192.168.2.1 -> 192.168.2.242 ICMP Echo (ping) reply
7 3.003997 192.168.2.242 -> 192.168.2.1 ICMP Echo (ping) request
8 3.004201 192.168.2.1 -> 192.168.2.242 ICMP Echo (ping) reply
[user@localhost tshark]$

Go forth and do good things,

Don C. Weber