Automatic payload selection ignores that Meterpreter no longer supports Windows systems prior to XP SP2

[bcoles]

Automatic payload selection ignores that Meterpreter no longer supports Windows systems prior to XP SP2.

As windows/meterpreter/reverse_tcp is usually the default selected payload this will result in failed exploitation at best and crashing targets at worst.

For example, the default payload for exploit/windows/smb/ms08_067_netapi will not work for a significant portion (10) of the available targets (71). Suddenly one of the oldest and most reliable and most famous exploits will "not work" by default.

msf6 > use exploit/windows/smb/ms08_067_netapi 
[*] No payload configured, defaulting to windows/meterpreter/reverse_tcp
msf6 exploit(windows/smb/ms08_067_netapi) > show targets

Exploit targets:

   Id  Name
   --  ----
   0   Automatic Targeting
   1   Windows 2000 Universal
   2   Windows XP SP0/SP1 Universal
   3   Windows 2003 SP0 Universal
   4   Windows XP SP2 English (AlwaysOn NX)
   5   Windows XP SP2 English (NX)
   6   Windows XP SP3 English (AlwaysOn NX)
   7   Windows XP SP3 English (NX)
   8   Windows XP SP2 Arabic (NX)
   9   Windows XP SP2 Chinese - Traditional / Taiwan (NX)
   10  Windows XP SP2 Chinese - Simplified (NX)
   11  Windows XP SP2 Chinese - Traditional (NX)
   12  Windows XP SP2 Czech (NX)
   13  Windows XP SP2 Danish (NX)
   14  Windows XP SP2 German (NX)
   15  Windows XP SP2 Greek (NX)
   16  Windows XP SP2 Spanish (NX)
   17  Windows XP SP2 Finnish (NX)
   18  Windows XP SP2 French (NX)
   19  Windows XP SP2 Hebrew (NX)
   20  Windows XP SP2 Hungarian (NX)
   21  Windows XP SP2 Italian (NX)
   22  Windows XP SP2 Japanese (NX)
   23  Windows XP SP2 Korean (NX)
   24  Windows XP SP2 Dutch (NX)
   25  Windows XP SP2 Norwegian (NX)
   26  Windows XP SP2 Polish (NX)
   27  Windows XP SP2 Portuguese - Brazilian (NX)
   28  Windows XP SP2 Portuguese (NX)
   29  Windows XP SP2 Russian (NX)
   30  Windows XP SP2 Swedish (NX)
   31  Windows XP SP2 Turkish (NX)
   32  Windows XP SP3 Arabic (NX)
   33  Windows XP SP3 Chinese - Traditional / Taiwan (NX)
   34  Windows XP SP3 Chinese - Simplified (NX)
   35  Windows XP SP3 Chinese - Traditional (NX)
   36  Windows XP SP3 Czech (NX)
   37  Windows XP SP3 Danish (NX)
   38  Windows XP SP3 German (NX)
   39  Windows XP SP3 Greek (NX)
   40  Windows XP SP3 Spanish (NX)
   41  Windows XP SP3 Finnish (NX)
   42  Windows XP SP3 French (NX)
   43  Windows XP SP3 Hebrew (NX)
   44  Windows XP SP3 Hungarian (NX)
   45  Windows XP SP3 Italian (NX)
   46  Windows XP SP3 Japanese (NX)
   47  Windows XP SP3 Korean (NX)
   48  Windows XP SP3 Dutch (NX)
   49  Windows XP SP3 Norwegian (NX)
   50  Windows XP SP3 Polish (NX)
   51  Windows XP SP3 Portuguese - Brazilian (NX)
   52  Windows XP SP3 Portuguese (NX)
   53  Windows XP SP3 Russian (NX)
   54  Windows XP SP3 Swedish (NX)
   55  Windows XP SP3 Turkish (NX)
   56  Windows 2003 SP1 English (NO NX)
   57  Windows 2003 SP1 English (NX)
   58  Windows 2003 SP1 Japanese (NO NX)
   59  Windows 2003 SP1 Spanish (NO NX)
   60  Windows 2003 SP1 Spanish (NX)
   61  Windows 2003 SP1 French (NO NX)
   62  Windows 2003 SP1 French (NX)
   63  Windows 2003 SP2 English (NO NX)
   64  Windows 2003 SP2 English (NX)
   65  Windows 2003 SP2 German (NO NX)
   66  Windows 2003 SP2 German (NX)
   67  Windows 2003 SP2 Portuguese - Brazilian (NX)
   68  Windows 2003 SP2 Spanish (NO NX)
   69  Windows 2003 SP2 Spanish (NX)
   70  Windows 2003 SP2 Japanese (NO NX)
   71  Windows 2003 SP2 French (NO NX)
   72  Windows 2003 SP2 French (NX)

Automatic payload selection was added in #13566.

Meterpreter support for Windows systems prior to XP SP2 was dropped not long after (some time around #14528).

In the past, a hack was added (#13755) to work around issues with payload selection for multi modules, but this issue won't be so easy to fix.

A few solutions (all terrible):

• The easiest solution, but not cleanest, would be to prefer windows/shell/reverse_tcp over windows/meterpreter/reverse_tcp - but this sucks.

• Hard-code a default payload (probably windows/shell/reverse_tcp) for each target in modules which target systems from this era. Hard-coding payloads kinda sucks. Automatic payload selection was added specifically to prevent hard-coded payloads. Also, this won't work with modules which support automatic targeting as the payload cannot be changed once the module has started.

• Add a supports-meterpreter flag to each target in each module which targets systems from this era. Add a check (somewhere) that the target has this flag if the selected payload is a Meterpreter payload. (or an inverse flag does-not-support-meterpreter)

• Try to work in a excluded_os along with excluded_platforms and excluded_archs in lib/msf/core/exploit.rb. This isn't particularly easy as there's no standardization and each target will need to be updated with an os flag to support matching match.

Creating an issue because I don't have any brilliant ideas as to how to solve this right now. Adding the bug label (even though this is more of a usability issue) as selecting the wrong payload by default is going to crash the target in many instances. It will likely also result in bug reports.

[smcintyre-r7]

I like a combination of options 1 & 3 (set a default to shell and add a supports-meterpreter flag to the targets).

To my knowledge, when v6 dropped XP SP1 support for Meterpreter was the first time that Metasploit dropped support for a target operating system from a payload that previously had it. I don't anticipate this happening again in the next couple of years, so I don't think adding a whole bunch of compatibility logic for payloads would be worth it. I'm sure it'll happen again eventually though but dropping support certainly isn't something that we're looking to do often.

I think there have even been some considerations to drop a lot of exploits from this time period (except for MS08-067 which would be treated as a special case due to its popularity). If that's something we do then it definitely would make more sense to handle the payload compatibility checks within the module itself since it would be one of very few that would use it and we're not still writing exploits targeting XP SP1 and older.

[bcoles]

I like a combination of options 1 & 3 (set a default to shell and add a supports-meterpreter flag to the targets).

Something like this seems most reasonable to me too.

Ruling out option 2, as this is too messy and unintuitive for modules which make use of automatic targeting. Ruling out option 4 because upon re-reading it it's not immediately obvious what I mean, so rejecting it as nonsense.

The affected modules which perform automatic targeting would need to check the supports-meterpreter flag following target selection and raise a Failure::PayloadFailed if the payload is incompatible.

That seems fairly straight forward on the surface; however, there's a nastier and more systemic underlying issue at play here. Whatever approach is implemented may need to be extendable or supplemented with additional payload compatibility checks (likely on a per-payload basis - for example, specifying the minimum version of PowerShell required).

On the other hand, perhaps I'm prematurely over-engineering. Refer to tangential ramblings below.

To my knowledge, when v6 dropped XP SP1 support for Meterpreter was the first time that Metasploit dropped support for a target operating system from a payload that previously had it.

This matches my understanding too.

I don't anticipate this happening again in the next couple of years, so I don't think adding a whole bunch of compatibility logic for payloads would be worth it.

Unfortunately this field of issues related to deprecated systems encompasses more than Windows.

While automatic payload selection is the most obvious problematic area, this issue extends to payload compatibility in general.

A different but somewhat similar type of issue exists with Mettle for Linux. This has resulted in at least one issue (https://github.com/rapid7/metasploit-framework/issues/14787#issuecomment-786105030) due to library changes. This broke chmod which did not break Mettle entirely (a session can be established), but it is a fairly important method. This probably isn't the first instance of an issue like this and there are likely more lurking.

The next era of Windows systems (2008 / Vista / 7) are already past end of life and nearing the end of extended support. These systems are the first to ship with PowerShell by default and this is used extensively. Fortunately, Microsoft love backwards compatibility, so existing PowerShell code should continue to work on newer systems. However, many new functions have been added to PowerShell since version 1.0, and developers attempting to write core library code using modern PowerShell has already caused issues (https://github.com/rapid7/metasploit-framework/pull/12970#issuecomment-589899690). This is only going to become more of a problem as PowerShell evolves.

[bcoles]

I think there have even been some considerations to drop a lot of exploits from this time period (except for MS08-067 which would be treated as a special case due to its popularity).

I'm against this idea and not convinced that it is necessary.

However, if maintenance and support for older systems becomes truly unachievable in the future, then I'd like to see some form of "official" exploit pack made available containing previously available modules which have been approved, validated, and field tested.

[adfoster-r7]

I think there have even been some considerations to drop a lot of exploits from this time period (except for MS08-067 which would be treated as a special case due to its popularity).

I'm against this idea and not convinced that it is necessary.

Cross-referencing the discussion piece here: https://github.com/rapid7/metasploit-framework/discussions/14485

[github-actions[bot]]

Hi!

This issue has been left open with no activity for a while now.

We get a lot of issues, so we currently close issues after 60 days of inactivity. It’s been at least 30 days since the last update here. If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!

As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request.