Tracy Reed
2017-01-28 05:40:31 UTC
So I'm teaching this security class at UCSD. It just started this past
Tuesday and so far so good. They have had their first lecture and are
about to receive their first homework and quiz.
I am setting them up with virtual machines running CentOS 7. They will
be configuring and hardening these machines using what they learn in
class. I also want to get them some experience with log analysis and
intrusion detection.
I'm thinking I might want to backdoor their machines when I deploy them
so that throughout the course I can occasionally give them an "intruder"
to hunt.
Anyone have any clever ways to do this? Nothing too elaborate.
The machines will be installed via kickstart so I can drop whatever I
want into them all at that point. They will have ssh, http, and https
available publicly pointed at them through a firewall.
I'm thinking I might ship the boxes with a few different issues, like
they inherited the box from a previous admin who had already let it be
compromised.
1. I could give them a preinstalled user with a weak password (which I
know) so I can just ssh in. But one of their early tasks will be to
setup ssh with pubkey only auth. So if they accomplish the ssh config
task properly that won't work.
2. I could setup a vulnerable cgi somewhere so that when they bring
apache online and configure it I can exploit some command injection.
Dropping some extra config in /etc/httpd/conf.modules.d/00-base.conf
should be pretty simple.
3. I could have the box open an ssh out to my "command and control"
server. That might be the easiest and most flexible way. And systemd is
convoluted enough that it should make it difficult to find until I give
them a clue. But I don't have experience actually setting up such
reverse tunnels so I'll have to do some thinking on how to do this
reliably to always have a connection open.
Once in I want to leave a suspicious looking process running, modify a
file and see if they can detect it with FIM, make a bunch of noise in
the logs and see if they can detect it etc. The idea is to make the
course very hands on. It's easy enough to test if they can properly
harden the box as specified. More difficult to see if they can have
enough basic awareness and understanding to spot simple suspicious
activity.
Any other ideas that would allow me to get in using a non-obvious
method?
I think their final task will be to shutdown my non-obvious method of
access, probably with a hint given as this might be unnecessarily
tricky, and lock the intruder out of the system.
Have to be careful with this as it has to be doable and fair to
everyone. The idea isn't to trick anyone or be too sneaky. The goal is
for the student to learn something and be graded in a fair way.
And if any of my students are researching me on google or on this list
and get a leg up from this discussion, great! Intelligence
gathering/Open Source Intelligence (OSINT) is very important and you
just earned your points!
Tuesday and so far so good. They have had their first lecture and are
about to receive their first homework and quiz.
I am setting them up with virtual machines running CentOS 7. They will
be configuring and hardening these machines using what they learn in
class. I also want to get them some experience with log analysis and
intrusion detection.
I'm thinking I might want to backdoor their machines when I deploy them
so that throughout the course I can occasionally give them an "intruder"
to hunt.
Anyone have any clever ways to do this? Nothing too elaborate.
The machines will be installed via kickstart so I can drop whatever I
want into them all at that point. They will have ssh, http, and https
available publicly pointed at them through a firewall.
I'm thinking I might ship the boxes with a few different issues, like
they inherited the box from a previous admin who had already let it be
compromised.
1. I could give them a preinstalled user with a weak password (which I
know) so I can just ssh in. But one of their early tasks will be to
setup ssh with pubkey only auth. So if they accomplish the ssh config
task properly that won't work.
2. I could setup a vulnerable cgi somewhere so that when they bring
apache online and configure it I can exploit some command injection.
Dropping some extra config in /etc/httpd/conf.modules.d/00-base.conf
should be pretty simple.
3. I could have the box open an ssh out to my "command and control"
server. That might be the easiest and most flexible way. And systemd is
convoluted enough that it should make it difficult to find until I give
them a clue. But I don't have experience actually setting up such
reverse tunnels so I'll have to do some thinking on how to do this
reliably to always have a connection open.
Once in I want to leave a suspicious looking process running, modify a
file and see if they can detect it with FIM, make a bunch of noise in
the logs and see if they can detect it etc. The idea is to make the
course very hands on. It's easy enough to test if they can properly
harden the box as specified. More difficult to see if they can have
enough basic awareness and understanding to spot simple suspicious
activity.
Any other ideas that would allow me to get in using a non-obvious
method?
I think their final task will be to shutdown my non-obvious method of
access, probably with a hint given as this might be unnecessarily
tricky, and lock the intruder out of the system.
Have to be careful with this as it has to be doable and fair to
everyone. The idea isn't to trick anyone or be too sneaky. The goal is
for the student to learn something and be graded in a fair way.
And if any of my students are researching me on google or on this list
and get a leg up from this discussion, great! Intelligence
gathering/Open Source Intelligence (OSINT) is very important and you
just earned your points!
--
Tracy Reed
Tracy Reed