Autonomous Vehicles and the Hyperloop

Two innovations expected to become mainstream in the (very near) future have formed an unexpected union: hyperloop and autonomous vehicles. With the race towards the development of the perfect self-driving vehicle heating up, and the competition to create the most effective hyperloop transportation system also well under way, experts at Los Angeles based Hyperloop One (H1) have envisioned a way to marry the two technologies.

In 2012, Tesla CEO Elon Musk suggested a hyperloop be built instead of a bullet train system from San Francisco to Los Angeles. While Tesla has yet to pick up this project themselves, he suggested others get started. H1 is one of many companies that took that challenge—having completed their first public test in 2016, with a full system test planned in early 2017.

Hyperloops consists of large travel tubes and pods for passengers. The inside of the tube is kept at a near vacuum in order to allow for less resistance and higher speeds. Magnets within the tube propel the pods to their destinations. Pods essentially float on a cushion of air as they travels through the tube, which eliminates the need for wheels or tracks and results in very high speed transport. At approximately 760 mph, a bit faster than the maximum speed on a standard commercial jet, this means the six hour drive from San Francisco to Los Angeles would decrease to a mere 30 minutes.

H1’s unique approach doesn’t limit hyperloop technologies to its own vehicles. They want to allow autonomous vehicles and hyperloops to communicate in order to ensure a seamless transfer from road to tube. The logistics of how they plan for this to work however, have yet to be disclosed. One can speculate that due to the fact that present-day autonomous vehicles may not conform to aerodynamics necessary for tube travel, H1 could allow the vehicles to drive into a pod and then enter the tube. Or maybe autonomous vehicles of the future will look very different to traditional cars today, eliminating this problem altogether. 

A few hyperloop companies have stated that short passenger trips will become a reality sometime between 2018 and 2021. And by 2020, the number of autonomous vehicles on the road is expected exceed 10 million. These technologies are flourishing fast and quickly becoming a reality. 

Unfortunately, one factor holding back hyperloop development at the moment is the exorbitant costs associated with building it. Hopefully the more commonplace it becomes, and more competitors entering the space, will make this more feasible, or allow for the development of more economical alternatives. Or maybe autonomous vehicle makers will collaborate in making this a reality. Hopefully it’s all not just a pipe dream.

Learn More:
https://hyperloop-one.com
https://www.youtube.com/watch?v=fze5spdN3nU

Quantum-Resistant Cryptographic Algorithms

Despite the fact that the practical application of quantum cryptography is well over a decade away, the National Institute of Standards and Technology (NIST) has requested public input and proposals regarding the development of quantum-resistant cryptographic algorithms. 

For some context, while modern day computers pass and conceal information through the use of bits (1s and 0s - on and off respectively), quantum computers operate with qubits. Qubits antiquate current bit functionalities because they can exist on, off, or in both states simultaneously. This allows for the factoring of large numbers in far less time than a standard computer.

Because of this, current encryption algorithms that could take centuries to solve would become obsolete; for with quantum cryptography, the process is reduced to mere minutes. This would essentially overwhelm current encrypted communications—compromising and exposing significant amounts of critical data. And while the advancement of quantum computing is exciting and filled with much promise, if and when it does become mainstream, existing network infrastructures will need to be entirely reconfigured.

While fully functioning quantum systems are a distant reality, NIST recognizes the impending implications of something with such strength and the need for preventative and resistant cryptography. The goal is to ensure that all systems can defend against breach attempts—both standard and quantum—before it’s too late.

The research and development of quantum-resistant cryptographic algorithms will take years, with NIST’s initial deadline for submissions set for November 2017. Throughout the following three to five years, trials will take place in order to identify the proposal with most potential for practical use.

At first glance, it may seem like NIST’s request is a bit preemptive; however, one cannot fully understand or predict the performance of a system until it’s been tested in the wild. Unforeseen glitches and miscalculations could occur with catastrophic results. It is important to develop and test this technology before a nation state or malicious actor obtains the capability to exploit quantum cryptography—using it not as a shield, but as a weapon. While quantum cryptography has many hurdles to overcome, in many ways it is also stronger than current standards. The actual implementation of this technology, however, will likely not be without its difficulties. It will be interesting to observe NIST’s progress as this project transpires.

Learn More:
https://www.federalregister.gov/documents/2016/12/20/2016-30615/announcing-request-for-nominations-for-public-key-post-quantum-cryptographic-algorithms
https://en.wikipedia.org/wiki/Qubit

Custom Tor Hidden Services

Have you ever wondered how hidden services on Tor obtain their hostnames? This process is quite different from how websites are identified on the open web. If you’ve spent any time on the Tor network, you’ve probably noticed that the hostnames belonging to hidden services are somewhat unusual and difficult to remember (e.g: duskgytldkxiuqc6[.]onion). But if this is the standard, how do hidden services like facebookcorewwwi[.]onion obtain custom hostnames?

Taking a step back for some context, hidden services are akin to websites found on the open web, but instead of .com, .org, etc., the Top-Level Domain (TLD) for hidden services on Tor is .onion. Hidden services can only be accessed via a modified version of Firefox, which can be downloaded on the Tor Project’s website.

Spinning up a standard .onion hidden service is a pretty straightforward process: connect to Tor, set up a web server, add a couple lines of config (or uncomment/adjust them), and restart. Hostnames for these hidden services are automatically generated during this process, and are associated with the service’s private key. However, when the creator of a hidden service wants a custom hostname and/or key, the process is not as simple as heading over to GoDaddy.

There are a few tools available to aid in the creation of custom hidden service hostnames: Shallot, Eschalot, and Scallion being a few oniony examples. Shallot, originally named onionhash, was created in 2006. Its source was hosted by a few different Tor users before it ended up on GitHub in 2010. Shallot brute forces the SHA-1 hash in order to generate partial custom hostnames. It’s important to clarify that partial, not full, custom hostnames are generated because this process can take a very long time.

For example, on a 1.5Ghz processor, it will take less than a minute to generate a hostname with five or less custom characters. It takes approximately 30 minutes for six, one day for seven, 25 days for eight, all the way up to 2.6 million years for a 14-character custom hostname. This means that if Shallot was used to create Facebook’s hidden service, it potentially took 25 days to obtain the hostname facebookcorewwwi[.]onion—presuming the “core” and “wwwi” were incidental.

Eschalot, a fork of Shallot, also uses brute force and wordlists to generate partially custom hostnames. Eschalot compiles on Linux and Unix systems and is a bit faster than Shallot. Scallion, on the other hand, is much faster than Shallot, but requires a GPU for hashing.

The creation of custom hostnames can help ensure visitors are not misled. One fear associated with complicated hidden service names is that users can unknowingly be directed to spoofed sites. Partially custom hostnames however, are easier for humans to remember and help to discourage this. Either way, it’s important to pay attention to the sites you visit. Exercising caution is key on both the open and (especially) the dark web.

Learn More:
https://www.torproject.org/docs/tor-hidden-service.html.en
https://github.com/katmagic/shallot
https://github.com/reclaimyourprivacy/eschalot
https://github.com/lachesis/scallion

Tor to Enhance Hidden Service Security

While it’s unwise to consider any form of online communication completely anonymous, the Tor network offers great alternatives for users seeking more online privacy. Websites residing on the network are known as hidden services. Currently—and despite the name—hidden services are not entirely unseen. In order to function, they need to be advertised within the network itself.

Nodes (also known as relays) are randomly chosen by newly created hidden services in order to create a circuit. Public keys are shared and circuits are assembled. From here the nodes function as introduction points for other connections, and through the use of public keys, aid in obfuscating IP addresses associated with hidden services, as well as bolstering privacy for users.

These introduction points exist within what are known as Hidden Service Directories (HSDirs). HSDirs make up a distributed database used to discretely connect users with hidden services through exchange of addresses and public keys. However, this configuration unfortunately comes with the potential to put users at risk for correlation attacks.

Later this year, the Tor Project plans to enhance privacy with the introduction of additional security to its hidden services. The number of characters within a standard hidden service hostname will increase from 16 to 50, and stronger encryption will be implemented through a switch from 1024-bit RSA to ED-25519 keys. While both options are undoubtedly substantial, ED-25519—despite its shorter public key—is slightly more difficult to crack than RSA because its elliptical curve yields more security per bit.

This change will also allow hidden services to share a unique cryptographic key with HSDirs instead of their addresses, thus preventing malicious HSDir nodes from snooping, crawling, and identifying new or secret sites. This will also make it more difficult to harvest HSDirs, keeping users from obtaining addresses they aren’t already familiar with or from going places where haven’t been invited.

Any volunteer can easily configure a node on the Tor network—this also includes people or agencies interested in spying on dark web traffic. Nodes can also be setup with an HSDir flag and route traffic to hidden services, and through this, can be used to crawl sites and discover new ones. And while some methods are already in place to increase hidden service security, they tend to be complex and somewhat arduous. These enhancements will make this level of security more attainable for all users.

Just like any other aspect of technology, a hidden service is only as secure as its weakest link. This link can vary from the person running it to the configurations of its web server. However, the security improvements, which will be carried out later this year, will aid in strengthening privacy on Tor, with little to no effort from the users themselves. Despite these upgrades however, there is no perfect system and other aspects of the Tor network can still be manipulated. Users and those running hidden services should remain cognizant of this.

Learn More:
https://www.torproject.org/docs/hidden-services
https://ed25519.cr.yp.to

Signal: Encrypted Communication

As the focus on security becomes more mainstream, chat application developers are racing to implement end-to-end encryption to keep up with competition and better guarantee user privacy. And while not all promise the same level of security, one application in particular is making great strides within this domain.

Signal, developed by San Francisco-based Open Whisper Systems, is the current darling of the cryptography world. It is endorsed by a broad spectrum of people and organizations ranging from security expert Bruce Schneier, to the infamous Edward Snowden, to the (post-DNC leak) 2016 Clinton presidential campaign. And despite it being less than three years-old, the Signal protocol is leading the way forward for encrypted communications.

The Signal application allows users to easily communicate with text, media, or voice calls—all protected from eavesdropping, as a result of the renowned Signal encryption protocol. Unlike some of its competitors, Signal is open-source and offers reproducible builds for Android. This allows for peace of mind, making malicious behavior such as man-in-the-middle attacks and malware injection considerably more difficult to execute.

While some companies are busy developing their own encryption standards (such as iMessage, Viber, and Wickr), Facebook Messenger, Google Allo, and WhatsApp have integrated the Signal encryption protocol into their own systems. However, despite this, they are not considered as trustworthy or secure as Signal itself. Unlike the Signal application, these applications are closed-source and security settings can often be manipulated by the user. In fact, just days ago, Signal was in the news as a result of flawed research directed at WhatsApp, purporting a cryptographic defect, which turned out to be not only an overstatement, but not news at all to the security community.

In addition to integrating their technology and protecting users throughout the world, Open Whisper Systems also stresses the importance of privacy for users affected by government censorship. Just days after the Egyptian government blocked Signal in mid-December, the company implemented a workaround known as domain fronting to its Android application (iOS update coming soon). Domain fronting masks Signal’s encrypted traffic, causing it to appear as a standard Google search. It also relies on Google and major Content Delivery Networks (CDNs); therefore at this point, an attempt by Egypt to block smaller services employing domain fronting, would either depend on the involvement of the larger ones, or an entire internet shutdown (again).

While it would be naive to believe there is a perfect solution to security and anonymity, Signal is revolutionizing this effort and can be considered one of the most trustworthy digital communication mechanisms to date. Users should still exercise caution with any form of internet or network communications, as this industry moves and changes rapidly, and one can never truly predict where or when the next obstacle or vulnerability may appear.

Learn More:
https://whispersystems.org/blog/reproducible-android
https://www.eff.org/node/82654
https://www.theverge.com/2017/1/13/14266632/whatsapps-backdoor-vulnerability-key-reset-signal
https://www.securityweek.com/signal-uses-domain-fronting-bypass-censorship

Google Hacking aka Google Dorking

Some hackers choose their victims for personal or political reasons, others take an approach that’s a bit less personal. Changing directions a bit, here’s a fun fact: while Google processes over 40,000 search queries every second, and not all are created equal. So, what exactly does that mean and how are these two things related? What does hacking have to do with a Google search?

While it may seem like there’s only one way to perform a search query, in 2002 a security expert named Johnny Long began to explore a more advanced search technique called Google Hacking. Google Hacking—also known as Google Dorking, in reference to those whose devices and vulnerabilities are unearthed through it—is a unique way of utilizing search operators to obtain results such as web server specifics, sites affected by vulnerabilities, login credentials, Personally Identifiable Information (PII), and even financial data.

So, instead of targeting a particular person, government, or corporation, an attacker can use these operators to find several targets, all suffering from the same vulnerability. Unfortunately, many servers are still operating on outdated standards, which puts them at risk. For example, entering the following string returns results of web servers still running one of the versions of SSL vulnerable to Heartbleed:

"OpenSSL" AND "1.0.1c Server at".

Exploit DB has integrated Long’s Google Hacking Database (GHDB) into their own site. From here, thousands examples of these search operators can be found. Results can be used to develop a list of targets vulnerable to specific exploits, for information theft, intelligence or espionage, or even cyber terrorism. However, while it may seem that the GHDB exists solely for the purpose of malicious behavior, security researchers and pen testers make use of it for exploit analysis and investigation.

Google hacking is also not just limited to available content. Users can tap into Google’s cache and access exposed data without ever touching the vulnerable server. Google’s search console (linked below) can assist in removing any cached content that should no longer be indexed.

Attackers don’t need fancy tools like those found in Kali or even an engine devoted to finding vulnerabilities, such as Shodan. They don’t need sophisticated or expensive tools and they don’t need a lot of expertise. All the information they need is just one Google search away.

Learn More:
https://www.internetlivestats.com/google-search-statistics
https://en.wikipedia.org/wiki/Johnny_Long
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-0160
https://www.exploit-db.com/google-hacking-database
https://www.google.com/webmasters/tools/removals

Malvertising and Router Malware

Malware is constantly evolving to be better, stronger, and faster. It is no longer limited to personal computers, but can spread throughout networks and to networking devices, as well. Zero days appear on everything from IoT and mobile devices to powerful commercial grade routers; yet somehow, many of us (including vendors themselves) seem to take security on our home networking devices for granted. 

Creating strong SSID credentials is a good first step, but in the end, will only prevent some attacks. After all, while home routers face a multitude of threats, one in particular can easily go undetected. And in the end, routers are affected in a way that most users may not notice: their DNS gets hijacked. 

DNS hijacking malware can easily be obtained via malicious downloads or websites, code that has been injected into a legitimate website, or even from malicious advertisments (malvertising) found on legitimate sites. If DNS settings on a home router have been manipulated, attackers have the ability to redirect web traffic, strip SSL, prevent software updates, carry out man-in-the-middle attacks, steal sensitive information, and much more. Even worse, a user who is not keen to notice something like a missing “https” from the address bar, may be fooled into entering sensitive information into forms which they believe are trusted websites.

Not unlike strengthening your SSID credentials, your router’s admin login credentials should also be changed. These are a separate set of credentials and it’s important to ensure that both have been updated. After all, there are entire lists of default credentials all over the internet, so it isn’t difficult for an attacker to deduce how to gain admin access to your device once the network has been infected. Herein lies a major part of the problem.

Check your manufacturer’s documentation on how and where to access the DNS configuration panel on your home router. Once you’ve gained access to the panel, it is likely that, unless it’s been manually configured, your DNS entries will be empty. If you see an entry you don’t recognize, conduct some research on the IP. If you still feel as if something may be awry, run a virus scan on your computer(s) and restore your router to factory defaults. 

Following preventative measures is also useful. First, ensure your firmware is up-to-date. Upon login, many control panels will alert the user that their device is in need of an update. Also, ensure this panel is not easily accessible from outside your network. If this is necessary, ensure that communications are encrypted. This is not necessary for most users however, and should be disabled.

If possible, regular panel logins could be useful for the prevention of malicious DNS and other router-based attack vectors. It is better to be safe than sorry, and in the end, anyone can fall victim to something like malvertising.

Learn More:
http://www.routerpasswords.com