Archive for the ‘Windows Security’ category

« Older Entries

Spawning A CMD Prompt From MS Word or Excel

October 15th, 2009

This is an old trick, but I still see a number of Administrators that think they have locked users out of the command prompt by simply removing the icon from the menu and disabling the Start–> Run option. In this post I’ll discuss how to create a command prompt with Visual Basic for Applications (VBA), as well as how to mitigate (although never completely eliminate) the risk of someone achieving access to the prompt.

Creating a command prompt with VBA

This technique will work with any application that supports VBA, but I’m specifically going to use Microsoft Word in my example. Here’s what you need to do:

  1. Launch Microsoft Word
  2. Press “ALT-F11” to launch the VBA editor
  3. Double click “ThisDocument” in the left pane
  4. When the editor window appears, type in the text shown in Figure #1
  5. Press the “F5” key
Figure 1: Our simple VB script

Figure 1: Our simple VB script

You should see a command prompt window appear in your task bar. Here’s a copy of the code you need in step 4 so you can copy/paste:

Sub GetCMD()

Shell “cmd.exe cmd.exe”

End Sub

How to prevent VBA from spawning a command prompt

Execution of the command prompt can be disabled with the Group Policy Editor tool. Here are the steps:

  1. Click Start –> Run
  2. Type in “gpedit.msc” (without the quotes)
  3. Click User Configuration –> Administrative Templates –> System
  4. Search down the list for “Prevent access to the command prompt” and double click it

You have two options available to you:

  • Enable/Disable access to the command prompt
  • Yes/No Disable command prompt scripting process

If you only disable the first option, direct access to cmd.exe is prevented but a smart user can still get to it via a batch file. To prevent script access, need to disable the second option as well. This prevents ALL scripting however and can play havoc in many environments. Also, both of these settings will apply to the Administrator account as well. This can make admin and troubleshooting far more difficult.

Even with both options disabled, a user can still get around these settings by using command.com instead of cmd.exe. To fix this, you need to restrict access to command.com via user permissions. If you are still running some old 16-bit apps, this fix will break them.

All of these steps do not completely solve the problem however. A user who knows what they are doing with debug can simply copy cmd.exe to another location and modify it so a prompt is achieved when using it to run a bogus command. So we also have to delete “debug.exe”.

Even then, a savvy programmer can create an executable to get around all of the above security checks. So we need to remove all ability to copy or write to the drive as well. Needless to say we have a pretty useless computer at that point.

Exec Summary

If someone smart has access to your system, it is doubtful you will be able to prevent him or her from getting to the command line. The Group Policy Editor can most certainly make it more difficult, but the tool simply reduces the risk of attack. You cannot completely eliminate the risk without severely hampering the system’s operation and usefulness.

No comments »

Posted in 4-notice, Windows Security

Tags:

Ubergeek Your Laptop For SANS Labs

September 17th, 2009

This morning I’m in San Diego giving a talk on how to work more effectively at the Window’s command line. Here’s a PDF version of the presentation for anyone that is interested:

uber-geek-laptop-R3.pdf

No comments »

Posted in 5-info, Windows Security

Tags:

Hiding A Backdoor Behind An Active Windows Listening Port

September 3rd, 2009

Its a common technique. You suspect one of your systems has been compromised, so you run a port scanner against the system. The hope is that if the system is backdoored you will identify an undocumented listening port. But what if a clever attacker hides the backdoor in plain site? What if they hide the backdoor behind an existing port you actually expect to see listening on the system? Unfortunately this is far too easy to accomplish if the host is running Windows.

The UNIX way

On a UNIX or Linux system, listening ports are always opened exclusively. In other words, if a mail process opens up TCP/25 to accept inbound mail connections, any other application that attempts to listen on TCP/25 will receive a bind error and be denied access. The only way the second application can bind to TCP/25, is to first kill off the mail process using the port. So only one application at a time is ever permitted access to a listening socket.

The Windows way

In Windows, exclusive access to a listening port is optional. Its perfectly legal to have multiple applications listening on the same TCP or UDP port. This of course can simplify the process of setting up a backdoor behind an existing application.

With Windows, exclusivity of socket access is actually a process that has been evolving over the years. Windows 95, 98 and ME actually had no way to open a port exclusively. There was nothing one application could do to prevent another from attaching to the same listening port. For versions of Windows between NT and XP, it is possible to request exclusive port access via the SO_EXCLUSIVEADDRUSE option. If exclusive access is not specifically requested however, the default is to fall back to providing shared access.

With Windows 2003 and later, the default is exclusive port access unless both applications specifically request shared access via the SO_REUSEADDR option. The exception is that if the same account is used to launch both applications, shared access is still possible unless exclusive access is specifically requested. This means that if a savvy attacker can launch their backdoor via the system account, this enhanced security will usually be defeated.

Try it yourself

To test how this works, you’ll need a copy of the Windows version of Netcat. Copy nc.exe into one of the directories in your path statement. Once you do, open a command prompt and try the following command:

C:\>nc -l -p 135

Can’t grab 0.0.0.0:135 with bind

We just told Netcat to listen (-l) on TCP port (-p) 135. When Windows first boots up, Microsoft RPC opens TCP/135 with the SO_EXCLUSIVEADDRUSE option set. Thus if any application (like Netcat) tries to listen on TCP/135, it receives the bind error shown above. This is the type of behavior we would like to see all of the time.

Now try opening a port that is not already in use:

C:\>nc -l -p 1234

It should appear as if the command is hanging (command prompt does not return). This tells you that Netcat is now listening on port TCP/1234. To verify this, open a second command prompt and type the command:

C:\>netstat -an | find “1234″

TCP 0.0.0.0:1234 0.0.0.0:0 LISTENING

This shows us that Netcat is now listening on TCP/1234 on all network interfaces.

When Netcat opens a listening port it does not request exclusive access to the port. This means it is possible to bind Netcat to an existing listening port that has not already been opened exclusively. To test this, open a third and fourth command prompt. Enter the same Netcat command into each that you run within the first command prompt. Each command should execute without error.

Does this mean Netcat is listening multiple times? Go back to the second command prompt window and try the following command:

C:\>netstat -aon | find “1234″

TCP 0.0.0.0:1234 0.0.0.0:0 LISTENING 448

TCP 0.0.0.0:1234 0.0.0.0:0 LISTENING 3044

TCP 0.0.0.0:1234 0.0.0.0:0 LISTENING 3016

We’ve added in the “o” switch which prints out the process ID for the application holding open the listening port. Note that a different instance of Netcat is responsible for each of the open listening ports. Because Netcat does not require exclusive access to the port, we can listen on the port multiple times.

So what happens when someone tries to connect to the port? Try it and find out using the following command:

C:\>nc 127.0.0.1 1234

This is a test

You should see the text “This is a test” appear in only one instance of the Netcat listeners. If you leave this session active and open (yet another) command prompt and type:

C:\>nc 127.0.0.1 1234

This is test 2

You should see this text appear in a different instance of the Netcat listener.

What have we learned

Since Windows does not require applications to have exclusive access to a listening port, its possible to have a malicious backdoor sitting behind a legitimate application, on the same listening port. This makes the backdoor undetectable when performing a port scan. In order to connect to the backdoor you must first busy out the legitimate application with an active session, but this is easy to achieve.

No comments »

Posted in 2-alert, Windows Security

Tags:

Spoofing Your IP Address During A Port Scan – Part 1

August 28th, 2009

I love debunking myths, one of my favorites is “a port scanner must reveal his true source IP address”. In this series I’ll show you how to perform a port scan while hiding your source IP address from the host being scanned. I’ll also tell you how you can detect the technique when it is used against you.

Nmap’s decoy mode

An alternative to the technique I will describe is nmap’s decoy mode. With decoy mode you identify a number of bogus source IP addresses. From the target host, it looks like all of the bogus IP addresses, as well as the true source IP address, are all performing a port scan at the same time. The concept is the administrator under attack will have no way of knowing which IP address is in fact the true IP performing the scan.

This technique really does not mask the true source, as the source IP address is one of the IPs performing the scan. If you know what to look for, you can easily figure out which source IP is actually scanning you. So while this technique will work, it is not completely effective at hiding the source IP address.

What is an idle scan?

When we perform an idle scan, we do not actually directly detect open ports. Rather, we detect the effect an open port would have on a third party system. The technique is similar to how many viruses are detected in the human body. Rather than detecting the actual virus, we look for antibodies that get produced when the virus is present in the system. An idle scan detects open ports in much the same fashion.

Before we can dig too deeply into an idle scan, we need to look at some of the intricacies of IP.

Predictable header values

While the RFCs are designed to be specific enough that dissimilar operating systems will still be able to communicate via IP, they still leave quite a bit open to interpretation. For example, the RFCs specify that the maximum Time To Live (TTL) value that can be used is 255. They do not however specify what initial TTL value must be used; so different operating systems use different starting TTLs. The RFCs describe how Ping should work, but do not specify what should be in the payload of Echo-Request packets. Again, different vendors use different values. These nuances can permit you to identify the source operating system based variations in the packet contents. The technique is referred to as passive fingerprinting.

The IP identifier (IP ID) field in the IP header (bytes 4 and 5) is a similar situation.  RFC 791 specifies that the number must be unique on a per host, per session basis. For example let’s say I connect to a remote SSH server. Each IP ID in that session must be unique. If I close the session and then connect back later, it is RFC compliant if one or more IP ID values get used again. They don’t have to be, but if it does happen it is not a problem.

So the RFCs say the IP ID needs to be unique, but it does not really tie down how to go about generating the value. This has lead to different operating systems deploying different methodologies. For example Windows starts at an IP ID value of 1 and simply increments the value by +1 for every packet leaving the system. When the maximum value of 65,535 is reached, it starts back over at 1. BSD puts a random value into the IP ID field of each packet leaving the system. Linux is random for TCP packet (except initial responses which are always zero), +1 incremental for ICMP, and time based for UDP. Whew!

The one that is interesting for our purposes is Windows. The fact that each packet leaving the system gets a +1 IP ID makes the value extremely predictable. For example, consider the following output:

[root@fubar ~]# hping -r 192.168.100.2

HPING 192.168.100.2 (eth0 192.168.100.2): NO FLAGS are set, 40 headers + 0 data bytes

len=46 ip=192.168.100.2 ttl=128 id=108 sport=0 flags=RA seq=0 win=0 rtt=0.4 ms

len=46 ip=192.168.100.2 ttl=128 id=+1 sport=0 flags=RA seq=1 win=0 rtt=0.4 ms

len=46 ip=192.168.100.2 ttl=128 id=+1 sport=0 flags=RA seq=2 win=0 rtt=0.4 ms

len=46 ip=192.168.100.2 ttl=128 id=+2 sport=0 flags=RA seq=3 win=0 rtt=0.4 ms

len=46 ip=192.168.100.2 ttl=128 id=+1 sport=0 flags=RA seq=4 win=0 rtt=0.4 ms

len=46 ip=192.168.100.2 ttl=128 id=+1 sport=0 flags=RA seq=5 win=0 rtt=0.4 ms

hping is a packet crafting tool which allows you create your own IP packets. In the above output we are using the “-r” switch to have hping monitoring the IP ID increment of a remote system. We know it is a Windows system, because Windows always uses a starting TTL of 128. Now look at the “id=” values. In the first line of output hping always prints out the absolute IP ID value used by the system. In this case here the value is 108. Each subsequent line then prints out the delta change from the previous packet. So in the second line the actual IP ID was 109, which is “+1” from the previous value of 108. The next packet had an IP ID of 110, which is “+1” from the previous IP ID value of 109.

Look closely at the fourth line of output. Note the delta change was “+2”. Since Windows uses sequential IP IDs, this tells us a packet we didn’t get to see just left the Windows system. We don’t know where it was going, but that’s OK. What’s important is that we can identify when the Windows system transmits and how many packets it sends out. For example had that line read “+5”, we would know that the Windows system transmitted four other packets since responding to our last probe.

Detecting open ports

So how can we leverage the predictable IP ID value of Windows for evil? One possibility is to turn the Windows system into an open port sensor. Here’s how we do it:

  1. Monitor the current IP ID being used by a Windows system. We should check the value at regular intervals over a relatively short period of time. Say once second.
  2. Find a target system we wish to port scan.
  3. While spoofing the source IP address of the Windows system, send a SYN packet to the TCP port we wish to probe on the target.

The target system will send a response packet back to the Windows system.  This response will either be:

The RFCs state you should never respond to error packets, regardless of whether you consider them to be legitimate or not. So when the Windows box receives the TCP reset error packet from the target host, it quietly ignores and discards the packet.

Things get a bit more interesting when a SYN/ACK is received however. From the Windows system’s perspective, it is just hanging out minding it’s own business when some unknown system sends it a SYN/ACK packet (remember we spoofed the Windows system’s IP address in the probe packet). A SYN/ACK effectively means “Sure, you can connect to me on that TCP port, no problem”. Of course since the Windows system didn’t actually send the SYN packet, it has no idea what the remote target is talking about.

With this in mind the Windows system sends a TCP reset error packet back to the target host. When the reset packet is transmitted, the next available IP ID is used within the IP header. This missing IP ID would be detected if we are still monitoring the IP ID increment once per second. So to review:

  • Closed port on target = No packets leaving Windows system
  • Open port on target = Windows sends a TCP reset using up an IP ID

So by monitoring the IP ID increment, we can identify when an open port is discovered as only probes to open ports will cause the IP ID increment to change.

Caveats

You can’t use just any Windows system for this attack. The box must meet certain criteria:

  • Relatively quite system generating little traffic (like a home system)
  • No stateful filtering of TCP traffic

Of course go to any cable or DSL network at 2:00 AM local time and you can find hundreds of thousands of systems that meet these criteria. Remember that Windows systems love to arbitrarily broadcast, so you may wish to perform multiple check of each open port just to ensure the IP ID increment change was in fact due to an open port being probed.

Exec Summary

An idle scan lets you probe open ports on a remote target, while fooling the target into believing that some third party system is performing the scan. Open ports are detected by monitoring for irregularities in the IP ID increment of the Windows box.

In the next installment we’ll actually see what these packets look like on the wire as well as discuss how to detect an idle attack when it is used against you.

No comments »

Posted in 3-err, Network Security, Windows Security

Tags:

How To Use Windows Auto-Complete And Command Line History

August 13th, 2009

Ran into this issue at a client site today so I thought I would post some info on it. I see a lot of Windows administrators that don’t know how to fully leverage the Windows auto-complete functionality as well as the command line history. I also see Linux and UNIX administrators who get confused because these features work differently under Windows. Thought I would write up a quick how-to.

Windows auto-complete

Auto-complete permits you to type in a portion of a file name and have the system fill in the rest of the name for you. It’s a great way to save a few keystrokes. Simply type in the first couple of letters for the file name and press the <tab> key. The first file in the current directory, which starts with the letters you typed, will be filled in on the command line. This is shown in Figure #1.

win-auto-complete

For the folks that have used auto-complete on UNIX or Linux, here is where they get confused. Both platforms require you to type in enough of the command to be unique. You can then press <tab> to fill in the rest of the file. Windows works a little different.

Note in Figure #1 Windows filled in the first file name match to the character string “nets” the first time the <tab> key was pressed. If this is not the file you wanted, simply press the <tab> key a second time. You can continue to press the <tab> key and scroll through all of the possible file options.

Eventually the system will wrap and return to the first file it presented. For example pressing <tab> six times in the above example will return you to the file named “netsetup.cpl”. If you need to scroll backwards through the file options, simply hold down the <shift> key while you press <tab>.

Windows command history

Most folks realize you can press the up and down arrow keys to scroll through your command line history. Have you tried the <F7> key? If you are working in a command prompt and press the function 7 key ( <F7> ), a menu appears showing all the commands that you typed. This is shown in Figure #2. You can then use the up and down arrows, as well as the <Page Up> and <Page Down> keys, to navigate this list of commands.

prompt-history

Here’s another area where Windows works a little differently than Linux and UNIX. With Linux and UNIX, pressing the up arrow will always retrieve the last command you typed. If you have 10 sequential commands you wish to repeat, you will have to repeatedly hit the up arrow key 10 times to retrieve each command in sequence. Windows makes this process a little easier.

Try this on your Windows system:

  • Open a command prompt
  • Type the number 1 and press <enter>
  • Ignore the command not found error
  • Repeat the last two steps for numbers 2 – 10
  • Press the up arrow till you retrieve the number 5
  • Press enter
  • Press <F7>

An example is shown in Figure #3. Note the menu bar is over the number 5. This is the current reference point in the command history. While pressing the up arrow on a Linux or UNIX command line will always recalls the last command you typed, Windows shift the reference point to last recalled command. So pressing up arrow recalls the command prior to the last recalled command, not the last executed command like Linux and UNIX.

win-auto-complete2

To test this, press the <Esc> key. This will return you to the command prompt. Now press the up arrow. This will recall “4”, the command prior to “5” in the history, not “10” which was the last command executed prior to recalling “5”. Now press the down arrow until the “7” command is displayed and press <Enter>. If you now press <F7> you will notice the reference pointer has been moved to “7”, the last recalled command.

Exec Summary

Some functions operated differently at the Windows command line than their UNIX or Linux counterparts. Auto-complete and command line history are two great examples. Which implementation is preferable, unusually depends on which operating system you are most comfortable using.

No comments »

Posted in 4-notice, Windows Security

Tags:

Leveraging the Windows “runas” command

July 28th, 2009

Sometimes we can be our own worst enemy. I’ve written a bit about Malware and how infection rates are through the roof. If you look at the one thing you can do to make a Malware author’s life easier, its logon to your Windows system as an Administrator equivalent.

This problem was solved long ago on UNIX and Linux systems via tools like su and sudo. You used to have an excuse for running Admin equivalent on Windows. Microsoft made it extremely difficult to perform IT functions unless you were a high level account. This problem was resolved years ago with the runas command however, so its time we took control of this potential security hole.

Why is it important to use runas

When you are logged on as an Administrator equivalent, you have full god/goddess rights to the local system, and possibly the whole network. This means that your credentials are capable of doing anything. If a Malware author drops something nasty on your system, they have the same level of access that you do. Administrators used to mitigate this threat by being careful about what they clicked on. Today however Malware can come at you through trusted sites. By running with a lower level of permissions, you can help reduce the magnitude of a Malware attack.

What does runas do for me?

When you execute the runas command, only applications running beneath it have high level permissions. So for example let’s say we leverage runas to launch the User Manager. The User Manager application will have Administrator level privileges but the rest of our system environment will not. If User Manager is open when an attacker delivers nasty Malware via your browser, the Malware will be constrained to the level of access granted by your regular user account because the browser is still running with lower level permissions.

Using runas via the GUI

One of the simplest ways to leverage the runas command is via shortcuts. In my last post I gave a list of common Windows administrator tools. Simply create a shortcut on your desktop for each tool you need to use. When you need to run the tool, right click the icon and select “Run as…” from the pop up menu (it should be the second option). This will produce the window shown in Figure #1. Simply supply the credential for your high level account and the tool will launch as it normally does.

runas

Note that in Figure #1 I’m logging on as Administrator. In an ideal world, each admin will have a dedicated administrator account (like cbrenton-admin or similar). This will make it much easier to create a proper audit trail of changes.

Using runas from the command line

Along with the GUI interface, you can leverage runas from the command line as well. The simplest solution is to place a command prompt shortcut on your desktop and launch it as specified above. If you already have a command prompt session going, you can leverage the runas command directly. The syntax is:

runas /user:<high level account name> <command we wish to run>

If we wish to generate a new command prompt with high permissions, we can do that too. The syntax is:

runas /user:<high level account name> c:\windows\system32\cmd.exe

This will produce output similar to Figure #2. Note that we have simply leveraged runas to spawn a new command prompt session. Now anything run within this new command prompt will be executed with higher permissions.

runas-command-line

Exec Summary

Today there is no excuse for logging into Windows as an administrator equivalent. By leveraging the runas command along with some shortcuts, IT folks can still get the job done while refraining from being their own worst enemy.

No comments »

Posted in 3-err, Windows Security

Tags:

Quick Access To Windows Admin Tools

July 28th, 2009

In my last post I talked about how using the Windows GUI can at times be cumbersome. If you administer a Windows network, you are frequently leveraging the Windows admin tools. Here are some tips to make that task a bit easier.

List of Tools

Here’s a list of the most commonly used Window’s admin tools as well as the command needed to launch them:

  • Add/Remove Programs = appwiz.cpl
  • Certificate Manager = certmgr.msc
  • Computer Manager = compmgmt.msc
  • Control Panel = control.exe
  • Copy screen to clipboard = <ctrl><Print Scrn>
  • Copy active window to clipboard = <ctrl><alt><Print Scrn>
  • Device Manager = devmgmt.msc
  • Event Viewer = eventvwr.msc
  • File Explorer = explorer.exe
  • File Signature Verification = sigverif.exe
  • Group Policy Editor = gpedit.msc
  • MS Management Console = mmc
  • Network Properties = control netconnections
  • Performance Monitor = perfmon.msc
  • Registry Editor = regedt32.exe
  • Security Center = wscui.cpl
  • User Manager = lusrmgr.msc
  • Security Policy Editor = secpol.msc
  • Services Screen = services.msc
  • Solitaire = sol.exe
  • System Config Utility = msconfig.exe
  • Task Manager = taskmgr.exe
  • Task Manager = <ctrl><shift><esc>
  • Task Scheduler = control schedtasks
  • User Manager = lusrmgr.msc

Quick Launch Options

Here are some tips for making each of the above easily accessible:

  1. Click Start –> Run then type in the command listed above
  2. Press <Windows key><r> then type in the command listed above
  3. Create a desktop shortcut
  4. Create a taskbar shortcut
  5. Create a single program group so everything is in one place

No comments »

Posted in 4-notice, Windows Security

Tags:

Helpful Shortcuts For The Windows IP Geek

July 25th, 2009

Many of us do testing with our Windows systems which inevitably require us to change firewall settings and IP info. While Windows has given us a pretty GUI for performing these tasks, it can be cumbersome to navigate the menu options. In this post I’ll show you how creating a few icons can help you take better control of this problem.

Dealing with the Windows firewall

One of the common tasks I need to perform is disabling and enabling the Windows firewall. I sometimes need to shut it off for testing, but of course want it turned back on again if I’m connected to a potentially hostile network. This introduces the additional problem that I can never remember if I had it turned on or off the last time the system was booted.

Disabling the Windows firewall

Open up a text editor and create a file named disable-firewall.bat. Type the following line into the file:

netsh firewall set opmode disable

Now save the file and create a desktop shortcut that points to it. Whenever you double click the icon, the Windows firewall will shut down.

Enabling the Windows firewall

Open up a text editor and create a file named enable-firewall.bat. The file will contain only a single line:

netsh firewall set opmode enable

Now save the file and create a desktop shortcut that points to it. Whenever you double click the icon, the Windows firewall will turn on.

Checking the Windows firewall status

Open up a text editor and create a file named fw-status.bat. Type the following three lines into the file:

netsh firewall show state
pause
exit

Now save the file and create two shortcuts pointing to it. One on the desktop and one in your startup group. When your system first boots up, a command prompt will open showing the current state of the Windows firewall. It will then pause on the screen until you press a key. Anytime you need to check the current status, simply double click the shortcut you placed on the desktop.

Dealing with IP settings

If every network used DHCP, dealing with IP would be much easier. When we work in a lab however, we typically have to manually configure IP for communications. Obviously we can use the GUI for this, but its easy to streamline the process with a couple of shortcuts.

Manually setting a wired IP address

For the purpose of this exercise I’ll assume the IP address you want to assign is 192.168.1.10. Change this IP address as needed.
Open up a text editor and create a file named 192-168-1-10.bat. The file will contain only a single line:

netsh interface ip set address local static 192.168.1.10 255.255.255.0

Now save the file and create a desktop shortcut that points to it. When ever you double click the icon, the IP address on your wired interface will be changed.

Adding a default gateway

If there is a default gateway you need to specify, we can do that as well. Assuming the gateway is at 192.168.1.1, we would change the above command to read:

netsh interface ip set address local static 192.168.1.10 255.255.255.0 192.168.1.1 1

Specifying a DNS server

If you need to specify DNS servers, we’ll need to add a few extra lines to the batch file. Let’s build on the last example and assume we have two DNS servers, one at 10.1.1.1 and another at 172.30.1.10. In this case our batch file would contain the following:

netsh interface ip set address local static 192.168.1.10 255.255.255.0 192.168.1.1 1
netsh interface ip set dns local static 10.1.1.1
netsh interface ip set dns local static 172.30.1.10

Reverting back to DHCP

Open up a text editor and create a file named reset-dhcp.bat. The file will contain only a single line:

netsh interface ip set address local dhcp

Now save the file and create a desktop shortcut that points to it. When ever you double click the icon, Windows will look to a local DHCP server for the IP info it will use.

What if I use multiple IP addresses?

The above example works great provided you consistently use the same IP address. What if you need a bit more flexibility to change it on the fly? Luckily we can handle that problem through the use of variables.

Open up a text editor and create a file named varip.bat. The file will contain only a single line:

netsh interface ip set address local static %1 255.255.255.0

Now save the file to a directory in your path statement. The Windows directory itself is usually a good last ditch option. If you don’t know which directories are in your path, simply open a command prompt and type the command “path”. This will produce a semi-colon ( ; ) separated list of all directories in your path. This tip will not work if the file is not saved to a directory in your path statement.
Whenever you need to set your IP address simply click Start–> Run and type in:

varip 192.168.50.25

or what ever IP address you wish to use. If you commonly need to change the subnet mask, change the command to read:

netsh interface ip set address local static %1 %2
Now when you click Start–> Run you would type:

varip 192.168.50.25 255.255.255.128

or whatever IP address/subnet mask combination you wish to use.

Exec Summary

While the Windows GUI is relatively easy to navigate, it can be cumbersome for common tasks like changing IP address or firewall settings. This can easily be rectified by creating a few batch files and placing shortcuts to them on the desktop.

1 comment »

Posted in 4-notice, Windows Security

Tags:

Dealing With Malware On Windows (Part 2) – Long Live Application Control

July 13th, 2009

Application control, sometimes called application white listing, gives you granular control of which applications are permitted to run on each of your systems. Not only can this replace your A/V solution, it can keep rogue users and license issues in check as well.

How does application control work?

The concept is relatively straightforward. You identify which application you want each of your users to be able to run and the software takes care of enforcing that policy. One of the nice things about application control software is that you usually get far more customization capability than A/V. For example with many A/V solutions I may be forced to completely disable A/V in order to run an application listed as malicious in the signature database (say I’m an Auditor that needs to do port scanning or password cracking). With application control, I can usually get as granular as writing policies on a per user, per system, per location level (for example the Auditor can only run the port scanner from a specific system when its attached to one specific network segment). This is cool because unlike A/V I don’t have to disable the software, thus exposing myself to risk, just to simply do my job.

What to look for in application control software

There’s a couple of things you need to look at when evaluating an application control product. First, you need to look at how files are identified. Are they simply looking at file names stored in a specific location, or are they running multiple hash algorithms to authenticate the file is in fact properly identified? You also want to look at what’s involved with approving files for use and how the system deals with patches.

For example, one of my favorite products is Parity from Bit9 Software. They start by referencing a file database with over 6 billion entries and counting. While that might seem like overkill, think of how many file are involved if you just want to approve Microsoft Office for use and include all versions and all patch levels. All of a sudden 6 billion entries does not seem that far-fetched.

Unfortunately a file database is not going to be enough. You need some way to approve custom scripts and executables, as well as deal with real time patch files. For example Adobe checks for patches whenever a user launches the application. If they happen to do this right at the exact minute a patch is released, the patch file info will not yet be propagated into the file database. What Parity does is permit you to approve software based on it being digitally signed. For example we can create an exception that says, “If the file is not in the database but has been digitally signed by us or Adobe, it’s OK for use”.

Protecting Supervisory Control And Data Acquisition (SCADA) Networks

This is a very cool solution for control networks. For example those networks running the grid, municipal services, military stuff, etc., which are not suppose to be connected to the Internet. The lack of connectivity creates a catch-22. You’ve disconnected from the Internet to help protect the network but how do you update your A/V signatures with no Internet access? With Parity this is a non-issue. You simply digitally sign all software required on the control network, write a rules saying only digitally signed software can be executed, and you are done. No signatures or updates to worry about, just re-sign new software as you wish to deploy it on the network.

Parity has some other cool features as well like the ability to track file execution or the ability to control which removable drives can be used (by model, by user and by level of access). I’m starting to feel like a sales person however, so I’ll leave it to the reader if they want to learn more. ;)

The dirty little secret

So why is it we are not seeing A/V vendors dump their signatures and jump on the application control bandwagon? I do not work for an A/V vendor so I can only speculate. I do however own stock in a few of them and will say that as soon as I see this trend occur I’m selling my stock. Think of it this way, where is the true cost in your A/V solution? Is it in the initial purchase price of the client, or is it in the monthly/annual subscription fee you pay for signatures?  Companies loooove reoccurring revenue streams because they mean predictable income with zero sales effort. Stockholders (like myself) love reoccurring revenue streams because “higher income + less up front costs = higher profit”. Note in the last example I discussed protecting a network without the need for signature updates. If users went this route it would have a serious financial impact on each A/V vendor’s bottom line.

The bad stuff

Now some caveats. You would probably want to use the file database if available, even if this means paying for a different subscription service. Digitally signing everything is fine on a network where the applications are infrequently changed (like SCADA) but in a typical corporate environment your job title would turn into “the Admin who’s always signing software”.

Also, application control simply regulates which applications are run on the system. Its not very helpful if an approved application gets whacked via a buffer overflow or the like. So patching is still a must and you will probably want to run a Host-based Intrusion Protection System (HIPS) to be completely locked down. Still, with application control you end up with a far more secure posture than sticking with that old carburetor A/V software.

No comments »

Posted in 3-err, Malware, Windows Security

Tags:

Uber Geek Your Windows Laptop

July 12th, 2009

Thought some folks might find this useful. I’ve noticed that over the last few years working with the Windows command line has become a bit of a lost art. This is too bad as you can do some really cool stuff. This instructional is geared towards those folks that do not know the power of working from “the dark place”. There are general tips for setup, how to perform common task, common error codes and how to resolve them, as well as batch file basics.

This is relatively low level material, but IMHO its a great primer for those who have not spent a lot of time working at the command line.

Enjoy!

C

Uber Geek Your Windows Laptop

No comments »

Posted in 4-notice, Windows Security

Tags: