WannaCry happened and nobody called me during my vacation – I tell you why

May 18, 2017

I was since last Wednesday on a biking biking trip through Austria and Bavaria, when on Friday reading main stream media the world broke down with WannaCry. Ok, I thought sensationalism by the main media but now as I’m at home, I cannot believe what I read in tech blogs and the IT media. I won’t link all of them here, just the one I plainly can’t understand and to which I disagree in the strongest way possible – telling plainly patching is hard and we can’t do anything.

Lets start with how a WannaCry infection spreads through a company.

  • The malware needed to get into the company network – be it via open SMB ports (445 TCP) to the Internet and via Email. As I read through the articles its not 100% clear how the infection – lets assume both methods have been used for this post
  • In the second case a user clicks onto the attachment and the malware gets executed
  • Than it searches through the company network and tries with a RCE (remote code execution) to infect other PCs
  • It encrypted the local hard drive

Now lets talk why this should not have been any problem in your organization

  • Port 445 TCP reachable from the Internet? Really? If you’re unsure, quickly go to Shodan and type into the search field net:"xxx.xxx.xxx.xxx/yy" with xxx.xxx.xxx.xxx you IP address range followed by the yy subnet mask and take a look if you know about open ports and services.
  • And now lets take a look at all the stuff I wrote over a year ago, what you should have done before the Locky malware happened (yes this is not the first ransomware making big waves), to be not affected:Stop panicking about the Locky ransomware [Update 2]
    • For the Email infection vector:
      • Block EXE attachments in emails
      • Remove active code from Word, Excel and Powerpoint files by default
      • Block EXE downloads on the Proxy
    • For both  infection vectors:
      • Use application white-listing – we moved to whitelisting for firewall rules a long time ago, its past time to do that for applications. Guess why there is not so much iPhone malware – Apple is effectively white-listing software.
      • Block client 2 client traffic – Even if that is not possible on a day2day basis, it should be prepared to be enabled in a case of emergency.

    With one of the last two alone an widespread infection would not have been possible.

  • Microsoft provided a patch on March 14 and called the vulnerability critical. Lets take a look when Microsoft calls some vulnerabilities  critical and when important. The difference is that with important the user gets asked and than infected, with critical there is nothing, just infection. So important is remote code execute and critical is wormable remote code execution.
    And at last take a look at following text from Microsoft: “Mitigating Factors: Microsoft has not identified any mitigating factors for this vulnerability.” To make it short if you read about such a vulnerability in Windows and know that an exploit is in the wild, drop everything and start patching that hole at once.

Looking at the above ways the malware/worm could have easily been blocked. Anyway at last I really want now to take a look at the post linked above from the SMBlog by Steven M. Bellovin.

  • Because patching is very hard and very risk, and the more complex your systems are, the harder and riskier it is.
    Thats not true in this case.

    • Port 445 open to the Internet, no real network separation, deactivated local Windows Firewall and still have SMB1 activated on Windows Client Systems (see Microsoft recommendation from 2016) – thats not at patching problem, thats a security policy failure (e.g. base hardening of operating systems)
    • standard client PCs (for the normal employee) not patched  – not talking about special systems – we patch thousand PCs every month after the Windows patches are released without any problems in years. The special systems needed to get infected after all by something.
    • If non company managed client PCs got connected to the network and infected special systems, its a failure in network access control – plane and simple
    • no mitigation prepared for a case like a worm breakout – Just to make a point, we prepared a client2client block  ACLs for all edge switches, which could be activated within a few minutes, in 2011 – as you newer can know. This is a missing emergency plan like required in ISO 27001.
    • 2 month window for patching an remote code execution wormable vulnerability. If it was not possible in 2 month to patch something like that, than the company has a high technical/security debt. This is a management failure.
    • still running non supported software – that is a management failure, by not making correct contracts with the vendor or ignoring the problem like a Ostrich.
  • So—if you’re the CIO, what do you do? Break the company, or risk an attack? (Again, this is an imaginary conversation.)
    Thats the wrong question – if the CIO is at the questing he has done a bad job before:

    • All your critical software should have a maintenance contract which specially handles security updates (and special the timeline) of the underlaying operating system and the software itself and there must be contractual penalty in it. Done that for year now with “call for bids” – Big IT companies provide that security handling without you asking for it – so this is mainly for special software.
    • If the IT department has not the time to patch everything a Triage needs to be done. The vulnerabilities with the highest probability and potential for damage need to be patched first – this vulnerability must have been on the top of any list.
    • The systems are not as in German is called “Stand der Technik” which can be translated as “state of the art” – an Windows XP system is not state of the art, no meaningful network separation is not state of the art, …..
  • That patching is so hard is very unfortunate. Solving it is a research question. Vendors are doing what they can to improve the reliability of patches, but it’s a really, really difficult problem.
    • Ok patching might be not a easy as it could be but
      • A big institution that got caught by this malware did leave the back door open and is now complaining that a herd of wild boars went through the house and did damage.
      • the security and IT department just failed at there job – just do a postmortem without finger pointing and fix the problems. I’m quite sure the affected IT departments got caught also by the Locky malware and didn’t learn a thing.
      • Vendors doing not enough, sure in this case Microsoft did patch it but specially with IoT devices vendor to nothing.
      • Searching through Google for problems after installing MS17-010 reviles only a few post after billions of updated PCs –> there are no problems with this patch –> no reason to not install it

So thats my view on to the WannaCry stuff after being on vacation ….. tell me your views – did I miss something?

Mitigating application layer (HTTP(S)) DDOS attacks

April 23, 2017

DDOS attacks seem to be new norm on the Internet. Years before only big websites and web applications got attacked but nowadays also rather small and medium companies or institutions get attacked. This makes it necessary for administrators of smaller sites to plan for the time they get attacked. This blog post shows you what you can do yourself and for what stuff you need external help. As you’ll see later you most likely can only mitigate DDOS attacks against the application layer by yourself and need help for all other attacks. One important part of a successful defense against a DDOS attack, which I won’t explain here in detail, is a good media strategy. e.g. If you can convince the media that the attack is no big deal, they may not report sensational about it and make the attack appear bigger and more problematic than it was. A classic example is a DDOS against a website that shows only information and has no impact on the day to day operation. But there are better blogs for this non technical topic, so lets get into the technical part.

different DDOS attacks

From the point of an administrator of a small website or web application there are basically 3 types of attacks:

  • An Attack that saturates your Internet or your providers Internet connection. (bandwidth and traffic attack)
  • Attacks against your website or web application itself. (application attack)

saturation attacks

Lets take a closer look at the first type of attack. There are many different variations of this connection saturation attacks and it does not matter for the SME administrator. You can’t do anything against it by yourself. Why? You can’t do anything on your server as the good traffic can’t reach your server as your Internet connection or a connection/router of your Internet Service Provider (ISP) is already saturated with attack traffic. The mitigation needs to take place on a system which is before the part that is saturated. There are different methods to mitigate such attacks.

Depending on the type of website it is possible to use a Content Delivery Networks (CDN). A CDN basically caches the data of your website in multiple geographical distributed locations. This way each location gets only attacked by a part of the attacking systems. This is a nice way to also guard against many application layer attacks but does not work (or not easily) if the content of your site is not the same for every client / user. e.g. an information website with some downloads and videos is easily changed to use a CDN but a application like a Webmail system or an accounting system will be hard to adapt and will not gain 100% protection even than. An other problem with CDNs is that you must protect each website separately, thats ok if you’ve only one big website that is the core of your business, but will be a problem if attacker can choose from multiple sites/applications. An classic example is that a company does protect its homepage with an CDN but the attacker finds via Google the Webmail of the companies Exchange Server. Instead of attacking the CDN, he attacks the Internet connection in front of the Qebmail. The problem will now most likely be that the VPN site-2-site connections to the remote offices of the company are down and working with the central systems is not possible anymore for the employees in the remote locations.

So let assume for the rest of the document that using a CDN is not possible or not feasible. In that case you need to talk to your ISPs. Following are possible mitigations a provider can deploy for you:

  • Using a dedicated DDOS mitigation tool. These tools take all traffic and will filter most of the bad traffic out. For this to work the mitigation tool needs to know your normal traffic patterns and the DDOS needs to be small enough that the Internet connections of the provider are able to handle it. Some companies sell on on-premise mitigation tools, don’t buy it, its wasting money.
  • If the DDOS attack is against an IP address, which is not mission critical (e.g. attack is against the website, but the web application is the critical system) let the provider block all traffic to that IP address. If the provider as an agreement with its upstream provider it is even possible to filter that traffic before it reaches the provider and so this works also if the ISPs Internet connection can not handle the attack.
  • If you have your own IP space it is possible for your provider(s) to stop announcing your IP addresses/subnet to every router in the world and e.g. only announce it to local providers. This helps to minimize the traffic to an amount which can be handled by a mitigation tool or by your Internet connection. This is specially a good mitigation method, if you’re main audience is local. e.g. 90% of your customers/clients are from the same region or country as you’re – you don’t care during an attack about IP address from x (x= foreign far away country).
  • A special technique of the last topic is to connect to a local Internet exchange which maybe also helps to reduce your Internet costs but in any case raises your resilience against DDOS attacks.

This covers the basics which allows you to understand and talk with your providers eye to eye. There is also a subsection of saturation attacks which does not saturate the connection but the server or firewall (e.g. syn floods) but as most small and medium companies will have only up to a one Gbit Internet connection it is unlikely that a descend server (and its operating system) or firewall is the limiting factor, most likely its the application on top of it.

application layer attacks

Which is a perfect transition to this chapter about application layer DDOS. Lets start with an example to describe this kind of attacks. Some years ago a common attack was to use the ping back feature of WordPress installations to flood a given URL with requests. I’ve seen such an attack which requests on a special URL on an target system, which did something CPU and memory intensive, which let to a successful DDOS against the application with less than 10Mbit traffic. All requests were valid requests and as the URL was an HTTPS one (which is more likely than not today) a mitigation in the network was not possible. The solution was quite easy in this case as the HTTP User Agent was WordPress which was easy to filter on the web server and had no side effects.

But this was a specific mitigation which would be easy to bypassed if the attacker sees it and changes his requests on his botnet. Which also leads to the main problem with this kind of attacks. You need to be able to block the bad traffic and let the good traffic through. Persistent attackers commonly change the attack mode – an attack is done in method 1 until you’re able to filter it out, than the attacker changes to the next method. This can go on for days. Do make it harder for an attacker it is a good idea to implement some kind of human vs bot detection method.

I’m human

The “I’m human” button from Google is quite well known and the technique behind it is that it rates the connection (source IP address, cookies (from login sessions to Google, …) and with that information it decides if the request is from a human or not. If the system is sure the request is from a human you won’t see anything. In case its sightly unsure a simple green check-mark will be shown, if its more unsure or thinks the request is by a bot it will show a CAPTCHA.  So the question is can we implement something similar by ourself. Sure we can, lets dive into it.

peace time

Set an special DDOS cookie if an user is authenticated correctly, during peace time. I’ll describe the data in the cookie later in detail.

war time

So lets say, we detected an attack manually or automatically by checking the number of requests eg. against the login page. In that case the bot/human detection gets activated. Now the web server checks for each request the presence of the DDOS cookie and if the cookie can be decoded correctly. All requests which don’t contain a valid DDOS cookie get redirected temporary to a separate host e.g. https://iamhuman.example.org. The referrer is the original requested URL. This host runs on a different server (so if it gets overloaded it does not effect the normal users). This host shows a CAPTCHA and if the user solves it correctly the DDOS cookie will be set for example.org and a redirect to the original URL will be send.

Info: If you’ve requests from some trusted IP ranges e.g. internal IP address or IP ranges from partner organizations you can exclude them from the redirect to the CAPTCHA page.

sophistication ideas and cookie

An attacker could obtain a cookie and use it for his bots. To guard against it write the IP address of the client encrypted into the cookie. Also put the timestamp of the creation of the cookie encrypted into it. Also storing the username, if the cookie got created by the login process, is a good idea to check which user got compromised.

Encrypt the cookie with an authenticated encryption algorithm (e.g. AES128 GCM) and put following into it:

  • NONCE
  • typ
    • L for Login cookie
    • C for Captcha cookie
  • username
    • Only if login cookie
  • client IP address
  • timestamp

The key for the encryption/decryption of the cookie is static and does not leave the servers. The cookie should be set for the whole domain to be able to protected multiple websites/applications. Also make it HttpOnly to make stealing it harder.

implementation

On the normal web server which checks the cookie following implementations are possible:

  • The apache web server provides a module called mod_session_* which provides some functionality but not all
  • The apache module rewriteMap (https://httpd.apache.org/docs/2.4/rewrite/rewritemap.html) and using „prg: External Rewriting Program“ should allow everything. Performance may be an issue.
  • Your own Apache module

If you know about any other method, please write a comment!

The CAPTCHA issuing host is quite simple.

  • Use any minimalistic website with PHP/Java/Python to create cookie
  • Create your own CAPTCHA or integrate a solution like Recaptcha

pro and cons

  • Pro
    • Users than accessed authenticated within the last weeks won’t see the DDOS mitigation. Most likely these are your power users / biggest clients.
    • Its possible to step up the protection gradually. e.g. the IP address binding is only needed when the attacker is using valid cookies.
    • The primary web server does not need any database or external system to check for the cookie.
    • The most likely case of an attack is that the cookie is not set at all which does take really few CPU resources to check.
    • Sending an 302 to the bot does create only a few bytes of traffic and if the bot requests the redirected URL it on an other server and there no load on the server we want to protect.
    • No change to the applications is necessary
    • The operations team does not to be experts in mitigating attacks against the application layer. Simple activation is enough.
    • Traffic stats local and is not send to external provider (which may be a problem for a bank or with data protections laws in Europe)
  • Cons
    • How to handle automatic requests (API)? Make exceptions for these or block them in case of an attack?
    • Problem with non browser Clients like ActiveSync clients.
    • Multiple domains need multiple cookies

All in all I see it as a good mitigation method for application layer attacks and I hope the blog post did help you and your business. Please leave feedback in the comments. Thx!

Implementing IoT securely in your company – Part 3

February 2, 2017

This is Part 3 of the series implementing IoT securely in your company, click here for part 1 and here for part 2. As it is quite common that new IoT devices are ordered and also maintained by the appropriate department and not by the IT department, it is important that there is a policy in place.

This policy is specially important in this case as most non IT departments don’t think about IT security and maintaining the system. They are often used to think about buying a device and it will run for years and often even longer, without doing much. We on the other hand in the IT know that the buying part is the easy part, maintaining it is the hard one.

Extend existing security policies

Most companies won’t need to start from scratch, as they most likely have policies for common stuff like passwords, patching and monitoring. The problem here is the scope of the policies and that you’re current able to technically enforce many of them:

  • Most passwords are typically maintained by an identity management system and the password policy is therefore enforced for the whole company. The service/admin passwords are typically configured and used by members of the IT department. For IoT devices that maybe not true as the devices are managed by the using department and technically enforcing it may not be possible.
  • Patching of the software is typically centrally done by the IT department, be it the client or server team. But who is responsible for updating the IoT devices? Who monitors that updates are really done? How does he monitor that? What happens if a department does not update their devices? What happens if a vendor stops providing security updates for a given device?
  • Centrally by the IT department provided services are generally monitored by the IT department. Is the IT department responsible for monitoring the IoT devices?  Who is responsible for looking into the problem?

You should look at this and write it down as a policy which is accepted by the other departments before deploying IoT devices. In the beginning they will say yes sure we’ll update the devices regularly and replace the devices before the vendors stops providing security updates – and often can’t remember it some years later.

Typical IoT device problems

Beside extending the policies to cover IoT devices it’s also important to check the policies if the fit the IoT space and cover typical problems. I’ll list some of them here, which I’ve seen done wrong in the past. Sure some of them also apply for normal IT server/services but are maybe consider so basically that everyone just does it right, that it is maybe not covered by your policy.

  • No Update is possible
    Yes, there are devices out in the wild that can’t be updated. What does your policy say?
  • Default Logins
    Many IoT devices come with a default login and as the management of the devices is done via a central (cloud) management system, it is often forgotten that the devices may have also a administration interface.What does your policy say?
  • Recover from IoT device loss
    Let’s assume that an attacker is able to get into one IoT device or that the IoT device gets stole. Is the same password used on the server? Do all devices use the same password? Will the IT department get informed at all? What does your policy say?
  • Naming and organizing things
    For IT devices it’s clear that we use the DNS structure – works for servers, switches, pc’s. Make sure that the same gets used for IoT device. What does your policy say?
  • Replacing IoT devices
    Think about > 100 IoT devices running for 4 years and now some break down, and the the devices are end of sales. Can you connect new models to the old ones?  does someone keep spare parts?  What does your policy say?
  • Self signed certificates
    If the system/devices uses TLS (e.g. HTTPS) it needs to be able to use your internal PKI certificates. Self signed certificates are basically the same as unencrypted traffic. What does your policy say?
  • Disable unused services
    IoT enable often all services by default, like I had a device providing a FTP and telnet server – but for administration only HTTP was ever used. What does your policy say?

I hope that article series helps you to implement IoT devices somewhat securely.

 

Implementing IoT securely in your company – Part 2

January 12, 2017

After Part 1 which focused on setting up your network for IoT this post focus on making sure that the devices are the right ones and that they work in your network. The first can be accomplished by asking basic security questions and talking only with the more secure vendors further.  In my experience that also leads to the better vendors which know IT and whom will make your life easier in the long run. There are plenty of vendors out there for whom the whole IT part is new as they are an old vendor in a given field which now needs to do the “network thing” and don’t have the employees for it. Johannes B. Ullrich at SANS ISC InfoSec came up with the idea to preselect IoT vendors with 5 questions. (You can read more on his reasoning behind each question in his post):

5 preselect questions

  1. For how long, after I purchase a device, should I expect security updates?
    This time frame will show us how long we can plan to use the device in our network, as using devices which get no security updates will be a compliance violation in most companies.
  2. How will I learn about security updates?
    Responsible vendors will add you to a security mailing list where you will get informed on all security related stuff via email.
  3. Can you share a pentest report for your device?
    If the vendor cares at all at security he let an external expert make a pentest, which will at least find the worst and stupid security holes. If the vendor is able to show you such an report, you should really take that vendor in consideration.
  4. How can I report vulnerabilities?
    We often found security holes in programs or devices and sometimes it is really hard to report that to the vendor in a way he accepts it and fixes the hole in a reasonable time frame. Sometimes we needed to go via our local Austrian CERT and sometimes that even was not enough as the vendor was in the US and only did something after their CERT asked them pointed questions. So a direct connection the guy(s) responsible for the security of device is important.
  5. If you use encryption, then disclose what algorithms you use and how it is implemented
    If the vendor tells you something about “Proprietary” run away from the product!  If you read that they use MD5 or RC4, the software on the device seems a little bit dated.

After selecting the best vendors ranked by the preselect questions you should make sure that the devices will run in your network. If you’re new to this kind of work you will not believe what garbage some vendors deliver. Some points are connected to your network and how it will look in the future.

  • The device needs to support DHCP!
    • Use DHCP reservations to provide fixed IP addresses
    • Special case in a secure network is to disable ARP learning on the Layer 3 switches (makes MitM attack a lot harder). In this case DHCP is used for filling the ARP table.
  • Check if the device will work with MAC oder 802.1x authentication flawlessly
    • Some devices only send a packet if queried, which won’t work if the device got de-authenticated e.g. idle timeout or network problem. The device needs to send a packet ever so often so the switch sees the MAC address and can make a RADIUS request.
  • The devices needs to support routing
    • We had devices that where only able to talk within the subnet. In some cases we were not sure if the product really didn’t support it or just the technician was unable to configure it.
    • As the PCs and servers need to be separated via a Firewall (see Part 1), this feature is a deal breaker
  • It should be possible to configure a local NTP Server
    • If not, the device time runs off or you need to allow the device to connect to the Internet, which can get complicated or insecure if you’ve different devices each using an other NTP server
  • The devices needs to support automatic restart of services after power or network outage
    • We had some devices which needed manual interventions to reconnect to the servers again after a network problem
  • Embedding of external resources should be looked at. e.g. If a device needs jquery for its web GUI and lets the browser load that via jquery.org it will not work it your Internet is down. In some cases that does not matter, in some thats a deal breaker.
  • support of 1Gbit Ethernet connection
    • Sure I know that IoT devices do not need 1Gibt, but the devices will maybe run 10 years and you’ll have 10Gbit switches by than. It is not sure that 100Mbit will be supported or work flawlessly. e.g. Some current Broadcom 10Gbit chipsets don’t support 100Mbit half duplex anymore. You need an other chipset which is a little bit more expensive .. and you know what switch vendors will pick? 😉

So so far for part 2 of this series … the next part will be on some policy stuff you need to agree with department wanting that devices.

Implementing IoT securely in your company – Part 1

January 6, 2017

The last articles in this blog about IoT (often called Internet of Targets 😉 ) where about a specific cam or about IoT at home. This article series will be different, it will focus on the IoT in companies. Part one will talk about what you need to in order to prepare your network for IoT.

Prepare your network for IoT

There are 2 kinds of IoT devices/setups:

  • ones that are directly connected to your network (e.g. house automation, access systems, …)
  • ones that are connected via a mobile operator via GPRS, LTE, …. (e.g. car traffic counter, weather stations, webcam at remote places, …)

For the first ones it is a good idea to implement a separate virtual network, which means the traffic from and to the IoT devices always goes over a firewall before going to your servers or PCs. A normal company network should have following separate virtual networks outside the data centers.

  • PC
  • VoIP
  • printer/scanner/MFD
  • external Clients / visitors
  • services = IoT

All those networks are connected to each other via a firewall and only required ports are opened. This separation is not arbitrary as it runs along some important differentiating factors:

  • You’re PCs are normally centrally managed (monthly software updates, no administrator privileges for the users, …) and are allowed to access many and critical servers and services.  Also there is normally no communication needed between 2 PCs, so you can block that to make an attacker the lateral movement harder/impossible.
  • The VoIP phones need QoS and talk directly which each other, as only SIP runs to the server, the (S)RTP media streams run between the phones – peer to peer.
  • Let’s face it, nobody installs software updates on their printers, but they are full computers often with Windows CE or Linux. So like IoT devices we need to contain them. Also one printer does not need to talk to an other printer – block printer to printer traffic.

So lets talk about the IoT network:

  • Put the servers of IoT devices (if they are not fully cloud based) into you’re data centers in the proper DMZ.
  • IoT normally don’t talk directly which each other as the don’t require that the different devices are in the same network at all. So I highly recommend to block client 2 client traffic also in the IoT network. This blocking is important as if an attacker got his hand on one device, he cannot exploit wholes in other IoT devices by simply leap frogging from the first.

After you got your internal IoT network set up we take a look at the devices you need to connect via a mobile operator. First it is never a good idea to put IoT devices directly onto the Internet. Sure you can can use a VPN router for each IoT device to connect back to your data centers, but there is an easier way if you’ve more than a few devices. Most mobile operators provide a service that contains following:

  • separate APN (access point name in GSM/UMTS/LTE speech) which allows authorized SIM cards to connect to a private non Internet network
  • you can choose the IP range of this special mad-for-you network
  • Each SIM card gets assigned a fixed IP address in this network
  • IPsec tunnel which connects the private network to you data center(s)

Here in Austria you pay a setup fee and monthly for the private network but the SIM cards and the cost for bandwidth are basically the same as for normal SIM cards which connect to the Internet.  I recommend to choose 2 providers for this kind of setup as it will happen that one as a bad coverage at a given spot.  With this network and the fixed IP addresses it is quite easy to configure the firewall securely.

The next part will take a look at the policy for implementing new IoT devices, on making sure that the devices are the right ones and that they work in your network.

How to brute force a MySQL DB

December 29, 2016

There are many articles on how to use Metasploit or some other mighty stuff that is fine if you work with it all day. But if you just found a MySQL server on an appliance listening in your network and need to do a fast small security check there is something easier. First find the MySQL server and check the version – maybe there is a exploit available and you don’t need to try passwords. The first choice for this is nmap, just install it with sudo apt-get install nmap and call it like this:

# nmap -sV -O <IP>

Starting Nmap 7.01 ( https://nmap.org ) at 2016-xx-xx xx:xx CET
Nmap scan report for hostname (<IP>)
Host is up (0.020s latency).
Not shown: 986 closed ports
PORT STATE SERVICE VERSION
....
3306/tcp open mysql MySQL 5.6.33-79.0-log
....
Device type: general purpose
Running: Linux 3.X|4.X
OS CPE: cpe:/o:linux:linux_kernel:3 cpe:/o:linux:linux_kernel:4
OS details: Linux 3.2 - 4.0
Network Distance: x hops

You need to call it as root with these options. The -sV shows the versions of the listening services and -O guesses the operating system.  For brute forcing we need 3 things

  • a list of usernames to try
  • a list of passwords to try
  • a software that does the trying

The first is for one thing quite easy as the default users are known and you maybe know something about the system .. like software name or vendor name or the online download-able manual shows the username. So lets write the file:

$ cat > usernames.txt
admin
root
mysql
db
test
user

Now we need a list of likely passwords .. sure we could think about some by our own, but it is easier to download them. A good source is Skull Security. Choose your list and download it and extract it with bunzip2 xxxxx.txt.bz2. Now we only need the software … we’ll use THC Hydra, but you don’t need to download it there and compile it, as Ubuntu ships with it. Just type sudo apt-get install hydra. Now we just need to call it.

$ hydra -L usernames.txt -P xxxxx.txt <ip> mysql
Hydra v8.1 (c) 2014 by van Hauser/THC - Please do not use in military or secret service organizations, or for illegal purposes.
Hydra (http://www.thc.org/thc-hydra) starting at 2016-12-29 14:19:38
[INFO] Reduced number of tasks to 4 (mysql does not like many parallel connections)
[DATA] max 4 tasks per 1 server, overall 64 tasks, 86066388 login tries (l:6/p:14344398), ~336196 tries per task
[DATA] attacking service mysql on port 3306
[STATUS] 833.00 tries/min, 833 tries in 00:01h, 86065555 todo in 1721:60h, 4 active
.....

I think this password list is too long 😉 Choose a shorter one 😉

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.

Spiegel Online uses a 2000 years old cipher for their pay wall

August 3, 2016

Today I cam across some not well done encryption. To be exact I surfed the website of the German news magazine Der Spiegel and clicked on an article that was of the type Spiegel Plus. That type is indicated by this logo:

spiegelplus

Scrolling down after some paragraphs I saw following:

blur_without_javascript

hmmm … funny …. lets take a look in a browser that has JavaScript enabled (as my default one does not).

blur_with_javascript

That’s some kind of pay wall. Lets take a look at the source code of the page with the Firefox Web Developer tools. Using the Inspector and clicking on the blurred paragraph I get to following CSS

blurhmm … lets disable that blur

unblured

Ok readable … but that does not look like German …. but it looks like a ROT13 algorithm, which is  is a simple letter substitution cipher that replaces a letter with the letter x (in the case of ROT13 x=13) letters after it in the alphabet. ROT13 is a special case of the Caesar cipher, developed in ancient Rome. Lets try some ROT variations. As I was just playing around I used a website for this and clicked through it … and I took until ROT25 get readable text.

 

rot25

That was too easy … under 10 minutes to get the clear text. I can’t be the first one … and I’m right … there is a Firefox plugin on Githup.  So it seems this is common knowledge already. Searching the German web I found that one blogger also from Austria already reported it to Spiegel, some Weeks ago … maybe ITIL  does not allow a change ;-).

So to Spiegel, as Andreas already told them, use some real cipher, there are plenty OpenSource JavaScript implementation. And use a different random key for every article, or at least one per day.

 

 

HiKam A7 – IoT security at its worst [Update]

July 8, 2016

[Update]

I’ll reached out to the company which got back to me today and told me that they are working on fixes for the problems.  I’ve also changed my cam from wired to wireless mode today and the app sent the wpa2 password via UDP to the Internet in the clear – I’m glad I used a separate SSID and password for this ;-). I also reported that info to the company.

[/Update]

In my last blog post I’ve written about IoT devices and their bad security and what you can do to mitigate that on a network level – what I didn’t know that I would have such a device in my hands only days later.I did get my hands on a HiKam A7 IP cam, which is at the German Amazon Store the number one product for surveillance cams – so not a nobody. At the end I’ll found 5+ security problems in 2 hours looking at it, but keep on reading for the details. 🙂

hikama7_amazon

As first act I’ve installed the app you need for configuring the cam in the first place. At first start you need to create a user, which should/must be unique per mobile / tablet. Looking at the network traffic I saw a HTTP request to api4.cloud-links.net and guess what was the content of that POST request?

hikama7_app1

Yes, that seems to be the user name and password in an effort to check if the username is already taken. The Pwd parameter is 32 chars long and looks like hex …. that couldn’t be MD5? Lets ask crackstation.net

crackstation

Yes! Sure its unsalted MD5 and the password matches. So here are the first 2 security related errors  … no HTTPS and than unsalted MD5 over an Internet connection.  Something funny – you need to enter the password twice to guard against typing errors … both values are send to the server in the clear …. why not compare them on the client and send the request only if they match? of course also via HTTP and not HTTPS

hikama7_app2So the account is also created with an MD5 password – which leads to the third security related problem …. customer passwords are stored as unsalted MD5 in the database … for years now we should know that that’s bad.

Ok, we got an UserID and soon after the app starts sending UDP packets to Chinese server (cloudlinks.cn) … let’s convert the UserID to hex, maybe we find it again

hikama7_app2_python

and of course we find it again in the UDP packets

hikama7_app3

So the userID is also send in the clear every few seconds and is only a 32bit integer … not hard to guess for an attacker  – third security related error. So this userID seems to be something important, lets call that registration function multiple times with curl and look at the answers.

{"error_code":"0","UserID":"-2144083657","P2PVerifyCode1":"999048728","P2PVerifyCode2":"1551418556","DomainList":""}
{"error_code":"0","UserID":"-2144083654","P2PVerifyCode1":"76169185","P2PVerifyCode2":"196029599","DomainList":""}
one minute wait
{"error_code":"0","UserID":"-2144083636","P2PVerifyCode1":"1008452257","P2PVerifyCode2":"1056609345","DomainList":""}
{"error_code":"0","UserID":"-2144083633","P2PVerifyCode1":"836153359","P2PVerifyCode2":"494065857","DomainList":""}

Oh yeah, the UserID are assigned sequentially for each registration and provided to the user and used later by the client  …. not a good idea .. lets call it fourth security related error

So lets stop looking at the app and take a quick look at the cam it self …. first a nmap scan:

PORT STATE SERVICE VERSION
554/tcp open rtsp?
5000/tcp open soap gSOAP soap 2.8
MAC Address: 4A:81:49:xx:xx:xx (Unknown)
Device type: general purpose
Running: Linux 2.6.X|3.X
OS CPE: cpe:/o:linux:linux_kernel:2.6 cpe:/o:linux:linux_kernel:3
OS details: Linux 2.6.32 - 3.2
Network Distance: 1 hop

hm … RTSP ….. let’s take a look with VLC to check if there is a username/password required

vlc rtsp://xxx.xxx.xxx.xxx:554/onvif1

a7_video

Of course there is no password required, everyone in the same network or who is able to connect port 554 can look at the video (There is no option in the app to configure a RTSP password).  So the next security problem is that there is no authentication required at all for RTSP, fifth security problem. As my router has UPNP disabled I did’t check if the cam would open port 554 on the router.

Interesting, I could not find the MAC vendor – even online. Anyway looking at the traffic the cam sends to the Internet, it seems to talk at once after booting to the same UDP port the app does – even the same IP address, but an other DNS name.

a7_1

a look at the UDP packet shows that the device ID (printed on the cam) in hex is at the same place of the packet as the UserID is:

a7_2

I could find an authentication between the cam and the cloud servers …. but maybe I missed something … but as I’m not 100% sure I’ll won’t count it. 😉

 

Ah there is also a button in the app for a firmware update of the cam …… and of course its HTTP and not HTTPS …. easy code inject? I couldn’t find a signature for the file to protect against it, but I didn’t try it so I’ll also don’t count it.

a7_firmware_update

Here is the link to the firmware file, I couldn’t resist an fast check of the file:

$ binwalk npcupg_13.00.00.90.bin
DECIMAL HEX DESCRIPTION
-------------------------------------------------------------------------------------------------------
32 0x20 JFFS2 filesystem, little endian
2998728 0x2DC1C8 ELF 32-bit LSB executable, ARM, version 1 (SYSV)
3002209 0x2DCF61 LZMA compressed data, properties: 0x03, dictionary size: 524288 bytes, uncompressed size: 196608 bytes

so lets take a look at the filesystem by mounting the jffs2 file system in RAM.

# modprobe mtdram total_size=32768 erase_size=256
# modprobe mtdblock
# dd if=20.jffs2 of=/dev/mtdblock0
5869+1 records in
5869+1 records out
3005295 bytes (3,0 MB) copied, 0,026426 s, 114 MB/s
# mount -t jffs2 /dev/mtdblock0 /mnt/

but that’s for an other time …. the blog post is already really loooooong. There seem to be much more possibilities to hack that cam. It even seems possible to access cam from others, as the authentication is only based on one or two 32bit values. But looking at that more deeply would take more than 2 hours (without writting this post itself)

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:

iot_network1

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.

iot_network2

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.

Powered by WordPress
Entries and comments feeds. Valid XHTML and CSS. 89 queries. 0.455 seconds.