Kees Leune

SANS 504 Mentor

2009-01-01T22:40:22Z

Just a quick reminder: I will be starting a new SANS mentor session for Security 504: Hacker Techniques, Exploits and Incident Handling on January 7 out of Garden City, NY (Long Island). Some spots are still available, so please sign up if you are interested. We'll convene once a week on Wednesday evening from 7.30pm-9.30pm.

More information at: http://www.sans.org/mentor/details.php?nid=14803

SOURCE Boston

2008-12-19T02:14:58Z

Just got word that our proposal for SOURCE Boston 2009 was accepted by the program committee. For those who are going: we'll see you there! As the conference gets closer, we'll share more details.

Making the world a little better

2008-12-18T00:19:34Z

From September to this week, I was privileged to teach an introductory class in computer science at Adelphi University (Garden City, New York). My objectives with this class were to take a group of computer science and management of information systems students who had not have any security classes and teach them the basics of computer security.

By the end of class, I wanted them to understand what the technological implications of computer security were, and I wanted them to be able to recognize certain attacks, as well as to know how to prevent and/or stop these attacks them from continuing.

This Tuesday, we had our final exam and the students did better than I had expected.

I did not set out to set a very hard final; I wanted to test knowledge and understanding of the topics that we covered in class. Skill and ability were put to the test throughout the semester in a security lab. The final mark consisted of 50% of the final result and 50% of the lab results.

One of the questions that I asked was the following:

The chart below was recently recovered from a group of attackers allegedly working on behalf of the Chinese government. This chart is the first documented evidence that attacker-groups are systematically working their way around the Internet to compromise machines.

List out the phases through with a typical computer attacks moves and relate one activity shown above to each phase. Briefly describe the goal of each phase and indicate a defensive action that belongs to that phase.

This question, while not very hard, brought together most of the elements that we covered: how does an attacker work, can you detect attacker activity and place it in context, and do you know how to prevent the activity from being successful. I was very glad to see that almost everyone got close to a full score on this question.

Hopefully, this indicate that my students, when they graduate and disappear into corporate America, have at least a very basic level of understanding of computer security attacks and are able to raise awareness on the topic. If this helped make the world a little better, I'm a very happy person.

If anyone interested in receiving the full exam, I'll be more than happy to share.

Rogue DHCP servers cause perceived service outages

2008-12-05T16:30:12Z

Starting last week, we have been having some issues with groups of machines experiencing unexplained network connectivity outages. The pattern is typically that of one machine losing connectivity, and over the course of an hour or two, many more follow. Almost from the beginning, I had a gut feeling that something was affecting the machine's behavior that was external to them; the pattern did not point at a large-scale distribution of malware.

Late last week, I formulated the hypothesis that we might have some rogue DHCP servers popping up here and there.

Since the machines that were having the problems revert to a presumed-good image upon reboot, finding the actual problem was a little bit of a challenge. Our only real option was to wait for another outbreak, followed by a focused and temporary capture of network traffic.

A few days ago, we got a call that machines were experiencing browsing difficulties, and we were able to capture some network traffic that confirmed my hypothesis; a box that not one of our DHCP servers was sending out DHCP offers.

The offers convinced the clients that received them to switch their DNS to an external machine. We block outbound DNS to anything but our own servers, so the result was that the infected machined were no longer able to resolve any host names. Not a good thing, since they are primarily used as web browsers (non-proxied).

As we were wrapping up the incident, segmenting our network even further, putting in additional monitoring, and doing some additional hardening in certain areas, the Internet Storm Center posts a diary message that was timely and on topic. The subject of the message was Rogue DHCP servers.

Not even a half-day later, I was on the phone with my previous employer and 'lo and behold: they were suffering outages and seeing strange DHCP traffic. It seems that whatever site is offering this Trojan.Flush.M-malware is very effective at reaching institutes for higher education world-wide.

Symantec ranks the risk of this malware as "risk level 1: very low". I disagree with this; risk is a function of probability and impact, and looking at my own experiences, both are high. I have first-hand knowledge of at least three institutes that have been hit, and the impact of getting hit (loss of the ability to resolve hostnames) is also large.

How do we defend against this? The most important steps are to ensure proper network segmentation and providing up-to-date anti-malware software on workstations. On servers, you probably want to statically configure your DNS settings. Make sure you can monitor what's happening on your network; block outbound DNS traffic to everything except your own servers, and consider deploying hardened proxy servers for browsing.

Security lab environment ftw

2008-11-25T13:30:33Z

I teach a basic undergraduate computer security class, which is a mix between ethical hacking, incident response, and a little bit of security management. My students do their assignments in a virtual security lab (7 hosts in a VMWare environment). When class is over, I'll post how I set up this lab in a little more detail.

Getting to work this morning, I found the following message in my mailbox:

Subject: host5 is down
Date: 11/25/2008 2:10 AM
Good Morning,

I crashed host5 by trying to run the following exploit:
http://milw0rm.com/exploits/7091
The files that should be removed: ~mikei/data/1.c and ~mikei/data/1

~Apologies

That makes me happy ;)

Not only did my students feel the urge to play around in the virtual lab in the middle of the night (the deadline isn't for a few weeks), they were also able to identify what they did, and were open and honest about it.

I wish everyone would be so forthcoming. Mistakes are there to be made and learned from. As an information security manager, it should be your job to encourage people to disclose mistakes to you without necessarily being afraid for their jobs.

Now, this is not to say that I wouldn't be extremely mad if someone if in a commercial environment crashes a production server by trying to run milw0rm exploit code on it, but I would still rather know ;)

Creating a Certificate Authority with OpenSSL

2008-11-20T03:15:52Z

Sometimes I need to play around with some digital certificates and I do not feel like shelling out a lot of money each time to buy real ones. Here's how to set up your own CA (certificate authority) in a quick-and-dirty way. Please do not use this guideline to set up a real CA!

The scenario in which I am interested is to set up a single root-CA, which signs the certificates of two sub-authorities. The sub-authorities are the entities that actually sign the end-user certificates. I will create one sub-authority to issue person certificates and one to issue site certificates.

A detailed description of my efforts has been posted.

Risk Management presentation by Dr. Peter Tippett

2008-11-12T19:39:45Z

I attended a two-hour presentation by Dr. Peter Tippett of Verizon Business's Cybertrust group at the Grant Hyatt Hotel in New York City (nice!) today.

Dr. Tippett is on tour to let the world know about the data breach investigations report that his team put together and published earlier this year. At the very least, the presentation was entertaining, but there were even some interesting bits here and there.

Dr. Tippett is a scientist.

Assume that someone says: We need to patch one per day.

In Tippett's view, that is a hypothesis and a hypothesis needs to be tested to determine its validity. These tests can be performed either by analyzing data, or by conducting a controlled experiment.

In many cases, Tippett claims, testing a hypothesis (we need more of product X) will show that the marginal benefits of deploying more (of the same) technology does not outweigh the marginal costs. For example, patching once a day instead of once a month might be much more expensive than the costs that are averted by it. If that hypothesis is proven to be true, patching once per month instead of once per day would be a colossal waste of resources. The costs would not outweight the benefits.

In an ideal risk-assessment scenario, sufficient data is available to estimate such a risk (defined as: likelihood ∙ impact) before a decision must be made, rather than in hindsight after a solution has been implemented.

Most organization lack the body of experience to be able to compute these risks at all, or at least in a way that is statistically significant enough to be usable. Most organizations are unwilling (or unable) to design and execute an experiment and draw conclusions based on the outcome of those experiments.

These two observations are the death-blow for a formal risk management approach to information security.

Until sufficient reliable data becomes available (at reasonable costs), organizations will never be able to build their information security programs based on a formal risk management approach.

When such data does become available (and it is starting to), the IT security landscape will change. Until then, risk management will be predominantly something we talk about, rather than practice.

CISM

2008-10-31T23:28:57Z

Back in July, I blogged that I had passed my CISM exam. Today I was pleasantly surprised that all the paperwork had cleared and that I am now officially certified.

Dear Dr. Kees Leune, CISM,CISSP

Congratulations! We are pleased to inform you that on 31 October 2008 the CISM Certification Board approved your application and awarded you the Certified Information Security Manager (CISM) designation.

What's next? We'll see. It's probably time for something more technical. Maybe a SANS class, or maybe something more off-beat, such as the training programs offered by Offensive Security. For the time being, I think I'll just ride the flow a bit and see what comes my way.

Tips for getting started in information security

2008-10-30T01:27:40Z

I regularly get questions of students who expect to graduate soon asking what they need to do to get started in the information security field. Unfortunately, I cannot give a straight unambiguous answer to that. What I can do is start a thought process for that student. In the end, they will have to do the work.
Become experienced
Get a job that sounds like it is relevant to security. It does not actually have to be dead-on, but when a potential employer reads your resume, she must feel some sort of connect. Unfortunately, most security jobs ask for experience, so that is exactly what you need to get.

Most likely, the easiest way to do so is to find a job for a large consultancy organization and make it clear to them that you are willing to work hard, travel when necessary, and add value to their organization. At the same time, don't let your employer ever doubt that you are going to become an information security specialist.

Focus
Information security professionals are service providers and you need to figure out if you want to become a consultant that comes in to do a job, or if you want to work for the organization that uses your services. Make up your mind if you want to become a product specialist. Early in your career, consulting is not a bad way to go, since that will expose you to different industries, different problems and different working cultures.

Deciding if you want to work in a specific industry, or in a particular geographic area is also part of making the focus decisions. I know people who decided very early on that they wanted to work for a specific organization and they had their career plan centered around that goal. The same is true for geographical areas. If you decide that you want to work in the New York City, you will probably end up in the financial services industry or in fashion. If you are on Long Island, start learning about medical services. Other areas have similar industry focuses.

Specialize
Think hard about the area in which you want to specialize and work towards that. Depending on the direction in which you want to move, you will need to spend just about every waking hour doing "stuff" with security.

If you chose your direction to be penetration testing, find a pentesting job. When you come home, start doing stuff in your own lab. If you want to become an incident responder, look in that area and start dabbling with forensics-type stuff on your own time. If you want to become an information security manager, try to get some leadership experience. If you want to become an application security specialist, start coding.

Certify
There is much discussion surrounding the actual value of a security certification, but the basic fact is that employers will look for something that can distinguish you from the rest. Not having a certification is definitely a distinguishing factor, but it may not be what you want.

When choosing your certifications, keep your specialization goals in mind. It is useless (and may even work against you) to pursue vendor-specific certifications if you want to do something with a broader scope. The opposite is also true-- striving to pursue a general certification when you want to be a niche specialist is also pointless.

Branding
Make yourself visible: become a member of security organizations and go to chapter meetings. Attend as many events as you can, even if they are not in your focus area. At worst, you will spend an afternoon thinking about why the topic is not relevant to you (also valuable), and at best you meet your next employer.

If there are no chapters, start one. If you can afford it, begin visiting security conventions and conferences, reading (and comment on) blogs, maybe even start your own blog, join dedicated chat rooms and online forums, jump on twitter, linkedin, etc. Set up your own web site; don't be afraid to oversell yourself, but never lie. As an information security professional, your personal reputation and credibility is everything. The information security field is young, highly dynamic and the good people in the field form a close community. Associate with the right people.

Plan
Finally, come up with a career plan. That plan will be perfect nor complete when you make it first, but continue to update it as your expectations of the future take on more concrete form. Write down that plan on paper (not just as a file on a computer-- paper is more convincing!)

No employer expects that you spend your entire working life with them, but job-hopping every few months will come back to bite you. It creates the impression that you are not reliable, because you are not going to be around long enough to invest in. Plan to stay in a position for at least a year.

Coding a buffer overflow exploit in a deliberatly vulnerable application

2008-10-28T02:07:22Z

I've been trying to get some very simple buffer overflow code proof-of-concept to run for quite a while. While I always thought I had a good understanding of what a buffer overflow is, and how it can lead to Badness, I was actually never able to recreate a deliberately vulnerable application and exploit it.

The problem that I kept on running into was that I was unable to point the instruction pointer to a point in my NOP-sled that would be correct the next time that the code was invoked.

Well, as it turns out, the problem wasn't with my code, or with my exploit, but in the Linux kernel that I used. After spending an insane amount of time trying to Google up why it didn't work, I finally found that I was missing one simple step:

# sysctl -w kernel.randomize_va_space=0

As it turns out, 2.6 Linux kernels randomize the address space of new processes when this option is set to '1', which is exactly the problem that I had. This makes a great deal of sense, since there is really no need to NOT do this. Adding that kind of randomization makes buffer overflows much harder to pull off.

Another option that is useful to know about when you want do demonstrate buffer overflows is --no-stack-protector option on gcc. Without that option, gcc adds a guard variable to functions with vulnerable object which adds extra code to check for buffer overflows, such as stack smashing attacks.

These two bits of knowledge finally helped me connect the dots and allowed me to finish up my demo code.

Red Flag Compliance postponed for FTC-covered entities

2008-10-22T19:25:03Z

While listening to an Educause webcast on Red Flag Compliance, the FTC announced that it would not be enforcing compliance on the Red Flag Legislation until May 1, 2009. That is a major relief and takes a lot of pressure off the remainder of this months. In the mean while, check the FTC site for the formal announcement.

Taking up research again?

2008-10-20T17:15:49Z

After having completed my PhD-research, I have been mostly out-of-touch with what is happening on the academic side of life. Consulting and "doing things" have been very enjoyable and I do not regret for a second that I stopped being a researcher.

However, since I am teaching at a college again, I have also been starting to feel the itch of doing research, (co)authoring and --hopefully-- publishing papers.

Once disconnected from academia, it is very hard to get back into, and I expect to spending several months reading up and figuring out where the scientific tide has taken the community.

Yet, before I set sail and try to make an serious effort at getting back into doing research, I need to decide what topics are currently worth while investigating, and which appeal to me.

So, having said this, please let me know! Comment to this post, contact me, or send me an email message. I look forward to hearing from you!

Security 504: SANS Hacker Techniques, Exploits and Incident Handling

2008-10-20T16:59:51Z

Dear Security Professional, SANS is bringing Security 504: SANS Hacker Techniques, Exploits and Incident Handling to your local community in out popular Mentor hands-on format! Beginning on January 7, SANS Mentor Kees Leune will be leading this class in Garden City, New York. For complete course details, please click on http://www.sans.org/info/34049. Before registering, please contact me for some referral information! SANS END OF YEAR APPLE GIFT CARD PROMOTION: For a limited time SANS is offering a $200 Apple gift card for registering and paying for this class prior to December 31. Looking to try the new iPhone? Here is your chance! Simply enter the word "Apple" in the comments box on the second registration screen and make payment by December 31 to receive a $200 Apple gift card. Why Choose the Mentor Program? The Mentor Program, http://www.sans.org/info/34054, consists of small, locally run, 10 week classes utilizing the same great SANS courseware presented at the larger conferences. This unique program opens SANS training up to students with family or work commitments necessitating a more flexible option. Mentored students report several major benefits of this format including: cost savings, time to digest the material, convenient evening classes, small groups, a Mentor "coach", and community networking. COST SAVINGS: Is the slowing economy resulting in reduced training budgets? With the SANS Mentor program, you save 25% off the regular SANS tuition fee with the ability to save even more with group discounts (see below). No need to spend money on travel and living expenses or spend a week away from the family. PACED STUDY: Take 10 weeks to work through and understand the material. Past students report that the slower pace allows them to absorb and apply the information. Each session provides you the opportunity to apply the materials the next day when you return to the office! EVENING CLASSES: The Mentor program provides a method for learning the SANS materials and working towards a GIAC certification without taking time off from work. COMMUNITY NETWORKING: The Mentor program allows you to work with local security professionals in an open discussion format. This community networking has been identified by students as a major benefit of the Mentor program. One recent Mentor student commented, "I thought that the class was great. I would consider taking another SANS Mentor Program class. It was much more convenient than traveling and I had the ability to review material at my own pace." Clint Barnett - Computer & Information Security Forensics Examiner A SANS Institute course delivered locally in Garden City, New York, by an experienced SANS Mentor who will lead you over a comfortable and convenient schedule, saving you money, while giving you the opportunity to network with local security professionals. What a great combination!! Plus SANS promises you will be able to use what you learn in the classroom as soon as you return to the office. TUITION DISCOUNTS! SANS offers group registration discounts for 2 or more students who register from the same organization. To obtain the Group Discount fee and Registration Code offered for this course, contact Miranda Ruddick at mentor@sans.org PRIOR to registering, and provide the names and e-mail addresses of all the students registering within your organization. Does this sound like the kind of training that would help you be more effective in your job? Then register today at http://www.sans.org/info/34049 and see for yourself the excellent value of SANS training and GIAC certification! If you have any questions about this course offering, please contact mentor@sans.org. ******************************************************************** SANS is pleased to announce our new Training and Events Calendar - an easy way to see what opportunities are available to you during the coming month! The current calendars are now available for download from http://www.sans.org/info/1372. To change your subscription, address, or other information, visit http://portal.sans.org. If you wish to have your name removed from our mailing list, visit the site above, click on "update your account" and check the box "Do not send any email.

Reconnaissance: don't post what you don't want found

2008-10-14T19:23:11Z

This week's topic of the computer security class that I teach was reconnaissance. The amount of information that is "out there", available for an attacker who wants to build a profile of his target is overwhelming. The things that we discussed today weren't very advanced or outlandish, but they were generally knew to my students (undergrads). Here are some take-homes:

Don't underestimate the amount of intel that can be found on social networking sites, such as LinkedIn, Facebook, Myspace, Twitter. It will be almost impossible to control what gets posted, so make sure that you know what information is there. Search for your organization and for your key employees and see what information is posted. Be aware of what others can find out about you as a target and act accordingly.
Be creative with search engines; check Johnny Long's Google Hacking Database. While you are there, order a copy of his book and support charity. Play around with the Goolag scanner to figure out what you can find.
Maltego is awesome; use it, play with it, and learn from using it.
Don't list anything in whois records that you do not have to. Do not list names, email addresses, titles, street addresses, etc. if you do not absolutely have to. Instead of a real name, list a job function. Instead of an individual's email address, list a functional email address. If you do list an individual's email address, make sure that the first part of the email address isn't also the user's login. List a P.O. Box, rather than a physical address. Real names and email addresses can be used for social engineering, physical addresses can be used for site visits (for example, to search for WiFi bleeding)
Use split DNS and do not allow zone transfers.
Most of all, abide by the adagio: don't post online what you don't want to be found

Apocalyptic Vulnerability Percentages - FUD 101

2008-10-12T23:54:55Z

While reading RSnake's latest post, I cannot escape the feeling that he's in a very gloomy mood today. His advice:

"The truth is, if you have something interactive connected to the Internet, it's probably exploitable in some way, and really, it's not that terrible of a thought considering it's pretty much always been that way."

As gloomy as that may sound, it is something that I run into regularly.

Too many people assume that the next new (web) app that is getting deployed 1) is absolutely essential for the continuity of the company and 2) must run on an internet-facing web server.

Air-gapping a system is probably not that feasible in this day and age (although I still see self-contained networks with only a dial-out modem that gets unplugged when not in use), but using common sense when deciding on the visibility of a system can never hurt!