Forwarded from Backup Legal Mega
Β» ]Quickly check whether the computer has been hacked (Linux version)
π¦other
1) Abnormally scheduled tasks
In addition to the above self-starting services, under Linux, you can also run persistent tasks through scheduled tasks.It is relatively simple to check for abnormal scheduled tasks
2) You only need to view /etc/crontaband /etc/cron.*the scheduled task files in the subdirectory .
3) bash initialization
Anyone who has used Linux knows that $HOME/.bashrcit can be initialized and applied to each shell in the file,
4) In other words, the script inside may be executed every time a new terminal is opened.
5) Such profiles include .bashrc, .bash_profile, .bash_login, .profileand so on.
6) Whether it runs and the order of running is determined by whether the shell is logged in when it is called, and whether it runs interactively,
π¦other
1) Abnormally scheduled tasks
In addition to the above self-starting services, under Linux, you can also run persistent tasks through scheduled tasks.It is relatively simple to check for abnormal scheduled tasks
2) You only need to view /etc/crontaband /etc/cron.*the scheduled task files in the subdirectory .
3) bash initialization
Anyone who has used Linux knows that $HOME/.bashrcit can be initialized and applied to each shell in the file,
4) In other words, the script inside may be executed every time a new terminal is opened.
5) Such profiles include .bashrc, .bash_profile, .bash_login, .profileand so on.
6) Whether it runs and the order of running is determined by whether the shell is logged in when it is called, and whether it runs interactively,
Forwarded from Backup Legal Mega
π¦For bash, the execution flow is as follows:
Forwarded from Backup Legal Mega
The execution sequence is A->B->C, B[123] means that it will be executed only when the first script exists. The flow chart is as follows:
Forwarded from Backup Legal Mega
Β» ]Quickly check whether the computer has been hacked (Linux version)
π¦ For the login/non-login shell and interactive/non-interactive shell, please refer to other introductions on the Internet, which will not be expanded here.
> As long as you know the order of files executed by your shell initialization and check these files for suspicious commands, you can find abnormal information.
> Application-level self-start
It is difficult to find all suspicious self-starting items. Experienced attackers can modify existing self-starting scripts and pull up additional commands.
> This reduces the risk of being discovered. Some Linux desktop versions will also be responsible for running similar self-starting commands, such as my favorite xfce,
In Settings -> Session Starup -> Application Autostartcan add applications from the start.
π¦ For the login/non-login shell and interactive/non-interactive shell, please refer to other introductions on the Internet, which will not be expanded here.
> As long as you know the order of files executed by your shell initialization and check these files for suspicious commands, you can find abnormal information.
> Application-level self-start
It is difficult to find all suspicious self-starting items. Experienced attackers can modify existing self-starting scripts and pull up additional commands.
> This reduces the risk of being discovered. Some Linux desktop versions will also be responsible for running similar self-starting commands, such as my favorite xfce,
In Settings -> Session Starup -> Application Autostartcan add applications from the start.
Forwarded from Backup Legal Mega
Β» ]Quickly check whether the computer has been hacked (Linux version)
π¦ Abnormal record
!) Abnormal command history
In general, hackers will execute certain commands on the shell after they obtain the shell.We can use the historycommands to view the commands that have been run.
2) Or view the ~/.bash_historyfile directly . A smart hacker may clean up the trace after doing bad things, but if history is found to be maliciously cleaned,
3) Or being tampered with abnormally, that is enough to give us a warning signal.
4) Abnormal logging
Logs, especially system logs, are our great helpers. The following commands can be used to read log files and output related information:
> View the latest login time and ip of each user: lastlog
> View each user's login record: last
> View the log of each user's login attempt (including failed): lastb
> View the currently logged in user, ip and the command being executed: w
> Of course, intentional attackers will also hide their traces in these commands, such as using the gadget hidemyass.
5) System logs are generally generated by the rsyslogd process, and are configured in /etc/rsyslog.conffiles and /etc/rsyslog.d/directories.
6) Some common logs and introductions are as follows:
> /var/log/messages: general system logs
> /var/log/kern.log: system kernel log
> /var/log/boot.log: system boot log
> /var/log/auth.log: Logs related to login, such as ssh/sudo
success and failure logs are here
> /var/log/secure: Same as above
> /var/log/cron.d: execution log of cron scheduled tasks
5) By checking the above logs, you can often find some unexpected traces (if any).
π¦Crime scene
1) Although the self-test is mainly to find clues and instructions from criminal traces, sometimes the malware left by the attackers will still be running,
2) At this time, it is also a good idea to search for clues from the crime scene.
β β β ο½ππ»βΊπ«Δπ¬πβ β β β
π¦ Abnormal record
!) Abnormal command history
In general, hackers will execute certain commands on the shell after they obtain the shell.We can use the historycommands to view the commands that have been run.
2) Or view the ~/.bash_historyfile directly . A smart hacker may clean up the trace after doing bad things, but if history is found to be maliciously cleaned,
3) Or being tampered with abnormally, that is enough to give us a warning signal.
4) Abnormal logging
Logs, especially system logs, are our great helpers. The following commands can be used to read log files and output related information:
> View the latest login time and ip of each user: lastlog
> View each user's login record: last
> View the log of each user's login attempt (including failed): lastb
> View the currently logged in user, ip and the command being executed: w
> Of course, intentional attackers will also hide their traces in these commands, such as using the gadget hidemyass.
5) System logs are generally generated by the rsyslogd process, and are configured in /etc/rsyslog.conffiles and /etc/rsyslog.d/directories.
6) Some common logs and introductions are as follows:
> /var/log/messages: general system logs
> /var/log/kern.log: system kernel log
> /var/log/boot.log: system boot log
> /var/log/auth.log: Logs related to login, such as ssh/sudo
success and failure logs are here
> /var/log/secure: Same as above
> /var/log/cron.d: execution log of cron scheduled tasks
5) By checking the above logs, you can often find some unexpected traces (if any).
π¦Crime scene
1) Although the self-test is mainly to find clues and instructions from criminal traces, sometimes the malware left by the attackers will still be running,
2) At this time, it is also a good idea to search for clues from the crime scene.
β β β ο½ππ»βΊπ«Δπ¬πβ β β β
Forwarded from Backup Legal Mega
β β β ο½ππ»βΊπ«Δπ¬πβ β β β
π¦The Abnormal process ":
1) To find the abnormal process, you can use the topcommand to view the resources occupied by the running program, or ps -eflist the processes used by the current system.
2) If you find a process you don't know, you can use the following command to check it in detail:
3) View the full command line started by the process: ps eho command -p $PID
4) View the directory where the process started: readlink /proc/$PID/cwd
5) View the complete environment variable when the process
> starts: strings -f /proc/$PID/environ | cut -f2 -d ' '
> List all files opened by the process: lsof -p $PID
> List the network connections opened by the process: netstat -pan | grep $PID
> Of course, if the attacker hides the process by some means, it
> will still leave some clues, such as the suspicious LKM module, which will not be deepened here.
π¦Abnormal network traffic
1) If a malicious process is active, it is likely that it is communicating with the external network at this time, which requires analysis by packet capture tools.
2) For Linux desktop users, wireshark is an excellent choice, and for the server, tcpdump is a good tool, and it is also necessary to master it.
3) Take wireshark as an example, open the packet capture for a few minutes, through the built-in filtering rules, plus the network connection opened by the application analyzed above,
4) You can see what evil communication this malicious application is doing with the outside world, so as to timely assess the loss and protect the data.
5) In addition to the web browsing initiated by malware, some are initiated by themselves. For example, the attacker modified iptables, DNS, http proxy,
> Or /etc/hosts, it may cause our normal network requests to be intercepted and tampered by attackers. These small modifications may not be obvious,
6) But once you find that your network environment is'not quite right', you must be vigilant and carefully investigate.
written by Undercode
β β β ο½ππ»βΊπ«Δπ¬πβ β β β
π¦The Abnormal process ":
1) To find the abnormal process, you can use the topcommand to view the resources occupied by the running program, or ps -eflist the processes used by the current system.
2) If you find a process you don't know, you can use the following command to check it in detail:
3) View the full command line started by the process: ps eho command -p $PID
4) View the directory where the process started: readlink /proc/$PID/cwd
5) View the complete environment variable when the process
> starts: strings -f /proc/$PID/environ | cut -f2 -d ' '
> List all files opened by the process: lsof -p $PID
> List the network connections opened by the process: netstat -pan | grep $PID
> Of course, if the attacker hides the process by some means, it
> will still leave some clues, such as the suspicious LKM module, which will not be deepened here.
π¦Abnormal network traffic
1) If a malicious process is active, it is likely that it is communicating with the external network at this time, which requires analysis by packet capture tools.
2) For Linux desktop users, wireshark is an excellent choice, and for the server, tcpdump is a good tool, and it is also necessary to master it.
3) Take wireshark as an example, open the packet capture for a few minutes, through the built-in filtering rules, plus the network connection opened by the application analyzed above,
4) You can see what evil communication this malicious application is doing with the outside world, so as to timely assess the loss and protect the data.
5) In addition to the web browsing initiated by malware, some are initiated by themselves. For example, the attacker modified iptables, DNS, http proxy,
> Or /etc/hosts, it may cause our normal network requests to be intercepted and tampered by attackers. These small modifications may not be obvious,
6) But once you find that your network environment is'not quite right', you must be vigilant and carefully investigate.
written by Undercode
β β β ο½ππ»βΊπ«Δπ¬πβ β β β
Forwarded from Backup Legal Mega
π¦70% of linux systems not safe and tracked anonymously, this new article is important for any linux user
t.me/UndercodeTesting
t.me/UndercodeTesting
What you need Undercode posts to focus on ?
Anonymous Poll
30%
Termux & Linux tools ?
11%
Accounts ?
24%
Courses ?
13%
General Hacking tips ?
23%
Carding ?
β β β ο½ππ»βΊπ«Δπ¬πβ β β β
π¦2020 from 2 days last update Advanced dork Search & Mass Exploit Scanner :
πΈπ½π π π°π»π»πΈπ π°π πΈπΎπ½ & π π π½ :
1) git clone https://github.com/AlisamTechnology/ATSCAN
2) cd ATSCAN
3) chmod +x ./atscan.pl
4) chmod +x ./install.sh
5) ./install.sh
6) Portable Execution: perl ./atscan.pl
7) Installed Tool Execution: atscan
Menu: Applications > Web Application analysis > atscan
π¦FEATURES :
β Engines: [Google apis cache] Bing Ask Yandex Sogou Exalead Shodan
β Mass Dork Search
β Multiple instant scans.
β Mass Exploitation
β Use proxy.
β Random user agent.
β Random engine.
β Mass Extern commands execution.
β Exploits and issues search.
β XSS / SQLI / LFI / AFD scanner.
β Filter wordpress & Joomla sites.
β Wordpress theme and plugin detection.
β Find Admin page.
β Decode / Encode Base64 / MD5
β Ports scan.
β Collect IPs
β Collect E-mails.
β Auto detect errors.
β Auto detect forms.
β Auto detect Cms.
β Post data.
β Auto sequence repeater.
β Validation.
β Post and Get method
β IP Localisation
β Issues and Exploit search
β Interactive and Normal interface.
β And more...
β Verified
@UndercodeTesting
β β β ο½ππ»βΊπ«Δπ¬πβ β β β
π¦2020 from 2 days last update Advanced dork Search & Mass Exploit Scanner :
πΈπ½π π π°π»π»πΈπ π°π πΈπΎπ½ & π π π½ :
1) git clone https://github.com/AlisamTechnology/ATSCAN
2) cd ATSCAN
3) chmod +x ./atscan.pl
4) chmod +x ./install.sh
5) ./install.sh
6) Portable Execution: perl ./atscan.pl
7) Installed Tool Execution: atscan
Menu: Applications > Web Application analysis > atscan
π¦FEATURES :
β Engines: [Google apis cache] Bing Ask Yandex Sogou Exalead Shodan
β Mass Dork Search
β Multiple instant scans.
β Mass Exploitation
β Use proxy.
β Random user agent.
β Random engine.
β Mass Extern commands execution.
β Exploits and issues search.
β XSS / SQLI / LFI / AFD scanner.
β Filter wordpress & Joomla sites.
β Wordpress theme and plugin detection.
β Find Admin page.
β Decode / Encode Base64 / MD5
β Ports scan.
β Collect IPs
β Collect E-mails.
β Auto detect errors.
β Auto detect forms.
β Auto detect Cms.
β Post data.
β Auto sequence repeater.
β Validation.
β Post and Get method
β IP Localisation
β Issues and Exploit search
β Interactive and Normal interface.
β And more...
β Verified
@UndercodeTesting
β β β ο½ππ»βΊπ«Δπ¬πβ β β β
GitHub
GitHub - AlisamTechnology/ATSCAN: Advanced dork Search & Mass Exploit Scanner
Advanced dork Search & Mass Exploit Scanner. Contribute to AlisamTechnology/ATSCAN development by creating an account on GitHub.
β β β ο½ππ»βΊπ«Δπ¬πβ β β β
π¦The Best way for hack any mail in 2020
& high rated :
π¦HOW IT WORKS ?
Your best friend in credential reuse attacks.
1) You give Cr3dOv3r an email then it does two simple useful jobs with it:
2) Search for public leaks for the email and returns the result with the most useful details about the leak (Using haveibeenpwned API) and tries to get the plain text passwords from leaks it find
3) Now you give it a password or a leaked password then it tries this credentials against some well-known websites (ex: Facebook, Twitter, Google...), tells if the login successful and if there's captcha some where blocking our way!
4) Some of the scenarios Cr3dOv3r can be used in it
5) Check if the targeted email is in any leaks and then use the leaked password to check it against the websites.
6) Check if the target credentials you found is reused on other websites/services.
7) Checking if the old password you got from the target/leaks is still used in any website.
πΈπ½π π π°π»π»πΈπ π°π πΈπΎπ½ & π π π½ :
1) download zip https://github.com/D4Vinci/Cr3dOv3r
2) cd Cr3dOv3r-master
3) python -m pip install -r win_requirements.txt
4) python Cr3d0v3r.py -h
+For Linux :
1) git clone https://github.com/D4Vinci/Cr3dOv3r.git
2) cd Cr3dOv3r
3) python3 -m pip install -r requirements.txt
4) python3 Cr3d0v3r.py -h
+For docker :
1) git clone https://github.com/D4Vinci/Cr3dOv3r.git
2) docker build -t cr3dov3r Cr3dOv3r/
3) docker run -it cr3dov3r "test@example.com"
β E N J O Y
use for learn only !
@UndercodeTesting
β β β ο½ππ»βΊπ«Δπ¬πβ β β β
π¦The Best way for hack any mail in 2020
& high rated :
π¦HOW IT WORKS ?
Your best friend in credential reuse attacks.
1) You give Cr3dOv3r an email then it does two simple useful jobs with it:
2) Search for public leaks for the email and returns the result with the most useful details about the leak (Using haveibeenpwned API) and tries to get the plain text passwords from leaks it find
3) Now you give it a password or a leaked password then it tries this credentials against some well-known websites (ex: Facebook, Twitter, Google...), tells if the login successful and if there's captcha some where blocking our way!
4) Some of the scenarios Cr3dOv3r can be used in it
5) Check if the targeted email is in any leaks and then use the leaked password to check it against the websites.
6) Check if the target credentials you found is reused on other websites/services.
7) Checking if the old password you got from the target/leaks is still used in any website.
πΈπ½π π π°π»π»πΈπ π°π πΈπΎπ½ & π π π½ :
1) download zip https://github.com/D4Vinci/Cr3dOv3r
2) cd Cr3dOv3r-master
3) python -m pip install -r win_requirements.txt
4) python Cr3d0v3r.py -h
+For Linux :
1) git clone https://github.com/D4Vinci/Cr3dOv3r.git
2) cd Cr3dOv3r
3) python3 -m pip install -r requirements.txt
4) python3 Cr3d0v3r.py -h
+For docker :
1) git clone https://github.com/D4Vinci/Cr3dOv3r.git
2) docker build -t cr3dov3r Cr3dOv3r/
3) docker run -it cr3dov3r "test@example.com"
β E N J O Y
use for learn only !
@UndercodeTesting
β β β ο½ππ»βΊπ«Δπ¬πβ β β β
GitHub
GitHub - D4Vinci/Cr3dOv3r: Know the dangers of credential reuse attacks.
Know the dangers of credential reuse attacks. Contribute to D4Vinci/Cr3dOv3r development by creating an account on GitHub.
Forwarded from Backup Legal Mega
β β β ο½ππ»βΊπ«Δπ¬πβ β β β
π¦ A simple TCP spoofing attack :
#git source
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 <SYN> --> Host B in.rshd
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 <-- <SYN/ACK> Host B in.rshd
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 <ACK> --> Host B in.rshd
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.
π¦ A simple TCP spoofing attack :
#git source
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 <SYN> --> Host B in.rshd
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 <-- <SYN/ACK> Host B in.rshd
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 <ACK> --> Host B in.rshd
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.
Forwarded from Backup Legal Mega
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 <patches@bsdi.com>
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
~~~~~~~~~
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 <patches@bsdi.com>
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
Forwarded from Backup Legal Mega
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
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