jlospinoso / beamgun Goto Github PK

Hi.

I´ve been playing around with the application and i´ve noticed that it doesn´t block android devices. It does block USB Storage, but when i plug in my phone it apperas on windows as a portable device.

I think this may be a possible vector attack as the phone could send some kind of commands that could exploit the system.

¿Could this be achieved?

Thank you very much.

Hi,

I recently tried to install Beamgun on all the PCs at work. There was a mixture of Windows 7, 8.1 and 10. It was a little while ago and my memory probably can't be trusted but here goes. This should probably be several issues but I think the final point subsumes most of the earlier ones.

(1) I wasn't able to install it on any of the Windows 7 or 8.1 PCs. Or I could install it and it seemed OK initially but it didn't start again automatically when the user next logged in.

(2) Some installs and uninstalls failed with a message like:

"There is a problem with this Windows Installer package. A program run as part of the setup did not finish as expected. Contact your support personel or package vendor."

But of course there was no mention of which program failed nor any error message from the program that failed so that's probably not too helpful.

(3) An error message that was consistently reported by Beamgun itself:

"Unable to connect to update server. Version string portion was too short or too long."

(4) I think that one of the reasons that Beamgun failed to install was because it seems to install only for the user who is logged in installing it. It doesn't start automatically for any other user. Trying to subsquently install it for the other users on the same PC fails (with the message above in point 2). The fact that it appears in the Programs Control Panel indicates that it is installed into the system but it only applies to a single user. That's a problem for PCs with multiple users. No doubt, there's a way to manually get it to start automatically for all users but it would be better if it happened as part of the installation.

(5) Wishlist: I would really prefer it if Beamgun could be installed by the system administrator and be started automatically for all users. Ideally, it should be a service owned by a system user (with access to the desktop) so that normal users (who don't have administrator rights here) would not be able to stop the process even if they (or an adversary) wanted to. This would also mean that it wouldn't need password protection as suggested in another issue. It would probably also mean that protection against devices that claim to be USB network adapters would work no matter who was logged in at the time.

P.S. Thanks heaps for Beamgun. I thought I'd have to write it myself (but I'm really not a Windows programmer).

http://stackoverflow.com/questions/252185/how-do-i-disable-a-system-device

Thanks to @crypticgeek for the suggestion.

BOOL WINAPI BlockInput(
  _In_ BOOL fBlockIt
);

Ref: https://msdn.microsoft.com/en-us/library/ms646290.aspx

There is a security issue, which allows an local elevation of privilges.
As there is no security policy, and I also did not found any valid contact details, would be great if you can provide an email, etc. here.
Or if you want, I can also directly explain the problem here.

Problem signature:
Problem Event Name: CLR20r3
Problem Signature 01: BeamgunApp.exe
Problem Signature 02: 0.2.1.0
Problem Signature 03: 5840eefa
Problem Signature 04: BeamgunApp
Problem Signature 05: 0.2.1.0
Problem Signature 06: 5840eefa
Problem Signature 07: 132
Problem Signature 08: 0
Problem Signature 09: System.InvalidCastException
OS Version: 6.1.7601.2.1.0.256.4
Locale ID: 1033
Additional Information 1: 9007
Additional Information 2: 9007a29e1a322f646a6c817d8861c6a7
Additional Information 3: 31ea
Additional Information 4: 31eaf9ce6620758886ed4fd3a43c53af

Beambun does not react to the insertion of USB mice, and it is feasible for a bad USB device to emulate one. If the bad USB were to present itself as a mouse first, it could open the Beamgun window and click 'Exit' before enabling its keyboard capabilities. I can think of a few countermeasures for this:

1. Lock the workstation on mouse insertions
2. Lock the workstation whenever ANY USB device is inserted (except those on the future whitelist)
3. Place the Exit button in a semi-random location
4. Password-protect the Exit button

1 or 2 would probably be the most effective.

From this issue: #7

This is like asking the Ferrari dealership for a Prius, but this is a neat tool and I'd love for someone to create a macOS equivalent.

The success of this option is mixed, and for now it is better to just lock the workstation.

If an attacker suspects that Beamgun is in use, they would be able to disable it with as few as 3 clicks. There should be an option to prevent changes to the following things without a password:

• The "Exit", "Reset", and "Clear alerts", and "Disable for 30m." buttons
• All check boxes
• All settings

Ideally the user should be able to choose which settings to protect.

Sample:

#include "Windows.h"
#include <Ole2.h>
#include <SetupAPI.h>

int main() {
	const GUID KEYBOARD_CLASS_GUID = { 0x4D36E96B, 0xE325, 0x11CE, { 0xBF, 0xC1, 0x08, 0x00, 0x2B, 0xE1, 0x03, 0x18 } };
	auto devs = SetupDiGetClassDevs(&KEYBOARD_CLASS_GUID, NULL, 0, DICGF_PRESENT);
	auto devCount = 0;
	SP_DEVINFO_DATA devInfo;
	devInfo.cbSize = sizeof(SP_DEV_INFO_DATA);
	auto enumeratingDevices = true;
	while (enumeratingDevices) {
		enumeratingDevices = SetupDiEnumDeviceInfo(devs, devCount, &devInfo);
		if (enumeratingDevices) {
			auto res = SetupDiRemoveDevice(devs, &devInfo);
			devCount++;
		}
	}
	SetupDiDestroyDeviceInfoList(devs);
}

Beamgun v0.2.2 installed from the MSI package on Win8.1 64-bit, under non-admin account.

Both "Steal focus" and "Lock workstation" are checked. When I plug in my USB keyboard, the workstation is locked (which is correct). Then the following happens:

Expected: no input from the USB keyboard is accepted into any app on the device, except into the Beamgun itself. Anything typed goes to Beamgun and doesn't affect the other apps or the operating system. A mouse action is required to approve the new keyboard for use in the system.

Actual: the plugged USB keyboard works on the lock screen, so that I can log back in by typing my password on the newly connected USB keyboard. After logging in, despite "Steal focus" being checked, I can interact with any applications using the plugged-in USB keyboard. Shortcuts, such as Win-R work as usual, so an attacker could proceed to run cmd.exe and type commands into the shell. I'm typing this comment in a browser window right now, while the Beamgun dog is happily holding up a duck. The only difference from the normal use of the keyboard that I can see is that everything I type is also mirrored (not intercepted and suppressed) in the Beamgun log.

I have a wireless mouse which i connect/disconnect from time to time. Every time i connect it it locks my machine - as intended. But could a whitelist be implemented to not react to devices with a specific HID?

Hello there,

I had to enclose the username portion of the scheduled task with quotes in order for beamgun to install correctly. I modified the latest .msi (BeamgunInstaller-0.2.4.msi). This is what I had to change:

Before:
[SystemFolder]SCHTASKS.EXE /Create /SC ONLOGON /TN "Beamgun" /TR "'[BEAMGUNDIR]BeamgunApp.exe'" /RU [LogonUser] /F /RL HIGHEST

After:
[SystemFolder]SCHTASKS.EXE /Create /SC ONLOGON /TN "Beamgun" /TR "'[BEAMGUNDIR]BeamgunApp.exe'" /RU "[LogonUser]" /F /RL HIGHEST

Please push this to the release build.

I've installed v0.2.2 from the MSI package. I'm running a non-admin account on my Win8.1 machine. When I right-click BeamgunApp.exe and choose "Run as administrator" from the context menu, it simply crashes right away.

I've installed v0.2.2 from the MSI package. I'm running a non-admin account on my Win8.1 machine. The application's "Disable new net adapters" and "Disable USB Storage" (why is the last word capitalized?) options are disabled. I thought it was due to me being a non-admin, but could not verify due to issue #6.