local user get created magically ! system hacked ?

Rick Stevens ricks at alldigital.com
Wed Dec 4 22:04:22 UTC 2013


On 12/04/2013 01:42 PM, Jehan Procaccia issued this missive:
> Le 04/12/2013 18:51, Rick Stevens a écrit :
>> On 12/03/2013 11:47 PM, Michael Schwendt issued this missive:
>>> On Tue, 03 Dec 2013 23:08:04 +0100, Jehan Procaccia wrote:
>>>
>>>> hello
>>>> I use about a hundred fedora19 stations in computer labs at our school
>>>> users accounts comes from an ldap directory and the homedir is
>>>> automounted via NFS.
>>>> However, recently I noticed that on some stations, local user account
>>>> had been created !
>>>> looking at the log file, I discovered in /var/log/secure something like
>>>> this:
>>>>
>>>> /accounts-daemon: request by system-bus-name ::1.733
>>>> [/usr/libexec/gnome-initial-setup pid:15259 uid:991]: create user
>>>> 'foobar'//
>>>> //useradd[29724]: new group: name=foobar, GID=1001//
>>>> //secure-20131117:Nov 15 17:16:43 b3-4 useradd[29724]: new user:
>>>> name=susana, UID=1001, GID=1001, home=/home/susana, shell=/bin/bash//
>>>> //secure-20131117:Nov 15 17:16:43 b3-4 useradd[29724]: add 'susana' to
>>>> group 'wheel'//
>>>> //secure-20131117:Nov 15 17:16:43 b3-4 useradd[29724]: add 'susana' to
>>>> shadow group 'wheel'/
>>>>
>>>> Scary ! how comes gnome-initial-setup could create users, and morever
>>>> add them to the wheel group !
>>>> could it be a bug in /gnome-initial-setup , /a feature side effect ? or
>>>> our students found a "back door" ?
>>>> any suggestion greatly appreciated .
>>>
>>> See what running
>>>
>>>    /usr/libexec/gnome-initial-setup --force-new-user
>>>
>>> does on one of your installed machines, where 'susana' has not been
>>> active
>>> before. Normally, it would prompt for the root password before
>>> creating a
>>> new account, but perhaps something else happens with your setup.
>>
>> In the old days, a process called 'firstboot' was run immediately upon
>> the first boot after a fresh install. firstboot was responsible for a
>> number of things, but one of them was setting up the first user account
>> and adding it to the "wheel" group because it was expected to be the
>> administrator's account. firstboot never asked for the root password as
>> it assumed it was being run as part of the install process by a human
>> who installed the system and would already know the root password.
>> Hence, the first user account was, by default, an administrative
>> account in the wheel group who could sudo any command.
>>
>> Once firstboot had been run, it disconnected itself from the boot
>> process by deleting a file in the root of the filesystem that an init
>> script looked for. If the file wasn't there, firstboot wouldn't run.
>>
>> I don't run gnome (because it's so damned bloated), so I'm not sure what
>> gnome-initial-setup does, but I suspect it took its cues from the old
>> firstboot mechanism. If so, then what probably happened is that the
>> install process was interrupted after the OS was installed. Whoever did
>> the install did NOT go through the first boot. "susana" was probably the
>> first person to see the machine, booted it and got the first boot thing.
>> She added herself, not knowing exactly what this meant at the time. I
>> doubt she was being malicious.
>>
>> These are just guesses, mind you, but seem to be a likely scenario.
> This senario is very possible
> we installed our station automatically (cobbler2 kickstart + cfengine3
> for post config) and remotely , it is possible that some stations didn't
> finish correctly the install process
> and that the "firstboot" process didn't finished properly .
> Do you know how to check on a station if the "firstboot process" state
> is still "on" or "off", what about that mysterious file you mention
> "/it disconnected itself from the boot //
> //process by deleting a file in the root of the filesystem that an init //
> //script looked for. If the file wasn't there, firstboot wouldn't run./"
> what is its name ?

On old systems (e.g. CentOS 5/6), the /etc/rc.d/init.d/firstboot script
looked for an /etc/sysconfig/firstboot file. That file would contain
either

	RUN_FIRSTBOOT=YES

to run firstboot, or

	RUN_FIRSTBOOT=NO

so it didn't run. Also, if the /etc/reconfigSys file was present, then
firstboot would be run with the "--reconfig" option.

Again, I don't run gnome (I'm an XFCE user) so I don't know if it's a
systemd service that should run and then remove itself or what. To be
honest, I haven't done a fresh Fedora installation (F18 or F19) in a
while (I've "fedup"ped already installed systems).

> could this pb be relatated to:
> https://bugzilla.redhat.com/show_bug.cgi?id=968582
> not sure, because on a station that has the pb it seems disabled:
>
> # /bin/systemctl status initial-setup-text.service
> initial-setup-text.service - Initial Setup configuration program (text mode)
>     Loaded: loaded (/usr/lib/systemd/system/initial-setup-text.service;
> disabled)
>     Active: inactive (dead)

It'd be interesting to bring up a system and see if that service is set
to start on the first boot after an install.

> and I do run my kickstart with
> firstboot --disabled

That may not have an effect as I don't think there is a "firstboot"
thing since we went to systemd/systemctl rather than the classic init
scripts. I think that initial-setup-text.service and/or the 
gnome-initial-setup thing may have replaced that. Since I never installed
Gnome, I don't have the gnome-initial-setup program nor do I seem to
have a initial-setup-text.service file.

I wish I could be of more help.
----------------------------------------------------------------------
- Rick Stevens, Systems Engineer, AllDigital    ricks at alldigital.com -
- AIM/Skype: therps2        ICQ: 22643734            Yahoo: origrps2 -
-                                                                    -
-   UNIX is actually quite user friendly.  The problem is that it's  -
-              just very picky of who its friends are!               -
----------------------------------------------------------------------


More information about the users mailing list