- Hello, everyone.
Thank you for attending the talk.
I'm Slava.
I've been doing security research
at Check Point for many years.
Reverse engineering and vulnerability research
is my daily work.
Today, I want to share my experience
of hacking Amazon Kindle E-reader devices
using a crafted eBook.
Personally, I use Kindle a lot,
but I've never heard about a malicious book.
It was a reason for me to research
how to create such book that could be used to root remotely
and take full control of a Kindle device.
Amazon has announced that since 2007,
they have sold tens of millions of Kindle devices.
It's impressive.
I tried to find some statistics about that and yes,
the Amazon Kindle is most widely owned e-reading device
in the USA.
There were 10 generations of Kindle readers on the market
and almost all of them, are still supported.
Typically users connect their Kindle devices
to a WiFi network, and WiFi protocols
there can be used as entry point to attack the Kindle,
but using an eBook to reach device is much easier
and mass attacks are possible.
What ways does Amazon offer to send a book to a Kindle?
If we are talking about your own device,
you can log into your Amazon account
and use a prepared chrome extension,
PC, or android applications,
or just use a USB cable to transfer the file.
Another way is to use a "send to Kindle by email"
Amazon service,
to send the book as an email attachment.
In this case,
you should know the unique email address
of the targeted Kindle device,
including six random characters.
So it's difficult to brute force.
In addition, the ability to spoof.
It was fixed by Amazon a year ago
and now the recipient needs to confirm the transfer,
if it was sent from an approved email address.
Or they both suggest that a phishing campaign
is only way for the attacker to reach your Kindle.
Dozens of free online libraries are open
to upload and download eBooks.
An attacker can easily upload a malicious book
for free access because no one expects to see malware
targeting the Kindle.
Most libraries only care about the correctness
of the metadata or the uploaded the book.
So when downloading an eBook from an online library,
you can never be sure of its content.
Okay.
Now let's deal with the Kindle device itself.
The latest version of the Kindle E-reader firmware
is publicly available on the official Amazon website.
The source code is also partially available there,
but there is no source code for components
responsible for parsing and rendering books.
In addition, I jail broke one of my Kindles.
It's clear that the research will go faster,
if you can see running processes
and can debug Kindle services.
The most general way to jail break you through
the serial port.
I took the photo.
Let's take a quick look at the Kindle architecture.
And basically the Kindle OS is the Linux kernel
with a set of Native programs,
mainly provided by BusyBox.
The LIPC subsystem for interprocess communication
and the Java and WebKit subsystem
for user interface and services.
The LIPC is a D-Bus based IPC library and it's environment
that links all Kindle components together.
A Kindle process can use this library to start apps,
expose application, same thing.
So listen for, or you may advance.
For example,
a WebKit application can use the LIPC
to interact with a Java service or a Native application.
Most of the UI is written in Java,
and the Java subsystem,
is a framework, implements LIPC handlers
for providing services and for providing a user interface,
so-called Booklets.
The WebKit subsystem, I mean HTML 5 and JavaScript,
is another way to create UI elements.
The built-in experimental browser is a part
of the WebKit subsystem.
The Pillow is a library that allows
access to the LIPC from JavaScript.
Good.
Who parses eBooks?
You put a new book on your Kindle device,
who is going to handle the file first?
This kind of service periodically scans
the documents directory for new files
and depending on the file extension
uses one of the extractor libraries
to extract metadata from the eBook.
All extractors are listed in the app registry database
and there is a handler for each
of the supported Kindle eBook formats.
If the scanner does not match file extension
or a parsing error occurs,
the book will not be shown to the user.
I did not go deep into the scanning process
because extracting metadata
is too simple in operation to suggest parsing errors.
All that matters to me is that the malware book
must have the correct metadata.
After the scanner does a job,
a thumbnail of the new book is displayed on the home screen,
and from this moment on, the Java framework
is responsible for opening the book when you click on it.
Java archive files that implement the logic
for opening and rendering eBooks
can be found in the /opt/amazon/ebook/lib directory.
Primarily these are .jars listed on the slide.
In this resource, I decided to focus my attention
on the PDF file format as it's one of the most common
and yet at the same time complex formats.
On this slide, you can see the function
to open PDF books implemented in the PDF reader, impl.jars.
It's only wrapper over the nativeOpenPDFDocument function
with the body in linPDFClientJNI.so.
The linPDFClientJNI.so lib starts as a PDF Reader service,
forking the process,
and synchronously send it an open book message
via the open source HTTP client server
library lib (indistinct).
In fact, it sends a get request
to a specific local host URL.
The PDF reader service defines those in soft sub handlers
for the higher level PDF operations,
including open book and start rendering,
ones we are interested in.
The libFoxitWrapper.so, written by Amazon,
provides an API for working views PDF files.
I want to know the only three significant functions
on the libFoxitWrapper.so library.
These functions are good entry points
for finding a PDF to restructure,
but I was lucky to find only a lot of another references.
As the name implies libFoxitWrapper.so,
is a wrapper over the popular Foxit PDF SDK,
presented on Kindle devices by libfpdfemb.so.
This is a closed source library,
proprietary to Foxit Software Incorporated.
Next, I decided to focus my attention on PDF stream filters
and I tried to fuzz the Foxit SDK library.
This is the fuzzing model I used.
It's pretty classic.
I used a combination of American fuzzing loop
and quick emulator, QEMU.
The host machine is Ubuntu.
A simple search for the words
cPDF and codec in the Foxit Library
allowed me to find all the possible stream filters.
Let's take a look at one of them as an example.
As you can see an image in one of these Jbig2 filter
is declared, and
Jbig2 is an image compression standard for B-level images.
The Jbig2 segments,
the input page into the regions: texts, halftone image,
refinement, and others.
This regions are held in the JBIG2Globals stream.
When rendering a PDF page,
the library parses the JBIG2Globals stream
and reconstructs the image.
The Jbig2Module object
defined in the Foxit library
is responsible for decoding Jbig2 compressed images.
It's StartDecode method is declared as shown on the slide.
I used the StartDecode function
as the fuzzing entry point and permuted the image size,
the image stream and the JBIG2Globals stream.
As a result, available vulnerability in the Jbig2,
the coding algorithm was found.
Let's take a look at the full JBIG2Globals stream.
Two page regions are defined here,
the image information region and the refinement region.
The refinement region contains the information
needed to refine the image including coordinates
of the refining rectangle.
In our case, an oversized rectangle is defined.
What's happens in this case?
The Jbig2 algorithm tries to expand the base image
to new dimensions.
The height of the new image is recalculated
as old height plus y
and old high plus y multiplied by the stride.
Heap memory is located for the resized image,
but there is a mistake in the expanding function
and missed check for int marks.
The 32-bit register overflows and 100 bytes
is located for the image instead of 40000100 bytes.
By using refinement regions,
we can refine the data outside of the image
and get the arbitrary bright primitive,
In the following example,
the second refinement region over various 16 bytes,
at the offset 12340 bytes from the beginning of the image
in the heap.
The indicated data envelope
will be decompressed by the Jbig2 algorithm
and then sorted with the heap content.
We can create any number of refinement regions
and over right parts of memory
that are at distance from each other.
In addition,
the factor that the writing is done through XOR operation
allows us to fix on specific bits of memory,
and bypass ASLR protection, if required.
As I mentioned,
the Foxit library is part of the PDF reader process.
The data and heap segments of this process
are Read/Write/Execute.
ASLR is built into the Linux kernel
and is controlled by the parameter proxy's kernel
randomize via space.
It's default value on Kindle devices is one,
which means the base address of the data segment
is located immediately after the end
of the executable code segment.
In other words, there is no randomization
for data segment in the heap.
These two facts make exploiting the vulnerability trivial.
At start-up, the PDF reader service lowers itself
to the permission of the framework user.
To prove permissions of our payload,
I create the following simple bash file in the framework
working directory and launch it.
There uid=9,000 of the framework user or sprint it.
Well, now we have remote code execution vulnerability
in the context of the PDF reader process,
which operates with the framework user rights.
We can send LIPC messages, access special internal files,
but we are still limited.
We want to be a root to reset all restrictions.
So the second stage of the research
was to find a local privilege escalation vulnerability
that allows the framework user
to run a quarter under the root use.
The framework user has read/write access
to the app registry database.
It means that we can fix a database entry
using the LIPC (indistinct) library
or by simply editing the file.
We need to page one of the command entries
in the property stream.
For example, I paged to the browser earlier at entry.
I set in the value field to the path
to the payload script created using the first
PDF vulnerability.
Next, the framework user can request the app manager,
represented by the appmgrd service,
to start an arbitrary application.
We can send a LIPC message to open the browser,
using the lib/lipc.so library.
The presented shell command to will do the same.
The app manager is responsible for launching built-in apps.
To do this, it listens for the appropriate LIPC events
and to start the browser app,
it reads the relevant entry from the application registry
and executes as a command specified in the the value field.
As we paged this database entry,
our payload.sh script will be launched.
The app manager service has root rights
and they, uid=0 will be printed by the payload script.
So by combining these two discovered vulnerabilities,
any malicious payload can be run as root.
Now let's take
a look at a small demo
in which I use a reverse shell
to remotely control a Kindle device.
On the left you can see a Kindle device,
the book called a_Book is our malicious file.
On the right, you can see the Metasploit server
that I opened on Google cloud.
The user clicked on the book and at that point,
the payload hidden in their book
connects to their remote server providing the reverse shell,
and then locks the user screen with a window.
As you can see, we gain the root permissions
so we can do whatever we want.
For example, we can steal Amazon account cookies
and we can take a look at device private keys.
Here we go.
To summarize,
I demonstrated how an eBook can be malware.
As the malware code is executed with root user rights,
just opening such a book can lead to irreparable damage.
That attacker can delete or sell your eBooks
taking money for themselves,
can brick your Kindle or convert to a bot,
attack other devices in your local network,
and more.
The discovered vulnerabilities
were reported to Amazon in February 2021,
and now both are fixed.
Thank you for your attention.
You can find many good security researchers
on the Check Point research book.