Recent research was presented[1] raising security and privacy concerns around URL shortening services like bit.ly, goo.gl, and others.  The services are used to shorten lengthy URL’s to more compatible URLs suitable for online use.  Smaller URLs also provide ancillary benefit since they are easier to remember.  My first impression was the recent research[1] on URL shorteners was that it was specious since URL shortening was never intended or designed as a security and privacy control from the start.  Reading the research softened my initial opinion.  The seeming randomness of these short URLs provides the public unfounded confidence of their utility for security.  Specifically, the false idea that others will not discover the link since it appears secure – difficult to guess.  Unfortunately, the part of the URI providing the identity for the long URL, is as few a 6-characters for some shortening services, far too small a space to be cryptographically secure, and easily brute forceable by attackers and demonstrated by researchers.

The research paper was not the first cracks in the short URL armor.  The following presents some concerns I gathered across different resources from other researchers.  I also share some personal thoughts about short URL weaknesses that I have not noticed elsewhere.  I don’t stake any claim to these and I’m simply passing them along to raise awareness.  I’m betting we have not seen the last around security and privacy concerns with short URLs.

1) Short URLs not secure
As researchers mention[1] these links are not secure and easily brute forced.  This may or may not be a concern for you depending on how you use them.

2) Short URLs target host unknown until clicked
Phishing is a problem for everyone.  Short URLs exacerbate an already bad email phishing problem.  There are some services like checkshorturl.com where email users can unwind these URLs but most people will never do this.  People are trusting and verification takes extra work.  Clicking a shortened URL is like hitchhiking in a strangers car, you don’t know where it’s taking you.

3) Obfuscated redirects
Brian Krebs makes an interesting point[3], attackers can leverage an open redirect on a government host and create a short branded URL.  The result is an authentic URL that looks like it navigates to a government web site but instead navigates to the attackers malware site.

This URL
http://dss.sd.gov/scripts/programredirect.asp?url=http://krebsonsecurity.com

Becomes this branded URL (notice the .gov domain, ouch!)
http://1.usa.gov/1pwtneQ.

The combination of an open redirect and short URL branding creates a situation of misplaced trust or false sense of security.  Users think clicking will take them to a government site when if fact it takes them to another site entirely.  The moral of the tale, if you have any open redirects in your web site your in trouble but if you also use branded URL shorteners your setting the public up for malware and phishing attacks.

4) Obfuscate payloads
A spin on Krebs idea I considered is that any arbitrary payload can be saved in a long URL by attackers and hidden from prying eyes – a payload.  For example, on some services it’s possible to create arbitrary URLs with invalid hosts and parameters so long as those URLs are syntactically correct.  Meaning if I create a URL https://www.xyz.com/def some shortening services are not checking to ensure host xyz is a valid host.  Even if the host is valid, URI parameters may be developed that legitimate hosts ignore entirely like the following, https://www.xyz.com/def?a=b,b=c.  Some servers like Blogger ignore superfluous parameters like a=b,b=c in the request if you pass them.  Attackers can create any URL they want.  I used the following in a quick test,

http://www.xx100kaass.com/0 (x10,000 zeros, for a 10k URL)

I created a bogus URL with a 10KB URI that consisted of a slash (/) followed by 10,000 zeros and was successful.  Attackers can store payloads in these bogus URLs to use for a variety of purposes.  Outside of validating the syntax and host, shortening services have no idea of knowing if these URIs are valid and, in their defense, there’s probably not a good way for them to validate.  Therefore, they must store the entire long URL.  This means an attacker can use URL shortening services, to hide small chunks of arbitrary data for nefarious purposes like command and control for bot networks, torrent information, etc.  URL shortening sites undoubtably provide security intrusion and content controls.  There’s likely some limits in size or number of URL per second they will accept, etc.  I’m not sure what they are but it’s likely they vary between shortening services.

5) Multiple indirection
Some of the URL shorting services will not accept their own URLs for a long URL but at least a few of them will accept shorted URLs of other services.  Therefore it’s possible to create multiple levels of indirection. short URLs referring to other short URLs.  How many levels can be created?  I’m not sure.  It seems like browsers must have some practical level of redirect control but I have no idea.  I’m not sure if this serves a practical purpose yet but at the very least it complicates organizational IT forensics.

6) Infinite loops
I was wondering if I could create two or more short URLs referring to each other.  To get this to working requires an understanding of the shortening algorithm such that the attacker can determine the shortened URI before it’s created.  Or perhaps a shortening services that allows changing a long URL after the short URL has been created.  This will allow an attacker to create short URLs that either directly or indirectly refer to each other.  I didn’t spend much time looking at this.  I tried to find some code online to see if there were any standard algorithms.  I was thinking everyone may be leveraging an open source project so I could determine the algorithm easily.  Nothing was obvious, I was not successful.  Perhaps someone else may want to take this up.  I’m not sure if the browser is smart enough to detect these types of infinite redirects or not.  If not, it seems plausible it could be used to hang or crash the browser.  Even if possible, I’m not sure this has any practical value for attackers anyway.

7) XSS in URLs
I tried to see if I could get JavaScript inside a long URL and then shorten it to bypass browser security controls.  No success.  I tried using the javascript URI scheme type.  Some URL shorteners allowed it but at least Chrome and Safari were smart enough to handle the redirects as a html scheme type regardless of the scheme type I provided.  I also tried the data scheme type with no positive result.  Data works when pasted directly into the browser URL bar but not successful as a redirect.  Again handled like html scheme type regardless of the specified scheme.  Browsers are a battle hardened environment, good news for us.

8) Shortener Service Unavailability
If the shortening services goes away temporarily or permanently it impacts the services anywhere shortened links are embedded.  What happens to Twitter if bit.ly goes away?  Not good.  DDOSing bit.ly is essentially the same as DDOSing Twitter since a better part of Twitters content would be unreachable for users if bit.ly cannot respond.  Bit.do has a big list of shortening services[2].  Bit.do also tracks shortening services no longer available and there’s many more of them I was aware.  If shortening is part of your business strategy, or your users are using it, you may want to consider all your available options and weight risks, reliable services, hosting your own, etc.

Keep in mind my tests were not comprehensive and exhaustive.  I didn’t want to do anything that could be considered offensive.  So if noted a test was successful it may not be successful across all services.  Conversely if a test was unsuccessful if may not be unsuccessful everywhere.  An important consideration, while there are some problems with URL shorteners there’s not a good immediate option for avoiding them.  If your going to participate in social media your going to be using short URLs like it or not until improvements are made.

[1] Gone in Six Characters: Short URLs Considered Harmful for Cloud Services
[2] Bit,do list of URL Shorteners
[3] Spammers Abusing Trust in US .Gov Domains

* Landminds image from World Nomads

CNBC: Execs We’re Not Responsible for Cybersecurity, “…executives like CEOs and CIOs, and even board members — didn’t feel personally responsible for cybersecurity or protecting the customer data…” (Twitter: @ArigatoDamato)

Video: Execs We’re Not Responsible for Cybersecurity

Laws and regulations have not kept pace with growth of Internet technologies.  No clear expectations have been communicated to the software industry or users of these services by policy makers.  Executives have responsibility for protecting customer data but enforcement remains selective.  In the most egregious incidents, top C-level execs have been terminated for poor cybersecurity (e.g., Target).

First things first, what hell is Internet of Things (IoT)?  Very simply, the IoT movement intends to connect a wide
variety of electronics, embedded devices, and sensors to the Internet.  As practical example, some makers of city street lights have Internet enabled their bulbs.  On the surface, Internet lightbulbs appear as useful as Internet connected refrigerators but a distinct advantage is that these bulbs will alert a central office when replacement is necessary.  In a city with hundreds, or thousands of street lights, a proactive message of an inoperable light eliminates significant effort driving around to check bulbs.  Even in the mundane case of the refrigerator, if Internet enabled, new water filters could be ordered before needed saving homeowners some trouble.
ADS-B.jpg
Photo: Raspberry Pi RLT-SDR receiver

What can you do with a RLT-SDR receiver, dump1090 software, and a Raspberry PI?  Easy, you can capture data like flight numbers, altitude, speed, and position information from ADS-B equipped aircraft in your area.

Ever since I was a kid I always enjoyed listening to my Grandfather’s shortwave radio.  Every twist of the tuner knob would produce a new discovery, aircraft, beeps and bleeps of Morse Code, far away news broadcasts.  Now I’m much older and technology has matured but so have my skills.  Now I have I have a Raspberry Pi, RLT-SDR, and know how to program (which means I’m dangerous).

Awhile back I built a Raspberry Pi project with a 2.8″ display from Adafruit.  I also purchased a low cost RLT-SDR receiver at DEFCON 22.  Shortly after I built my Pi project I could not make up my mind what I wanted to do with it so it sat on my shelf collecting dust.  Same goes with the SDR receiver after I returned from DEFCON.  That is until yesterday evening when I had the bright idea to put the Pi and SDR receiver together and make it do something useful.  Around the time I was searching for more information on Internet to get SDR going on Raspberian I discovered some information about ADS-B.  ADS-B equipped aircraft transmit telemetry on 1090mhz and within my SDR receivers bandwidth.  You can learn more about ADS-B on RLT-SDR.com.  I still learning myself so I don’t have a good idea where ADS-B fits into aircraft management just yet but ADS-B is definitely interesting technology.

Untitled%2B2014-08-27%2B16-10-12%2B2014-08-27%2B16-11-14.png
Photo: FlightRadar24.com

As you can see in the picture of my Raspberry Pi screen photo (first photo), various information about aircraft flying in my area are presented near my home.  I had no idea if this information was accurate so to verify I opened FlightRadar24 in my web browser (2nd photo on right).  The results were accurate although I only receive a fraction of the plans arriving or departing from San Francisco, Oakland, San Jose, and Sacramento.  I’m still not sure what the negative longitude is just yet.  In any case, I noticed that I receive telemetry from some aircraft almost 100 miles away with a 4″ antenna – wow!  Other aircraft passing over the mountains near my home would drop off my display and to be expected since mountains interfere with radio signals.  I was very impressed with the unit I purchased at DEFCON from Hacker Warehouse and at $20US there’s no reason not to experiment.  I noticed at the conference Hacker Warehouse sold a larger microwave antennas at the conference as well as directional antennas which would be interesting to experiment with.

The software package on the Raspberry Pi that makes detecting ADS-B transmissions possible is dump1090.  Dump1090 is used to tune your RLT-SDR radio and receive the ADS-B.  If you want to get dump1090 running on your Pi I then recommend reading Ferran Casanovas blog.  Following are the command line options for dump1090 so you can get some idea for what it does.

pi@raspberrypi ~/dump1090 $ ./dump1090 –help
—————————————————————————–
|                        dump1090 ModeS Receiver         Ver : 1.09.0608.14 |
—————————————————————————–
–device-index <index>   Select RTL device (default: 0)
–gain <db>              Set gain (default: max gain. Use -10 for auto-gain)
–enable-agc             Enable the Automatic Gain Control (default: off)
–freq <hz>              Set frequency (default: 1090 Mhz)
–ifile <filename>       Read data from file (use ‘-‘ for stdin)
–interactive            Interactive mode refreshing data on screen
–interactive-rows <num> Max number of rows in interactive mode (default: 15)
–interactive-ttl <sec>  Remove from list if idle for <sec> (default: 60)
–interactive-rtl1090    Display flight table in RTL1090 format
–raw                    Show only messages hex values
–net                    Enable networking
–modeac                 Enable decoding of SSR Modes 3/A & 3/C
–net-beast              TCP raw output in Beast binary format
–net-only               Enable just networking, no RTL device or file used
–net-http-port <port>   HTTP server port (default: 8080)
–net-ri-port <port>     TCP raw input listen port  (default: 30001)
–net-ro-port <port>     TCP raw output listen port (default: 30002)
–net-sbs-port <port>    TCP BaseStation output listen port (default: 30003)
–net-bi-port <port>     TCP Beast input listen port  (default: 30004)
–net-bo-port <port>     TCP Beast output listen port (default: 30005)
–net-ro-size <size>     TCP raw output minimum size (default: 0)
–net-ro-rate <rate>     TCP raw output memory flush rate (default: 0)
–net-heartbeat <rate>   TCP heartbeat rate in seconds (default: 60 sec; 0 to disable)
–net-buffer <n>         TCP buffer size 64Kb * (2^n) (default: n=0, 64Kb)
–lat <latitude>         Reference/receiver latitude for surface posn (opt)
–lon <longitude>        Reference/receiver longitude for surface posn (opt)
–fix                    Enable single-bits error correction using CRC
–no-fix                 Disable single-bits error correction using CRC
–no-crc-check           Disable messages with broken CRC (discouraged)
–phase-enhance          Enable phase enhancement
–aggressive             More CPU for more messages (two bits fixes, …)
–mlat                   display raw messages in Beast ascii mode
–stats                  With –ifile print stats at exit. No other output
–onlyaddr               Show only ICAO addresses (testing purposes)
–metric                 Use metric units (meters, km/h, …)
–snip <level>           Strip IQ file removing samples < level
–debug <flags>          Debug mode (verbose), see README for details
–quiet                  Disable output to stdout. Use for daemon applications
–ppm <error>            Set receiver error in parts per million (default 0)
–help                   Show this help
 
Debug mode flags: d = Log frames decoded with errors
                  D = Log frames decoded with zero errors
                  c = Log frames with bad CRC
                  C = Log frames with good CRC
                  p = Log frames with bad preamble
                  n = Log network debugging info
                  j = Log frames to frames.js, loadable by debug.html

My experience with dump1090 was excellent.  The output is more or less what is shown on my Pi photo (first photo).  I say, more or less, since I made some changes to the program for my smaller display on my Pi.  The problem I had on my 2.8″ screen was that the lines would wrap around past the edge of the screen and into the next line.  All the information was on the screen but it was hard to read in –interactive mode.  To get the Pi display cleaned up I was thinking I could find a command line option and then grep something together for a cleaner display.  Unfortunately, I didn’t notice any easy way to do this.  As a workaround, I made some changes to the program to shorten the output to only the fields of interest within interactive.c.  The code is customized for the 2.8″ PiTFT Mini Kit at Adafruit.  After apply the changes, I recompiled dump1090 and output was shortened to fit my display as I expected.  Next, I made some changes to force the Pi to login automatically and start the dump1090 program running.  I know, not very secure but I don’t have any data on this device.  For now, I just used the default account on the Pi but it would be more secure if I created a new account with less privilege.  Anyway, I was lazy and wanted to get this thing finished before I went to bed so I improvised.

b747-8i_lufthansa_02.jpgOne final thought I have rolling around inside my head, since my profession is application security, is that ADS-B does not seem very secure.  ADS-B telemetry is sent from aircraft real-time in route completely unencrypted so far as I know.  I wonder what would happen if an ADS-B transmitter was built and launched in a ballon or drone by an adversary?  It seems possible for adversaries to fake flight numbers, altitude, air speed, and position at a minimum.  Transmitting on ADS-B band is more than likely highly illegal but then again adversaries give little regard to laws.  I hope critical air traffic management systems don’t use these signals for routing traffic but I really have no idea.  If anyone is an ADS-B expert and would like to post a comment to educate readers please do.  I’m a noob in this area.

Update March 4, 2015, I have since learned other security researchers consider insecure ADS-B a security safety problem, Air Traffic Control Systems Vulnerabilities Could Make for Unfriendly Skies [Black Hat].  Apparently the Government Accountability Office (GAO) is recommending improvements, FAA Must Address Cyber-Security of Air Traffic Control Systems: GAO.

Update April 22, 2015, I discovered a presentation on the ADS-B at a security conference about 2 years ago, “DEFCON 20: Hacker + Airplanes = No Good Can Come Of This“.  The presentation is provided by Brad Haines, Render Man(@iheckedwhat).  Render Man goes a step further to demonstration ADS-B spoofing and does a simulated pass by an airport tower.  The radio transmissions were terminated into a dummy load so no danger of harming any real aircraft.  According to Render Man, FAA representatives where attending his conference session.

Update May 1, 2015, FAA’s answer to aging air traffic infrastructure is NextGen.  Apparently, NextGen is falling short of expectations.  A little digging on NextGen reveals it’s not the deep overhaul expected but more of tune-up.  In fact, NextGen still includes proven insecure technologies like ADS-B.  Unfortunately, the FAA efforts seem to focus on efficiency and safety as opposed to security which is a distinctly different challenge.  FAA continues to press forward with NextGen even after debate on public research and the GAO report noting security concerns.  The price tag for NextGen is around $40 billion but a complete overhaul would likely cost far more.  New infrastructure or sharing military infrastructure may be required to develop a secure solution since foundational technologies like GPS were proven insecure long ago.