Re: [PLUG] that's nice

[Fred Stluka via plug <plug@lists.phillylinux.org>]

On 4/8/21 9:26 PM, Rich Freeman wrote:
> If the registry key says you're not allowed to modify the registry
> key, well, you can't modify the registry key, just as a non-root user
> can't run chown on a file they don't own, even though chown modifies
> the very record that contains the owner.

Come on!  You don't really believe that, do you?  The internal
security of the Windows registry's "filesystem within a file" is
as robust as the security of the Linux filesystem?  Sorry, but I
really don't believe "Captain Underpants" was able to whip up
something in a year or less that Unix has matured and evolved
for over 50 years.  Especially given my own personal experience
of casually walking around so many different attempts at
"Windows security".


> Sure, not all Windows sysadmins know how to actually admin Windows,
> but then again I'm sure there are plenty of Linux sysadmins out there
> who don't know what they're doing.  If you deploy Linux desktops with
> the user having UID 0 then the user is obviously going to be able to
> fiddle with things.  That is pretty analogous to giving users admin
> rights on Windows...

OK.  So you're saying that inexperienced Linux sysadmin might
fire up a new Linux box, change the UID of root to another
number than 0, create a user, and explicitly assign them UID 0?
All entirely by accident, with no intention of giving that user any
special access?  Doesn't seem that likely to me...

Compare this with an inexperienced Windows sysadmin firing
up a new Windows box, and leaving all the default settings in
place, so that there are no file permissions, or restricted users.
Seems much more likely...

It's like the difference between Linux and Windows PATHs.  On
Linux, "." is not on your PATH by default, and no competent
sysadmin ever puts it there, especially not as the 1st entry.
But on Windows, it's HARDCODED to ALWAYS be there, and to
always be the 1ST ENTRY!  Doh!

On that topic, here's another tip I plan to finish writing and
mail out someday.  Probably to my Windows Users list,
Unix/Linux Users list, Mac Users list, and Computer Security
list.  I roughed out this tip a few years back, but the security
hole just made the news when it bit some folks 2 days ago.
See the link below.

I REALLY have to get around to sending out that series of
tips soon...  So many tips, so little time...

---------------------

*Adding "." to your PATH...*

If you start creating local scripts in various directories, as I
suggested with "editall" scripts in my previous email, you may
want to add "." to your PATH.

Then you can just type:
% editall
instead of always having to type:
% ./editall

But if you do so, be sure to put the "." at the END of the PATH,
not at the beginning of the PATH.  Here's why:

Savvy Linux/Unix sys admins know to never put "." on their PATH
except at the very end.  If they put it at the beginning, they are
vulnerable to a malicious attack by one of their users.  Here's
an example.

The user could create a script called "ls" that does something
bad while suppressing all output, then calls ls as usual but tells
it to not show the name of the "ls" script itself.  Then, the user
could contact the sys admin, reporting some sort of a fake
problem, and asking the sys admin for help, and directing him
to the directory where the "ls" script resides.  The sys admin is
likely to do:
% cd the_directory
% ls

See what happens?  The admin is tricked into doing the bad
thing, and never even knows it because he sees the output of
his "ls" command exactly as expected.  He pokes around for a
while, finds and fixes the reported problem, or gives up
mystified, but has no idea that he's been duped.

This trick can be played on regular users also, not just admins,
but with admins it is more worthwhile to the malicious user.
With a regular users, the bad thing can be one or more
commands to delete all of that user's files, or search for
credit card numbers and mail them to the malicious user, or
send rude email to the user's boss, or anything else that the
user is authorized to do.

But with an admin, the bad thing can also be a command to
give root access (full admin privileges) to the malicious user.
Or insert a virus into a system file.  Or delete all files on the
entire system.  Or anything that the admin is authorized to do.
Whenever anyone w/o privileges tries, it fails, but suppresses
all output, and goes on to the next step of doing the "ls"
command.  So, no one's the wiser.

The malicious user doesn't really even have to contact the
admin.  Can just set the trap, and sit back and wait, hoping
the admin eventually wanders by and steps in it.  Can place
such traps all over the place.  Maybe even add a clause that
notices when it succeeds and deletes all the "ls" scripts that
were placed in all the places, hiding the evidence.

To protect yourself, never put "." anywhere on the PATH except
at the very end.  Then a script in the local directory never hides
any command that has the same name.  You can still run all of
your local scripts without having to type "./" before the name,
but it will always search all the standard places for a command
with the same name before running it.

If you do create a script with the same name as a standard
command, you probably want to know anyhow, and avoid
doing it.  It's generally a bad idea, even if you don't know
about or use the standard command because you may
someday run a script that uses the command, written by
someone who knew the command.  If the script finds your
script instead of the standard command, it will probably fail
in an unexpected way, and neither you nor the writer of the
script will have any idea why.

If you really DO want your script to hide any standard command
with the same name, create an alias called your_script that
invokes "./your_script" explicitly.  Aliases do NOT affect the
behavior of scripts, so hiding a command with an alias is OK.

BTW, this is another way that Microsoft is so bad at security.
All savvy Linux/Unix sys admins know to NEVER put "." at the
front of the PATH, and all Linux/Unix systems are configured
to NOT have "." on the PATH at all by default.

But all Windows systems ALWAYS have "." as the first thing on
the PATH.  It is hard-coded into the Windows OS.  Cannot be
changed.  Doesn't even show as part of the PATH environment
variable.  The command invocation logic of the OS just always
looks in the current directory before looking in the directories
of the PATH.  So all Windows sys admins are always vulnerable
to this trick.  Doh!!!

Here's a real-world case where a hacker used it to break into
Windows computers:
- 
https://confluence.atlassian.com/bamboo/bamboo-security-advisory-2021-04-07-1047552896.html

The trick was to put a file called git.bat or git.exe into a Git
repo.  Then encourage people to use the repo.  When they
pull it with the "git clone" or "git pull" command, the next
command they're likely to type is "git".  But with "." on the
front of the PATH, that runs the programs they just pulled,
not the regular git command.  And that program can do
anything it wants.  Can even do something malicious, like
create an account on the Windows computer for the hacker
to be able to login.  And then call the regular git command
so the user doesn't notice that anything odd happened.
This will work on ANY Windows system, no matter how
careful and security conscious you are.  But will NOT work
on Mac, Linux, or any other Unix, unless the user was foolish
enough to put "." at the front of his PATH.

--------------------------

> Even in a less-secure configuration, the policy is going to get
> reapplied every time you log in, so you're still going to have to load
> that registry key every time you log in.

Not always true.  Sometime they're not set up to re-apply
themselves.  If they are, just add your own REG file to your
Windows startup scripts to re-apply your fix after the
policy is re-applied.  Easy, peasy!...

--Fred
------------------------------------------------------------------------
Fred Stluka -- http://bristle.com -- Glad to be of service!
Open Source: Without walls and fences, we need no Windows or Gates.
------------------------------------------------------------------------


___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug