Archive for the ‘2-alert’ category

Breaking Out Of A sudo Shell

August 18th, 2009

I’ve been meaning to write this up for a while, but had a post go by on one of the SecurityFocus mailing lists that motivated me to get it done. The post asked, “How do you restrict sudo so a user can not delete the whole hard drive?”. The short answer is, it is extremely difficult.

Sudo is a security tool used within the UNIX and Linux world. It permits the Administrator to restrict access to high-level commands. It differs from the su command in that su immediately gives the user root level access. Sudo permits the Administrator to fine-tune which root commands can actually be accessed. In addition, sudo creates an audit trail of all executed commands.

The problem with sudo is that it has no visibility when a tool permits a command shell to be spawned. This means a user can misbehave on the system while generating an audit trail, which makes it appear they have done nothing wrong.

Try it yourself

I’m going to walk you through an example so you can experience exactly what I mean. You will need a Linux system for this. If you don’t have one handy, Backtrack should work just fine. The test system I’m using is based on Fedora but they are pretty similar.

Step #1: Add yourself to the users group

Use your favorite text editor to edit the /etc/group file. Look for the “users” group and add your account name. In this example I’ve added the account name “cbrenton”.

users:x:100:cbrenton

Step #2: Create a sudousers entry

Next we need to edit the /etc/sudoers file to define what the users group is permitted to do. We need to use visudo for this, which is a text editor based on the vi editor. If you are comfortable with vi, type in the command “visudo” and add this line to the end of the file:

%users ALL=/usr/bin/less

If you do not know vi, I’ll give you the exact commands. Remember everything is case sensitive:

visudo

G

o <– lower case letter O

%users ALL=/usr/bin/less

<Esc><Esc>

:wq

Step 3: Monitor sudo activity

Open a second terminal window and use “su -” to assume root privileges. Type in the command:

tail -f /var/log/secure

This will permit us to monitor all sudo activity.

Step 4: Run a sudo command

Back in the first terminal window type in the command:

sudo less /etc/hosts

You will be prompted for your password (your password, not root’s password). Once you type in your password you should see the contents of the /etc/hosts file. In the second terminal window you should now have a log entry similar to the following:

Aug 18 16:07:58 fubar sudo: cbrenton : TTY=pts/4 ; PWD=/home/cbrenton ;USER=root ; COMMAND=/usr/bin/less /etc/hosts

So we can see date/time, who executed the command, which terminal they were on, what directory they were in, what permissions level they were using, and what command they executed including any command line switches (in this case a file specification). So far, so good.

Step 5: Bust a shell

In the first terminal window (running the less command) type in:

! <Enter>

You should now be looking at a root command prompt. To verify you are in fact root, type in the command:

whoami

Note that typing in the command “whoami” did not generate a security log entry. In other words, once we spawned a command shell with the less command, we can do anything we want and sudo will not log it.

Step 6: Additional verification

In the first terminal window where “less” is in the background, type in the command:

top

This will print out statistics about the running system.

In the second terminal window note the terminal in use. In the above example log entry the terminal is “TTY=pts/4″ but yours might be different. Make a note of the terminal. Now, in this second window press:

<CTRL>-C

to kill the tail command. Now run the command:

ps ax | grep ‘pts/4′

Replacing “pts/4″ with whatever terminal name you noted. You should receive output similar to the following:

17330 pts/4    Ss     0:00 bash

18392 pts/4    S      0:00 less /etc/hosts

18410 pts/4    S      0:00 /bin/bash

18432 pts/4    S+     0:00 top

This tells us that we have two shells running on that terminal. The first is looking at the hosts file while the second is running the top command. So the system does actually see that we are playing around within the second shell, its just that sudo can not log it.

Some other root level commands you can try that will not harm anything:

iptables -L

ifconfig

lsof -i

When you are convinced you have full root access, go back and check the log to verify that sudo has not logged anything:

tail /var/log/secure

When you are done with the shell in the first terminal window, type in:

exit

q

What have we learned?

We’ve learned that we cannot permit users to have full sudo access to the system and actually maintain an audit trail of what they do. Access has to be restricted to tools that do not support invoking a shell. If we are unsure, its a simple matter of checking the man pages. Try this:

man less

/

shell

The command “man less” brings up the manual for using the “less” command. Pressing the backslash key brings up the search function. When we type in the word “shell” and press the enter key, man jumps to the first instance of the string “shell” and highlights every instance. Note the section man jumped to discribes how less can invoke a shell. Now we know we cannot permit sudo access to the command “less”. A better option may be the command “cat” which does not support invoking a shell.

Another possibility is to simply use a different tool. For example the tool op was specifically designed to address some of the security shortcomings in sudo, including the ability to control shell access.

Exec Summary

Sudo is a great security tool provided you use it wisely. One of the most common mistakes made with sudo is using it to permit access to all root level tools. Sudo can generate an effective audit trail, but only if it is limited to tools which do not have shell capability.

No comments »

Posted in 2-alert, Linux Security

Tags: audit trail Linux Security shell breakout sudo

Top 5 Firewall Threats – Part 2

August 3rd, 2009

In the last post I started counting down the five greatest threats to perimeter security. In this post I’ll complete the list.

Firewall Threat #3: Outbound HTTP

The popularity of HTTP (TCP/80) has become both a blessing and a tragedy. Certainly the Internet would not be as popular as it is today without the World Wide Web. While HTTP has lead to the greatest exchange of information in mankind’s history, our implementation of the service has caused it to become one of our greatest security problems on the Internet.

Why is it a threat?

The first issue is that TCP/80 access has become so commonplace; many firewall administrators have chosen to ignore it. An overwhelming majority of the networks I have audited permit outbound TCP/80 access but then never log its use. When I ask why the permitted traffic pattern is not being logged, the standard answer I receive is “it makes my firewall logs too big”. Hummm, didn’t realize the perimeter security mantra was “no fatties”.

Permitted traffic is inherently a higher risk than denied traffic because it facilitates the exchange of information. That passing traffic could be a zombie calling home or an internal system leaking sensitive data. If we do not log the use of a permitted protocol, we are completely blind to its abuse. The problem “how do I process large log files?” is much easier to solve than “how do I spot evil traffic when I’m not bothering to look for it?”.

Since HTTP has become a “turn it on and forget it” service, vendors and attackers alike have started running everything through this port. The brainchild at Microsoft who thought tunneling RPC through DCOM though HTTP was a good idea obviously had zero concern for how we would actually secure the implementation. While IRC used to be the protocol of choice for call home Malware, it is now HTTP because attackers can usually count on that port being wide open and unlogged.

How to prevent it

All permitted traffic patterns need to be logged. This includes outbound HTTP traffic traveling from the internal network to the Internet. In a later post I’ll tackle the problem of processing firewall log files so it is relatively easy to pull out the interesting bits.

Firewall threat #2: Banner grabbing

Most Internet based servers will happily identify themselves to connecting clients. For example whenever you connect to this hosted server, your browser sees:

Server: Apache/2.2.11 (Unix) mod_ssl/2.2.11 OpenSSL/0.9.8k DAV/2 mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635

While this information can be useful for troubleshooting, it can also be extremely useful for someone wanting to attack the system.

Why is it a threat?

Consider the following analogy: You are playing Five Card Draw against a number of opponents. Your opponent’s cards are well hidden in their hands, while your cards are laid out on the table for all to see. What are your chances of walking away the big winner at the end of the night?

Displaying version banners to connecting clients puts you in a similar position. If an attacker can see what software you are running along with the specific version, they can immediately determine if you are vulnerable to any of the attacks in their arsenal. So by displaying a software banner you’ve effectively helped the attacker get it right on the first try.

Without the benefit of the banner, the attacker would be forced to try each of their attacks in order to see if they will work. If we are vulnerable, we’re still going to get whacked. If we’re not, we’ve just forced the attacker to start generating log entries that will clue us in that the source IP is hostile. In other words, we’ve called their bluff so we now get to see their losing cards. This gives us an audit history and time to respond accordingly.

How to prevent it

Change the banners on any Internet facing services. This includes Web, FTP, name servers, mail servers, or any other service that can be reached from the Internet. Do not forget to restart the service after you make the change.

How easy or hard this is depends on the vendor. For example to fix this problem with the Apache Web server we would simply edit the “httpd.conf” file and change the “ServerTokens” parameter to be “Prod”. With IIS however, we do not have this type of flexibility. Microsoft does not let you change the banner to help insure they can properly identify their current market share. Your only real option is to put a reverse proxy in front of the Web server and leverage the proxy to scrub the banner.

Can changing the banner cause problems?

Most vulnerability scanners are primarily banner grabbing devices. For example when you run a vulnerability scanner against your mail server, it does not try every attack pattern its been programmed to test. Rather, it will grab the server’s banner and check it against a built in database. If the reported software version has known vulnerabilities, they get printed to a report. If you have ever run a vulnerability scan which claims to check for thousands of known attacks, but your IDS barely notices the scan, this is why.

Now with that said, not all checks are banner based. For example reading the banner will not tell the vulnerability scanner whether your mail server can be used as a spam relay. The scanner has to specifically test for that condition. So some exploits do need to be tested directly. Simply reading the banner however can satisfy a majority of the verification testing.

So, changing the banners not only makes it more difficult for attackers to assess your vulnerabilities, but it makes it more difficult for you to do so as well. You may be forced to drop to the command line to verify the version of software you are running. Luckily most software supports a “-v” or “-V” option which will print out it’s version information. Sometimes a different switch value is used so we will need to do a bit of research in the application’s help files. For example to get version information for Sendmail we would type:

[root@fubar ~]# sendmail -d0.1

Version 8.14.3

Compiled with: DNSMAP HESIOD HES_GETMAILHOST LDAPMAP LOG MAP_REGEX

MATCHGECOS MILTER MIME7TO8 MIME8TO7 NAMED_BIND NETINET NETINET6

NETUNIX NEWDB NIS PIPELINING SASLv2 SCANF SOCKETMAP STARTTLS

TCPWRAPPERS USERDB USE_LDAP_INIT

Firewall threat #1: Non-signature Malware

I’ve written extensively on the problems with detecting Malware. Feel free to use the search option on this site to pull up earlier posts for more info.

The bottom line is we try very hard to solve this problem at the perimeter by leveraging Unified Threat Management (UTM), firewall plug-ins, anti-virus proxies, etc. These solutions will never be 100% effective. In fact, their effectiveness has been declining sharply over the last few years. If you truly want to get a handle on modern day Malware threats you have to look at an application control solution.

Exec Summary

So the top five firewall threats are:

Non-signature Malware
Leaking banner info
Outbound HTTP
Outbound SSH
Commercial VPN services

Note that the last four of the five are outbound traffic patterns. While we tend to focus heavily on what is trying to get in to our network, we also tend to blindly trust the traffic leaving it. Its this misplaced confidence that has lead to each of these items making it to our list.

No comments »

Posted in 2-alert, Network Security

Tags: attack mitigation firewall perimeter security

Top 5 Firewall Threats – Part 1

August 1st, 2009

I spend a bit of time in the field consulting. Over the last few years I’ve noticed a trend with new clients whereby I can usually (about 7 out of 10 times) identify “something” leaking out through the client’s perimeter that they were unaware of. I thought I would compile a list of the top 5 so folks could sanity check their own security.

Firewall Threat #5: Commercial VPN services

It amazes me how often employees will do an end run around perimeter security and setup their own VPN solution. I even see this on networks that already have an existing VPN solution in place. Could be the end user thinks the corporate solution is too restrictive. Could be they simply want to be able to extract info without going through the corporate content checking solution. Unfortunately there are a number of third party companies that are more than happy to sell VPN services that will circumvent the average firewall policy.

How does it work?

There are a number of VPN service vendors, but the most popular is GoToMyPC (now owned by Citrix), so I will talk about that service specifically. Implementation for the end user is pretty straightforward:

Create an account and pay the $20/month fee
Load agent software on their system at work
Go home and launch their Web browser

The user can then logon to their work system and control their desktop remotely. They can even transfer file information by dragging files in or out of the session window.

Why are third party VPN services a problem?

Third party VPN services allow your end users to create an encrypted tunnel between their work system and systems on the Internet. If you have implemented some form of Data Leak Prevention (DLP) or content checking on the perimeter to control the flow of company private information, they will be defeated by a third party VPN. This means your end users could be transferring anything out of your network. Not only do you have no control of what info passes through the VPN tunnel, these services try very hard to look like normal traffic so you may not even know this is happening on your network.

Under the hood

Figure #1 shows how a third party VPN solution can work. Note that session establishment originates from the work system, not from a system on the Internet. So as far as the firewall is concerned this is an outbound session. Further, many of these services use TCP/443 to communicate and SSL to secure the session. So from the firewall this looks like normal HTTPS traffic. Most admins do not log outbound HTTPS, so there may not be any log entries to review.

How to prevent it

There are a number of possible solutions to curb this activity:

1) Review outbound firewall logs

Specifically, you want to look at outbound traffic taking place after hours. Filter out patching sites (Microsoft, Adobe, etc.), A/V signature updates, or any other expected pattern. Everything else should be scrutinized. Pay close attention to repeated connection attempts to the same host or subnet at a predictable interval (say every 20-60 seconds).

2) Desktop enforcement

Leverage application control or a similar technology to control which applications your users can install on their desktop. While this option may seem to be the most cumbersome, its also the only one that will work most consistently.

3) Block the IP addresses of known VPN services

While this option will work, it requires research to find out which IPs you should ban. Also, the list is going to change as new vendors come on the scene or IPs get moved around. For these reasons its my least favorite option.

Firewall Threat #4: Secure Shell (SSH)

It pains me to put SSH on this list, as over the years I’ve found it to be one of my most useful tools. Unfortunately SSH can be your worst nightmare when its in the hands of your end users.

How does it work?

Most people know you can use SSH as a secure replacement for Telnet. What is not as well known is that SSH can be used to tunnel TCP traffic. This can be implemented as either a forward tunnel, or a reverse tunnel.

SSH forward tunnels

When a user creates an SSH forward tunnel, the SSH client will open up which ever TCP port is specified by the user. Further, the user can instruct the remote SSH server where to send any traffic sent to this local port.

An example is shown in Figure #2. Let’s say that all outbound Web traffic is sent through a content checking system. The firewall checks outbound HTTP to ensure that only appropriate sites are accessed and that certain keywords are not permitted through. Let’s further assume that we have an internal user who wishes to access inappropriate sites.

Here’s what the end user would do. On their home system they would run a proxy server as well as an SSH server. From their office system they would run an SSH client in order to connect to their SSH server and request a forward tunnel. They would tell the SSH client to open a local port (say 8080) and tell the SSH server to forward all of this traffic to the local proxy server. Now all they need to do is tell their Web browser to use the proxy server located at Localhost, port 8080.

Voila! When they launch their Web browser it will connect to TCP/8080 on the local system. This traffic is then sent down the encrypted tunnel to the SSH server, and then on to the proxy. The proxy server will then connect to what ever site on the Internet the user specified. The firewall can not content check the passing data or control which sites get accessed, because the datastream is encrypted. Our perimeter security has been circumvented.

By the way, the user does not have to limit access to only their personal system. Its possible to tell the SSH client to service connections for other hosts on the wire as well. I remember an on-site I once performed where my porn signatures were triggering on the internal network but not at the perimeter. Turned out one of the engineers had done the above and opened up access to their buddies. So when another engineer connected to his system, the porn content was visible. When it left his system and went to the Internet, it was now encrypted and protected from detection.

SSH reverse tunnels

SSH reverse tunnels are similar to SSH forward tunnels, but are designed to handle data requests headed in the other direction. This is shown in Figure #3. Let’s say we have an internal server which is only accessible to internal employees. In other words, the firewall does not permit inbound connection requests from the Internet to be forwarded to the server. In fact there may not even be any one-to-one NAT or port forwarding in place for folks on the Internet to even try and access the server. Let’s further assume that we have an end user who wishes to expose this server to the Internet.

This time the user only needs the SSH server on their home system. From their office system, they launch an SSH session out to their server and request a reverse tunnel. With a reverse tunnel the user tells the SSH server to listen on some local TCP port (say TCP/80) and send any inbound connection requests to the SSH client. The user then tells the SSH client to forward these connection attempts to a specific port at a specific IP address (say TCP/80 on an internal HR Web sever).

Once this connection is complete, anyone connecting to TCP/80 on the users home system will be forwarded to TCP/80 on the internal HR Web sever. The firewall can not control the session because it looks like outbound traffic and all the data is encrypted. In fact you can’t even detect this activity on the HR Web server as all connection requests will be logged as originating from the user’s internal desktop system (the one running the SSH client).

How to prevent it

Take control of all outbound SSH activity. Block TCP/22 outbound and only permit it through when its verified the traffic meets corporate policy. SSH can be configured to listen on any TCP port, so we have to be able to spot non-standard port use as well. Leverage a NIDS or NIPS signature that checks the first three incoming TCP reply packets for an SSH server banner. This should be done on all TCP ports except 22. The banner will contain the string “SSH-1” or “SSH-2”. While its possible to hack the client and server software to change the banners, most end users do not have necessary skills to modify the software and still have it remain functional.

That’s enough for this post. In the next I’ll include the last three threats.

2 comments »

Posted in 2-alert, Network Security

Tags: attack mitigation firewall perimeter security

Stateful inspection firewalls Vs. NIPS

July 20th, 2009

Yesterday I wrote about “What makes a system vulnerable?” and had someone call me on this comment here:

Both NIPS and UTM firewalls are based on the same underlying technology (stateful inspection) so the same problems arise here as well.

The individual was confused as they thought these were two distinctively different technologies.

I’m sure at some point in your life you’ve heard the phrases “Don’t judge a book by its cover” or “A rose by any other name would still be a rose”. Both are directly applicable here. Let’s look under the hood to see what we mean.

A stateful inspection firewall is a pattern matching device which has the ability to match on pre-defined patterns in both the header and payload of passing packets (sort of like what Anti-Virus does when checking files). Typically these are IP packets, although its possible to do it with IPX, NETBEUI, etc. as well.

What distinguishes stateful inspection from stateful packet filtering is the ability to analyze the payload. Stateful packet filtering can only analyze header information. You may have head the term “deep packet inspection”. This is vaporware created by one or more marketing people who have probably watched too many porn videos. Once you are inspecting the payload there is nowhere deeper to go in the packet, except maybe the Ethernet CRC check which would provide zero security value from Internet based attacks.

A Network Based Intrusion Detection System (NIPS) also leverages stateful inspection to pattern match on passing packets. Typically it uses a number of signatures, or pre-defined patterns the device has been programmed to for, in order to flag and screen out known malicious patterns. Both the header and payload of IP packets can be screened for these known patterns. So NIPS pattern matches on the header and payload, just like a stateful inspection firewall.

Consider the following products:

Check Point UTM-1 or Power-1
TippingPoint (3COM) 10 or Core Controller

While Check Point is considered to be the classic firewall and TippingPoint represents the cool new NIPS technology, both offer similar features for screening out known malicious patterns on the wire. In fact both offer subscription services for keeping these signatures up to date. Check Point calls it “SmartDefense” while TippingPoint calls it “Digital Vaccine”. So both product lines are levering stateful inspection to check headers and payload (although the TippingPoint product does not seem to maintain state as often as Check Point, but that’s a topic for another post ).

So if its the same underlying technology, why don’t we simply call NIPSs stateful inspection firewalls? This was one of the best marketing slicks I’ve ever seen in the security industry. Think of it this way, pretend you are the security manager for your company (or maybe you already are, in which case you don’t have to pretend that hard ), I’m a sales person who walks into your office and says:

“Hi, I have this great new stateful inspection firewall I want to sell you”

What is your reply going to be? Probably something like:

“No thank you. I already have one I’m happy with”.

Now, I walk in and say:

“I have this spiffy new network based intrusion prevention system I want to sell you”

Now the response is more along the lines of:

“Wow! I don’t have that yet. Can I buy two?”

You get the idea. By changing the name we make it sound like its a new bleeding edge “must have” technology, which makes it easier for the sales people to generate a commission. When it comes to what happens on the wire however, its just a repackaged familiar tool.

Hope this clarifies the topic!

No comments »

Posted in 2-alert, Network Security

Tags: firewall NIPS signature detection stateful inspection

What does the little lock icon mean in my browser? – Part 3

July 17th, 2009

In the first two parts of this post, I described what goes on when creating an HTTPS connection to a Web server. In this third and final part I’ll get into what can go wrong.

What can go wrong if I trust the rabbit hole?

For the sake of argument let’s assume we “feel” the HTTPS process is trustworthy all the way down to the bottom of the rabbit hole. Our first problem is we never actually go there. Check out Figure #1. This shows some of the configurable options for Internet Explorer 8. Note the two circled lines.

The first one, “Check for Publisher’s certificate revocation” attempts to validate the locally stored digital certificate. Its on by default, but all its really doing is checking to see if the trusted third party has identified their signing server as being compromised. If they have not figured it out yet, or if an attacker is able to compromise this session, all bets are off. In other words, in part 2 I described a path all the way down the rabbit hole to a self signed digital certificate. What this option is tells us is that we are never going to check down that far. We’ll do a quick check one level deep and stop there.

Now, look at the second line which is circled, “Check for server certificate revocation”. Note this option is turned off by default. So while you could be checking to see if the Web server your talking to had it’s digital certificate revoked, you don’t bother because of an options setting. The concept is “Hey you can trust Verisign because they never mess up”. In part 2 we also discussed how this is not always the case.

Does SSL and TLS always encrypt my data?

As mentioned in part 1 of this post, SSL and TLS are a framework. They pull together a lot of possibilities for securing your data but leave the particulars to the negotiation between the client and the server. Consider the picture shown in Figure #2. These are the SSL and TLS options for a Firefox Web browser. Note the lines within the red box.

Firefox let's you select which privacy options to support

The first option says “Use RSA for initial authentication and HMAC-MD5 to authenticate each packet”. The second option says the same thing, but to use HMAC-SHA for packet level authentication. Notice anything missing? Like… how should we be encrypting the data? Both of these options specify authentication without any kind of encryption.

Why is this even a possibility? Because sometimes its enough to know your datastream can not be changed in transit. You might not be worried about people seeing the data or it may be possible that you are located in a country which does not let you encrypt your information. If either is the case, SSL and TLS can still help you out.

Now, remember back to part 1 of this post I said that in an SSL/TLS handshake we go with the highest level of data privacy supported by both ends of the connection. With this in mind, you hopefully will never see “no encryption” negotiated in the wild. If however this is all the remote server wants to support we may be in trouble. Luckily Firefox has both of these options disabled by default. But what about other browsers? That’s the kicker. Most browsers will let you select the version of SSL and/or TLS you want to support. They will not let you drill down to specific protocols. So this could be on and you would never even know it.

And now back to that little lock icon

I have a love/hate relationship with the little lock icon. I like the idea of making it simple for users to figure out when their data is being secured. I hate the idea that the accepted implementation is a little graphic that it very easy to duplicate. For example, have a look at Figure #3. Note the bank has placed a copy of the lock icon right on the logon page. Does this really tell us the data is being secured? Absolutely not! It could just as easily be a picture of a cute kitty cat. In this context the lock icon is nothing more than a display graphic.

Note the lock icon within the HTML page

OK, so let’s look around our browser window a bit. In older browsers I got used to seeing the lock icon at the bottom right of the screen. Hey look at figure 3 again, there’s a lock icon at the bottom right of the window! So that tells us our data is secure, right? Nope. In IE8 Microsoft changed the browser layout. That specific lock icon will tell me if the browser is filtering content coming from the Web site. So a user who does not do their homework will probably think every site on the Internet has been secured. Why didn’t they use another graphic to avoid this confusion???

Look to the right of the URL. Hey, there’s the lock icon! Yup, so this is where the user is suppose to look. There is just one problem however. If you are reading this post directly from my site you will notice you also have a lock icon to the left of the URL. All I did was mess with favicon. So by drawing the users eye to the URL to look for the lock icon we just made it easier to fool people into thinking their data is secure when its really not. Will the typical end user notice/care that the lock icon is before or after the URL? Yuck.

So where are we at

To summarize what has been discussed so far:

Liberal use of the lock icon can fool users into thinking their data is secure
Our security protocols support transmission of data without encryption
Digital certificates have a server at the bottom of the rabbit hole saying “trust me because I say its OK. Here, have some candy little geek” (OK, the candy bit is not part of the spec )
The rabbit hole really is not a problem because we never look all the way down it anyway
We have security checks we choose not to use
We produce error screens that end users have become accustom to ignoring
If an attacker can break initial authentication, the integrity of the whole session falls apart
Security experts keep figuring out how to forge certificates and are finding new exploits all the time

Sanity check time

OK, so its easy to feel like the whole thing is insecure and we should run away to Vermont and build a moat around our house (inside joke, I know someone who has done this). Here’s some simple advice for the non-cipher- wienies that will help keep you relatively secure on the Internet. If you want full protection, disconnect now and build your own moat.

1) Look for HTTPS in the URL

Forget about lock icons and other fancy stuff. If you see “HTTPS” instead of “HTTP” then you know you are using SSL or TLS to secure the datastream. Remember this does not guarantee data privacy, so we still have more to do.

2) When in doubt, check the connection

Take a look at Figure #4. When I connected to this site and saw “HTTPS” I double clicked on the lock icon. That produced this dialog box. There is some real useful information here, like what level of encryption is being used to provide data privacy. This will tell me if my data is “safe” (encrypted).

Double click the lock icon during an HTTPS session to produce this screen

This will also identify who issued the digital certificate. Remember the bottom of the rabbit hole is warm fuzzy. This means you really have to ask yourself if you think the issuing company has a clue about security, because you have little ability to check for yourself. Personally I never trust a server or company that signs their own certificates (this means you American Express!) because your options for verification are even more limited. They are just begging to get their client’s data compromised in order to save a few $$$ by not purchasing a certificate from a well known authority (note: Its OK to sign your own certs if you manage both ends of the connection, but this is not the case when we visit an e-commerce site).

3) Tweak your browser options

Finally, leverage what ever options your browser gives you to lock down your HTTPS sessions. I mentioned initial authentication comes down to a subjective judgment call, and the security of the rest of the session teeters on this point. If you sleep better verifying all certificates, go for it. If you feel comfortable just verifying with local info, that’s fine too (its your data after all). Yes SSL and TLS have some issues, but its the only game in town so do the best that you can with it.

4) Leverage your common sense

Last December I logged on to my bank site to pay some bills. When I was redirected to the payment server, I was presented with a self signed certificate. I’ve used this bank for years and know they use Verisign to sign their certificates. I immediately told my browser “no thank you”, and found out a day later the site had been hijacked.

The best way to keep your data safe is to use your head. If things do not look right, there is probably a reason why. While it can sometimes be hard to wrap your brain around the intricacies of technology, good old fashion street smarts can go a long way towards keeping you out of trouble.

That’s about it. Hope you found this info useful and don’t forget to tip your waiter!

1 comment »

Posted in 2-alert, VPN

Tags: best practice digital certificates HTTPS lock icon SSL TLS

What does the little lock icon mean in my browser? – Part 2

July 16th, 2009

In my last post I started talking about why your data might not be as secure as you think during an HTTPS session. We made it as far as the mandatory handshake requirements with SSL and TLS. In this post I’ll get into the optional features which is the start of where things can go wrong.

Optional portions of the SSL/TLS handshake

After the initial client/server exchange, the two end points are free to choose which options they feel are appropriate, depending on how the administrator has configured them. Next we could:

Client can check the authenticity of the server using local info
Client can go back to the trusted authority and check the certificates authenticity
Client can check the authenticity of the trusted authority’s issuing server
Client can send a copy of its digital certificate to the server
Server can validate the client’s digital certificate if it has one
Server can require the client to have a valid digital certificate

Wow! Lots of possibilities. We typically don’t implement the last three unless we have control of both ends of the connection (like with a VPN). For a secure connection to a Web server, we’re typically looking at just the first three possibilities.

How digital certificates work

First, let’s talk about those digital certificates. A digital certificate contains the public key for the entity described within the certificate. So the server is basically saying “This is who I am and here is my public key for asymmetrically encrypted communications”. The way you know you can trust this certificate is that it has been digitally signed by a mutually trusted third party, like Verisign. Specifically, its been signed using the private key of a certain server under Verisign’s control. The concept is you can use the public key of the Verisign server to check the signature created by its private key. If the hash validates, you know the digital certificate has not been messed with.

OK, here’s our first problem. The information we use to validate the web server’s certificate is actually a copy of the Verisign server’s digital certificate stored on the local system. Hummm. So if the client becomes compromised, we can fool it into thinking a bogus digital certificate is actually legitimate, right? Absolutely. However this would only be useful in specific situations. If I can compromise the client there are probably easier ways to get access to the information I’m looking for.

If we want to ensure we’re safe however, we can go with option #3 above and check the validity of the locally stored Verisign certificate. This would send us out to Verisign server #2 to get its digital certificate. If we want to insure that our copy of Verisign server #1′s digital certificate is OK, we can use Verisign server #2′s public key to check the hash. If the hash validates, we know the digital certificate for Verisign server #1 is valid.

Hummm. So how do I know an attacker didn’t mess with the transfer of Verisign server #2′s digital certificate? Because that has been digitally signed by Verisign server #3. Go get that server’s public key and check the hash. How do I know Verisign server #3′s cert has not been messed with? You guessed it. Go get the digital certificate from Verisign server #4. While this sounds pretty complex (and it is!) this gives us sound math we can work with. In other words, smart crypto people can look at this math and predict how safe it is to use. Cool. I’m a geek so trusting math is a natural. The problem however occurs at the bottom of the rabbit hole.

Why should I trust you?

Eventually we will run into what is called a self signed digital certificate. This is basically a server’s way of saying “trust me because I say so”. In other words, there is no math to calculate if we should trust this server or not. All we have is “warm and fuzzy”. In other words, we need to sit in a Buda pose, sign Kum Ba Yah, get in touch with our inner child, pointy up our ears, and ask ourselves “How do we feel?”. Really, that’s all we’ve got, and there is no wrong answer because its subjective. If we “feel” that final system is secure, then it is. If we “feel” it is insecure than it is. There is no math to help point us in one direction or the other.

What if the trusted third party messes up?

So you may be asking yourself “All that sounds great, but what if the trusted third party makes a mistake and gives a digital certificate to the wrong party?”. First of all, that could NEVER happen. Oh wait, it has happened. Seriously, this is a valid concern as the chances of catching this after the fact are minimal.

Its possible to “revoke” a digital certificate. This is a trusted third party’s way of saying “Oops, we screwed up. You really should not trust that digital certificate we said is trustworthy”. So the concept is, when you get the Web server’s digital certificate you can go back to the issuing server to see if its been revoked.

OK, that’s set the groundwork for our HTTP session. In the next installment we’ll talk about what can specifically go wrong if we trust the security of the rabbit hole.

1 comment »

Posted in 2-alert, VPN

Tags: digital certificates HTTPS SSL TLS

Test your network security skills

July 15th, 2009

As mentioned on the About page, I spend a bit of time teaching computer security via SANS as well as directly to clients. When people ask me if they would get anything out of taking my SANS course, I point them to this quick test. If you can score 12/15, you are in good shape. Less than that, and you need to cut the knowledge curve. I’ll put the answers in a different post so its less tempting to cheat.

Note: I’ve messed with the submission dates so the answers do not appear before the questions on the main page.

1) How many different techniques are available to sniff in a switched environment:

A) None. Switches block unicast traffic to all ports.
B) 2
C) 4
D) 6

2) You receive the ICMP packet shown below from a remote host. Which of the following is the most likely source of the packet?

A) Ping run on a Windows system.
B) Ping run on a Linux system.
C) hping using the “-C 8” option.
D) nmap using the “-sP” option.

15:52:50.129178 IP (tos 0×0, ttl 47, id 51389, offset 0, flags [none], proto: ICMP (1), length: 28) 1.2.3.4 > 172.30.2.10: ICMP echo request, id 18492, seq 21446

3) Which is the best way to discourage attackers from using your address space as part of a SYN flood attack?

A) Quietly drop all inbound SYN/ACK packets that are unsolicited.
B) Return an ICMP Admin Prohibited error packet for all inbound SYN/ACK traffic that is unsolicited.
C) Advertise all portions (even unused) of your IP address space via BGP.
D) Report all suspicious inbound traffic to the listed administrative contact of the source IP.

4) Which firewall product is susceptible to loose source route attacks?

A) Check Point
B) Cisco
C) Netscreen
D) None of the above

5) Which Libpcap filter would permit you to see potentially malicious IP fragments which could not have been generated by a normal topology MTU?

A) ip = frag and evil bit = enable
B) ip[12:2] = ip[16:2]
C) ip[2:2]<0x1F4 and ip[6]&32!=0
D) ip[8]<0x2A or ip[0]&0x0F>5

6) Which of the following techniques would permit an attacker to port scan your network without giving any indication of their true source IP address?

A) nmap “stealth” (-sS) scan.
B) nmap “idle” (-sI) scan.
C) nmap “decoy” (-D) scan.
D) Port scans require responses to stimulus so the true source IP cannot be completely hidden.

7) Which of the following best describes what happens when you surf to a Web site, see “HTTPS” in the URL, and the little lock icon on your Web browser is activated?

A) All data to and from the Web server is at least authenticated.
B) All data to and from the Web server is at least encrypted.
C) All data to and from the Web server is encrypted and the digital certificate is fully verified.
D) All data to and from the Web server is authenticated and encrypted.
E) All data to and from the Web server is authenticated, encrypted and the digital certificate is fully verified.

8 ) You see the following packet leaving your Web server and headed to an IP address on the Internet. What is the most likely cause?

A) Problem with the firewall state table time-out being set too low.
B) Automatic update checking for new patches.
C) Attacker retrieving a toolkit.
D) A secure HTTPS session.

17:08:08.412172 IP (tos 0×0, ttl 128, id 18210, offset 0, flags [DF], proto: UDP (17), length: 33) 172.30.2.185.32851 > 1.2.3.4.69:

9) You see the following packet entering your network. Which answer gives the most accurate and likely possibility of what is going on?

A) TCP transmission from a Windows system.
B) SMTP transmission from a Windows system.
C) Spam or Phishing attempt from a Windows system.
D) SMTP transmission from a Linux or UNIX system.

19:22:17.631407 IP (tos 0×0, ttl 112, id 30435, offset 0, flags [DF], proto: TCP (6), length: 48) 1.2.3.4.4110 > 192.168.1.10.25: S, cksum 0xc25c (correct), 103504428:103504428(0) win 8192 <mss 1460,nop,nop,sackOK>

10) Given the following netstat output, which of the answers best describes the situation:

A) The system has potentially been compromised.
B) The system needs a restart to install updated software.
C) The system is configured as a typical Windows desktop.
D) The system is configured as a typical Windows server.

Proto Local Address          Foreign Address        State           PID
TCP    0.0.0.0:80           0.0.0.0:0              LISTENING       2648
TCP    0.0.0.0:80               0.0.0.0:0              LISTENING       2292
TCP    0.0.0.0:135               0.0.0.0:0              LISTENING       1204
TCP    0.0.0.0:445               0.0.0.0:0              LISTENING       4

11) Which of the following systems can potentially be taken over by a remote attacker?

A) A Web server exposed to Internet access.
B) A desktop with Internet access.
C) A firewall or Network Based Intrusion Prevention (NIPS) system.
D) All of the above.
E) None of the above.

12) A Network Based Intrusion Prevention System (NIPS) is simply a relabeled:

A) Proxy based firewall.
B) Stateful inspection based firewall.
C) Neither, it is its own unique technology.
D) A combination of both.

13) You see the following pattern in your firewall log, which answer best describes what may be going on?

A) Someone is fingerprinting which firewall product we are using.
B) A remote site is having connectivity issues connecting to our Web server.
C) The state table time-out value on our firewall is set too low.
D) This is normal and expected traffic to our servers.

Jun 8 05:40:36 SRC= 1.2.3.4 DST=our_web_server LEN=40 TTL=2 ID=7831 PROTO=TCP SPT=2023 DPT=80 WINDOW=1400 SYN
Jun 8 05:40:38 SRC= 1.2.3.4 DST=our_web_server LEN=40 TTL=44 ID=7832 PROTO=TCP SPT=80 DPT=80 WINDOW=1400 SYN
Jun 8 05:40:40 SRC= 1.2.3.4 DST=our_web_server LEN=40 TTL=44 ID=7833 PROTO=TCP SPT=2024 DPT=80 WINDOW=1400 ACK
Jun 8 05:40:45 SRC= 1.2.3.4 DST=our_dns_server LEN=38 TTL=44 ID=7834 PROTO=ICMP TYPE=8 CODE=0 ID=47578 SEQ=5
Jun 8 05:40:50 SRC= 1.2.3.4 DST=our_dns_server LEN=58 TTL=44 ID=7835 PROTO=UDP SPT=2025 DPT=53
Jun 8 05:40:52 SRC= 1.2.3.4 DST=our_dns_server LEN=58 TTL=44 ID=7836 PROTO=UDP SPT=80 DPT=53
Jun 8 05:40:54 SRC= 1.2.3.4 DST=our_dns_server LEN=58 TTL=44 ID=7837 PROTO=TCP SPT=2026 DPT=53 WINDOW=1400 SYN
Jun 8 05:40:59 SRC= 1.2.3.4 DST=our_dns_server LEN=58 TTL=44 ID=7838 PROTO=TCP SPT=2026 DPT=53 WINDOW=1400 RST

14) You see the following traffic pattern in your proxy log. What is the most likely cause?

A) 192.168.1.22 is performing normal Web browsing.
B) 192.168.1.22 is downloading patches.
C) Someone on 192.168.1.22 is running an nmap version scan against 1.2.3.4.
D) 192.168.1.22 has been compromised and is calling home.

192.168.1.22 [ 9/Jul/2009:10:42:55 +0000] “GET http:// 1.2.3.4/ HTTP/1.1″ “-” “-”
192.168.1.22 [ 9/Jul/2009:10:42:55 +0000] “POST http:// 1.2.3.4/ HTTP/1.1″ “-” “-”
192.168.1.22 [ 9/Jul/2009:10:43:20 +0000] “GET http:// 1.2.3.4/ HTTP/1.1″ “-” “-”
192.168.1.22 [ 9/Jul/2009:10:43:20 +0000] “POST http:// 1.2.3.4/ HTTP/1.1″ “-” “-”
192.168.1.22 [ 9/Jul/2009:10:43:45 +0000] “GET http:// 1.2.3.4/ HTTP/1.1″ “-” “-”
192.168.1.22 [ 9/Jul/2009:10:43:45 +0000] “POST http:// 1.2.3.4/ HTTP/1.1″ “-” “-”

15) Analyze the following network drawing. How many potential paths does an attacker have available in order to gain access to the internal network?

A) 1
B) 2
C) 3
D) 4

Answers will be posted tomorrow!

1) How many different techniques are available to sniff in a switched environment:

A) None. Switches block unicast traffic to all ports.

B) 2

C) 4

D) 6

2) You receive the ICMP packet shown below from a remote host. Which of the following is the most likely source of the packet?

15:52:50.129178 IP (tos 0×0, ttl 47, id 51389, offset 0, flags [none], proto: ICMP (1), length: 28) 1.2.3.4 > 172.30.2.10: ICMP echo request, id 18492, seq 21446

A) Ping run on a Windows system.

B) Ping run on a Linux system.

C) hping using the “-C 8” option.

D) nmap using the “-sP” option.

3) Which is the best way to discourage attackers from using your address space as part of a SYN flood attack?

A) Quietly drop all inbound SYN/ACK packets that are unsolicited.

B) Return an ICMP Admin Prohibited error packet for all inbound SYN/ACK traffic that is unsolicited.

C) Advertise all portions (even unused) of your IP address space via BGP.

D) Report all suspicious inbound traffic to the listed administrative contact of the source IP.

4) Which firewall product is susceptible to loose source route attacks?

A) Check Point

B) Cisco

C) Netscreen

D) None of the above

5) Which Libpcap filter would permit you to see potentially malicious IP fragments which could not have been generated by a normal topology MTU?

A) ip = frag and evil bit = enable

B) ip[12:2] = ip[16:2]

C) ip[2:2]<0x1F4 and ip[6]&32!=0

D) ip[8]<0x2A or ip[0]&0x0F>5

6) Which of the following techniques would permit an attacker to port scan your network without giving any indication of their true source IP address?

A) nmap “stealth” (-sS) scan.

B) nmap “idle” (-sI) scan.

C) nmap “decoy” (-D) scan.

D) Port scans require responses to stimulus so the true source IP cannot be completely hidden.

7) Which of the following best describes what happens when you surf to a Web site, see “HTTPS” in the URL, and the little lock icon on your Web browser is activated?

A) All data to and from the Web server is at least authenticated.

B) All data to and from the Web server is at least encrypted.

C) All data to and from the Web server is encrypted and the digital certificate is fully verified.

D) All data to and from the Web server is authenticated and encrypted.

You see the following packet leaving your Web server and headed to an IP address on the Internet. What is the most likely cause?

17:08:08.412172 IP (tos 0×0, ttl 128, id 18210, offset 0, flags [DF], proto: UDP (17), length: 33) 172.30.2.185.32851 > 1.2.3.4.69:

A) Problem with the firewall state table time-out being set too low.

B) Automatic update checking for new patches.

C) Attacker retrieving a toolkit.

D) A secure HTTPS session.

9) You see the following packet entering your network. Which answer gives the most accurate and likely possibility of what is going on?

19:22:17.631407 IP (tos 0×0, ttl 112, id 30435, offset 0, flags [DF], proto: TCP (6), length: 48) 1.2.3.4.4110 > 192.168.1.10.25: S, cksum 0xc25c (correct), 103504428:103504428(0) win 8192 <mss 1460,nop,nop,sackOK>

A) TCP transmission from a Windows system.

B) SMTP transmission from a Windows system.

C) Spam or Phishing attempt from a Windows system.

D) SMTP transmission from a Linux or UNIX system.

10) Given the following netstat output, which of the answers best describes the situation:

Proto Local Address Foreign Address State PID

TCP 0.0.0.0:80 0.0.0.0:0 LISTENING 2648

TCP 0.0.0.0:80 0.0.0.0:0 LISTENING 2292

TCP 0.0.0.0:135 0.0.0.0:0 LISTENING 1204

TCP 0.0.0.0:445 0.0.0.0:0 LISTENING 4

A) The system has potentially been compromised.

B) The system needs a restart to install updated software.

C) The system is configured as a typical Windows desktop.

D) The system is configured as a typical Windows server.

11) Which of the following systems can potentially be taken over by a remote attacker?

A) A Web server exposed to Internet access.

B) A desktop with Internet access.

C) A firewall or Network Based Intrusion Prevention (NIPS) system.

D) All of the above.

E) None of the above.

12) A Network Based Intrusion Prevention System (NIPS) is simply a relabeled:

A) Proxy based firewall.

B) Stateful inspection based firewall.

C) Neither, it is its own unique technology.

D) A combination of both.

13) You see the following pattern in your firewall log, which answer best describes what may be going on?

A) Someone is fingerprinting which firewall product we are using.

B) A remote site is having connectivity issues connecting to our Web server.

C) The state table time-out value on our firewall is set too low.

D) This is normal and expected traffic to our servers.

Jun 8 05:40:36 SRC= 1.2.3.4 DST=our_web_server LEN=40 TTL=2 ID=7831 PROTO=TCP SPT=2023 DPT=80 WINDOW=1400 SYN

Jun 8 05:40:38 SRC= 1.2.3.4 DST=our_web_server LEN=40 TTL=44 ID=7832 PROTO=TCP SPT=80 DPT=80 WINDOW=1400 SYN

Jun 8 05:40:40 SRC= 1.2.3.4 DST=our_web_server LEN=40 TTL=44 ID=7833 PROTO=TCP SPT=2024 DPT=80 WINDOW=1400 ACK

Jun 8 05:40:45 SRC= 1.2.3.4 DST=our_dns_server LEN=38 TTL=44 ID=7834 PROTO=ICMP TYPE=8 CODE=0 ID=47578 SEQ=5

Jun 8 05:40:50 SRC= 1.2.3.4 DST=our_dns_server LEN=58 TTL=44 ID=7835 PROTO=UDP SPT=2025 DPT=53

Jun 8 05:40:52 SRC= 1.2.3.4 DST=our_dns_server LEN=58 TTL=44 ID=7836 PROTO=UDP SPT=80 DPT=53

Jun 8 05:40:54 SRC= 1.2.3.4 DST=our_dns_server LEN=58 TTL=44 ID=7837 PROTO=TCP SPT=2026 DPT=53 WINDOW=1400 SYN

Jun 8 05:40:59 SRC= 1.2.3.4 DST=our_dns_server LEN=58 TTL=44 ID=7838 PROTO=TCP SPT=2026 DPT=53 WINDOW=1400 RST

14) You see the following traffic pattern in your proxy log. What is the most likely cause?

A) 192.168.1.22 is performing normal Web browsing.

B) 192.168.1.22 is downloading patches.

C) Someone on 192.168.1.22 is running an nmap version scan against 1.2.3.4.

D) 192.168.1.22 has been compromised and is calling home.

192.168.1.22 [ 9/Jul/2009:10:42:55 +0000] “GET http:// 1.2.3.4/ HTTP/1.1″ “-” “-”

192.168.1.22 [ 9/Jul/2009:10:42:55 +0000] “POST http:// 1.2.3.4/ HTTP/1.1″ “-” “-”

192.168.1.22 [ 9/Jul/2009:10:43:20 +0000] “GET http:// 1.2.3.4/ HTTP/1.1″ “-” “-”

192.168.1.22 [ 9/Jul/2009:10:43:20 +0000] “POST http:// 1.2.3.4/ HTTP/1.1″ “-” “-”

192.168.1.22 [ 9/Jul/2009:10:43:45 +0000] “GET http:// 1.2.3.4/ HTTP/1.1″ “-” “-”

192.168.1.22 [ 9/Jul/2009:10:43:45 +0000] “POST http:// 1.2.3.4/ HTTP/1.1″ “-” “-”

No comments »

Posted in 2-alert, General Security, Network Security

Tags: computer security network security security training

Test your network security skills – Answers

July 15th, 2009

In yesterday’s post I gave you a quick network security test to try. Here are the answers:

1) D

There are six different techniques that can be used to sniff in a switched environment. ARP cache poisoning, ARP cache flooding, DHCP spoofing, Port stealing, ICMP redirect attack and ICMP route discovery attack. High end vendor switches can be configured to block all of these except the ICMP redirect attack. That must be addressed on a per host level.

2) D

Ping on both Windows and Linux encapsulate data in the payload of their Echo-Request packets. The above packet has a length of 28, which is just an IP and ICMP header. When hping generates Echo-Request packets, it uses an initial sequence number of 0 and then increments by +256. The above sequence number of 21446 is not evenly divisible by 256. This makes nmap the most likely candidate as it generates empty payload Echo-Requests with random sequence numbers.

3) B

When your address space is spoofed as part of a SYN flood attack, you will see a high number of unsolicited SYN/ACK packets being sent to your network. Quietly dropping this traffic makes your address space highly attractive to attackers spoofing packets because it maximizes the amount of time their attacking SYN packets fill up the remote connection queue. By returning an ICMP error for these packets, your IP address space becomes less desirable as you are quickly removing the attacking SYN packets from the remote connection queue.

4) C

All three products prevent source route packets (both loose and strict) from being bounced off of the firewall itself. Netscreen however will pass loose source route packets targeting a host on the other side. So to be safe from redirection attacks in a Netscreen environment, you must ensure source routing is disabled on all exposed hosts.

5) C

The first portion of the filter, “ip[2:2]<0x1F4” checks to see if the packet is less than 500 bytes in size. The second portion of the filter, “ip[6]&32!=0” checks to see if the more fragment flag is turned on. So the complete filter will catch non-last fragments smaller than 500 bytes. All non-last fragments will express the smallest topology Maximum Transmission Unit (MTU) they pass through. The smallest LAN or WAN MTU used in the Internet is 512 bytes. So fragments smaller than 500 bytes are being crafted, most likely to obfuscate an attack pattern and avoid detection.

6) B

An idle scan leverages the predictable IP ID’s being used by a secondary system in order to make it appear that all the scanning packets are originating from that host. Since all the scan packets use the spoofed IP address of this secondary host, the attacker’s true IP address is not revealed to the host being targeted. nmap’s stealth and decoy options still transmit packets using the attacker’s true source IP address.

7) A

The protocol HTTPS and the little lock icon being activated on a Web browser simply means that the SSL or TLS protocol is being used to secure the data stream. Both specifications require that every packet be authenticated. Both specifications make encryption an optional feature. So its possible to use either SSL or TLS to communicate without encrypting any of the data passing between the systems. The only way to prevent this is to disable these options in your browser. Further, digital certificates are typically checked against a locally stored public key, but the browser does not check to see if the certificate has been revoked. This can also be changed through the browser’s options.

8 ) C

The traffic in question is an outbound attempt to connect to a TFTP server. Since Web servers do not use TFTP, this is not a problem with the firewall state table. Also, vendors do not make fixes available via TFTP, so this is not a check for new patches. The most likely candidate is that an attacker has compromised the system and is attempting to move their toolkit onto the box.

9) C

The TTL value in this packet is 112. Linux and UNIX use a starting TTL of 64, so this packet most likely did not come from one of these systems. Windows uses 128 as a starting TTL so this could likely be a Windows host located 16 hops away. This is a TCP packet headed to port 25, so it is most likely the start of an SMTP session. The system is using a very small window size (8192 bytes) and does not support the TCP windowing option (this would be listed in the output as “wscale” followed by a numeric value), which indicates that it is an older Windows desktop system. Since most organizations do not rely on old Windows desktops as their SMTP servers, this is most likely a compromised host transmitting spam or phishing attacks. A firewall such as pf or Netfilter would be able to filter these packets by passively identifying the source operating system.

10) A

Within a Linux or UNIX environment, ports can only be opened exclusively. This means that only one application can hold open a TCP or UDP listening port at any given time. While most Windows applications open ports exclusively as well, Windows permits applications to listen with non-exclusive access. The result is that one application will service most inbound sessions but if that port is busied out, connections are then passed to the second application. This can permit an attacker to open a back door on a system that is undetectable during port scans of the system.

11) D

The classic view is that only systems with open listening ports exposed to Internet access are susceptible to attack. The point of risk is in fact permitting unknown entities to interact with code running on the local system. All of the indicated systems permit some level of code interaction with untrusted IPs on the Internet. With this in mind, all can potentially be remotely compromised.

12) B

Network based intrusion prevention systems leverage stateful inspection technology to analyze both header and payload information, same as a stateful inspection based firewall. Sometimes NIPS provides more signatures to look for hostile patterns, but most high-end stateful inspection firewalls provide multiple signatures as well, but typically at a lower cost.

13) A

There are many suspicious patterns in these log entries. To start, the Time To Live (TTL) in the first packet is 2. Given modern OSs use a starting TTL of 64 or higher, and most systems are about 15 hops away from each other on the Internet, we should never see a TTL this low. Most likely this is someone running a TCPTraceroute variant to map our network through the firewall.

Look at the length of the first three TCP packets; its 40 bytes. This means no TCP options have been set. All modern day operating systems support some number of TCP options, so these looks like crafted packets. Also, the TTL of 44 is indicative of a Linux or UNIX variant, but the increment of the IP identification (ID) looks like a Windows system. The Echo Request recorded in log entry four is also suspicious, as a Linux/UNIX variant would use an initial Echo-Request sequence number of 0 or 1, not 5.

So what’s going on? Look at the source port in the first two packets. Based on the response (if any) from these probes a smart attacker can tell what technology the firewall is based on (proxy, static filtering or stateful filtering). If you know which firewall products leverage each technology, its now just a matter of further reducing the possibilities.

The second packet would identify if the source port is being restricted, which is done by some firewall products but not others. The third packet would identify if an ACK can create a new state table entry, which again is done by some products but not others. The rest of the pattern is similar. Based on what replies come back from each of these probe packets a smart attacker may be able to identify what vendor firewall product we are running.

14) D

The log entries claim this is normal HTTP 1.1 traffic. The issue is that normal HTTP traffic would include additional fields of information such as the full URI visited (we just see the target IP address 1.2.3.4) and the host identification field (what OS is being used, name and version of the browser, etc.). Both of these pieces of information are missing, which makes the log entries very suspicious. The GET and POST nature of the traffic implies that an exchange of information is taking place. While we would want to confirm via additional investigation work, it is very likely our internal system (192.168.1.22) has been compromised and is calling home for instructions.

15) C

There are three potential paths into the internal network; through the firewall, through the VPN gateway and through the switch. The firewall may be attacked directly or via data replies from a malicious site. The VPN gateway has exposed ports with no trusted system to monitor them, so it is susceptible to direct attack. Finally, the switch is a potential path as it is VLANing across multiple security zones. Features like auto trunk negotiation may be leveraged to gain access to the internal network from the DMZ, thus bypassing the firewall’s filtering capability between these two security zones.

So how did you do? The benchmark is being able to answer (meaning you knew the answer, not just a lucky guess ) 12/15 questions. If you scored below that point its time to hone the old skills.

No comments »

Posted in 2-alert, General Security, Network Security

Tags: computer security network security security training

Newer Entries »