Merge branch 's2progress' of https://github.com/cliffe/secgen into s2progress

This commit is contained in:
ts
2019-02-18 11:17:11 +00:00
22 changed files with 1008 additions and 8 deletions

View File

@@ -0,0 +1,35 @@
#!/usr/bin/ruby
require_relative '../../../../../../lib/objects/local_hackerbot_config_generator.rb'
class HB < HackerbotConfigGenerator
attr_accessor :server_ip
def initialize
super
self.module_name = 'Hackerbot Config Generator Authentication'
self.title = 'Authentication'
self.local_dir = File.expand_path('../../',__FILE__)
self.templates_path = "#{self.local_dir}/templates/"
self.config_template_path = "#{self.local_dir}/templates/lab.xml.erb"
self.html_template_path = "#{self.local_dir}/templates/labsheet.html.erb"
self.server_ip = []
end
def get_options_array
super + [['--server_ip', GetoptLong::REQUIRED_ARGUMENT]]
end
def process_options(opt, arg)
super
case opt
when '--server_ip'
self.server_ip << arg;
end
end
end
HB.new.run

View File

@@ -0,0 +1,39 @@
<?xml version="1.0"?>
<generator xmlns="http://www.github/cliffe/SecGen/generator"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.github/cliffe/SecGen/generator">
<name>Hackerbot config for an access control lab</name>
<author>Z. Cliffe Schreuders</author>
<module_license>GPLv3</module_license>
<description>Generates a config file for a hackerbot for an integrity lab.
Topics covered: .</description>
<type>hackerbot_config</type>
<platform>linux</platform>
<read_fact>accounts</read_fact>
<read_fact>flags</read_fact>
<read_fact>root_password</read_fact>
<!--TODO: require input, such as accounts, or fail?-->
<default_input into="accounts">
<generator type="account">
<input into="username">
<value>vagrant</value>
</input>
</generator>
</default_input>
<default_input into="flags">
<generator type="flag_generator"/>
</default_input>
<default_input into="root_password">
<value>puppet</value>
</default_input>
<output_type>hackerbot</output_type>
</generator>

View File

@@ -0,0 +1,29 @@
<html>
<head>
<title><%= self.title %></title>
</head>
<body>
<meta name="viewport" content="width=device-width, initial-scale=1">
<link rel="stylesheet" href="css/github-markdown.css">
<style>
.markdown-body {
box-sizing: border-box;
min-width: 200px;
max-width: 980px;
margin: 0 auto;
padding: 45px;
}
@media (max-width: 767px) {
.markdown-body {
padding: 15px;
}
}
</style>
<article class="markdown-body">
<%= self.html_rendered %>
</article>
<script src="js/code-prettify/loader/run_prettify.js"></script>
</body>
</html>

View File

@@ -0,0 +1,4 @@
## License
This lab by [*Z. Cliffe Schreuders*](http://z.cliffe.schreuders.org) at Leeds Beckett University is licensed under a [*Creative Commons Attribution-ShareAlike 3.0 Unported License*](http://creativecommons.org/licenses/by-sa/3.0/deed.en_GB).
Included software source code is also licensed under the GNU General Public License, either version 3 of the License, or (at your option) any later version.

View File

@@ -0,0 +1,195 @@
## Introducing Full Access Control List (ACL) File Permissions
An *access control list (ACL)* is attached to an object (resource) and lists all the subjects (users / active entities) that are allowed access, along with the kind of access that is authorised.
We have explored standard Unix file permissions, which is an abbreviated (simplified) ACL. With standard Unix file permissions all authorisation is defined in terms of the owning user (u), groups (g), and others (o), and the type of access that can be granted are read (r), write (r), and execute (x) -- along with some special permission flags, SUID, SGID, and stickybit, which change the meaning of these.
The Unix file permissions (0664) `-rw-rw-r-- 1 user1 group1 5 Feb 5 test` can be thought of as a simplified ACL with:
Subject | Permission
--- | ---
user1 | read, write
members of group1 | read, write
everyone else | read
While this is an effective way of representing permissions, and is often adequate, using traditional file permissions there is no way of representing more complicated rules, such as also granting specific users access to write the file without making them members of group1.
Modern systems (Windows, Linux, and some other Unix-based systems) now have more complete (and complicated) ACL support, enabling more fine-grained control over authorisation.
A more expressive ACL for a file can represent a state such as:
Subject | Permission
--- | ---
user1 | read, write
user2 | read, write
members of group1 | read, write
members of group2 | read
everyone else | nothing
## Linux Extended ACLs
Linux now has support for full ACLs (known as Linux ACLs or POSIX ACLs). Linux ACLs can include entries for named users and named groups.
ACLs require compatible filesystems so that they can be stored. Linux ACLs are saved as extended attributes (EA), which is used to associate metadata with files.
Linux ACLs that are equivalent with Unix file permissions are known as **minimal ACLs**. Linux ACLs with more than these three entries (owner user, owner group, and others) are known as **extended ACLs**.
Subject type | Text representation
--- | ---
Owner | user::rwx
Named user | user:name:rwx
Owning group | group::rwx
Named group | group:name:rwx
Mask | mask::rwx
Other | other::rwx
The Owner (user::xxx) and Other (other:xxx) permissions are automatically synced to the Unix file permission bits.
==Set a file ACL on your mysecret file==, using the setfacl command:
```bash
setfacl -m u:user2:r ~/mysecret
```
> The `-m` flag specifies that the ACL is to be modified
> `u:` or `user:` specifies a rule for a named user
> `g:` or `group:` could be used for a named group
> This is followed by the name of the user or group
> Finally read (r), write (w), and/or execute (x) can be specified using letters (rwx) or a number (7, which is the octet representing wrx)
This grants user2 read access to the file (without requiring access granted to any other groups or users).
==Confirm you can access the file from user2:==
```bash
su - user2
cat /home/user1/mysecret
exit
```
Note that the stat program is not usually ACL aware, so won't report anything out of the usual. ==Run:==
```bash
stat ~/mysecret
```
The ls program can be used to detect File ACLs. ==Run:==
```bash
ls -la ~/mysecret
```
`-rw-r-----+ 1 user1 user1 22 Feb 28 11:47 mysecret`
Note that the output includes a `+`. This indicates an ACL is in place.
==Use getfacl to display the permissions:==
```bash
getfacl ~/mysecret
```
## Mask
Extended ACLs contain a mask entry that defines the upper bound (maximum permissions) that can be assigned by the ACL rules that apply to any named users or groups. This mask (mask::xxx) is typically automatically updated to the union (maximum) of all permissions granted, and automatically synced with the value of the group Unix file permission bits.
==Grant full rwx permission to user2:==
```bash
setfacl -m u:user2:rwx ~/mysecret
```
==View the updated permissions visible via `ls`:==
```bash
ls -la ~/mysecret
```
Note that the group file permission has changed (in addition to the `+`, this helps to show the level of permission that can result from the new ACL rule.
Again ==use getfacl to display the ACL rules:==
```bash
getfacl ~/mysecret
```
Note that the mask has changed.
==Change the mask value to "r"==
> Hint: see the table above that describes the text representation.
==Confirm user2 can no longer access the file due to the mask, even though they have rwx permission.==
## Understanding the access check behaviour
The decision making logic has been described as follows:
>If
>>the user ID of the process is the owner, the owner entry determines access
>else if
>>the user ID of the process matches the qualifier in one of the named user entries, this entry determines access
>else if
>>one of the group IDs of the process matches the owning group and the owning group entry contains the requested permissions, this entry determines access
>else if
>>one of the group IDs of the process matches the qualifier of one of the named group entries and this entry contains the requested permissions, this entry determines access
>else if
>>one of the group IDs of the process matches the owning group or any of the named group entries, but neither the owning group entry nor any of the matching named group entries contains the requested permissions, this determines that access is denied
>else
>>the other entry determines access.
>If
>>the matching entry resulting from this selection is the owner or other entry and it contains the requested permissions, access is granted
>else if
>>the matching entry is a named user, owning group, or named group entry and this entry contains the requested permissions and the mask entry also contains the requested permissions (or there is no mask entry), access is granted
>else
>>access is denied.
Quoted from (Grünbacher, 2003) [^1]
## Default ACLs
Directories can have two kinds of ACLs: **access ACLs** (which define the actual rules applied -- this is what we have been using so far), and **default ACLs**.
Default ACLs set the ACL rules that are applied to any new files created in the directory. Directories created inherit the default ACL, as the new access ACL and default ACL.
When a default ACL is specified on the parent directory, `umask` has no effect on the permissions of new files.
==Create a directory to share with user2:==
```bash
mkdir shared
setfacl -m u:user2:rw -d -m u:user2:rw shared
```
==Create a new file in the shared directory.==
==View the ACL created on the new file.==
## Comparison with Windows ACLs
Windows file permissions are similar to Linux ACLs, although they are slightly more complicated.
On Windows permissions are dynamically inherited and checked at access time. Changing permissions on a directory can change the permissions applied to the files within (or even changing the permissions of a directory's parent directory!). Linux ACLs only inherit permissions from default ACLs when they are created, and there is no complicated checking of all the parent directories to calculate access permissions.
Windows has lots more kinds of access that can be assigned (including append and delete permissions, and ACLs can contain rules about inheritance logic, and deny permissions), compared to Linux ACLs that define rules in terms of read, write, and execute (rwx).
Linux ACLs use local UIDs and GIDs to assign identity to all subjects (even when authenticating against remote servers, local UIDs are generated). Windows uses global security identifers (SIDs) that can be local or for domain users (authenticated against a domain controller, the global SID is used on ACLs).
## Hackerbot challenges
## ---------------
Use Linux File ACLs to grant one or more specific users (other class members) read access to your mysecrets file.
Using ACLs, grant any other group (you choose) read-write access to your mygroupshare file.
Remove the group permission you just added.
> Example: `setfacl -x g:staff file`

View File

@@ -0,0 +1,34 @@
# Access Controls: Access Control Lists
## Getting started
### VMs in this lab
==Start these VMs== (if you haven't already):
- hackerbot_server (leave it running, you don't log into this)
- desktop (you can sudo to get superuser access)
- server (<%= $server_ip %>, you can ssh to this machine, but you don't have superuser access)
### Your login details for the "desktop" and "server" VMs
User 1: <%= $main_user %>
Password: tiaspbiqe2r (**t**his **i**s **a** **s**ecure **p**assword **b**ut **i**s **q**uite **e**asy **2** **r**emember)
User 2: <%= $second_user %>
Password: <%= $second_password %>
You won't login to the hackerbot_server, but the VM needs to be running to complete the lab.
### For marks in the module
1. **You need to submit flags**. Note that the flags and the challenges in your VMs are different to other's in the class. Flags will be revealed to you as you complete challenges throughout the module. Flags look like this: ==flag{*somethingrandom*}==. Follow the link on the module page to submit your flags.
2. **You need to document the work and your solutions in a Log Book**. This needs to include screenshots (including the flags) of how you solved each Hackerbot challenge and a writeup describing your solution to each challenge, and answering any "Log Book Questions". The Log Book will be submitted later in the semester.
## Meet Hackerbot!
![small-right](images/skullandusb.svg)
This exercise involves interacting with Hackerbot, a chatbot who will attack your system. If you satisfy Hackerbot by completing the challenges she will reveal flags to you.
> If Hackerbot seems to be waiting or halted, simply say 'hi'
Work through the below exercises, completing the Hackerbot challenges as noted.
---

View File

@@ -0,0 +1,161 @@
<%
require 'json'
require 'securerandom'
require 'digest/sha1'
require 'fileutils'
require 'erb'
if self.accounts.empty?
abort('Sorry, you need to provide an account')
end
$first_account = JSON.parse(self.accounts.first)
$main_user = $first_account['username'].to_s
$main_user_pass = $first_account['password'].to_s
$second_account = JSON.parse(self.accounts[1])
$second_user = $second_account['username'].to_s
$second_password = $second_account['password'].to_s
$third_account = JSON.parse(self.accounts[2])
$third_user = $third_account['username'].to_s
$third_password = $third_account['password'].to_s
$server_ip = self.server_ip.first
$root_password = self.root_password
$flags = self.flags
REQUIRED_FLAGS = 1
while $flags.length < REQUIRED_FLAGS
$flags << "flag{#{SecureRandom.hex}}"
Print.err "Warning: Not enough flags provided to hackerbot_config generator, some flags won't be tracked/marked!"
end
def get_binding
binding
end
-%>
<?xml version="1.0"?>
<hackerbot
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.github/cliffe/SecGen/hackerbot">
<!--<hackerbot xmlns="http://www.github/cliffe/SecGen/hackerbotz"-->
<name>Hackerbot</name>
<AIML_chatbot_rules>config/AIML</AIML_chatbot_rules>
<!--Method for gaining shell access, can be overwritten per-attack-->
<get_shell>sshpass -p <%= $root_password %> ssh -oStrictHostKeyChecking=no root@{{chat_ip_address}} /bin/bash</get_shell>
<messages>
<show_attack_numbers />
<greeting>Hi there. Solve some challenges and I'll give you some flags.</greeting>
<!--Must provide alternatives for each message-->
<say_ready>When you are ready, simply say 'ready'.</say_ready>
<say_ready>'Ready'?</say_ready>
<next>Ok, I'll do what I can to move things along...</next>
<next>Moving things along to the next one...</next>
<previous>Ok, I'll do what I can to back things up...</previous>
<previous>Ok, backing up.</previous>
<goto>Ok, skipping it along.</goto>
<goto>Let me see what I can do to goto that attack.</goto>
<last_attack>That was the last one for now. You can rest easy, until next time... (End.)</last_attack>
<last_attack>That was the last one. Game over?</last_attack>
<first_attack>You are back to the beginning!</first_attack>
<first_attack>This is where it all began.</first_attack>
<getting_shell>Doing my thing...</getting_shell>
<getting_shell>Here we go...</getting_shell>
<got_shell>...</got_shell>
<got_shell>....</got_shell>
<repeat>Let me know when you are 'ready', if you want to move on say 'next', or 'previous' and I'll move things along.</repeat>
<repeat>Say 'ready', 'next', or 'previous'.</repeat>
<!--Single responses:-->
<help>I am waiting for you to say 'ready', 'next', 'previous', 'list', 'goto *X*', or 'answer *X*'</help>
<say_answer>Say "The answer is *X*".</say_answer>
<no_quiz>There is no question to answer</no_quiz>
<correct_answer>Correct</correct_answer>
<incorrect_answer>Incorrect</incorrect_answer>
<invalid>That's not possible.</invalid>
<non_answer>Wouldn't you like to know.</non_answer>
<!--can be overwritten per-attack-->
<shell_fail_message>Oh no. Failed to get shell... You need to let us in.</shell_fail_message>
</messages>
<tutorial_info>
<title>Access Controls: ACLs</title>
<tutorial><%= ERB.new(File.read self.templates_path + 'intro.md.erb').result(self.get_binding) %></tutorial>
<footer>
<%= File.read self.templates_path + 'resources.md.erb' %>
<%= File.read self.templates_path + 'license.md.erb' %>
Randomised instance generated by [SecGen](http://github.com/cliffe/SecGen) (<%= Time.new.to_s %>)
</footer>
<provide_tutorial>true</provide_tutorial>
</tutorial_info>
<attack>
<% $rand_secret1 = "secret#{SecureRandom.hex(3)}" %>
<% $secret_file = "/home/#{$main_user}/mysecret" %>
<% $suid_program = "/home/#{$main_user}/access_my_secrets" %>
<% $suid_program_path = "/home/#{$main_user}" %>
<prompt>Add "<%= $rand_secret1 %>" to <%= $secret_file %> and make the file only available to the <%= $second_user %> user via a SUID execuable at <%= $suid_program %>.</prompt>
<post_command>grep <%= $rand_secret1 %> <%= $secret_file %>; echo contents-$?-; cd <%= $suid_program_path %>; sudo -u <%= $second_user %> <%= $suid_program %> | grep <%= $rand_secret1 %> >/dev/null; echo suid-$?-; sudo -u <%= $second_user %> cat <%= $secret_file %> | grep <%= $rand_secret1 %> >/dev/null; echo direct-$?-</post_command>
<condition>
<output_matches>contents-[1-9]+</output_matches>
<message>:( It looks like the file might not exist or not contain the message.</message>
</condition>
<condition>
<output_matches>direct-0-</output_matches>
<message>:( Other users can access the file directly, make sure it's only avaiable via the SUID program</message>
</condition>
<condition>
<output_matches>suid-0-</output_matches>
<message>:) Well done! <%= $flags.pop %></message>
<trigger_next_attack />
</condition>
<else_condition>
<message>:( Something was not right</message>
</else_condition>
<tutorial><%= ERB.new(File.read self.templates_path + 'facls.md.erb').result(self.get_binding) %></tutorial>
</attack>
<attack>
<prompt>There are two problem solving challenges on the server. Look at the home directories and the .c files. 1: Use the access_my_flag program to access the two flags (hint: think about how you can use hardlink trickery to access relative paths). 2: Look at the two shell programs and how you can combine them together to get at a flag. This is the end.</prompt>
<condition>
<output_matches>.*</output_matches>
<message>:)</message>
<trigger_next_attack />
</condition>
<condition>
<output_matches>.*</output_matches>
<message>:)</message>
<trigger_next_attack />
</condition>
<else_condition>
<message>:)</message>
</else_condition>
</attack>
<!-- TODO: add another attack where HB uses a hardlink attack against the SUID program - they have to fix the problem -->
</hackerbot>

View File

@@ -0,0 +1,114 @@
<html>
<head>
<title><%= self.title %></title>
</head>
<body>
<meta name="viewport" content="width=device-width, initial-scale=1">
<link rel="stylesheet" href="css/github-markdown.css">
<style>
.markdown-body {
box-sizing: border-box;
min-width: 200px;
max-width: 980px;
margin: 0 auto;
padding: 45px;
}
.markdown-body h4[id^='hackerbot']:after {
display: inline-block;
float: right;
content: url("images/skullandusb.svg");
width: 30px;
}
article {
float: right;
width: calc(100% - 300px);
}
.toc {
float: left;
font-size: smaller;
color: #1a1d22;
width: 300px;
position: fixed;
height: calc(100% - 56px);
overflow-y: scroll;
font-family: sans-serif;
margin-top: 50px;
}
.toc ul {
list-style-type: none;
padding: 0;
margin-left: 1em;
}
.toc li { /* Space between menu items*/
margin: 1em 0;
}
.toc a {
color: #1a1d22;
text-decoration: none;
}
.toc a:hover {
color: #6c036d;
text-decoration: none;
}
.toc a:visited {
color: #1a1d22;
text-decoration: none;
}
.markdown-body pre, .markdown-body code {
background-color: #570138;
color: whitesmoke;
}
.markdown-body img[alt="small-left"] {
max-width: 100px;
float: left;
}
.markdown-body img[alt="small-right"] {
max-width: 100px;
float: right;
}
.markdown-body img[alt="tiny-right"] {
max-width: 30px;
float: right;
}
.markdown-body img[alt="small"] {
max-width: 100px;
display: block;
margin-left: auto;
margin-right: auto;
padding: 15px;
}
mark {
background-color: white;
color: #5b29bd;
font-weight: bolder;
}
@media (max-width: 767px) {
.markdown-body {
padding: 15px;
min-width: 200px;
max-width: 980px;
}
.toc {
float: none;
width: 100%;
position: relative;
overflow: auto;
height: auto;
}
article {
float: none;
width: 100%;
}
}
</style>
<div class="toc">
<%= self.html_TOC_rendered %>
</div>
<article class="markdown-body">
<%= self.html_rendered %>
</article>
<script src="js/code-prettify/loader/run_prettify.js?autoload=true&amp;skin=sunburst&amp;lang=css"></script>
</body>
</html>

View File

@@ -0,0 +1,6 @@
## License
This lab by [*Z. Cliffe Schreuders*](http://z.cliffe.schreuders.org) at Leeds Beckett University is licensed under a [*Creative Commons Attribution-ShareAlike 3.0 Unported License*](http://creativecommons.org/licenses/by-sa/3.0/deed.en_GB).
Included software source code is also licensed under the GNU General Public License, either version 3 of the License, or (at your option) any later version.
![small](images/leedsbeckett-logo.png)

View File

@@ -0,0 +1,5 @@
# Resources
This excellent paper describes Linux ACL in detail:
[^1]: Grünbacher, Andreas. "POSIX Access Control Lists on Linux." *USENIX Annual Technical Conference*, FREENIX Track. 2003.
<https://www.usenix.org/legacy/events/usenix03/tech/freenix03/full_papers/gruenbacher/gruenbacher.pdf>

View File

@@ -0,0 +1,35 @@
# CONVERT THESE INTO HB CHALLENGES
==Create a file "~/myshare", and grant everyone read-write access.==
> Test whether you have correctly set permissions.
==Create "mygroupshare", grant only read access to everyone in your group.==
> Test whether you have correctly set permissions.
Create a new group called "staff", and create a file that you and the other user can collaborate on (both edit).
> Hint, you should both be added to the group. You may require root access for this task. Your classmate may want to ssh to your system.
>
> Test whether you have correctly set permissions. Both users should be able to edit the file, yet other users should not have write access.
Read and write to the shared files created by others, for example:
```bash
cat /home/*dropbear*/myshare
```
**Challenge**:
```bash
mkdir test
```
```bash
touch test/test1 test/test2 test/test3
```
> Use a single chmod command to recursively set the permissions for all files contained in the new "test" directory.
>
> Hint: `man chmod`

View File

@@ -135,7 +135,7 @@ Randomised instance generated by [SecGen](http://github.com/cliffe/SecGen) (<%=
<attack>
<prompt>There are two problem solving challenges on the server. Look at the home directories and the .c files. 1: Use the access_my_flag program to access the two flags (hint: think about how you can use hardlinks to access relative paths). 2: Look at the two shell programs and how you can combine them together to get at a flag. This is the end.</prompt>
<prompt>There are two problem solving challenges on the server. Look at the home directories and the .c files. 1: Use the access_my_flag program to access the two flags (hint: think about how you can use hardlink trickery to access relative paths). 2: Look at the two shell programs and how you can combine them together to get at a flag. This is the end.</prompt>
<condition>
<output_matches>.*</output_matches>

View File

@@ -161,6 +161,8 @@ Note that the effective ID is that of the owner of the program. You should also
Think about the security of this solution. How secure is it? Would it be safe for root to be the owner of this program? Why not? (You will come back to this.)
> Hint: the system will be particularly vulnerable when fs.protected_hardlinks = 0 (you can run `echo 0 | sudo tee /proc/sys/fs/protected_hardlinks` to disable hardlink protection, as is the case on some Unix/Linux systems).
==**Recommended AFTER completing all the flags:**==
==Lab Book Question:== It is possible to use this SUID program to get read access to **any** one of the owner user's files! Modify the program to correct the above vulnerability.

View File

@@ -1,4 +1,4 @@
class gcc::install{
class gcc::install {
package { ['build-essential', 'gcc-multilib']:
ensure => 'installed',
}

View File

@@ -25,11 +25,14 @@ define relative_path_suid_hardlinks::account($username, $password, $strings_to_l
source => 'puppet:///modules/relative_path_suid_hardlinks/access_my_flag.c',
}
file { '/etc/sysctl.d/hardlinks.conf':
content => "fs.protected_hardlinks = 0",
}
exec { "$username-compileandsetup2":
cwd => "/home/$username/",
command => "gcc -o access_my_flag access_my_flag.c && sudo chown $username access_my_flag && sudo chmod 4750 access_my_flag",
command => "gcc -o access_my_flag access_my_flag.c && sudo chown $username access_my_flag && sudo chmod 4755 access_my_flag",
path => [ '/bin/', '/sbin/' , '/usr/bin/', '/usr/sbin/' ],
require => Package['build-essential', 'gcc-multilib']
}
}

View File

@@ -7,7 +7,7 @@
<author>Z. Cliffe Schreuders</author>
<module_license>Apache v2</module_license>
<description>A setuid program feeds the user a flag from it's home directory.
A second flag is available via hardlink trickery.
A second flag is available via hardlink trickery (possible due to disabled newer protections).
</description>
<type>system</type>

View File

@@ -30,14 +30,12 @@ define two_shell_calls::account($username, $password, $strings_to_leak, $leaked_
cwd => "/home/$username/",
command => "gcc -o shell shell.c && sudo chown $username:managers shell && sudo chmod 2755 shell",
path => [ '/bin/', '/sbin/' , '/usr/bin/', '/usr/sbin/' ],
require => Package['build-essential', 'gcc-multilib']
}
} else {
exec { "$username-compileandsetup2":
cwd => "/home/$username/",
command => "gcc -o shell shell.c && sudo chown $username:managers shell && sudo chmod 4750 shell",
path => [ '/bin/', '/sbin/' , '/usr/bin/', '/usr/sbin/' ],
require => Package['build-essential', 'gcc-multilib']
}
}

View File

@@ -148,6 +148,7 @@ int main()
</input>
</utility>
<utility module_path=".*handy_cli_tools"/>
<utility module_path=".*gcc"/>
<utility module_path=".*iceweasel">
<input into="accounts">

View File

@@ -0,0 +1,339 @@
<?xml version="1.0"?>
<scenario xmlns="http://www.github/cliffe/SecGen/scenario"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.github/cliffe/SecGen/scenario">
<name>Access Control Lists lab</name>
<author>Z. Cliffe Schreuders</author>
<description>A Hackerbot lab. Work through the labsheet, then when prompted interact with Hackerbot.</description>
<type>ctf-lab</type>
<type>hackerbot-lab</type>
<type>lab-sheet</type>
<difficulty>intermediate</difficulty>
<system>
<system_name>shared_desktop</system_name>
<base distro="Debian 9" type="desktop" name="KDE"/>
<input into_datastore="IP_addresses">
<!-- 0 desktop -->
<value>172.16.0.2</value>
<!-- 1 server -->
<value>172.16.0.3</value>
<!-- 2 hackerbot_server -->
<value>172.16.0.4</value>
</input>
<!-- generate some usernames to use -->
<input into_datastore="usernames">
<!-- main user -->
<generator type="random_word_generator">
<input into="wordlist">
<value>mythical_creatures</value>
</input>
</generator>
<!-- 4 other users -->
<generator type="random_word_generator">
<input into="wordlist">
<value>mythical_creatures</value>
</input>
</generator>
<generator type="random_word_generator">
<input into="wordlist">
<value>mythical_creatures</value>
</input>
</generator>
<generator type="random_word_generator">
<input into="wordlist">
<value>mythical_creatures</value>
</input>
</generator>
<generator type="random_word_generator">
<input into="wordlist">
<value>mythical_creatures</value>
</input>
</generator>
</input>
<!-- generate some passwords to be cracked -->
<input into_datastore="passwords">
<generator type="medium_password_generator"/>
<generator type="strong_password_generator"/>
<generator type="strong_password_generator"/>
<generator type="strong_password_generator"/>
</input>
<input into_datastore="groups">
<value>staff</value>
<value>team_one</value>
<value>team_two</value>
</input>
<!-- accounts on the desktop, with the main user as a sudoer -->
<input into_datastore="user_accounts_desktop">
<!-- main user, sudoer -->
<generator type="account">
<input into="username">
<datastore access="0">usernames</datastore>
</input>
<input into="password">
<value>tiaspbiqe2r</value>
</input>
<input into="super_user">
<value>true</value>
</input>
</generator>
<!-- other users, with weak passwords, no flags -->
<generator type="account">
<input into="username">
<datastore access="next">usernames</datastore>
</input>
<input into="password">
<datastore access="0">passwords</datastore>
</input>
</generator>
<generator type="account">
<input into="username">
<datastore access="next">usernames</datastore>
</input>
<input into="password">
<datastore access="next">passwords</datastore>
</input>
</generator>
<generator type="account">
<input into="username">
<datastore access="next">usernames</datastore>
</input>
<input into="password">
<datastore access="next">passwords</datastore>
</input>
</generator>
<generator type="account">
<input into="username">
<datastore access="next">usernames</datastore>
</input>
<input into="password">
<datastore access="next">passwords</datastore>
</input>
</generator>
</input>
<input into_datastore="desktop_root_password">
<generator type="strong_password_generator"/>
</input>
<!--Create the groups-->
<utility module_path=".*groups">
<input into="groups">
<datastore>groups</datastore>
</input>
</utility>
<!--Create the users-->
<utility module_path=".*parameterised_accounts">
<input into="accounts">
<datastore>user_accounts_desktop</datastore>
</input>
</utility>
<utility module_path=".*kde_minimal">
<input into="autologin_user">
<datastore access="0">usernames</datastore>
</input>
<input into="accounts">
<datastore>user_accounts_desktop</datastore>
</input>
<input into="autostart_konsole">
<value>true</value>
</input>
</utility>
<utility module_path=".*handy_cli_tools"/>
<utility module_path=".*hash_tools"/>
<utility module_path=".*pam_modules"/>
<utility module_path=".*iceweasel">
<input into="accounts">
<datastore>user_accounts_desktop</datastore>
</input>
<input into="autostart">
<value>true</value>
</input>
<input into="start_page">
<datastore access="2">IP_addresses</datastore>
</input>
</utility>
<utility module_path=".*pidgin">
<input into="server_ip">
<datastore access="2">IP_addresses</datastore>
</input>
<input into="accounts">
<datastore access="0">user_accounts_desktop</datastore>
</input>
</utility>
<vulnerability module_path=".*ssh_root_login">
<input into="root_password">
<datastore>desktop_root_password</datastore>
</input>
</vulnerability>
<network type="private_network">
<input into="IP_address">
<datastore access="0">IP_addresses</datastore>
</input>
</network>
</system>
<system>
<system_name>server</system_name>
<base distro="Debian 9" type="server"/>
<!-- user accounts on the server, with matching usernames and passwords, but with flags to find -->
<input into_datastore="user_accounts_server">
<!-- main user, NOT sudoer -->
<generator type="account">
<input into="username">
<datastore access="0">usernames</datastore>
</input>
<input into="password">
<value>tiaspbiqe2r</value>
</input>
<input into="super_user">
<value>false</value>
</input>
<input into="groups">
<value>staff</value>
<value>team_one</value>
</input>
</generator>
<!-- other users, with the SAME passwords -->
<generator type="account">
<input into="username">
<datastore access="next">usernames</datastore>
</input>
<input into="password">
<datastore access="0">passwords</datastore>
</input>
<input into="groups">
<value>staff</value>
<value>team_one</value>
<value>team_two</value>
</input>
</generator>
<generator type="account">
<input into="username">
<datastore access="next">usernames</datastore>
</input>
<input into="password">
<datastore access="next">passwords</datastore>
</input>
<input into="groups">
<value>staff</value>
<value>team_two</value>
</input>
</generator>
<generator type="account">
<input into="username">
<datastore access="next">usernames</datastore>
</input>
<input into="password">
<datastore access="next">passwords</datastore>
</input>
<input into="groups">
<value>staff</value>
</input>
</generator>
<generator type="account">
<input into="username">
<datastore access="next">usernames</datastore>
</input>
<input into="password">
<datastore access="next">passwords</datastore>
</input>
<input into="groups">
<value>staff</value>
</input>
<!-- <input into="leaked_filenames">
<value>flags</value>
</input>
<input into="strings_to_leak">
<generator type="flag_generator" />
<generator type="flag_generator" />
</input> -->
</generator>
</input>
<!--Create the groups-->
<utility module_path=".*groups">
<input into="groups">
<datastore>groups</datastore>
</input>
</utility>
<!--Create the users-->
<utility module_path=".*parameterised_accounts">
<input into="accounts">
<datastore>user_accounts_server</datastore>
</input>
</utility>
<utility module_path=".*handy_cli_tools"/>
<vulnerability module_path=".*ssh_root_login">
<input into="root_password">
<datastore>desktop_root_password</datastore>
</input>
</vulnerability>
<network type="private_network">
<input into="IP_address">
<datastore access="1">IP_addresses</datastore>
</input>
</network>
</system>
<system>
<system_name>hackerbot_server</system_name>
<base distro="Kali" name="MSF"/>
<service type="ircd"/>
<utility module_path=".*metasploit_framework"/>
<utility module_path=".*nmap"/>
<utility module_path=".*handy_cli_tools"/>
<service type="httpd"/>
<utility module_path=".*hackerbot">
<input into="hackerbot_configs">
<generator module_path=".*hb_facls">
<input into="accounts">
<datastore>user_accounts_desktop</datastore>
</input>
<input into="root_password">
<datastore>desktop_root_password</datastore>
</input>
<input into="server_ip">
<datastore access="1">IP_addresses</datastore>
</input>
</generator>
</input>
</utility>
<network type="private_network" >
<input into="IP_address">
<datastore access="2">IP_addresses</datastore>
</input>
</network>
<build type="cleanup">
<input into="root_password">
<generator type="strong_password_generator"/>
</input>
</build>
</system>
</scenario>

View File

@@ -114,7 +114,7 @@ def build_vms(scenario, project_dir, options)
end
# if deploying to ovirt, when things fail to build, set the retry_count
retry_count = OVirtFunctions::provider_ovirt?(options) ? 2 : 0
retry_count = OVirtFunctions::provider_ovirt?(options) ? 1 : 0
successful_creation = false
while retry_count >= 0 and !successful_creation