1
00:00:00,000 --> 00:00:19,255
35C3 preroll music
2
00:00:19,255 --> 00:00:30,393
Herald Angel: So… Yaniv Balmas is a
software engineer and he started tinkering
3
00:00:30,393 --> 00:00:35,558
with Commodore's C64 when he was 8
years old.
4
00:00:35,558 --> 00:00:38,836
He was kind of a teenage hacker of games as well.
5
00:00:38,836 --> 00:00:43,497
And now he's in the security field and he
got interested in the fax machine
6
00:00:43,497 --> 00:00:51,762
together with his friend Eyal Itkin, who
is also a security guy and malware researcher.
7
00:00:51,762 --> 00:00:57,373
And together they're going to tell us
about the fax machines and What The Fax?!
8
00:00:57,373 --> 00:01:00,911
Why still using people those machines?
9
00:01:00,911 --> 00:01:03,805
And it's gonna be really interesting I think.
10
00:01:03,805 --> 00:01:08,278
And the title is also
"Hacking your network likes it's 1980 again"
11
00:01:08,278 --> 00:01:12,308
I'm really excited. Please give a warm
round of applause to those two guys.
12
00:01:12,308 --> 00:01:15,552
applause
13
00:01:15,552 --> 00:01:25,159
fax modem sounds
14
00:01:31,259 --> 00:01:35,568
Yaniv: Thank you, thank you guys.
Hi, CCC!
15
00:01:35,568 --> 00:01:39,276
You probably know this sound, right?
And now get to know us:
16
00:01:39,276 --> 00:01:44,553
My name is Yaniv Balmas, I'm a security
researcher. I work at Check Point Research,
17
00:01:44,553 --> 00:01:50,172
and with me here today is Eyal Itkin, also a
security researcher, also works at
18
00:01:50,172 --> 00:01:55,269
Check Point Research, and let's begin
with talking a bit about the history of fax.
19
00:01:55,269 --> 00:01:59,131
So I guess that not many of you know
that fax started,
20
00:01:59,131 --> 00:02:03,745
it was first invented in 1846 by a scientist
called Alexander Bain.
21
00:02:03,745 --> 00:02:09,480
Fun fact, this happened 20 years before
the invention of the light bulb.
22
00:02:09,480 --> 00:02:14,060
And then it had some more advances to it,
this is the actual first thing that looked
23
00:02:14,060 --> 00:02:16,582
like a fax machine, a standard fax machine.
24
00:02:16,582 --> 00:02:20,710
And again, this thing was invented 20
years before the invention of the telephone.
25
00:02:20,710 --> 00:02:25,292
So humanity was sending faxes before we
had light or talked over the phone.
26
00:02:25,292 --> 00:02:29,948
And then there was some more
advancements like radio fax,
27
00:02:29,948 --> 00:02:34,894
and an another important point in time is
1966, where a small unknown company
28
00:02:34,894 --> 00:02:39,995
called Xerox invented – came out with the
first commercial fax machine.
29
00:02:39,995 --> 00:02:42,988
This is the advertisement for it.
30
00:02:42,988 --> 00:02:49,805
And in 1980 a strange organization
called ITU defined the core standards for fax.
31
00:02:49,805 --> 00:02:56,234
Namely it's T.30, T.4, T.6, and those
standars are still the same standards
32
00:02:56,234 --> 00:03:00,304
that we use today – basically, with just
minor changes to them.
33
00:03:00,304 --> 00:03:05,065
So this was all in the past.
But what's happening today?
34
00:03:05,065 --> 00:03:09,512
I mean today we have far better ways
to send electronic documents
35
00:03:09,512 --> 00:03:11,544
from one to the other, right?
36
00:03:11,544 --> 00:03:14,882
You know, let's compare fax to just, I dunno,
off the top of my head
37
00:03:14,882 --> 00:03:21,704
just, you know, one method like, let's say, email.
And just to, you know, remind you.
38
00:03:21,704 --> 00:03:27,758
We are comparing this… to this, okay?
So… let's look at some of the features here.
39
00:03:27,758 --> 00:03:36,433
In terms of quality, in terms of accessibility,
I'm pretty sure that all of you here
40
00:03:36,433 --> 00:03:43,424
have 24/7 access to emails. Not so sure
you're carrying around your fax machines with you.
41
00:03:43,424 --> 00:03:48,679
In terms of reliability, well, when you
send a fax, you don't really know
42
00:03:48,679 --> 00:03:52,979
if it got received or not. Yes, there is
this strange confirmation page,
43
00:03:52,979 --> 00:03:55,910
but it doesn't really mean anything.
I mean, if there's no paper in the
44
00:03:55,910 --> 00:04:01,812
receiving fax, you still get it. If the
dog ate it, you still get it.
45
00:04:01,812 --> 00:04:08,895
There's absolutely no reliability in fax.
Regarding authenticity, well, we can argue
46
00:04:08,895 --> 00:04:12,638
about emails, if it's authenticated or
not, it could be forged, of course.
47
00:04:12,638 --> 00:04:16,449
But we do have public key cryptography
and stuff like that, that will help us
48
00:04:16,449 --> 00:04:21,842
when talking about emails, while we don't have…
we don't have nothing when it comes to fax.
49
00:04:21,842 --> 00:04:26,487
Absolutely no authenticity. So, if we're
looking at this table, one might think to
50
00:04:26,487 --> 00:04:31,307
himself: Okay, so… Who the hell still
uses fax today? It's 2018.
51
00:04:31,307 --> 00:04:37,285
I mean, it deserves a place in the museum
of great technologies and that's it.
52
00:04:37,285 --> 00:04:40,144
So, nobody is using fax today, right?
53
00:04:40,227 --> 00:04:41,796
Wrong.
54
00:04:41,858 --> 00:04:44,929
Everybody are using fax today.
55
00:04:44,929 --> 00:04:52,322
You see, fax is used to send these very
critical maritime maps to ships at open seas
56
00:04:52,322 --> 00:04:57,924
90% of the japanese population uses fax –
according to Wikipedia at least.
57
00:04:57,924 --> 00:05:02,965
And if you google any kind of combos like
"contact us" and "fax" or stuff like that,
58
00:05:02,965 --> 00:05:08,379
you will come up with something like
300 million results. 300 million published
59
00:05:08,379 --> 00:05:13,006
fax numbers in Google. And that's not
counting the unpublished numbers.
60
00:05:13,006 --> 00:05:17,978
That's a huge amount of numbers. But it's
not all about numbers. It's not "how many
61
00:05:17,978 --> 00:05:22,126
fax machines are out there?", but it's
also "Who is using fax?"
62
00:05:22,126 --> 00:05:25,957
You see, if you're a small corporation, a
medium corporation, a huge corporation,
63
00:05:25,957 --> 00:05:30,344
you have fax. Not necessarily anybody is
sending fax to this number, but there is a
64
00:05:30,344 --> 00:05:35,614
fax machine sitting there waiting for a
fax to be received. If you're a bank,
65
00:05:35,614 --> 00:05:41,211
you simply love faxes. This is
Bank of China, the biggest bank in the
66
00:05:41,211 --> 00:05:47,129
world, and that's the fax number of it.
I think most importantly, if you're a
67
00:05:47,129 --> 00:05:49,697
government organization… you…
laughter
68
00:05:49,697 --> 00:05:53,362
… simply wake up in the morning and you
want to have more fax. This is
69
00:05:53,362 --> 00:05:56,979
Donald Trump's fax number if anybody wants
to send him a fax. Go ahead.
70
00:05:56,979 --> 00:06:02,975
That's it. It's not a secret, it's from
Google… We should send him something
71
00:06:02,975 --> 00:06:10,020
by the way. And the thing is that, you know, those
banks and government institutions, they
72
00:06:10,020 --> 00:06:14,844
don't only support fax, allow you to send
fax, the funny thing is that actually most
73
00:06:14,844 --> 00:06:18,726
of the time, it's mandatory to send fax,
there is no other way. You can either
74
00:06:18,726 --> 00:06:22,473
postal mail it, or fax it. They didn't
hear about anything else.
75
00:06:22,473 --> 00:06:26,426
So we looked at this, state of affairs,
strange state of affairs,
76
00:06:26,426 --> 00:06:31,063
and said to ourselves: "This looks
strange". I mean, it can't be true.
77
00:06:31,063 --> 00:06:35,840
Humanity came so far and we're still using
these old technologies, so…
78
00:06:35,840 --> 00:06:38,572
What The Fax?!
79
00:06:38,572 --> 00:06:43,369
And we decided and try to do something
about it. And we started very long
80
00:06:43,369 --> 00:06:50,224
research to try and find some security
vulnerabilities in fax. And before we do
81
00:06:50,224 --> 00:06:56,698
that, you need to explain how fax looks
like today. You see, today fax doesn't
82
00:06:56,698 --> 00:07:01,888
look like it looked 20 or 30 years ago.
Then, it was just standalone fax machines.
83
00:07:01,888 --> 00:07:02,618
Right?
84
00:07:02,618 --> 00:07:08,382
Today, fax is mostly old technology
embedded within newer technology.
85
00:07:08,382 --> 00:07:16,030
So, we have fax to email services or email
to fax services, we have as I said before,
86
00:07:16,030 --> 00:07:22,237
radio fax and fax over satellite and stuff
like that. I think most commonly, we have
87
00:07:22,237 --> 00:07:28,725
this. These machines. All-in-one printers.
You buy them, they scan, they print.
88
00:07:28,725 --> 00:07:32,525
And they fax. It actually comes with a
phone cable out of the box, so you can
89
00:07:32,525 --> 00:07:37,341
connec… I guess most people connect it?
I also think that is the most common
90
00:07:37,341 --> 00:07:41,838
faxing solution today. So we decided to
take a look at these machines.
91
00:07:41,838 --> 00:07:47,412
These fax machines.
If you look at these boxes
92
00:07:47,412 --> 00:07:52,248
from a security point of view you can
imagine them to be just black boxes.
93
00:07:52,248 --> 00:07:56,464
And those black boxes have interfaces.
In one side of the box we have interfaces
94
00:07:56,464 --> 00:08:02,021
like WiFi, bluetooth, ethernet, stuff like
that, these interfaces connect the printer
95
00:08:02,021 --> 00:08:05,751
to the internal network, the external
network, basically it connects it to the
96
00:08:05,811 --> 00:08:11,534
world. And on the other side of this box,
there's this little interface here that
97
00:08:11,534 --> 00:08:16,721
connects this black box to somewhere
to the 1970s I would say.
98
00:08:16,721 --> 00:08:18,396
Laughter
99
00:08:18,396 --> 00:08:19,986
So that's pretty funny.
100
00:08:20,041 --> 00:08:26,894
And if you remember, at the end of the day
these printers are basically nothing but
101
00:08:26,894 --> 00:08:31,468
computers. They have CPUs, they have
memories, they have operating systems,
102
00:08:31,476 --> 00:08:34,598
they are computers. Not standard ones,
but they are computers.
103
00:08:34,598 --> 00:08:39,871
And we were thinking to ourselves, imagine
this scenario: There's an attacker sitting
104
00:08:39,871 --> 00:08:45,326
somewhere in the world. All he has is
access to a phone line and his targets fax
105
00:08:45,326 --> 00:08:50,366
number. What will happen if this attacker,
this guy, would be able to send a
106
00:08:50,366 --> 00:08:55,443
malicious fax and with this malicious fax
he would be able to exploit the printer.
107
00:08:55,448 --> 00:09:00,958
Then he has complete control over the
printer, right? If he does that, he could
108
00:09:00,978 --> 00:09:07,196
then maybe pivot through any one of those
other interfaces, let's say the Ethernet
109
00:09:07,196 --> 00:09:12,228
and jump from this printer to the rest of
the network, the internal network.
110
00:09:12,228 --> 00:09:16,778
Effectively creating a bridge between the
external world and the internal network
111
00:09:16,778 --> 00:09:20,090
through the phone line.
That's 1980s again!
112
00:09:20,090 --> 00:09:26,377
So we thought this is a really cool attack
scenario and we decided to accept this
113
00:09:26,377 --> 00:09:31,774
challenge and go for it. Try and actually
show this thing happening in reality.
114
00:09:31,774 --> 00:09:37,282
We were really excited about this.
But then after we slept a bit and drank
115
00:09:37,282 --> 00:09:42,797
a bit, sat down and talked about it, we
kind of found out that there is like a lot
116
00:09:42,797 --> 00:09:47,920
of challenges, really hard challenges in
front of us and we're not really sure how
117
00:09:47,920 --> 00:09:54,148
to deal with them. Let me name just a few
of them. One of the challenges is how do
118
00:09:54,148 --> 00:09:58,010
we obtain the firmware. The code that this
printer runs. It's not like you have it
119
00:09:58,010 --> 00:10:02,566
everywhere. And after we get it, how do we
analyze this firmware?
120
00:10:02,566 --> 00:10:03,776
After we analyze it,
121
00:10:03,776 --> 00:10:07,521
we need to understand what operating
system are those printers running.
122
00:10:07,521 --> 00:10:10,122
And then we need to understand how to
debug a printer..
123
00:10:10,122 --> 00:10:11,792
I never debugged a printer before..
124
00:10:11,792 --> 00:10:15,098
I need to understand how to debug
a printer. And after we do all that,
125
00:10:15,098 --> 00:10:20,032
we need to understand… How does fax even
work? We only know the beeping sounds like
126
00:10:20,032 --> 00:10:25,823
most of us I think. And after we did all
that, we can start talking about where can
127
00:10:25,823 --> 00:10:29,325
we find vulnerabilities inside this
big, big, big ecosystem.
128
00:10:29,325 --> 00:10:33,716
And today, we'll try to take you through
these challenges, one-by-one and explain
129
00:10:33,716 --> 00:10:38,157
how to do it until we'll be able to
actually do the scenario that we just
130
00:10:38,157 --> 00:10:43,634
showed you. So, let's start with the first
challenge.
131
00:10:43,634 --> 00:10:49,282
How do we obtain the firmware
for the printer?
132
00:10:49,282 --> 00:10:53,082
So, meet our nice printer.
It's an HP inkjet printer,
133
00:10:53,082 --> 00:10:59,237
an HP Officejet printer, we chose this
model, first of all we chose HP because
134
00:10:59,237 --> 00:11:03,729
it has like – I think – 40% of the market
share so it's not that we dislike HP, we
135
00:11:03,729 --> 00:11:07,632
really like them, but unfortunately for
them, they are just the biggest target out
136
00:11:07,632 --> 00:11:12,108
there. And this specific model, well we
had a lot of reasons why we chose this
137
00:11:12,108 --> 00:11:16,800
printer. But basically it's the cheapest
one.
138
00:11:16,800 --> 00:11:19,267
Laughter
139
00:11:19,267 --> 00:11:23,029
We bought it. We didn't have a lot of
budget. We bought it and we abused it for
140
00:11:23,029 --> 00:11:30,716
a lot of time. And our goal was to break
fax, but before we do that, we had to
141
00:11:30,716 --> 00:11:36,877
break the printer. I mean literally break
the printer. So yeah, that was the fun
142
00:11:36,877 --> 00:11:42,320
part of the project, we broke it. And
inside the printer we find this thing:
143
00:11:42,320 --> 00:11:46,583
The main PCB, the brains behind the
printer, and it looks like this.
144
00:11:46,583 --> 00:11:49,006
Let's map the critical components of it:
145
00:11:49,006 --> 00:11:53,836
So we have here: Flash ROM,
SPANSION some model,
146
00:11:53,836 --> 00:11:59,131
and then we have some more memory here,
this might look like not a lot, because
147
00:11:59,131 --> 00:12:04,594
the PCB has two sides to it of course,
and on the other side of it we have the
148
00:12:04,594 --> 00:12:08,001
more interesting components, like USB,
WiFi, electricity, SRAM,
149
00:12:08,001 --> 00:12:13,457
battery – probably for the memory but who
knows – and now we have two very
150
00:12:13,457 --> 00:12:18,682
interesting components here. One of them
is the main CPU. It's a Marvell CPU, and
151
00:12:18,682 --> 00:12:23,530
it's proprietarily manufactured for HP.
So we can't tell anything about it,
152
00:12:23,530 --> 00:12:27,526
there's no available specs, nothing.
We can just find bits of information
153
00:12:27,526 --> 00:12:34,712
here and there. And then we have the fax
modem. It's located here and it's a
154
00:12:34,712 --> 00:12:42,717
CSP1040. What we need to understand now is
how do these two components operate and
155
00:12:42,717 --> 00:12:46,646
what is the relationship between them?
If we do that, we're one step further.
156
00:12:46,646 --> 00:12:53,184
So that's what we tried to do. And as I
said, the first challenge is to get the
157
00:12:53,184 --> 00:12:57,153
firmware of this thing. And when we're
looking a bit closer into this PCB, we
158
00:12:57,153 --> 00:13:02,262
find these 2 very interesting interfaces:
One of them is a serial debug, the other
159
00:13:02,262 --> 00:13:08,151
is JTAG. If you're familiar with them, you
know that they give you debugging
160
00:13:08,151 --> 00:13:11,951
capabilities, or at least memory read,
memory write, exactly what we need to get
161
00:13:11,951 --> 00:13:15,444
the firmware. So we're smiling to
ourselves saying "Haha, this is going to
162
00:13:15,444 --> 00:13:19,519
be really easy". But unfortunately it's
not. Because the JTAG is, of couse,
163
00:13:19,519 --> 00:13:24,747
disabled completely. We can't do anything
with it. And the serial port, we managed
164
00:13:24,747 --> 00:13:30,228
to connect to it. And we get this terminal
that for almost every instruction we type
165
00:13:30,228 --> 00:13:34,302
gives us this error: "I don't understand".
Well, we don't understand either.
166
00:13:34,302 --> 00:13:35,795
laughter
167
00:13:36,102 --> 00:13:40,394
But it looks like this terminal is not
going to get us very far. So we dropped
168
00:13:40,394 --> 00:13:45,433
this path and tried and look for other
ways to get the firmware and obviously one
169
00:13:45,433 --> 00:13:52,963
of the most common ways is to try and grab
the firmware upgrade and after looking a
170
00:13:52,963 --> 00:13:59,429
bit in the internet we find this jewel,
this FTP site by HP that contains
171
00:13:59,429 --> 00:14:02,734
every firmware version for
every HP product
172
00:14:02,734 --> 00:14:05,186
ever produced in the history
of HP and the Internet
173
00:14:05,186 --> 00:14:08,130
and a lot of other stuff.
174
00:14:08,130 --> 00:14:12,713
And it actually took us about, I think,
two weeks to find our firmware within
175
00:14:12,713 --> 00:14:12,963
Laughter
176
00:14:12,963 --> 00:14:18,197
… this mess of firmwares. But once we
did,
177
00:14:18,197 --> 00:14:21,082
we had a firmware upgrade file.
Applause
178
00:14:21,082 --> 00:14:24,971
Yes, thank you! It's still alive so you
can go there and look for some… there's a
179
00:14:24,971 --> 00:14:29,101
lot of interesting stuff in there. And now
we've got ourselves a file. And this file
180
00:14:29,101 --> 00:14:33,201
is the firmware upgrade file. It's not an
executable file, it's just a binary,
181
00:14:33,201 --> 00:14:36,396
and now we kinda need to understand…
182
00:14:36,396 --> 00:14:38,924
How do you even upgrade
a printer firmware?
183
00:14:38,924 --> 00:14:42,787
I never did it i before. Anybody did it?
Anybody upgraded these firmwares? Lately?
184
00:14:42,787 --> 00:14:46,948
Ah, good. Good for you. Good for you.
185
00:14:46,948 --> 00:14:52,320
Anyway, the answer to this question is
surprisingly… funny, I would say.
186
00:14:52,320 --> 00:14:54,170
You just print it.
187
00:14:54,170 --> 00:14:55,170
Laughter
188
00:14:55,170 --> 00:14:59,366
That's because, you see, a printer
receives a firmware upgrade just the same
189
00:14:59,366 --> 00:15:04,155
way as it receives a normal print job.
That's the thing and it's actually pretty
190
00:15:04,155 --> 00:15:09,504
nice and it's defined in a HP protocol,
it's called PCL XL Feature Reference
191
00:15:09,504 --> 00:15:13,984
Protocol Class 2.1 Supplement. And if
you're still sane after reading this like
192
00:15:13,984 --> 00:15:19,837
300 pages of insanity you understand that
this thing defines something called a
193
00:15:19,837 --> 00:15:24,455
PJL – print job language. If you ever
scanned from a printer to the network you
194
00:15:24,455 --> 00:15:30,198
see this port I think 9100, something like
that, open, that you send print jobs to,
195
00:15:30,198 --> 00:15:35,583
and it's the same port that you send the
firmware upgrade to, and that's nice.
196
00:15:35,583 --> 00:15:38,255
So when we look at the file, it actually
confirms this,
197
00:15:38,255 --> 00:15:41,783
because it actually begins
with the words: PJL – Print job language.
198
00:15:41,783 --> 00:15:44,499
So that's nice. So now we know it's a
print job language.
199
00:15:44,499 --> 00:15:48,317
But unfortunately this document doesn't
document anything about the firmware
200
00:15:48,317 --> 00:15:53,010
upgrade protocol, or anything,
because it's HP proprietary.
201
00:15:53,010 --> 00:15:55,710
So unfortunately we had
to do it ourselves
202
00:15:55,710 --> 00:16:01,931
and analyze this thing. Now I'm not going
to take you through the entire process of
203
00:16:01,931 --> 00:16:07,169
unwrapping this firmware because frankly
it's quite boring. But I'll just tell you
204
00:16:07,169 --> 00:16:11,167
that it's composed of several layers of
compression, one of them is called
205
00:16:11,167 --> 00:16:14,974
NULL decoder, the other is called TIFF
decoder, and another one called Delta Raw
206
00:16:14,974 --> 00:16:21,344
decoder. And the thing is that these
things do something like… If the previous
207
00:16:21,344 --> 00:16:25,685
line was all blanks, and if this line is
also all blanks, just write one instead of
208
00:16:25,685 --> 00:16:30,095
the line, so that gives you some kind of
compression, and it makes really a lot of
209
00:16:30,095 --> 00:16:34,702
sense when you're talking about print jobs
because paper has a lot of spaces in it,
210
00:16:34,702 --> 00:16:39,626
but when you're talking about binary files
it makes absolutely no sense to do it this
211
00:16:39,626 --> 00:16:46,809
way. But still, it just works this way, so
after we understand that, we were able to
212
00:16:46,809 --> 00:16:50,489
decode everything, decompress everything,
and we're talking to ourselves and
213
00:16:50,489 --> 00:16:53,420
laughing, when you're
a hammer everything looks like a nail,
214
00:16:53,420 --> 00:16:56,333
and when you're a printer,
everything looks like a print job.
215
00:16:56,333 --> 00:16:58,000
Laughter
216
00:16:58,000 --> 00:17:02,241
So that was nice. And now, after we did
that, we have a big file that hopefully
217
00:17:02,241 --> 00:17:04,986
now is our firmware.
218
00:17:04,986 --> 00:17:07,408
So how do we analyze it?
219
00:17:07,408 --> 00:17:10,929
Looking at this thing right at the
beginning of the file, there's something
220
00:17:10,929 --> 00:17:14,917
that really looks like a table. It doesn't
only really look like a table, it is
221
00:17:14,917 --> 00:17:20,636
a table. We define it, it looks like this.
And what this table defines is a loading
222
00:17:20,636 --> 00:17:25,560
address, section name and location in
binary. So what that means is that our big
223
00:17:25,560 --> 00:17:30,548
file is actually split into several
sections. This table just defines those
224
00:17:30,548 --> 00:17:35,350
sections. So now we are able to split this
big file into several smaller chunks and
225
00:17:35,350 --> 00:17:40,867
inspect each chunk. The most important
chunk, the one that looks most promising
226
00:17:40,867 --> 00:17:47,102
looks like it contains our firmware. So we
took a closer look into that and that's
227
00:17:47,102 --> 00:17:52,249
what we saw: It actually looks like our
firmware. That's because you see: That's
228
00:17:52,249 --> 00:17:55,412
one of the strings that we've seen here.
229
00:17:55,412 --> 00:17:56,569
Laughter
230
00:17:56,569 --> 00:18:00,896
Yeah! We all saw that before, right? It's
"Error: I don't understand". But it's not
231
00:18:00,896 --> 00:18:05,348
completely "Error: I don't understand".
There's some missing bytes in here.
232
00:18:05,348 --> 00:18:09,537
And actually those missing bytes are
pretty consistent throughout the entire
233
00:18:09,537 --> 00:18:13,945
chunk. So although we know that we are
looking at the code, we can't actually
234
00:18:13,945 --> 00:18:18,638
see the code until we have those missing
bytes filled. We need to understand: Why
235
00:18:18,638 --> 00:18:23,764
are they there and what were they replaced
with? So let's try to analyze this thing
236
00:18:23,764 --> 00:18:28,578
together, quickly, now. But first, let's
try to understand what is this thing.
237
00:18:28,578 --> 00:18:34,750
We have a lot of things in mind, every one
seemed crazy, but I think the least crazy
238
00:18:34,750 --> 00:18:40,682
option was that this is yet another form
of compression. A really bad one, again.
239
00:18:40,682 --> 00:18:44,437
Because when we tried to compress this
thing with zlib, for example, we get like
240
00:18:44,437 --> 00:18:49,146
80% better compression than it currently
is, and we know that the printer has zlib,
241
00:18:49,146 --> 00:18:53,895
because we see zlib strings in there, so
why not use zlib? I don't know.
242
00:18:53,895 --> 00:18:57,716
But still, we are left with a challenge.
So this is one snippet of the code that
243
00:18:57,716 --> 00:19:00,420
you just saw,
so let's try to decompress this.
244
00:19:00,420 --> 00:19:03,957
First of all, you need to understand this
thing is composed of two types of
245
00:19:03,957 --> 00:19:08,471
characters, one are ASCII characters,
stuff that you can read, and some other
246
00:19:08,471 --> 00:19:13,781
are stuff that you can't read, non-ASCII
characters. And those non-ASCII characters
247
00:19:13,781 --> 00:19:18,054
are actually those missing bytes that we
have. So we need to understand what they
248
00:19:18,054 --> 00:19:22,135
are, so let's take a closer look at them.
And if you stare at this thing long enough
249
00:19:22,135 --> 00:19:27,386
you'll start seeing some kind of pattern.
I'll save you the trouble and just show you.
250
00:19:27,386 --> 00:19:33,529
It's composed of these one single bytes,
and then those double bytes in there.
251
00:19:33,529 --> 00:19:37,838
And if the distance between the single
bytes looks suspiciously patterned,
252
00:19:37,838 --> 00:19:42,212
8 bytes, 9 bytes, 9 bytes, 8 bytes, over
and over again, so what does this mean,
253
00:19:42,212 --> 00:19:47,094
where is the pattern here? If you look at
this from a different angle, maybe the
254
00:19:47,094 --> 00:19:52,353
pattern will look a bit clearer. You see
that F7 and F7, they look the same.
255
00:19:52,353 --> 00:19:55,469
The FF and FF, they look the same.
Something here looks really pattern-ish.
256
00:19:55,469 --> 00:20:00,044
In order to understand this pattern, you
need to sharpen your binary view a bit,
257
00:20:00,044 --> 00:20:05,124
and if you understand that FF is just
8 one bits, and if you do that
258
00:20:05,124 --> 00:20:08,794
consistently for all of these chunks, you
will start seeing the pattern.
259
00:20:08,794 --> 00:20:13,631
The pattern is that the zero bit always
falls within this two-byte hole.
260
00:20:13,631 --> 00:20:18,131
It's consistent throughout the file. And
what this means is that the first byte is
261
00:20:18,131 --> 00:20:22,638
just a bitmap describing the following
8 bytes after it. That's what it means.
262
00:20:22,638 --> 00:20:27,171
And that's perfect because now we
understand what is this single bytes, but
263
00:20:27,171 --> 00:20:32,202
we still don't understand, what are those
double bytes? And they were replaced with
264
00:20:32,202 --> 00:20:37,615
something, but with what? So if you know
anything about compression, you know that
265
00:20:37,615 --> 00:20:41,572
there's not a lot of options here really.
It could be either a forward or backward
266
00:20:41,572 --> 00:20:46,499
pointer, it could be a dictionary of some
sort, or it could be a sliding window.
267
00:20:46,499 --> 00:20:50,200
Now we can pretty easily confirm that
it's not a forward/backward pointer just
268
00:20:50,200 --> 00:20:54,167
because we tried to follow the references
in the file, we see nothing that should be
269
00:20:54,167 --> 00:20:58,922
there, same goes for dictionary. We can't
find anything that's consistent enough to
270
00:20:58,922 --> 00:21:03,000
be a dictionary. So it leaves us only with
with the option of a sliding window.
271
00:21:03,000 --> 00:21:08,366
Once we're equipped with this information,
we go to our favorite place, to Google.
272
00:21:08,366 --> 00:21:12,821
And try to find some similar
implementations to this. Luckily for us,
273
00:21:12,821 --> 00:21:18,797
in some very dark corner of the internet,
we find this wiki page. It defines
274
00:21:18,797 --> 00:21:25,145
something called a Softdisk Library
Format. I won't ask if someone knows what
275
00:21:25,145 --> 00:21:31,988
Softdisk is, because probably somebody
knows here, it's CCC after all. But inside
276
00:21:31,988 --> 00:21:35,817
this thing it defines some kind of
compression algorithm that looks very
277
00:21:35,817 --> 00:21:41,623
similar to ours. It looks actually really
really like ours. Actually, it's exactly
278
00:21:41,623 --> 00:21:48,299
our compression algorithm. So yeah. That's
nice. And I think the funny thing here is
279
00:21:48,299 --> 00:21:53,786
that this compression algorithm was used
in the past somewhere, and only there.
280
00:21:53,786 --> 00:21:56,221
Can you guess where?
281
00:21:56,235 --> 00:21:58,612
Waiting for response from the audience
282
00:21:58,612 --> 00:22:03,820
Uh, yeah, somebody who didn't see chuckles
this presentation before?
283
00:22:04,116 --> 00:22:06,661
Yeah! It was used in Commander Keen.
284
00:22:06,661 --> 00:22:09,230
Softdisk is the company who produced
Commander Keen.
285
00:22:09,230 --> 00:22:12,181
So the compression algorithm
from Commander Keen made its way,
286
00:22:12,181 --> 00:22:17,094
somehow, into the entire HP line of
products.
287
00:22:17,094 --> 00:22:18,860
Laughter
288
00:22:18,860 --> 00:22:23,284
Applause
289
00:22:23,284 --> 00:22:27,577
How? I don't know! You can check if there
was anybody who was fired from Softdisk
290
00:22:27,577 --> 00:22:32,062
and hired in HP. Probably that would be my
guess. But we'll never know.
291
00:22:32,062 --> 00:22:36,757
So now we understand exactly what is this
thing, and how does this compression work.
292
00:22:36,757 --> 00:22:40,687
We have the missing data that we need. And
this data means that those two bytes are
293
00:22:40,687 --> 00:22:44,541
actually composed of window location and
data length. And that's all we need, and
294
00:22:44,541 --> 00:22:48,404
let me show you, like really quickly, how
this compression works. So we have an
295
00:22:48,404 --> 00:22:51,950
input text, output text and sliding
window. We want to compress this string
296
00:22:51,950 --> 00:22:56,397
over here, and let's try and do it.
So first byte is the bitmap, so we leave
297
00:22:56,397 --> 00:23:01,170
it empty for now. Then, second byte, we
start with "A". So we place it both in the
298
00:23:01,170 --> 00:23:05,447
output text and in the sliding window.
Then we go to "B", same thing. "C", same
299
00:23:05,447 --> 00:23:09,717
thing. "D", again, and now we get to "A".
But "A" is already present in the sliding
300
00:23:09,717 --> 00:23:13,631
window, so we don't need to write it in
the output text, we can just do
301
00:23:13,631 --> 00:23:19,183
nothing and then go to "B", same thing,
it's just the following character in the
302
00:23:19,183 --> 00:23:23,735
sliding window, and then when we get to
"E", we just write "00 02". That means
303
00:23:23,735 --> 00:23:28,636
"Go to the sliding window at position 0,
and take the first two bytes". That's what
304
00:23:28,636 --> 00:23:33,420
it means. Then we continue to "E", "F",
"G", after we did that, we input our
305
00:23:33,420 --> 00:23:38,490
bitmap here, and now we know the bitmap
value and that's all there is to it.
306
00:23:38,490 --> 00:23:40,130
That's the compression algorithm.
307
00:23:40,130 --> 00:23:42,885
It's pretty easy
looking at it this way, right?
308
00:23:42,885 --> 00:23:48,979
Looking at it in reverse is a bit more
difficult, but yes, now we can do that.
309
00:23:48,979 --> 00:23:52,839
And now we completely open everything, and
yes, we have our firmware, you can read
310
00:23:52,839 --> 00:23:56,321
everything. It's actual code. And now we
need to understand:
311
00:23:56,321 --> 00:24:00,139
What does this code mean? And basically,
first of all, we need to understand what
312
00:24:00,139 --> 00:24:03,984
architecture is this, what is the
operating system and so on and so on.
313
00:24:03,984 --> 00:24:09,771
So it took us quite some time to do that.
But let me give you a brief explanation.
314
00:24:09,771 --> 00:24:13,575
First of all, the operating system is
called ThreadX. It's a real-time operating
315
00:24:13,575 --> 00:24:20,707
system. The CPU, the processor, is ARM9
big-endian, and then it has several
316
00:24:20,707 --> 00:24:25,039
components to it, like stuff that's
related to system, some common libraries,
317
00:24:25,039 --> 00:24:31,936
and tasks. Tasks are the equivalent of
processes in normal operating systems.
318
00:24:31,936 --> 00:24:37,129
In the system stuff we have boot loaders
and some networking functionality and some
319
00:24:37,129 --> 00:24:43,356
other stuff, Common Libraries we have a
lot of common libraries, and tasks, once
320
00:24:43,356 --> 00:24:46,811
we're able to isolate them, we can
understand exactly the tasks, and once
321
00:24:46,811 --> 00:24:52,677
we do that, we now know that all we need
to do is focus on these tasks, because
322
00:24:52,677 --> 00:24:55,230
they're the tasks relevant
to fax protocols,
323
00:24:55,230 --> 00:24:56,940
we can leave everything else aside.
324
00:24:56,940 --> 00:25:01,807
It will make our work much more easy. We
want to start doing that. But,
325
00:25:01,807 --> 00:25:07,704
just a second before we do that. Looking
at this, we see something that looks not
326
00:25:07,704 --> 00:25:13,286
really… I don't know, it doesn't make
sense a lot. This thing is Spidermonkey.
327
00:25:14,066 --> 00:25:18,818
Every HP printer contains a Spidermonkey
library. I don't know if you know what
328
00:25:18,818 --> 00:25:22,724
Spidermonkey is, but basically it's the
JavaScript implementation by Mozilla.
329
00:25:22,955 --> 00:25:26,275
It's used in Firefox for example. And we
were thinking to ourselves:
330
00:25:26,275 --> 00:25:30,487
Why does a printer need to render
JavaScript? It makes no sense.
331
00:25:30,487 --> 00:25:34,893
I mean yeah, it has a web server, but it's
not a web client. We couldn't think of
332
00:25:34,893 --> 00:25:37,955
any situation in which a printer needs to
render JavaScript.
333
00:25:37,955 --> 00:25:43,402
It looked really strange to us. So we
decided to try and see where this printer
334
00:25:43,402 --> 00:25:49,365
is actually using JavaScript, so we went
back a bit and checked and we found that
335
00:25:49,385 --> 00:25:53,949
JavaScript is used in a feature called
PAC – Proxy Auto Configuration.
336
00:25:53,982 --> 00:26:04,612
It's pretty common, it's a good protocol.
It defines proxies when you're doing DHCP
337
00:26:04,760 --> 00:26:09,716
or something like that. The thing is that
the top layer functionality of this entire
338
00:26:09,716 --> 00:26:15,408
PAC functionality was written by HP.
And when we were looking at that, we see
339
00:26:15,408 --> 00:26:20,424
all this functionality, and we see this
strange thing here. The printer once it
340
00:26:20,424 --> 00:26:23,519
does this PAC functionality, it tries to
connect to this domain:
341
00:26:23,519 --> 00:26:26,846
fakeurl1234.com. Just connect to it and
do nothing with it.
342
00:26:26,846 --> 00:26:31,378
Some sort of sanity test I guess? I don't
really know why.
343
00:26:31,378 --> 00:26:39,386
But the interesting thing here is: Do you
know who owns the domain fakeurl1234.com?
344
00:26:39,386 --> 00:26:42,115
Laughter mixed with murmur
345
00:26:42,115 --> 00:26:42,908
No, it's not HP.
346
00:26:42,908 --> 00:26:44,731
Murmur & responses from the audience
347
00:26:44,734 --> 00:26:47,614
Ehh, Check Point is kinda… eh…, yeah.
348
00:26:48,886 --> 00:26:49,595
I own it.
349
00:26:50,087 --> 00:26:51,690
Laughter
350
00:26:51,690 --> 00:26:53,080
Applause
351
00:26:53,080 --> 00:26:58,290
It just wasn't registered.
So, we registered it for 5 Dollars.
352
00:26:58,290 --> 00:27:02,115
And now every HP printer is connecting to
my domain. Chuckling
353
00:27:02,336 --> 00:27:06,336
Laughter
354
00:27:06,496 --> 00:27:09,899
Applause
355
00:27:09,899 --> 00:27:13,319
So, if anybody wants to buy the domain, I
have a very good price for you:
356
00:27:13,319 --> 00:27:14,560
More than 5 dollars.
357
00:27:14,560 --> 00:27:18,808
And now I'll hand it over
to Eyal to continue.
358
00:27:19,363 --> 00:27:23,394
Eyal Itkin: Okay, thank you Yaniv.
After we've finished messing around with
359
00:27:23,394 --> 00:27:27,378
Spidermonkey, it's time to focus back on
fax, so T.30.
360
00:27:27,378 --> 00:27:31,706
T.30 – in its full name it's
ITU-T recommendation T.30 – is a standard
361
00:27:31,706 --> 00:27:37,521
that defines the fax protocol. Actually
it's a very very long PDF, more than
362
00:27:37,521 --> 00:27:42,025
300 pages. It defines all the phases and
messages we need in order to send and
363
00:27:42,025 --> 00:27:48,131
receive a fax document. It was first
defined very long ago, 1985, and was last
364
00:27:48,131 --> 00:27:53,377
updated more than a decade ago. So from
our perspective that's a very good idea,
365
00:27:53,377 --> 00:27:59,504
because we want to find vulnerabilities in
an old and complicated protocol.
366
00:27:59,504 --> 00:28:04,439
We're most probably going to find some.
After we read through the standard we
367
00:28:04,439 --> 00:28:12,358
started to dynamically look at it, opened
it in IDA and look up on the T.30 task.
368
00:28:12,358 --> 00:28:17,798
And you can see that the state machine is
quite huge as you can see here in IDA, and
369
00:28:17,798 --> 00:28:22,984
actually that's a small state machine.
Because most of the code blocks you can
370
00:28:22,984 --> 00:28:27,309
see over here contain additional state
machines inside them. Meaning that this is
371
00:28:27,309 --> 00:28:31,894
going to be a very very huge and
complicated state machine to reverse.
372
00:28:31,894 --> 00:28:36,594
And if that wasn't enough it turns out
that HP really likes to use
373
00:28:36,594 --> 00:28:40,388
function pointers and global variables in
their code. Meaning that statically
374
00:28:40,388 --> 00:28:47,336
reverse-engineering this huge task is
going to be very complicated. Although I
375
00:28:47,336 --> 00:28:52,266
personally prefer to statically
reverse-engineer, this time we had to
376
00:28:52,266 --> 00:28:56,783
choose a different tactic, we'll need to
dynamically reverse-engineer this thing
377
00:28:56,783 --> 00:29:00,463
and for this we'll need to have a
debugger.
378
00:29:00,463 --> 00:29:06,235
As Yaniv mentioned earlier, nobody knows
how can we debug a printer.
379
00:29:06,235 --> 00:29:11,976
We already tried built-in JTAG and
serial port and that failed.
380
00:29:11,976 --> 00:29:16,084
We then searched for a builtin GDB stub we
could use,
381
00:29:16,084 --> 00:29:18,964
but I couldn't find any such stub.
382
00:29:18,964 --> 00:29:24,215
At this point it's very important to
remember that even if we could control the
383
00:29:24,215 --> 00:29:29,432
execution flow, no-one can put a debugger
without controlling the execution flow,
384
00:29:29,432 --> 00:29:34,760
and we can't do anything, it's a black
box, I can send papers and that's it.
385
00:29:35,330 --> 00:29:40,948
And even if I could control the execution
flow and load my debugger, the printer
386
00:29:40,948 --> 00:29:46,295
uses a hardware watchdog. And this is an
external hardware mechanism that monitors
387
00:29:46,295 --> 00:29:51,566
the main CPU and whenever the main CPU
enters an endless loop or it halts,
388
00:29:51,566 --> 00:29:59,140
the watchdog reboots the entire printer.
This means that since essentially a
389
00:29:59,140 --> 00:30:02,904
breakpoint halts the program,
390
00:30:02,904 --> 00:30:06,239
whenever we hit a breakpoint,
the watchdog will kill us.
391
00:30:06,239 --> 00:30:11,086
So we need to find a way around this
thing, the easiest way we could find out
392
00:30:11,086 --> 00:30:16,780
was to split this enormous task into
chunks, if we could find any code
393
00:30:16,780 --> 00:30:21,785
execution vulnerability, we could try to
execute code over the printer and load our
394
00:30:21,785 --> 00:30:27,066
own debugger. And at this stage we had
luck, and we believe that luck is an
395
00:30:27,066 --> 00:30:35,058
important part in every research project.
On the 19th of July, SENRIO published a
396
00:30:35,058 --> 00:30:37,538
vulnerability called "Devil's Ivy".
397
00:30:37,694 --> 00:30:42,875
Devil's Ivy is a remote code execution in
gSOAP and many embedded devices (and our
398
00:30:42,875 --> 00:30:47,334
printer included) tend to implement a web
server for management and configuration,
399
00:30:47,334 --> 00:30:52,604
and in our case this web server uses
gSOAP, and it even uses a vulnerable
400
00:30:52,604 --> 00:30:57,810
version of gSOAP, so we now have our
vulnerability, and we'll need to exploit
401
00:30:57,810 --> 00:31:03,310
it. For those of you not familiar with
Devil's Ivy, here is the code.
402
00:31:03,737 --> 00:31:05,495
And here is the vulnerability itself.
403
00:31:06,361 --> 00:31:10,629
Devil's Ivy is a signed integer underflow
vulnerability,
404
00:31:10,629 --> 00:31:13,199
meaning that we'll need to send
405
00:31:13,199 --> 00:31:19,240
enough data for the variable to go from
negative back to positive. And that means
406
00:31:19,240 --> 00:31:22,695
we need to send roughly 2 Gigabytes of
data to the printer.
407
00:31:23,446 --> 00:31:26,870
So HP really prides itself on the printing
speed of the printer,
408
00:31:26,870 --> 00:31:28,817
but not on the network speed.
409
00:31:30,355 --> 00:31:35,382
After many optimization rounds we managed
to reduce the exploit time to roughly
410
00:31:35,382 --> 00:31:43,419
7 minutes. So you start the exploit, you
wait, and after 7 minutes you have
411
00:31:43,419 --> 00:31:50,761
your exploit. And here our good luck
ended, because we had a side effect in our
412
00:31:50,761 --> 00:31:57,216
exploit, and after two to ten minutes the
printer will crash. And this means we will
413
00:31:57,216 --> 00:32:02,600
need to wait an additional 7 minutes,
we'll have 2 minutes to debug it,
414
00:32:02,600 --> 00:32:08,518
and then it will crash again. So we
waited a lot of 7 minutes in our research.
415
00:32:08,518 --> 00:32:10,539
Laughter
416
00:32:10,539 --> 00:32:15,793
If you recall, we wanted a debugger so we
could dynamically reverse-engineer the
417
00:32:15,793 --> 00:32:20,240
firmware. We wanted read memory and write
memory, and now we have a debugging
418
00:32:20,240 --> 00:32:25,179
vulnerability, so we can load a debugger,
we need to execute this debugger, so
419
00:32:25,179 --> 00:32:28,930
we'll need executing permissions
to load it.
420
00:32:28,930 --> 00:32:30,638
The most important thing is that we need
421
00:32:30,638 --> 00:32:35,391
to execute our debugger without crashing
the firmware. Because we want the debugger
422
00:32:35,391 --> 00:32:41,159
to run and the firmware to debug and we
want them to blend inside the
423
00:32:41,159 --> 00:32:44,808
virtual address space of the printer,
living happily together.
424
00:32:44,808 --> 00:32:52,163
We couldn't find any debugger that achieve
this goal, so I did what my mother usually
425
00:32:52,163 --> 00:32:56,597
tells me not to do, we actually wrote our
own debugger.
426
00:32:58,089 --> 00:33:02,492
So this is Scout. Scout is an instruction
based debugger that supports Intel CPUs
427
00:33:02,492 --> 00:33:07,309
and ARM CPUs, because we have an ARM
printer. As a prototype we had a Linux
428
00:33:07,309 --> 00:33:11,489
kernel driver, and this time we're going
to use it its embedded mode.
429
00:33:12,062 --> 00:33:15,672
In embedded mode we compile it to be fully
positioned in the unintelligible,
430
00:33:15,672 --> 00:33:19,607
because we essentially throw it somewhere
inside the firmware and expect it to
431
00:33:19,607 --> 00:33:25,230
execute. We pre-equip it with useful
addresses like:
432
00:33:25,230 --> 00:33:29,339
memcpy, socket, bind, listen, we
find using IDA.
433
00:33:29,339 --> 00:33:33,330
And whenever it tries to
call these functions it goes to its
434
00:33:33,330 --> 00:33:35,827
own GAT, finds the address and
435
00:33:35,827 --> 00:33:38,292
jumps to it.
436
00:33:38,292 --> 00:33:45,137
After we compile it, we use it in our
exploit, we jump into this blob, and it
437
00:33:45,137 --> 00:33:49,354
starts up a TCP server, we can now connect
to to send instructions to
438
00:33:49,354 --> 00:33:52,651
read memory, to write memory,
and whatever we want.
439
00:33:53,588 --> 00:33:59,219
You can find Scout in our GitHub, with the
examples for Linux kernel driver and
440
00:33:59,219 --> 00:34:02,791
embedded mode. And we're actually using it
for some CVEs now,
441
00:34:02,791 --> 00:34:06,913
so it's highly recommended.
442
00:34:06,913 --> 00:34:09,487
Now that we reach this point in our talk,
443
00:34:09,487 --> 00:34:14,813
we haven't yet described to you how a fax
actually works, so with Scout we
444
00:34:14,813 --> 00:34:18,252
dynamically reverse-engineered the
firmware, and now we can actually
445
00:34:18,252 --> 00:34:24,669
describe to you how a fax actually works.
In order to send a fax, we need a sending
446
00:34:24,669 --> 00:34:29,688
machine, we need to send it to some modem,
the packets from the modem will be
447
00:34:29,688 --> 00:34:35,266
processed in the CPU, and afterwards, the
data is going to be processed and probably
448
00:34:35,266 --> 00:34:42,021
printed. Let's see how it starts. We start
with network interaction,
449
00:34:42,021 --> 00:34:48,402
probing and ranging, equalizer and echo
cancelling, more training,
450
00:34:48,402 --> 00:34:51,738
and you actually need to be quite familiar
with these steps,
451
00:34:51,738 --> 00:34:53,314
because they sound like this:
452
00:34:53,314 --> 00:34:55,333
repetitive fax modem sounds
453
00:34:56,017 --> 00:35:01,298
With these beeps, we actually created an
HDLC tunnel. Through this tunnel, we're
454
00:35:01,298 --> 00:35:07,882
going to send our T.30 messages, to
the CPU. In T.30 you have phase A,
455
00:35:07,882 --> 00:35:12,784
in which we send the caller ID, which is
a string. In phase B you negotiate the
456
00:35:12,784 --> 00:35:16,996
capabilities, so I send my capabilities
and receive the printer's capabilities.
457
00:35:17,726 --> 00:35:21,730
Phase C is the important step because here
we actually send our fax data,
458
00:35:21,730 --> 00:35:26,971
line after line, and page after page.
And in phase D, we finish. I send an ACK,
459
00:35:26,971 --> 00:35:31,520
I receive an ACK, and that's it.
Let us now see how a normal black/white
460
00:35:31,520 --> 00:35:36,161
fax document is going to be sent through
the protocol. So we have our document,
461
00:35:36,161 --> 00:35:41,426
it's going to be sent over the HDLC tunnel
using T.30 messages, over phase C, and the
462
00:35:41,426 --> 00:35:46,686
receive document is actually the body of a
TIFF file compressed in G.3 or G.4
463
00:35:46,686 --> 00:35:52,370
compressions. From our perspective, that's
partial good news, because there are
464
00:35:52,370 --> 00:35:56,867
many vulnerabilities when parsing TIFF
headers, and we only control the data
465
00:35:56,867 --> 00:36:01,116
of the file. The headers themselves are
going to be constructed by the printer
466
00:36:01,116 --> 00:36:03,899
itself, using messages from phase A
and phase D.
467
00:36:03,899 --> 00:36:11,255
So, we partially control a TIFF file and
after it's done and ready, the file
468
00:36:11,255 --> 00:36:17,143
is going to be printed. Like every good
protocol – and here it becomes very
469
00:36:17,143 --> 00:36:22,785
interesting – T.30 many extensions.
Can you guess what interesting extensions
470
00:36:22,785 --> 00:36:24,293
there are in the protocol?
471
00:36:27,510 --> 00:36:31,640
There's a security extension, but no-one
uses it, the other extension…
472
00:36:31,750 --> 00:36:33,740
is..
473
00:36:33,740 --> 00:36:34,597
Color Extension!
474
00:36:34,822 --> 00:36:36,955
Actually you can send colorful faxes and
475
00:36:36,955 --> 00:36:39,902
they really use it in hospitals
for some reason
476
00:36:41,670 --> 00:36:44,362
Let's see how colorful fax works.
477
00:36:44,362 --> 00:36:47,440
We send a document through
the HDLC tunnel,
478
00:36:47,440 --> 00:36:53,836
over phase C, and the received document is
actually a JPEG file. This time we control
479
00:36:53,836 --> 00:36:58,587
the header and the data of the file, and
we can do whatever we want to it,
480
00:36:58,587 --> 00:37:00,476
and send it for printing.
481
00:37:00,476 --> 00:37:02,806
Now that we know how a fax
actually works,
482
00:37:02,806 --> 00:37:05,125
where should we look for
vulnerabilities in it?
483
00:37:05,125 --> 00:37:10,036
Well, we have complicated state machines,
withstand strings, there are
484
00:37:10,036 --> 00:37:13,518
several file layers, but the most
convenient layer is the applicative one,
485
00:37:13,518 --> 00:37:17,452
and most importantly, JPEG, because we
control the entire file.
486
00:37:18,461 --> 00:37:22,802
If we look at a JPEG file, it mainly
consists of markers, we have a
487
00:37:22,802 --> 00:37:26,165
start marker, application marker with
length and data, more markers with length
488
00:37:26,165 --> 00:37:29,367
and data, and so and and so on.
489
00:37:29,367 --> 00:37:35,504
If we zoom in on one such marker, we can
see that in this marker we have a
490
00:37:35,504 --> 00:37:41,368
compression table, a 4x4 compression
matrix for the exact document we send, we
491
00:37:41,368 --> 00:37:45,510
have a header, length field, 4x4 matrix,
and the data itself.
492
00:37:46,383 --> 00:37:52,667
If you zoom in a bit deeper, we can see
that here we get a matrix, we sum up all
493
00:37:52,667 --> 00:37:56,656
of the values. This matrix should be
rather sparse, with zeroes, ones,
494
00:37:56,656 --> 00:38:00,183
and twos. The accumulated value is going
to be our length field,
495
00:38:00,183 --> 00:38:04,882
in this case 6 bytes, and 6 bytes are
going to be copied from the data to
496
00:38:04,882 --> 00:38:08,582
a local, small, stack buffer.
Like this.
497
00:38:09,175 --> 00:38:12,969
So if you consider vulnerabilities, at
this point we were like "What The Fax?!"
498
00:38:13,352 --> 00:38:18,078
because that doesn't make sense. We
control the entire header. If you put huge
499
00:38:18,078 --> 00:38:23,503
values in our matrix, like so, we have a
4 kilobyte length field copied into
500
00:38:23,503 --> 00:38:29,232
a stack buffer of 256 bytes, effectively
having a stack-based buffer overflow in
501
00:38:29,232 --> 00:38:30,909
our printer.
502
00:38:34,018 --> 00:38:38,020
It's a trivial stack buffer overflow, we
have no byte constraints, we can use
503
00:38:38,040 --> 00:38:43,773
whatever we want, null bytes, non-ASCII
bytes, whatever we want. And 4 kilobytes
504
00:38:43,773 --> 00:38:49,429
user-controlled data, that's more than enough
to exploit. At this point we had to bypass
505
00:38:49,625 --> 00:38:53,946
several operating system security
mitigations… Nah, not exactly.
506
00:38:53,946 --> 00:38:55,441
Laughter
507
00:38:55,441 --> 00:39:00,395
It's an …, fixed address spaces, no
canaries, it's the eighties, it's really
508
00:39:00,395 --> 00:39:06,147
simple. We've got the CVEs from HP,
9.10 critical, you should really patch
509
00:39:06,147 --> 00:39:11,339
your printers now. And here you can see
the response we have seen from HP after
510
00:39:11,339 --> 00:39:14,463
we've worked with them to patch these
vulnerabilities,
511
00:39:14,463 --> 00:39:17,392
which is a good time for our demo!
512
00:39:20,505 --> 00:39:24,044
Yaniv Balmas: Unfortunately we couldn't
really live-demo, so we just filmed
513
00:39:24,044 --> 00:39:27,530
something for you. So, this is our
attacker machine, all you need to do is
514
00:39:27,530 --> 00:39:31,150
run this script, it's connected to a modem
that we bought for like 10 dollars
515
00:39:31,150 --> 00:39:38,270
from Amazon. We're sending our malicious
fax to this printer, and… yeah.
516
00:39:38,270 --> 00:39:42,554
Incoming call… from who?
517
00:39:45,000 --> 00:39:46,000
Wait just a second.
518
00:39:46,778 --> 00:39:49,459
Eyal Itkin: Faxes are slow.
Yaniv Balmas: Yeah, they are.
519
00:39:49,996 --> 00:39:54,587
Yaniv Balmas: So, from an evil attacker of
course, we forged this easily. And now,
520
00:39:54,587 --> 00:40:00,298
the printer is receiving the fax, and
processing it, and now it's obviously a
521
00:40:00,298 --> 00:40:04,729
colorful fax, and now we have full control
over the printer, so it's ours.
522
00:40:05,795 --> 00:40:09,654
But that's not enough! Because we want to
show that we can propagate to another
523
00:40:09,654 --> 00:40:16,077
computer, so our malicious fax, contained
EternalBlue in it, so once any computer is
524
00:40:16,077 --> 00:40:20,746
connected to the network, the fax now will
recognize it, and will try to exploit it,
525
00:40:20,746 --> 00:40:22,672
and here you go!
526
00:40:22,893 --> 00:40:31,482
Laughter & Applause
527
00:40:31,743 --> 00:40:36,318
So yeah, we made it after all.
It was a long way.
528
00:40:36,482 --> 00:40:40,645
Some conclusions we have to tell you:
First, PSTN seems to still be
529
00:40:40,645 --> 00:40:45,487
a valid attack surface in 2018. Fax can
be used as a gateway to internal networks,
530
00:40:45,487 --> 00:40:49,680
and old and outdated protocols… probably
not so good for you, try not to use them
531
00:40:49,680 --> 00:40:54,260
if you can. What can you do to defend
yourself against this catastrophy?
532
00:40:54,407 --> 00:40:57,953
A lot of things. First of all, you can
patch your printers, as Eyal said,
533
00:40:57,953 --> 00:41:03,193
this link will just tell you if your
printer is vulnerable, by the way, every
534
00:41:03,193 --> 00:41:08,497
HP Inkjet (or HP Officejet) printer is
vulnerable to this thing, it's the biggest
535
00:41:08,497 --> 00:41:11,364
line of printers from HP, over – I think –
200 or …
536
00:41:11,364 --> 00:41:13,949
Eyal Itkin: 300
Yaniv Balmas: … 300 models are vulnerable
537
00:41:13,949 --> 00:41:19,447
to this thing, so really go and update!
Another thing I could tell you is:
538
00:41:19,447 --> 00:41:25,282
If you don't need fax, don't use it.
Also, if you do need to use fax after all,
539
00:41:25,282 --> 00:41:29,997
try and make sure your printer is
segregated from the rest of the network,
540
00:41:29,997 --> 00:41:33,576
so even if somebody takes over the
printer, he will just be confined to the
541
00:41:33,576 --> 00:41:38,988
printers, and won't be able to take over
your entire network. These are really good
542
00:41:38,988 --> 00:41:41,565
suggestions, all of them, but really,
543
00:41:41,565 --> 00:41:43,864
the best suggestion
I have to give you today is:
544
00:41:43,874 --> 00:41:46,373
Please!
Stop using fax!
545
00:41:46,604 --> 00:41:47,923
Laughter
546
00:41:47,923 --> 00:41:52,112
Applause
547
00:41:52,775 --> 00:41:53,916
Thank you, thank you!
548
00:41:53,916 --> 00:41:59,569
And, just one second before we finish,
this was a long way, a long journey.
549
00:41:59,569 --> 00:42:04,162
We had some very good friends that helped
us a lot along the way,
550
00:42:04,162 --> 00:42:06,022
physically, mentally, technically,
551
00:42:06,022 --> 00:42:10,795
so we must mention them.
These are the guys here. Some of them are
552
00:42:10,795 --> 00:42:13,837
in the crowd, so they deserve come claps.
553
00:42:13,998 --> 00:42:16,246
applause
554
00:42:16,246 --> 00:42:21,574
One special guy that helped us is
Yannay Livneh, he also deserves this, and…
555
00:42:21,574 --> 00:42:25,997
… that's it basically, guys!
So if you want to follow more of our work,
556
00:42:25,997 --> 00:42:30,386
you can find us here. Follow us.
Thank you very much!
557
00:42:30,386 --> 00:42:41,670
Applause
558
00:42:41,670 --> 00:42:45,097
Herald Angel: Thank you very much.
We have 5 minutes for Q&A.
559
00:42:45,097 --> 00:42:48,082
So please line up at the microphones.
If you want to leave now,
560
00:42:48,082 --> 00:42:52,710
please do it to your right side, so this
side. From the stage it's the left side,
561
00:42:52,710 --> 00:42:56,944
but for you it's the right side.
So please line up at the microphones.
562
00:42:56,944 --> 00:43:05,679
I think I can see microphone 4 already,
so we'll start with microphone 4.
563
00:43:06,780 --> 00:43:12,611
Question: First, thank you for this talk.
It's scary to see that these can be
564
00:43:12,611 --> 00:43:18,762
exploited today. You talked about
email-to-fax or fax-to-email services,
565
00:43:18,762 --> 00:43:26,371
and I wondered: Is it possible that there
are vulnerabilities in those as well?
566
00:43:26,371 --> 00:43:33,615
I know Fritz!Box routers allow
fax-to-email, could you attack those,
567
00:43:33,615 --> 00:43:34,561
possibly?
568
00:43:35,353 --> 00:43:39,995
Yaniv Balmas: So basically, those services
use T.30 as well. We didn't look at them,
569
00:43:39,995 --> 00:43:44,360
frankly. We had so much work to do with
the printer, that we didn't look at any
570
00:43:44,360 --> 00:43:50,793
other printers, or any other services.
I can't say for sure, but if you're
571
00:43:50,793 --> 00:43:54,481
looking for vulnerabilities, I would
recommend to go look there as well.
572
00:43:56,127 --> 00:43:58,194
Herald Angel: Great, microphone number 5
please.
573
00:43:59,395 --> 00:44:04,213
Question: What can you disclose about the
data that's hitting your URL?
574
00:44:05,425 --> 00:44:06,252
Yaniv Balmas: The…? Uh!
575
00:44:06,473 --> 00:44:10,188
Question: What can you disclose about the
machines that are knocking on your URL,
576
00:44:10,188 --> 00:44:12,652
the fakeurl1234.
577
00:44:13,056 --> 00:44:15,058
Yaniv Balmas: There are a lot of HP printers
out there.
578
00:44:15,058 --> 00:44:17,243
Laughter
579
00:44:17,461 --> 00:44:23,277
That's all I can disclose. Sorry.
580
00:44:25,842 --> 00:44:27,626
Herald Angel: We have one question from
the Signal Angel, please.
581
00:44:28,771 --> 00:44:33,295
Signal Angel: Did you try to activate JTAG
by upgrading to a modified firmware?
582
00:44:33,295 --> 00:44:38,677
Eyal Itkin: We tried to use the JTAG, we
think it's disabled from the factory
583
00:44:38,677 --> 00:44:45,014
lines, it was too much work. So we decided
to use Devil's Ivy, it's a good
584
00:44:45,014 --> 00:44:50,305
vulnerability. Once we have Devil's Ivy
and we can use Scout, Scout is more than
585
00:44:50,305 --> 00:44:51,412
enough for debugging.
586
00:44:52,503 --> 00:44:59,159
Essentially, after we used the JPEG
vulnerability and we loaded up Scout,
587
00:44:59,159 --> 00:45:03,143
Scout survived for weeks on a printer
without any crash.
588
00:45:03,693 --> 00:45:05,010
So that's more than enough.
589
00:45:06,735 --> 00:45:09,636
Herald Angel: Great, we'll go with
microphone number 2 please.
590
00:45:09,636 --> 00:45:13,490
Question: Yes, thank you for the nice
talk, and I think you're completely right
591
00:45:13,490 --> 00:45:19,048
you can have many problems with legacy
protocols, the only thing I do not really
592
00:45:19,048 --> 00:45:25,526
get was the part how you then can
automatically successfully attack your
593
00:45:25,526 --> 00:45:31,577
laptop on the network. My point would be:
My laptop is as secured as I'm going to
594
00:45:31,577 --> 00:45:35,768
the internet cafe or something else, so
you would not be able – with your HP
595
00:45:35,768 --> 00:45:40,228
printer – to start the calculator on my
Linux or even on my Windows.
596
00:45:41,502 --> 00:45:46,891
Yaniv Balmas: Your laptop might be secure,
I'm sure it is, but many others are not.
597
00:45:46,891 --> 00:45:52,440
We tried to show it using the EternalBlue
exploit, as you know, WannaCry, stuff like
598
00:45:52,440 --> 00:45:56,183
that. This thing created a lot of…
– and there were patches out there –
599
00:45:56,183 --> 00:46:01,840
…and still it was… So… we're not here to
attack anyone. We're just saying that
600
00:46:01,840 --> 00:46:05,186
theoretically, if somebody wants to get
into the network and he has a
601
00:46:05,186 --> 00:46:08,894
vulnerability that you have may have not
patched or secured, fax would be a bad
602
00:46:08,894 --> 00:46:10,134
idea to have.
603
00:46:10,834 --> 00:46:14,442
Question: But it was nothing which was
part of the printer…
604
00:46:14,442 --> 00:46:20,551
Herald Angel: Sorry, unfortunately we do
not have more time for Q&A, so thank you
605
00:46:20,551 --> 00:46:22,748
again very much.
606
00:46:22,994 --> 00:46:24,192
Yaniv Balmas: Thank you!
607
00:46:24,513 --> 00:46:32,694
Applause
608
00:46:32,694 --> 00:46:36,764
Music
609
00:46:36,764 --> 00:46:55,000
subtitles created by c3subtitles.de
in the year 2019. Join, and help us!