File monitoring and Obfuscation

Deather

Member

Reaction score: 1
Messages: 25

1.Hello, I was wondering about which files a inturder would want to attack and make changes to that the system doesn't edit at all.

2. How could you confuse the attacker by making them think that they are on a different OS and not FreeBSD?

3. Final thing, Is there a file of which can monitor all the commands run by any user?

Note: I will be reading the HandBook soon but for right now I need answers. Also I doubt it's in the HandBook. Thank you for your help <3
 

Sevendogsbsd

Aspiring Daemon

Reaction score: 470
Messages: 945

Are you doing homework or a certification test? 🤣

No way to obfuscate what OS an attacker is ALREADY ON - a good attacker will immediately know this. The files accessed by an attacker depend entirely on their motives and the purpose of your server. If an attacker is already on your server, you have bigger issues to worry about than what files they will access though...
 

rootbert

Well-Known Member

Reaction score: 80
Messages: 250

1.) Depends on what the attacker is up for. Use a host intrusion detection system to detect changes.
2.) Very difficult, only possible with tremendous work: you need to delete all kinds of traces of the OS, like uname, sysctl, libraries, binary format etc. ... it's maybe easier to write an own operating system. Have a look at unikernels like NetBSD Rumpkernel or other solutions
3.) https://www.freebsd.org/doc/handbook/audit.html
 

mjollnir

Aspiring Daemon

Reaction score: 269
Messages: 658

Ha! You're under-estimating the quality of the FreeBSD Handbook.
1. Replace the monitoring binary e.g. freebsd-update(8), then the victim does not detect your changes
3. RTFM apropos accounting & the Handbook.
 
OP
D

Deather

Member

Reaction score: 1
Messages: 25

Are you doing homework or a certification test? 🤣

No way to obfuscate what OS an attacker is ALREADY ON - a good attacker will immediately know this. The files accessed by an attacker depend entirely on their motives and the purpose of your server. If an attacker is already on your server, you have bigger issues to worry about than what files they will access though...
The only thing i'm worried about is if they get access they can disable the firewall. As it's only allowing proxy traffic. And if I can detect if someone is in my system then it will shutdown and notify me. Pulling out the files and examing, fixing and then reinstalling.
 

Sevendogsbsd

Aspiring Daemon

Reaction score: 470
Messages: 945

Well, all I can say is if they are already on, your firewall is pointless at that point. I would say if you can tell someone is on your system, then a notification is good, but most attackers will be very stealthy. Unless they just want to wreak havoc and don't care. As mentioned earlier, a host based IDS is a good idea.
 
OP
D

Deather

Member

Reaction score: 1
Messages: 25

Well, all I can say is if they are already on, your firewall is pointless at that point. I would say if you can tell someone is on your system, then a notification is good, but most attackers will be very stealthy. Unless they just want to wreak havoc and don't care. As mentioned earlier, a host based IDS is a good idea.
I plan on making a computer board. Not sure how to do that yet but I am willing to learn. Preferably small, 512Mb ram and a decent cpu is fine. (I will test the requirements for my project later), But it will have a built in firewall on the board. So it goes through a microcontroller and into the pc, kinda like ethernet but on the board instead. And will not be able to tell the microcontroller what to do. But the firewall thing was an example. Also I read all the way to 3.2 Virtual consoles in the handbook :)
 
OP
D

Deather

Member

Reaction score: 1
Messages: 25

So run it [FreeBSD] with a kern.securelevel to 3?

It can be part of System Hardening, the subject of one of your other topics...
Yeah I got that stuff. But not just the kernel can have vulnerabilities.
 

julp

Member

Reaction score: 32
Messages: 61

Mounting a simple USB stick fails if kern.securevel is too high. So I don't touch it.
This shouldn't be too problematic as long as you have physical access to it.

If I were to accomplish the same, I would use some kind of removable media, I'd mount read-only (except /var + /tmp?) and I'd update it from an other system (when a new vulnerability is patched). At least, you keep a spare one ready to minimize downtime. But it depends of the (exact) needs.
 

ralphbsz

Daemon

Reaction score: 1,546
Messages: 2,477

1.Hello, I was wondering about which files a inturder would want to attack and make changes to that the system doesn't edit at all.
Could be nearly anything. The one time I was root-kitted (about 1999, on Linux, the attack actually failed), the attacker inserted a directory called "/usr/bin/..." (yes, three dots), which was a real directory, and contained their attack executables. I noticed the attack pretty quickly (because their root kit was so stupidly written, it tried to send mail, but with wrong parameters to the mail program, duh), and then it took me 10 minutes to find out where they were hiding their files. Note that no files were changed, only a directory entry created.

If you are wondering about files being changed: I vaguely remember that one of the daily or weekly security jobs takes checksums of all files in somewhere (like /bin or /usr/bin or similar), and reports when they change. Or is that only for setuid files? You might start by reading the periodic infrastructure.

2. How could you confuse the attacker by making them think that they are on a different OS and not FreeBSD?
Forget it. The fact that it is not Linux becomes immediately obvious when you look at the places things are stored. For example /usr/local being full of stuff. Or look for the difference between /etc/syconfig/... and /etc/sysctl.conf. While you can easily change the kernel to return a different answer from the uname() system call, that will A: break a lot of software, and B: immediately be noticed as fake by anyone who knows what they're doing. And then there are things that you just can't fix. Like:
Code:
# file /bin/ls
/bin/ls: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=c132aa35afa3aeb96336b2241f38e2edcbc3b945, stripped
/bin/ls: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 11.3, FreeBSD-style, stripped
So you can change the file command, the the executable loader in the kernel, and the elf linker, and nm and ... really? It just won't work.

3. Final thing, Is there a file of which can monitor all the commands run by any user?
What makes you think that your attackers are actually issuing commands from a shell? Today, real attackers are more likely to use things like the mail server or the web infrastructure on your machine than logins. That's why securing the machine against remote logins (things like ssh passwords) and bugs in the shell have become of little use: those things are typically so well secured, the real attacks are elsewhere.

Anyway: As you certainly know, anytime a user executes a "command" from a shell, that either runs a process, or it doesn't; the "it doesn't" case is using shell built-ins. Most damage can be done by running processes, for example "rm -f /boot/kernel/kernel", which runs the /bin/rm executable. That kind of attack you could audit by turning on process accounting (there is a handbook chapter for that). But beware: once you have process accounting on, the audit log of accounting (all process creations!) will be extraordinarily long. You will find thousands of times that someone runs for example the /bin/rm executable. Which of those are an attacker? Good luck. And then you find that someone runs "/usr/local/bin/perl foo.pl" ... and you have no idea what that did; and from inside, interpreters like perl or python or ruby can do nearly anything, without running a process. And shell builtins also don't create processes, and saying "echo foo > /boot/kernel/kernel" is just as damaging as deleting the kernel.

Have you looked at security auditing? There is a handbook chapter about that.

Note: I will be reading the HandBook soon but for right now I need answers. Also I doubt it's in the HandBook. Thank you for your help <3
Sorry, but you have it exactly backwards. Please read the handbook. You are currently making a fool of yourself in public. That makes it quite unlikely that you will receive meaningful help.

Most of the details you are asking are in the handbook. What is not in the handbook is basics (like what is a process and what isn't), and common sense (like finding the needly in the haystack).
 
OP
D

Deather

Member

Reaction score: 1
Messages: 25

Mounting a simple USB stick fails if kern.securevel is too high. So I don't touch it.
Do you know of any FreeBSD rootkits, viruses, etc? That could be scanned for? I know theres chkrootkit and others but I think they only scan for linux rookits correct me if I'm wrong :)
 
OP
D

Deather

Member

Reaction score: 1
Messages: 25

Could be nearly anything. The one time I was root-kitted (about 1999, on Linux, the attack actually failed), the attacker inserted a directory called "/usr/bin/..." (yes, three dots), which was a real directory, and contained their attack executables. I noticed the attack pretty quickly (because their root kit was so stupidly written, it tried to send mail, but with wrong parameters to the mail program, duh), and then it took me 10 minutes to find out where they were hiding their files. Note that no files were changed, only a directory entry created.

If you are wondering about files being changed: I vaguely remember that one of the daily or weekly security jobs takes checksums of all files in somewhere (like /bin or /usr/bin or similar), and reports when they change. Or is that only for setuid files? You might start by reading the periodic infrastructure.


Forget it. The fact that it is not Linux becomes immediately obvious when you look at the places things are stored. For example /usr/local being full of stuff. Or look for the difference between /etc/syconfig/... and /etc/sysctl.conf. While you can easily change the kernel to return a different answer from the uname() system call, that will A: break a lot of software, and B: immediately be noticed as fake by anyone who knows what they're doing. And then there are things that you just can't fix. Like:
Code:
# file /bin/ls
/bin/ls: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=c132aa35afa3aeb96336b2241f38e2edcbc3b945, stripped
/bin/ls: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 11.3, FreeBSD-style, stripped
So you can change the file command, the the executable loader in the kernel, and the elf linker, and nm and ... really? It just won't work.


What makes you think that your attackers are actually issuing commands from a shell? Today, real attackers are more likely to use things like the mail server or the web infrastructure on your machine than logins. That's why securing the machine against remote logins (things like ssh passwords) and bugs in the shell have become of little use: those things are typically so well secured, the real attacks are elsewhere.

Anyway: As you certainly know, anytime a user executes a "command" from a shell, that either runs a process, or it doesn't; the "it doesn't" case is using shell built-ins. Most damage can be done by running processes, for example "rm -f /boot/kernel/kernel", which runs the /bin/rm executable. That kind of attack you could audit by turning on process accounting (there is a handbook chapter for that). But beware: once you have process accounting on, the audit log of accounting (all process creations!) will be extraordinarily long. You will find thousands of times that someone runs for example the /bin/rm executable. Which of those are an attacker? Good luck. And then you find that someone runs "/usr/local/bin/perl foo.pl" ... and you have no idea what that did; and from inside, interpreters like perl or python or ruby can do nearly anything, without running a process. And shell builtins also don't create processes, and saying "echo foo > /boot/kernel/kernel" is just as damaging as deleting the kernel.

Have you looked at security auditing? There is a handbook chapter about that.


Sorry, but you have it exactly backwards. Please read the handbook. You are currently making a fool of yourself in public. That makes it quite unlikely that you will receive meaningful help.

Most of the details you are asking are in the handbook. What is not in the handbook is basics (like what is a process and what isn't), and common sense (like finding the needly in the haystack).
I already started reading the handbook. Also if you ever looked at a honeypot (you can find videos), usually they first find a vulnerability and then get a backdoor into the system. I have exploited computers for 2-3 years so- I have found tons of zero days too.

Edit: I don't care about my public image and people seem to be helping either way and i'm greatful they are.
 

ralphbsz

Daemon

Reaction score: 1,546
Messages: 2,477

... I have exploited computers for 2-3 years so- I have found tons of zero days too.
Just as a reality check: Typical prices for selling zero days to legitimate buyers (typically computer companies and government agencies) range from $100K to $1M; the prices are higher for mobile OSes. Typical prices for selling them to criminals tend to be significantly higher, but are often paid in a fashion that is a bit difficult to turn into fiat currency (meaning the black market is difficult to exploit efficiently).

If you have found tons of zero days, then you should just hire yourself consultants to answer these questions, you have the means.

And about honeypots: When Niels Provos was still a grad student, I tried to hire him. Sadly (for me, good for him) he went to work for the competition.
 
OP
D

Deather

Member

Reaction score: 1
Messages: 25

Then why are you asking?
Because i've dealt with script kiddies who think they are anonymous using a vpn, but then when I ask them to go to a link with a vpn or tor they don't. They did carding.

Also in a honeypots I have not seen someone check the os. they see a terminal and assume linux. So script kiddies like to do the following commands when they get inside: "apt-get install" "yum install" "pacman" etc..

I also plan on mixing the kernel with other unix's. and removing some of bsd etc.
 
OP
D

Deather

Member

Reaction score: 1
Messages: 25

Just as a reality check: Typical prices for selling zero days to legitimate buyers (typically computer companies and government agencies) range from $100K to $1M; the prices are higher for mobile OSes. Typical prices for selling them to criminals tend to be significantly higher, but are often paid in a fashion that is a bit difficult to turn into fiat currency (meaning the black market is difficult to exploit efficiently).

If you have found tons of zero days, then you should just hire yourself consultants to answer these questions, you have the means.

And about honeypots: When Niels Provos was still a grad student, I tried to hire him. Sadly (for me, good for him) he went to work for the competition.
I like keeping them to myself for use, and they wouldn;t interest the government. Maybe the company that developed them. ANd mAyBe one of them might interest a governement
 

rf10

Member

Reaction score: 6
Messages: 29

Definitely study the handbook. But not for obfuscation.

There is software which can fingerprint the OS and sometimes even the hardware running on a box just by portscanning a remote box. Nmap is one example of open source but there are more sophisticated tools.

So studying is useful to be able to properly defend you box, so that the attacker does not get inside. Obfuscation and other tricks won’t have any desired effect since most passive attacks are automated. And if you piqued the interest of a government agency or a foreign state, it is game over.
 

mark_j

Well-Known Member

Reaction score: 172
Messages: 445

The OP's got some grandiose ideas but most of them are just plain stupid. Obfuscate the OS? Seriously?

Anyone with half the desire to break into a system should be able to work out an OS in a heartbeat. Check OS macros in the compiler, the header files, logs, scripts, startup methods, etc etc etc. It might, granted, be hard to work out a specific Linux distribution, but then someone more familiar with Linux would take no time at all.

To even think you can obfuscate an OS away is, well, childishly silly. It's also a waste of time and just nonsense.

On the "file" that can monitor user activity, again you've got the wrong OS. I think Linux had sysdig a while back. No such analogue for FreeBSD. You could, of course, wrap a script around shell invoke, but I imagine the output would be a tad useless once the user begins using a GUI or even an ANSI terminal.
 

vigole

Active Member

Reaction score: 197
Messages: 168

And will not be able to tell the microcontroller what to do.
Would you care to elaborate on microcontroller part. Thanks, I appreciate it.
Also if you ever looked at a honeypot (you can find videos), usually they first find a vulnerability and then get a backdoor into the system
How do they match honeypot (or as Microsoft used to call them Honeymonkey) and vulnerability, to get into backdoor scene?
How much should I read a day though? [...] Also if you ever looked at a honeypot (you can find videos)
Video?! you are not much of a reader, aren't you? but that's OK, you've just started to read the handbook.
I have found tons of zero days too
Zero day is just a fancy/marketing name for good old term: bug, written and used by journos in Red tops and alike. They love to use the word glitch too.
might interest a governement
Which government?
Because i've dealt with script kiddies [...] ANd mAyBe one of them might interest a governement
Speaking of script kiddies, and also the way you wrote, ANd, which reminds me of NAND gate .../.../... I have to conclude my rant with this summary:
usually but not exclusively having a good understanding of ISA (instruction set architecture) is a line which separates the experts from script kiddies.
 

wolffnx

Well-Known Member

Reaction score: 73
Messages: 402

The only thing i'm worried about is if they get access they can disable the firewall. As it's only allowing proxy traffic. And if I can detect if someone is in my system then it will shutdown and notify me. Pulling out the files and examing, fixing and then reinstalling.
ehmmm only if the are in the root acount, also they cannot change system settings,so,dont install sudo
and choose a good root password, but for sure you already know this
 
Top