5 ms·

I honestly wonder who can use these applications these days? Large companies have stopped giving administrator access years ago. The vendor could corrupt their

I honestly wonder who can use these applications these days? Large companies have stopped giving administrator access years ago. The vendor could corrupt their way into some middle manager all they want, they have zero power over procurement and IT, users won't get administrator access to use the app. If the app is really unusable, which it is, that must be preventing a whole lot of sales.

hhh 5y ago
Microsoft provides toolkits to help with this. I have spent easily 100+ hours churning through a catalogue of applications that 'need local admin' and have only found one case where it was true, and it was due to a bug that the latest software version fixed. It is almost always a false truth due to cost I feel. I primarily analyzed applications that were for PLCS and other industrial equipment. You can find more information about this here: https://docs.microsoft.com/en-us/windows/deployment/planning/compatibility-administrator-users-guide https://docs.microsoft.com/en-us/windows/deployment/planning... I run a VM that stays up to date with the latest Windows version that I install the toolkit on for testing. (side tangent, the user of this application insisted they had the latest version, and with it being behind some login that required some form related to ITAR or something to register, we just had to trust him until I had him download it 'just in case.')
- rckoepke 5y ago
  Great timing. I'm looking for solutions to run Siemens Simatic PDM without being a local admin. Installing it with temporary admin rights seems to silently fail. I'm also trying to use libpcap and USBPcap without local admin. They request UAC every time I open Wireshark to start a new capture session. (Needed for debugging raw Ethernet and serial stacks) If you have any tips for either of these I am all ears!
  - corty 5y ago
    Use npcap and check the settings for the admin-not-required button (forgot the exact name). But generally, accessing raw anything needs elevated rights and should need elevated rights. For a normal user to be able to sniff network and usb traffic is usually a huge security hole and therefore correctly locked away. Not at all comparable to the other cases someone discussed above about some crappy app needing admin to write c:\windows\crappyapp.ico...
hug 5y ago
> Large companies have stopped giving administrator access years ago. This is untrue for low-end enterprise. Orgs with up to 10,000 seats run weird shitty local-admin-required products all over the place, usually due to legacy. In consulting, I would regularly run into core LOB apps that not only required local admin but "couldn't" run as a Windows service and required a user to be logged on with the UI window open in order to function. You spend hours using the associated Microsoft toolkit & various shims to make the product function without, but there's always another business who just does it the lazy way.
jcrites 5y ago
I've worked for two of the FAANG companies together about 15 years, and I've always had local administrator access and root access to (1) my personal client machines (laptop, desktop on all platforms) (2) my personal development machines on the corporate network (3) my teams' production machines. I'm a software developer and wouldn't have it any other way. Software developers need root/admin access if you expect any development velocity and ability to solve problems in production with expedience. There are too many diagnostic operations that depend on having root/admin, and especially fixes to errors. One exception might be if the production fleet is handled by a separate operations team – but I'm not in favor of this model, which has its own negative impact on velocity/delivery speed due to the coordination involved, and the tension between "software developers want to ship" and "operations team wants software to remain unchanging and stable". I'm not in favor of operations teams until the software team is overwhelmed with support requests and their velocity is slowing down. In that case, I'd start with beefing up the support team; and then finally at tremendous scale with high operational burden, hire an operations team / SRE team to operate the system. The solution is to make software responsible for owning/operating their own systems until they are extremely large scale (Amazon S3 scale) – as scale so large that rare spontaneous faults would eat up a significant percentage of the overall software team's time. I'm not opposed to having frontline customer support in front of the developers, potentially multiple tiers (since a lot of customers need to Read The Fine Manual); but once the escalation hits a developer, to expeditiously solve the problem they need root/admin. Your software developers with root/admin access should still be logged such that central security team can observe what's going on on every machine at the company, via configuration of SSHD, and regular inspection of that config – e.g. a shell that logs off-box command execution in real-time by default, either for all commands or commands root; and this will capture what they're doing unless they go very far out of the way to conceal and obfuscate their activities. Even then, the initial steps to begin the concealment will show up in the logs, unless very well obfuscated.) Lastly, if your team runs public web servers, then you need to listen on ports like 80 and 443 while requiring root. Well-written servers drop root immediately after opening the socket, but custom written servers may run on those ports and not drop capabilities and run in a container. For example, Faceook Messenger Platform's onboarding instructions and example code –https://developers.facebook.com/docs/messenger-platform/getting-started/webhook-setup https://developers.facebook.com/docs/messenger-platform/gett... – recommends binding a TCP port >1024: ``` app.listen(process.env.PORT || 1337, () => console.log('webhook is listening')); ``` Aside: Nice and professional port number there. If I'd written that documentation I would have used 8081 or 8443, and included a discussion of the implications of running a web server on HTTPS (443) or HTTP (80). I understand that having software developers having root/admin on their machine is very different than non-tech jobs, but for any jobs in the engineering family it's essential. The builders and operators of a system should always have root access to it, because (1) it's needed for development throughput (2) they can trivially get root access anyway through a variety of different means, such as incorporating a grant of root access into the code they're shipping, with minor obfuscation. At my last company I was also involved in a major effort to make easier to not run software as root. However, for "typical" services running on single-purpose machines or Virtual Machines that don't do anything but receive or process commands from any other software, and don't run any other software (besides company Infra), I think the risk is low. "root" and "nobody" are marginally different on a machine that runs a single application because an attacker who breaks in can access all of its data anyway. It's true that with root an attacker can implant rootkits and more firmly maintain a grasp of the server, but competent FAANG companies (1) require MFA in order to log in to servers besides the initial hardware client in front of the user (2) will audit machines for unexpected changes like what I'm describing above. I'm guessing only highly sophisticated attackers like APTs would be able to conceal from those scans, and there will always be the record of initial penetration to review. Incident response will quickly fan out to all machines the pwned machines has communicated with. One of the FAANGs had complete network logs for machines like this and would have been able to inspect the network traffic. Lastly, sophisticated corps employ defense-in-depth and multiple layers of redundancy like (1) you can't attempt to log into machines on the network without both being on the VPN and having authenticated certificates from the enterprise root authority, and (2) Bastion machines which can log commands being sent to machines even if the machines themselves don't, and so on.

hhh 5y ago

Microsoft provides toolkits to help with this. I have spent easily 100+ hours churning through a catalogue of applications that 'need local admin' and have only found one case where it was true, and it was due to a bug that the latest software version fixed. It is almost always a false truth due to cost I feel. I primarily analyzed applications that were for PLCS and other industrial equipment. You can find more information about this here: https://docs.microsoft.com/en-us/windows/deployment/planning/compatibility-administrator-users-guide https://docs.microsoft.com/en-us/windows/deployment/planning... I run a VM that stays up to date with the latest Windows version that I install the toolkit on for testing. (side tangent, the user of this application insisted they had the latest version, and with it being behind some login that required some form related to ITAR or something to register, we just had to trust him until I had him download it 'just in case.')

rckoepke 5y ago
Great timing. I'm looking for solutions to run Siemens Simatic PDM without being a local admin. Installing it with temporary admin rights seems to silently fail. I'm also trying to use libpcap and USBPcap without local admin. They request UAC every time I open Wireshark to start a new capture session. (Needed for debugging raw Ethernet and serial stacks) If you have any tips for either of these I am all ears!
- corty 5y ago
  Use npcap and check the settings for the admin-not-required button (forgot the exact name). But generally, accessing raw anything needs elevated rights and should need elevated rights. For a normal user to be able to sniff network and usb traffic is usually a huge security hole and therefore correctly locked away. Not at all comparable to the other cases someone discussed above about some crappy app needing admin to write c:\windows\crappyapp.ico...

hug 5y ago

> Large companies have stopped giving administrator access years ago. This is untrue for low-end enterprise. Orgs with up to 10,000 seats run weird shitty local-admin-required products all over the place, usually due to legacy. In consulting, I would regularly run into core LOB apps that not only required local admin but "couldn't" run as a Windows service and required a user to be logged on with the UI window open in order to function. You spend hours using the associated Microsoft toolkit & various shims to make the product function without, but there's always another business who just does it the lazy way.

jcrites 5y ago

I've worked for two of the FAANG companies together about 15 years, and I've always had local administrator access and root access to (1) my personal client machines (laptop, desktop on all platforms) (2) my personal development machines on the corporate network (3) my teams' production machines. I'm a software developer and wouldn't have it any other way. Software developers need root/admin access if you expect any development velocity and ability to solve problems in production with expedience. There are too many diagnostic operations that depend on having root/admin, and especially fixes to errors. One exception might be if the production fleet is handled by a separate operations team – but I'm not in favor of this model, which has its own negative impact on velocity/delivery speed due to the coordination involved, and the tension between "software developers want to ship" and "operations team wants software to remain unchanging and stable". I'm not in favor of operations teams until the software team is overwhelmed with support requests and their velocity is slowing down. In that case, I'd start with beefing up the support team; and then finally at tremendous scale with high operational burden, hire an operations team / SRE team to operate the system. The solution is to make software responsible for owning/operating their own systems until they are extremely large scale (Amazon S3 scale) – as scale so large that rare spontaneous faults would eat up a significant percentage of the overall software team's time. I'm not opposed to having frontline customer support in front of the developers, potentially multiple tiers (since a lot of customers need to Read The Fine Manual); but once the escalation hits a developer, to expeditiously solve the problem they need root/admin. Your software developers with root/admin access should still be logged such that central security team can observe what's going on on every machine at the company, via configuration of SSHD, and regular inspection of that config – e.g. a shell that logs off-box command execution in real-time by default, either for all commands or commands root; and this will capture what they're doing unless they go very far out of the way to conceal and obfuscate their activities. Even then, the initial steps to begin the concealment will show up in the logs, unless very well obfuscated.) Lastly, if your team runs public web servers, then you need to listen on ports like 80 and 443 while requiring root. Well-written servers drop root immediately after opening the socket, but custom written servers may run on those ports and not drop capabilities and run in a container. For example, Faceook Messenger Platform's onboarding instructions and example code –https://developers.facebook.com/docs/messenger-platform/getting-started/webhook-setup https://developers.facebook.com/docs/messenger-platform/gett... – recommends binding a TCP port >1024: ``` app.listen(process.env.PORT || 1337, () => console.log('webhook is listening')); ``` Aside: Nice and professional port number there. If I'd written that documentation I would have used 8081 or 8443, and included a discussion of the implications of running a web server on HTTPS (443) or HTTP (80). I understand that having software developers having root/admin on their machine is very different than non-tech jobs, but for any jobs in the engineering family it's essential. The builders and operators of a system should always have root access to it, because (1) it's needed for development throughput (2) they can trivially get root access anyway through a variety of different means, such as incorporating a grant of root access into the code they're shipping, with minor obfuscation. At my last company I was also involved in a major effort to make easier to not run software as root. However, for "typical" services running on single-purpose machines or Virtual Machines that don't do anything but receive or process commands from any other software, and don't run any other software (besides company Infra), I think the risk is low. "root" and "nobody" are marginally different on a machine that runs a single application because an attacker who breaks in can access all of its data anyway. It's true that with root an attacker can implant rootkits and more firmly maintain a grasp of the server, but competent FAANG companies (1) require MFA in order to log in to servers besides the initial hardware client in front of the user (2) will audit machines for unexpected changes like what I'm describing above. I'm guessing only highly sophisticated attackers like APTs would be able to conceal from those scans, and there will always be the record of initial penetration to review. Incident response will quickly fan out to all machines the pwned machines has communicated with. One of the FAANGs had complete network logs for machines like this and would have been able to inspect the network traffic. Lastly, sophisticated corps employ defense-in-depth and multiple layers of redundancy like (1) you can't attempt to log into machines on the network without both being on the VPN and having authenticated certificates from the enterprise root authority, and (2) Bastion machines which can log commands being sent to machines even if the machines themselves don't, and so on.