Copperhead, Job Hunting

 I'm trying to decide whether to even bother writing Copperhead.  It's supposed to run nmap -sV scans against hosts, then check exploitdb for known exploits.  The problem is, it takes a ton of text parsing and massaging to get something vague enough to search exploitdb without being too vague.  Oh, and it'd have to require the offline version of exploitdb and its tools, because I can't find a way to search exploitdb's website.

It almost seems like a solution in search of a problem.  So at the moment, it's on the back burner.

I'm also getting discouraged in my job hunt.  I'm not sure if I'm not putting myself out there well enough (too shy and stuttery, bad body language, etc.) or if my lack of experience is my problem.  I do have about 3 years of experience in security... as a sysadmin.  But because I didn't have "security" in my job title, that doesn't seem to count.  Plus that was 6 years ago.  I'm re-teaching myself everything I've forgotten about security over the years plus adding new skills, but... I don't know.  Job hunting is feeling futile at the moment.

Miscellany

 I've been doing little things here and there, but nothing worthy of a full blog post.  I'm trying to get in the habit of writing at least weekly, though.

I'm doing little things here and there on TryHackMe, but I'm running into more and more rooms that are premium-only.  Rooms that you need to complete to finish training paths, or even worse, to complete free rooms.  Looking over Hack The Box, it's similarly restricted for free users, plus it has time limits and no way around the time limits.  At least THM only limits your use of their in-browser attack box for free users, but VPN access is unlimited.  The $10/mo. doesn't sound like much for THM, but it adds up and I really can't justify it right now.

I'm still slowly working my way through "Violent Python", and it's inspired Copperhead and Pocketnuke over on my github.  Pocketnuke is a more refined version of the C runstub I mentioned previously in this blog.

I had been studying again for my CCNA, but that's fallen by the wayside for right now.  Instead, I'm slowly working on studying for the eJPT.  Or at least, doing INE's PTS courses through their free "starter pass".  I'm not sure I want to do pentesting, or jump right into Red Team, but at least in my opinion, you can't defend against the enemy properly unless you know how they think and operate.  So, like when I was in high school and hung out in 2600 IRC to learn how they would attack my server so I could protect it, I'm learning pentesting.

Changing users with SUID and setuid/setgid

 Doing the Linux privilege escalation room on TryHackMe reminded me of a trick I've used in the past.  I haven't used it for nefarious purposes, only to get around a web script being run as the woefully unprivileged apache user, when it needed to run as a more privileged user.  It could easily be used as a good pentesting exploit.  I DO NOT endorse using this for evil.  Only use this for good, people.

It uses what I call a run stub.  It's a C wrapper that launches the script, but only after it changes the UID/GID to the desired higher-privileged user.  The run stub has to have SUID permissions and be owned by root.  So, chmod u+s runstub after compiling runstub.c into runstub.  The permissions listing should say: -rwsr-xr-x root root.

Below is the code: 

#include <stdio.h> 
#include <stdlib.h>
#include <sys/types.h>
#include <unistd.h>
#include <string.h>
int uid;
int gid;
char runprog[512];
int main(int argc, char *argv[])
{
setgid(<gid>); /* <gid> is whatever GID you want to switch to */
setuid(<uid>);  /* <uid> is whatever UID you want to switch to */
snprintf(runprog, 512, "/path/to/script %s", argv[1]);  /* runprog is the buffer, 512 is the size of the buffer, the rest is the script you're trying to run and any arguments you want to pass to it, specified on the run stub's command line */
system(runprog);
return 0;
}

The two magic parts here are setuid()/setgid(), which *nix uses to switch users and groups in things like sudo and su, and system().  The snprintf() line formats the command into a string that can be passed to system(), which executes commands.

So, use your powers for good, and happy hacking.

The Beauty and Wonder of Programming Specs

Bit of a work rant. I'm not trying to use this as a whine-fest, although it'll sound like one at points. Take this more of a case study or illustrative, anecdotal example of why it's proper practice to write out a formal specification for your developers.

There's a project I've been working on for 9 months now; I'm not sure if I've mentioned it, but if I have it's the pricing update program. Anyway, this was originally slated to be a 6mo project. Well, obviously, it hasn't been. Part of the problem has been, I'm learning Flashbasic (Pick/Basic, whatever) as I'm writing it. So that's obviously going to make things take longer than if someone experienced in the language is working on it.

 However, I'm getting ready to put it into testing for the 3rd time here in the next week or so. Why? I had no specification to work off of. All I've had to go by is a couple meetings with the heads of the involved departments, and streams of emails back and forth. Plus the input during the previous 2 demos/tests. Neither meeting was that enlightening-- the first one got bogged down in minutiae and was more confusing to me than explanatory.  I took down some notes, and ended up with something that got completely rejected when I called the second meeting.  However, that was all I got out of the second meeting: what you're doing won't work, it's too unlike what we're doing now and generally wrong anyway, but the current way of doing this is still terrible.  I cobbled together something based on what I could glean from the second meeting and from what I was learning on my own from the way pricing currently works.  Then I demoed it.  It had a lot of flaws, was missing a lot of features, there were a lot of miscommunicated aspects.  I took copious notes, learned that the department head I hadn't consulted with so much a) had taken on the duty of updating pricing and therefore needed the project more than the other department did, and b) he was more analytical and demanding, and therefore easier to hammer out the program with.  Cue the storm of emails back and forth on what was needed where.  Got a mostly workable version, demoed it again, except for a major missing feature it was great.  Now I'm finishing that feature and reworking the program flow to shoehorn this whole extra step in, and hoping it'll fly (it's necessary still to edit the spreadsheet, just not to the extent it was the last time I showed them the program-- they want to do 0 editing.  This is not possible).

Note all the miscommunication, poorly stated needs and goals, and tendency to leave how to write the program (and therefore alter the business processes surrounding it) to an inexperienced programmer who has never had anything to do with that aspect of the business, and never will on a daily basis.  Note how much time was wasted simply trying to get information and input from the people who will be using it every day for the rest of their career with the company (theoretically).  This could have been avoided with one thing-- a program specification.

Even though my classes in college were theoretically all intro classes (although you could get more out of them if you put more in, as I did), we were taught to work with specs.  In Linux Administration class,  Netware Administration, C Programming, Java Programming, Security, Forensics, all the electronics classes (DC/AC Circuit Analysis, Semiconductor Applications, Digital Electronics, Intro to Microprocessors), even the first semester classes like Computer Repair and Survey of Operating Systems-- they all dealt with both writing specs, and working from one.  With a proper spec, there is no question of what needs to be done.  Everything is laid out, from the current process, to what is broken about the current process, to what needs to remain the same with the new process, to the new process.  Even if the new process is a proposal, it still gives the programmer, who does not and will not work in the department that needs the program they're tasked to write, a starting point to work from.  And in the meeting about the proposed spec, there can be discussion over what is possible, what the needs are, etc.  Rather than everyone just throwing up their hands and asking "well, what do you think it should do?".  I was, in fact, asked by the less-analytical dept. head that exact question.  That was the point I threw up my hands and called the second meeting, so her boss and my boss could provide us some guidance.  Had there been a spec prior to the first meeting, much of that back-and-forth wouldn't have happened, and much of my time (and everyone else's) wouldn't have been wasted.

Unfortunately, and this is where it gets a little whiny again, I've brought up the suggestion (during the first demo) of writing a spec from now on.  It was met with total resistance.  So right now I'm basically... how shall I put this politely?.... whistling in the wind, as far as applying this to myself.

But maybe this can be an example to someone else, and save them the heartache I'm relegated to.  However, this experience has taught me a lot about my coworkers, and working with them on designing programs.  And hopefully taught them a thing or two about working with the programmer who hasn't basically built everything from the ground up, or rebuilt it for the company's needs, for the past 15 years.

I'm just really looking forward to the end of this project, and to move on to other, more interesting projects I have lined up.