248 days uptime is bad for a Mikrotik running RouterOS below 6.34

November 14, 2016

I’ve some info for you, if you’re running Mikrotik RouterOS in a version below 6.34rc45 and are using a tunnel (like IPIP over IPsec). If you don’t boot the router for about 248 days, your router will get inaccessible. This is specially bad if your routers are in remote locations and you’ve got multiple routers with the same updates ( like > 100 😉 ) as you did the firmware update at the same time.

The changelog for the 6.34rc45 version states the problem, but it doesn’t tell you that the router is offline and can only be accessed via serial cable.

*) tunnel – fix complaining about loop after ~248 days;

If you look into the log via the serial port you’ll see

07:21:13 interface,info tunnel_1 link down
07:21:13 interface,info tunnel_2 link down
07:21:13 interface,info tunnel_3 link down
07:21:13 interface,info tunnel_4 link down
07:21:14 interface,warning tunnel_1 transmit loop detected, downing interface for 60 seconds
07:21:14 interface,warning tunnel_2 transmit loop detected, downing interface for 60 seconds
07:21:14 interface,warning tunnel_3 transmit loop detected, downing interface for 60 seconds
07:21:14 interface,warning tunnel_4 transmit loop detected, downing interface for 60 seconds

and nothing else. 😉

If you’re running an affected version you need to reboot before reaching 35 weeks or upgrade to a new version.

Howto live-sniffer traffic on a remote Linux system with Wireshark

October 2, 2016

You ask why you should need this at all? Easy, sometimes a tcpdump is not enough or not that easy to use:

• You want to check the TTL/hop count of BGP packets before activating TTL security
• You want to look at encrypted SNMPv3 packets (Wireshark is able to decrypt it, if provided the password)
• You want to look at DHCP packets and their content

Sure, it’s quite easy to sniffer on a remote Linux box with tcpdump into an file and copy that that over via scp to the local system and take a closer look at the traffic. But getting used to the feature of my Mikrotik routers to stream traffic live to my local Wireshark, I thought something similar must also be possible with normal Linux boxes. And sure it is.

We just use ssh to pipe the captured traffic through to the local Wireshark. Sure this is not the perfect method for GBytes of traffic but often you just need a few packets to check something or monitor some low volume traffic. Anyway first we need to make sure that Wireshark is able to execute the dumpcap command with our current user. So we need to check the permissions

ll /usr/bin/dumpcap
-rwxr-xr-- 1 root wireshark 88272 Apr 8 11:53 /usr/bin/dumpcap*

So on Ubuntu/Debian we need to add ourself to the wireshark group and check that it got applied with the id command (You need to logoff or start a new sesson with su - $user beforehand). Now you can simply call:

ssh [email protected] 'tcpdump -f -i eth0 -w - not port 22' | wireshark -k -i -

And now the really cool part comes. I’m using Ubiqity Unifi access points in multiple setups and I sometimes need to look at the traffic a station communicates with the access point on the wireless interface. With that commands I’m able to ssh into the access point and look at the live traffic of an access point and a station which is hundreds of kilometres way. You can ssh into the AP with your normal web GUI user (if not configured differently) and the bridge config looks like this

BZ.v3.7.8# brctl show
bridge name bridge id STP enabled interfaces
br0 ffff.00272250d9cf no ath0
ath1
ath2
eth0


You can choose one of that interfaces (or the bridge) for normal IP traffic or go one level deeper with wifi0, which looks like this

ssh [email protected] 'tcpdump -f -i wifi0 -w -' | wireshark -k -i -

That’s cool!?! 😉

Howto protect BGP router against DOS and injection attacks

September 17, 2016

It is good practice to configure an individual MD5 password for each BGP peer, but this is not enough. Why?

• Resource consumption attacks against TCP connections protected with MD5 as the router must verify the MD5 signature of packets it receives
• Many routers are based on Linux as there base operating system and there is a weakness which allows an attacker to insert arbitrary data into TCP connection. For more details click on this link.

The classical BGP TTL security is based on using a low TTL, generally 1, for single-hop BGP connections. The measure is effective in preventing a BGP connection from being established from a peer more than one hop away. Why? routers decrement the TTL when routing the packets and won’t route packets with a TTL of 1. So if your BGP session is a multi hop connection over one router a TTL of 2 makes sure the packet travels only over one router and not more. That sounds fine but has still has a drawback, as packets with a TTL of 1 are trivial to spoof, so rogue packets will still reach the router – leading to the problems described above.

GTSM (Global TTL Security Mechanism; RFC 5082, which obsolated RFC 3682) suggests the opposite approach. Instead of using a TTL value of 1, it suggests a value of 255 and discarding any packets received with have a TTL lower than 255 minus the hop count for this BGP session. Doing that an attacker is not able to perform the attack as the TTL gets decremented by every router (something the attacker can’t prevent). So setting the TTL on the router to 255 and having no multi hop BGP session allows to drop all packets on the receiving router which are lower than 255. This way only an attack in the same subnet is possible.

After the theory here the actual doing:

For Cisco routers is quite easy, just add ttl-security hops 1 (for a BGP session in the local subnet) to the peering config neighbor x.x.x.x command. For Mikrotik routers it is a little more complicated. For IPv4 connections configure following (should be default anyway):

/routing bgp peer set 0 ttl=255

For dropping incoming packets just use the firewall on the Mikrotik with a command like this:

/ip firewall filter add action=drop chain=input log=yes log-prefix="RFC 5082 block" src-address=xxx.xxx.xxx.xxx ttl=less-than:255

For IPv6 it is a little more complicated as setting the TTL for bgp peer configuration does have no effect (I’ve reported the bug already) but there is a simple workaround possible. Just use the mangle function of the firewall to set the correct hop count:

/ipv6 firewall mangle add action=change-hop-limit chain=output dst-address=xxx:xxx:xxx::xxx/128 new-hop-limit=set:255

Now you need only to filter the IPv6 packets:

/ipv6 firewall filter add action=drop chain=input log=yes log-prefix="RFC 5082 block" src-address=xxx:xxx:xxx::xxx/128 hop-limit=less-than:248

This configuration is quite easy and minimal invasive but should help a lot against attacks on your BGP routers.

Ready your home network for IoT

July 2, 2016

I’ll keep reading about the whole Internet of Things (IoT) but something I see missing is the security aspect. Sure there are white papers and article out there how an enterprise should deploy IoT in a secure way, but not much for home and SOHO networks. In this blog post I’ll address the problems of current IoT devices and what you can do to mitigate them.  I’ll concentrate on typical IoT devices used/designed for home users.

Why the security of IoT devices sucks

Just remember one mantra – IoT devices suck at security – and here is the why.

• Many of these devices are build by Start-ups, which have one goal. Get the product out as fast as possible and get the company bought by someone and hit pay day. Even if not, they need to get enough revenue first and to start than fixing the security problems.
• If the device is not build by a Start-up than it got build by an established manufacturer in the area the IoT device is build for. The problem is the manufacturer has no idea about connected devices and that Internet stuff – Its called “Neuland” :-). They will make every error the IT industry did 10-15 years ago. Yes, if you’re that long in the business as I’m you’ll see the same security holes you saw in the first years of this millennium for normal PCs now for IoT devices.
• Usability and security is not easy .. so most of the time the easy to use and insecure variant is used
• If the IoT device is for a semi established area like IP cams / baby cams the devices are build and designed by a Chinese company and sold under various labels. The company selling the devices does not know anything about the internal workings. If a security problem is found and somehow the OEM vendor in China fixes the problem, you’ll wont get an update from the company that sold the devices.
• Automatic updates of the devices is not the norm, so most devices wont get any updates. While in the PC marked it is for years now common that  software get updates automatically, the same is not true for most IoT devices. And lets be honest who is checking for security updates of the light bulbs on a regular base?
• But before we can talk about automatic updates lets don’t forget that for most IoT devices you’ll get updates only for a short period of time. The vendor wants to sell his next product, so why support the old one? To make the problem bigger most IoT will get used longer than a typical mobile phone, which also suck at security update time frames. No one will replace his/her IP cam every 2 years like a mobile phone (ok, that’s also not true, but its typical a shorter interval)
• UPNP was a bad idea and still is one. Some IoT automatically open ports from the internet so any security flaw can be exploited directly from anywhere in the world. Oh, joy! 🙂
• Even if the device does not use UPNP it often connects per default directly to a cloud service, over which you (and potentially an attacker) can access your device. e.g. accessing the baby cam via the mobile phone app via and cloud service. There have been some horrible security flaws in the past, like a consecutively numbered ID without password or the MAC address of the device as ID (really heard the guess an MAC address if you know the vendor ID 😉 ).

There are some more points I could made, but these should be already depressing enough.

ps: yes, there are some IoT devices with good security but these are less than 5% of the total market.

Theoretical mitigating the problems

As we’ve established that the security is not good, we need ways to mitigate the problem, within the scope of a home network. To be honest that can’t be done by your typical mum, but needs some one technical minded – but others would not read my blog anyway.

Securing or hardening IoT devices is sometimes possible but for most consumer ones that won’t work. So lets accept that the device will have security problems. In some cases that will be a big problem in its own right, e.g. a IP cam that can be watched from anyone world wide. In other cases e.g. a light bulb that can be controlled from anyone world wide is more a nuisance that a real problem. The same is true for weather station that is readable world wide.

For the first case there is nothing that can be done on the network level as general rule, as disabling the Internet connection for the device will prevent it from working in the first place. Sure there are cases where the cloud connection is not needed, in these you can deactivate or block it. But for the second case there is something. Let’s assume the attacker got access to the IoT device, which is by itself in this example case not that bad, surely a nuisance but not a big problem. The problem arises now from the fact that the IoT device is controlled by the attacker and what he can do with that. So lets look at some possible scenarios.

• If the device is connected via WiFi the attacker has now the WPA2 PSK key from your WiFi.
• If the family NAS provides the shares without username/password an attacker can access it
• Maybe the router can be configured without a secure password or has also a weakness. The attacker can use this to change the DNS servers to allow MiTM attacks
• ARP spoofing and similar attack are also possible.

To guard against that attacks you need to segment the IoT network from your normal network, even better isolate the various IoT devices from each other.

Practical mitigation – three stupid routers

The segmentation can be achieved in various ways. The first one needs only standard routers …. just more than one … you need 3 routers. Lets take a look at the diagram:

The first router is often provided by the cable or telephone company and you need to buy 2 stupid/cheap routers behind it. One is for the normal internal network and one for the IoT devices that connect a cloud service. For the IoT device router configure the WiFi in client isolation mode (if possible). As both (internal and IoT) routers masquerade their clients a direct connection is not possible. If a connection should be possible a port forwarding needs to be enabled and also make sure that the IP subnets are different.  If one IoT devices gets compromised it can not leak the internal WiFi password as it does not have it. Also accessing the NAS is not possible as the ARP spoofing is not possible. Use the provider router for guest which should not be able to get anything except Internet.

The setup is quite simple and also cheap but has its short comings:

• Works only for apartments and small houses – if you need more than one access point for you’re house it does not work.
• You need multiple routers, which need more power.
• You lack flexibility

Practical mitigation – intelligent router / access points

If you move away from the typical stupid routers you can make use of the more advanced features. The exact setup depends on the used network devices, so I’ll can only show a possible setup. Following requirements need to be met by scenario setup.

• Three floors, each with its own access point
• IoT and internal devices in each flow, cable and wireless connect ones (multiple SSIDs on each access point)
• Clients want to move within the building without loosing connection (same SSIDs on all access points)

Just to make it clear, there are other setups possible to fulfill the requirements. Following diagram shows the possible setup.

The router or firewall (could be a router like a Mikrotik or a pfSense firewall) is the gateway for all 3 networks (yes, I through a guest network in for good measure 🙂 ). On it the policy which network is allowed to connect to which other network is configured. All three networks are connected to the managed switch (if the router has enough ports it may can fulfill the role of switch too).  On the switch most ports will be configured for one VLAN but the ports to the access points get all three VLANs.

The access points get configured in way that the management IP address is in the internal VLAN and a separate SSID is used for each VLAN. All access points use the same SSID for the same VLAN, so roaming for the clients is possible. Set the SSID for IoT and external use to client isolation mode (one wireless client can’t communicate with an other)

Optional, if the the switch supports it. Configure private VLANs for the IoT and external network, so only the router can talk with all devices

I hope this blog post shows you the basics for readying your home or maybe SOHO network for IoT devices which will surely come.

The insecurity of the building automation system KNX

April 29, 2016

Today I’ll write a completely different security blog post to which I normally write. This one is about KNX – I’ll guess most readers (which are largely IT people) don’t even know what it is about. Here from Wikipedia:

KNX is a standardized (EN 50090, ISO/IEC 14543), OSI-based network communications protocol for building automation. KNX is the successor to, and convergence of, three previous standards: the European Home Systems Protocol (EHS), BatiBUS, and the European Installation Bus (EIB or Instabus). The KNX standard is administered by the KNX Association.

(Source: https://laughingsquid.com/tetris-building-hack-at-mit/)

 

Now you’re asking why I’m writing about it and why I wrote it’s a security blog post? The KNX standard is now getting whitely deployed in Tirol in new office buildings and even is used on bigger renovations of these.  Most of these deployments are done by civil and electrical engineer, which don’t think (care?) about IT security. And as it is a network communication protocol and is often connected to the IT network of the company someone in the company should think about it.

KNX Basics

So let’s starts with the basics. The most common form of deploying that network (called KNXnet sometimes only KNX) is over a two wire bus (twisted pair, called KNXnet TP) which is routed in parallel to the 230 V electrical power supply KNXnet connects all devices and systems of the building. To make the list complete following media are possible:

• TP: twisted pair
• PL: power line (over the normal 230V lines)
• IP: Internet protocol
• RF: wireless

The network speed is 9600 bit/s and following device groups get normally connected to the network:

• Sensors (e.g. push buttons, wind-, temperature-, movement-sensors)
• Actuators (dimming units, electrical heating valves, displays)
• System devices and components (e.g. Line-Couplers, Backbone-Couplers)

Most often the system is used to automate the building (turn all lights of if no one is in the building, move the blinds up and down), but there are also implementations which are more in the direction of alarm systems.  In a security respect that means that everywhere any device, which is connected to KNX networks, is located (outside?) an attacker can get access to the network.  In any case if the system/building is larger the building manager would like to configure the system via his working PC, which leads to a connection to the IT network. This a common case so the “The KNX standard – the basics” shows following diagram:

And yes, you’re reading that correctly, the KNXnet can be tunnelled over IP and therefore over Ethernet, which leads also to following setups:

But lets keep looking at the KNXnet more directly. Setting up the KNX network is possible via 3 bus topologies:

These topologies can be mixed as needed, but no ring is not allowed. As the line and star topology are a subset of the tree topology, the tree topology is the most flexible one and used in most bigger installations. The network IDs of a given nodes is based on its location in the tree (and looks like that 1.5.1), more information can be found here. Following diagram from the “The KNX standard – the basics” shows a full network over various media. The white boxes are the networks IDs of the various devices connected.

building automation security

As we now know how the system works in basic lets take an overview look why building automation sucks at security.

• Default passwords: Yes, you’ll see building automations systems in the wild with default passwords. If set a different one it won’t comply to the password policy of the company.
• No authentication: Be it for users or devices
• No encryption
• Management system reachable from the Internet (e.g. for easier support from the vendor)
• Back door access: Some vendors deploy UMTS/LTE routers and connect via them to the system. This is often done if the system has problems in the first years of the deployment. e.g. most often seen for heading systems … a high percentage seems to have problems in the first years)
• No separation from the normal PC IT network

And these points are mainly because the building automation is not part of / controlled by the company IT department and therefore not on the radar of the IT security staff.

KNX specific problems

So now lets look at some KNX design problems. KNX providers filters on the line couplers to limit the load on the network. These provide a feature like TTL the field in the IPv4 packets do. But if you use a routing counter of 7, that goes through every filter. This allows to send packets from a subsidiary line (does not matter where you’re connected to the network) to the complete network. You just need to capture a packet (or guess one) which tells all lights to turn off (to show something harmless ;-)) and resend it at a later time with a routing counter of 7 to turn every light in the building of. Spoofing of the network id is simple, just choose one … good luck finding the place where the bad device is – it could be anywhere in (or even outside) the building and it can completely control it. Take a look at following sides from a presentations at BSidesVienna 2014 to get to know many more problems, like code injection to the ETS software and so on. So attacking the IT network over it is also possible .. maybe the ETS software runs in the same networks as you’re other servers? Its really broken from a security stand point.

Hint: KNX for hotels is also quite common and every guest room has access to the KNX network. Just saying – don’t do it 😉

Hint 2: If someone tells KNX provides security features like a password. Reply: Yes – sure …. it’s optional and its a 4 (in words “four”) byte password transmitted in clear text … really hard to sniff or guess  ;-).

KNX software

Following software can be used to play with KNXnetworks

• eibd (alternative URL) a guy from the TU Vienna.

Concussion

If you’re in an IT security roll at the IT department you most likely cannot circumvent the installation of a KNX bus, but make sure that the system does not allow any attack vector against your services and systems. Think about it like an external IT network, you need to protect your systems against it (e.g. Firewall, network separation, …) . Make the normal security checks of the devices directly connected to your network (nmap, openvas scans, check used passwords, software versions, ….)  and make sure that its clear (in writing 😉 ) who is responsible for maintaining the KNX network it’s security – its not your.

If you’re a building manager … talk and listen to the security guys from your IT department. They fight every day against attacks and know how to mitigate security problems.

 

 

Block Ransomware botnet C&C traffic with a Mikrotik router

March 14, 2016

In my last blog post I wrote about blocking, detecting and mitigating the Locky Ransomware. I’ve referenced to a earlier blog post of mine which allows to block traffic to/from the Tor network. This blog post combines both – a way to block Ransomware botnet C&C traffic on a Mikrotik router. The base are the block lists from Abuse.ch, which also provide a nice statistic. Locky is not the most common Ransomware today.

Linux part

You need also a small Linux/Unix server to help. This server needs to be trustworthy one as the router executes a script this server generates. This is required as RouterOS is only able to parse text files up to 4096 by itself, and the IP address and domain list is longer.

So first we create the script /usr/local/sbin/generateMalwareBlockScripts.py on the Linux server by downloading following Python script. Open the file and change the paths to your liking. The filename path works on CentOS, on Ubuntu you need to remove the html directory. Now make the file executable

chmod 755 /usr/local/sbin/generateMalwareBlockScripts.py

and execute it

/usr/local/sbin/generateMalwareBlockScripts.py

No output is good. Make sure that the file is reachable via HTTP (e.g. install httpd on CentOS) from the router. If everything works make sure that the script is called once every hour to update the list. e.g. place a symlink in /etc/cron.hourly:

ln -s /usr/local/sbin/generateMalwareBlockScripts.py /etc/cron.hourly/generateMalwareBlockScripts.py

Mikrotik part

Copy and paste following to get the IP address script onto the router:

/system script
add name=scriptUpdateMalwareIPs owner=admin policy=ftp,reboot,read,write,policy,test,password,sniff,sensitive source="# Script which will download a script which adds the malware IP addresses to an address-list\
\n# Using a script to add this is required as RouterOS can only parse 4096 byte files, and the list is longer\
\n# Written by Robert Penz <[email protected]> \
\n# Released under GPL version 3\
\n\
\n# get the \"add script\"\
\n/tool fetch url=\"http://10.xxx.xxx.xxx/addMalwareIPs.rsc\" mode=http\
\n:log info \"Downloaded addMalwareIPs.rsc\"\
\n\
\n# remove the old entries\
\n/ip firewall address-list remove [/ip firewall address-list find list=addressListMalware]\
\n\
\n# import the new entries\
\n/import file-name=addMalwareIPs.rsc\
\n:log info \"Removed old IP addresses and added new ones\"\
\n"

and copy and paste following for the DNS filtering script – surely you can combine them … I let them separated as maybe someone needs only one part:

/system script
add name=scriptUpdateMalwareDomains owner=admin policy=ftp,reboot,read,write,policy,test,password,sniff,sensitive source="# Script which will download a script which adds the malware domains as static DNS entry\
\n# Using a script to add this is required as RouterOS can only parse 4096 byte files, and the list is longer\
\n# Written by Robert Penz <[email protected]> \
\n# Released under GPL version 3\
\n\
\n# get the \"add script\"\
\n/tool fetch url=\"http://10.xxx.xxx.xxx/addMalwareDomains.rsc\" mode=http\
\n:log info \"Downloaded addMalwareDomains.rsc\"\
\n\
\n# remove the old entries\
\n/ip dns static remove [/ip dns static find comment~\"addMalwareDomains\"]\
\n\
\n# import the new entries\
\n/import file-name=addMalwareDomains.rsc\
\n:log info \"Removed old domains and added new ones\"\
\n"

To make the first try run use following command

/system script run scriptUpdateMalwareIPs

and

/system script run scriptUpdateMalwareDomains

if you didn’t get an error

/ip firewall address-list print

and

/ip dns static print

should show many entries. Now you only need to run the script once a hour which following command does:

/system scheduler add interval=1h name=schedulerUpdateMalwareIPs on-event=scriptUpdateMalwareIPs start-date=nov/30/2014 start-time=00:05:00

and

/system scheduler add interval=1h name=schedulerUpdateMalwareDomains on-event=scriptUpdateMalwareDomains start-date=nov/30/2014 start-time=00:10:00

You can use the address list and DNS blacklist now in various ways .. the simplest is following

/ip firewall filter
add chain=forward comment="just the answer packets --> pass" connection-state=established
add chain=forward comment="just the answer packets --> pass" connection-state=related
add action=reject chain=forward comment="no Traffic to malware IP addresses" dst-address-list=addressListMalware log=yes log-prefix=malwareIP out-interface=pppoeDslInternet
add action=reject chain=forward comment="report Traffic to DNS fake IP address" dst-address=10.255.255.255 log=yes log-prefix=malwareDNS out-interface=pppoeDslInternet
add chain=forward comment="everything from internal is ok --> pass" in-interface=InternalInterface

If a clients generates traffic to such DNS names or IP address you’ll get following in your log (and the traffic gets blocked):

20:07:16 firewall,info malwareIP forward: in:xxx out:pppoeDslInternet, src-mac xx:xx:xx:xx:xx:xx, proto ICMP (type 8, code 0), 10.xxx.xxx.xxx->104.xxx.xxx.xxx, len 84

or

20:09:34 firewall,info malwareDNS forward: in:xxx out:pppoeDslInternet, src-mac xx:xx:xx:xx:xx:xx, proto ICMP (type 8, code 0), 10.xxx.xxx.xxx ->10.255.255.255, len 84

ps: The Python script is done in a way that it easily allows you to add also other block lists … e.g. I added the Feodo blocklist from Abuse.ch.

Tips on how to provide a secure public WiFi hotspot – Part 3

February 4, 2016

This the last part of the the series “tips on how to provide a secure public WiFi hotspot”. In the first two parts we concentrated on the wireless and layer 2 and 3 part, this time we take a look at the application layer stuff you should tune to provide a secure hotspot.

Captive Portal and non HTTP traffic

If you want or need to show the user a website before he is able to surf the web, you should not only think about redirecting HTTP to your landing page.  You should reject (send an ICMP error) for all other TCP connection attempts. Why? Many pages are nowadays HTTPS and letting the user wait for a time-out is not nice. Sure technical minded user will not wait, but others may do. Sure this is not a security advice but an usability one. But it does work nice together with following: Don’t try to provide your own TLS certificate to redirect traffic to the captive portal. Users should not be trained to accept error messages and ignore them and it will give your hotspot an bad look security-wise.

There is just nothing you can do to redirect HTTPS URLs. Just make sure that the captive portal detection of modern operating systems work and so the user is told there is a captive portal.

HTTPS for captive portal

If you require any data from the user except accepting the terms of service your captive portal should be HTTPS.  Get an official DNS name for your portal, e.g. portal.<company>.com and a valid TLS certificate. As there are multiple methods for getting free TLS certificate e.g. startssl or let’s encryt, you should get a real one. One thing that is important to whitelist for your captive portal are the OCSP and CRL URLs of your certificate, issuing CA and root CA. To check for the URLs look at the certificate details for all certificates in the chain of your captive portal. Following images show the 2 places for google.com (you need to check also the Google Internet Authority G2 and GeoTrust Gobal CA in this case.)

Why, you ask, you should whitelist these URLs? The browsers will check them before showing your captive portal site. Some/Most browsers will fail open, but some will fail close.

Limit and monitor the DNS

If the user has not past the captive portal his only way though the firewall will be the DNS server. You normally need to resolve the requests to the true IP address to guard against problems with false cached DNS entries after the user past the captive portal. As the user is able to craft the requests as he likes it is possible to send data through to a 3rd party DNS server. This setup can be used as DNS tunnel – it will be not fast but its possible to work through it. As nowadays simple howtos like following and OpenSource tools are provided, consider it easily possible for most power users – its not a expert thing any more.

So now comes the question what you can do against it. In this case you don’t need to block the covert channel of sophisticated malware but just script kiddies that want to tunnel through. Your typical user will only need A and AAAA query types. Tunneling is mostly done via TXT as it allows big packets. Following query types are common:

• Any
• A
• AAAA
• CNAME
• MX
• NS
• SOA

I won’t go into too much detail, but blocking can be done on the DNS server … e.g. if it is a Windows DNS Server (Allow only certain QTypes) or with the Firewall in this case iptables.

Content Filtering via DNS

Often you’re required to filter certain traffic but don’t want to setup and maintain a transparent proxy or with all the HTTPS it does not help that much any more. An easy way is to use the OpenDNS system, which allows to select certain categories which are then blocked on the DNS level (Query will resolve to an error page) . If you redirect all port 53 traffic to your DNS server which uses the OpenDNS ones as recursive DNS servers you should be good for most cases.

SMTP

Just reject (blocking lets the client run into timeouts) TCP port 25, otherwise infected client systems will flood your bandwidth with SPAM mails.  A mail agent should not send mails to the mail server via port 25 anyway.

I hope this article series helped you and leads to more secure hot spots I’m also able to enjoy. 😉

Decoding SNMPv3 encrypted traffic in Wireshark

January 7, 2016

Talking with fellows about SNMPv3 I hear often that its not that critical that SNMP is encrypted and that encryption makes debugging more complicated as they can’t see what is send over the network.I won’t talk about the need for encrypting SNMP as it is like SSH gets used instead of Telnet. This post shows how easy it is to decode SNMPv3 encrypted messages with Wireshark (if you know the secrets 🙂 ).  This is possible as SNMPv3 is a simple UDP protocol which encodes the packets with a shared secret and does not use forward secrecy like TLS does.

If you take a look on properly encrypted SNMPv3 traffic it looks like this.

Now you just click on “Edit | Preferences”:

Search for “Protocols | SNMP” and click on “User Table | Edit”.

Click onto the “New” button:

 

Now enter your user name, select the authentication and encryption method and provide the 2 passwords. You don’t need to provide the Engine ID normally.

After clicking onto Ok multiple times the traffic looks like this:

If you use one SNMP profile for multiple systems its nice that the values get stored in the Wireshark preferences.  Hope this takes some fear away from SNMPv3. 🙂

 

 

 

 

Tips on how to provide a secure public WiFi hotspot – Part 2

December 7, 2015

So lets start with tips on how to provide a secure public WiFi hotspot part 2. In the first part we concentrated on the wireless part, this time we take a look at the some layer 2 and 3 stuff you can do to protect your hotspot and your clients.

client 2 client traffic again

Yes, I know I’ve written about hat in the first part. But this was on the wireless side. Many access points block the traffic coming and leaving on the wireless interface but not traffic coming or leaving on the wired side.  So it is possible to think of an attacker finding it’s victims not on the same access point but on others in the same layer 2.  There are multiple way to achieve that once you think about it:

• Lets assume your client networks are all in 10.0.0/16 and you’re servers are in 10.1.0.0/24. You can simply filter with an ALC on the access points or switches which drop traffic where the source and destination host is within 10.0.0/16.
• If you’re using a VPN on you’re access points to tunnel the traffic back to a central controller, just don’t bridge/route traffic between them.
• If it’s one simple layer2 network on one switch, take a look at PVLANs. Many low cost managed switches have this feature.

Enforce DHCP usage

I’ve written a full blog post on why and how to enforce the usage of DHCP in any client network. Its even more important in an public WiFi setting. Following benefits are the most important in this setup:

• Protection against simple ARP spoofing
• That a client configures a fix IP address which an other client got via DHCP – be it by accident or malicious act.

Additionally to the example in the linked blog post, here is one where a Mikrotik router is the default gateway and DHCP server in a client network.

Disable the ARP learning on the router
/interface ethernet set 1 arp=proxy-arp

configure the DHCP server to add dynamic ARP entries
/ip dhcp-server set 1 add-arp=yes

Control the uplink bandwidth

This one is not directly a security point, but without it a user can use up all bandwidth and deny other clients access to the internet. I won’t stop long here, just use something similar like the PCQ on Mikrotiks. This will provide a fair distribution between the clients without looking at the traffic itself and classifying it. So you’re within the net neutrally rules if that matters for you.

Management of your devices

Make sure that no management interface of your devices is reachable via the customer/client networks. The easiest way to achieve this is to use a separate management network and make sure the management services of the devices only listen on this network. For access points it could be as easy as using the untagged VLAN to the switch for management and send the client traffic only as tagged traffic to the switch.

If this is not possible in your setup, make a least sure that a local firewall on the devices allow only administration from specify source IP addresses (e.g. the IP of your central management system, or the VPN IP range you use the remotely log into an router).

no default logins and encrypted management

This should be an no-brainer (but I’ll add it here so no one can say it was not on the list), but I’ve seen access points with the SNMP community public in the wild. And choose ssh over telnet and HTTPS over HTTP for management. Won’t write more lines about that basic stuff.

monitor the network traffic

Most routers provide plenty of data via netflow or sflow. Capture that with software like Ntop (open source)  or a commercial offering. Look at the traffic what is normal and what is not. An example for something like this would be if the average packet sizes goes way down for a client it is likely it is scanning something with a tool like nmap or zmap.  ps: Taking a look at the TCP retransmissions also helps to monitor the quality of your service.

After this layer 2 and layer 3 stuff only one part is still open for this series – the application level stuff. Stay tuned.

 

Tips on how to provide a secure public WiFi hotspot – Part 1

December 1, 2015

As I was travelling a little bit in the last few months I came across many public WiFi hotspots and most of them where not that good from a security perspective. So I thought lets write some articles with tips on how to build a secure public WiFi hotspot. This article is not for the end user on how to connect securely to a hotspot, but how to provide a secure hotspot.

The first part of this series talks about the wireless part and how to secure it, following posts will talk about other measures to secure your hotspot. So lets start with the security of the data transmitted over the air.

Encyption of the WiFi Traffic

All most all hotspots I cam across did use unencrypted WiFi , the exception where small hotels which used WPA2 PSK on the SOHO Router and told the guest the password at check in. From a security standpoint using WPA2 PSK with one password for all guest is better than an open network. Why do you ask?

1. With an open WiFi its trivial to sniff the traffic of other guests and if there are no other protections in the network a man in the middle attack is simply possible. There are really simple to use tools for “normal people” like Firesheep.
2. With WPA2 PSK each client gets its own session key during the association process. An attacker needs witness the associaton to eavesdrop on the connection. It is possible my an attacker to force a reassociations, by faking a disassociation packet in the name of the target.The disassociation packet attack is an attack at its own, we’ll talk later about it. With Wireshark you can decrypt all traffic if its sees the association process.

So using WP2 PSK is not perfect but its better than nothing. It is even easy to implement in some cases like in a hotel setting. Put the password in the folder in the guest rooms or tell it the customer at check in / arrival – so you can promote your service too.  An other way is to provide two SSIDs one named “Public WLAN open” and one “Public WLAN wps2psk” and tell the user on a captive portal site (if you have/need such an site anyway) to change to the encrypted one for more security.

Ok, that basic security but, you can do better.  Some hotels print a username and password on the receipts which you get on check in. You than need to connect to a insecure wifi and need to enter that in a HTTP website.  Some hotels also just tell you to use room number as username and your family name or your birthday as password, yes again over an insecure network and over HTTP … ok I’ll stop with the rumpling.

If you provide the user already with a custom login – why not use PEAP or EAP-TTLS to secure the log in.  The user chooses the network and gets prompted with an username/password dialog.  For this you need to run an RADIUS server against which the Users authenticates, with FreeRadius, which is provided with all major Linux Distributions, its quite easy, even on embedded devices using with OpenWRT. Such a setup is maybe not the best way for a small hotel, but for a big hotel chain, with a central IT department which already prints the login data on the invoices, this should be easily possible.  And if the marking persists (the legal stuff could be on the invoice .. as nobody reads the backside anyway) on a captive portal page, just make one where the terms of service needs to be accepted and put some nice marketing images there. 😉

There is also a way for you to use WPA2 Enterprise with PEAP / EAP-TTLS and the newer EAP-PWD  if you don’t know the customers and just want to provide a more secure WiFi. Just tell every user the same username / password – as with WAP2 PSK. With FreeRadius its even possible to accept any username / password combinations. With PEAP that works for most clients but not all of them as the returning hash is not correct, but for those the written down username/passwords works.  For example at the biggest European hacker congress from the Chaos Computer Club that setup was used 2 times already with over 9000 attendees.

Just to be sure to tell it. The use of PEAP is not recommend for authenticating users for an internal network (e.g. with BYOD) – Why? It is possible to intercept the wireless traffic using a roque accesspoint using the same (company) SSID-name and tools like freeradius-WPE and cloudcracker.  But for a free / cheep public WiFi it does seem to an common attack route.

At the end of this chapter I’ll provide you also with a really secure setup (that’s what you want to read if you read my blog? Yeah ;-)), which is not that easy to setup but makes sure you know the user which connect to your network – even if its free to use but you’re required to know the user by law.  I’ve not seen this setup in the wild, only told about it by a college.

1. Provide an open WiFi which only gets you to an HTTPS page where the user can enter his/her phone number
2. Generate a TLS key/cert in a format the mobile browser accepts and encrypt it with an random password
3. Send the password via SMS to the user
4. Let the User download the key/cert
5. Tell him to connect to the secure WiFi with the certificate.

As told above that’s not easy to do … but secure ;-). You can also provide the decrypt password via the HTTPS page, but than you can’t identify the user, but maybe that’s not necessary in your case. This solution is only workable if the user does this once and uses your Internet connection for a long time. e.g. you provide public Wifi in a public transport vehicle for commuters.  Otherwise I would stick with the WAP2 Enterprise and EAP-TTLS and as compatibility with PEAP.

rouge access points

Rouge access points in this context are devices an attacker normally uses near your hotspots with your SSIDs to get clients to connect to them. Specially if the WiFI is open or only secured with a know WPA2 PSK it’s easy to do so. Clients which have in past already been connected to your network will often connect automatically to the rouge access point using your SSID. If the attacker does a NAT and connects to your hotspot as client most users will not see a difference and their whole network traffic can be intercepted.

Most enterprise access points provide a feature to at least monitor for rouge access points and alert you if they see your SSID with an BSSID not from your access points. This helps but does not guard completely against it. To get the best protection against that attack you need to use EAP-TLS (certificates for every client – internal wifi setup) oder EAP-TTLS (certificate only for the RADIUS server and username/password for the client). But if the client does not validate the RADIUS server certificate (and there is no common name to check against, only the CA) you can’t prevent that attack, you need to monitor for it and act than.

Following measures can be taken to detect such access points on your network:

• Compare MAC addresses against know vendor IDs. An Apple or Samsung vendor looks more like a mobile phone than a Cisco or Mikrotik one as a client in your hotspot.
• Run an nmap finger print scan against new MAC addresses .. if the OS guess flags it as a WAP, or “Wireless Access”  take a look, also take a look at the open ports … telnet and ftp or snmp (with default community) are not common for phones. 🙂
• Look at the traffic with IDSes like Suricata for a X-Forwarded-For field and User-Agent strings associated with proxies
• Detect when one IP address is presenting itself as multiple operating systems e.g. via different TTLs (Linux uses an different than Windows) .. Take a look at this paper and look also at this Linux netfilter module.

denial of service

Depending on the surrounding of your hotspots it is possible that an attacker wants to deny your customers the access to your public WiFi or use the attack to force the client to associate again with the access point to capture the session key. An easy way to do this is to send faked disassociation packets.  In 802.11w (rolled up in the 802.11-2012 maintenance release) a protection against this disassociation packets has been implemented and is called protected management frames. Check your access points for support of it. On the client side all modern Linux/BSD distributions support it, starting with Windows 8 the support is also enabled by default.

client 2 client traffic

There is commonly no need for one client to talk to an other client –> block that traffic. Sure you can and should put some text into your terms of service that the user should only connect the network with a secure system and that you’re not responsible for any attack, but there is no harm in providing the user with some additional security against direct attacks and ARP spoofing and there like. Many access points provide this feature, it is often called client isolation –> so that’s a quick win.

dhcp replies / answers

This is connected to filtering client 2 client traffic but I’ve seen that some access points block normal unicast traffic but let broadcast through. With such traffic an attacker can provide the target with an wrong IP address, which is often not filtered by the client isolation feature as it is not within the local subnet and so the access points does not think about it as local traffic. More detail on how I filter that traffic can be found here.

That was the wireless part – I hope it was informative – … the next part will go up the chain to Layer2&3 an application stuff. Stay tuned!

ps: If you’ve ideas to increase the security even more, post a comment! I’m sure I forgot something.