Fix failing versions, specify version explicitly

[jjarmoc]

Two changes to cisco_asa_extrabacon.rb module:

• Fixed failure on some ASA versions due to lack of MIB support.
• Added ability to (optionally) specify an ASA version instead of querying.

I've confirmed msftidy comes back clean.

I'll describe each of these changes below in greater detail.

Fixed failure on some ASA versions due to lack of MIB support.

Some versions of ASA fail due to an inability to detect the version. I first noticed this on ASA 8.2(4) which returns:

msf auxiliary(cisco_asa_extrabacon) > check

[!] Received Cisco ASA version noSuchInstance, but no payload available
msf auxiliary(cisco_asa_extrabacon) >

This is due to a lack of response for Cisco specific MIBs on this target. Specifically, OID '1.3.6.1.2.1.47.1.1.1.1.10.1'. According to this link this occurs on non-admin contexts. My test target was only single context, so there must another cause, but it's unfortunate for the module to fail despite a vulnerable version and known offsets.

snmpwalk -v 2c -c <community> <ip> 1.3.6.1.2.1.47.1.1.1.1.10.1 returns:

iso.3.6.1.2.1.47.1.1.1.1.10.1 = No Such Instance currently exists at this OID

We can use OID '1.3.6.1.2.1.1.1.0' this is from MIB-2 and much more widely supported. (The original EXTRABACON code used this OID as well)

snmpwalk -v 2c -c <community> <ip> 1.3.6.1.2.1.1.1.0 returns:

iso.3.6.1.2.1.1.1.0 = STRING: "Cisco Adaptive Security Appliance Version 8.4(2)"

I've modified this module such that it falls back to MIB-2's SysDescr OID when the existing OID fails.
With this change, my 8.4(2) box is successfully detected, and the exploit succeeds.

msf auxiliary(cisco_asa_extrabacon) > check

[+] Payload for Cisco ASA version 8.4(2) available!
[*] 192.168.x.y:161 The target appears to be vulnerable.
msf auxiliary(cisco_asa_extrabacon) > exploit

[*] Building pass-enable payload for version 8.4(2)...
[*] Sending SNMP payload...
[+] Clean return detected!
[*] Auxiliary module execution completed
msf auxiliary(cisco_asa_extrabacon) > 

Added ability to (optionally) specify an ASA version instead of querying.

Pretty self explanatory. An 'ASAVER' OptEnum allows specifying any of the supported versions. If set, that will be used instead of sending a fingerprinting SNMP request. If unset, the module fingerprints by querying SNMP as before.

msf > use auxiliary/admin/cisco/cisco_asa_extrabacon 
msf auxiliary(cisco_asa_extrabacon) > options

Module options (auxiliary/admin/cisco/cisco_asa_extrabacon):

   Name       Current Setting  Required  Description
   ----       ---------------  --------  -----------
   ASAVER                      no        Target ASA version (unset to autodetect) (Accepted: , 9.2(4)13, 9.2(4), 9.2(3), 9.2(2)8, 9.2(1), 9.1(1)4, 9.0(1), 8.4(7), 8.4(6)5, 8.4(4)9, 8.4(4)5, 8.4(4)3, 8.4(4)1, 8.4(4), 8.4(3), 8.4(2), 8.4(1), 8.3(2)40, 8.3(2)39, 8.3(2), 8.3(1), 8.2(5)41, 8.2(5)33, 8.2(5), 8.2(4), 8.2(3), 8.2(2), 8.2(1), 8.0(5), 8.0(4)32, 8.0(4), 8.0(3)6, 8.0(3), 8.0(2))
   COMMUNITY  public           yes       SNMP Community String
   MODE       pass-disable     yes       Enable or disable the password auth functions (Accepted: pass-disable, pass-enable)
   RETRIES    1                yes       SNMP Retries
   RHOST                       yes       The target address
   RPORT      161              yes       The target port
   TIMEOUT    1                yes       SNMP Timeout

msf auxiliary(cisco_asa_extrabacon) > 

Verification

List the steps needed to make sure this thing works

• Start msfconsole
• use auxillary/admin/cisco/cisco_asa_extrabacon
• set RHOST a.b.c.d
• Verify check functions
• Verify exploit functions
• set ASAVER A.B(C)D explicitly
• Verify check functions
• Verify exploit functions

[jjarmoc]

fyi @zerosum0x0 @wwebb-r7 - thought you might be interested in this PR.

[bcook-r7]

Hi @jjarmoc , thanks for the changes, they work fine for me here.

Question: can you modify this to use the Metasploit 'targets' feature rather than using an ad-hoc version option? The version offsets could be moved to live in the targets hash directly, rather than in the version_offsets function. See modules/exploits/android/browser/stagefright_mp4_tx3g_64bit.rb for example.

[jjarmoc]

@bcook-r7

I can take a look at using targets.

I'd also kind of like to rework the payload storage and seperate out the bits that are specific to this vuln from the platform-specific payload shellcode, and encode everything as hex ints, encoding for SNMP automatically for this module. That might make for easier to re-use shellcode should other vulns in ASA come forth, or adding other payloads to this one.

I'll try to work on this over the weekend, and hopefully update the pull to incorporate those changes as well, but at minimum moving to targets with the existing payload structure.

[jjarmoc]

So, I took a look at this @bcook-r7, and it looks like using Targets is going to be a fairly significant change.

Targets is implemented only for exploit modules, and this one is currently an auxiliary module, presumably because it doesn't directly yield a shell. It can though, with a little extra shellcoding work, since it's RCE...

We can convert the module to an exploit module simply enough, but then we need to build out payload modules for ASA or we don't have a payload to use the exploit with. I've kind of wanted to do that anyhow, since I suspect ASA payload modules will be useful if/when additional vulns are made public.

The tricky bit is that the existing payloads (to disable or re-enable authentication checks) are version specific memory patches. It seems to me the way to do this would be to have everything needed to get EIP stay within this module, while the memory patches to change authn state are moved to ASA payload modules.

The payload will need to know the target version in order to return an appropriate shellcode though, and I'm not too sure how to handle that part. Both the exploit module and payload will need the version, but how do I best pass the version from the exploit to the payload?

The exploit module can accept a Target option with any defined version, and I can have it check that the payload also supports that version. Can I just query the Target value from the payload? If not, should I register a 'Payload_version' (or similar) advanced option, set it from the exploit, and check it from the payload?

It's kind of overkill for this one module, but it'd free us up to implement additional ASA payloads that would work with it, or other exploits that leverage the same payloads. In the long run, i think that's better, but getting from here to there is a little complicated; I'm essentially implementing an entirely new target platform for Metasploit...

[wvu]

@bcook-r7, @jjarmoc: Do you guys mean actions? Exploits have targets; aux modules have actions.

[jjarmoc]

@wvu-r7 I don't think actions are what we're looking for.

This is really an exploit - it's RCE via memory corruption. The only reason I can see for why it isn't an exploit module currently are that we don't have payloads which give shell; the current payloads instead patch memory to enable/disable authentication. We could use 'actions' to convey whether we want to enable or disable auth. It's currently in a 'mode' enum, but that's secondary to the version-specific bits.

Right now, It keeps all the version specific addresses in an array, and @bcook-r7 asked if I could make it use targets to better align with Metasploit standards. I can, but only if it becomes an Exploit module, which then makes the version stuff an issue when seperating out exploit from payloads.

The existing payloads are version specific. ASA is essentially a monolithic binary running atop Linux, so with each release any change potentially shifts addresses around in that binary and the offsets change frequently.

A version independent payload seems possible, but would likely involve searching memory dynamically to string it together. That'll make for a larger payload, and possibly a stager. Today, no one has made a functional payload using that approach public.

Parts of the exploit are also hard-coded to version, including:

• A jmp esp pointer that varies per-version
• Fixing a corrupted ebp uses one of two values depending on version
• Return pointer offset varies per version.

So I think what we want to do is to separate this into an exploit module and two payload modules (with hopes of more coming; I really want to directly return shells but right now there's no place to put those payloads). We can then use targets for the version-specific parts of the exploit, but I'm not sure how to handle version-specific payloads.

Can we just have the exploit set the target after it detects, and check the target within the payload? It seems odd to link two modules via an option that the exploit would be required to set...

Would there be concerns about the exploit and initial payloads not yielding a shell? I know that historically shells versus not-shells have been one of the ways to draw the distinction between exploit and aux modules. This is an odd case because all we need is appropriate shellcode to return shells, but that just hasn't been made public so far.

[wvu]

@jjarmoc: Do you remember why we merged #7359 over #7282? I don't want a redux of that. If you want to make this an exploit, yes, targets would make sense.

[ghost]

@wvu-r7 #7359 was pulled over #7282 because it uses less stages, resulting in better reliability, and it includes more versions than the original exploit did.

"ExtraBacon", the exploit as it were, is not a Metasploit "exploit". I highly encourage anyone if you want to make a Metasploit mettle version that takes care of that vulnerability. However, in my research, getting a shell on the Lina binary (what the aux module does) is often better than a shell on the underlying Linux OS, ironically. This is because of the weird way Cisco binds things, even at the Kernel level. And getting a shell on the Linux part of ASA, is not what Equation Group deemed "ExtraBacon".

Targets might make sense, but not in the opportunities presented. I am more interested in solutions which resolve the NPE and SMP versions of the exploit. Or also, versions which include: x64/ASLR/DEP/etc.

I like jjarmoc's target options. This is 100% an auxiliary module. A session will need to be an exploit module, and won't be as useful (but I am encouraging it, if that wasn't clear).

Full disclosure: I experimented with payloads which fully reverse shelled to Linux, but found it unnecessary (and even useless) in a pentest environment. If it is chosen to go this direction: timesaver: look how the original exploit jumped to stage 3, and substitute Metasploit's egghunter.

[wvu]

@zerosum0x0: Sorry, that was a rhetorical question. My point is that we specifically chose to merge your aux module even though there was internal development on making an exploit (which ended up being an aux module anyway). If we want an exploit proper, we're gonna need payloads, as @jjarmoc explained.

There is one loophole, though...

[wvu]

Has anyone tried to make this a cmd_interact exploit? No binary payloads required, and the module already disables auth. Just a shot in the dark. No idea if it'd be successful or not. If you want to do the exploit conversion now, I'd suggest looking into it.

[jjarmoc]

I agree with @zerosum0x0 about x64, NPE and SMP.. those are definitely things that would be valuable to add.

When I talk about shell, I'm not referring to a Linux shell really; as you note that's not very useful. What I'd like to see is dropping into a Lina/ASA CLI shell. Currently, the aux doesn't really get you a shell; it disables auth so you can connect in and get shell. In the context of this vuln, that's just as good, but it doesn't generalize as well. I'm thinking more about a payload which returns a Lina/ASA CLI connect-back, without the need for disabling auth and connecting explicitly.

Mettle would be another option. If we went that route the first thing I'd want to do is drop to a CLI shell via a POST module anyhow.

Exodus Intel posted an overview of their approach along with a PoC for CVE-2016-1287. It could make for another ASA module, and it'd be great if we could share payloads between it and this one. I haven't looked at that exploit beyond the blogpost yet, but I definitely intend to.

Maybe a better approach is for me to work on developing that module, and think about larger changes to this one when it lands? My original intent with this PR wasn't to significantly rework this module really, I just encountered a few cases where it didn't work, and sought to fix those... As it stands currently it does that.

[wvu]

Wow, it looks like this blew up because of a simple misunderstanding. Apologies for being dense.

Let me tackle this point by point. If I am repeating what anyone has said, please bear with me, as I'm just trying to make sense of all of this.

It was suggested that we use targets for the version-specific payload offsets. Since this is an aux module, we can't use targets: only actions are supported. Since actions wouldn't make sense for this use case, we have one other option: convert the aux module to an exploit.

When we merged #7359, we did so with the explicit understanding that this was meant to be an aux module, not an exploit. We had no payloads to use, and we didn't need any, since what we really wanted was access to the Cisco interface, not the Linux operating system. Do you remember the Fortinet backdoor? Exactly.

What I think @jjarmoc is trying to do is clean up the payload offsets, since they exist somewhat messily within the module, given that we can't use targets in aux modules. This PR cleans that up a bit by def'ing off the offsets. However, it's still an aux module.

There is one possibility for converting to an exploit while retaining the preferred access to the Cisco interface: using a cmd_interact "payload" instead of a binary one. With this, in theory, we could create a session from the auth-disabled interface. Is this overkill? Perhaps. But if we want to use targets, we'll need to think of something.

What do you guys want to do? I'm in favor of keeping this an aux module and cleaning up the payload offsets. If someone wants to refactor into an exploit, I'm eager to help where I can. Let me know.

[wvu]

Reading some good novels here, gents. :-)

[jjarmoc]

I think you're right @wvu-r7 - keep it as an aux for now, don't worry about targets. If/when we have another ASA exploit module with payloads (CVE-2016-1287 being a good candidate with functional exploit code already available) we could consider making this an exploit and porting the existing payloads.

Sound reasonable?

[wvu]

👍

[jjarmoc]

So then, where does this leave us on this module currently?

The more important change is adding the MIB2 fallback, since that fixes non-functional scenarios.

The ASAVER option was really just to speed up development by skipping fingerprinting and ended up getting us looking at targets. I could just remove that part entirely, or we could land it as is...

If we want to use an action in keeping with Aux module standards, I could swap that mode Opt for an Action, that'd be simple and doesn't change the effect...

Happy to take whichever approach makes sense :)

[wvu]

Yeah, the OptEnum for MODE should be an Actions/DefaultAction thing. Would be happy to see that change. :)

[wvu]

ASAVER is fine as OptEnum.

[wvu]

There is one downside to getting sessions from an exploit if the exploit doesn't actually give you a shell: post modules are gonna be really screwed up. Traditionally, exploits get you real shells. Another reason to keep this an aux.

Would I like to see an exploit for the underlying OS? Hell yeah. I just don't want to tamper with the vital functionality we have here. Separate module would be nice!

[busterb]

I just forgot that Targets weren't used in the Aux module metadata, thanks for answering the question :) This is a good change then.

[ghost]

I understand what you mean with the payload separation now. Perhaps it may even make sense to store offsets in a data file (like the exploit William Webb was working on did)? Then if someone makes proper "payloads" for other functions they can just include that file as well.

For an "exploit", maybe it can patch the auth, connect, and unpatch in another thread or something after the connection is done. At that point its just creating a simple SSH/telnet session that doesn't require a password. It's kind of a hack in that normally an exploit doesn't operate that way.

To do a proper reverse shell, especially one with the more useful Cisco-CLI, one has to make use of existing functions in the Lina binary (which involves finding more offsets). Just using Linux socket syscalls isn't enough because everything is a TAP device and Lina does all the heavy lifting, and even if that worked you'd just get a Linux shell.

[jjarmoc]

I just committed the change to use aux actions instead of the 'MODE' Opt.

• Tested with a couple versions, all good.
• Confirmed msftidy comes back clean.

msf auxiliary(cisco_asa_extrabacon) > show actions

Auxiliary actions:

   Name          Description
   ----          -----------
   PASS_DISABLE  Disable password authentication.
   PASS_ENABLE   Enable password authentication.


msf auxiliary(cisco_asa_extrabacon) > run

[*] Building PASS_DISABLE payload for version 8.4(2)...
[*] Sending SNMP payload...
[+] Clean return detected!
[!] Don't forget to run PASS_ENABLE after logging in!
[!]   set ACTION PASS_ENABLE
[*] Auxiliary module execution completed
msf auxiliary(cisco_asa_extrabacon) > 
msf auxiliary(cisco_asa_extrabacon) > set ACTION PASS_ENABLE
ACTION => PASS_ENABLE
msf auxiliary(cisco_asa_extrabacon) > run

[*] Building PASS_ENABLE payload for version 8.4(2)...
[*] Sending SNMP payload...
[+] Clean return detected!
[*] Auxiliary module execution completed
msf auxiliary(cisco_asa_extrabacon) > 

[bcook-r7]

LGTM, thanks (and good side-discussion too.)

[bcook-r7]

Release Notes

This improves the cisco_asa_extrabacon module in a few ways. It adds support for some ASA versions which failed previously due to lack of MIB support. The module now uses an auxiliary module 'action' specifier rather than a custom data store option for specifying what action the module should take. It also allows specifying a particular ASA version to target, for when auto-targeting does not work and to aid in future module development.