start	end	text
940	3400	Hello everyone, and thank you for joining my talk today
3400	6080	called Don't Be Silly, It's Only a Lightbulb.
6080	8680	Before we begin, just a brief introduction.
9280	11440	My name is Eyal Itkin.
11440	12640	I'm a vulnerability researcher
12640	15060	working at Checkpoints Research Group.
15240	16580	In my research projects,
16580	20020	I tend to focus on embedded devices and protocols,
20020	22680	and in which case I combine these both together.
23100	25560	You can usually read more about my recent publications
25560	27360	on my Twitter account.
28500	31140	The motivation for this specific research
31140	33860	started a few years ago in 2016,
33860	37760	when I heard of a new smart IoT device, smart lightbulbs.
37940	41020	I was already quite familiar with many smart gadgets
41020	43960	and even smart air conditioner,
43960	46620	which allows you to activate it remotely on your way home
46620	49620	so the temperature will be just fine when you arrive.
49920	53540	But why would I need a smart lightbulb?
53540	56720	I only need a light when I'm physically in a room
56720	59500	and I'm fully capable of toggling the switch on and off
59500	61520	when I enter and leave the room.
61520	63480	Why would I need an app for that?
63480	66220	Well, I figured out that it won't catch,
66220	68400	people won't buy it, and that's it.
68600	70460	And apparently I was wrong,
70460	74140	because according to a report from the end of 2018,
74140	76940	more than 400,000 households in the UK
77360	79740	were already using smart lighting solutions.
79740	82360	So people are apparently buying this gadget.
83000	87800	Okay, but if I connect my lightbulb to the mobile phone
87800	89220	or to the internet,
89220	92440	there will be some security risk about it, right?
92920	94740	But when I ask people about it,
94740	97220	I always receive the same response.
97260	100820	Don't be silly, it's only a lightbulb, it's fine.
102060	105220	Obviously, I'm not the first to study this test case
105220	108400	and there is some great firework before me.
109200	111300	We will start with a lightbulb worm
111300	113580	by Colin Flynn and Eyal Ronen,
113580	117260	which presented their research on Blackhead USA on 2016.
117580	119680	Later on, they developed the research
119680	124160	into IoT goes nuclear, creating a ZigBee chain reaction.
124540	126600	This time they were joined by Adi Shamir
126600	128180	and Achior Weingarten,
128180	131500	and you can read all about it on their website.
131860	133940	I really recommend you reading about the research
133940	135240	because it was so cool,
135240	137620	they actually took over all of the lightbulbs
137620	141600	on campus in a war flying demo from their drone.
142320	146260	Since I already was familiar with Eyal Ronen's work
146260	150160	and both Eyal Ronen and Achior are all colleagues of mine,
150160	152400	I talked with Eyal Ronen and together we decided
152400	155740	that with his help, I'm going to continue on the research
155740	157720	and take it to the next level.
158160	160280	So, what did they find?
160880	164040	Well, it turns out that attackers can remotely steal
164200	165980	a lightbulb from a given ZigBee network
165980	167920	and force it to join their own.
168300	169940	Once it joined the network,
169940	172840	attackers can send the lightbulb a malicious firmware update
172840	174820	to fully take over it.
175220	177020	And if that wasn't enough,
177020	179120	it turns out that even a regular lightbulb
179120	180520	can steal other lightbulbs
180520	182760	and you don't need any fancy RF equipment
182760	184980	or an antenna in order to do it.
185840	188220	Using these three primitives together,
188220	190220	the researchers claim that you can take over
190720	193420	a selected set of lightbulbs in a given city.
193420	194280	From each lightbulb,
194280	197240	you'll take over the other lightbulbs in close proximity
197750	200200	and so on and so forth in order to propagate
200200	203380	and take over all of the lightbulbs in a given city
203380	206080	in a nuclear-like chain reaction.
206640	210260	Sadly for us, the vendor did fix the last vulnerability
210710	212940	and we were only left with the first two.
213840	215740	If you put it visually,
215740	218420	we can see the network diagram over here.
219300	221200	On the right, we can see a smart lightbulb
221200	224100	which communicates with its bridge, the controller,
224100	225980	over ZigBee radio.
226060	228180	The bridge is connected to both the radio network
228180	230700	and the computer network with an ethernet cable
230700	234180	so we could control the lightbulb from our mobile phone
234960	236580	through the controller.
237040	238860	The attack itself will start
238860	240280	when the attacker will transmit
240280	242960	ZigBee factory reset messages to the lightbulb
242960	244300	in order to confuse it
244300	247280	and convince it to join their own network.
247500	249120	Once it joined the network,
249120	251860	attackers can send a malicious over-the-air firmware update
251860	255220	to the lightbulb to fully take over the lightbulb itself.
256300	257680	And while the original research
257680	259300	only focused on the lightbulbs,
259300	261940	we are focused on a much broader target
261940	265460	and we want to take their research to the next step.
265460	267520	We want to infiltrate the network.
268340	270240	In order to infiltrate the network,
270240	271780	we are hoping to find a vulnerability
272300	276620	so that our lightbulb will be able to remotely exploit
276620	278820	the ZigBee vulnerability in the bridge itself
278820	280640	in order to take over it.
281240	282820	Once we took over the bridge,
282820	285380	the bridge can launch attack inside a computer network
285380	287740	and hopefully allow us to take over the computers
287740	289740	inside the network itself.
290300	292580	Once we understood our attack vector,
292580	294240	it's time to get started.
299540	303000	But first, some preliminary slides on ZigBee.
303460	305440	ZigBee is a suite of high-level protocols
305440	307740	for closed proximity networks.
307880	311580	It's an IEEE 802.154-based specs
311580	315540	that defines a low-range, low-power radio.
316000	318720	Not to be confused with IEEE 802.11,
318720	321840	which stands for the more commonly used Wi-Fi.
322720	325660	The maximal transmission unit, or the MTU,
325660	329280	over ZigBee is only 127 bytes long.
329280	330460	And I repeat that.
330460	333440	The maximal packet we can transmit over the air
333440	336680	contains only 127 bytes.
336680	339120	And with this harsh limit,
339120	342580	we should be able to somehow exploit vulnerabilities
342580	345100	that we hope to find in the bridge.
346540	348760	ZigBee has a full network stack of its own.
349360	351000	Like any other network stack,
351000	352420	it starts with the lower levels,
352420	353740	which is the physical layer
353740	355740	and the medium access control layer,
355740	358000	which acts as the internet acts
358000	360200	in normal computer networks.
361040	363680	On top of that, we have the network access layer,
363680	367060	which is responsible for both routing and encryption.
367820	370200	Above that, we have the application sub-layer,
370200	372340	which is responsible for routing our packet
372340	375380	to the respective application in the upper layers.
375820	378260	This application could be ZDP,
378260	380380	which stands for ZigBee Device Profile
380380	383180	and responsible for managing different aspects
383180	384840	of the ZigBee protocol.
385280	388760	It could be ZCL, ZigBee Cluster Library,
388760	391100	which is responsible for managing the configurations
391100	392960	of the different devices.
393660	395920	And it could be whatever other application
395920	397880	that the vendor decided to implement.
398500	400780	Now that we understood how ZigBee works,
400780	402420	it's time to meet our target.
403360	404700	The target for this research
404700	407320	is going to be the Philips Hue Smart Lighting,
407320	409160	now under Signify.
410400	413140	Signify controls approximately one third of the market
413140	415600	in the UK, so it's a broad target.
416040	418280	And we're going to focus specifically on the bridge
418280	420560	because as we mentioned earlier,
420560	422560	the bridge is connected to both the radio network
422560	423780	and the computer network,
423780	425280	and we hope to bridge the two.
427000	429660	Specifically, we're going to focus on a second generation
429660	431300	of hardware for the bridge,
431300	433160	which is the rectangular version of the bridge
433160	434380	as seen on the right.
435460	437780	If you remove the plastic cover from the bridge,
437780	439140	we can see the board.
439760	440840	When looking on a board,
440840	442860	we can see on the right, the main CPU,
442860	444980	which is a Qualcomm CPU usually found
444980	447060	on Wi-Fi enabled devices.
447960	450840	Over the left, we can see an Atmel CPU,
450840	454080	which we'll refer to as the ZigBee modem.
454080	456440	And like any other embedded device,
456440	459220	we have a clear pinout for serial debug,
459220	462440	which turned out to be quite useful throughout this research.
464120	466420	The main CPU is a MIPS architecture,
466420	467720	which is quite unique.
467800	470560	And the operating system is Linux.
470620	473740	This is quite refreshing because in prior research projects,
473740	477520	we mainly had to handle real-time operating systems,
477520	479280	which are harder to debug.
479340	481420	This time, since we have Linux,
481420	482740	we hope to be able to root it
482740	485240	and to access it directly using an SSH connection
485560	488580	in order to extract the file of the firmware itself,
489260	492680	and in order to hopefully install a remote GDB server
492680	494940	in order to debug the device.
495580	498400	And luckily enough, Colin O'Flynn details in his blog
498400	499840	exactly how to root the bridge
499840	504300	with a step-by-step guide followed by a video.
505000	508400	Once finished, we will get a root SSH connection.
509840	511920	When I started this research,
511920	514840	LLNN told me that the bridge is using a single huge process
514840	517720	that's pretty much doing everything.
517720	519560	And this is the IP bridge.
520460	521840	The IP bridge is a single process
521840	524120	that acts as the brain of the device.
524120	528020	It is responsible for parsing incoming ZigBee messages,
528020	530380	maintaining the different ZigBee state machines,
530380	533160	and pretty much doing everything it needs.
534200	536280	And like any other embedded device,
536280	538720	IP bridge runs with root privileges,
538720	541580	which means that once we took over this process,
541580	544040	we don't need any other vulnerability.
544860	547300	Now that we saw all of these data,
547300	550420	it's time to start looking for vulnerabilities
550420	553120	and IP bridge is going to be our target.
557320	559400	We had quite a slow start to begin with
559400	561040	because due to technical issues,
561040	562300	I couldn't root the bridge.
562300	564820	It turns out that I don't have the right hardware equipment
564820	567840	as my younger brother rightfully pointed out.
568400	570520	And the package we ordered got delayed
570520	573080	like pretty much any other research project
573080	575320	I've done thus far.
575780	577340	Instead of sitting idle,
577340	580260	we decided to start working on the old firmware version,
580260	582880	which we received from the original research team.
583240	585780	This is a firmware version, which is a few years old,
585780	588220	and we really hope that it didn't change a lot
588220	590680	throughout the years, but we really don't know.
590680	594300	We simply have to cross our fingers and hope for good.
595980	597840	When analyzing IP bridge,
597840	600420	we soon enough saw something quite odd.
600920	603460	The code expects strings to be found inside
603460	605840	incoming messages instead of bits,
605840	610460	because we can see the strings as such as ZDP or ZCL
610460	611940	or even connection,
611940	616800	but the maximum message size is only 127 bytes long.
616800	620180	We don't have enough room for textual strings.
620180	623880	We have enough room for mere single bits and that's it.
623880	626260	So what's going on?
626780	629300	And things got complicated.
629980	632700	It turns out we forgot about the ZigBee modem.
632940	635400	The ZigBee modem uses Atmel's BitCloud SDK
635400	637960	in order to parse incoming ZigBee messages
637960	640900	before they arrive to the main CPU.
642080	643980	Effectively, it acts as a co-processor
643980	646100	that handles the ZigBee lower network layers
646100	648060	instead of the main CPU.
648840	651600	It converts the parse messages to textual form
651600	655520	and sends them over serial to the main CPU to be handled.
656200	659040	And of course we don't have the firmware for it,
659040	660400	so it's a black box.
662520	664840	The modem reduces the attack surface on the main CPU
664840	668880	because complex parsing is offloaded to the modem.
668880	671960	And if the main CPU doesn't handle a specific task,
671960	674620	it can be vulnerable when doing so.
675020	676980	And we don't fully control the messages
676980	678840	which are sent to the main CPU
678840	682520	because they are constructed on the modem itself.
683960	685860	And if that wasn't enough,
685860	688100	it puts a huge question mark on everything we find
688100	691100	because maybe the modem checks it.
691840	693660	Maybe there's no check at all.
693880	696380	So we'll have to add this to the list of ongoing issues
696380	698480	and really hope for the best.
700100	702060	Our first vulnerability attempt focus
702060	706340	on ZigBee cluster library, which is ZCL.
706540	709160	ZCL is responsible for managing configurations
709160	712140	and it really is similar to SNMP
712140	714460	in traditional IT networks.
714780	717720	It offers a read attribute, write attribute interface
717720	720660	and it supports multiple data types.
720880	723620	The first data type is Boolean.
723640	726840	Then we have an unsigned integer of eight bits,
726840	731080	an unsigned integer of 32 bits, and even a dynamic array.
731760	735320	And a variable size data type in an embedded device
735320	737740	is a sure recipe for vulnerabilities.
737960	739680	It looks promising.
740020	742620	When we dived in to look how ZCL arrays
742620	744340	are being parsed in the code,
744340	746280	we saw the following code snippet.
747220	749180	Here we can see that at first,
749300	751500	a one byte length field is read from the message
752040	755100	and then a fixed buffer is allocated over the heap
755100	757300	with 33 bytes.
757940	760800	Don't be confused by the delay slot in MIPS.
760800	764260	The assignment into register A0 is done chronologically
764260	767280	before the invocation of the malloc function
767820	770520	and that's why it's called a delay slot.
770820	773720	Effectively, we allocate a fixed size buffer over the heap
773720	774820	and that's it.
775520	777840	Later on, we'll read the entire blob
777840	781920	from our attackers packet into the fixed size buffer.
782320	783860	And what does it mean?
783860	786420	Well, a controlled one byte name copy
786420	788040	into a fixed size heap buffer
788040	791380	and that's the definition of a heap-based buffer overflow.
792740	794460	Sadly for us, it isn't a vulnerability
794460	797700	until we have a working proof of concept to trigger it.
797840	799340	We don't have the latest firmware
799340	801240	and things might get changed.
801700	803640	The modem might block large ZCL arrays
803640	804780	because we don't know.
805140	806260	And we can't test it
806260	807700	because we don't have the radio equipment
807700	810380	to transmit the attack and check it.
810900	813700	Luckily enough, the package arrived quite in time
814180	815520	and we can now load the bridge
815520	816720	and extract the latest firmware
816720	819220	and check if something got changed.
819560	821680	And of course it did.
822040	825380	It turns out that now ZCL arrays are no longer supported
825740	828140	and instead there was an additional support
828140	830000	for ZCL strings.
830000	832560	But if we look on the support of strings,
833640	836520	we can see that the following code was changed.
836520	839180	Now we allocate a dynamic buffer on the heap
839180	840820	using the one byte length field
840820	844760	plus an additional one byte for the added null terminator.
845260	848240	This means we don't have any vulnerability this time,
848240	849240	which is bad.
850280	852500	Of course, we still have some good news
852500	854320	because as you can see,
855160	858260	the firmware was shipped with debug symbols.
858660	860520	For some unknown reason,
860520	862180	the new firmware version supports
863140	865780	and was shipped with all of the names
865780	867980	of all of the functions in the firmware,
867980	870080	which was really quite useful for us
870080	872340	for reverse engineering the new firmware.
873220	874740	So what do we have?
875000	877680	The latest firmware version dropped support for the ZCL arrays
877680	880160	because now they use strings instead
880160	882660	and strings don't have a vulnerability in them.
883440	886620	It's a good time to search for other vulnerabilities.
887000	888560	And we did try.
888560	890260	We really, really did try
890260	891660	and we covered most of the firmware
891660	894840	and still we found pretty much nothing.
895800	897400	And then remember,
898640	900700	the ZCL strings were handled correctly
900700	902680	and sent to another thread.
902680	905460	But what does this thread do
905460	907600	with the incoming ZCL strings?
907600	911160	So we traced it down to this code snippet.
911160	912220	In this code snippet,
912220	915800	we can see the same memory location over the heap
915800	919580	using the same fixed size we saw earlier.
919580	922300	So that's quite suspicious.
922920	924980	We can even see that later on,
924980	927020	the buffer is being copied
927260	929400	to the newly allocated heap buffer
929740	932340	using the length field stored in the struct itself
932340	934280	without any side checks.
934560	937000	The only condition for reaching this code snippet
937000	940700	is to have the fixed size of code of 16
941300	943320	stored in our struct.
943540	944620	And when we go back
944620	947480	to how we initialize the ZCL string struct,
947480	951600	we can see that it indeed uses the same opcode, 16.
951600	955100	So it turns out that someone forgot
955100	958140	to finish the migration from arrays to strings.
958180	961660	Strings should have been marked with F for strings
961660	965620	and then be duplicated using a call to strdup.
965620	968420	Instead, for some reason,
968420	971260	internally they are still marked with 16 for arrays
971260	974060	and are handled using the same vulnerable code snippet
974060	975780	we saw in the earlier firmware version,
975780	978040	which is quite good from our perspective.
978040	981540	So the original vulnerability still exists.
981540	984760	It is just buried deeper, that's all.
985520	987560	Time to start transmitting ZigBee messages
987560	989540	and hope to trigger the vulnerability.
998300	1000120	In order to play around with ZigBee,
1000120	1001320	like the previous research,
1001320	1007200	we decided to use the ATmega256RFR2x probe board.
1007340	1010720	It enables us to send and receive ZigBee frames
1010720	1011740	over the radio.
1013200	1015840	It should be computationally equivalent to a light bulb,
1015840	1016940	which is quite important
1016940	1019680	because we are going to do all of our exploit
1019680	1021080	from this board.
1021080	1022580	And if we will succeed,
1022580	1024920	then the same exploit could have been performed
1024920	1026420	from a light bulb we took over
1026420	1028700	using the previous research findings.
1030220	1032840	In addition, it turned out to be even more important
1033780	1037840	because there's really strict timing constraints in ZigBee.
1037840	1039200	And the timing constraints dictate
1039200	1042200	that we actually use C code from the board itself.
1042200	1045040	We can't use Python from our laptop, for example.
1045980	1048260	This means that the entire ZigBee code,
1048260	1050340	the entire ZigBee stack that we need to implement
1050340	1051620	should be in C.
1051620	1055020	And the entire exploit should also be implemented in C.
1055020	1056320	So it's not going to be easy,
1056320	1059080	but we'll have to live with this.
1060260	1062260	And the vulnerable flow is only accessible
1062260	1064840	during a process called commissioning.
1064940	1067120	And what is commissioning?
1067120	1070380	Well, commissioning is a process of pairing
1070380	1072340	and associating a new light bulb.
1072340	1074260	We have two types of commissioning.
1074260	1076060	We have classic commissioning
1076060	1079280	and we have touch link commissioning.
1079280	1081900	The Philips Hue app on Android, which we use,
1081900	1084260	initiates a classic commissioning process.
1084260	1086120	And so we focus on this one.
1086740	1088480	Technically, in theory,
1088480	1091260	the ZigBee specs explain the entire process.
1092080	1094480	In practice, there's a lot of room for vendors
1094480	1097340	to do as they wish, and trust me, they do.
1098960	1101640	When analyzing the protocol, we got quite stuck
1101640	1105300	because there was no documented flow,
1105300	1107980	or at least no documented flow we could find.
1107980	1109180	There was enough documentation
1109180	1112000	for the structure of each specific message,
1112000	1114460	but we don't know what message is supposed to be sent
1114890	1117260	and when, as a response for what,
1117260	1120540	so we don't have any clear flow for the commissioning.
1121300	1124340	In addition, we can't sniff a full conversation
1124340	1126040	from our light bulb and the bridge
1126040	1128160	because too many messages are sent
1128160	1129600	and they are sent too fast,
1129600	1131780	and we simply miss some of them.
1132920	1136780	If that wasn't enough, we need a cryptographic key.
1136900	1138380	There is a transport key,
1138380	1141240	which is shared between all of the ZigBee Lite devices,
1141240	1143920	but we don't have the key inside.
1143920	1145280	So how do we get it?
1145280	1148640	We need to decrypt the messages really from an early phase
1148640	1149860	in the commissioning.
1149880	1151660	We will need the key.
1153040	1155640	Luckily for us, we are not the first to tackle this issue,
1155640	1157980	and in this blog post,
1157980	1159500	you can find all of the information
1159500	1162640	for all of the keys used in touch link commissioning
1162640	1164080	and in classic commissioning
1164780	1167260	with the values of the keys themselves.
1167440	1170700	So we took the keys, we inserted them to Wireshark,
1170700	1172140	and Wireshark can now automatically
1172140	1174340	decrypt the messages we sniff.
1175740	1178140	The analysis and the implementation part
1178140	1181380	took a lot of effort, a lot of work days,
1181380	1183100	but eventually it worked.
1183560	1185940	We managed to fake our own light bulb.
1185940	1188400	You can see a brand new checkpoint research light bulb
1188400	1191100	with the model CPR123.
1191100	1194180	So now our board is doing
1194180	1196500	all of the classic commissioning phase,
1196500	1198480	faking our own light bulb,
1199080	1201180	so we could continue on.
1201480	1204460	In order to help other researchers with this task,
1204460	1206360	we decided to open source the full pickup
1206360	1207820	of the classic commissioning
1207820	1210360	as we sent it from our board.
1210360	1211880	So instead of other researchers
1211880	1214940	having to manually analyze the commissioning phase,
1214940	1216480	you can now look on the pickup,
1216480	1220000	the decrypted pickup with all of the messages we've sent.
1221940	1224420	The lessons we learned thus far are,
1225340	1226840	without user interaction,
1226840	1228660	the bridge won't accept new light bulbs,
1228660	1230880	which is a good security precaution,
1230880	1232120	but it doesn't help us.
1232120	1236340	We will need somehow to bypass this limitation.
1236900	1240100	In addition, we have approximately one minute
1240100	1242500	to commission as many light bulbs as we want.
1242500	1244860	There is no check about it.
1245180	1247540	The user will only see the light bulbs in the app
1247540	1251420	after they finished a specific phase we labeled ZCL phase,
1251420	1257280	which is pretty much the last phase in the commissioning.
1257780	1259880	If we fake other light bulbs
1259880	1262040	and we stop before the ZCL phase,
1262040	1263600	the user won't be aware of that,
1263600	1265840	which is pretty good for our attack.
1266520	1268340	And the really good news are,
1268340	1269660	we managed to trigger the vulnerability
1269660	1273680	during the ZCL phase, so we have a success.
1273680	1275300	We really have a vulnerability.
1276600	1278820	There is no state machine check in place.
1278820	1281880	We can simply send whatever ZCL strings we want,
1281880	1285220	whenever we want, without any request to get them.
1285220	1287480	So we can pretty much do anything we want
1287480	1289020	with the long ZCL strings,
1289700	1292900	as long as we do it during the ZCL phase,
1292900	1295260	and specifically during the commissioning.
1295260	1298320	Once the light bulb was fully added to the network,
1298320	1300560	it can no longer trigger the vulnerability.
1300580	1302420	The vulnerability will only be accessible
1302420	1304440	during the commissioning phase.
1305560	1307700	Time to start the exploit.
1312430	1316090	Just a basic recap on our vulnerability before we continue.
1316730	1320310	We have a linear-based buffer overflow over the heap.
1320850	1324110	Our buffer size is limited to 70 controllable bytes.
1324270	1328030	And this is because we only started with 127 bytes,
1328030	1329930	which is the MTU on ZigBee,
1329930	1332470	and the ZCL is quite high on the ZigBee stack.
1332470	1334790	So we lost a lot of bytes due to headers.
1335230	1338450	We will have to settle down with the 70 bytes we have.
1339330	1341670	We don't have any byte constraints on our payload,
1341670	1342490	which is good.
1342490	1345270	We can send null bytes, non-printable bytes,
1345270	1346950	pretty much everything we want.
1347730	1350550	And the destination buffer is allocated over the heap
1350550	1354270	using a fixed size buffer of 43 bytes.
1355870	1357570	Time to focus the heap.
1358450	1360050	The bridge uses uclibc,
1360050	1362270	which is an old embedded libc implementation
1362270	1364190	used in embedded devices.
1364830	1367130	The chosen heap implementation inside uclibc
1367130	1368610	is the malloc standard,
1368610	1371110	which is dlmalloc behind the scene.
1372210	1374770	Effectively, it is much like glibc,
1374770	1377230	but with way less sanity checks.
1377510	1381670	And this is because uclibc stands for micro-libc.
1381670	1385390	It is meant to be used by devices without a lot of RAM,
1385390	1387590	without a lot of CPU power,
1387590	1389610	so it has to be slim.
1389750	1392130	And being slim means there's less code
1392130	1394150	and less sanity checks.
1395750	1397810	All of our free buffers will fall into the range
1397810	1399730	of what is called fast bins.
1400330	1401910	There's a bin for each buffer size
1401910	1403530	in multiple of eight bytes,
1403530	1406490	starting from 16 being the minimal size.
1406490	1412870	So we have a bin for all of the buffers up to 16 bytes,
1413030	1415930	a bin for 16 to 24,
1416130	1417930	a bin for 24 to 32,
1417930	1419790	and so on and so forth.
1420210	1422950	Inside each bin, we will have a singly-linked list
1422950	1424670	of all of the free buffers.
1425910	1429650	When examining the code for free in uclibc,
1429650	1431850	we saw the following check.
1432110	1434290	If size is less than or equal
1434290	1437210	to some configurable amount called max-fast,
1437210	1439990	we will use the fast bins
1439990	1441830	and store our buffer inside them.
1441830	1445450	In order to find the respective fast bin for our buffer,
1445450	1447290	we will use the fast bin index macro
1447290	1448870	we can see over here.
1449450	1452350	In short, the macro divides the size by eight
1452350	1453830	and subtracts two,
1453830	1457070	because 16 should be the minimal size.
1457070	1458910	But there's no check in place
1458910	1464190	that the size indeed is bigger or equal to 16.
1464190	1467710	So if we will be able to corrupt a buffer over the heap
1467710	1469170	and modify the size,
1469170	1471310	we could change the size to be eight
1471310	1473090	or even zero,
1473090	1475090	giving us the indices of minus one
1475090	1476970	and minus two, respectively.
1477450	1479510	In order to understand what will happen
1479510	1481690	if we will use negative indices,
1481690	1484170	we can see the malloc state start over here
1484170	1487330	and the variables before the fast bins array.
1487810	1491190	So if we will use index minus one,
1491190	1493850	we will store our buffer on top of the max-fast
1493850	1495970	before the fast bin array.
1496410	1499130	Storing a pointer over the configurable size
1499130	1502690	for fast bins will be too risky.
1502690	1504690	It will simply ruin the heap.
1504830	1507950	But what will happen if we'll use index minus two?
1508030	1512270	Well, index minus two will store the pointer to our buffer
1512270	1514730	before the malloc state variable.
1514730	1517830	And before the malloc state start in memory,
1517830	1520950	it turns out to be an unused variable,
1520950	1522390	simply nothing.
1522470	1526430	So if we free a buffer with size of zero,
1526430	1528330	it will be stored somewhere in memory
1528330	1530010	before the malloc state,
1530010	1531630	and no one will reach it.
1531770	1533930	The next buffer will be joined to it,
1533930	1535450	creating a ghost link list
1535450	1538750	we can refer to as the dev null fast bin.
1538850	1541430	Since malloc is not aware of this bin,
1541430	1543710	it won't extract buffers from it.
1543710	1545490	And all of the buffers we free
1545490	1547310	will be joined to this bin,
1547310	1549710	but won't be returned to the heap itself,
1549710	1554030	effectively enabling us to gradually shape the heap
1554030	1555750	in the desired structure.
1557510	1560710	The plan for our heap overflow is quite simple.
1560730	1562470	We can see our buffer in blue
1562470	1566050	and a buffer adjacent to it in memory in purple.
1567190	1569170	The plan is to modify only the size
1569170	1571830	and the pointer of the adjacent buffer.
1572890	1575130	If you change the size to one,
1575130	1577310	which means a size of zero bytes
1577310	1581950	and one for the previous buffer is in use,
1581950	1584990	then the buffer will go to the dev null link list
1584990	1589650	because size zero will reflect it to index minus two.
1589930	1594450	And the pointer will be changed to be our arbitrary address.
1595210	1597870	Effectively, we want to get this structure.
1597870	1600970	We want to corrupt the singly linked list inside fastbin
1600970	1604530	so that an arbitrary buffer will be stored,
1604530	1607510	or at least malloc will think that an arbitrary buffer
1607510	1610630	will be stored in our arbitrary address.
1611090	1613570	The goal is we want to confuse malloc
1613570	1616210	so it will allocate a buffer at an arbitrary address
1616210	1620470	and then will let us write our data into this buffer,
1620470	1624250	effectively giving us a write-what-where exploit primitive.
1625070	1628270	The heap shaping strategy is as follows.
1628570	1631470	If we overflow this free fastbin buffer buffer,
1631470	1632930	then we won.
1632930	1634610	This is exactly what we aim at.
1634610	1637030	We corrupted the singly linked list inside the fastbin
1637030	1639510	and we will get our allocation.
1640490	1642810	If we overflow the use buffer,
1642810	1644370	then when it will be freed,
1644370	1646310	it will go to the dev null fastbin
1646310	1648230	and we won't see it any longer.
1649570	1653150	If we overflow the use buffer that lives forever,
1653150	1656630	oh, well, nothing would happen and no one will notice it.
1657650	1660470	But if we overflow the free large buffer,
1660470	1661790	then we're in trouble.
1661790	1663270	We will probably crash soon,
1663270	1665450	so we really don't want to do that.
1666150	1667470	If done correctly,
1667470	1670010	we will get the desired malloc-where primitive.
1671330	1674850	malloc-where will grant us the ability to write over the got.
1674850	1678030	The got is the global offset table.
1678090	1680130	It's a global table of function pointers
1680130	1682130	used to execute library functions,
1682130	1686310	such as free, malloc, sleep, memcpy,
1686310	1689170	and pretty much every other library call.
1689270	1692530	And luckily for us, the got is at a fixed address.
1693630	1697090	The modified function pointer will jump to our shell code,
1697090	1698590	or at least in theory,
1698590	1700430	because it sounds easy on paper,
1700430	1702750	but it's way harder in real life.
1708190	1710400	Time to construct the shell code.
1712310	1714730	Location, location, location.
1715230	1717510	We need to store a binary shell code
1717510	1719470	in a fixed global address.
1720050	1722390	The problem is we only get textual messages
1722390	1723990	from the ZigBee modem,
1723990	1727390	so we don't get any controlled binary data
1728070	1730190	into the main CPU.
1730770	1735250	We found only one good candidate for such a possible buffer,
1735250	1737450	and this is the ZigBee phone book.
1737990	1740070	This is an array of ZigBee addresses
1740070	1743470	seen by, or advertised to, the bridge.
1744430	1747610	It can hold up to 65 records of 16 byte each,
1747610	1750990	giving us an upper bound of approximately one kilobyte
1750990	1752870	for the entire shell code.
1753550	1757130	It's not a lot of bytes, but it should be enough for us.
1758350	1760990	The neighbor record inside the ZigBee phone book
1760990	1763410	is constructed as follows.
1763470	1767210	The first eight bytes are for the extended network address,
1767210	1768830	which we fully control.
1768910	1771290	After that, we have additional two bytes
1771290	1775190	for the short network address, again, fully controlled.
1775890	1778390	And our stroke of luck ended,
1778390	1781650	which is quite reasonable, sorry,
1781650	1785910	because now we have six bytes for miscellaneous fields,
1785910	1787870	and we don't really control them.
1787870	1790290	So we have 10 consecutive bytes we control,
1790290	1793010	but we don't control the entire memory.
1794970	1797310	Oh, and about that.
1797310	1798930	It turns out the bridge is unstable
1798930	1801710	when it gets more than 20 records,
1801710	1806730	so this is going to be quite a small shell code.
1807790	1811370	The initial plan was simple.
1811610	1814530	It looks infeasible to restore the execution flow,
1814530	1816690	because we pretty much ruined the heap.
1817350	1820550	Instead, our shell code will try to patch the binary
1820550	1823870	on the file system and install a backdoor.
1823870	1826370	After the process will crash,
1826510	1830230	a daemon will reboot the binary with our backdoor,
1830230	1833390	and then we will trigger it from another light bulb.
1834410	1837950	Problem is, both the patch and the file path
1837950	1840770	don't fit in 10 consecutive bytes each,
1840770	1844510	so we can't decode them properly in the ZigBee phone book.
1844530	1848990	The solution for this problem is purely academic.
1849890	1853270	An ideal shell code by reduction will be,
1853270	1857250	use the 10 consecutive bytes per record to build a decoder,
1857250	1859470	and the decoder will decode the rest of the records
1859470	1862570	to be nicely ordered in memory.
1863430	1865850	In MIPS 16, a jump to the next record
1865850	1867870	will only cost us two bytes,
1867870	1870570	giving us eight spare bytes in each record
1870570	1872730	to construct our decoder.
1874530	1877110	But there are problems with this plan.
1877650	1879670	We need to clear the instruction cache
1879670	1882730	before jumping to the unpacked shell code,
1882730	1886650	and because this is a MIPS CPU and we crashed when trying.
1887590	1890070	And if we use sleep to clear the cache,
1890070	1893470	as people usually do, the watchdog will kill the process
1893470	1895550	because it doesn't respond.
1896430	1900310	And we don't have enough records to silence the watchdog,
1900310	1902390	sleep, and use a decoder,
1902390	1905090	so the ideal shell code is good on paper,
1905090	1907270	but it's not practical.
1908350	1911390	Instead, we went for a more bold design.
1912120	1913930	We will restore the execution flow.
1913930	1916130	We really don't have any choice.
1916830	1918790	This means we will call mprotect
1918790	1922270	to modify the permissions of the code in memory
1922270	1926410	from executable to be executable and writable,
1926410	1928830	and we will install the backdoor in RAM
1928830	1930270	during the execution.
1932390	1936750	A few days and one hand-crafted shell code later on,
1936750	1940450	we have a shell code that fully restores the execution.
1940450	1942850	It restores the GOT, it restores the HEAP,
1942850	1945390	and it restores pretty much everything we need.
1946250	1949710	In addition, the shell code will only cost us 16 records,
1949710	1952570	which is well in budget, less than 20.
1953810	1957090	And here we can see the shell code in IDA.
1957490	1960510	From the first record, we will jump to the second,
1960510	1962450	and then we'll jump to the third,
1962450	1966030	and so on and so forth until we install the backdoor
1966030	1968010	and restore the execution flow.
1969630	1972670	When we connect all of the dots together,
1972670	1974050	the backdoor shell code will give us
1974050	1975810	an arbitrary write primitive.
1976590	1979530	Our exploit will fake an additional legitimate light bulb,
1979530	1982310	but we'll leverage this arbitrary write primitive we installed
1983030	1986510	and we'll use it to write Scout's loader to memory.
1987450	1990670	Upon execution, Scout will load the full payload,
1990670	1993450	which in this case, we've chosen to use EternalBlue.
1994590	1997470	Here we can see that Scout dropped the file
1997470	2001110	on tmp.exploit with root privileges,
2001110	2004010	and this tmp.exploit file will use EternalBlue
2004010	2006830	to attack computers inside a computer network,
2006830	2009830	which is a good time for our demo.
2019100	2022200	Here we can see the light bulb and the user using it.
2022560	2023920	We can see that it works.
2023920	2025380	The app works fine.
2025380	2027860	And the user can modify the color of the light bulb
2027860	2029000	as he wishes.
2034900	2036240	When the attacker starts,
2036240	2038540	he will try to hijack the light bulb
2038540	2040440	and steal it from the network.
2040820	2043220	And once he joined the attacker's network,
2043220	2045720	the attacker will change the light bulb to a hideous color
2045720	2046980	to annoy the user,
2047840	2050020	so that the user will see that something is wrong
2050020	2051160	with his light bulb.
2052680	2056500	So we took over the light bulb and now it's ours.
2057180	2059140	When the user sees that something is wrong,
2059140	2062000	you can see that he no longer controls the light bulb,
2062000	2063900	he can't change the light bulb's color,
2063900	2068240	and it seems to be unreachable when it sees it over the app.
2069120	2072080	The only way to reinstall the light bulb is to delete it
2072080	2075200	and tell the bridge to search for new light bulbs.
2075200	2078160	And this is where our attack will officially start.
2078880	2080680	We will fake a legitimate light bulb,
2080680	2083620	so the user will be happy, this is our light bulb,
2083620	2087620	and we will fake it as the user actually configures
2087620	2089240	the light bulb as he wishes,
2089240	2091320	so the user won't see that something is wrong
2091320	2093500	with our fake light bulb.
2096270	2099030	Behind the scene, the full attack will take place.
2102640	2106680	Here we can see that the bridge is connected to the laptop,
2106680	2108780	so it's connected to the computer network.
2109440	2112100	And now behind the scene, we will use our vulnerability,
2112100	2114140	shape the heap and take over the bridge.
2114140	2116020	And from the bridge, we will use EternalBlue
2116020	2120300	to attack the computer inside the network and pop a cock.
2120440	2122480	So our attack worked.
2124420	2126920	Time for the coordinated disclosure.
2127700	2129480	The vulnerability was reported to Signify
2129480	2132120	on the 5th of November, 2019.
2132780	2135200	The vendor confirmed the vulnerability on the same day,
2135200	2136660	which is quite impressive.
2136660	2139820	It's even more impressive because not only the vendor
2140420	2143060	sent its acknowledgement on the same day
2143060	2145140	when it received our report,
2145140	2149040	it actually acknowledged the existence of the vulnerability,
2149040	2152320	which it found in the code according to our report.
2152380	2156060	So the vendor did pretty much everything in a single day,
2156060	2158000	which is very impressive.
2159700	2161340	Later on, Signify issued a patch
2161340	2163520	via an automatic update in January.
2164260	2166500	And you can find the full details and advisory
2166500	2167680	in our blog post.
2167680	2170820	And the official CVE issued for this specific vulnerability
2171440	2174940	is CVE-2020-6007.
2175580	2178860	And if you have Philips Hue lighting in your office
2178860	2181140	or in your home, don't worry.
2181140	2184380	All of the products should have received the update by now.
2185660	2186860	Conclusion.
2187960	2191940	Even with an MTU of 127 bytes, ZigBee vulnerabilities
2191940	2195180	are indeed exploitable as we've shown in our demo.
2196580	2201000	Security mitigations only work when they are on by default.
2201480	2203320	The IP bridge binary was compiled
2203320	2205740	to use static fixed addresses.
2205740	2207720	So we were able to target the GOT
2207720	2209480	which was on a fixed address,
2209480	2212160	even without an information leak vulnerability.
2212860	2215780	The binary was not compiled with any stacking areas.
2215780	2217120	The GOT was writable,
2217120	2219520	so we could do pretty much everything we want to do
2219520	2222000	once we had an initial vulnerability.
2222620	2226160	Still, there was ASLR in place for the heap,
2226160	2228700	for the stack, and for the loaded libraries,
2228700	2230200	and that's thanks to Linux.
2230200	2232760	So if it's on by default, you will get it,
2232760	2235340	but if you need to manually do something in your makefile,
2235340	2238580	you won't get it in most common cases.
2240000	2243380	And small devices are becoming popular by the minute,
2243380	2246200	and yet we can't even trust our own light bulbs.
2246200	2248780	So maybe we should do something about it.
2250060	2253240	We can't finish this research and this presentation
2253240	2254900	without saying special thanks
2254900	2257500	to everyone that helped make this research possible.
2257500	2260740	So we have Eyal Ronyan for the research idea
2260740	2262840	and the active guidance.
2263580	2265420	Colin O'Flynn for the detailed write-ups
2265420	2266240	on routing the bridge
2266240	2268860	and the entire hardware analysis of it.
2269640	2272500	For Peter, for publishing the ZigBee transport keys
2272500	2273480	for the light bulbs,
2273480	2276100	which we used and couldn't continue without.
2276960	2278780	And for Yaron Itkin,
2278780	2281440	for the crucial hardware support along the way.
2281560	2282980	Thanks, little brother.
2283540	2285120	And last but not least,
2285120	2286980	for the entire CPR research team
2286980	2290760	and for their support alongside this very long research.
2291340	2294460	Until the next time, thank you for joining this talk.