DEV Community: Tepid Angler

Moving Forward.cpp

Tepid Angler — Wed, 13 Nov 2019 18:26:47 +0000

This is gonna be a relatively short and sweet article. I recently began refreshing myself on C++ (post C++98) and that gave me an idea to possibly look into game development. Although I'm very aware it's frowned upon to code your own game engine, that's exactly what I will be doing. So to basically sum things up without being too winded, I'll be using this to post Hack the Box (HTB) write-ups of boxes that I pwn once they retire, and I've also thought of the possibility of detailing my game dev projects here. Anyway, stay tuned for more folks!

P.S. Below is a simple calculator program I wrote, it's available on my github page as well in the 'Calculator' repo. Feel free to improve it, break it or whatever you feel like doing. If you make it do something cool or unexpected definitely let me know. If you want to add algebraic functions or something similar that's also fine.

calc.cpp:

/* This is my first attempt at a calculator program. It will have the ability to add, divide, subtract, and multiply values given to it by the user */

#include <iostream>
#include <unistd.h>

int getValueFromUser()
{
    std::cout << "Enter an Integer please: ";
    int input{ 0 };
    std::cin >> input;
    std::cout << "[+] Storing value, please wait\n";
    sleep(2);
    return input;
}

int add(int x, int y)
{
    return x + y;
}

int multiply(int z, int w)
{
    return z * w;
}

int sub(int b, int c)
{
    return b - c;
}

int divide(int d, int e)
{
    return d / e;
}

void doCalc(int choice)
{
    int a{ };
    int s{ };
    int m{ };
    int di{ };

    switch(choice) {

        case 1 :
            a = ( add( getValueFromUser(), getValueFromUser() ));
            std::cout << "Your Total for addition is => " << a << "\n";
            std::cout << "\nThank you for using the Calculator\n";
            break;
        case 2 :
            s = sub( getValueFromUser(), getValueFromUser() );
            std::cout << "Your Total for subtraction is => " << s << "\n";
            std::cout << "\nThank you for using the Calculator\n";
            break;
        case 3 :
            m = multiply( getValueFromUser(), getValueFromUser() );
            std::cout << "Your Total for Multiplication is => " << m << "\n";
            std::cout << "\nThank you for using the Calculator\n";
            break;
        case 4 :
            di = divide( getValueFromUser(), getValueFromUser() );
            std::cout << "Your Total for Division is => " << di << "\n";
            std::cout << "\nThank you for using the Calculator\n";
            break;
        case 5 :
            std::cout << "Thanks for wasting your own time fam. You played yourself\n";
            exit (EXIT_SUCCESS);
            break;
        default :
            std::cout << "The Instructions were clear than a mothafucker dog, learn to read.\n";
            std::cout << "You know what fuck this shit I'm aborting\n";
            exit (EXIT_SUCCESS);
    }
}

int main()
{
    int choice{ 0 };
    std::cout << "Welcome to Tepi's original Calculator written in C++\n";
    std::cout << "Would you like do (1) Addition, (2) Subtraction, (3) Multiplication, (4) Division, or (5) Exit?\n>";
    std::cin >> choice;
    doCalc(choice);
    return 0;
}

Using 'scl' of scl-utils to abuse sudo on CentOS/RHEL

Tepid Angler — Tue, 02 Apr 2019 13:23:38 +0000

What:
In an effort to make it easier for unprivleged users on a shared system to use 'scl' an admin (reasonably) might
allow sudo privs with no password for 'scl'. What's expected is for the unprivledged user to be able to execute
the 'scl' binary to see a multitude of different information regarding the binary and whatever collections an
admin may have downloaded for the developers to use on the system. Because the binary passes arguments through 'exec()'
to achieve this, an attacker can leverage the 'exec()' function to pop a shell while abusing sudo to escalate privileges
by simply adding bash as the 'COMMAND' argument in the scl syntax like so 'sudo scl enable rh-ruby25 bash'.

Who:
It's important to mention that this vulnerability doesn't affect all environments. For instance, if your users are protected by passwords
this adds an extra layer of security against the vulnerability as the attacker would have to then find the password.
Another example, if you have scl installed by default but don't have any packages in the '/opt/rh/' directory then
scl will not have any collections to pull from which results in the 'scl' binary itself failing and then exiting.
As far as who would be affected, any system that has scl-utils downloaded, has a collection installed, and that allows users to
call the 'scl' binary using sudo.

How:
The driving force behind this abuse stems from the 'args.c' file which holds the source code for how to handle arguments.
While reviewing 'args.c' I noticed they call the 'exec()' function which ultimately starts a new process using the arguments
we gave the 'scl' binary on the command line. This is where our root shell comes from: since there it doesn't drop privileges
to that of the person who called the sudo, we're left with a process that is now running as root.
Lines 331-359 are as follows:

 else if (!strcmp(argv[1], "run") || !strcmp(argv[1], "enable")) {
        int i, i2;

        args->action = ACTION_COMMAND;

        for (i = 2; i < argc; i++) {
            if (!strcmp(argv[i], "--exec") || !strcmp(argv[i], "-x")) {
                args->exec_flag = true;
                break;
            }
        }

        /* Remove -x / --exec from argv */
        if (args->exec_flag) {
            for (i2 = i; i2 < argc - 1; i2++) {
                argv[i2] = argv[i2 + 1];
            }
            argc--;
        }

        if (argc < 4) {
            ret = EINPUT;
            goto fail;
        }
        ret = parse_run_args(argc, argv, args);
        if (ret != EOK) {
            goto fail;
        }

Line 356: ret = parse_run_args(argc, argv, args); is the line that passes our arguments to the 'exec()' function.
To mitigate this vulnerability I have written a patch that checks the 'SUDO_GID' and 'SUDO_UID' environment variables
and then drops the privileges of the process to the user who called the sudo. This stops our attacker from escalating
his privileges allowing the system users to continue using the 'scl' binary the same way they have been before.

Below I have provided a link to the bug I submitted through bugzilla, which does provide a patch to mitigate this type
of attack:

https://bugzilla.redhat.com/show_bug.cgi?id=1694875

Closing:

I should mention that I did reach out to a vulnerability disclosure program, Zerodium, and was told that this isn't
considered a privilege escalation exploit. Redhat also advised it's a feature. I should also note that even if you don't meet the conditions to escalate privilege's you can still use this binary to escape jails. I also provided the patch (SEE BUGZILLA LINK) to the upstream. With all of this being said I felt it was safe to release this information to the world specifically because until the patch
has been pushed by upstream systems may still be infected and now they will at least have a patch available until
they can apply the patch to a release. Since there has been no CVE issued at this time I feel this issue is best
covered by CWE-264 with a severity of 41.6.

Tepidangler / SCL-patch

A patch for the args.c file in the scl binary source

SCL-patch

A patch for the args.c file in the scl binary source

Applying the patch

If you already have scl compiled on your host you can delete the binary using

# rm -rf path/to/scl/binary

Steps

Create a temporary working space in the /tmp directory and change to that directory

$ mkdir /tmp/scl-patch && cd /tmp/scl-patch

Clone scl-utils repo from github

$ git clone https://github.com/sclorg/scl-utils.git

Clone the patch for args.c from this repo

$ git clone https://github.com/Tepidangler/SCL-patch.git

Change to the src directory in scl-utils/ $ cd scl-utils/src/
Patch the args.c file

$ patch < /tmp/scl-patch/SCL-patch/args.patch

Compile the source code

$ cmake . && make

View on GitHub

Shoutout to:

@TJnull & @lewellyn

Feel free to follow them on Twitter

Hack The Box

Tepid Angler — Mon, 13 Aug 2018 17:42:59 +0000

I recently stumbled upon what I now call a gem, Hack The Box. In short it's a series of servers on a vpn that you can hack with the ultimate goal of rooting the box. They have varying difficulties the easiest I've completed (which is 1/2 lol) was 'Jerry', it didn't take much knowledge of anything except maybe enumeration. 'Poison' however was very difficult in the sense that sometimes when starting my testing I have a tendency to get brute-force happy on everything while sometimes overlooking much easier vulnerabilities. Anyway the goal of most of these boxes are to get a user hash and and root hash, you earn points for it which translates to rank and I would assume eventually leads to job offers or something like that. But it's the best 'hacker game' I've seen since Pull the Plug. If you enjoy these kinds of things or are at least interested you should probably check it out. Now be forewarned you have to 'hack' your way through the invitation process, but it's not something that you should find too difficult.

Vulns

Tepid Angler — Mon, 13 Aug 2018 16:03:52 +0000

It would seem as though today there is a major emphasis on cyber security. For what reason I'm honestly not sure. Let's play devils advocate and say that there are corporations out there that genuinely care about your CPNI for the sole sake of doing good business. One may argue that it's impossible to cover all vulnerabilities and exploits, and to that I say bullshit. While you're right that anything can be exploited with the right amount of time and effort, the other side to this coin is that most people aren't going to take that time and effort unless there a big payout. As much as I would love to blame corporations for the entirety of this BS I can't, having personally witnessed some of the "cautionary" steps that some of our more powerful collectives of people take to ensure their own trade secrets; it blows my mind that they don't take YOUR information as serious when it comes to protection. Willingness to facilitate crimes by placing the responsibility with others is never the way to go. Not to much can be said, but I CAN say this: if you're into cyber security, or even if you aren't, be very very very careful with who you trust with your personal information..... it could be only a well-crafted google search away