Root me write-up : Bash - cron

To comply with the write-up rule of root-me.org, in this write-up, I just talk about some hints related this challenge. Here is no solution and correct answer.

Check the provided file the "ch4". It executes files regularly with cron service and makes directory "._cron". It is driven with the permission to get the flag.

And this is some operations of bash script if statement :
1. -f : Exist & Regular file
2. -a : And
3. -x : Exist & Executable file

Using the above conditions, you can do anything with the given permission. But the directory creation strangely couldn't do.

Root me write-up : Python - input()

To comply with the write-up rule of root-me.org, in this write-up, I just listed hints related this challenge. Here is no solution and correct answer. I ask for your understanding.


<Source code>

#!/usr/bin/python2

import sys

def youLose():
    print "Try again ;-)"
    sys.exit(1)


try:
    p = input("Please enter password : ")
except:
    youLose()


with open(".passwd") as f:
    passwd = f.readline().strip()
    try:
        if (p == int(passwd)):
            print "Well done ! You can validate with this password !"
    except:
        youLose()

In this source code, there is "input()" function. It has a critical vulnerability, The post I wrote before about "input()" function maybe helps you.

Using this vulnerability can result in a number of cases. I could get the flags without satisfying the condition of the if statement.

Root me write-up : Perl - Command injection

Retrieve the password stored in .passwd.

There are .passwd, ch7.pl and setuid-wrapper files.

This challenge seems to read the .passwd file using the permissions of the setuid-wrapper file.

※ Two kinds of SUID(Link).

This program prompts you to enter a file path. Then it outputs the statistical results of the contents of the file.



<setuid-wrapper.c>

#include <stdlib.h>

/* setuid script wrapper */

int main()
{
    system("/challenge/app-script/ch7/ch7.pl");
    return 0;
}

<ch7.pl>

#!/usr/bin/perl

delete @ENV{qw(IFS CDPATH ENV BASH_ENV)};
$ENV{'PATH'}='/bin:/usr/bin';

use strict;
use warnings;

main();

sub main {
    my ($file, $line) = @_;

    menu();
    prompt();

    while((my $file = <STDIN>)) {
        chomp $file;

        process_file($file);

        prompt();
    }
}

sub prompt {
    local $| = 1;
    print ">>> ";
}
sub menu {
    print "*************************\n";
    print "* Stat File Service    *\n";
    print "*************************\n";
}

sub check_read_access {
    my $f = shift;

    if(-f $f) {
        my $filemode = (stat($f))[2];

        return ($filemode & 4);
    }

    return 0;
}

sub process_file {
    my $file = shift;
    my $line;
    my ($line_count, $char_count, $word_count) = (0,0,0);

    $file =~ /(.+)/;
    $file = $1;
    if(!open(F, $file)) {
        die "[-] Can't open $file: $!\n";
    }


    while(($line = <F>)) {
        $line_count++;
        $char_count += length $line;
        $word_count += scalar(split/\W+/, $line);
    }

    print "~~~ Statistics for \"$file\" ~~~\n";
    print "Lines: $line_count\n";
    print "Words: $word_count\n";
    print "Chars: $char_count\n";

    close F;
}

The perl script file, ch7.pl, uses <STDIN> to accept user input and store it in $file. Then it opens $file to print simple statistics.

Note that this script uses the open () function. This function has a hidden feature that can use shell commands. Details can be found here(Link). This hidden feature can be used to get a flag.

The flag obtained successfully.

Root me write-up : Bash - System 2

It looks like that it can be solved by changing the "ls" command to "cat". However, since there is no "-l" option in "cat" command, "ls -lA" should be "cat".

SUID is in use.

I used the following method to change "ls -lA" to "cat".


1. Make a /tmp/tmpt/ls program to exploit.

#include<stdio.h>

int main() {
system("■■■ ■■■■■■■■■■■■■t/ch12/.passwd;");
return 0;
}

2. Add /tmp/tmpt to PATH environment variable.

Clear!

Root me write-up : sudo - weak configuration

Wishing to simplify the task by not modifying rights, the administrator has not thought about the side effects...

The "~/ch1cracked/.passwd" file is for the "app-script-ch1-cracked" account. The file has a flag.

There is a mention of "Privilege escalation" in the game description.

The traditional way to escalate privilege is to use "sudo" or "su". It is possible to see what what permissions are available through "sudo -l".

The important point is that there is a wildcard character(*). This means that both the parent directory and the current directory are included.

The flags can be obtained using the characteristic of the wildcard.

Root me write-up : Bash - System 1

Try to find your path padawan!

"ch11" has SUID permission, and the "ls" command depends on the PATH environment variable.

The goal is reading the ".passwd".

The soft link "ls" that functions as "cat" reads the ".passwd".

If the current path is included in the PATH environment variable, the vulnerability can occur like above.

But there is something strange.

I changed the path "/tmp/test2" to "/tmp" but it doesn't worked. The "app-script-ch11-cracked" account could not run "/tmp/ls". There was no problem with file permissions(777).

I also used "alias" to make the "ls" to execute "/bin/cat", but it did not work. and I made the "ls" run a bash script file, but SUID was not applied.

It seems that a secure OS is applied the server and the separate invisible security policy is in operation.