Jose Carlos Norte Personal Blog

It is possible to monitor and control float trucks, public bus or delivery vans from the internet, obtaining their speed, position, and a lot other parameters. You can even control some parameters of the vehicle or hack into the canbus of the vehicle remotely.

Those vehicles have a Telematics Gateway Unit (TGU) device and a 3g/4g/gprs/lte/edge/HDSPA modem to connect to the internet, with a public I.P. address.

There are thousands of TGU connected to the internet, with no authentication at all and with administrative interfaces through a web panel or a telnet session.

Finding publicly exposed TGUs in the internets

There are tons of open TGU and similar vehicle appliances on the internet. One very interesting and easy to find is the c4max.

The c4max smartbox is a TGU with powerful capabilities, a simple console on port 23, and is easy to identify while scaning the internet.

A quick search with shodan, reveals 733 open c4max devices on the internet, at the time of scanning. Because of the nature of these devices, connected to the internet using mobile data plans and in industrial vehicles, the devices you can find vary a lot from time to time.

Scanning the internet yourself with masscan finds different industrial vechicles working at different hours.

The c4max can be found looking for port 23, and the banner ‘gps’ or ‘welcome on console’ or similar strings from the telnet console they provide.

An example with shodan:

https://www.shodan.io/search?query=port%3A23+gps+%22on+console%22

What can be done inside a c4max TGU

The c4max devices that I found on the internet are not password protected, and there is no security that prevents anyone from connecting to them.

The telnet interface has 3 screns: basic, advanced, and commands.

The basic interface:

The advanced interface:

Commands:

Some interesting commands:

Basics[C4E]> iostate
Input 1 : Disconnected
Output 1 : Disconnected
Output 2 : Disconnected
Alarm : Disconnected
Ignition : Connected
Basics[C4E]>

Retriving gps coordinates of the vehicle (removed some info from the output, replaced by XXX…):

Basics[C4E]> gpspos
Internal antenna
GPRMC Frame value is
$GPRMC XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

GPGGA Frame value is
$GPGGA,XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Basics[C4E]>

And with the gps coordinates, we can locate the vehicle in google maps, for example:

List available modules:

Basics[C4E]> list
dbg
pdm
sql
wdg
boot
dhcpServer
sshTunnel
serialPPP
cpnManager
netMonitoring
boardsInfo
messageBrokerProxy
versionManager
messageBroker
config
dnsProxy
fileManager
dictionary
can
gps
ios
usb
bootReason
batt
leds
onewire
wifi
smartCardManager
j1587
j1708
j1850
j1939
kline
modem
nvram
usbHfk
chronoTachyGraph
sensors
dtc
jvm
obd
ibutton
dataEmitter
jbinaryGate
ledManager
network
adminProtocol
crashSensor
timeZoneManager
instantFixII
modemOperatorDriver
gpsOdometer
smartSensors
relayControl
driverBehavior
obdStacks
locales
fileSync
pwrManager
gpsMvtDetector
geoFencing
sensorsCalibration
updateManager
companionSoftwareClient
urlServer
gpsEcho
binaryGateMonitor
sensorsRecorder
messageGate
binaryGate
deadReckoning
speedDropControl
criticalCommandManager
cacheManager
update
acceleroMvtDetector
history
commandManager
dataRecorder
eeprom
Basics[C4E]>

The can bus module:

Basics[C4E]> list can

com::mdi::drivers::can.activateDebug=0
com::mdi::drivers::can.active_protocols=255
Basics[C4E]>

And with listdb, we can get a lot of information from the vehicle, the company that operates the vehicle, the driver etc, that I will not post here, for obvious reasons, but some of the information form listdb:

...
MDI_EXT_BATT_VOLTAGE='12687'
MDI_GPS_SPEED='0000090'
...

Modem information:

Basics[C4E]> modem
ppp0	XXXXXXXXXXX
APN: XXXXXXXXXXX
autoAPN: XXXXXXXXXXX
Your IMEI is : XXXXXXXXXXX
Your IMSI is : XXXXXXXXXXX
DNS servers are
nameserver XXXXXXXXXXX
nameserver XXXXXXXXXXX
In case of problem, check your configuration (with "list all" command)
Basics[C4E]>

We can even geofence the vehicle (I don’t know what it would cause):

com::mdi::services::geoFencing.periodInMs=5000
com::mdi::services::geoFencing.directory[0]=/mnt/user/writeDir/geofencing
com::mdi::services::geoFencing.directory[1]=/mnt/user/data/geofencing
com::mdi::services::geoFencing.directory[2]=/mnt/user/mmc/geofencing
com::mdi::services::geoFencing.areaModeSearch=0

Conclusion

Telematic Gateway Units exposed to the internet with public addresses and no authentication can be used to remotely track industrial vehicles, geofence them, change the mission route, if you read the schematics of these units:

http://www.neweagle.net/ProductDocumentation/Telematics/C4MAX_datasheet.pdf

You can see this device is connected to the bus of the vehicle, to the ignition, to the battery… and the theoretical things that could cause are very scary. Of course, not having one of these available and just testing in the wild is not responsible and of course I will not do it, so I still don’t know how far one can go with access to one of these devices. Caution is advised.

IMPORTANT NOTE: ALL THE INFORMATION CONTAINED IN THIS POST IS INTENDED FOR EDUCATIONAL AND RESEARCH PURPOSES ONLY. MANIPULATING REAL AUTOMOTIVE DEVICES FROM THE INTERNET IS NOT ETHICAL AND COULD BE ILLEGAL UNDER YOUR JURISDICTION. ANY VIEWS OR OPINIONS EXPRESSED IN THIS ARTICLE ARE ONLY MY OPINIONS AND NOT RELATED TO MY EMPLOYER OR ANY ORGANIZATION I BELONG TO. ALL THE INFORMATION PROVIDED IN THIS POST HAS BEEN COLLECTED USING PUBLICLY AVAILABLE RESOURCES, LIKE MANUFACTURER MANUALS AND SPECIALIZED SEARCH ENGINES. IN THE COURSE OF THIS FINDINGS, THE DEVICES DESCRIBED HERE NEVER HAD ANY KIND OF SECURITY IMPLEMENTED TO PREVENT CONNECTIONS TO THE DISCOVERED INTERFACES AND THEIR SECURITY WAS NEVER CIRCUMVENTED OR BYPASSED.

Tor Browser

The ability to privately communicate through the internet is very important for dissidents living under authoritary regimes, activists and basically everyone concerned about internet privacy.

While the TOR network itself provides a good level of privacy, making difficult or even practically impossible to discover the real I.P. address of the tor users, this is by no means enough to protect users privacy on the web. When browsing the web, your identity can be discovered using browser exploits, cookies, browser history, browser plugins, etc.

Tor browser is a firefox browser preconfigured and modified to protect user privacy and identity while browsing the web using TOR. Browser plugins are disabled, history and cache aren’t persistent and everything is erased after closing the browser, etc.

The user fingerprinting problem

While preventing users IP address to be disclosed is a key aspect for protecting their privacy, a lot of other things need to be taken into consideration. Tor browser is preconfigured to prevent a lot of possible attacks on user privacy, not only the communications layer provided by tor itself.

One common problem that tor browser tries to address is user fingerprinting. If a website is able to generate a unique fingerprint that identifies each user that enters the page, then it is possible to track the activity of this user in time, for example, correlate visits of the user during an entire year, knowing that its the same user.

Or even worse, it could be possible to identify the user if the fingerprint is the same in tor browser and in the normal browser used to browse internet. It is very important for the tor browser to prevent any attempt on fingerprinting the user.

In the past, a lot of fingerprinting methods has been used and proposed and tor browser has been updated with countermeasures. Examples of that are reading text sizes out of a canvas element, screen dimensions, local time, operating system information, etc.

One famous example of browser fingerprinting was Canvas fingerprinting. As of today, almost everything that can be used to identify the user has been disabled in tor browser.

UberCookie

During the last weeks I have been able to fingerprint tor browser users in controlled environments and I think it could be interesting to share all the findings for further discussion and to improve tor browser.

All the provided fingerprinting methods are based on javascript (enabled by default in tor browser as of today). I have created a quick and dirty PoC called UberCookie available as a demo here:

Try ubercookie

Measuring time

One interesting countermeasure for fingerprint implemented in tor browser is that javascript Date.getTime() (unix time) only updated each 100ms. So you can’t measure events happening under 100ms. This is useful to prevent a javascript inside a webpage to measure events in order to fingerprint the user. Since for some of the things I wanted to try needed better time accuracy than 100ms, this was the first thing to bypass.

There are a lot of ways to measure times smaller than 100ms using javascript in tor browser, some are obvious, or ther are intersting.

The first one I implemented was simply increment a variable by 1 each millisecond using setInterval. Even if the precision is not at milisecond level, is extremly better than the 100ms accuracy provided by Date.getTime.

Another way you can use to measure time is to create an animation in CSS3, configured at 1ms interval and listen to the animationiteration event.

However, the better accuracy I could achieve was using setInterval incrementing inside a webworker.

Mouse wheel fingerprinting

The mouse wheel event in Tor Browser (and most browsers) leaks information of the underlying hardware used to scroll the webpage. The event provides information about the delta scrolled, however if you are using a normal computer mouse with a mouse wheel, the delta is always three, but if you are using a trackpad, the deltas are variable and related to your trackpad and your usage patterns.

Another leak in the mouse wheel, is the scroll speed that is linked to the configuration of the operating system and the hardware capabilities itself.

I have created a little experiment as a proof of concept, available here:

Mouse wheel information leak demo

This demo creates three graphs, one with the scrolling speed, another with the scrolling delta, and another one with the number of times the user scrolled in the red box.

Mouse Speed fingerprinting

Another interesting fingerprint that could reveal some entropy is the speed of the mouse moving acrross the webpage. Since the speed of the mouse is controlled by the operating system and related to hardware, and can be read using javascript if you can measure time using the mentioned strategies.

It could be interesting also to measure average mouse speed while the user is in the page moving the mouse.

CPU Benchmark fingerprinting

With the improved accuracy on time provided by the setInterval inside the WebWorker, it is easy to create a CPU intensive script (or even memory intensive) and measure how long it takes for the user browser to execute it.

I have done some tests with different computers, getting completely different results, all of them using the same tor browser version.

getClientRects fingerprinting

The most intersting fingerprinting vector I found on Tor Browser is getClientRects. Is strange that reading back from a canvas has been prevented but simply asking the browser javascript API how a specific DOM elements has been drawn on the screen has not been prevented or protected in any way.

getClientRects allows to get the exact pixel position and size of the box of a given DOM element. Depending on the resolution, font configuration and lots of other factors, the results of getClientRects are different, allowing for a very quick and easy fingerprinting vector, even better than the canvas fingerprinting that is fixed.

Example of getClientRects on the same page with same Tor Browser version on different computers:

Computer 1:

Computer 2:

As you can see, there is a lof of difference in the results of getClientRects between two computers using the same tor browser on the same page and on the same DOM Element.

Results

An example of running ubercookie PoC in one computer (computer 1):

Client rects: {"x":131.5,"y":462,"width":724,"height":19,"top":462,"right":855.5,"bottom":481,"left":131.5}

scrolling milis: [2,2,0,3,0,1,0,2,3,0,0,3,1,2,2,1,2,1,4,4,35,2,1,3,0,1,0,3,0,1,0,3,0,1,0,3,1,0,3,1,3,0,1,3,2,4,4,8,44,4,1,4,4,405,2,3,2,1,3,1,3,57,2,0,2,2,0,2,2,4,60,2,0,2,2,0,2,2,6,54,2,2,2,0,2,1,4,8]

scrolling deltas: [3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]

Biggest mouse step: 65

In a few seconds, the result of the CPU benchmark will appear, please wait...

CPU Mean: 3245

And the result of running it in a different computer (computer 2), same Tor browser version:

Client rects: {"x":159.51666259765625,"y":465.25,"width":664.6500244140625,"height":18.449996948242188,"top":465.25,"right":824.1666870117188,"bottom":483.6999969482422,"left":159.51666259765625}

scrolling milis: [0,3,0,2,2,2,2,0,3,0,2,1,2,2,1,3,1,1,4,1,2,1,1,3,1,2,2,3,2,5,3,3,5,3,0,0,2,0,2,0,1,1,0,2,0,3,2,1,1,3,1,3,2,3,1,3,2,2,2,2,0,2,3,2,2,2,244,0,2,1,2,1,3,2,0,2,0,1,2,1,0,2,0,3,1,0,2,1,1,1,2,1,1,1,1,1,1,2,2,1,2,2,2,2,1,4,2,2,2,2,2,4,2]

scrolling deltas: [3,0.975,1.65,1.5,1.725,2.25,2.775,2.4,3.15,3.375,3.975,3.675,4.35,4.95,5.625,5.55,5.25,5.25,4.2,6.3,9.975,13.95,7.575,6.9,2.85,5.925,8.85,0.9,4.425,3.675,4.725,2.625,2.4,5.475,2.625,3.675,5.4,5.775,7.275,6.975,8.175,9,8.475,3.45,2.475,2.25,0.6,1.8,11.1,8.4,8.475,8.1,7.5,6.375,8.175,4.95,4.8,4.275,3.525,3.375,1.125,2.7,2.175,1.95,1.65,1.2,1.05,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]

Biggest mouse step: 40

In a few seconds, the result of the CPU benchmark will appear, please wait...

CPU Mean: 4660.5

It is evident that the getClientRects are completly different, providing an interesting fingerprinting vector. The scrolling speed (milis) is also different. The scrolling deltas are very different, because of hardware differences. The mouse of computer 1 is faster, as you can see in ‘biggest mouse step’. The CPU benchmark provides different results, computer 1 being faster than computer 2.

Conclusion

It is easy to fingerprint users using tor browser to track their activity online and correlate their visits to different pages. getClientrects provides a very interesting vector for fingerprinting TOR Browser users. The CPU benchmark and the Mouse wheel and mouse speed methods provide even more information to distinguish between similar users.

Hidden Services in TOR

Tor is a service run by a network of volunteers to allow people to use internet anonymously. Normally tor is used to browse the web without being tracked or identified.

One less known feature of the tor service is the ability to provide what is known in tor as hidden services. Hidden services are basically servers that provide services through the tor network. When you think about tor the first thing you think of is anonymous web browsing. However, for hacktivists and dissidents it is very useful not only to be able to browse the web without being identified, but also providing web pages for people in a way that such webpages can not be tracked or shutdown easily.

In the tor network there are thousands of ‘hidden services’ accessible only for people using the tor network, providing access to forbidden information about very different topics. Those sites have a hidden DNS address with the .onion tld, for example example.onion. Sites ending in .onion can not be easily tracked or shutdown, and the owner can not be easily identified.

One of the most complex things about setting up a hidden service, is configuring the web server in a way that doesn’t leak information about the real IP address of the server, or the country location etc. The more complex the site, the more difficult it becomes to setup a real hidden service that doesn’t leak service information in any way.

During the last years, the F.B.I. has been able to identify and shutdown certain hidden services, using social engineering, information leaks and browser vulnerabilities. The most famous example is The Silk Road, a well known black market hidden inside tor, used for selling drugs and similar stuff.

Of course, the administrators behind hidden services try its best to not leak any information about the physical location of the server providing the service, or any other information that could lead to the identification of the owner of the hidden service.

Leaking the timezone

The HTTP protocol allows the client to inform the server about its compression capabilities. If the client and server share support for a specific compression format, the server can decide to compress the http response in order to save bandwidth and time. All major web servers and browsers support compression. The most common formats used for HTTP compression are gzip and deflate.

Gzip is a compression format that allows relative fast data compression with decent compression ratios.

As a compression format, gzip specifies a data header to be included in the resulting compressed data, this header includes information about the compressed data, the operating system that compressed the data, and most importantly: the date when the data was compressed, in theory in universal time (UTC).

The header is as follows, as you can see in Foreniscs Wiki:

Offset	Size	Value	Description
0	2	0x1f 0x8b	Magic number to idenitfy gzip streams
2	1		Compression method
3	1		Flags
4	4		Compression Date
8	1		Compression flags
9	1		Operating system

So, if this header is present in any gzip compressed data, we can make a gzip compressed request to any webserver, wait for the gzip compressed response, check if the bytes starts with 0x1f 0x8b, and check for the compression date to know the exact date configured at the server that serves the page.

With normal webservers, this is only useful in a very limited scenarios, because the geopraphical position of the server is not hidden in any way, and can be known easily knowing the server IP address, that is not hidden at all. However, in a Hidden Service, the information about the server timezone can be very useful to identify the possible countries where the server is running.

The GZIP specification clearly states that universal time should be used instead of local time for the MTIME header field. However, I have found lots of sites sending local times instead of universal times. It seems that maybe the flaw is in Microsoft Windows, but further investigation is needed to clarify which implementations are not following the specification and are leaking the local time.

This, of course, its NOT a TOR fault and its not a bug in the tor protocol and IS NOT a problem with the GZIP spec, but with certain implementations. Its just a obscure feature of the gzip format that has ben wrongly implemented by some vendors, and made available in the HTTP Protocol by default in most web servers.

The good news is that lots of webservers are preconfigured to fill the date field of the gzip header with ‘0’s, maybe because of performance issues, who knows. After some research, I found that around 10% of the webservers leak the remote date when compressing HTTP Responses with gzip, and only some of the servers that includes the remote date in the headers fails to use UTC instead of local time.

Clock Skew identification

Even the implementations that are sending the universal time instead of the local time, in other words, even the correct implementations that are not filling the MTIME with zeros, but sending the correct universal time are prone to identification through clock skew attacks as you can read in the previous work by Murdoch, 2006

However, in this scenario the universal time provided in correct gzip implementations is just another side channel to mount the attack

Proof Of Concept

I have developed a little php script that uses curl (command line) to get the remote server date if available in the gzip compressed HTTP Response. It will only work in web server that allows for compression of HTTP Responses, and fills the ‘date’ field of the gzip header with the correct date instead of zeroes.

I have tested it with some servers, an example of servers where a date is sent in the gzip header are instagram.com, reddit.com and bing.com. In this example reddit.com and instagram.com are sending universal times, as the specification states. bing.com is sending local times.

Of course, because of privacy concerns, I’m not going to provide information on which hidden services are leaking the remote date.

Examples of use:

user@localhost:~$ php time.php bing.com
The server that processed the request on: bing.com has local date set to:
Sunday 21st of February 2016 01:21:21 PM

user@localhost:~$ php time.php reddit.com
The server that processed the request on: reddit.com has local date set to:
Sunday 21st of February 2016 09:21:25 PM

user@localhost:~$ php time.php instagram.com
The server that processed the request on: instagram.com has local date set to:
Sunday 21st of February 2016 09:21:30 PM

user@localhost:~$

In this example all three servers are including times in the gzip headers, but reddit.com and instagram.com are providing universal times, while bing.com is providing local times.

The Proof of concept is available here:

https://github.com/jcarlosn/gzip-http-time

GZIP in tor itself

the TOR protocol itself uses gzip for some of its communications, however this issue was already known and taken into account when developing tor, as stated by Tim Wilson-Brown in the tor-onions mailing list.

TOR itself does not suffer from this issue, even though it uses gzip compression internally to compress directory documents. Hidden services and clients do not produce or recompress directory documents, so they could never be affected. And tor authorities use deflateInit2 to initialise compression for votes and consensuses, which zeroes the gzip header. From the deflateInit2 documentation in zlib.h:

    "windowBits can also be greater than 15 for optional gzip encoding.  Add
   16 to windowBits to write a simple gzip header and trailer around the
   compressed data instead of a zlib wrapper.  The gzip header will have no
   file name, no extra data, no comment, no modification time (set to zero), no
   header crc, and the operating system will be set to 255 (unknown).  If a
   gzip stream is being written, strm->adler is a crc32 instead of an adler32."

You can see the entire conversation about this in the tor-onions mailing lists

Thanks

From the moment I found this potential issue I was affraid that this could be affecting the privacy of tor users even in remote ways. It has been a bit complicated to understand why this was happening and why while the gzip specification clearly states that the time should be universal, some servers where sending local times instead. Even with the confusion of early sharing this findings I believe that has been more constructive to openly discuss this potential issue than to keep it secret while I try to understand better the impact. I believe that the most reponsible thing was to contact the onion tor mailing list, like I did, and to diffuse this article to raise concerns and get help understanding if this could be an issue.

Thanks to HDM, brlewis and Henryk Plotz for joining the discussion and providing aditional information regarding the issue and helping clarify the potential impact it could have.

Last updated at: 2/22/2016 8:50:16 PM UTC. Corrected some mistakes and added more information provided in the comments