Fred Stluka via plug on 8 Apr 2021 18:27:25 -0700


[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: [PLUG] that's nice 

Thomas,


As long as I have physical access to the box, ...


Yes, physical access does open up a lot of possibilities.
But Microsoft keeps claiming that it doesn't.  NTFS was
supposed to prevent live CD attacks.  But of course it
didn't.  Just needed a live CD with a driver for the NTFS
file system, which was pretty easy to come by.  Doh!

I agree that it's better to get permission.  I do that whenever
possible.  But sometimes it's the middle of the night, and
the product absolutely, positively has to go out the door by
8am tomorrow.  To prevent the client from losing a ton of
money by missing a regulatory deadline or a market window.
In such cases I've occasionally been known to do the client
a favor.

When necessary, I rely on the rule that "it's easier to get
forgiveness than permission".  And even occasionally,
"what they don't know won't hurt them".  Especially if the
"policy" was put in place by a sys admin who's not answering
my phone call at this time of night.  Or one who knows and
trusts me well enough to prefer I deal with it myself, and let
him sleep.

Rule #1: In any job, always befriend the support staff!  See:
- http://bristle.com/Tips/Career.htm#support_the_support_staff



How's that not similar to what you describe doing with windows registry
files?


The big difference is that I can do it on any Windows box, local
or remote, without requiring physical access.  Also without
rebooting, which might be a red flag to a security person.

Windows doesn't really have file permissions at all, or at least
they're pretty much always not being used, or are being deleted
from files all the time.  So the registry tries to be a file system
within a file, with its own set of permissions via its own access
control mechanism.

Here are 2 more snippets that I plan to include in that same
upcoming series of "Captain Underpants" tips:

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

*Unix/Linux file permissions*

In the Unix/Linux world, files are protected by file permissions.
The owner of each file sets the permissions of the file to say
which other users can run, read, modify and/or delete the file.
And which other users can modify the permissions of the file.
So, you might typically allow read access to many of your files
by many or all users.  But allow write access to few or none.

This has always been critical because right from the start in
the 1970's, Unix computers could be shared by multiple
users, networked with other Unix computers, etc.  It was
always important to protect the files of one user from other
users.

*Windows lack of file permissions*

In Windows, there are no file permissions.  On older, less
powerful PC hardware, resources were pretty tight, things
ran slower, RAM and disk space was expensive.  And
security wasn't a concern.  PCs were not networked to
other PCs.  Each one was a single user "toy"computer, not
a real computer.  No need to protect one user's files from
other users.

If your kid got into the PC in your home office and messed
up your budget spreadsheet, you yelled at him and told
him to not do that again.  So, older versions of Windows
had no file permissions, or logins, or any other security.
That was unnecessary, and would have slowed them down
too much, and consumed too much RAM and disk space.

Even on modern PC's that run the latest versions of
Windows, and the latest file system types, most Windows
installations have file permissions turned off, or set to
allow anyone to do anything to any file.

Most Windows users are not used to even thinking about
file permissions.  They're used to older Windows versions
that didn't have any file permissions at all.  Or they're still
using an older file system format like FAT or FAT32 that
doesn't store file permissions.  So anyone can still do
anything to any file.

Even if their hard drive uses a newer file system format like
NTFS that DOES store file permissions, they're probably
moving files between PCs via USB drives that are formatted
with the FAT32 file system that does NOT.  Or copying them
across the LAN or the Internet to PCs that use FAT32.  So
as they copy files around, the permissions are silently
stripped off, so anyone can do anything to the files.

So basically, in Windows, there are no file permissions.

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

Yeah, I'll have to actually finish writing and publish this
series soon.  But, I have a couple of other series queued
up first, and I try to never send out more than 1 tip per
day so my subscribers don't get overwhelmed.  Soon...

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

On 4/8/21 7:33 PM, Thomas Delrue via plug wrote:

I'm with Walt on this one.

As for Fred's suggestion: I see where you're going, but Linux isn't
"that much different" either for this type of attack.

As long as I have physical access to the box, and I can boot from any
medium I want, I can run a Live version of my favorite distro and
replace any binary that I want with my favorite malware to ensure it
runs on next boot.
Heck, from that live-cd (let's call it that, because I'm old enough to
remember knoppix), I can edit anything in /etc, /root, or wherever... I
can even create cron-jobs that run the malware-of-my-choice as root
every 5 minutes next time you boot up.

How's that not similar to what you describe doing with windows registry
files?

Be careful shouting "Windows is not secure, and it's all just security
through obscurity". That's a knife that can cut both ways.

But yeah, what Walt said; there's a reason those policies are in place
(typically because some 'other dumb user' did something 'unwise' and now
we gotta protect ourselves against /that/ too). Circumventing those
should be considered a Career Limiting Move and are not advised!
Better to work the system and see if you can get an exemption or
elevated privileges from those who can bestow those. If not, then I'm
sure there's a reason for that too (see 'some other dumb user' reference
before).

On 4/8/21 19:11, Walt Mankowski via plug wrote:

Changing obscure registry settings to override your organization's
security and virus-checking settings on company-owned hardware and/or
while on the company's VPN sounds like what we used to call a
"career-limiting move". If they find out they may very well decide to
fire you for ignoring company policy. Do this at your own risk.

On Thu, Apr 08, 2021 at 06:58:41PM -0400, Fred Stluka via plug wrote:

Jeff (and other PLUG folks),

Even if your not a member of the Administrators group, you
can probably just casually walk around any restrictions and
do whatever you want.  Windows has no security, only
obscurity, and it's really not even very obscure.

I haven't had time to write it up formally as a tip yet, but I've
mapped out an entire tip series on my ongoing battle with
"Captain Underpants" (as I call the collective groups of folks
at Microsoft who make the high level architectural decisions).
This is an excerpt I've roughed out that applies to your
situation.

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

*Windows obscurity over security*

To this day, on Windows, there's no real security.  Just
obscurity.  So if you know what value to change and where,
you can easily break into anything.  Most everything is still
stored in the registry, which is still an unprotected binary
file with a proprietary format.

So everything is supposedly obscure and secret, but nothing
is really secure.  And it turns out, it's not that obscure either
because it's the same on every Windows PC in the entire world.

Imagine you want to do something on a Windows PC, but don't
have permission because a Windows "policy" set by a sys admin
disallows it.  just go to another PC where you have admin rights,
dump the registry file to an ASCII text REG file, set the policy to
allow it, then dump the registry again, and diff the 2 REG files.
Copy the part that enforces the "policy" (now allowing it).
Paste into into a new REG file.  Apply that REG file to the target
PC with the REGEDIT or REGEDT32 command.  You're in!

If there's a policy that says you can't apply a REG file to change
that part of the registry, no worries.  That policy is also stored
in the registry.  See where I'm going with this?  Go to the other
PC, dump the registry, change that policy to say you ARE
allowed to edit the desired part of the registry, re-dump, diff,
copy, paste, and apply to the target PC.  Easy-peasy!

I used this technique at a large international corp once.  I was
a consultant writing a web app for them.  My web app needed
to be allowed to do something when run by one of their users.
But their was a Windows policy in place that said the users
couldn't do it.  So I created a REG file and pushed it to the web
site.  Told the users that if they got an error, just click on the
REG file.

Windows used its "file associations" to automatically run
REGEDIT when the REG file was clicked.  It updated the registry
and they were now allowed to do what they needed to do.

The sys admins didn't like that at all.  So, they added a new
policy that said users couldn't make changes to that part of
the registry.  So I updated the REG file to first say that, yes,
they COULD make such changes, and then to proceed to
make the changes.  I even had it change the policy back
afterwards so the new policy was still in effect, to prevent
the users from accidentally being allowed to make other
changes that the sys admins wanted to disallow.  The sys
admins never even noticed that I had casually strolled
around their best efforts at "security".

As with most (all?) Windows "security, it was like putting a lock
on the front door and the key under a specific rock in the
garden.  But all Windows systems have the same lock, with the
same key under the same rock.  So I was easily able to find the
rock (diff the 2 dumped reg files), copy the key (copy/paste
into new file), open the door (run the REG file) and then put the
key back under the rock (also done by running the REG file).

Once I automated it like that, any user could break in with a
simple click of a REG file, without having to know any of the
security details.  And it left the door locked behind them
when they were done so no one would know they'd been
there.  Doh!

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

Once I write up the series of tips, I'll mail it to my "Windows
Users" mailing list, my "Computer Security" mailing list, and
perhaps a few others.  And of course, post it to the Tips
pages that archive mailings to those lists.  Many of you are
already on those mailing lists.  The rest of you should feel
free to subscribe at:
- http://bristle.com/invite

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

On 4/5/21 9:26 AM, Thomas Delrue via plug wrote:

Then your only avenue is to actually talk to those who locked you out
and convince them to change how that task is configured... That'll
likely be a bit of an undertaking.
Just like on linux, you need permissions to modify the process you want
to modify.

There's even a chance that they themselves don't even have the ability
to change the priority of that task because it could be that it is
configured by the AV installer which obviously configures it as "Highest
Priority" because it's the only thing that matters in the world
according to itself.

You could always ask for local root as well: a no is what you have, a
yes is what you could get.

On 4/5/21 09:19, jeffv via plug wrote:

Thanks for the info, but I don't have admin.
Normally that would piss me off, but I think they did a good job of
locking things down to keep us safe from ourselves (and maybe even others).

The program eats everything, making opening browser tabs an event.


On 4/5/21 8:53 AM, Thomas Delrue wrote:

If you're a member of the administrators group, the command you're
looking for is
      taskkill /im application.exe /f

:P

Otherwise, if you want to stay 'nice', you can hop into the task
manager, right click on the process that eating up all your CPU and
select "Change Priority".
It will try to scare you out of doing that but just proceed, everything
is fine.

All of this will only work if you're on an account that has privileges
over that process.

More systemically, good luck on convincing those folks that that process
should be run in a more 'nice way'. Let me know which arguments worked...

On 4/5/21 08:45, jeffv via plug wrote:

I'm fuming because w@rk runs virus scans which eat up every last
resource. I'm all for scans, but it runs at 100% cpu for hours. I want
to contact the correct people and discuss it with them...I don't know if
there's a Windows command to do this...


"Linux has a nice command, which can reduce the amount of resources a
program is eating."

What's it called?

Nice.

Yes, what is the nice program called.

It's nice.

I'm sure it is, but what's it called?

Nice.

Look, I understand it's nice to have this program, but what program?

Nice.

Ok, you fire up the program to help you. What do you run?

Nice.

and so on....

___________________________________________________________________________
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

___________________________________________________________________________
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

___________________________________________________________________________
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


___________________________________________________________________________
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


___________________________________________________________________________
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