A recent blog post from Microsoft Threat Intelligence shed light on a critical vulnerability stemming from publicly disclosed ASP.NET machine keys. These keys protect ViewState data’s integrity and confidentiality but can be compromised if developers inadvertently include them in their applications by copy-pasting from public sources.

ViewState, for those unfamiliar, is a mechanism in ASP.NET WebForms that preserves the state of a web page across postbacks. It’s essentially a hidden field that stores encoded and optionally encrypted data. The security of ViewState hinges on the machine keys – the ValidationKey for ensuring data integrity and the DecryptionKey for protecting sensitive information.

Imagine ViewState as a locked vault containing your application’s secrets. The machine keys are the combination of that vault. Now, picture a scenario where that combination is freely available on the internet, just waiting for a malicious actor to use it. That’s the danger of using publicly disclosed keys.

When a threat actor gets these keys, they can craft a malicious ViewState payload and send it to your application. ASP.NET, trusting the keys, will decrypt and validate the payload, inadvertently executing the attacker’s code. It’s like giving a burglar the keys to your house and inviting them in for coffee.

The consequences can be severe. In the incident described by Microsoft, an attacker used a publicly known machine key to perform a ViewState code injection attack, eventually deploying the Godzilla post-exploitation framework. This gave them remote code execution capabilities on the compromised IIS web server.

So, what can we, as developers, do to prevent such attacks? The most crucial step is to treat machine keys as the sensitive secrets they are. Never use keys from public sources or default values. Always generate your keys securely. It’s also good practice to rotate your keys regularly, adding an extra layer of protection.

In ASP.NET, you can set the machine keys in the web.config file using the element. However, a more secure approach is to encrypt sensitive sections of your configuration, ensuring that keys are never stored in plain text on the file system.

Upgrading to ASP.NET 4.8 is also recommended, as it enables advanced security features like the Antimalware Scan Interface (AMSI). Hardening your servers with attack surface reduction rules, such as blocking webshell creation, further enhances your defenses.

The key (pun intended) takeaway here is that security isn’t a one-time checkbox. It’s a continuous process of vigilance, best practices, and staying informed about emerging threats. The convenience of copy-paste can be tempting, but it’s not worth risking the integrity of your application and the trust of your users.

As web developers, we hold a great responsibility. The applications we build are not just lines of code; they are digital fortresses safeguarding valuable data. It’s up to us to ensure that the keys to those fortresses remain secure.

Stay safe out there, fellow developers. And remember, a little extra caution and much less Ctrl+C and Ctrl+V can go a long way in keeping your ASP.NET applications secure.

See if you’re environment is compromised by running this Powershell script

Why? In the mindset of a developer, its priorities are two things at the start of their day:

Write new code for a new story
or
Fix critical bugs

Unfortunately, the latter point does not include the vulnerabilities found from the security tests we, as security professionals, executed. The business value takes precedence over these discoveries without realizing that the risk that these security flaws pose will eventually bring the business value down.

A balance that a wise developer must consider if one ever reaches that epiphany.

The solution? Change the term. Talk more about “security bugs” than “vulnerabilities.” because to a developer, fixing bugs is second nature.

In my book “ASP.NET Core 5 Secure Coding Cookbook: Practical recipes for tackling vulnerabilities in your ASP.NET web applications“, I use the term “security bug” more often than I should. The book talks directly to the developer psyche, with the step-by-step telling of how you can fix a security flaw in code.

So I say, grab my book and again, change the conversation.

Let the “ASP.NET Core 5 Secure Coding Cookbook” guide your ASP.NET developer to better ways to solve a security problem.

I often hear that corporate LOB internal applications are secure because they have a robust authentication system, insisting that no one nefarious will be granted access. That they have a “rigorous” verification process of creating user accounts. I also hear people say they’re behind a sophisticated firewall and that attacks to applications will not succeed. While these statements are in its truest sense (at least in the context of network and not application security), there are other ways to circumvent this, and an attacker can think maliciously of different means and sources to get access to these systems.

Security platforms can’t wholly protect applications against a disgruntled employee, insider threats, social engineering, and open-source intelligence. Once the authentication is bypassed, what else is there to protect your app from cross-site scripting, SQL injection, and insecure deserialization attacks unless you have done your share of writing secure code?

Protection should come in layers. Attacks come in many forms and are not made in one step alone. Reducing the number of opportunities will prevent hackers from infiltrating into our system. It’s time to change our mindset about security. Let’s all be more defensive.

Logging and monitoring help answer all of these fundamentally asked questions. It provides context merely to identify malicious activities that allow more in-depth incident analysis. Logging failed authentication, sensitive transactions, privilege escalation, access control, and server-side input validation are beneficial in establishing proactive response to threats and risks. Clear audit trails are great tools for investigating and resolving exploitations.

Risk = Likelihood * Impact

There are plenty of methodologies out there and to gauge likelihood, here are points to consider:

1. The reliability of the exploit leaving such attacks undetected by our defensive security systems
2. The required high-level or specialized skill to exploit the vulnerability
3. The availability of kits that can ease up attack automation
4. Necessitate permissions to carry out the successful malicious payload

The “Sec” in DevSecOps is foreign and unusual to some. A new concept certainly and if not done correctly can slow the whole pipeline down. This is where the accuracy of the tool and the correctness of the configuration becomes essential to a true DevSecOps implementation. We do not simply run the tool and do a fire-and-forget. We tweak and optimize to make it useful for its purposes.

Not all tools are created equal though. For longer running application security tests the best practice is to change the frequency of execution as cadence. It should never break the build. Making adjustments in the tests are key. After all, DevSecOps is all about being agile.

As we adopt the new DevOps let’s also look at the security features of our applications. DevSecOps is here to stay and so is Continuous Application Security Testing.

Code is one resource that can be difficult to secure. If not written properly, can result in a tedious task of reviewing for security flaws, slows down the performance of static analysis and can result in repetitive remediation in multiple places of the codebase. Clean code is a path to secure code.

Let’s make our code more readable too. After all, codes are written for people to read.

What form of implementation could one possibly apply to force an app to fail safely and securely? For one, a developer can start to send users to default and generic error message when these exceptions occur. Prevent the system from divulging sensitive information like stack traces, code file paths or even the name of the stored procedure that failed to execute!

Sanitization is around changing input values. It’s a way to manipulate illegal characters, so they are replaced (or stripped off) making sure it is safe for our apps to process. It steers us off from the occurrence of data being interpreted as code and breaking it out of its contextual form.

“Validation or Sanitization?” is not a chicken or egg question. It is a chicken and egg answer. You need both in making your apps secure.

What you probably don’t know is that its possible websites can use crypto miner scripts; scripts that run in-browser and utilize CPU power collectively and massively from visitors to mine cryptocurrencies.

If these crypto-mining scripts are not in any way referenced in your web applications, then your web apps are free from helping someone “mine” cryptocurrencies. Beware though, crypto jacking can occur, and someone might be getting crypto rich – at your company’s expense.

In one incident, hackers were able to alter a javascript file hosted by an Assistive Technology provider used in US government websites like the US Court. This modified javascript library injected the mining script until it was discovered late by the provider hours later.

As they always say, prevention is better than cure, so the way to counter this threat in one way is for web developers to implement Content Security Policy.