Antoine Beaupr : Internet in Cuba
A lot has been written about the Internet in Cuba over the years. I
have read a few articles, from
New York Times' happy support for Google's invasion of Cuba to
RSF's dramatic and fairly outdated report about censorship in Cuba. Having
written before about
Internet censorship in Tunisia, I was curious to
see if I could get a feel of what it is like over there, now that a
new Castro is in power and the
Obama administration has started restoring diplomatic ties with Cuba. With
those political changes coming signifying the end of an embargo that
has been called genocidal by the Cuban government, it is surprisingly
difficult to get fresh information about the current state of affairs.
This article aims to fill that gap in clarifying how the internet
works in Cuba, what kind of censorship mechanisms are in place and how
to work around them. It also digs more technically into the network
architecture and performance. It is published in the hope of providing
both Cubans and the rest of the world with a better understanding of
their network and, if possible, Cubans ways to access the internet
more cheaply or without censorship.
"Censorship" and workarounds
Unfortunately, I have been connected to the internet only through the
the Varadero airport and the WiFi of a "full included" resort near
Jibacoa. I have to come to assume that this network is likely to be
on a segregated, uncensored internet while the rest of the country
suffers the wrath of the Internet censorship in Cuba I
have seen documented elsewhere.
Through my research, I couldn't find any sort of direct
censorship. The Netalyzr tool
couldn't find anything significantly wrong with the connection,
other than the obvious performance problems related both to the
overloaded uplinks of the Cuban internet. I ran an incomplete
OONI probe as well, and it seems there was no obvious censorship
detected there as well, at least according to folks in the helpful
"Censorship" and workarounds
Unfortunately, I have been connected to the internet only through the
the Varadero airport and the WiFi of a "full included" resort near
Jibacoa. I have to come to assume that this network is likely to be
on a segregated, uncensored internet while the rest of the country
suffers the wrath of the Internet censorship in Cuba I
have seen documented elsewhere.
Through my research, I couldn't find any sort of direct
censorship. The Netalyzr tool
couldn't find anything significantly wrong with the connection,
other than the obvious performance problems related both to the
overloaded uplinks of the Cuban internet. I ran an incomplete
OONI probe as well, and it seems there was no obvious censorship
detected there as well, at least according to folks in the helpful
#ooni
IRC channel. Tor also works fine, and could be a great way
to avoid the global surveillance system described later in this
article.
Nevertheless, it still remains to be seen how the internet is censored
in the "real" Cuban internet, outside of the tourist designated
areas - hopefully future visitors or locals can expand on this using
the tools mentioned above, using the regular internet.
Usual care should be taken when using any workaround tools, mentioned
in this post or not, as different regimes over the world have accused,
detained, tortured and killed sometimes for the mere fact of using or
distributing circumvention tools. For example, a Russian developer
was arrested and detained in 2001 by United States' FBI for
exposing vulnerabilities in the Adobe e-books copy protection
mechanisms. Similarly, people distributing Tor and other tools have
been arrested during the period prior to the revolution in Tunisia.
The Cuban captive portal
There is, however, a more pernicious and yet very obvious censorship
mechanism at work in Cuba: to get access to the internet, you have to
go through what seems to be a state-wide captive portal, which I have
seen both at the hotel and the airport. It is presumably deployed at
all levels of the internet access points.
To get credentials through that portal, you need a username and
password which you get by buying a Nauta card. Those cards cost
2$CUC and get you an hour of basically unlimited internet
access. That may not seem like a lot for a rich northern hotel
party-goer, but for Cubans, it's a lot of money, given that the average
monthly salary is around 20$CUC. The system is also pretty annoying to
use, because it means you do not get continuous network access: every
hour, you need to input a new card, which will obviously make
streaming movies and other online activities annoying. It also makes
hosting servers basically impossible.
So while Cuba does not have, like China or Iran, a
"great firewall", there is definitely a big restriction to going
online in Cuba. Indeed, it seems to be how the government ensures that
Cubans do not foment too much dissent online: keep the internet slow
and inaccessible, and you won't get too many Arab spring / blogger
revolutions.
Bypassing the Cuban captive portal
The good news is that it is perfectly possible for Cubans (or at least
for a tourist like me with resources outside of the country) to bypass
the captive portal. Like many poorly implemented portals, the portal
allows DNS traffic to go through, which makes it possible to access
the global network for free by using a tool like iodine which
tunnels IP traffic over DNS requests.
Of course, the bandwidth and reliability of the connection you get
through such a portal is pretty bad. I have regularly seen 80% packet
loss and over two minutes of latency:
--- 10.0.0.1 ping statistics ---
163 packets transmitted, 31 received, 80% packet loss, time 162391ms
rtt min/avg/max/mdev = 133.700/2669.535/64188.027/11257.336 ms, pipe 65
Still, it allowed me to login to my home server through SSH using
Mosh to workaround the reliability issues.
Every once in a while, mosh would get stuck and keep on trying to send
packets to probe the server, which would clog the connection even
more. So I regularly had to restart the whole stack using these
commands:
killall iodine # stop DNS tunnel
nmcli n off # turn off wifi to change MAC address
macchanger -A wlan0 # change MAC address
nmcli n on # turn wifi back on
sleep 3 # wait for wifi to settle
iodine-client-start # restart DNS tunnel
The Koumbit Wiki has good instructions on
how to setup a DNS tunnel. I am wondering if such a public service
could be of use for Cubans, although I am not sure how it could be
deployed only for Cubans, and what kind of traffic it could
support... The fact is that iodine does require a server to
operate, and that server must be run on the outside of the censored
perimeter, something that Cubans may not be able to afford in the
first place.
Another possible way to save money with the captive portal would be to
write something that automates connecting and disconnecting from the
portal. You would feed that program a list of credentials and it would
connect to the portal only on demand, and disconnect as soon as no
traffic goes through. There are details on the implementation of the
captive portal below that may help future endeavours in that field.
Private information revealed to the captive portal
It should be mentioned, however, that the captive portal has a
significant amount of information on clients, which is a direct threat
to the online privacy of Cuban internet users. Of course the unique
identifiers issued with the Nauta cards can be correlated with your
identity, right from the start. For example, I had to give my room
number to get a Nauta card issued.
Then the central portal also knows which access point you are
connected to. For example, the central portal I was connected to
Wifi_Memories_Jibacoa
which, for anyone that cares to research, will
give them a location of about 20 square meters where I was located
when connected (there is only one access point in the whole hotel).
Finally, the central portal also knows my MAC address,
a unique identifier for the computer I am using which also reveals
which brand of computer I am using (Mac, Lenovo, etc). While this
address can be changed, very few people know that, let alone how.
This led me to question whether I would be allowed back in Cuba (or
even allowed out!) after publishing this blog post, as it is obvious
that I can be easily identified based on the time this article was
published, my name and other details. Hopefully the Cuban government
will either not notice or not care, but this can be a tricky
situation, obviously. I have heard that Cuban prisons are not the best
hangout place in Cuba, to say the least...
Network configuration assessment
This section is more technical and delves more deeply in the Cuban
internet to analyze the quality and topology of the network, along
with hints as to which hardware and providers are being used to
support the Cuban government.
Line quality
The internet is actually not so bad in the hotel. Again, this may be
because of the very fact that I am in that hotel, and I get a
privileged access to the new fiber line to Venezuela, the
ALBA-1 link.
The line speed I get is around 1mbps, according to speedtest,
which selected a server from LIME in George Town, Cayman Islands:
[1034]anarcat@angela:cuba$ speedtest
Retrieving speedtest.net configuration...
Retrieving speedtest.net server list...
Testing from Empresa de Telecomunicaciones de Cuba (152.206.92.146)...
Selecting best server based on latency...
Hosted by LIME (George Town) [391.78 km]: 317.546 ms
Testing download speed........................................
Download: 1.01 Mbits/s
Testing upload speed..................................................
Upload: 1.00 Mbits/s
Latency to the rest of the world is of couse slow:
--- koumbit.org ping statistics ---
122 packets transmitted, 120 received, 1,64% packet loss, time 18731,6ms
rtt min/avg/max/sdev = 127,457/156,097/725,211/94,688 ms
--- google.com ping statistics ---
122 packets transmitted, 121 received, 0,82% packet loss, time 19371,4ms
rtt min/avg/max/sdev = 132,517/160,095/724,971/93,273 ms
--- redcta.org.ar ping statistics ---
122 packets transmitted, 120 received, 1,64% packet loss, time 40748,6ms
rtt min/avg/max/sdev = 303,035/339,572/965,092/97,503 ms
--- ccc.de ping statistics ---
122 packets transmitted, 72 received, 40,98% packet loss, time 19560,2ms
rtt min/avg/max/sdev = 244,266/271,670/594,104/61,933 ms
Interestingly, Koumbit is actually the closest host in the above
test. It could be that Canadian hosts are less affected by bandwidth
problems compared to US hosts because of the embargo.
Network topology
The various traceroutes show a fairly odd network topology, but
that is typical of what I would described as "colonized internet
users", which have layers and layers of NAT and obscure routing that
keep them from the real internet. Just like large corporations are
implementing NAT in a large scale, Cuba seems to have layers and
layers of private RFC 1918 IPv4 space. A typical traceroute
starts with:
traceroute to koumbit.net (199.58.80.33), 30 hops max, 60 byte packets
1 10.156.41.1 (10.156.41.1) 9.724 ms 9.472 ms 9.405 ms
2 192.168.134.137 (192.168.134.137) 16.089 ms 15.612 ms 15.509 ms
3 172.31.252.113 (172.31.252.113) 15.350 ms 15.805 ms 15.358 ms
4 pos6-0-0-agu-cr-1.mpls.enet.cu (172.31.253.197) 15.286 ms 14.832 ms 14.405 ms
5 172.31.252.29 (172.31.252.29) 13.734 ms 13.685 ms 14.485 ms
6 200.0.16.130 (200.0.16.130) 14.428 ms 11.393 ms 10.977 ms
7 200.0.16.74 (200.0.16.74) 10.738 ms 10.019 ms 10.326 ms
8 ix-11-3-1-0.tcore1.TNK-Toronto.as6453.net (64.86.33.45) 108.577 ms 108.449 ms
Let's take this apart line by line:
1 10.156.41.1 (10.156.41.1) 9.724 ms 9.472 ms 9.405 ms
This is my local gateway, probably the hotel's wifi router.
2 192.168.134.137 (192.168.134.137) 16.089 ms 15.612 ms 15.509 ms
This is likely not very far from the local gateway, probably still in
Cuba. It in one bit away from the captive portal IP address (see
below) so it is very likely related to the captive portal implementation.
3 172.31.252.113 (172.31.252.113) 15.350 ms 15.805 ms 15.358 ms
4 pos6-0-0-agu-cr-1.mpls.enet.cu (172.31.253.197) 15.286 ms 14.832 ms 14.405 ms
5 172.31.252.29 (172.31.252.29) 13.734 ms 13.685 ms 14.485 ms
All those are withing RFC 1918 space. Interestingly, the Cuban
DNS servers resolve one of those private IPs as within Cuban
space, on line #4. That line is interesting because it reveals the
potential use of MPLS.
6 200.0.16.130 (200.0.16.130) 14.428 ms 11.393 ms 10.977 ms
7 200.0.16.74 (200.0.16.74) 10.738 ms 10.019 ms 10.326 ms
Those two lines are the only ones that actually reveal that the route
belongs in Cuba at all. Both IPs are in a tiny (/24
, or 256 IP
addresses) network allocated to ETECSA, the state telco
in Cuba:
inetnum: 200.0.16/24
status: allocated
aut-num: N/A
owner: EMPRESA DE TELECOMUNICACIONES DE CUBA S.A. (IXP CUBA)
ownerid: CU-CUBA-LACNIC
responsible: Rafael L pez Guerra
address: Ave. Independencia y 19 Mayo, s/n,
address: 10600 - La Habana - CH
country: CU
phone: +53 7 574242 []
owner-c: JOQ
tech-c: JOQ
abuse-c: JEM52
inetrev: 200.0.16/24
nserver: NS1.NAP.ETECSA.NET
nsstat: 20160123 AA
nslastaa: 20160123
nserver: NS2.NAP.ETECSA.NET
nsstat: 20160123 AA
nslastaa: 20160123
created: 20030512
changed: 20140610
Then the last hop:
8 ix-11-3-1-0.tcore1.TNK-Toronto.as6453.net (64.86.33.45) 108.577 ms 108.449 ms 108.257 ms
...interestingly, lands directly in Toronto, in this case going later
to Koumbit but that is the first hop that varies according to the
destination, hops 1-7 being a common trunk to all external
communications. It's also interesting that this shoves a good 90
milliseconds extra in latency, showing that a significant distance and
number of equipment crossed. Yet a single hop is crossed, not showing
the intermediate step of the Venezuelan link or any other links for
that matter. Something obscure is going on there...
Also interesting to note is the traceroute to the redirection host,
which is only one hop away:
traceroute to 192.168.134.138 (192.168.134.138), 30 hops max, 60 byte packets
1 192.168.134.138 (192.168.134.138) 6.027 ms 5.698 ms 5.596 ms
Even though it is not the gateway:
$ ip route
default via 10.156.41.1 dev wlan0 proto static metric 1024
10.156.41.0/24 dev wlan0 proto kernel scope link src 10.156.41.4
169.254.0.0/16 dev wlan0 scope link metric 1000
This means a very close coordination between the different access
points and the captive portal system. Finally, note that there seems
to be only three peers to the Cuban internet:
Teleglobe, formerly Canadian, now owned by the Indian
[[!wiki Tata group]], and Telef nica, the Spanish Telco
that colonized most of Latin America's internet, all the way down to
Argentina. This is confirmed by my traceroutes, which show traffic to
Koumbit going through Tata and Google's going through Telef nica.
Captive portal implementation
The captive portal is https://www.portal-wifi-temas.nauta.cu/ (not
accessible outside of Cuba) and uses a
self-signed certificate. The domain name resolves to
190.6.81.230
in the hotel.
Accessing http://1.1.1.1/ gives you a status page which allows you
to disconnect from the portal. It actually redirects you to
https://192.168.134.138/logout.user. That is also a
self-signed, but different certificate. That
certificate actually reveals the implication of Gemtek which is a
"world-leading provider of Wireless Broadband solutions, offering a
wide range of solutions from residential to business". It is somewhat
unclear if the implication of Gemtek here is deliberate or a
misconfiguration on the part of Cuban officials, especially since the
certificate is self-signed and was issued in 2002. It could be,
however, a trace of the supposed involvement of China in the
development of Cuba's networking systems, although Gemtek is based in
Taiwan, and not in the China mainland.
That IP, in turn, redirects you to the same portal but in a page that
shows you the statistics:
https://www.portal-wifi-temas.nauta.cu/?mac=0024D1717D18&script=logout.user&remain_time=00%3A55%3A52&session_time=00%3A04%3A08&username=151003576287&clientip=10.156.41.21&nasid=Wifi_Memories_Jibacoa&r=ac%2Fpopup
Notice how you see the MAC address of the machine in the URL
(randomized, this is not my MAC address), along
with the remaining time, session time, client IP and the Wifi access
point ESSID. There may be some potential in defrauding the session
time there, I haven't tested it directly.
Hitting Actualizar
redirects you back to the IP address, which
redirects you to the right URL on the portal. The "real" logout is at:
http://192.168.134.138/logout.user?cmd=logout
The login is performed against
https://www.portal-wifi-temas.nauta.cu/index.php?r=ac/login with a
referer of:
https://www.portal-wifi-temas.nauta.cu/?&nasid=Wifi_Memories_Jibacoa&nasip=192.168.134.138&clientip=10.156.41.21&mac=EC:55:F9:C5:F2:55&ourl=http%3a%2f%2fgoogle.ca%2f&sslport=443&lang=en-US%2cen%3bq%3d0.8&lanip=10.156.41.1
Again, notice the information revealed to the central portal.
Equipment and providers
I ran Nmap probes against both the captive portal and
the redirection host, in the hope of finding out how they were built
and if they could reveal the source of the equipment used.
The complete nmap probes are available in nmap, but it seems that
the captive portal is running some embedded device. It is confusing
because the probe for the captive portal responds as if it was the
gateway, which blurs even more the distinction between the hotel's
gateway and the captive portal. This raises the distinct possibility
that all access points are actually captive portal that authenticate
to another central server.
The nmap traces do show three distinct hosts however:
- the captive portal (
www.portal-wifi-temas.nauta.cu
, 190.6.81.230
)
- some redirection host (
192.168.134.138
)
- the hotel's gateway (
10.156.41.1
)
They do have distinct signatures so the above may be just me
misinterpreting traceroute and nmap results. Your comments may help in
clarifying the above.
Still, the three devices show up as running Linux, in
the two last cases versions between 2.4.21
and 2.4.31
. Now, to
find out which version of Linux it is running is way more challenging,
and it is possible it is just some custom Linux distribution. Indeed,
the webserver shows up as G4200.GSI.2.22.0155
and the SSH server is
running OpenSSH 3.0.2p1
, which is basically prehistoric (2002!)
which corroborates the idea that this is some Gemtek embedded device.
The fact that those devices are running 14 years old software should
be a concern to the people responsible for those networks. There is,
for example, a remote root vulnerability that affects that
specific version of OpenSSH, among
many other vulnerabilities.
A note on Nauta card's security
Finally, one can note that it is probably trivial to guess card
UIDs. All cards i have here start with the prefix 15100
, the
following digits being 3576
or 4595
, presumably depending on the
"batch" that was sent to different hotels, which seems to be batches
of 1000 cards. You can also correlate the UID with the date at which
the card was issued. For example, 15100357XXX
cards are all valid
until 19/03/2017, and 151004595XXX
cards are all valid until
23/03/2017. Here's the list of UIDs I have seen:
151004595313
151004595974
151003576287
151003576105
151003576097
The passwords, on the other hand, do seem fairly random (although my
sample size is small). Interestingly, those passwords are also 12
digits long, which is about as strong as a seven-letter password
(mixed uppercase and lowercase). If there are no rate-limiting
provisions on that captive portal, it could be possible to guess
those passwords, since you have free rein on accessing those
routers. Depending on the performance of the routers, you could be
lucky and find a working password for free...
Conclusion
Clearly, Internet access in Cuba needs to be modernized. We can
clearly see that Cuba years behind the rest of the Americas, if only
through the percentage of the population with internet access, or
download speeds. The existence of a centralized captive portal also
enables a huge surveillance potential that should be a concern for
any Cuban, or for that matter, anyone wishing to live in a free
society.
The answer, however, lies not in the liberalization of commerce and
opening the doors to the US companies and their own systems of
surveillance. It should be possible, and even desirable for Cubans to
establish their own neutral network, a proposal I have made in the
past even for
here in Qu bec. This
network could be used and improved by Cubans themselves, prioritizing
local communities that would establish their own infrastructure
according to their own needs. I have been impressed by this article
about the El Paquete system - it shows great innovation and
initiative from Cubans which are known for engaging in technology in a
creative way. This should be leveraged by letting Cubans do what they
want with their networks, not telling them what to do.
The best the Googles of this world can do to help Cuba is not to
colonize Cuba's technological landscape but to cleanup their own and
make their own tools more easily accessible and shareable offline. It
is something companies can do
right now, something I detailed in
a previous article.
Bypassing the Cuban captive portal
The good news is that it is perfectly possible for Cubans (or at least
for a tourist like me with resources outside of the country) to bypass
the captive portal. Like many poorly implemented portals, the portal
allows DNS traffic to go through, which makes it possible to access
the global network for free by using a tool like iodine which
tunnels IP traffic over DNS requests.
Of course, the bandwidth and reliability of the connection you get
through such a portal is pretty bad. I have regularly seen 80% packet
loss and over two minutes of latency:
--- 10.0.0.1 ping statistics ---
163 packets transmitted, 31 received, 80% packet loss, time 162391ms
rtt min/avg/max/mdev = 133.700/2669.535/64188.027/11257.336 ms, pipe 65
Still, it allowed me to login to my home server through SSH using
Mosh to workaround the reliability issues.
Every once in a while, mosh would get stuck and keep on trying to send
packets to probe the server, which would clog the connection even
more. So I regularly had to restart the whole stack using these
commands:
killall iodine # stop DNS tunnel
nmcli n off # turn off wifi to change MAC address
macchanger -A wlan0 # change MAC address
nmcli n on # turn wifi back on
sleep 3 # wait for wifi to settle
iodine-client-start # restart DNS tunnel
The Koumbit Wiki has good instructions on
how to setup a DNS tunnel. I am wondering if such a public service
could be of use for Cubans, although I am not sure how it could be
deployed only for Cubans, and what kind of traffic it could
support... The fact is that iodine does require a server to
operate, and that server must be run on the outside of the censored
perimeter, something that Cubans may not be able to afford in the
first place.
Another possible way to save money with the captive portal would be to
write something that automates connecting and disconnecting from the
portal. You would feed that program a list of credentials and it would
connect to the portal only on demand, and disconnect as soon as no
traffic goes through. There are details on the implementation of the
captive portal below that may help future endeavours in that field.
Private information revealed to the captive portal
It should be mentioned, however, that the captive portal has a
significant amount of information on clients, which is a direct threat
to the online privacy of Cuban internet users. Of course the unique
identifiers issued with the Nauta cards can be correlated with your
identity, right from the start. For example, I had to give my room
number to get a Nauta card issued.
Then the central portal also knows which access point you are
connected to. For example, the central portal I was connected to
Wifi_Memories_Jibacoa
which, for anyone that cares to research, will
give them a location of about 20 square meters where I was located
when connected (there is only one access point in the whole hotel).
Finally, the central portal also knows my MAC address,
a unique identifier for the computer I am using which also reveals
which brand of computer I am using (Mac, Lenovo, etc). While this
address can be changed, very few people know that, let alone how.
This led me to question whether I would be allowed back in Cuba (or
even allowed out!) after publishing this blog post, as it is obvious
that I can be easily identified based on the time this article was
published, my name and other details. Hopefully the Cuban government
will either not notice or not care, but this can be a tricky
situation, obviously. I have heard that Cuban prisons are not the best
hangout place in Cuba, to say the least...
Network configuration assessment
This section is more technical and delves more deeply in the Cuban
internet to analyze the quality and topology of the network, along
with hints as to which hardware and providers are being used to
support the Cuban government.
Line quality
The internet is actually not so bad in the hotel. Again, this may be
because of the very fact that I am in that hotel, and I get a
privileged access to the new fiber line to Venezuela, the
ALBA-1 link.
The line speed I get is around 1mbps, according to speedtest,
which selected a server from LIME in George Town, Cayman Islands:
[1034]anarcat@angela:cuba$ speedtest
Retrieving speedtest.net configuration...
Retrieving speedtest.net server list...
Testing from Empresa de Telecomunicaciones de Cuba (152.206.92.146)...
Selecting best server based on latency...
Hosted by LIME (George Town) [391.78 km]: 317.546 ms
Testing download speed........................................
Download: 1.01 Mbits/s
Testing upload speed..................................................
Upload: 1.00 Mbits/s
Latency to the rest of the world is of couse slow:
--- koumbit.org ping statistics ---
122 packets transmitted, 120 received, 1,64% packet loss, time 18731,6ms
rtt min/avg/max/sdev = 127,457/156,097/725,211/94,688 ms
--- google.com ping statistics ---
122 packets transmitted, 121 received, 0,82% packet loss, time 19371,4ms
rtt min/avg/max/sdev = 132,517/160,095/724,971/93,273 ms
--- redcta.org.ar ping statistics ---
122 packets transmitted, 120 received, 1,64% packet loss, time 40748,6ms
rtt min/avg/max/sdev = 303,035/339,572/965,092/97,503 ms
--- ccc.de ping statistics ---
122 packets transmitted, 72 received, 40,98% packet loss, time 19560,2ms
rtt min/avg/max/sdev = 244,266/271,670/594,104/61,933 ms
Interestingly, Koumbit is actually the closest host in the above
test. It could be that Canadian hosts are less affected by bandwidth
problems compared to US hosts because of the embargo.
Network topology
The various traceroutes show a fairly odd network topology, but
that is typical of what I would described as "colonized internet
users", which have layers and layers of NAT and obscure routing that
keep them from the real internet. Just like large corporations are
implementing NAT in a large scale, Cuba seems to have layers and
layers of private RFC 1918 IPv4 space. A typical traceroute
starts with:
traceroute to koumbit.net (199.58.80.33), 30 hops max, 60 byte packets
1 10.156.41.1 (10.156.41.1) 9.724 ms 9.472 ms 9.405 ms
2 192.168.134.137 (192.168.134.137) 16.089 ms 15.612 ms 15.509 ms
3 172.31.252.113 (172.31.252.113) 15.350 ms 15.805 ms 15.358 ms
4 pos6-0-0-agu-cr-1.mpls.enet.cu (172.31.253.197) 15.286 ms 14.832 ms 14.405 ms
5 172.31.252.29 (172.31.252.29) 13.734 ms 13.685 ms 14.485 ms
6 200.0.16.130 (200.0.16.130) 14.428 ms 11.393 ms 10.977 ms
7 200.0.16.74 (200.0.16.74) 10.738 ms 10.019 ms 10.326 ms
8 ix-11-3-1-0.tcore1.TNK-Toronto.as6453.net (64.86.33.45) 108.577 ms 108.449 ms
Let's take this apart line by line:
1 10.156.41.1 (10.156.41.1) 9.724 ms 9.472 ms 9.405 ms
This is my local gateway, probably the hotel's wifi router.
2 192.168.134.137 (192.168.134.137) 16.089 ms 15.612 ms 15.509 ms
This is likely not very far from the local gateway, probably still in
Cuba. It in one bit away from the captive portal IP address (see
below) so it is very likely related to the captive portal implementation.
3 172.31.252.113 (172.31.252.113) 15.350 ms 15.805 ms 15.358 ms
4 pos6-0-0-agu-cr-1.mpls.enet.cu (172.31.253.197) 15.286 ms 14.832 ms 14.405 ms
5 172.31.252.29 (172.31.252.29) 13.734 ms 13.685 ms 14.485 ms
All those are withing RFC 1918 space. Interestingly, the Cuban
DNS servers resolve one of those private IPs as within Cuban
space, on line #4. That line is interesting because it reveals the
potential use of MPLS.
6 200.0.16.130 (200.0.16.130) 14.428 ms 11.393 ms 10.977 ms
7 200.0.16.74 (200.0.16.74) 10.738 ms 10.019 ms 10.326 ms
Those two lines are the only ones that actually reveal that the route
belongs in Cuba at all. Both IPs are in a tiny (/24
, or 256 IP
addresses) network allocated to ETECSA, the state telco
in Cuba:
inetnum: 200.0.16/24
status: allocated
aut-num: N/A
owner: EMPRESA DE TELECOMUNICACIONES DE CUBA S.A. (IXP CUBA)
ownerid: CU-CUBA-LACNIC
responsible: Rafael L pez Guerra
address: Ave. Independencia y 19 Mayo, s/n,
address: 10600 - La Habana - CH
country: CU
phone: +53 7 574242 []
owner-c: JOQ
tech-c: JOQ
abuse-c: JEM52
inetrev: 200.0.16/24
nserver: NS1.NAP.ETECSA.NET
nsstat: 20160123 AA
nslastaa: 20160123
nserver: NS2.NAP.ETECSA.NET
nsstat: 20160123 AA
nslastaa: 20160123
created: 20030512
changed: 20140610
Then the last hop:
8 ix-11-3-1-0.tcore1.TNK-Toronto.as6453.net (64.86.33.45) 108.577 ms 108.449 ms 108.257 ms
...interestingly, lands directly in Toronto, in this case going later
to Koumbit but that is the first hop that varies according to the
destination, hops 1-7 being a common trunk to all external
communications. It's also interesting that this shoves a good 90
milliseconds extra in latency, showing that a significant distance and
number of equipment crossed. Yet a single hop is crossed, not showing
the intermediate step of the Venezuelan link or any other links for
that matter. Something obscure is going on there...
Also interesting to note is the traceroute to the redirection host,
which is only one hop away:
traceroute to 192.168.134.138 (192.168.134.138), 30 hops max, 60 byte packets
1 192.168.134.138 (192.168.134.138) 6.027 ms 5.698 ms 5.596 ms
Even though it is not the gateway:
$ ip route
default via 10.156.41.1 dev wlan0 proto static metric 1024
10.156.41.0/24 dev wlan0 proto kernel scope link src 10.156.41.4
169.254.0.0/16 dev wlan0 scope link metric 1000
This means a very close coordination between the different access
points and the captive portal system. Finally, note that there seems
to be only three peers to the Cuban internet:
Teleglobe, formerly Canadian, now owned by the Indian
[[!wiki Tata group]], and Telef nica, the Spanish Telco
that colonized most of Latin America's internet, all the way down to
Argentina. This is confirmed by my traceroutes, which show traffic to
Koumbit going through Tata and Google's going through Telef nica.
Captive portal implementation
The captive portal is https://www.portal-wifi-temas.nauta.cu/ (not
accessible outside of Cuba) and uses a
self-signed certificate. The domain name resolves to
190.6.81.230
in the hotel.
Accessing http://1.1.1.1/ gives you a status page which allows you
to disconnect from the portal. It actually redirects you to
https://192.168.134.138/logout.user. That is also a
self-signed, but different certificate. That
certificate actually reveals the implication of Gemtek which is a
"world-leading provider of Wireless Broadband solutions, offering a
wide range of solutions from residential to business". It is somewhat
unclear if the implication of Gemtek here is deliberate or a
misconfiguration on the part of Cuban officials, especially since the
certificate is self-signed and was issued in 2002. It could be,
however, a trace of the supposed involvement of China in the
development of Cuba's networking systems, although Gemtek is based in
Taiwan, and not in the China mainland.
That IP, in turn, redirects you to the same portal but in a page that
shows you the statistics:
https://www.portal-wifi-temas.nauta.cu/?mac=0024D1717D18&script=logout.user&remain_time=00%3A55%3A52&session_time=00%3A04%3A08&username=151003576287&clientip=10.156.41.21&nasid=Wifi_Memories_Jibacoa&r=ac%2Fpopup
Notice how you see the MAC address of the machine in the URL
(randomized, this is not my MAC address), along
with the remaining time, session time, client IP and the Wifi access
point ESSID. There may be some potential in defrauding the session
time there, I haven't tested it directly.
Hitting Actualizar
redirects you back to the IP address, which
redirects you to the right URL on the portal. The "real" logout is at:
http://192.168.134.138/logout.user?cmd=logout
The login is performed against
https://www.portal-wifi-temas.nauta.cu/index.php?r=ac/login with a
referer of:
https://www.portal-wifi-temas.nauta.cu/?&nasid=Wifi_Memories_Jibacoa&nasip=192.168.134.138&clientip=10.156.41.21&mac=EC:55:F9:C5:F2:55&ourl=http%3a%2f%2fgoogle.ca%2f&sslport=443&lang=en-US%2cen%3bq%3d0.8&lanip=10.156.41.1
Again, notice the information revealed to the central portal.
Equipment and providers
I ran Nmap probes against both the captive portal and
the redirection host, in the hope of finding out how they were built
and if they could reveal the source of the equipment used.
The complete nmap probes are available in nmap, but it seems that
the captive portal is running some embedded device. It is confusing
because the probe for the captive portal responds as if it was the
gateway, which blurs even more the distinction between the hotel's
gateway and the captive portal. This raises the distinct possibility
that all access points are actually captive portal that authenticate
to another central server.
The nmap traces do show three distinct hosts however:
- the captive portal (
www.portal-wifi-temas.nauta.cu
, 190.6.81.230
)
- some redirection host (
192.168.134.138
)
- the hotel's gateway (
10.156.41.1
)
They do have distinct signatures so the above may be just me
misinterpreting traceroute and nmap results. Your comments may help in
clarifying the above.
Still, the three devices show up as running Linux, in
the two last cases versions between 2.4.21
and 2.4.31
. Now, to
find out which version of Linux it is running is way more challenging,
and it is possible it is just some custom Linux distribution. Indeed,
the webserver shows up as G4200.GSI.2.22.0155
and the SSH server is
running OpenSSH 3.0.2p1
, which is basically prehistoric (2002!)
which corroborates the idea that this is some Gemtek embedded device.
The fact that those devices are running 14 years old software should
be a concern to the people responsible for those networks. There is,
for example, a remote root vulnerability that affects that
specific version of OpenSSH, among
many other vulnerabilities.
A note on Nauta card's security
Finally, one can note that it is probably trivial to guess card
UIDs. All cards i have here start with the prefix 15100
, the
following digits being 3576
or 4595
, presumably depending on the
"batch" that was sent to different hotels, which seems to be batches
of 1000 cards. You can also correlate the UID with the date at which
the card was issued. For example, 15100357XXX
cards are all valid
until 19/03/2017, and 151004595XXX
cards are all valid until
23/03/2017. Here's the list of UIDs I have seen:
151004595313
151004595974
151003576287
151003576105
151003576097
The passwords, on the other hand, do seem fairly random (although my
sample size is small). Interestingly, those passwords are also 12
digits long, which is about as strong as a seven-letter password
(mixed uppercase and lowercase). If there are no rate-limiting
provisions on that captive portal, it could be possible to guess
those passwords, since you have free rein on accessing those
routers. Depending on the performance of the routers, you could be
lucky and find a working password for free...
Conclusion
Clearly, Internet access in Cuba needs to be modernized. We can
clearly see that Cuba years behind the rest of the Americas, if only
through the percentage of the population with internet access, or
download speeds. The existence of a centralized captive portal also
enables a huge surveillance potential that should be a concern for
any Cuban, or for that matter, anyone wishing to live in a free
society.
The answer, however, lies not in the liberalization of commerce and
opening the doors to the US companies and their own systems of
surveillance. It should be possible, and even desirable for Cubans to
establish their own neutral network, a proposal I have made in the
past even for
here in Qu bec. This
network could be used and improved by Cubans themselves, prioritizing
local communities that would establish their own infrastructure
according to their own needs. I have been impressed by this article
about the El Paquete system - it shows great innovation and
initiative from Cubans which are known for engaging in technology in a
creative way. This should be leveraged by letting Cubans do what they
want with their networks, not telling them what to do.
The best the Googles of this world can do to help Cuba is not to
colonize Cuba's technological landscape but to cleanup their own and
make their own tools more easily accessible and shareable offline. It
is something companies can do
right now, something I detailed in
a previous article.
--- 10.0.0.1 ping statistics ---
163 packets transmitted, 31 received, 80% packet loss, time 162391ms
rtt min/avg/max/mdev = 133.700/2669.535/64188.027/11257.336 ms, pipe 65
killall iodine # stop DNS tunnel
nmcli n off # turn off wifi to change MAC address
macchanger -A wlan0 # change MAC address
nmcli n on # turn wifi back on
sleep 3 # wait for wifi to settle
iodine-client-start # restart DNS tunnel
Wifi_Memories_Jibacoa
which, for anyone that cares to research, will
give them a location of about 20 square meters where I was located
when connected (there is only one access point in the whole hotel).
Finally, the central portal also knows my MAC address,
a unique identifier for the computer I am using which also reveals
which brand of computer I am using (Mac, Lenovo, etc). While this
address can be changed, very few people know that, let alone how.
This led me to question whether I would be allowed back in Cuba (or
even allowed out!) after publishing this blog post, as it is obvious
that I can be easily identified based on the time this article was
published, my name and other details. Hopefully the Cuban government
will either not notice or not care, but this can be a tricky
situation, obviously. I have heard that Cuban prisons are not the best
hangout place in Cuba, to say the least...
Network configuration assessment
This section is more technical and delves more deeply in the Cuban
internet to analyze the quality and topology of the network, along
with hints as to which hardware and providers are being used to
support the Cuban government.
Line quality
The internet is actually not so bad in the hotel. Again, this may be
because of the very fact that I am in that hotel, and I get a
privileged access to the new fiber line to Venezuela, the
ALBA-1 link.
The line speed I get is around 1mbps, according to speedtest,
which selected a server from LIME in George Town, Cayman Islands:
[1034]anarcat@angela:cuba$ speedtest
Retrieving speedtest.net configuration...
Retrieving speedtest.net server list...
Testing from Empresa de Telecomunicaciones de Cuba (152.206.92.146)...
Selecting best server based on latency...
Hosted by LIME (George Town) [391.78 km]: 317.546 ms
Testing download speed........................................
Download: 1.01 Mbits/s
Testing upload speed..................................................
Upload: 1.00 Mbits/s
Latency to the rest of the world is of couse slow:
--- koumbit.org ping statistics ---
122 packets transmitted, 120 received, 1,64% packet loss, time 18731,6ms
rtt min/avg/max/sdev = 127,457/156,097/725,211/94,688 ms
--- google.com ping statistics ---
122 packets transmitted, 121 received, 0,82% packet loss, time 19371,4ms
rtt min/avg/max/sdev = 132,517/160,095/724,971/93,273 ms
--- redcta.org.ar ping statistics ---
122 packets transmitted, 120 received, 1,64% packet loss, time 40748,6ms
rtt min/avg/max/sdev = 303,035/339,572/965,092/97,503 ms
--- ccc.de ping statistics ---
122 packets transmitted, 72 received, 40,98% packet loss, time 19560,2ms
rtt min/avg/max/sdev = 244,266/271,670/594,104/61,933 ms
Interestingly, Koumbit is actually the closest host in the above
test. It could be that Canadian hosts are less affected by bandwidth
problems compared to US hosts because of the embargo.
Network topology
The various traceroutes show a fairly odd network topology, but
that is typical of what I would described as "colonized internet
users", which have layers and layers of NAT and obscure routing that
keep them from the real internet. Just like large corporations are
implementing NAT in a large scale, Cuba seems to have layers and
layers of private RFC 1918 IPv4 space. A typical traceroute
starts with:
traceroute to koumbit.net (199.58.80.33), 30 hops max, 60 byte packets
1 10.156.41.1 (10.156.41.1) 9.724 ms 9.472 ms 9.405 ms
2 192.168.134.137 (192.168.134.137) 16.089 ms 15.612 ms 15.509 ms
3 172.31.252.113 (172.31.252.113) 15.350 ms 15.805 ms 15.358 ms
4 pos6-0-0-agu-cr-1.mpls.enet.cu (172.31.253.197) 15.286 ms 14.832 ms 14.405 ms
5 172.31.252.29 (172.31.252.29) 13.734 ms 13.685 ms 14.485 ms
6 200.0.16.130 (200.0.16.130) 14.428 ms 11.393 ms 10.977 ms
7 200.0.16.74 (200.0.16.74) 10.738 ms 10.019 ms 10.326 ms
8 ix-11-3-1-0.tcore1.TNK-Toronto.as6453.net (64.86.33.45) 108.577 ms 108.449 ms
Let's take this apart line by line:
1 10.156.41.1 (10.156.41.1) 9.724 ms 9.472 ms 9.405 ms
This is my local gateway, probably the hotel's wifi router.
2 192.168.134.137 (192.168.134.137) 16.089 ms 15.612 ms 15.509 ms
This is likely not very far from the local gateway, probably still in
Cuba. It in one bit away from the captive portal IP address (see
below) so it is very likely related to the captive portal implementation.
3 172.31.252.113 (172.31.252.113) 15.350 ms 15.805 ms 15.358 ms
4 pos6-0-0-agu-cr-1.mpls.enet.cu (172.31.253.197) 15.286 ms 14.832 ms 14.405 ms
5 172.31.252.29 (172.31.252.29) 13.734 ms 13.685 ms 14.485 ms
All those are withing RFC 1918 space. Interestingly, the Cuban
DNS servers resolve one of those private IPs as within Cuban
space, on line #4. That line is interesting because it reveals the
potential use of MPLS.
6 200.0.16.130 (200.0.16.130) 14.428 ms 11.393 ms 10.977 ms
7 200.0.16.74 (200.0.16.74) 10.738 ms 10.019 ms 10.326 ms
Those two lines are the only ones that actually reveal that the route
belongs in Cuba at all. Both IPs are in a tiny (/24
, or 256 IP
addresses) network allocated to ETECSA, the state telco
in Cuba:
inetnum: 200.0.16/24
status: allocated
aut-num: N/A
owner: EMPRESA DE TELECOMUNICACIONES DE CUBA S.A. (IXP CUBA)
ownerid: CU-CUBA-LACNIC
responsible: Rafael L pez Guerra
address: Ave. Independencia y 19 Mayo, s/n,
address: 10600 - La Habana - CH
country: CU
phone: +53 7 574242 []
owner-c: JOQ
tech-c: JOQ
abuse-c: JEM52
inetrev: 200.0.16/24
nserver: NS1.NAP.ETECSA.NET
nsstat: 20160123 AA
nslastaa: 20160123
nserver: NS2.NAP.ETECSA.NET
nsstat: 20160123 AA
nslastaa: 20160123
created: 20030512
changed: 20140610
Then the last hop:
8 ix-11-3-1-0.tcore1.TNK-Toronto.as6453.net (64.86.33.45) 108.577 ms 108.449 ms 108.257 ms
...interestingly, lands directly in Toronto, in this case going later
to Koumbit but that is the first hop that varies according to the
destination, hops 1-7 being a common trunk to all external
communications. It's also interesting that this shoves a good 90
milliseconds extra in latency, showing that a significant distance and
number of equipment crossed. Yet a single hop is crossed, not showing
the intermediate step of the Venezuelan link or any other links for
that matter. Something obscure is going on there...
Also interesting to note is the traceroute to the redirection host,
which is only one hop away:
traceroute to 192.168.134.138 (192.168.134.138), 30 hops max, 60 byte packets
1 192.168.134.138 (192.168.134.138) 6.027 ms 5.698 ms 5.596 ms
Even though it is not the gateway:
$ ip route
default via 10.156.41.1 dev wlan0 proto static metric 1024
10.156.41.0/24 dev wlan0 proto kernel scope link src 10.156.41.4
169.254.0.0/16 dev wlan0 scope link metric 1000
This means a very close coordination between the different access
points and the captive portal system. Finally, note that there seems
to be only three peers to the Cuban internet:
Teleglobe, formerly Canadian, now owned by the Indian
[[!wiki Tata group]], and Telef nica, the Spanish Telco
that colonized most of Latin America's internet, all the way down to
Argentina. This is confirmed by my traceroutes, which show traffic to
Koumbit going through Tata and Google's going through Telef nica.
Captive portal implementation
The captive portal is https://www.portal-wifi-temas.nauta.cu/ (not
accessible outside of Cuba) and uses a
self-signed certificate. The domain name resolves to
190.6.81.230
in the hotel.
Accessing http://1.1.1.1/ gives you a status page which allows you
to disconnect from the portal. It actually redirects you to
https://192.168.134.138/logout.user. That is also a
self-signed, but different certificate. That
certificate actually reveals the implication of Gemtek which is a
"world-leading provider of Wireless Broadband solutions, offering a
wide range of solutions from residential to business". It is somewhat
unclear if the implication of Gemtek here is deliberate or a
misconfiguration on the part of Cuban officials, especially since the
certificate is self-signed and was issued in 2002. It could be,
however, a trace of the supposed involvement of China in the
development of Cuba's networking systems, although Gemtek is based in
Taiwan, and not in the China mainland.
That IP, in turn, redirects you to the same portal but in a page that
shows you the statistics:
https://www.portal-wifi-temas.nauta.cu/?mac=0024D1717D18&script=logout.user&remain_time=00%3A55%3A52&session_time=00%3A04%3A08&username=151003576287&clientip=10.156.41.21&nasid=Wifi_Memories_Jibacoa&r=ac%2Fpopup
Notice how you see the MAC address of the machine in the URL
(randomized, this is not my MAC address), along
with the remaining time, session time, client IP and the Wifi access
point ESSID. There may be some potential in defrauding the session
time there, I haven't tested it directly.
Hitting Actualizar
redirects you back to the IP address, which
redirects you to the right URL on the portal. The "real" logout is at:
http://192.168.134.138/logout.user?cmd=logout
The login is performed against
https://www.portal-wifi-temas.nauta.cu/index.php?r=ac/login with a
referer of:
https://www.portal-wifi-temas.nauta.cu/?&nasid=Wifi_Memories_Jibacoa&nasip=192.168.134.138&clientip=10.156.41.21&mac=EC:55:F9:C5:F2:55&ourl=http%3a%2f%2fgoogle.ca%2f&sslport=443&lang=en-US%2cen%3bq%3d0.8&lanip=10.156.41.1
Again, notice the information revealed to the central portal.
Equipment and providers
I ran Nmap probes against both the captive portal and
the redirection host, in the hope of finding out how they were built
and if they could reveal the source of the equipment used.
The complete nmap probes are available in nmap, but it seems that
the captive portal is running some embedded device. It is confusing
because the probe for the captive portal responds as if it was the
gateway, which blurs even more the distinction between the hotel's
gateway and the captive portal. This raises the distinct possibility
that all access points are actually captive portal that authenticate
to another central server.
The nmap traces do show three distinct hosts however:
- the captive portal (
www.portal-wifi-temas.nauta.cu
, 190.6.81.230
)
- some redirection host (
192.168.134.138
)
- the hotel's gateway (
10.156.41.1
)
They do have distinct signatures so the above may be just me
misinterpreting traceroute and nmap results. Your comments may help in
clarifying the above.
Still, the three devices show up as running Linux, in
the two last cases versions between 2.4.21
and 2.4.31
. Now, to
find out which version of Linux it is running is way more challenging,
and it is possible it is just some custom Linux distribution. Indeed,
the webserver shows up as G4200.GSI.2.22.0155
and the SSH server is
running OpenSSH 3.0.2p1
, which is basically prehistoric (2002!)
which corroborates the idea that this is some Gemtek embedded device.
The fact that those devices are running 14 years old software should
be a concern to the people responsible for those networks. There is,
for example, a remote root vulnerability that affects that
specific version of OpenSSH, among
many other vulnerabilities.
A note on Nauta card's security
Finally, one can note that it is probably trivial to guess card
UIDs. All cards i have here start with the prefix 15100
, the
following digits being 3576
or 4595
, presumably depending on the
"batch" that was sent to different hotels, which seems to be batches
of 1000 cards. You can also correlate the UID with the date at which
the card was issued. For example, 15100357XXX
cards are all valid
until 19/03/2017, and 151004595XXX
cards are all valid until
23/03/2017. Here's the list of UIDs I have seen:
151004595313
151004595974
151003576287
151003576105
151003576097
The passwords, on the other hand, do seem fairly random (although my
sample size is small). Interestingly, those passwords are also 12
digits long, which is about as strong as a seven-letter password
(mixed uppercase and lowercase). If there are no rate-limiting
provisions on that captive portal, it could be possible to guess
those passwords, since you have free rein on accessing those
routers. Depending on the performance of the routers, you could be
lucky and find a working password for free...
Conclusion
Clearly, Internet access in Cuba needs to be modernized. We can
clearly see that Cuba years behind the rest of the Americas, if only
through the percentage of the population with internet access, or
download speeds. The existence of a centralized captive portal also
enables a huge surveillance potential that should be a concern for
any Cuban, or for that matter, anyone wishing to live in a free
society.
The answer, however, lies not in the liberalization of commerce and
opening the doors to the US companies and their own systems of
surveillance. It should be possible, and even desirable for Cubans to
establish their own neutral network, a proposal I have made in the
past even for
here in Qu bec. This
network could be used and improved by Cubans themselves, prioritizing
local communities that would establish their own infrastructure
according to their own needs. I have been impressed by this article
about the El Paquete system - it shows great innovation and
initiative from Cubans which are known for engaging in technology in a
creative way. This should be leveraged by letting Cubans do what they
want with their networks, not telling them what to do.
The best the Googles of this world can do to help Cuba is not to
colonize Cuba's technological landscape but to cleanup their own and
make their own tools more easily accessible and shareable offline. It
is something companies can do
right now, something I detailed in
a previous article.
[1034]anarcat@angela:cuba$ speedtest
Retrieving speedtest.net configuration...
Retrieving speedtest.net server list...
Testing from Empresa de Telecomunicaciones de Cuba (152.206.92.146)...
Selecting best server based on latency...
Hosted by LIME (George Town) [391.78 km]: 317.546 ms
Testing download speed........................................
Download: 1.01 Mbits/s
Testing upload speed..................................................
Upload: 1.00 Mbits/s
Latency to the rest of the world is of couse slow:
--- koumbit.org ping statistics ---
122 packets transmitted, 120 received, 1,64% packet loss, time 18731,6ms
rtt min/avg/max/sdev = 127,457/156,097/725,211/94,688 ms
--- google.com ping statistics ---
122 packets transmitted, 121 received, 0,82% packet loss, time 19371,4ms
rtt min/avg/max/sdev = 132,517/160,095/724,971/93,273 ms
--- redcta.org.ar ping statistics ---
122 packets transmitted, 120 received, 1,64% packet loss, time 40748,6ms
rtt min/avg/max/sdev = 303,035/339,572/965,092/97,503 ms
--- ccc.de ping statistics ---
122 packets transmitted, 72 received, 40,98% packet loss, time 19560,2ms
rtt min/avg/max/sdev = 244,266/271,670/594,104/61,933 ms
Interestingly, Koumbit is actually the closest host in the above
test. It could be that Canadian hosts are less affected by bandwidth
problems compared to US hosts because of the embargo.
Network topology
The various traceroutes show a fairly odd network topology, but
that is typical of what I would described as "colonized internet
users", which have layers and layers of NAT and obscure routing that
keep them from the real internet. Just like large corporations are
implementing NAT in a large scale, Cuba seems to have layers and
layers of private RFC 1918 IPv4 space. A typical traceroute
starts with:
traceroute to koumbit.net (199.58.80.33), 30 hops max, 60 byte packets
1 10.156.41.1 (10.156.41.1) 9.724 ms 9.472 ms 9.405 ms
2 192.168.134.137 (192.168.134.137) 16.089 ms 15.612 ms 15.509 ms
3 172.31.252.113 (172.31.252.113) 15.350 ms 15.805 ms 15.358 ms
4 pos6-0-0-agu-cr-1.mpls.enet.cu (172.31.253.197) 15.286 ms 14.832 ms 14.405 ms
5 172.31.252.29 (172.31.252.29) 13.734 ms 13.685 ms 14.485 ms
6 200.0.16.130 (200.0.16.130) 14.428 ms 11.393 ms 10.977 ms
7 200.0.16.74 (200.0.16.74) 10.738 ms 10.019 ms 10.326 ms
8 ix-11-3-1-0.tcore1.TNK-Toronto.as6453.net (64.86.33.45) 108.577 ms 108.449 ms
Let's take this apart line by line:
1 10.156.41.1 (10.156.41.1) 9.724 ms 9.472 ms 9.405 ms
This is my local gateway, probably the hotel's wifi router.
2 192.168.134.137 (192.168.134.137) 16.089 ms 15.612 ms 15.509 ms
This is likely not very far from the local gateway, probably still in
Cuba. It in one bit away from the captive portal IP address (see
below) so it is very likely related to the captive portal implementation.
3 172.31.252.113 (172.31.252.113) 15.350 ms 15.805 ms 15.358 ms
4 pos6-0-0-agu-cr-1.mpls.enet.cu (172.31.253.197) 15.286 ms 14.832 ms 14.405 ms
5 172.31.252.29 (172.31.252.29) 13.734 ms 13.685 ms 14.485 ms
All those are withing RFC 1918 space. Interestingly, the Cuban
DNS servers resolve one of those private IPs as within Cuban
space, on line #4. That line is interesting because it reveals the
potential use of MPLS.
6 200.0.16.130 (200.0.16.130) 14.428 ms 11.393 ms 10.977 ms
7 200.0.16.74 (200.0.16.74) 10.738 ms 10.019 ms 10.326 ms
Those two lines are the only ones that actually reveal that the route
belongs in Cuba at all. Both IPs are in a tiny (/24
, or 256 IP
addresses) network allocated to ETECSA, the state telco
in Cuba:
inetnum: 200.0.16/24
status: allocated
aut-num: N/A
owner: EMPRESA DE TELECOMUNICACIONES DE CUBA S.A. (IXP CUBA)
ownerid: CU-CUBA-LACNIC
responsible: Rafael L pez Guerra
address: Ave. Independencia y 19 Mayo, s/n,
address: 10600 - La Habana - CH
country: CU
phone: +53 7 574242 []
owner-c: JOQ
tech-c: JOQ
abuse-c: JEM52
inetrev: 200.0.16/24
nserver: NS1.NAP.ETECSA.NET
nsstat: 20160123 AA
nslastaa: 20160123
nserver: NS2.NAP.ETECSA.NET
nsstat: 20160123 AA
nslastaa: 20160123
created: 20030512
changed: 20140610
Then the last hop:
8 ix-11-3-1-0.tcore1.TNK-Toronto.as6453.net (64.86.33.45) 108.577 ms 108.449 ms 108.257 ms
...interestingly, lands directly in Toronto, in this case going later
to Koumbit but that is the first hop that varies according to the
destination, hops 1-7 being a common trunk to all external
communications. It's also interesting that this shoves a good 90
milliseconds extra in latency, showing that a significant distance and
number of equipment crossed. Yet a single hop is crossed, not showing
the intermediate step of the Venezuelan link or any other links for
that matter. Something obscure is going on there...
Also interesting to note is the traceroute to the redirection host,
which is only one hop away:
traceroute to 192.168.134.138 (192.168.134.138), 30 hops max, 60 byte packets
1 192.168.134.138 (192.168.134.138) 6.027 ms 5.698 ms 5.596 ms
Even though it is not the gateway:
$ ip route
default via 10.156.41.1 dev wlan0 proto static metric 1024
10.156.41.0/24 dev wlan0 proto kernel scope link src 10.156.41.4
169.254.0.0/16 dev wlan0 scope link metric 1000
This means a very close coordination between the different access
points and the captive portal system. Finally, note that there seems
to be only three peers to the Cuban internet:
Teleglobe, formerly Canadian, now owned by the Indian
[[!wiki Tata group]], and Telef nica, the Spanish Telco
that colonized most of Latin America's internet, all the way down to
Argentina. This is confirmed by my traceroutes, which show traffic to
Koumbit going through Tata and Google's going through Telef nica.
Captive portal implementation
The captive portal is https://www.portal-wifi-temas.nauta.cu/ (not
accessible outside of Cuba) and uses a
self-signed certificate. The domain name resolves to
190.6.81.230
in the hotel.
Accessing http://1.1.1.1/ gives you a status page which allows you
to disconnect from the portal. It actually redirects you to
https://192.168.134.138/logout.user. That is also a
self-signed, but different certificate. That
certificate actually reveals the implication of Gemtek which is a
"world-leading provider of Wireless Broadband solutions, offering a
wide range of solutions from residential to business". It is somewhat
unclear if the implication of Gemtek here is deliberate or a
misconfiguration on the part of Cuban officials, especially since the
certificate is self-signed and was issued in 2002. It could be,
however, a trace of the supposed involvement of China in the
development of Cuba's networking systems, although Gemtek is based in
Taiwan, and not in the China mainland.
That IP, in turn, redirects you to the same portal but in a page that
shows you the statistics:
https://www.portal-wifi-temas.nauta.cu/?mac=0024D1717D18&script=logout.user&remain_time=00%3A55%3A52&session_time=00%3A04%3A08&username=151003576287&clientip=10.156.41.21&nasid=Wifi_Memories_Jibacoa&r=ac%2Fpopup
Notice how you see the MAC address of the machine in the URL
(randomized, this is not my MAC address), along
with the remaining time, session time, client IP and the Wifi access
point ESSID. There may be some potential in defrauding the session
time there, I haven't tested it directly.
Hitting Actualizar
redirects you back to the IP address, which
redirects you to the right URL on the portal. The "real" logout is at:
http://192.168.134.138/logout.user?cmd=logout
The login is performed against
https://www.portal-wifi-temas.nauta.cu/index.php?r=ac/login with a
referer of:
https://www.portal-wifi-temas.nauta.cu/?&nasid=Wifi_Memories_Jibacoa&nasip=192.168.134.138&clientip=10.156.41.21&mac=EC:55:F9:C5:F2:55&ourl=http%3a%2f%2fgoogle.ca%2f&sslport=443&lang=en-US%2cen%3bq%3d0.8&lanip=10.156.41.1
Again, notice the information revealed to the central portal.
Equipment and providers
I ran Nmap probes against both the captive portal and
the redirection host, in the hope of finding out how they were built
and if they could reveal the source of the equipment used.
The complete nmap probes are available in nmap, but it seems that
the captive portal is running some embedded device. It is confusing
because the probe for the captive portal responds as if it was the
gateway, which blurs even more the distinction between the hotel's
gateway and the captive portal. This raises the distinct possibility
that all access points are actually captive portal that authenticate
to another central server.
The nmap traces do show three distinct hosts however:
- the captive portal (
www.portal-wifi-temas.nauta.cu
, 190.6.81.230
)
- some redirection host (
192.168.134.138
)
- the hotel's gateway (
10.156.41.1
)
They do have distinct signatures so the above may be just me
misinterpreting traceroute and nmap results. Your comments may help in
clarifying the above.
Still, the three devices show up as running Linux, in
the two last cases versions between 2.4.21
and 2.4.31
. Now, to
find out which version of Linux it is running is way more challenging,
and it is possible it is just some custom Linux distribution. Indeed,
the webserver shows up as G4200.GSI.2.22.0155
and the SSH server is
running OpenSSH 3.0.2p1
, which is basically prehistoric (2002!)
which corroborates the idea that this is some Gemtek embedded device.
The fact that those devices are running 14 years old software should
be a concern to the people responsible for those networks. There is,
for example, a remote root vulnerability that affects that
specific version of OpenSSH, among
many other vulnerabilities.
A note on Nauta card's security
Finally, one can note that it is probably trivial to guess card
UIDs. All cards i have here start with the prefix 15100
, the
following digits being 3576
or 4595
, presumably depending on the
"batch" that was sent to different hotels, which seems to be batches
of 1000 cards. You can also correlate the UID with the date at which
the card was issued. For example, 15100357XXX
cards are all valid
until 19/03/2017, and 151004595XXX
cards are all valid until
23/03/2017. Here's the list of UIDs I have seen:
151004595313
151004595974
151003576287
151003576105
151003576097
The passwords, on the other hand, do seem fairly random (although my
sample size is small). Interestingly, those passwords are also 12
digits long, which is about as strong as a seven-letter password
(mixed uppercase and lowercase). If there are no rate-limiting
provisions on that captive portal, it could be possible to guess
those passwords, since you have free rein on accessing those
routers. Depending on the performance of the routers, you could be
lucky and find a working password for free...
Conclusion
Clearly, Internet access in Cuba needs to be modernized. We can
clearly see that Cuba years behind the rest of the Americas, if only
through the percentage of the population with internet access, or
download speeds. The existence of a centralized captive portal also
enables a huge surveillance potential that should be a concern for
any Cuban, or for that matter, anyone wishing to live in a free
society.
The answer, however, lies not in the liberalization of commerce and
opening the doors to the US companies and their own systems of
surveillance. It should be possible, and even desirable for Cubans to
establish their own neutral network, a proposal I have made in the
past even for
here in Qu bec. This
network could be used and improved by Cubans themselves, prioritizing
local communities that would establish their own infrastructure
according to their own needs. I have been impressed by this article
about the El Paquete system - it shows great innovation and
initiative from Cubans which are known for engaging in technology in a
creative way. This should be leveraged by letting Cubans do what they
want with their networks, not telling them what to do.
The best the Googles of this world can do to help Cuba is not to
colonize Cuba's technological landscape but to cleanup their own and
make their own tools more easily accessible and shareable offline. It
is something companies can do
right now, something I detailed in
a previous article.
traceroute to koumbit.net (199.58.80.33), 30 hops max, 60 byte packets
1 10.156.41.1 (10.156.41.1) 9.724 ms 9.472 ms 9.405 ms
2 192.168.134.137 (192.168.134.137) 16.089 ms 15.612 ms 15.509 ms
3 172.31.252.113 (172.31.252.113) 15.350 ms 15.805 ms 15.358 ms
4 pos6-0-0-agu-cr-1.mpls.enet.cu (172.31.253.197) 15.286 ms 14.832 ms 14.405 ms
5 172.31.252.29 (172.31.252.29) 13.734 ms 13.685 ms 14.485 ms
6 200.0.16.130 (200.0.16.130) 14.428 ms 11.393 ms 10.977 ms
7 200.0.16.74 (200.0.16.74) 10.738 ms 10.019 ms 10.326 ms
8 ix-11-3-1-0.tcore1.TNK-Toronto.as6453.net (64.86.33.45) 108.577 ms 108.449 ms
1 10.156.41.1 (10.156.41.1) 9.724 ms 9.472 ms 9.405 ms
2 192.168.134.137 (192.168.134.137) 16.089 ms 15.612 ms 15.509 ms
3 172.31.252.113 (172.31.252.113) 15.350 ms 15.805 ms 15.358 ms
4 pos6-0-0-agu-cr-1.mpls.enet.cu (172.31.253.197) 15.286 ms 14.832 ms 14.405 ms
5 172.31.252.29 (172.31.252.29) 13.734 ms 13.685 ms 14.485 ms
6 200.0.16.130 (200.0.16.130) 14.428 ms 11.393 ms 10.977 ms
7 200.0.16.74 (200.0.16.74) 10.738 ms 10.019 ms 10.326 ms
inetnum: 200.0.16/24
status: allocated
aut-num: N/A
owner: EMPRESA DE TELECOMUNICACIONES DE CUBA S.A. (IXP CUBA)
ownerid: CU-CUBA-LACNIC
responsible: Rafael L pez Guerra
address: Ave. Independencia y 19 Mayo, s/n,
address: 10600 - La Habana - CH
country: CU
phone: +53 7 574242 []
owner-c: JOQ
tech-c: JOQ
abuse-c: JEM52
inetrev: 200.0.16/24
nserver: NS1.NAP.ETECSA.NET
nsstat: 20160123 AA
nslastaa: 20160123
nserver: NS2.NAP.ETECSA.NET
nsstat: 20160123 AA
nslastaa: 20160123
created: 20030512
changed: 20140610
8 ix-11-3-1-0.tcore1.TNK-Toronto.as6453.net (64.86.33.45) 108.577 ms 108.449 ms 108.257 ms
traceroute to 192.168.134.138 (192.168.134.138), 30 hops max, 60 byte packets
1 192.168.134.138 (192.168.134.138) 6.027 ms 5.698 ms 5.596 ms
$ ip route
default via 10.156.41.1 dev wlan0 proto static metric 1024
10.156.41.0/24 dev wlan0 proto kernel scope link src 10.156.41.4
169.254.0.0/16 dev wlan0 scope link metric 1000
190.6.81.230
in the hotel.
Accessing http://1.1.1.1/ gives you a status page which allows you
to disconnect from the portal. It actually redirects you to
https://192.168.134.138/logout.user. That is also a
self-signed, but different certificate. That
certificate actually reveals the implication of Gemtek which is a
"world-leading provider of Wireless Broadband solutions, offering a
wide range of solutions from residential to business". It is somewhat
unclear if the implication of Gemtek here is deliberate or a
misconfiguration on the part of Cuban officials, especially since the
certificate is self-signed and was issued in 2002. It could be,
however, a trace of the supposed involvement of China in the
development of Cuba's networking systems, although Gemtek is based in
Taiwan, and not in the China mainland.
That IP, in turn, redirects you to the same portal but in a page that
shows you the statistics:
https://www.portal-wifi-temas.nauta.cu/?mac=0024D1717D18&script=logout.user&remain_time=00%3A55%3A52&session_time=00%3A04%3A08&username=151003576287&clientip=10.156.41.21&nasid=Wifi_Memories_Jibacoa&r=ac%2Fpopup
Notice how you see the MAC address of the machine in the URL
(randomized, this is not my MAC address), along
with the remaining time, session time, client IP and the Wifi access
point ESSID. There may be some potential in defrauding the session
time there, I haven't tested it directly.
Hitting Actualizar
redirects you back to the IP address, which
redirects you to the right URL on the portal. The "real" logout is at:
http://192.168.134.138/logout.user?cmd=logout
The login is performed against
https://www.portal-wifi-temas.nauta.cu/index.php?r=ac/login with a
referer of:
https://www.portal-wifi-temas.nauta.cu/?&nasid=Wifi_Memories_Jibacoa&nasip=192.168.134.138&clientip=10.156.41.21&mac=EC:55:F9:C5:F2:55&ourl=http%3a%2f%2fgoogle.ca%2f&sslport=443&lang=en-US%2cen%3bq%3d0.8&lanip=10.156.41.1
Again, notice the information revealed to the central portal.
Equipment and providers
I ran Nmap probes against both the captive portal and
the redirection host, in the hope of finding out how they were built
and if they could reveal the source of the equipment used.
The complete nmap probes are available in nmap, but it seems that
the captive portal is running some embedded device. It is confusing
because the probe for the captive portal responds as if it was the
gateway, which blurs even more the distinction between the hotel's
gateway and the captive portal. This raises the distinct possibility
that all access points are actually captive portal that authenticate
to another central server.
The nmap traces do show three distinct hosts however:
- the captive portal (
www.portal-wifi-temas.nauta.cu
, 190.6.81.230
)
- some redirection host (
192.168.134.138
)
- the hotel's gateway (
10.156.41.1
)
They do have distinct signatures so the above may be just me
misinterpreting traceroute and nmap results. Your comments may help in
clarifying the above.
Still, the three devices show up as running Linux, in
the two last cases versions between 2.4.21
and 2.4.31
. Now, to
find out which version of Linux it is running is way more challenging,
and it is possible it is just some custom Linux distribution. Indeed,
the webserver shows up as G4200.GSI.2.22.0155
and the SSH server is
running OpenSSH 3.0.2p1
, which is basically prehistoric (2002!)
which corroborates the idea that this is some Gemtek embedded device.
The fact that those devices are running 14 years old software should
be a concern to the people responsible for those networks. There is,
for example, a remote root vulnerability that affects that
specific version of OpenSSH, among
many other vulnerabilities.
A note on Nauta card's security
Finally, one can note that it is probably trivial to guess card
UIDs. All cards i have here start with the prefix 15100
, the
following digits being 3576
or 4595
, presumably depending on the
"batch" that was sent to different hotels, which seems to be batches
of 1000 cards. You can also correlate the UID with the date at which
the card was issued. For example, 15100357XXX
cards are all valid
until 19/03/2017, and 151004595XXX
cards are all valid until
23/03/2017. Here's the list of UIDs I have seen:
151004595313
151004595974
151003576287
151003576105
151003576097
The passwords, on the other hand, do seem fairly random (although my
sample size is small). Interestingly, those passwords are also 12
digits long, which is about as strong as a seven-letter password
(mixed uppercase and lowercase). If there are no rate-limiting
provisions on that captive portal, it could be possible to guess
those passwords, since you have free rein on accessing those
routers. Depending on the performance of the routers, you could be
lucky and find a working password for free...
Conclusion
Clearly, Internet access in Cuba needs to be modernized. We can
clearly see that Cuba years behind the rest of the Americas, if only
through the percentage of the population with internet access, or
download speeds. The existence of a centralized captive portal also
enables a huge surveillance potential that should be a concern for
any Cuban, or for that matter, anyone wishing to live in a free
society.
The answer, however, lies not in the liberalization of commerce and
opening the doors to the US companies and their own systems of
surveillance. It should be possible, and even desirable for Cubans to
establish their own neutral network, a proposal I have made in the
past even for
here in Qu bec. This
network could be used and improved by Cubans themselves, prioritizing
local communities that would establish their own infrastructure
according to their own needs. I have been impressed by this article
about the El Paquete system - it shows great innovation and
initiative from Cubans which are known for engaging in technology in a
creative way. This should be leveraged by letting Cubans do what they
want with their networks, not telling them what to do.
The best the Googles of this world can do to help Cuba is not to
colonize Cuba's technological landscape but to cleanup their own and
make their own tools more easily accessible and shareable offline. It
is something companies can do
right now, something I detailed in
a previous article.
www.portal-wifi-temas.nauta.cu
, 190.6.81.230
)192.168.134.138
)10.156.41.1
)15100
, the
following digits being 3576
or 4595
, presumably depending on the
"batch" that was sent to different hotels, which seems to be batches
of 1000 cards. You can also correlate the UID with the date at which
the card was issued. For example, 15100357XXX
cards are all valid
until 19/03/2017, and 151004595XXX
cards are all valid until
23/03/2017. Here's the list of UIDs I have seen:
151004595313
151004595974
151003576287
151003576105
151003576097
The passwords, on the other hand, do seem fairly random (although my
sample size is small). Interestingly, those passwords are also 12
digits long, which is about as strong as a seven-letter password
(mixed uppercase and lowercase). If there are no rate-limiting
provisions on that captive portal, it could be possible to guess
those passwords, since you have free rein on accessing those
routers. Depending on the performance of the routers, you could be
lucky and find a working password for free...