DHCP Snooping vs Raspberry PI (A beginner concept)

Elliot is a savvy techie that works at Price Wright Corporation. This morning, his routine seemed all too normal. He arrived at work at 9am sharp, filled his mug with coffee and started to chat with his colleagues. As he chatted away, the back of his mind was running with a technical sequence he planned to execute.

In Elliot’s backpack, he brought a specifically configured Raspberry PI that would do his bidding. The fifth floor of Price Wright Corporation was under construction. No one was on this floor. This is where he would find a port to plug in the router. He sneaks away from the conversation he was having, and proceeds to execute his plan.

At his cubicle, he remotely checks to see if his plan worked. The Raspberry PI should have already ran the necessary configurations.

1.     DHCP Starvation Attack – Kali is running on the Raspberry PI. A script on this OS would begin the process to flood Price Wright Corporation’s DHCP server with fake DHCP requests. The DHCP server would no longer be able to hand out IP addresses at this point.

2.     Rouge DHCP Server – Then the Kali box would supplant the DHCP server. All devices would then be requesting IP address information from Kali. That includes the DNS Server, and default gateway information.

3.     Man in the Middle – End clients would have their traffic rerouted because, IP addressing is owned. Traffic would be forwarded to a MITM Server as a proxy to the internet. All traffic would then be visible to Elliot. The network would be considered owned.

When Elliot logs into the remote server traffic is to be forwarded to, he finds no forwarded traffic. After troubleshooting, he finds out the Kali Box was denied of the DHCP server status.

In this scenario, the DHCP Starvation attack is thwarted by a concept called DHCP Snooping. When DHCP snooping is applied, switch ports are able to restrict the type of DHCP data that is forwarded to it.

DHCP negotiation is remembered by the acronym DORA – Discover, Request, Offer, and Acknowledgement. Discover and request traffic are made by machines requesting for IP address information, while the offer and acknowledgement traffic are DHCP server traffic. The DHCP server traffic should only come from the appropriate DHCP server. DHCP snooping restricts ports that should not have DHCP server traffic running through it. This was the case for Price Wright Corporation.

DHCP snooping was enabled for Price Wright Corporation which restricted the Kali Box from acting as the DHCP server. Their environment only allowed DHCP server traffic coming from the access port of the main DHCP server, the trunk link to the switch of the fault tolerant server, and the access port of the fault tolerant DHCP server.

Although there are malicious reasons rogue DHCP servers enter the environment, it is also very likely an accident by an employer. Sometimes employees bring in a router to have more accessible ports, and when it’s plugged into the company network, the router acts as a DHCP server. The intent isn’t malicious if done by accident. It was an unknowing mistake. Routers by default become a DHCP server when plugged into a network. If computers decide to use this DHCP server, they won’t be able to talk to the network. The accident would cause a denial of service, DoS.

Kali’s Macof for CAM Table Overflow Attack is Denied by Port Security

Kali OS, the one with the cool dragon logo on it is a great toolkit for the hacker’s arsenal. If you’ve ever seen Mr. Robot, you’ll see the dragon symbol on their computer to own Evil Corp. With this OS, networks can be owned, if they aren’t configured well.

Macof is a program that can run inside the Kali OS. If this is run against a port on a switch, it does what’s called a Content Addressable Memory Table Overflow Attack, or CAM Table Overflow Attack for short. The CAM Table is used to remember which port to reference a mac address to. Because, the table can only store so many mac addresses, older mac addresses start to be removed when the table reaches capacity. This is what begins to happen when the macof program is utilized, the program sends 1000s on 1000s mac addresses until CAM Table reaches capacity and the oldest mac addresses are removed.

So why is this an issue? Let’s say there’s a switch with CAM Table capacity of 2000 mac addresses. On this switch there are three ports occupied. One is a Windows computer, and one of them is an Ubuntu machine. These machines have been on the switch and have been able to send traffic as wanted. Until now. A Kali laptop is newly plugged into the switch. It runs the macof program. The CAM Table Overflow Attack makes the switch forget the mac addresses for the two other legitimate computers. Therefore once these computers try to talk with each other, the switch will not know which ports to send the traffic to, as the port reference for the mac addresses has been forgotten. Switch logic then dictates, to figure out who owns these addresses by sending out the traffic to all the ports (except for the one the traffic initiated from). When the traffic is sent, the Kali Laptop can then receive and interpret the traffic from the other devices on the switch.

The CAM Table Overflow attack is a huge risk. This attack leaves traffic exposed, and can make avenues for further risk escalation into the network ie DNS Poisoning via MITM. Luckily, switches have preventative measures to mitigate risks, and to specifically block the CAM Table Overflow attack.

Port security is the preventative measure that Cisco switches have for attacks from Kali’s macof program. It prevents CAM Table overflow attacks by three major actions:

1.     Protect – This is basic protection and rarely used. It simply doesn’t allow for traffic beyond what is configured for it. For instance if a port is configured to have 3 mac addresses only, it will not allow traffic beyond these 3 mac addresses. So when a machine with the 4^th mac addresses is plugged into it, the port simply just does not allow the traffic to continue. There are no messages that are sent to alert administrators of this 4^th mac addresses, the port simply just prevents the traffic.

2.     Restrict – This is like protect in that it stops traffic from mac addresses that isn’t configured for the port. It also does an additional action by telling someone if there is a violation. A violation would look like a machine with 4^th mac address plugged into the port, when that port is configured to have 3 mac addresses on it. As soon as this machine is plugged in and tries to communicate, the port will not recognize the mac address and will send an alert to the proper administrator of this violation. Additionally counters are incremented of the violation.

3.     Shutdown – This has the same principle as the previous two ports. With this mode, traffic is still denied if there’s a violation. However, greater measures are taken by completely shutting down the port for a violation. Like Restrict Mode, this will also send SNMP alerts and increment counters.

It may be helpful to note that I have also seen Shutdown VLAN added to this list if a violation occurs.

To differentiate the appropriate mac addresses to be allowed on a switch, there are also three primary modes that can be configured for this. By default, switches are configured to have one mac address per port. But this can also be configured with the help of three primary modes:

1.     Dynamic – Mac addresses are learned without any manually configuration. If a port is set to have 4 mac addresses, dynamic mode will learn and apply the first 4 machines that are plugged into the port. Beyond that, a violation occurs. This is the default mode.

2.     Static – This mode requires that mac addresses are applied manually. If port security allows to have 3 mac addresses on a port, then 1 mac address can be assigned manually, and also allow 2 more mac addresses allowed through dynamic mode.

3.     Sticky – Sticky is like dynamic and allows a direct save to the running configuration. So if the running configuration is saved to the startup configuration, when a switch is rebooted, the mac addresses remembered.

Port security can also be configured more specifically. Though any configuration of port security is only limited to access or trunk ports. So if a switch has a port that is dynamic and allows for either access or trunk ports, then port security cannot be configured here. If a port is either an access or a trunk port the configurations, and even more specific port security configurations can be made. More specific configuration include different capacities of mac addresses allowed on each vlan; what mode a vlan can have; and also aging the mac addresses out of the CAM Table.

The problem of the CAM Table Overflow attack can be defended with the proper implementation of port security. If the switch in our attack scenario was configured to have a violation of 2 before shutting down, and the CAM Table capacity was at 8000, when Kali executed macof, nothing would happen and the port would be shutdown. An alert would be sent to an administrator, and they would have to investigate this port before bringing it back up again.

Confidentiality Integrity and Availability vs Techman X

CIA is the acronym that boils down the basics of security - and no, I don’t mean CIA as in the intelligence organization. In tech, it’s a standard acronym that is Confidentiality, Integrity and Availability. It is the measurements that determine security in an environment. If these measurements look good in your environment, you can feel good that the bad guys will do no harm. In this post I’ll give a briefer through examples with Techman X.

Confidentiality

A bad guy, Techman X, learns that Gym A puts their customers’ credit card information on one particular laptop. Techman X thinks, “Aha! My recon work is done. If I get my hands on that laptop, I can steal other people’s credit card information.” One evening, Techman X tip toes into the gym. While no one is looking he snatches the laptop, and sneaks out! “Success!” so he thinks.

Techman X is a pretty smart guy. He knows how tech stuff works. So later that evening, he grabs one of his fancy forensic tech tools. The tool should allow him to see what’s in the laptop without the password. But a surprise hits Techman X. When he attempts to pwn the laptop, he’s stunned at what he sees… Giberrish… The data in the laptop is jumbled up.

This is confidentiality. It is the idea that allows for credit card information to be kept secret for Gym A. Encryption falls into this category, and was the saving defense for Gym A – it made the data look like gibberish.

Other aspects to confidentiality, also include authentication. Users can access secret information if they have authorized credentials such as a username and password. Some companies also use smart cards to authenticate. This gives an extra layer of security by having a physical item as a prerequisite to access.

Integrity

This topic is based on reputation. Can the data that you have be trusted? Or has it morphed into something evil? Perhaps. Well, at least in the next scenario with Techman X it has.

Techman X decides to use an executable to steal credit card information. On a Saturday morning, he poses as a patching technician that corporate sent to Gym A. The local IT guy at Gym A is weary because he hasn’t been informed about this surprise visit. Techman X tries to ease the local IT guy’s nerves, “It’s all good, I don’t have to stay. You can perform the patching. Here’s the regular OS update from Big Company.” Techman X hands the local IT guy the usb with the patch from Big Company’s OS update. The patch is an executable and it looks legit.

When the surprise visitor leaves, local IT guy takes off his glasses and dons the blue cape. BlueTeamTech goes into action. He goes to Big Company’s website to see that the executable’s name is legitimate, patch.exe. That checks out. BlueTeamTech has abilities that are out of this planet, so he doesn’t stop there. He checks to see if there is a hash for the executable. Behold, Big Company has the hash.

BlueTeamTech goes to his isolated sandbox, and navigates to the terminal and types:

cd D:

certutil –hashfile patch.exe

The terminal spits out a hash. BlueTeamTech checks to see if it matches with Big Company’s hash. It doesn’t. BlueTeamTech immediately destroys the isolated sandbox and reports the usb incident to proper authorities.

Integrity checks beyond what seems reputable. In this case, the patch, looked legitimate. But at a closer look shows it wasn’t. The data couldn’t be trusted.

Availability

Backups and throughputs could sum up availability. These two components allow continuous use of data. Backups allows continuous use of data if previous data happens to become corrupt. Throughputs allows continuous use of data, by making sure there is no obstacles in the way to get to the data (ie network latency).

With this example with Techman X, I’ll explore the throughput side of availability.

Techman X is at it again. His plans keep getting foiled. But this time, he thinks, “If I make my attacks more sophisticated, I will eventually steal the credit card information.” So he devises.

On his white board he draw out what he’s going to do. On the left side of the board, he draws 10 computers representing 1,000,000 other computers. On the right, he draws Gym A’s infrastructure where website credit card payments are processed. In the middle is Gym A’s main website IP, and his Man-in-the-Middle Server. His plan is to unleash a full scale distributed denial of service attacks from his unaware cavalry of 1,000,000 computers against Gym A’s website IP. This should bring it down. Meanwhile, he will enable his MITM Server to go live to replicate Gym A’s website. With the MITM Server, users who enter credit card information will now be visible to Techman X.

The Zero Day DDOS attack approaches and is executed. 1,000,000 unwitting soldiers fire shots of ping, and syn flood messages towards the website IP. Techman X’s eyes are wide with malicious hope. One minute goes by, and the attack rages on. Two minutes… Three minutes… Four minutes… Nothing is happening. His MITM server isn’t online, and customers are still able to use Gym A’s website. Techman X is infuriated, “It must be that darn local IT guy!”

It was that darn local IT guy. With network visibility, BlueTeamTech laughed as he saw the attack being thwarted by his sophisticated fortress. The network perimeter was built with next generation equipment. Stacked with Intrusion Prevention Systems, and load balancers in mind, the website was impregnable. Availability prevailed.

Actually Finishing the Certificate You Started On

Success in finishing any certification depends on commitment. But sometimes you stop studying and you ask is the certificate worth committing to? Maybe not. Other times, certificates will play into the next promotion or job. It then becomes a matter of pressing on.

It's grueling work to become certified. I know, because as of this writing, I'm there with you trying to get my next certificate. I also know, like my previous certifications, it'll be worth it.

During my previous certificate study processes, I found some key points that helped remind me that it's worth it. I'm hoping these points maybe useful to someone else. 

Social Accountability

If your social circles cheer you on, that's your best guarantee. There are reasons others are recognized for self achievements - it's because they were needed to push on. Social circles are the giants to stand on, if anything is going to get done. Stand on them like you have before.

You can get creative in what this looks like. Just be consistent, even if it's brief. Just telling close family and friends about your updates will help. Social media can also be a place where this can happen. You can post your status updates with your progress. But only if you don't forget to #blueteamtechblog  :)

Set Reasonable and Specific Goals

This speaks for itself. 

It's easy to get carried away sometimes with planning. For me, I dream big. Nothing wrong with that, but my time line usually looks like zero to CCIE in 3 months. Impossible. Reasonable means, you've got a good idea on how long it'll take based on small steps in the past. You've got to set reasonable goals. 

Along with reasonable goals, being specific is helpful too. So that looks like this: finish the CCENT in 6 months by reading and annotating two chapters a month. You can make a check list out of that one. 

Study in Community

Go find people that are also studying. This also plays into the social accountability aspect, but this is more specific. It builds a lifestyle where you surround yourself with minds that are doing what you're doing. They understand your motivation and help you remember it.

These community groups can be local, like a school, workplace or Meetup. You can also develop community on line through forums, and Slack.

I hope these three tips help. Happy studies!

11 - Provisioning User Rights

Some scenarios require users to have console access but not complete console access. In these situations, configuring the router to grant limited access is helpful. This lab will review how users are granted rights, more specifically the extended ping.

Step 1 - Configuring Extended Ping for User, Elliot

User, Elliot is created with password, toor. Elliot doesn't need privilege 15 rights that could allow global mode access or the command, configure terminal. However, Elliot does need privilege level 7 and extended ping.  To do this the command will process from enabling privilege level 7 with extended ping, then create user, Elliot, and finally show run to see that Elliot is associated with level 7 and extended ping.

From the R-1 Router:

configure terminal

privilege exec level 7 ping

username elliot secret toor 

username elliot privilege 7

do show run | inc username

Step 2 - Showing the Autocommand Function 

The autocommand function limits Elliot to log into the router and only perform extended ping. Once ping is complete, Elliot is kicked out of the terminal. This requires Elliot to log back in after performing the extended ping. 

While still at global mode, the configurations will first enable autocommand. Then Elliot will telnet into the router's ASAv facing interface G0/1 10.1.0.1. Once telnet is a success, extended ping is available. The ping test will point to the inside ASAv interface with IP 10.1.0.250. Once completed, notice that Elliot is kicked immediately out due to autocommand. This is also verified via who. If Elliot were still logged into the terminal, Elliot's username would show under the who command. Then write is issued to save running the configuration.

username elliot autocommand ping

end

telnet 10.1.0.1

elliot

toor

[enter for protocol]

10.1.0.250

[enter for the rest of extended ping setup]

who

write

Step 3 - Introducing Nohangup

Nohangup allows Elliot to have a suspended session in the terminal without being completely booted after the extended ping. After Elliot finishes the extended ping, he can retype his username and password again, instead of having to telnet again.

Once nohangup is configured and exampled, notice how when the ping completes, the user prompt comes back.  

configure terminal

username elliot nohangup

end

telnet 10.1.0.1

elliot

toor

[enter for protocol]

10.1.0.250

[enter for the rest of extended ping setup]

[notice how username pops up, instead of going back to the R1# prompt]

Step 4 - Configuring Elliot for Privilege 7 Only

Elliot will no longer be limited to extended ping and the be kicked back out. The next commands will allow Elliot to access level 7 privilege - meaning Elliot will still be able to use extended ping (which can't be used with level 1 privilege) but level 7 will not allow Elliot to configure terminal. After this is configured the configured is saved.

do show run | inc elliot

no username elliot

[enter to confirm]

username elliot privilege 7 secret toor

end 

show run | inc elliot

telnet 10.1.0.1

elliot

toor

who

exit

write

10 - Configuring SNMP Access

Router, R-1 will be configured to allow SNMP management coming from IP 192.168.14.132 - this is the SNMP management server (not shown in lab). 

The story for the commands below begins with allowing traffic from the SNMP management server. Then, group, evoolcorp is created for SNMP version 3 to allow read and write permissions. Next, user, admin is created into the evoolcorp group to authenticate using sha encryption, and privilege of aes 256 bit encrypiton with acl 1 applied. Show snmp is also shown to give a detail of what's going on with snmp such as bad packets. Lastly, these configurations are saved.

configure terminal

access-list 1 permit host 192.168.14.132

snmp-server group evoolcorp v3 priv read write

snmp-server user admin evoolcorp v3 auth sha toor priv aes 256 toor acc 1

end

show snmp

write

9 - Configuring Router Time and NTP Review

In this lab, the router time source will be configured to allow the authoritative and synchronized time to come directly from the local hardware. There will be a review of NTP configuration, but this will not be implemented in the lab.

STEP 1 - Configuring Router Time

Router time has three modes. 

1. Asterisk is non-authoritative
2. Period is authoritative but not synchronized
3. No asterisk and no period shows the router is authoritative and synchronized to the NTP (else, it is set manually)

Initially, the lab router R-1 is non-authoritative as shown by 

show clock detail

The asterisk is the giveaway that the router time mode is non-authoritative. After manually configuring the router, it will be left without an asterisk or period.

Here's the total configuration

show clock detail

configure terminal

clock time zone utc -5

clock summer-time edt recurring

end 

clock set 21:04:00 Aug 17 2017

show clock detail

write

Notice with the final show clock detail command, the router is manually configured. 

STEP 2 - Reviewing NTP Source

The router will not be configured with NTP. But it's handy to underatand how to configure synchronization to an available NTP server.

In the configuration below, the NTP server IP is left blank. But there are plenty of public IP addresses that can be used for NTP servers if a little googling is done.

configure terminal

ntp server [NTP Address]

end

show clock detail

show ntp status

The last two commands are just to show more information about what's happening between the router and the NTP server. As mentioned earlier you can see what mode the router is in regards to time by show clock detail; using show ntp status will give further detail about what's going on between the router and NTP server.