KCodes NetUSB vulnerability (CVE-2015-3036) and a short-term fix for TP-Link

There was a vulnerability disclosed by SEC Consult earlier today that affects a significant number of SOHO routers. NetUSB is a technology that provides a "USB over IP" functionality. It was developed by a company KCodes and since then has been adopted by many popular network device manufactures (including Netgear and TP-Link). 

NetUSB runs as a Linux kernel driver. When it is available it launches a server on TCP port 20005 (that is typically accessible on the LAN only). I have seen some reports already claiming that some (mis)configurations were exposing port 20005 on the WAN side (i.e. to the Internet) as well. And this is bad news because according to the advisory NetUSB suffers from a remote stack buffer overflow. And being kernel driver it means that remote attacker by exploiting this vulnerability can gain admin privileges on the affected device.

The AES keys are static - that's not great, as it means they are useless. They won't be able to stop the attackers as the keys are already known to them. And all they need to do is to send a computer name longer than 64 bytes to cause an overflow. This feels like 90s again.

If port 20005 is not accessible from the outside then this reduces the risk but it still leaves this network vulnerable to the attacks from the inside.

I've got my hands on one of the affected models - TP-Link Archer D9.

A quick test to connect to port 20005: 

telnet 192.168.0.1 20005

reveals that it does indeed listen on port 20005 in the default configuration (i.e. I was able to connect).

A web management interface has this section under USB Management -> Print server:

As you can see by default the Print Server is turned on.

Let's click the Stop button...

... and try to connect again:

Ah, much better.

I am not sure if this approach fully mitigates this issue but it certainly makes the overall situation better.
An updated firmware version with a fix from TP-Link is expected around the 25th of May. Until then I would recommend you to stop the Print Server.

Integers - when size does matter

I have just read about an issue affecting all Boeing 787 airplanes:

"We have been advised by Boeing of an issue identified during laboratory testing. The software counter internal to the generator control units (GCUs) will overflow after 248 days of continuous power, causing GCU to go into failsafe mode. If the four main GCUs (associated with the engine mounted generators) were powered up at the same time, after 248 days of continuous power, all four GCUs will go into failsafe mode at the same time, resulting in a loss of all AC electrical power regardless of flight phase.

Wow, this is scary - especially the "regardless of flight phase" bit. I've done some research and it turns out that the probability is VERY low for a given aircraft to remain powered for 248 days in a row.

In the same document FAA (as an interim measure) adds a requirement:

This AD requires a repetitive maintenance task for electrical power deactivation

This essentially means - each plane must be periodically powered off (obviously with the frequency < 248 days). We all recognise this pattern - a periodic application restart or server reboot when dealing with the misbehaving applications (memory leaks etc)

In fact, there are several relevant and related to IT moments that caught my attention.

The "magic" 248 days number

A 32 bit signed (i.e. we can only use 31 bit) integer can store a maximum value of 2147483647.

2,147,483,647 / (24 hours*60 min*60 sec) = 24,855

Many sensors connected to the ARINC-429 bus have a 100Hz data sampling rate.

Dividing 24,855 by 100Hz we get 248.55 days needed to overflow this integer.

We have many examples in IT, where integer overflows cause all sorts of troubles (ranging from availability to security)

But I wanted to mention one issue that's worth keeping an eye on. Have you ever seen an error message like this?

Server: Msg 8115, Level 16, State 1, Line 1
Arithmetic overflow error converting IDENTITY to data type int.
Arithmetic overflow occurred.

SQL Server will generate this error when it detects an IDENTITY column overflow.

I used to use a script that looked very similar to the one provided by Red-gate. Give it a go - who knows, you might be able to discover an identity column approaching the limit and prevent an outage.

If the four <redundant devices> were powered up at the same time...

This is another interesting issue. If we have N redundant devices but they all share the same common (time based) problem then there is a chance that the fault across all N devices will happen at the same time. This means that a fault will escalate to a system-wide failure (i.e. outage). 

It is quite common in IT to implement a staggered approach when introducing changes (OS patches, code rollout etc) - "touching" all systems at the same time is not desirable.

There are certain events that bring application restarts and server reboots back in "sync". E.g.

• A predictable Patch Tuesday and default settings will result in many computers applying patches and rebooting around 3 AM (in a given time zone). Note: Microsoft decided to move away from the monthly cycle and release patches as they become available - this is a good move in my view.
• A vulnerability in a common library might force many systems administrators to patch affected software almost at the same time around the world. Plus SSL certificates might need to be reissued too - we've seen an April spike caused by Heartbleed 

This is something that we usually don't think about when patching our systems. So take this into the consideration next time you apply patches to a multi-node cluster or a group of network devices operating in HA mode.

Aussie banks security (HTTP headers edition)

Introduction

Troy Hunt has recently published a blog post, where he analysed a current state of affairs with regards to SSL/TLS support and (in)secure configurations in the Australian banking industry. This is an interesting overview and a great mechanism for raising awareness, which (judging by the updates) has already prompted some banks to make changes and improve their ratings.

I was curious - how would the situation with SSL correlate with another publicly available piece of information - HTTP headers (especially the security related subset). These headers could provide some valuable insights (although in my view in general the impact of SSL misconfiguration could be bigger compared to the presence/absence of a particular header).

So I performed a mini-research, focusing on the same set of Australian banks. I used https://securityheaders.io to simplify the collection of all headers. The headers I was interested in were (group 1):

• Strict-Transport-Security
• Content-Security-Policy
• Public-Key-Pins
• X-Frame-Options
• X-Xss-Protection
• X-Content-Type-Options

When I started analysing captured results I decided to add the following headers into the mix (group 2):

• Server
• X-Powered-By
• X-AspNet-Version

Surprisingly, I haven't observed the 3rd "usual suspect" - x-aspnetmvc-version. Perhaps banks haven't upgraded their web applications to the MVC versions yet?

Also worth mentioning that X-AspNet-Version will only be emitted by the ASP.Net powered application - i.e. this header won't be relevant for other platforms.
All results have been collected in early May 2015 - the situation may have changed since then. It will be interesting to perform periodic checks to observe the dynamics.

Methodology

Once the raw data were captured in a table I started thinking how I could rank these findings. Here's a set of rules I came up with (I'd be very keen to hear suggestions for improvement):

• The initial state - everyone starts with 0 (zero) points - neutral state 
• If Strict-Transport-Security is present - add 2 points. HSTS is too good to be ranked equally with the other headers
• If any other header from group 1 is present - add 1 point for each header
• If "Server" header is present
• Deduct 1 point if a full/non-obfuscated name is found (marked red in the table below)
• Otherwise deduct 0.5 points (e.g. "CUA Server" doesn't disclose much and is much more benign compared to "Microsoft-IIS/7.5" - marked as orange)
• If "X-Powered-By" header is present
• Deduct 1 point if a well-known framework is disclosed
• Otherwise deduct 0.5 points (marked as orange)
• If "X-AspNet-Version" header is present - deduct 1 point
• I took a sum for each bank and listed it as a "Score"
• Then I assigned banks to the corresponding groups based on that score
• Green: greater than 0
• Yellow: 0
• Orange: -0.5
• Red: less than -0.5

Results

Bank	Score	Strict-Transport-Security	Content-Security-Policy	Public-Key-Pins	X-Frame-Options	X-Xss-Protection	X-Content-Type-Options	Server	X-Powered-By	X-AspNet-Version
Bank West	5	Yes	Yes	No	Yes, SAMEORIGIN	Yes	No	No	No	No
CUA	1.5	Yes	No	No	No	No	No	Yes, CUA Server	No	No
Commonwealth Bank	1	Yes	No	No	No	No	No	Yes, Apache/2.2.3 (Red Hat)	No	No
ING Direct	1	No	No	No	Yes, SAMEORIGIN	No	No	No	No	No
AMP	0.5	No	No	No	Yes, SAMEORIGIN	No	No	Yes, IBM_HTTP_Server	No	No
St George	0.5	No	No	No	Yes, SAMEORIGIN	No	No	Yes, Apache	No	No
Bankmecu	0	No	No	No	No	No	No	No	No	No
Bendigo Bank	0	No	No	No	No	No	No	No	No	No
Beyond	0	No	No	No	No	No	No	No	No	No
Greater	0	No	No	No	No	No	No	No	No	No
Heritage	0	No	No	No	No	No	No	No	No	No
Macquarie	0	No	No	No	No	No	No	No	No	No
People's Choice Credit Union	0	No	No	No	No	No	No	No	No	No
Suncorp	0	No	No	No	Yes, SAMEORIGIN	No	No	No	Yes, ASP.NET	No
IMB	-0.5	No	No	No	No	No	No	Yes, Sandstone Framework	No	No
Westpac	-0.5	No	No	No	No	No	No	No	Yes, Servlet/3.0	No
Newcastle Permanent	-1	No	No	No	No	No	No	No	Yes, ASP.NET	No
ANZ	-2	No	No	No	No	No	No	Yes, Microsoft-IIS/6.0	Yes, ASP.NET	No
Bank of Queensland	-2	No	No	No	No	No	No	No	Yes, ASP.NET	Yes, 2.0.50727
P&N	-2	No	No	No	No	No	No	Yes, Microsoft-IIS/7.5	Yes, ASP.NET	No
Teachers Mutual	-3	No	No	No	No	No	No	Yes, Microsoft-IIS/8.0	Yes, ASP.NET	Yes, 4.0.30319

Update 1 - 14 June 2015: Bank West has addressed a few issues and contacted me to update the results. A quick check revealed a massive improvement - going from a "-2" score all the way to the top of the leaderboard! Congratulations to the team - thank you for taking time to improve your ranking.
This also gave me an opportunity to review the situation with the other banks from this list. Newcastle Permanent dropped 1 point down for the presence of the X-Powered-By header. ANZ did the same for the Server header (IIS 6, really???). Heritage went 1 point up (removed Server header)

Key findings

• Only Strict-Transport-Security and X-Frame-Options security headers have been observed in the wild
• Surprisingly - clear lack of wider adoption of security headers (group 1) by the banks.
• Only 2 banks out of 21 use HSTS - kudos to CUA and Commonwealth Bank;
• Only 4 banks  use X-Frame-Options
• The situation with the group 2 headers was better, most of the banks had none of them. Some banks had several Asp.Net related headers (which took them to the bottom of the list). This situation is especially surprising given how easy it is to remove these headers.
• Weak correlation between SSL and HTTP headers results
• ING Direct is the only bank that has managed to reach the top (green) categories in both tests

And the last point that I would like make - some headers (which are not directly related to security per se) might still leak some useful to the attackers information. This includes:

• Set-Cookie: f5_cspm=[skipped]; - indicates presence of an F5 appliance
• Set-Cookie: citrix_ns_id=[skipped] - indicates presence of a Citrix Netscaler appliance
• Set-Cookie: ASP.NET_SessionId=[skipped]; path=/; HttpOnly - indicates an ASP.Net application even if all other headers (from group 2) have been removed

To summarise - it is a bit disappointing that we don't see a wider adoption of the HTTP security headers by the Australian banking industry. Some of these headers are trivial to implement (e.g. X-Frame-Options) and yet they provide a valuable protection layer.

I would like to encourage everyone reading this blog to get a better understanding of what all of these headers do and to start implementing at least some of these headers on your own web sites. This will make Internet as a whole more secure.