Here is a quick writeup of the protocol for the iKettle taken from my
Google+ post
earlier this month. This protocol allows you to write your own software
to control your iKettle or get notifications from it, so you can integrate
it into your desktop or existing home automation system.

The iKettle is
advertised as the first wifi kettle, available in UK since February 2014. I
bought mine on pre-order back in October 2013. When you first turn on the
kettle it acts as a wifi hotspot and they supply an app for Android and iPhone
that reconfigures the kettle to then connect to your local wifi hotspot instead.
The app then communicates with the kettle on your local network enabling you
to turn it on, set some temperature options, and get notification when it
has boiled.

Once connected to your local network the device responds to ping requests and
listens on two tcp ports, 23 and 2000. The wifi connectivity is enabled by
a third party serial to wifi interface board and it responds similar to a
HLK-WIFI-M03. Port 23 is used to configure the wifi board itself (to
tell it what network to connect to and so on). Port 2000 is passed through
to the processor in the iKettle to handle the main interface to the kettle.

Port 2000, main kettle interface

The iKettle wifi interface listens on tcp port 2000; all devices that connect
to port 2000 share the same interface and therefore receive the same messages.
The specification for the wifi serial board state that the device can only
handle a few connections to this port at a time. The iKettle app also uses
this port to do the initial discovery of the kettle on your network.

Discovery

Sending the string "HELLOKETTLE\n" to port 2000 will return with "HELLOAPP\n".
You can use this to check you are talking to a kettle (and if the kettle has
moved addresses due to dhcp you could scan the entire local network looking
for devices that respond in this way. You might receive other HELLOAPP
commands at later points as other apps on the network connect to the kettle.

Initial Status

Once connected you need to figure out if the kettle is currently doing
anything as you will have missed any previous status messages. To do
this you send the string "get sys status\n". The kettle will respond with
the string "sys status key=\n" or "sys status key=X\n" where X is a single
character. bitfields in character X tell you what buttons are currently
active:

Bit 6

Bit 5

Bit 4

Bit 3

Bit 2

Bit 1

100C

95C

80C

65C

Warm

On

So, for example if you receive "sys status key=!" then buttons
"100C" and "On" are currently active (and the kettle is therefore
turned on and heating up to 100C).

Status messages

As the state of the kettle changes, either by someone pushing the physical button
on the unit, using an app, or sending the command directly
you will get async status messages. Note that although the status
messages start with "0x" they are not really hex. Here are all
the messages you could see:

sys status 0x100

100C selected

sys status 0x95

95C selected

sys status 0x80

80C selected

sys status 0x100

65C selected

sys status 0x11

Warm selected

sys status 0x10

Warm has ended

sys status 0x5

Turned on

sys status 0x0

Turned off

sys status 0x8005

Warm length is 5 minutes

sys status 0x8010

Warm length is 10 minutes

sys status 0x8020

Warm length is 20 minutes

sys status 0x3

Reached temperature

sys status 0x2

Problem (boiled dry?)

sys status 0x1

Kettle was removed (whilst on)

You can receive multiple status messages given one action, for example
if you turn the kettle on you should get a "sys status 0x5" and a
"sys status 0x100" showing the "on" and "100C" buttons are selected.
When the kettle boils and turns off you'd get a "sys status 0x3" to
notify you it boiled, followed by a "sys status 0x0" to indicate all
the buttons are now off.

Sending an action

To send an action to the kettle you send one or more action messages
corresponding to the physical keys on the unit. After sending an
action you'll get status messages to confirm them.

set sys output 0x80

Select 100C button

set sys output 0x2

Select 95C button

set sys output 0x4000

Select 80C button

set sys output 0x200

Select 65C button

set sys output 0x8

Select Warm button

set sys output 0x8005

Warm option is 5 mins

set sys output 0x8010

Warm option is 10 mins

set sys output 0x8020

Warm option is 20 mins

set sys output 0x4

Select On button

set sys output 0x0

Turn off

Port 23, wifi interface

The user manual for this document
is available
online, so no need to repeat the document here. The iKettle uses the device
with the default password of "000000" and disables the web interface.

If you're interested in looking at the web interface you can enable it by
connecting to port 23 using telnet or nc, entering the password, then issuing the commands
"AT+WEBS=1\n" then "AT+PMTF\n" then "AT+Z\n" and then you can open up a webserver on port 80
of the kettle and change or review the settings. I would not recommend you
mess around with this interface, you could easily break the iKettle in a way
that you can't easily fix. The interface gives you the option of uploading
new firmware, but if you do this you could get into a state where the kettle
processor can't correctly configure the interface and you're left with
a broken kettle. Also the firmware is just for the wifi serial interface,
not for the kettle control (the port 2000 stuff above), so there probably
isn't much point.

Missing functions

The kettle processor knows the temperature but it doesn't expose that in any
status message. I did try brute forcing the port 2000 interface using
combinations of words in the dictionary, but I found no hidden features (and
the folks behind the kettle confirmed there is no temperature read out). This
is a shame since you could combine the temperature reading with time and figure
out how full the kettle is whilst it is heating up. Hopefully they'll address
this in a future revision.

Security Implications

The iKettle is designed to be contacted only through the local network - you
don't want to be port forwarding to it through your firewall for example because
the wifi serial interface is easily crashed by too many connections or bad
packets. If you have access to a local network on which there is an iKettle you
can certainly cause mischief by boiling the kettle, resetting it to factory
settings, and probably even bricking it forever. However the cleverly designed
segmentation between the kettle control and wifi interface means it's pretty
unlikely you can do something more serious like overiding safety (i.e. keeping
the kettle element on until something physically breaks).

"for all packages, from release of 6.3 up to and including 6.4, we shipped
108 advisories to address 311 vulnerabilities. 18 advisories were rated
critical, 28 were important, and the remaining 62 were moderate and low."

"Updates to correct 77 of the 78 critical vulnerabilities were available via
Red Hat Network either the same day or the next calendar day after the
issues were public. The other one was in OpenJDK 1.60
where the update took 4 calendar days (over a weekend)."

And if you are interested in how the figures were calculated, here is the
working out:

Note that we can't just use a date range because we've pushed some
RHSA the weeks before 6.4 that were not included in the 6.4 spin.
These issues will get included when we do the 6.4 to 6.5 report (as
anyone installing 6.4 will have got them when they first updated).

Note: although we have 3 default criticals, they are in openjdk-1.6.0, but we
only call Java issues critical if they can be exploited via a browser, and in
RHEL6 the Java browser plugin is in the icedtea-web package, which isn't a
default package. So that means on a default install you don't get Java plugins
running in your browser, so really these are not default criticals in RHEL6
default at all.

"for all packages, from release of 6.2 up to and including 6.3, we shipped
88 advisories to address 233 vulnerabilities. 15 advisories were rated critical,
23 were important, and the remaining 50 were moderate and low."

"Updates to correct 34 of the 36 critical vulnerabilities were
available via Red Hat Network either the same day or the next calendar
day after the issues were public. The Kerberos telnet flaw was fixed
in 2 calendar days as the issue was published on Christmas day. The
second PHP flaw took 4 calendar days (over a weekend) as the initial
fix released upstream was incomplete."

And if you are interested in how
the figures were calculated, as always view the source of this
blog entry.

The Common Vulnerability Reporting Framework (CVRF) is a way to share
information about security updates in an XML machine-readable format. CVRF
1.1 got released this week and over at Red Hat we've started publishing
our security advisories in CVRF format.

Red Hat Enterprise Linux 5.8 was released today (February 2012), seven
months since the release of 5.7 in July 2011. So let's use this opportunity to
take a quick look back over the vulnerabilities and security updates made in
that time, specifically for Red Hat Enterprise Linux 5 Server.

Errata count

The chart below illustrates the total number of security updates issued for Red
Hat Enterprise Linux 5 Server if you had installed 5.7, up to and including the
5.8 release, broken down by severity. It's split into two columns, one for
the packages you'd get if you did a default install, and the other if you
installed every single package (which is unlikely as it would involve quite a bit of
manual effort to select every one). For a given installation, the number of
package updates and vulnerabilities that affected you will depend on exactly
what packages you have installed or removed.

So, for a default install, from release of 5.7 up to and including
5.8, we shipped 42 advisories to address 118 vulnerabilities. 4
advisories were
rated critical, 13 were important, and the remaining
25 were moderate and low.

Or, for all packages, from release of 5.7 up to and including 5.8, we
shipped 71 advisories to address 177 vulnerabilities. 7 advisories
were rated critical, 16 were important, and the remaining 48 were
moderate and low.

An update to the
MIT krb5 telnet daemon
(December 2011) where
a remote attacker who can access the telnet port of a target machine could use
this flaw to execute arbitrary code as root. Note that the krb5 telnet daemon
is not installed or enabled by default, and the default firewall rules block remote access to
the telnet port. This flaw did not affect the more commonly used telnet daemon distributed in the
telnet-server package.

Updates to
PHP
and
PHP 5.3
(February 2012)
where a remote attacker could send a specially-crafted HTTP request to cause the
PHP interpreter to crash or, possibly, execute arbitrary code. This flaw was
caused by the fix for CVE-2011-4885.

Updates to correct 19 out of the 20 critical vulnerabilities were
available via Red Hat Network either the same day or the next
calendar day after the issues were public. The update to krb5
took 2 calendar days because it was public on Christmas day.

Overall, for Red Hat Enterprise Linux 5 since release until 5.8, 98%
of critical vulnerabilities have had an update available to address
them available from the Red Hat Network either the same day or the
next calendar day after the issue was public.

Other significant vulnerabilities

Although not in the definition of critical severity, also of interest during
this period were a couple of remote denial of service flaws that were easily exploitable:

Previous update releases

To compare these statistics with previous update releases we need
to take into account that the time between each update release is different.
So looking at a default installation and calculating the number of
advisories per month gives the following chart:

This data is interesting to get a feel for the risk of running Enterprise
Linux 5 Server, but isn't really useful for comparisons with other major
versions, distributions, or operating systems -- for example, a default install
of Red Hat Enterprise Linux 4AS did not include Firefox, but 5 Server does. You
can use our public
security measurement data and tools, and run your own custom metrics for any
given Red Hat product, package set, timescales, and severity range of interest.

Red Hat Enterprise Linux 6.2 was released this week (Dec 2011), just
over six months since the release of 6.1 in May 2011. So let's
use this opportunity to take a quick look back over the
vulnerabilities and security updates made in that time, specifically
for Red Hat Enterprise Linux 6 Server.

Errata count

The chart below illustrates the total number of security updates issued for Red
Hat Enterprise Linux 6 Server if you had installed 6.1, up to and including the
6.2 release, broken down by severity. It's split into two columns, one for
the packages you'd get if you did a default install, and the other if you
installed every single package (which is unlikely as it would involve a bit of
manual effort to select every one). For a given installation, the number of
package updates and vulnerabilities that affected you will depend on exactly what you
have installed or removed.

So, for a default install, from release of 6.1 up to and including 6.2, we
shipped 36 advisories to address 121 vulnerabilities. 2 advisories were rated
critical, 10 were important, and the remaining 24 were moderate and low.

Or, for all packages, from release of 6.1 up to and including 6.2, we shipped
88 advisories to address 218 vulnerabilities. 10 advisories were rated critical,
16 were important, and the remaining 62 were moderate and low.

Updates to correct all of the 31 critical vulnerabilities were
available via Red Hat Network either the same day or the next calendar
day after the issues were public.

Other significant vulnerabilities

Although not in the definition of critical severity, also of interest during
this period were a few flaws that were high risk or easily exploitable:

A flaw in Bind, CVE-2011-4313
fixed by RHSA-2011:1458
where a malicious client could cause Bind to stop responding, a denial
of service attack. This flaw was discovered by it being accidentally
triggered in the wild.

A flaw in the Apache HTTP Server, CVE-2011-3192,
fixed by RHSA-2011:1245, where a remote attacker could
cause a denial of service attack. This was discovered due to a public exploit.

A flaw in RPM, CVE-2011-3378
fixed by RHSA-2011:1349
where a specially-crafted RPM package that, when queried or installed,
would cause rpm to crash or, potentially, execute arbitrary code prior to any
signature checking. We're not aware of any working exploits for this issue.

Previous update releases

To compare these statistics with previous update releases we need to take into
account that the time between each update release is different. So looking at
a default installation and calculating the number of advisories per month
gives the following chart:

This data is interesting to get a feel for the risk of running Enterprise
Linux 6 Server, but isn't really useful for comparisons with other major
versions, distributions, or operating systems -- for example, a default install
of either Red Hat Enterprise Linux 4AS and 6 Server does not include Firefox, but a
default install of 5 Server does. You can use
our public security
measurement data and tools, and run your own custom metrics for any given
Red Hat product, package set, timescales, and severity range of interest.

When we get notified of a security issue affecting a Red Hat product
in advance we give an acknowledgement in the security advisory and in our
CVE database.

We've now created a
page to give acknowledgements to the companies and individuals that
report issues in our online services, such as finding a cross-site scripting
flaw in a Red Hat web site, or a vulnerability in OpenShift.

We pushed an
update to Flash Player for Red Hat Enterprise Linux Supplementary today, on
a Friday, because it fixed Critical vulnerabilities. But we try not to push
updates on a Friday unless they are critical and already public.

So let's take a look at the most common times and days we push
advisories for Red Hat Enterprise Linux 4, 5, and 6 (including
Supplementary) using a heatmap:

The more advisories pushed for a given date and hour, the darker
that section of the graph is. So the most popular times
for pushing advisories are Tuesdays at 10am and 2pm Eastern US time,
Fridays are pretty light for pushes, and there was nothing
during the weekends. The spread of the graph shows that we push advisories when
they are ready, rather than waiting to a fixed day and time, in order to reduce
the risk to users.

All the data used to create this graph is available as part of
our public metrics.
Thanks to Sami Kerola for
the R code from which I based my
graph generation.

Every year since Red Hat Enterprise Linux 4 was released we've
published a risk report where we look at the state of security
of the distribution. We investigate the key vulnerabilities,
metrics on vulnerability counts, and how users could have been
exploited by them. The
Six
Years
of Red Hat Enterprise Linux 4 report (PDF) covering Feb 2005-2011
was published today.

"Red Hat knew about 51.5% of the security vulnerabilities
that we fixed in advance. The
average time between Red Hat knowing about an issue and it being made
public was 23 days (median 10 days).... A default installation of Red
Hat Enterprise Linux 4 AS was vulnerable to 20 critical security
issues over the first six years. "

The data we publish is interesting to get a feel for the risk of running
Enterprise Linux, but isn't really useful for comparisons with other
distributions, or operating systems. One important difference is that it is Red
Hat policy to count vulnerabilities and allocate CVE names to all issues that
we fix, including ones that are found internally. This is not true for many
other vendors including folks like
Microsoft
and
Adobe
who do not count or disclose issues they fix which were found internally.