Top Vulnerabilities in Linux Environment

• Introduction
• Top Vulnerabilities 
  • BIND Domain Name System
  • Remote Procedure Calls (RPC)
  • Apache Web Server
  • General UNIX Authentication  -- Accounts with No Passwords or Weak Passwords
  • Clear Text Services
  • Sendmail
  • Simple Network Management Protocol (SNMP)
  • Secure Shell (SSH)
  • Shellshock and other bash vulnerabilities
  • Misconfiguration of Enterprise Services NIS/NFS
  • Open Secure Sockets Layer (SSL)
  • systemd vulnerabilities
•  Common Vulnerable Ports

Introduction

It is generally stupid to talk about individual vulnerabilities without taking into account the general architecture of a particular network segment, especially set of ports opened across the segment. Also routers, switches and even network printers can be as vulnerable or even more vulnerable then individual Linux servers or desktops.

Internet routers are now the most common point of attacks on individual home computers. That means that the usage of a proxy server after the rounter (using some kind of Firewall Micro Appliance ) for internet access now should be viewed as the necessary evil, as the "best practice".

But unfortunately in home networks they are not widely used, mostly because the user lack the necessary skills. That is often true even for home netwrk of system administrators, who are lazy enough to configure VPN for connection with the organization and use completely separate, not connected to home network computer to work with corporate server. Duel use laptops in such case is huge evil. Which means that home networks of system administrators often represent the weakest link in corporate security and the optimal entry point for a determined hacker into corporate or some other networks.

Another important fact is the level of stupidity/gullibility of users in a large organization. It can take various forms. With the most recent, most stunning example being Hillary Clinton email scandal which demonstrated that shadow IT represents a significant and underappreciated danger. And the level of stupidity and greed cannot be overestimated. Note that the level of qualification of system administrators in this case was average at best, and even NIST recommendations were ignored in setup and maintenance of the server(s). So people who installed and maintained the server were not qualified to do that. And such situation is typical for shadow IT.

So the security and vulnerability of Linux is only a small part of the whole puzzle. Human factor is another important variable and some user represent natural Trojan horse in corporate networks. That means that many organizations which enforce monthly or even more frequent patching in a vain attempt to increase their server security actually lower it, as they are barking to the wrong tree. And those efforts might be better used for user education and for improving general architecture (for example blocking the ability of desktops/laptops to communicate with other desktops laptops directly but only via server segment. Even Windows administrators should first connect to some window server (which serve ads multiplexor of remote desktops) and from it to user laptops/desktops.

Fascination with the installation of multiple security products on a corporate desktop is another cancer that recently hit corporate networks. Not only it make desktops/laptops often barely operable, it also provide a false sense of security, offloading the responsively to protect the network of AV vendor. Usefulness of AV in protection of Linux and linux workstations is highly questionable and attempt to "unify" them with Windows are badly advised.

Also security vulnerability patches are created equal. Only very few of them represent remotely exploitable vulnerability and even those presuppose that specific ports are open. which often is not true in corporate or a good home network where only three of for port are allowed to communicate with external sites. (for example, http https, DNS and ssh/scp) Most security patches pushed by vendors like Red hat each month are exploitable only with the account on the server or even some additional conditions.

Claims that open source software is more secure then proprietary solutions can not be taken at their face value. Theoretically this is true, but the complexity of open source software negates this. Historically OpenSSH vulnerabilities were one of the most favorite ways for breaking into Internet ISPs, for at least a half of the decade. According the US Government's database of computer security vulnerabilities maintained by the National Institute of Standards and Technology (http://icat.nist.gov) as of April 15, 2004, there have been more High Severity (remotely exploitable) vulnerabilities found in the Linux operating system than in Microsoft Windows. And this is not surprising as Linux has more goodies installed in the standard setup and more ports opened (recently that changed in RHEL). But if linux installed in minimal configuration (as it should) many of those vulnerabilities are related to non-existent packages and protocols. So the reverse is true -- minimized linux even without hardening is much more secure than any, even hardened, Windows desktop or server.

Also many vulnerabilities are applicable only to specific version of linux or application, or protocol In March 2004, Forrester Research published a report that came to the conclusion that Linux is no more secure than Windows. Also Linux in practice (especially in home networks) is often running with firewall disabled, which is big "no-no" security wise. Amateur users often use root as their user account -- another bog "no-no". Add to this mind boggling complexity of modern Linux where even Apache server probably requires years of study to be configured and used properly and you get the picture.

It is true that Windows is often used is less secure way then Linux (with the user operating all the time from Administrator account or equivalent), but if regular user account is used such mechanisms for providing security as Windows Group policy and cryptographically signed executables beats Linux in default configuration. An excellent security system introduced by Suse AppArmor did not became Linux standard. Red Hat SElinux that few people understand and few configure correctly (most often disable) is dominant.

Only Solaris is competitive in this area. It also benefits from security via obscurity, especially if deployed on Sparc servers.

Another key factor that the number of security flaws discovered is generally proportional to market share, so the dominant OS is the most natural target of attacks. This issue on a new level is often replayed in Linux vs. Solaris security debate. In security, being a non-mainstream has its own set of advantages. There is huge and lucrative market for Windows zero days exploits. Some market exist for Linux too. There is no such market for Solaris.

There is also government sponsored hackers who develop professional exploit for both windows and Linux. Stuxnet, Flame and subsequent set of nasty worms were developed by government and later those technologies fall into the hand of the hackers. Unlike regular munitions, cyber weapons did not explode on contact. They can be captured disassembled, studied and replicated on a new, more sophisticated and dangerous level in a never ending battle of defense and attack tools. When some government unleashed Stuxnet out of the box it literally open the Pandora box of cyber war.

In other words when we discuss security of an individual Linux box this is an abstraction, and often not very useful abstraction,. What we should discuss is the security of network in which particular Linux box is installed. Also there are some "semi-hidden" parts of network infrastructure, for example the subnet on which management interfaces like Dell DRAC or HP ILO exist (and nobody knows how many vulnerabilities those contain and who has them other then NSA), and which are seldom secured properly despite the fact that this is an obvious like of attack on linux servers. As such they represent more subtle and potentially more lucrative way to break into the server the frontal attack. There are a lot of commercial servers, even in major datacenters which still have default passwords for DRAC or ILO, and default accounts still enabled.

All this suggest that when discussing individual vulnerabilities it is important to see the bigger picture -- it is architecture that matter most in providing desirable level of security. What boxes are open to internet and which are not. Which ports are opened across the segment on this sensitive box is installed. Is DMZ configuration used. Is private DNS used? answers to all those questions by-and-large define the level of security that you can achieve. Patching is another interesting topic with its own set of warts. And patching infrastructure can and was in the past used as a way to break into the servers (breaking into repository and installing troyanized versions of some components is just the tip of this iceberg). Again look at the level of stupidity in configuring Hillary bathroom server (Hillary Clinton email scandal) as a pretty educational example how not to do such things.

Smartphone infrastructure (and Android is nothing but a proprietary version of Linux used by Google) in companies is now another "Wild West" with little security and a lot of ways to subvert those few measures that are used. Here stupidity and gullibility of users reached probably its maximum level.

But there silver lining in any dark clouds. first of all there are "DVD-only" distributions which are secure after each reboot. So for highly confidential tasks you can reimage the server from DVD or just use such a distribution. That somewhat guarantees that for the next few hours you work with "clean" system. In general use of non-violable storage can be considered as a measure that is to some extent is alternative to periodic patching. In this case you are guaranteed that you executables will not be troyanized or some accounts or components are added to the system. There is no real necessary for such directories as /bin /usr /boot /root, and some others to be writable. And /etc/while writable consist mostly of static files that can be overwritten as often as you wish from "safe" non-violable storage. This is one way to avoid web site hacking -- nobody can write file on a write protected disks without physical access to the disk.

And then there is such danger as Shadow IT, which often exists below the radar in many highly bureaucratized, fossilized/outsourced IT environments. Which are pretty common for large corporations. This was the essence of Hillary Clinton email hacking scandal. To make long story short the key part of the State Department IT infrastructure -- mail server used by Secretary of state and her close entourage -- was installed as a private "bathroom" Windows-based server with Microsoft Exchange as a mail server directly opened to the Internet. And all this mess was maintained by rank-and-file specialists with mainly experience in IT for non-profits and without proper security training.

After this episode it is easy to stop believing into the ability of the US government to maintain security of its servers. The server (or group of servers ) was configured without any attempt to satisfy NIST guidelines for this type of servers. If you have architecture flaws like this, you are royally f*cked no matter how hard you try to patch individual vulnerabilities. Architecture faults overwrite all this and when we are talking about individual vulnerabilities we assume that sound architecture, proper for desirable level of security of particular server is already in place. Otherwise the whole discussion just does not make any sense.

Forrester measured the time between the discovery of a flaw and the release of a fix for the flaw -- not a perfect but still worthwhile metric. It claims Linux, in this particular sense, was less secure than Windows because not only the total number of security alerts for Linux outnumbered those for Windows, but also because time for fixing it was not impressive. But this is a difficult metric to provide objectively, as the severity of the flaws varies and the most flaws counted against Linux were actually flaws in applications or programming environments that run on Linux, not in the Linux kernel per se. Also with firewall tightly configured many of them just does not make any sense and are not exploitable. Paranoia fueled by greedy security firms, which exaggerate the severity of the flaw and hide the information about conditions necessary for its exploitation, actually does a lot of harm to Linux.

On high level of security with AppArmor enabled (or if you have an expert in SElinux security, able to configure it properly for your case) and with internal firewall not only enabled, but properly configured (emphasize of properly), you simply deny access to most vulnerabilities and it does not matter much if they patched or not -- they are simply inaccessible.

Only very few protocols that are opened (DNS is one example) can be secured by constantly monitoring the integrity of the server and blocking any changes outside /tmp and similar filesystems. In case of DNS using private internal DNS with "fake" root also helps. For small organizations it is possible to use /etc/hosts table instead, eliminating DNS. But even for DNS there are inventive way to improve security -- for example in most organizations DNS tables are pretty much static and can be written on CD instead of hard drive. That makes it harder possibility to modify them you need to create new writable directory copy files and redirect DNS server to this folder -- the task which is difficult to accomplish without already being root. In general the more secure environment you wish to have the larger part of this environment should consist of non writable media.

Another important aspect is what you are running. For example if you do not run X server, it is unclear why you should worry about those vulnerabilities that apply to this environment. In this sense minimization of your installation is the most powerful security tool and early hardening packages like Titan provides some minimization frameworks. Now most commercial distribution have the option "minimal server" which is a good start.

As Linux is an independent POSIX compatible reimplementation of Unix, the principles of Linux hardening are the same as for other Unixes and are well developed. That means that Linux in principle can be more completely and more deeply hardened then Windows, because it is more open system.

But the way how Linux is typically installed often deny or even pervert this advantage. In June 2004, Danish security firm Secunia compared security across operating systems and concluded that Windows was more secure, than many people think. According to a new Aberdeen Group report, open-source solution Linux has surpassed Windows as the most vulnerable OS, contrary to the high-profile press Microsoft's security woes. And march larger share of servers running windows. Furthermore, the Aberdeen Group reports that more than 50 percent of all security advisories that CERT issued in the first 10 months of 2002 were for Linux and other open-source software solutions.

"Open-source software, commonly used in many versions of Linux, UNIX, and network routing equipment, is now the major source of elevated security vulnerabilities for IT buyers," the report reads. "Security advisories for open-source and Linux software accounted for 16 out of the 29 security advisories--about one of every two advisories--published for the first 10 months of 2002. During this same time, vulnerabilities affecting Microsoft products numbered seven, or about one in four of all advisories."

Decentralized nature of Linux development makes possible for critical flows in applications (and sometimes even kernel) to exist for years without detection.

The Aberdeen Group says this information proves that Linux and UNIX are just as prone to Trojan horse attacks as any other OS, despite press reports to the contrary. According to the Aberdeen Group, the open-source community's claim that it can fix security vulnerabilities more quickly than proprietary developers means very little. The group says that the open-source software and hardware solutions need more rigorous security testing before they're released their products to customers. As I mentioned before, it is interesting that open SSH implementation was for several year the preferred way of hacking into Linux ISPs.

We can rail against Microsoft and its security policies (which are indefensible), but far more people and systems use Microsoft's software than any competing software. And most Linux system administrators do not know how secure Linux and are not motivated to do this as it makes their work much more difficult. Linux is moving to Windows environment when "clueless administrator managed servers used by clueless users". And this environment that can't be defended by any technical means.

Moreover even despite the fact that Linux isn't as prevalent as Windows, we're still seeing a gradual increase in Linux security advisories from year to year. We judge that the large companies should exercise caution in deploying Linux on DMZ and deploy Solaris instead, if they are really concerned about hacking and Linux security. Security via obscurity is not a bad thing. Even use of FreeBSD (or, better, OpenBSD) sometimes can dramatically improve the level of security, as it automatically stops most of linux exploits without any patching.

Long time ago, Secunia publishes graphs on the security advisories for Red Hat Enterprise AS3. According to the graphs, 66% of the listed vulnerabilities can be exploited remotely, meaning they are exposed to an attacker who does not have an account on the system. Even if they are wrong by 50% that's a lot. Another graph shows that 17% of the vulnerabilities can allow a cracker to escalate his privileges on the vulnerable system, which means that after getting into the system on non-privileged account the cracker may be able to get root privileges. Secunia page that includes similar graphs for Windows 2003 Enterprise Edition. According to these graphs, only 48% of the Windows 2003 vulnerabilities can be exploited by a remote user, which taking into account weakness of their methodology might mean that in this sense Linux and windows are close. None is superior to another. The number of vulnerabilities that allow a cracker to escalate privileges is only 13% in Windows compared to 17% for Red Hat, which also means that they are close (as those figures need to be taken with a grain of salt and definitely rounded tin a single significant digits, as one percent difference means nothing in this context.

That means that without additional hardening Red Hat Enterprise Server AS3 used to have approximately the same level of risk as Windows 2003 Enterprise Edition. which means both are indefensible against motivated hacker.

In other words the level of security of the system depends on several factors:

• General architecture of particular network (whether NIST recommendations were used to configure the network and servers, is it proxied, firewalled both on entrance from the internet and individual server level, whether AppArmor is used and properly configured (brilliant security idea that never get enough traction as Red Hat supported SElinux), whether organization uses private DNS, uses hostfile for name resolution instead of DNS (not a bad idea for small networks), how well individual server is hardened, etc) and
• the level of hardening
• Qualification of administrators and users.
• Level of security of other components of particular network segment (DRAC or ILO if they are on the same segment, router, switch, etc)

It means that it is almost meaningless to discuss it in abstract terms, It should be self-evident that the most serious type of vulnerability, unless architecture prevent their use, it possible for an attacker without any account on the system to gain administrator privileges and seize control of your system via the Internet both on Windows and Linux. Especially for the attacker who can buy "zero-day" exploit.

If you need highly secure environment, then your network should be isolated from internet, and/or use non IP based communication protocols (such as good old UUCP, BBS infrastructure and Fidonet internally, or on more more modern level by use of Infiniband for UUCP). I actually saw that UUCP was used in some organizations for explicitly this purpose. New is sometimes well forgotten old. The most secure way to use computers is to use isolated non-network computers producing CD/DVDs or just print materials. Rescanning of printed documents is pretty accurate, especially for regular text files. I read somewhere that Russian government, after Stuxnet and Flame were exposed, switched a part of its operation to electric typewriters. That's probably too drastic move, but good old DOS can do wonders for most office tasks and has collection of applications which was produced before NSA figured the ways to troyanize them ;-)

Top Vulnerabilities

The question arises what vulnerabilities of the Linux operating systems are most often targeted by malicious attackers. While there is a non-stopping stream of remotely exploitable Linux vulnerabilities but only few of them were used for actual exploits against the number of servers.

But for the top vulnerabilities it make sense to go extra mile. for example it does not make any sense to open ssh to the world unless absolutely necessary. Restricting IP range via tcp wrappers or firewall in a powerful mechanism of making more secure even top exploitable protocols.

Below we will reproduce slightly edited list of the ten most commonly exploited vulnerabilities similar to on produced by SANS Institute The list for Unix/Linux vulnerabilities currently includes (vulnerabilities that represent additional danger in large corporate environment due to the number of servers with those applications installed):

• Services like Webmin, phpmyadmin, Cpanel, etc that provide Web-based interface for administrators and webmasters. They are typically attacked by script kiddies 24 x 7. As they typically they do not understand what they are doing this is just noise, but still it requires some means to hide ports and make URLs unique for the site. You should never have generic URLs for those applications (Cpanel is an exception for obvious reasons).
  • Web and Application Server Misconfiguration: It is of critical importance that a secure Web application have a strong server configuration standard.
• PHP Web applications misconfigurations or, more commonly, bugs in major PHP applications. PHP is rarely used in enterprise environment, but it attracts lion share of exploits directed against Web sites. The top ten are:
  • Unvalidated Parameters: Those intent on an attack can use this flaw to get at backside components through a Web application. Information from Web requests is not validated before being used by a Web application.
  • Broken Access Control: These flaws can be taken advantage of by hackers to access other users' accounts, view sensitive files or use unauthorized functions. The flaws occur because the restrictions on what authenticated users are allowed to do are not properly enforced.
  • Broken Account and Session Management: This vulnerability occurs when account credentials and session tokens are not properly protected. Attackers can assume other users' identities by compromising passwords, keys, session cookies or other tokens.
  • Cross-Site Scripting (XSS) Flaws: An attacker can use the Web application as a mechanism to transport an attack to an end user's browser. Successfully utilizing this method can disclose the end users' session token, attack the local machine or spoof content to fool the user.
  • Buffer Overflows: Web application components in some languages that do not properly validate input can be crashed and, in some cases, used to take control of a process. These components can include CGI, libraries, drivers and Web application server components.
  • Command Injection Flaws: Web applications pass parameters when they access external systems or the local operating system. If an attacker can embed malicious commands in these parameters, the external system may execute those commands on behalf of the Web application.
  • Error Handling Problems: If an attacker is able to create errors that the Web application does not handle, they can gain detailed system information, deny service, cause security mechanisms to fail or crash the server.
  • Insecure Use of Cryptography: Web applications often use cryptographic functions to protect information and credentials. These functions, along with the code to integrate them, have proven difficult to code properly, often resulting in weak protection.
  • Remote Administration Flaws: Many Web applications allow administrators to access the site using a Web interface. If these administrative functions are not very carefully protected, an attacker can gain full access to all aspects of a site.
• Secure Shell (SSH) -- paradoxically ssh due to complexity of protocol and its implementation is the most common way to get into remote system. Stream of remotely exploitable openssh vulnerabilities has a long and ugly history.
• BIND Domain Name System (large corporations often use appliances for DNS, but that does not mean that they are more secure ;-).
• Java. Exploits against Java programs are actually far more common then exploits against Apache. See the list of PHP vulnerabilities. It is fully applicable. Popular Java-based application can be attacked like popular PHP application with application-specific exploits.
• Open Secure Sockets Layer (SSL) -- like SSH it has a history of nasty exploits. Patching is very important.
• Remote Procedure Calls (RPC). There were several famous malware worms instances that used those vulnerabilities to spread inside corporate environment.
• Apache Web Server (large corporations generally use HTTP proxy and firewall before any Web server, which limit impact of even unpatched exploits)
• General UNIX Authentication problems such as accounts with no passwords or weak passwords. In modern environment chances of cracking password via external login are close to zero, unless the attacker has additional information about the victim. But still prudence dictates the necessity to two factor authentication for any Internet facing server. In this sense many US banks, brokers and financial companies are simply negligent. For you as a customer ability to provide a token is now an important criteria of choosing the financial institution. For example both eTrade and Paypal provide tokens to customers. No externally facing corporate server can use just password authentication. Tokens are really cheap and increase security. CMS protocol and cell phones can be used instead. In this case CMS message is send and serve as the second password after the user authenticated, One time passwords , mascots , etc also increase security of authentication. Individual user mascots allow to distinguish real site from fake one.
• Clear Text Services and shell vulnerabilities (predominantly bash). The most recent was Shellshock (September, 2014).
• Sendmail and set of email based exploits including phishing. Sendmail is outdated and poorly understood by administrator program with multiple vulnerabilities and dismal history of exploits that is still widely used in large corporate environment. The program still has vulnerabilities that were not patched in common distributions but they are becoming more rate. Sendmail mainly is used as a transport mechanism for malware and here the weakest link is not the software but the users. Some phishing attempt are so ingenious, that they can full a large number of users.
• Simple Network Management Protocol (SNMP). This is a little understood by a typical sysadmin protocol which if enabled often has mistakes in configuration. Generally it should be restricted to relevant IPs. Opening it to the world is a big mistake.
• Misconfiguration of Enterprise Services like NIS ( which is still widely used, but gradually is replaced with LDAP), NFS, Samba, etc. Often IP ranges used to open those services are way too wide. The additional problem with Samba is that Unix sysadmin often does not clearly understand mapping of Windows file attributed into extended attributes.

Although there are thousands of security incidents each year affecting major Linux distribution, the majority of successful attacks target one or more of these vulnerable services. Attackers usually are opportunistic. They take the easiest and most convenient route and exploit the best-known flaws with the most effective and widely available attack tools. They count on organizations to be behind in patching, especially patching of application and protocols like SSL, not fixing well-known the problems. They often attack indiscriminately, scanning the Internet for any vulnerable systems.

The best strategy for large corporate is avoidance. On the Unix and Linux side, Berkeley Internet Domain Name (BIND) software remains the top problem software. That means that large corporate should never try to run bind on Linux. Similarly Apache as an external web server should generally work via HTTP proxy. Generally apache is way too complex to be used as Internet facing Web server (but it can and should be used as an internal WEB server, due to its functional superiority over competitors). Running Sendmail on Linux is not recommended for the same reason, as at number 6 it belongs to most vulnerable software on the Unix/Linux servers. In major distribution it was replaced by postfix long ago, so this is only inertia that dictates continued use of Sendmail in enterprise environment.

SANS Institute provides periodic list of top vulnerabilities which while can't be taken at face value, still might contain useful information. It can be viewed on the organization's Web site, The list below is adapted from the SANS Web site and is old. But as reference is still makes sense as it shows the futility of viewing Linux security without considering of network architecture and the level of hardening. It also shows limitation of people at SANS which complied the list. Concentration on individual software vulnerabilities makes sense for the attacker, but much less sense for the defender.

BIND Domain Name System

Description

The Berkeley Internet Name Domain (BIND) package is the most widely used implementation of the Domain Name Service (DNS), a critical system that allows the conversion of hostnames into the registered IP address. Unless you run your own internal DNS (which many corporation do and which constitute a good practice) this is the system exposed to external attacks.

The ubiquity and critical nature of BIND has made it a frequent target, especially in Denial of Service (DoS) attacks, which can result in a complete loss of accessibility to the Internet for services and hosts. Whilst BIND developers have historically been quick to repair vulnerabilities, an inordinate number of outdated, misconfigured and/or vulnerable servers remain in place. Also there are some high level exploit of bind based of architectural flows that are not that easy to patch.

Among old, well know BIND weaknesses was a denial of service discussed in CERT Advisory CA-2002-15. In this case, an attacker can send specific DNS packets to force an internal consistency check which itself is vulnerable and will cause the BIND daemon to shut down. Another was a buffer overflow attack, discussed in CERT Advisory CA-2002-19, in which an attacker utilizes vulnerable implementations of the DNS resolver libraries. By sending malicious DNS responses, the attacker can explore this vulnerability and execute arbitrary code or even cause a denial of service.

A further risk is posed by a vulnerable BIND server, which may be compromised and used as a repository for illicit material without the administrator's knowledge or in stepping-stone attacks which use the server as a platform for further malicious activity.

Operating Systems Affected

Nearly all UNIX and Linux systems are distributed with a version of BIND. To increase the level of protection it is recommended to use self-complied version of bind using Intel compiler and replace with this compiled version the stock version of bind provided by operating system vendor.

Also due to criticality of the service Linux is a bad choice of the platform for its deployment. Solaris should be used instead. For excellent guides to hardening BIND on Solaris systems as well as additional references for BIND documentation, see Running the BIND9 DNS Server Securely and the archives of BIND security papers available from Afentis.

CVE/CAN Entries
CVE-1999-0009, CVE-1999-0024, CVE-1999-0184, CVE-1999-0833, CVE-1999-0837,
CVE-1999-0835, CVE-1999-0849, CVE-1999-0851, CVE-2000-0887, CVE-2000-0888,
CVE-2001-0010, CVE-2001-0011, CVE-2001-0012, CVE-2001-0013

CAN-2002-0029, CAN-2002-0400, CAN-2002-0651, CAN-2002-0684, CAN-2002-1219,
CAN-2002-1220, CAN-2002-1221

How to Determine if you are Vulnerable

for mission critical servers run BIND not installed via RPM, but compiled with appropriate compiler option from source downloaded directly from the Internet Software Consortium (ISC). Or buy a DNS appliance.

Ensure that your externally exposed DNS server runs the latest version of BIND. For most systems, the command "named -v" will show the installed BIND version enumerated as X.Y.Z where X is the major version, Y is the minor version, and Z is a patch level. A proactive approach to maintaining the security of BIND is to subscribe to customized alerting and vulnerability reports. In addition, a vulnerability scanner might be used to check DNS systems for configuration blunders and potential vulnerabilities.

Remote Procedure Calls (RPC)

This subsystem does not need to be exposed to the internet, so it is mostly internal vulnerability, unlike DNS. most corporation now provide access to internal network for both users and sysadmins via VPN, using separate not shared corporate PC/laptops, which often have smart card authentication.

Description
Remote procedure calls (RPCs) allow programs on one computer to execute procedures on a second computer by passing data and retrieving the results. RPC is therefore widely used for many distributed network services such as remote administration, NFS file sharing, and NIS. However there are numerous flaws in RPC which are being actively exploited. Many RPC services execute with elevated privileges that can provide an attacker unauthorized remote root access to vulnerable systems.

The majority of the distributed denial of service attacks launched were executed by systems that had been victimized through these RPC vulnerabilities. The broadly successful attack on U.S. Military systems during the Solar Sunrise incident also exploited an RPC flaw found on hundreds of Department of Defense computer systems. More recently, an MS Windows DCOM Remote Procedure Call vulnerability has played a role in one of the most significant worm propagation events.

Operating Systems Affected
All versions of UNIX and Linux come with RPC services installed and often enabled. It is not always possible to shut down this service as it is widely used and required for NFS implementation. For that reason NFS should not be used on DMZ

CVE/CAN Entries
CVE-1999-0002 , CVE-1999-0003 , CVE-1999-0008 , CVE-1999-0018 , CVE-1999-0019 ,
CVE-1999-0168 , CVE-1999-0170 , CVE-1999-0208 , CVE-1999-0211 , CVE-1999-0493 ,
CVE-1999-0693 , CVE-1999-0696 , CVE-1999-0977 , CVE-1999-0320 , CVE-2000-0666 ,
CVE-2001-0717 , CVE-2001-0779 , CVE-2001-0803 , CVE-2002-0033 , CVE-2002-0391 ,
CVE-2002-0573 , CVE-2002-0679

CAN-2002-0677 , CAN-2003-0028 , CAN-2003-0252

How to Determine if you are Vulnerable

Use a vulnerability scanner or the 'rpcinfo' command to determine if you are running one of the most commonly exploited RPC services:

RPC services are typically exploited through buffer overflow attacks which are successful because the RPC programs do not perform sufficient error checking or input validation. Buffer overflow vulnerabilities allow an attacker to send unexpected data (often in the form of malicious code) into the program memory space. Due to poor error checking and input validation, the data overwrite key memory locations that are in line to be executed by the processor. In a successful overflow attack, this malicious code is then executed by the operating system. Since many RPC services execute with elevated privileges, successful exploitation of these vulnerabilities can provide unauthorized remote root access to the system.

How to Protect Against It
Use the following steps to protect your system against RPC attacks:

1. Turn off or remove any RPC service which is not absolutely necessary for the function of your network.
2. Install the latest patches for any services you cannot remove:

   For Solaris Software Patches:
   http://sunsolve.sun.com

   For IBM AIX Software Patches:
   http://www.ibm.com/support/us
   http://techsupport.services.ibm.com/server/fixes

   For SGI Software Patches:
   http://support.sgi.com

   For Compaq (Digital UNIX) Software Patches:
   http://www.compaq.com/support

   For Linux Software Patches:
   http://www.redhat.com/apps/support/errata
   http://www.debian.org./security

   For HP-UX Software Enhancements and Patch Bundles:
   http://www.software.hp.com/portal/swdepot/displayProductsList.do?category=ER

3. Regularly search the vendor patch database for new patches and install them right away.
4. Block the RPC portmapper, port 111 (TCP and UDP) and Windows RPC, port 135 (TCP and UDP), at the border router or firewall.
5. Block the RPC "loopback" ports, 32770-32789 (TCP and UDP).
6. Enable a non-executable stack on those operating systems that support this feature. While a non-executable stack will not protect against all buffer overflows, it can hinder the exploitation of some standard buffer overflow exploits publicly available on the Internet.
7. For NFS exported file systems, the following steps should be taken:
   1. Use host/IP based export lists.
   2. Set up exported file systems for read-only or no-suid wherever possible.
   3. Use 'nfsbug' to scan for vulnerabilities.

   A summary document pointing to specific guidance about three principal RPC vulnerabilities - Tooltalk, Calendar Manager, and Statd - may be found at: http://www.cert.org/incident_notes/IN-99-04.html.

   Summary documents pointing to specific guidance about the above RPC vulnerabilities may be found at:

   • Statd: http://www.cert.org/advisories/CA-2000-17.html
     http://www.cert.org/advisories/CA-1999-05.html
     http://www.cert.org/advisories/CA-1997-26.html
   • Tooltalk: http://www.cert.org/advisories/CA-2002-26.html
     http://www.cert.org/advisories/CA-2002-20.html
     http://www.cert.org/advisories/CA-2001-27.html
   • Calendar Manager: http://www.cert.org/advisories/CA-2002-25.html
     http://www.cert.org/advisories/CA-1999-08.html
   • Cachefsd: http://www.cert.org/advisories/CA-2002-11.html
   • Sadmind: http://www.cert.org/advisories/CA-1999-16.html
     http://www.cert.org/advisories/CA-2001-11.html
   • Mountd: http://www.cert.org/advisories/CA-1998-12.html
   • SnmpXdmid: http://www.cert.org/advisories/CA-2001-05.html
   • Rwalld: http://www.cert.org/advisories/CA-2002-10.html
   • XDR: http://www.cert.org/advisories/CA-2003-10.html

Apache Web Server

In large corporation Apache or other Web server is never exposed to Intent directly. Usually it is exposed via proxy such as BlueCoat. But small ISPs and small companies have Apache exposed directly.

Apache has historically been, and continues to be the most popular web server on the Internet. In comparison to Microsoft's Internet Information Server, Apache may have a cleaner record in regards to security, but it still has its fair share of vulnerabilities. In addition to exploits in Apaches core and modules (CA-2002-27, CA-2002-17), SQL, databases, CGI, PHP vulnerabilities are all potentially exposed through the web server.

If left unsecured, vulnerabilities in the Apache web server implementation and associated components can result in denial of service, information disclosure, web site defacement, remote root access, or countless other unfavorable results.

Affected Operating Systems

All UNIX systems running Apache. Many Linux and UNIX variants come with Apache installed and sometimes enabled by default. Like in case of bind it is recommended to compile own version of Apache before deployment.

CVE/CAN Entries
CVE-1999-0021, CVE-1999-0066, CVE-1999-0067, CVE-1999-0070, CVE-1999-0146,
CVE-1999-0172, CVE-1999-0174, CVE-1999-0237, CVE-1999-0260, CVE-1999-0262,
CVE-1999-0264, CVE-1999-0266, CVE-2000-0010, CVE-2000-0208, CVE-2000-0287,
CVE-2000-0941, CVE-2002-0082, CVE-2002-0392

CAN-1999-0509, CAN-2000-0832, CAN-2002-0061, CAN-2002-0513, CAN-2002-0655,
CAN-2002-0656, CAN-2002-0657, CAN-2002-0682, CAN-2003-0132, CAN-2003-0189,
CAN-2003-0192, CAN-2003-0254

How to Determine if you are Vulnerable
Information regarding security advisories for Apache 2.x security information resides at http://httpd.apache.org/security/

How to Protect Against It

1. Ensure that you are running the latest patch level.
   • http://httpd.apache.org provides the most recent versions and patch levels available.
   • Source code for the most recent version(s) of Apache is available at http://httpd.apache.org/download.cgi
   • The latest patches are available at http://www.apache.org/dist/httpd/patches/
2. Ensure that core operating system components that are referenced by Apache are patched. Only the modules necessary for your server to function properly should be compiled into Apache. note: The mod_ssl worm (CA-2002-27) is a perfect example that resulted from vulnerabilities within OpenSSL (CA-2002-23).
3. Never run Apache as root. A unique user and group with minimal privileges should be created for running Apache. No other system processes should be run under this user or group.
4. Limit the server information that is revealed.
   While this suggestion tends to encounter opposition from people suggesting security by obscurity is not the way and a number of exploit attempts you will see are done in a blind sweeping fashion (proven by the fact that you will see in many Apache logs IIS exploit attempt after IIS exploit attempt), there are also some exploits that will trigger based on header information.
   • Modify the default Apache HTTP response token.
     1. For Apache 1.3.x see http://httpd.apache.org/docs/mod/core.html#servertokens http://httpd.apache.org/docs/mod/core.html#serversignature.
     2. For Apache 2.0.x see http://httpd.apache.org/docs-2.0/en/mod/core.html#servertokens.
   • Ensure that mod_info is not accessible from the Internet.
   • Directory indexing should be disabled.
5. For security centitive systems always run Apache in a chroot environment. If Apache is started chroot-ed it cannot access any part of the operating system directory structure outside of the chroot. This can often critical to prevent exploits. For example, an exploit may call a shell and since /bin/sh likely does not (and should not) reside in the chroot, it would be ineffective.
   As there are numerous methods of chrooting, software documentation should be consulted for assistance. Additional information can be found below.
   • http://www.w3.org/Security/Faq/wwwsf3.html#SVR-Q5
   • http://www.modsecurity.org/documentation/apache-internal-chroot.html
6. Efficient and thorough logging is essential to effectively track down any potential security problems or unexplained behavior you may be experiencing with your web server. It is a good practice to routinely rotate logs and keep older logs archived. This will make the log size more manageable and easier to parse through if necessary.
   Various information regarding log formats and rotation are available here:
   • For Apache 1.3.x see: http://httpd.apache.org/docs/logs.html
   • For Apache 2.0.x see: http://httpd.apache.org/docs-2.0/logs.html

   In many scenarios the content of these logs may not be sufficient. Especially if youre using PHP, CGI or other scripting it is a good idea to log GET and POST payloads. This can yield important data and evidence in the event of a security compromise. Logging of GET and POST payloads can be implemented via mod_security.

   • http://www.modsecurity.org
   • http://www.securityfocus.com/infocus/17064.152.44.126 152.44.126
7. PHP, CGI, SSI and other scripting.
   • For security sensitive systems you should disable PHP, CGI, SSI and other scripting languages as it is difficult/impossible to protect then from exploits. Use only precompiled static pages.
   • Disable Server Side Includes (SSI) which can potentially be abused and cause the web server to execute code which it was not intended to.
   • If PHP, CGI, SSI or other scripting languages are necessary, consider utilizing suEXEC. suEXEC allows scripts to be run under Apache with a user id other than the Apache user id.
     WARNING: It is imperative that suEXEC is understood thoroughly. If it is improperly utilized it can create new security holes.
     1. For Apache 1.3.x see http://httpd.apache.org/docs/suexec.html
     2. For Apache 2.0.x see http://httpd.apache.org/docs-2.0/suexec.html
   • Ensure the content of cgi-bin and other scripts directories. All sample and default scripts should be removed.
   • Securing PHP:
     This is a broad topic in and of itself. What follows gives some sound starting points for ensuring your PHP implementation is secure.
     1. Disable parameters that will cause PHP to disclose information in the HTTP header.
     2. Ensure that PHP is running in safe mode.

     Detailed information can be found here:
     http://www.securityfocus.com/printable/infocus/1706

   • Additional modules can aid in security. The mod_security (www.modsecurity.org) module can help protect against Cross Site Scripting (XSS) and SQL injection. Detailed implementation instructions can be found at their website.
   • Auditing your scripts for vulnerabilities including XSS and SQL injection is also important. There are a few open source tools that will accomplish this. Nikto (available at http://www.cirt.net/code/nikto.shtml) is one of the more comprehensive CGI scanning tools.

General Unix Authentication Accounts
with No Passwords or Weak Passwords

This is mostly an internal vulnerability as in no way you should be able to authenticate to internal system from Internet for security sensitive systems. Only from private VPN. It is an external vulnerability for ISPs and small companies that does no use VPN for this purpose. In this case one time passord system or security token should be used to avoid cracking of password database See recent Yahoo hack for details Yahoo discloses hack of 1 billion accounts

Google provides two factor authentication which as we know now Podesta did not use which lead to huge embarrassment when his emails were stolen due to simplistic phishing scheme (he proved to be completely incompetent idiot as for computer security, as most of Hillary Clinton entourage; was too lazy to use two factor authentication that Google provides):

Signing in to your account will work a little differently

1. You'll enter your password.Whenever you sign in to Google, you'll enter your password as usual.
2. You'll be asked for something else. Then, a code will be sent to your phone via text, voice call, or our mobile app. Or, if you have a Security Key, you can insert it into your computer's USB port.

Passwords, passphrases and/or security codes are used in virtually every interaction between users and information systems. The most simplisitc (one factor) authentication, as well as file and data protection, rely heavily on user or vendor supplied passwords. In addition, since properly authenticated access is often not logged, or if logged not likely to arouse suspicion, a compromised password is an opportunity to explore a system virtually undetected. An attacker in possession of a valid user password would have complete access to any resources available to that user, and would be significantly closer to being able to access other accounts, nearby machines, and perhaps even obtain root level access on this system. Despite this threat, user and administrator level accounts with poor or non-existent passwords are still very common. As well, organizations with a well-developed and enforced password policy are still uncommon.

The most common password vulnerabilities are:

• user accounts that have weak or nonexistent passwords;
• users accounts with widely known or openly displayed passwords;
• system or software created administrative level accounts with widely known, weak, or nonexistent passwords;
• weak or well known password hashing algorithms and/or user password hashes that are stored with weak security and are visible to anyone.

The best defense against all of these vulnerabilities is a strong authentication policy that includes usage of Secure Id or smartcards. We also need to create detailed instructions for users for strong passwords creation; explicit rules for users to ensure their passwords remain secure; a process for IT staff to promptly replace weak/insecure/default or widely known passwords and to promptly lock down inactive or close down unused accounts; and a proactive and regular process of checking all passwords for strength and complexity.

Operating Systems Affected
Any operating system or application on any platform where users authenticate via a user ID and password. In Linux You we should requre to use the MD5 algorithm to hash passwords; this is somewhat more secure than the older crypt algorithm.

CVE/CAN Entries
CVE-1999-0502

How to Protect Against It
The best and most appropriate defense against password weaknesses is a strong policy which provides detailed instructions to engender good user password habits and also entails regular proactive checking of password integrity by system administrators with complete support from the organization. The following steps should be used as guidelines for a good password policy:

1. Assure that passwords are consistently strong. Given enough hardware resources and enough time, any password can be cracked using brute force guessing. Password crackers that are employed by attackers use what are known as dictionary-style attacks. Since common password encryption methods are widely known, the cracking utilities simply compare the encrypted form of a target password against the encrypted forms of all dictionary words (in many languages), along with proper names, and various common permutations of both. Therefore a password that in any way resembles a word (or words in almost any documented language) is highly susceptible to a dictionary attack. Many organizations instruct users to generate passwords by including combinations of alphanumeric and special characters, and users more often than not adhere by taking a word (e.g., password) and converting letters to numbers or special characters (e.g., pa$$w0rd). Such permutations cannot protect against a dictionary attack: pa$$w0rd is as likely to be cracked as password.

   A good password therefore cannot have a word or proper name as its root. A strong password policy should direct users to generate passwords from something more random, like a phrase or a longer title of a book or song. By concatenating a longer phrase into a string (i.e., taking the first letter of each word in the phrase (preferably in mixed case), or substituting a special character for a word in the initial phrase, and/or replacing all the vowels in that concatenated phrase with various special characters, etc.), users can generate sufficiently long password strings which combine alphanumeric and special characters in a way that dictionary attacks will have greater difficulty cracking. And if the initial phrase is easy to remember, then the resulting password string should be as well.

   Once users are given the proper instructions for generating good passwords, detailed procedures should be put in place to assure that these instructions are followed. The best way to do this is by validating the password whenever the user changes it. Most flavors of UNIX/LINUX can use Npasswd as a front-end to check entered passwords against your password policy. PAM-enabled systems can also be extended to include cracklib (the libraries which accompany Crack) to check passwords as they are generated. Most new PAM-enabled systems can also be setup to refuse bad passwords that do not meet certain guidelines.

   However, if passwords cannot be verified against dictionary libraries when they are entered using tools such as Npasswd or PAM-enabled libraries, then cracking utilities should be run by the system administrator in a stand-alone mode as part of a regular proactive procedure. Tools like those used by potential attackers are generally the best choice. On a UNIX/LINUX-based platform, that would include Crack and John the Ripper.

   Please Note: Never run a password scanner, even on systems for which you have root-like access, without explicit and preferably written permission from your employer/organization. Administrators with the most benevolent of intentions have been fired for running password cracking tools without the authority to do so. This authority should be in the form of a written letter that forms part of the organizations strong password policy and allows for regular scheduled password checks.

   Once you have acquired authority to run cracking utilities on your system, do so regularly on a physically protected and secure machine. The tools on the machine should not be openly accessible to anyone but the authorized system administrator. Users whose passwords are cracked should be notified confidentially and given instructions on how to choose a better password. As part of the organizations password policy, both administrators and management should develop these notification procedures together, so that management can provide guidance and/or assistance when users do not respond to these notifications.

   Other possible options to protect against nonexistent or weak passwords and/or to maintain password policy procedures are (a) to use an alternative form of authentication such as password-generating tokens or biometrics. These are effective if you are having trouble with weak passwords and can be used as an alternative means of authenticating users. It should be noted that some password-generating tokens need procedures in place to ensure they are not openly accessible to unauthorized users and if stolen they are promptly denied from the system. Biometrics is a developing area and depending on the type of authentication (e.g., fingerprints versus facial recognition), some of the technology has not been perfected and errors in authentication may be common. (b) There are many comprehensive third party tools (free and commercial) available to help manage good password policy.
   

2. Protect Strong Passwords. If you store password hashes in /etc/passwd, update your system to use /etc/shadow. If your system runs NIS or LDAP in such a way that hashes cannot be protected, anyone (even non-authenticated users) can read your password hashes and attempt cracking. You should look for more secure alternatives to the NIS and LDAP version you are running. Until those insecure applications can be secured/replaced, you should secure proper permission and run proactive cracking as a regular procedure against those applications as well. Consider using the MD5 algorithm to hash your passwords instead of crypt.

   However, even if passwords themselves are strong, accounts can be compromised if users do not protect their passwords. A good password policy should include detailed procedures for a user that require that a user should never tell his or her password to anyone else, never write a password down where it could be read by others, properly secure any files in which a password is stored for automate authentication, and if a password is known to be stolen or known by others, to promptly notify the system administrator. Password aging should be enforced so that any passwords which slip through these rules are only vulnerable for a short window of time, and old passwords should not be reused. Administrators should make sure that the users are given warning of a pending password change and several chances to change their password before it expires. When faced with the message Your password has expired and must be changed, users will tend to pick a bad password.
   

3. Tightly Control Accounts. Any service-based or administrative accounts not in use should be disabled or if possible removed completely. Any service-based or administrative accounts which are used should be given new and strong passwords as soon as the service or account is installed or activated. Configure new user accounts with randomly-generated initial passwords, and force users to change them when they first log in. Audit the accounts on your systems on a regular and proactive basis, and maintain a master list of all of these accounts detailing the service requiring the account and the intended need. Develop stringent procedures for adding/removing authorized accounts to/from the list. Have rigid procedures for removing accounts when employees or contractors leave or when the accounts are no longer required. Validate the master list on a regular scheduled basis to make sure no new accounts have been added and that unused accounts have been removed. In addition, do not forget to check the accounts and passwords on supporting systems like routers, switches, and Internet-connected digital printers, copiers and printer controllers.

Clear Text Services

Many network services utilized by UNIX systems are clear-text (also known as "plain text"). That means that there is no encryption used by those services. Lack of encryption allows everybody who is observing network traffic ("sniffing") to gain access to either communication contents and/or authentication credentials.

For example, to steal the FTP or telnet login information, an attacker needs to place a network sniffer somewhere along the connection path, such as on the FTP server LAN or on the client LAN. The transmission of information between R-command clients and R-services in plain-text permits data or keystrokes to be intercepted as well. Attackers have often deployed sniffers in recent security incidents and often on compromised machines. Finding usernames and passwords in sniffed data is very easy.

Here is a summary table of most common UNIX network services which are transmitted in clear text.

Services such as telnet and FTP where both contents and authentication credentials are transmitted in clear text present the highest risk, since attacker will be able to reuse the credentials and access the system at their leisure. Additionally, command session run in clear text may also be hijacked and used by the attacker to run commands without authentication.

Here is the risk summary from clear text services:

The Operating Systems Affected
All UNIX flavors contain clear-text services (telnet and FTP being the most common). All UNIX/Linux flavors with the possible exception of the latest editions of Free/OpenBSD ship with some of the services enabled by default.

CVE/CAN Entries
CVE-2000-0087

CAN-2002-0322, CAN-2000-0086

How to Determine if you are Vulnerable
The most effective and reliable way to determine whether clear text services are in use is to use a sniffer tool similar to those used by attackers.

The most commonly used sniffer is "tcpdump" Run it as:

# tcpdump -X -s 1600

to detect any clear text communication. "Tcpdump" may be obtained at http://www.tcpdump.org.

Another such tool is "ngrep" which allows one to look for specific patterns in network communication, such as "sername" or "assword" (the first letters are removed to accomodate for possible capitalization). Run the tool as:

# ngrep assword

"Ngrep" may be obtained at http://www.packetfactory.net/projects/ngrep/.

There are also more sophisticated tools specifically designed to detect authentication credentials on the network. "Dsniff" is the most popular tool of that sort. Simply running:

# /usr/sbin/dsniff

will make the tool to detect and print all username-password pairs detected on the network in a large number of plain text protocols, such as FTP, telnet or POP3. Dsniff may be obtained at http://www.monkey.org/~dugsong/dsniff/.

How to Protect Against It
Using end-to-end or at least link-level encryption will help. Some protocols have encrypted equivalents such as POP3S and HTTPS. For the protocols which do not have native encryption capabilities, one can tunnel them over SSH (Secure Shell) or SSL connection.

As an example: FTP might be replaced with more secure software solutions such as SFTP or SCP (parts of the Secure Shell software package) and use a web server to distribute files to a wide audience.

The most popular and flexible SSH implementation is OpenSSH (available at http://www.openssh.org). It runs on most UNIX variants and may be used for remote interactive sessions (replaces telnet, rlogin and rsh) and tunneling (of POP3, SMTP, X11 and many other protocols).

Here is how one can tunnel POP3 over SSH connection. The POP3 server needs to be also running the SSH server. First run this on the client machine:

# ssh -L 110:pop3.mail.server.com:110 [email protected]

Now, point your email client to localhost, TCP port 110 (unlike the usual 'pop3.mail.server.com', port 110). All communication between your machine and the POP3 mail server will be tunneled over SSH and thus encrypted.

Another popular encrypted tunneling solution is "stunnel". It implements SSL protocol (via OpenSSL toolkit) and may be used to tunnel various plain text protocols. Stunnel may be obtained at http://www.stunnel.org/.

Sendmail

Sendmail is the program that sends, receives, and forwards most electronic mail processed on UNIX and Linux systems. Sendmail is the most popular Mail Transfer Agent (MTA) and its widespread use on the Internet has historically made it a prime target of attackers, resulting in numerous exploits over the years.

Most of these exploits are successful only against older or unpatched versions of the software. Despite the fact that the known vulnerabilities are well documented and have been repaired in newer releases, there remain so many outdated or misconfigured versions still in use today that Sendmail remains one of the most frequently attacked services. Among the most recent critical vulnerabilities are:

• CERT Advisory CA-2003-12 Buffer Overflow in Sendmail
• CERT Advisory CA-2003-07 Remote Buffer Overflow in Sendmail
• CERT Advisory CA-2003-25 Buffer Overflow in Sendmail

CERT Advisory CA-2003-12 Buffer Overflow in Sendmail gives the following excellent description of a Sendmail buffer overflow and the danger it poses to network integrity.

This vulnerability is message-oriented as opposed to connection-oriented. That means that the vulnerability is triggered by the contents of a specially-crafted email message rather than by lower-level network traffic. This is important because an MTA that does not contain the vulnerability will pass the malicious message along to other MTAs that may be protected at the network level. In other words, vulnerable sendmail servers on the interior of a network are still at risk, even if the site's border MTA uses software other than sendmail. Also, messages capable of exploiting this vulnerability may pass undetected through many common packet filters or firewalls.

The risks presented by running Sendmail can be grouped into two major categories: privilege escalation caused by buffer overflows, and improper configuration that allows your machine to be a relay for electronic mail from any other machine. The former is a problem on any system still running older or unpatched versions of the software. The latter results from using either improper or default configuration files, and is a chief obstacle to fighting the proliferation of spam.

Operating Systems Affected
Nearly all UNIX and Linux systems come with a version of Sendmail installed that is enabled and running by default.

CVE/CAN Entries
CVE-1999-0047, CVE-1999-0095, CVE-1999-0096, CVE-1999-0129, CVE-1999-0131,
CVE-1999-0203, CVE-1999-0204, CVE-1999-0206, CVE-1999-1109, CVE-2000-0319,
CVE-2001-0653, CVE-2001-1349, CVE-2002-0906

CAN-1999-0098, CAN-1999-0163, CAN-2001-0713, CAN-2001-0714, CAN-2001-0715,
CAN-2002-1165, CAN-2002-1278, CAN-2002-1337, CAN-2003-0161, CAN-2003-0285

How to Determine if you are Vulnerable
Sendmail has had a large number of vulnerabilities in the past. Do not always trust the version string returned by the daemon as that is just read from a text file on the system that may not have been updated properly.

Any outdated or unpatched version of the software is likely to be vulnerable.

To determine the version of Sendmail, use the following command:

echo \$Z | /usr/lib/sendmail -bt -d0

Depending on your system, the path to Sendmail may be different and you have to modify the above command accordingly to point to the right path.

To determine whether the version you are running is current, check the current release of Sendmail version at:
http://www.sendmail.org/current-release.html

How to Protect Against It
The following steps should be taken to protect Sendmail:

1. Upgrade to the latest version and/or implement patches. The source code can be found at http://www.sendmail.org/. If your version of Sendmail came packaged with your operating system, patches should be available at your operating system vendor's website (various vendor-specific information, including compile-time and configuration suggestions, is also available at http://www.sendmail.org).
2. Sendmail is typically enabled by default on most UNIX and Linux systems, even those which are not acting as mail servers or mail relays. Do not run Sendmail in daemon mode (turn off the "-bd" switch) on these machines. You can still send email from this system by configuring it to point to a mail relay in the sendmail configuration file, sendmail.cf (which is typically located at /etc/mail/sendmail.cf).
3. If you must run Sendmail in daemon mode, ensure that your configuration is designed to relay mail appropriately and only for systems under your purview. See http://www.sendmail.org/tips/relaying.html and http://www.sendmail.org/m4/anti_spam.html for assistance in properly configuring your server. Starting with Sendmail 8.9.0, open relaying was disabled by default.
4. When you change to a new version of Sendmail, it is also recommended to change the configuration files that are provided with that version as older configurations may still allow relaying even when running the newest code. It is now possible to build a Sendmail configuration file (sendmail.cf) using the configuration files provided with the Sendmail release. Additional details on Sendmail configuration can be obtained at http://www.sendmail.org/m4/readme.html.
5. When you download the Sendmail distribution you must verify the PGP signature to ensure it is an authentic copy. Do not use Sendmail without verifying the integrity of the source code. Trojan copies of Sendmail have existed in the past. Please read the CERT Advisory CA-2002-28 Trojan Horse Sendmail Distribution to learn more. Keys used to sign Sendmail distributions can be obtained at http://www.sendmail.org/ftp/PGPKEYS. In the absence of PGP, you should use the MD5 checksums to verify the integrity of the Sendmail source code distribution.
6. Additional information on how to configure and run Sendmail in a more secure manner can be obtained at:
   http://www.sendmail.org/secure-install.html
   http://www.sendmail.org/m4/security_notes.html
   http://www.sendmail.org/~gshapiro/security.pdf

Simple Network Management Protocol (SNMP)

The Simple Network Management Protocol (SNMP) is used extensively to remotely monitor and configure almost all types of modern TCP/IP-enabled devices. While SNMP is rather ubiquitous in its distribution across networking platforms, it is most often used as a method to configure and manage devices such as printers, routers, switches, access points, and to provide input for network monitoring services. Simple Network Management communication consists of different types of exchanged messages between SNMP management stations and network devices which run what is commonly referred to as agent software. The method by which these messages are handled and the authentication mechanism behind such message handling both have significant exploitable vulnerabilities.

The vulnerabilities behind the method by which SNMP version 1 handles and traps messages are outlined in detail in CERT Advisory CA-2002-03. There exists a set of vulnerabilities in the way trap and request messages are handled and decoded by management stations and agents alike. These vulnerabilities are not restricted to any specific implementation of SNMP but instead affect a variety of vendors' SNMP distributions. The result of attackers exploiting these vulnerabilities may range anywhere from denial of service to unwanted configuration and management of your SNMP-enabled machinery.

The authentication mechanism of older SNMP frameworks also poses a significant vulnerability. SNMP versions 1 and 2 use an unencrypted "community string" as their only authentication mechanism. Lack of encryption is bad enough, but the default community string used by the vast majority of SNMP devices is "public," with a few supposedly clever network equipment vendors changing the string to "private" for more sensitive information. Attackers can use this vulnerability in SNMP to reconfigure or shut down devices remotely. Sniffed SNMP traffic can reveal a great deal about the structure of your network as well as the systems and devices attached to it. Intruders use such information to pick targets and plan attacks.

Most vendors enable SNMP version 1 by default, and many do not offer products capable of using SNMP version 3's security models which can be configured to use improved authentication methods. However, there are freely-available replacements which do provide SNMPv3 support under GPL or BSD licenses.

SNMP is not unique to UNIX; it is extensively used on Windows, in networking equipment, wireless access points and bridges, printers and embedded devices. But the majority of SNMP-related attacks seen thus far have occurred on UNIX systems with poor SNMP configurations.

Operating Systems Affected
Nearly all UNIX and Linux systems come with SNMP installed, and often by default it is enabled. Most other SNMP-enabled network devices and operating systems are also vulnerable.

CVE/CAN Entries
CVE-2001-0236, CVE-2002-0797

CAN-1999-0186, CAN-1999-0254, CAN-1999-0516, CAN-1999-0517, CAN-1999-0615,
CAN-2002-0012, CAN-2002-0013, CAN-2002-0796

How to Determine if you are Vulnerable
You can verify whether SNMP is running on network-connected devices by running a scanner or checking manually.
SNMPing - You can obtain the free SNMPing scanning tool from the SANS Institute by emailing a blank mail message to [email protected]. You will get a return message with the URL where you can download the tool.
SNScan - Foundstone created another easy-to-use SNMP scanning tool called SNScan, which can be obtained at http://www.foundstone.com/knowledge/free_tools.html.

If you cannot use any of the above tools, you should manually verify if SNMP is running on your systems. Refer to your operating system documentation on how to specifically identify its particular SNMP implementation, but the basic daemon can usually be identified by grepping for "snmp" in the process list or by looking for services running on ports 161 or 162.

A running SNMP instance is probably sufficient evidence that you are vulnerable to pervasive trap and request handling errors. Please see CERT Advisory CA-2002-03 for additional information.

If SNMP is running and any of these additional variables are met, you may have a default or easily guessable string-related vulnerability:

1. Blank or default SNMP community names.
2. Guessable SNMP community names.
3. Hidden SNMP community strings.

Please see http://www.sans.org/resources/idfaq/snmp.php for information on how to identify the presence of those conditions.

How to Protect Against It
Trap and Request Handling Vulnerabilities:

1. If you do not absolutely require SNMP, disable it.
2. Wherever possible, employ an SNMPv3 user-based security model with message authentication and possibly encryption of the protocol data unit.
3. If you must use SNMPv1 or v2, make sure you are running the latest patched version from your vendor. A good starting point in obtaining vendor specific information is Appendix A of CERT Advisory CA-2002-03.
4. Filter SNMP (port 161 TCP/UDP and 162 TCP/UDP) at the ingress points to your networks unless it is absolutely necessary to poll or manage devices externally.
5. Employ host-based access control on your SNMP agent systems. While this capability may be limited by SNMP agent operating system capabilities, control of what systems your agents will accept requests from may be possible. On most UNIX systems this can be accomplished through a TCP-Wrappers or Xinetd configuration. An agent-based packet filtering firewall on the host can also be used to block unwanted SNMP requests.

Default and Guessable String-Related Vulnerabilities:

1. If you do not absolutely require SNMP, disable it.
2. Wherever possible, employ an SNMPv3 user-based security model with message authentication and possibly encryption of the protocol data unit.
3. If you must use SNMPv1 or v2, use the same policy for community names as used for passwords. Make sure they are difficult to guess or crack and they are changed periodically.
4. Validate and check community names using snmpwalk. Additional information can be found at http://www.zend.com/manual/function.snmpwalk.php. A good tutorial on this tool can be found at http://www.sans.org/resources/idfaq/snmp.php.
5. Filter SNMP (port 161 TCP/UDP and 162 TCP/UDP) at the ingress points to your networks unless it is absolutely necessary to poll or manage devices externally. Then, if possible, configure filtering to only permit SNMP traffic between trusted subnets.
6. Where possible make MIBs read-only. Additional information can be found at http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/snmp.htm#xtocid210315.

Secure Shell (SSH)

Description
Secure shell (SSH) is a popular service for securing logins, command execution, and file transfers across a network. Most UNIX-based systems use either the open-source OpenSSH package or the commercial version from SSH Communication Security. Although SSH is vastly more secure than the telnet, ftp, and R-command programs it is intended to replace, there have been multiple flaws found in both implementations. Most are minor bugs, but a few are major security issues that should be repaired immediately. The most dangerous of these actively exploited holes allows attackers to remotely obtain root access on a vulnerable machine.

It should also be noted that there is a growing use of SSH clients and servers in the Windows environment and that most of the information in this section applies to both the *nix and Windows implementations of SSH.

While SSH is presented here as one of the Top 20 vulnerabilities, it is more the case that the mismanagement of SSH, specifically misconfiguration and the failure to apply updates and patches in a timely manner, account for its inclusion in this list.

SSH2 is actually a powerful tool that when properly configured and maintained can help remediate many of the other top 20 vulnerabilities, specifically those that send material in clear text across untrusted networks like the Internet. Many of the vulnerabilities found in protocols such as POP3, FTP (replace with SSH2s SFTP), Telnet, HTTP, and the rhost based tools (rlogin, rcp, and rsh) involve eavesdropping on clear text transmissions or manipulating client server sessions. This makes encryption and authentication key management provided by SSH2 along with its ability to forward or redirect sessions, an attractive VPN type of wrapper for otherwise vulnerable traffic.

The SSH1 protocol itself has been demonstrated to be potentially vulnerable to having a session decrypted in transit given certain configurations. For this reason, administrators are encouraged to use the stronger SSH2 protocol whenever possible.

Note: SSH1 and SSH2 are not compatible. With only a few exceptions, the version of SSH on both the client and the server must match.

In addition, users of OpenSSH should note that the OpenSSL libraries against which OpenSSH is typically built have software vulnerabilities of their own. Please see CERT Advisory 2002-23 for more details. They should also be aware that a trojan-horse version of the OpenSSH was being distributed for a short time in the summer of 2002 (CAN-1999-0661). Please see http://www.openssh.org/txt/trojan.adv for details about ensuring that your version is not affected.

Operating Systems Affected
Any UNIX or Linux system running OpenSSH 3.3 or earlier (version 3.6.1 was released on April 1, 2003), or SSH Communication Security's SSH 3.0.0 or earlier (3.2.5 was released on June 30, 2003).

CVE/CAN Entries
For SSH from SSH Communications Security:
CVE-2000-0217, CVE-2000-0575, CVE-2000-0992, CVE-2001-0259, CVE-2001-0361,
CAN-2001-0471, CVE-2001-0553

For SSH from OpenSSH:
CVE-2000-0525, CVE-2000-1169, CVE-2001-0060, CVE-2001-0144, CVE-2001-0361,
CVE-2001-0872, CVE-2002-0002, CVE-2002-0083

CAN-2001-1380, CAN-2002-0575, CAN-2002-0639, CAN-2002-0640, CAN-2002-0765,
CAN-2003-0386

Multiple implementations of SSH:
CAN-2002-1357, CAN-2002-1358, CAN-2002-1359, CAN-2002-1360

How to Determine if you are Vulnerable
Use a vulnerability scanner to see whether you are running a vulnerable version, or check the software version reported by running the command 'ssh -V'.

The ScanSSH tool is particularly useful for remotely identifying SSH servers that are dangerously un-patched. The ScanSSH command line tool scans a list of addresses and networks for SSH protocol servers and reports their version numbers. Written by Niels Provos and released under the BSD-license, the latest version was released on 2001-11-30 and is available at http://www.monkey.org/~provos/scanssh/.

How to Protect Against It

1. Upgrade to the most recent version of either OpenSSH or SSH. Or if SSH or OpenSSH came installed with your operating system, retrieve the latest patches from your operating system vendor. If you use OpenSSL, be sure to use the latest version of those libraries.
2. Where possible, upgrade from SSH1 to SSH2. SSH1 does not appear to be under further development, while SSH2 is in active development. Where migration is not possible, begin developing plans and strategies that will make migration to SSH2 possible.
3. Both the SSH implementations include a variety of configuration options to restrict what machines can connect, what users are allowed to authenticate, and via what mechanisms. Administrators should determine how these options could most appropriately be set for their environment.
4. Verify that each SSH client is not configured to revert back to the rsh program when connecting to a server that does not support SSH. The FallBackToRsh key should be set to No in the SSH configuration file.
5. Specify the use of blowfish encryption rather than the 3DES, which may be the default of the version. This will provide faster operation without reducing the effective encryption strength.
6. A host providing SSH services must itself be adequately protected otherwise vulnerabilities that allow the host to be compromised put the SSH service at risk.

Misconfiguration of Enterprise Services NIS/NFS

Description

The Network File System (NFS) and Network Information Service (NIS) are two important services used in UNIX networks. NFS is a service originally created by Sun Microsystems that is designed to share files among UNIX systems over a network. NIS is also a set of services that works as a database service to provide location information, called Maps, to other network services such as NFS. The most common examples of these Maps are the passwd and group files which are used to centralize user authentication.

The security problems with both services, represented by the continuous issues discovered over the years (buffer overflows, DoS and weak authentication), made them a frequent target of attack.

Besides the unpatched services that are still widely deployed, the higher risks may be represented by the misconfiguration of NFS and NIS that will easily allow security holes to be exploited and accessed by users locally or remotely.

The lax authentication offered by NIS while querying NIS maps allow users to use applications like ypcat that can display the values of NIS database, or map, to retrieve the password file. The same kind of problem occurs with NFS which implicitly trusts the UID (user ID) and GIDs (group ID) that the NFS client presents to the server, and depending on the server configuration, this may allow any user to mount and explore the remote file system.

Operating Systems Affected
Nearly all UNIX and Linux systems come with a version of NFS and NIS installed and often enabled by default.

CVE/CAN Entries
NFS
CVE-1999-0002, CVE-1999-0166, CVE-1999-0167, CVE-1999-0170, CVE-1999-0211,
CVE-1999-0832, CVE-1999-1021, CVE-2000-0344

CAN-1999-0165, CAN-1999-0169, CAN-2000-0800, CAN-2002-0830, CAN-2002-1228,
CAN-2003-0252, CAN-2003-0379, CAN-2003-0576

NIS
CVE-1999-0008, CVE-1999-0208, CVE-1999-0245, CVE-2000-1040

CAN-1999-0795, CAN-2002-1232, CAN-2003-0176, CAN-2003-0251

How to Determine if you are Vulnerable
The following steps are related to NIS/NFS software vulnerabilities:

1. Verify that you are current with the patches released by your vendor. For most versions the command rpc.mountd -version for NFS and ypserv -version for NIS will show the version of both. Any unpatched or outdated version of the software is likely to be vulnerable.
2. For software vulnerabilities, a more complete approach would be to use an updated vulnerability scanner to periodically check your system against new flaws.

The following steps are related to NIS configuration:

1. Ensure that Root password is not maintained in an NIS map.
2. Check if the users passwords are in accord with the security practices. A password cracker can be used to accomplish this.

   Please Note: Never run a password cracker, even on systems for which you have root-like access, without explicit and preferably written permission from your employer. Administrators with the most benevolent of intentions have been fired for running password cracking tools without authority to do so.

The following steps are related to NFS configuration:

1. Verify if the hosts, netgroups and permissions in the /etc/exports file is up-to-date.
2. Run the command showmount e to see what has been exported. Check to see if your mounts are in compliance with your security policy.

How to Protect Against It

The following steps are related to NIS configuration:

1. In each client you can explicitly list the NIS servers to bind to, preventing another systems from masquerading as a NIS server.
2. While making the DBM files, activate the YP_SECURE feature to ensure that the server will only answer requests from a client on privileged ports. This can be accomplished by using the switch s with the command makedbm.
3. Include the trusted hosts and networks in the /var/yp/securenets used by the ypserv and the ypxfrd processes, and remember to restart the daemons to get the changes to take effect.
4. On your NFS Clients be sure to have the entry +:*:0:0::: in your password map.

The following steps are related to NFS configuration:

1. Use numeric IP addresses or fully qualified domain names instead of aliases when allowing clients in the /etc/exports file.
2. A tool called NFSBug can be used to test the configuration. The tests will include finding world exported file systems, determining whether export restrictions work, determining whether file systems can be mounted through the portmapper, trying to guess file handles, and exercising various bugs to access file systems. ftp://coast.cs.purdue.edu/pub/tools/unix/nfsbug/
3. Use the /etc/exports file to restrict access to NFS file system by adding parameters:
   • Prevent normal users from mounting an NFS file system by adding a secure parameter after the IP address or domain name of your NFS client. (e.g.: /home 10.20.1.25(secure) )
   • Export the NFS file system with appropriate permissions. This could be done by adding the appropriate permission (ro for Read-only or rw for Read-Write) after the IP address or domain name of your NFS client in the /etc/exports file. (e.g.: /home 10.20.1.25(ro) )
   • If possible, use the parameter root_squash after the IP address or domain name of your NFS client. If this parameter is enabled, the superuser ID root on NFS Client will be replaced by the user ID nobody in the NFS Server. This means that the root user on the client can't access or change files that only root on the server can access or change, preventing it from gaining superuser privileges in the server. (e.g.: /home 10.20.1.25(root_squash) )
   • A complete set of parameters can be found in the /etc/exports manpage. http://www.netadmintools.com/html/5exports.man.html
4. On Solaris O.S. make sure to activate the Port Monitoring feature. This can be done by adding the line set nfssrv:nfs_portmon = 1 on the /etc/system file.

   A Linux system by default denies cooperation with NFS clients using a non-privileged port.

General considerations related to NIS and NFS:

1. Review your firewall policies and be sure to block all unnecessary ports, as well Port 111 (Portmap) and Port 2049 (Rpc.nfsd). Also allow access to the NIS and NFS servers only from authorized clients. A local measure can also be applied by restricting access through tcp_wrappers located at http://sunsite.cnlab-switch.ch/ftp/software/security/security-porcupine.org/. In your etc/hosts.allow file you should state the service and IP allowed to access the service (e.g. portmap: 10.20.1.1/16 to allow the network 10.20.0.0 to access the portmap service). Also, in the /etc/hosts.deny file, you should include the services and the IPs that are NOT allowed to access the services (e.g.: portmap: ALL, which will deny access to all other IP addresses that are not included in the /etc/hosts.allow). The Portmap service is an important service to have the access denied because it is the one that the NFS operates though.
2. Consider the use of NFS over a secure protocol like SSH. A good start point is http://www.math.ualberta.ca/imaging/snfs/.
3. Apply all vendor patches or upgrade your NIS and NFS Servers to the latest version. For more information about hardening your UNIX installation, see the CERTs UNIX Security Checklist.
4. Disable the NFS and NIS daemons on any system that is not specifically designated and authorized to be a NFS and/or NIS server. To prevent this change from being reversed, it may be wise to also remove the NFS and/or NIS software.

Open Secure Sockets Layer (SSL)

Description

The open-source OpenSSL library is a popular package to add cryptographic security to applications that communicate over the network. Although Apache is probably the most well-known use of the package (to support https: connections on port 443), many other programs have been modified to use OpenSSL for security.

The usual usage of OpenSSL is a toolkit where other applications use OpenSSL to provide cryptographic security for a connection. As a result, rather than targeting OpenSSL directly, the exploits for the vulnerabilities will target the application using it. One popular exploit attacks the Apache server's use of OpenSSL. Just because you are not running Apache with OpenSSL support does not mean you are safe. A suitable modification of the exploit may be able to attack Sendmail, openldap, CUPS, or any other OpenSSL using program installed on the target machine.

Multiple vulnerabilities have been found in OpenSSL, of which the most serious are the set of 4 vulnerabilities listed in CAN-2002-0655, CAN-2002-0656, CAN-2002-0557, and CAN-2002-0659. These allow the remote execution of arbitrary code as the user of the OpenSSL libraries (which in some cases, such as 'sendmail', is the 'root' user).

Operating Systems Affected
Any UNIX or Linux system running OpenSSL 0.9.7 or earlier. Note that quite often, OpenSSL is installed to support some other component. For instance, on a RedHat Linux 9.0 system packages such as Apache, CUPS, Curl, OpenLDAP, Stunnel, and Sendmail (among others) all use the OpenSSL libraries to secure connections.

CVE/CAN Entries
CVE-1999-0428, CVE-2001-1141

CAN-2000-0535, CAN-2002-0655, CAN-2002-0656, CAN-2002-0557, CAN-2002-0659,
CAN-2003-0078, CAN-2003-0131, CAN-2003-0147

How to Determine if you are Vulnerable
Check the output of the command 'openssl version'. If the version isn't 0.9.7a or later, you are vulnerable.

How to Protect Against It

1. Upgrade to the most recent version of OpenSSL. If OpenSSL came installed with your operating system, retrieve the latest patches from your operating system vendor. Note that in some cases, re-compiling and/or re-linking of applications may be required to enable the updated libraries. Note that one of the most common usages of OpenSSL is for securing HTTP traffic over the public Internet for e-commerce where restricting hosts is probably not feasible.

Common Vulnerable Ports

In this section, we will reproduce SANS list of ports that are commonly probed and attacked.

NEWS CONTENTS

• 20210723 : NVD - CVE-2021-33909 ( Jul 23, 2021 , nvd.nist.gov )
• 20210527 : Pen testing with Linux security tools - Opensource.com ( May 27, 2021 , opensource.com )
• 20210129 : Sudo vulnerability allows attackers to gain root privileges on Linux systems (CVE-2021-3156) - Help Net Security ( Jan 29, 2021 , www.helpnetsecurity.com )
• 20141003 : Everything you need to know about the Shellshock Bash bug ( September 25, 2014 , troyhunt.com )
• 20141003 : Shellshock (software bug) ( en.wikipedia.org )
• 20141003 : Frequently Asked Questions about the Shellshock Bash flaws ( Sep 26, 2014 , securityblog.redhat.com )
• 20141003 : https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/ ( https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/, )
• 20140929 : Shellshock: How to protect your Unix, Linux and Mac servers by Steven J. Vaughan-Nichols ( zdnet.com )
• 20140929 : http://support.novell.com/security/cve/CVE-2014-6271.html ( 26 Sep 2014 , support.novell.com )

Old News ;-)

[Jul 23, 2021] NVD - CVE-2021-33909

A vulnerability (CVE-2021-33909) in the Linux kernel's filesystem layer that may allow local, unprivileged attackers to gain root privileges on a vulnerable host has been unearthed by researchers.

"Qualys security researchers have been able to independently verify the vulnerability, develop an exploit, and obtain full root privileges on default installations of Ubuntu 20.04, Ubuntu 20.10, Ubuntu 21.04, Debian 11, and Fedora 34 Workstation. Other Linux distributions are likely vulnerable and probably exploitable," said Bharat Jogi, Senior Manager, Vulnerabilities and Signatures, Qualys.

Jul 23, 2021 | nvd.nist.gov

Description

fs/seq_file.c in the Linux kernel 3.16 through 5.13.x before 5.13.4 does not properly restrict seq buffer allocations, leading to an integer overflow, an Out-of-bounds Write, and escalation to root by an unprivileged user, aka CID-8cae8cd89f05.

http://packetstormsecurity.com/files/163621/Sequoia-A-Deep-Root-In-Linuxs-Filesystem-Layer.html

http://www.openwall.com/lists/oss-security/2021/07/22/7

https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.13.4

https://github.com/torvalds/linux/commit/8cae8cd89f05f6de223d63e6d15e31c8ba9cf53b

https://lists.debian.org/debian-lts-announce/2021/07/msg00014.html

https://lists.debian.org/debian-lts-announce/2021/07/msg00015.html

https://lists.debian.org/debian-lts-announce/2021/07/msg00016.html

https://lists.fedoraproject.org/archives/list/[email protected]/message/Z4UHHIGISO3FVRF4CQNJS4IKA25ATSFU/

https://www.debian.org/security/2021/dsa-4941

https://www.openwall.com/lists/oss-security/2021/07/20/1

[May 27, 2021] Pen testing with Linux security tools - Opensource.com

May 27, 2021 | opensource.com

Pen testing with Linux security tools Use Kali Linux and other open source tools to uncover security gaps and weaknesses in your systems. 25 May 2021 Peter Gervase (Red Hat) Feed 26 up Image credits : Lewis Cowles, CC BY-SA 4.0 x Subscribe now

Get the highlights in your inbox every week.

https://opensource.com/eloqua-embedded-email-capture-block.html?offer_id=70160000000QzXNAA0

The multitude of well-publicized breaches of large consumer corporations underscores the critical importance of system security management. Fortunately, there are many different applications that help secure computer systems. One is Kali , a Linux distribution developed for security and penetration testing. This article demonstrates how to use Kali Linux to investigate your system to find weaknesses.

Kali installs a lot of tools, all of which are open source, and having them installed by default makes things easier.

kali-tools.png

^{(Peter Gervase, CC BY-SA 4.0 )}

The systems that I'll use in this tutorial are:

1. kali.usersys.redhat.com : This is the system where I'll launch the scans and attacks. It has 30GB of memory and six virtualized CPUs (vCPUs).
2. vulnerable.usersys.redhat.com : This is a Red Hat Enterprise Linux 8 system that will be the target. It has 16GB of memory and six vCPUs. This is a relatively up-to-date system, but some packages might be out of date.
3. This system also includes httpd-2.4.37-30.module+el8.3.0+7001+0766b9e7.x86_64 , mariadb-server-10.3.27-3.module+el8.3.0+8972+5e3224e9.x86_64 , tigervnc-server-1.9.0-15.el8_1.x86_64 , vsftpd-3.0.3-32.el8.x86_64 , and WordPress version 5.6.1.

I included the hardware specifications above because some of these tasks are pretty demanding, especially for the target system's CPU when running the WordPress Security Scanner ( WPScan ).

Investigate your system

I started my investigation with a basic Nmap scan on my target system. (You can dive deeper into Nmap by reading Using Nmap results to help harden Linux systems .) An Nmap scan is a quick way to get an overview of which ports and services are visible from the system initiating the Nmap scan.

nmap-scan.png

^{(Peter Gervase, CC BY-SA 4.0 )}

This default scan shows that there are several possibly interesting open ports. In reality, any open port is possibly interesting because it could be a way for an attacker to breach your network. In this example, ports 21, 22, 80, and 443 are nice to scan because they are commonly used services. At this early stage, I'm simply doing reconnaissance work and trying to get as much information about the target system as I can.

I want to investigate port 80 with Nmap, so I use the -p 80 argument to look at port 80 and -A to get information such as the operating system and application version.

nmap-port80.png

^{(Peter Gervase, CC BY-SA 4.0 )}

Some of the key lines in this output are:

PORT STATE SERVICE VERSION
80 / tcp open http Apache httpd 2.4.37 (( Red Hat Enterprise Linux ))
| _http-generator: WordPress 5.6.1

Since I now know this is a WordPress server, I can use WPScan to get information about potential weaknesses. A good investigation to run is to try to find some usernames. Using --enumerate u tells WPScan to look for users in the WordPress instance. For example:

┌── ( root💀kali ) - [ ~ ]
└─ # wpscan --url vulnerable.usersys.redhat.com --enumerate u
_______________________________________________________________
__ _______ _____
\ \ / / __ \ / ____ |
\ \ / \ / /| | __ ) | ( ___ ___ __ _ _ __ ®
\ \ / \ / / | ___ / \___ \ / __ |/ _ ` | '_ \
\ /\ / | | ____) | (__| (_| | | | |
\/ \/ |_| |_____/ \___|\__,_|_| |_|

WordPress Security Scanner by the WPScan Team
Version 3.8.10
Sponsored by Automattic - https://automattic.com/
@_WPScan_, @ethicalhack3r, @erwan_lr, @firefart
_______________________________________________________________

[+] URL: http://vulnerable.usersys.redhat.com/ [10.19.47.242]
[+] Started: Tue Feb 16 21:38:49 2021

Interesting Finding(s):
...
[i] User(s) Identified:

[+] admin
| Found By: Author Posts - Display Name (Passive Detection)
| Confirmed By:
| Author Id Brute Forcing - Author Pattern (Aggressive Detection)
| Login Error Messages (Aggressive Detection)

[+] pgervase
| Found By: Author Posts - Display Name (Passive Detection)
| Confirmed By:
| Author Id Brute Forcing - Author Pattern (Aggressive Detection)
| Login Error Messages (Aggressive Detection)

This shows there are two users: admin and pgervase . I'll try to guess the password for admin by using a password dictionary, which is a text file with lots of possible passwords. The dictionary I used was 37G and had 3,543,076,137 lines.

Like there are multiple text editors, web browsers, and other applications you can choose from, there are multiple tools available to launch password attacks. Here are two example commands using Nmap and WPScan:

# nmap -sV --script http-wordpress-brute --script-args userdb=users.txt,passdb=/path/to/passworddb,threads=6 vulnerable.usersys.redhat.com

# wpscan --url vulnerable.usersys.redhat.com --passwords /path/to/passworddb --usernames admin --max-threads 50 | tee nmap.txt

This Nmap script is one of many possible scripts I could have used, and scanning the URL with WPScan is just one of many possible tasks this tool can do. You can decide which you would prefer to use

This WPScan example shows the password at the end of the file:

┌── ( root💀kali ) - [ ~ ]
└─ # wpscan --url vulnerable.usersys.redhat.com --passwords passwords.txt --usernames admin
_______________________________________________________________
__ _______ _____
\ \ / / __ \ / ____ |
\ \ / \ / /| | __ ) | ( ___ ___ __ _ _ __ ®
\ \ / \ / / | ___ / \___ \ / __ |/ _ ` | '_ \
\ /\ / | | ____) | (__| (_| | | | |
\/ \/ |_| |_____/ \___|\__,_|_| |_|

WordPress Security Scanner by the WPScan Team
Version 3.8.10
Sponsored by Automattic - https://automattic.com/
@_WPScan_, @ethicalhack3r, @erwan_lr, @firefart
_______________________________________________________________

[+] URL: http://vulnerable.usersys.redhat.com/ [10.19.47.242]
[+] Started: Thu Feb 18 20:32:13 2021

Interesting Finding(s):

..

[+] Performing password attack on Wp Login against 1 user/s
Trying admin / redhat Time: 00:01:57 <==================================================================================================================> (3231 / 3231) 100.00% Time: 00:01:57
Trying admin / redhat Time: 00:01:57 <========================================================= > (3231 / 6462) 50.00% ETA: ??:??:??
[SUCCESS] - admin / redhat

[!] Valid Combinations Found:
| Username: admin, Password: redhat

[!] No WPVulnDB API Token given, as a result vulnerability data has not been output.
[!] You can get a free API token with 50 daily requests by registering at https://wpscan.com/register

[+] Finished: Thu Feb 18 20:34:15 2021
[+] Requests Done: 3255
[+] Cached Requests: 34
[+] Data Sent: 1.066 MB
[+] Data Received: 24.513 MB
[+] Memory used: 264.023 MB
[+] Elapsed time: 00:02:02

The Valid Combinations Found section near the end contains the admin username and password. It took only two minutes to go through 3,231 lines.

I have another dictionary file with 3,238,659,984 unique entries, which would take much longer and leave a lot more evidence.

Using Nmap produces a result much faster:

┌── ( root💀kali ) - [ ~ ]
└─ # nmap -sV --script http-wordpress-brute --script-args userdb=users.txt,passdb=password.txt,threads=6 vulnerable.usersys.redhat.com
Starting Nmap 7.91 ( https: // nmap.org ) at 2021 -02- 18 20 : 48 EST
Nmap scan report for vulnerable.usersys.redhat.com ( 10.19.47.242 )
Host is up ( 0.00015s latency ) .
Not shown: 995 closed ports
PORT STATE SERVICE VERSION
21 / tcp open ftp vsftpd 3.0.3
22 / tcp open ssh OpenSSH 8.0 ( protocol 2.0 )
80 / tcp open http Apache httpd 2.4.37 (( Red Hat Enterprise Linux ))
| _http-server-header: Apache / 2.4.37 ( Red Hat Enterprise Linux )
| http-wordpress-brute:
| Accounts:
| admin:redhat - Valid credentials <<<<<<<
| pgervase:redhat - Valid credentials <<<<<<<
| _ Statistics: Performed 6 guesses in 1 seconds, average tps: 6.0
111 / tcp open rpcbind 2 - 4 ( RPC #100000)
| rpcinfo:
| program version port / proto service
| 100000 2 , 3 , 4 111 / tcp rpcbind
| 100000 2 , 3 , 4 111 / udp rpcbind
| 100000 3 , 4 111 / tcp6 rpcbind
| _ 100000 3 , 4 111 / udp6 rpcbind
3306 / tcp open mysql MySQL 5.5.5-10.3.27-MariaDB
MAC Address: 52 : 54 :00:8C:A1:C0 ( QEMU virtual NIC )
Service Info: OS: Unix

Service detection performed. Please report any incorrect results at https: // nmap.org / submit / .
Nmap done: 1 IP address ( 1 host up ) scanned in 7.68 seconds

However, running a scan like this can leave a flood of HTTPD logging messages on the target system:

10.19.47.170 - - [18/Feb/2021:20:14:01 -0500] "POST /wp-login.php HTTP/1.1" 200 7575 "http://vulnerable.usersys.redhat.com/" "WPScan v3.8.10 (https://wpscan.org/)"
10.19.47.170 - - [18/Feb/2021:20:14:00 -0500] "POST /wp-login.php HTTP/1.1" 200 7575 "http://vulnerable.usersys.redhat.com/" "WPScan v3.8.10 (https://wpscan.org/)"
10.19.47.170 - - [18/Feb/2021:20:14:00 -0500] "POST /wp-login.php HTTP/1.1" 200 7575 "http://vulnerable.usersys.redhat.com/" "WPScan v3.8.10 (https://wpscan.org/)"
10.19.47.170 - - [18/Feb/2021:20:14:00 -0500] "POST /wp-login.php HTTP/1.1" 200 7575 "http://vulnerable.usersys.redhat.com/" "WPScan v3.8.10 (https://wpscan.org/)"
10.19.47.170 - - [18/Feb/2021:20:14:00 -0500] "POST /wp-login.php HTTP/1.1" 200 7575 "http://vulnerable.usersys.redhat.com/" "WPScan v3.8.10 (https://wpscan.org/)"
10.19.47.170 - - [18/Feb/2021:20:14:00 -0500] "POST /wp-login.php HTTP/1.1" 200 7575 "http://vulnerable.usersys.redhat.com/" "WPScan v3.8.10 (https://wpscan.org/)"
10.19.47.170 - - [18/Feb/2021:20:14:02 -0500] "POST /wp-login.php HTTP/1.1" 200 7575 "http://vulnerable.usersys.redhat.com/" "WPScan v3.8.10 (https://wpscan.org/)"
10.19.47.170 - - [18/Feb/2021:20:14:02 -0500] "POST /wp-login.php HTTP/1.1" 200 7575 "http://vulnerable.usersys.redhat.com/" "WPScan v3.8.10 (https://wpscan.org/)"
10.19.47.170 - - [18/Feb/2021:20:14:02 -0500] "POST /wp-login.php HTTP/1.1" 200 7575 "http://vulnerable.usersys.redhat.com/" "WPScan v3.8.10 (https://wpscan.org/)"

To get information about the HTTPS server found in my initial Nmap scan, I used the sslscan command:

┌── ( root💀kali ) - [ ~ ]
└─ # sslscan vulnerable.usersys.redhat.com
Version: 2.0.6-static
OpenSSL 1.1.1i-dev xx XXX xxxx

Connected to 10.19.47.242

Testing SSL server vulnerable.usersys.redhat.com on port 443 using SNI name vulnerable.usersys.redhat.com

SSL / TLS Protocols:
SSLv2 disabled
SSLv3 disabled
TLSv1.0 disabled
TLSv1.1 disabled
TLSv1.2 enabled
TLSv1.3 enabled
< snip >

This shows information about the enabled SSL protocols and, further down in the output, information about the Heartbleed vulnerability:

Heartbleed:
TLSv1.3 not vulnerable to heartbleed
TLSv1.2 not vulnerable to heartbleed Tips for preventing or mitigating attackers More Linux resources

• Linux commands cheat sheet
• Advanced Linux commands cheat sheet
• Free online course: RHEL Technical Overview
• Linux networking cheat sheet
• SELinux cheat sheet
• Linux common commands cheat sheet
• What are Linux containers?
• Our latest Linux articles

There are many ways to defend your systems against the multitude of attackers out there. A few key points are:

• Know your systems: This includes knowing which ports are open, what ports should be open, who should be able to see those open ports, and what is the expected traffic on those services. Nmap is a great tool to learn about systems on the network.
• Use current best practices: What is considered a best practice today might not be a best practice down the road. As an admin, it's important to stay up to date on trends in the infosec realm.
• Know how to use your products: For example, rather than letting an attacker continually hammer away at your WordPress system, block their IP address and limit the number of times they can try to log in before getting blocked. Blocking the IP address might not be as helpful in the real world because attackers are likely to use compromised systems to launch attacks. However, it's an easy setting to enable and could block some attacks.
• Maintain and verify good backups: If an attacker comprises one or more of your systems, being able to rebuild from known good and clean backups could save lots of time and money.
• Check your logs: As the examples above show, scanning and penetration commands may leave lots of logs indicating that an attacker is targeting the system. If you notice them, you can take preemptive action to mitigate the risk.
• Update your systems, their applications, and any extra modules: As NIST Special Publication 800-40r3 explains, "patches are usually the most effective way to mitigate software flaw vulnerabilities, and are often the only fully effective solution."
• Use the tools your vendors provide: Vendors have different tools to help you maintain their systems, so make sure you take advantage of them. For example, Red Hat Insights , included with Red Hat Enterprise Linux subscriptions, can help tune your systems and alert you to potential security threats.

Learn more

This introduction to security tools and how to use them is just the tip of the iceberg. To dive deeper, you might want to look into the following resources:

• Armitage , an open source attack management tool
• Red Hat Product Security Center
• Red Hat Security Channel
• NIST's Cybersecurity page
• Using Nmap results to help harden Linux systems

[Jan 29, 2021] Sudo vulnerability allows attackers to gain root privileges on Linux systems (CVE-2021-3156) - Help Net Security

Jan 29, 2021 | www.helpnetsecurity.com

Sudo vulnerability allows attackers to gain root privileges on Linux systems (CVE-2021-3156)

A vulnerability ( CVE-2021-3156 ) in sudo, a powerful and near-ubiquitous open-source utility used on major Linux and Unix-like operating systems, could allow any unprivileged local user to gain root privileges on a vulnerable host (without authentication).

"This vulnerability is perhaps the most significant sudo vulnerability in recent memory (both in terms of scope and impact) and has been hiding in plain sight for nearly 10 years," said Mehul Revankar, Vice President Product Management and Engineering, Qualys, VMDR, and noted that there are likely to be millions of assets susceptible to it.

About the vulnerability (CVE-2021-3156)

Also dubbed Baron Samedit (a play on Baron Samedi and sudoedit), the heap-based buffer overflow flaw is present in sudo legacy versions (1.8.2 to 1.8.31p2) and all stable versions (1.9.0 to 1.9.5p1) in their default configuration.

"When sudo runs a command in shell mode, either via the -s or -i command line option, it escapes special characters in the command's arguments with a backslash. The sudoers policy plugin will then remove the escape characters from the arguments before evaluating the sudoers policy (which doesn't expect the escape characters) if the command is being run in shell mode," sudo maintainer Todd C. Miller explained .

"A bug in the code that removes the escape characters will read beyond the last character of a string if it ends with an unescaped backslash character. Under normal circumstances, this bug would be harmless since sudo has escaped all the backslashes in the command's arguments. However, due to a different bug, this time in the command line parsing code, it is possible to run sudoedit with either the -s or -i options, setting a flag that indicates shell mode is enabled. Because a command is not actually being run, sudo does not escape special characters. Finally, the code that decides whether to remove the escape characters did not check whether a command is actually being run, just that the shell flag is set. This inconsistency is what makes the bug exploitable."

Qualys researchers, who unearthed and reported CVE-2021-3156, have provided additional technical details and instructions on how users can verify whether they have a vulnerable version.

They developed several exploit variants that work on Ubuntu 20.04, Debian 10, and Fedora 33, but won't be sharing the exploit code publicly. "Other operating systems and distributions are also likely to be exploitable," they pointed out.

Fixes are available

The bug has been fixed in sudo 1.9.5p2, downloadable from here .

Patched vendor-supported version have been provided by Ubuntu , RedHat , Debian , Fedora , Gentoo , and others.

Though it only allows escalation of privilege and not remote code execution, CVE-2021-3156 could be leveraged by attackers who look to compromise Linux systems and have already managed to get access (e.g., through brute force attacks).

[Oct 03, 2014] Everything you need to know about the Shellshock Bash bug

September 25, 2014 | troyhunt.com

Remember Heartbleed? If you believe the hype today, Shellshock is in that league and with an equally awesome name albeit bereft of a cool logo (someone in the marketing department of these vulns needs to get on that). But in all seriousness, it does have the potential to be a biggie and as I did with Heartbleed, I wanted to put together something definitive both for me to get to grips with the situation and for others to dissect the hype from the true underlying risk.

To set the scene, let me share some content from Robert Graham's blog post who has been doing some excellent analysis on this. Imagine an HTTP request like this:

target = 0.0.0.0/0
port = 80
banners = true
http-user-agent = shellshock-scan (http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html)
http-header = Cookie:() { :; }; ping -c 3 209.126.230.74
http-header = Host:() { :; }; ping -c 3 209.126.230.74
http-header = Referer:() { :; }; ping -c 3 209.126.230.74

Which, when issued against a range of vulnerable IP addresses, results in this:

[Oct 03, 2014] Shellshock (software bug)

en.wikipedia.org

Analysis of the source code history of Bash shows that the vulnerabilities had existed undiscovered since approximately version 1.13 in 1992.^[4] The maintainers of the Bash source code have difficulty pinpointing the time of introduction due to the lack of comprehensive changelogs.^[1]

In Unix-based operating systems, and in other operating systems that Bash supports, each running program has its own list of name/value pairs called environment variables. When one program starts another program, it provides an initial list of environment variables for the new program.^[14] Separately from these, Bash also maintains an internal list of functions, which are named scripts that can be executed from within the program.^[15] Since Bash operates both as a command interpreter and as a command, it is possible to execute Bash from within itself. When this happens, the original instance can export environment variables and function definitions into the new instance.^[16] Function definitions are exported by encoding them within the environment variable list as variables whose values begin with parentheses ("()") followed by a function definition. The new instance of Bash, upon starting, scans its environment variable list for values in this format and converts them back into internal functions. It performs this conversion by creating a fragment of code from the value and executing it, thereby creating the function "on-the-fly", but affected versions do not verify that the fragment is a valid function definition.^[17] Therefore, given the opportunity to execute Bash with a chosen value in its environment variable list, an attacker can execute arbitrary commands or exploit other bugs that may exist in Bash's command interpreter.

The name "shellshock" is attributed^{[by whom?][not in citation given]} to Andreas Lindh from a tweet on 24 September 2014.^{[18][non-primary source needed]}

On October 1st, Zalewski released details of the final bugs, and confirmed that Florian's patch does indeed prevent them. Zalewski says fixed

CGI-based web server attack

When a web server uses the Common Gateway Interface (CGI) to handle a document request, it passes various details of the request to a handler program in the environment variable list. For example, the variable HTTP_USER_AGENT has a value that, in normal usage, identifies the program sending the request. If the request handler is a Bash script, or if it executes one for example using the system(3) call, Bash will receive the environment variables passed by the server and will process them as described above. This provides a means for an attacker to trigger the Shellshock vulnerability with a specially crafted server request.^[4] The security documentation for the widely used Apache web server states: "CGI scripts can ... be extremely dangerous if they are not carefully checked."^[20] and other methods of handling web server requests are often used. There are a number of online services which attempt to test the vulnerability against web servers exposed to the Internet.^{[citation needed]}

SSH server example

OpenSSH has a "ForceCommand" feature, where a fixed command is executed when the user logs in, instead of just running an unrestricted command shell. The fixed command is executed even if the user specified that another command should be run; in that case the original command is put into the environment variable "SSH_ORIGINAL_COMMAND". When the forced command is run in a Bash shell (if the user's shell is set to Bash), the Bash shell will parse the SSH_ORIGINAL_COMMAND environment variable on start-up, and run the commands embedded in it. The user has used their restricted shell access to gain unrestricted shell access, using the Shellshock bug.^[21]

DHCP example

Some DHCP clients can also pass commands to Bash; a vulnerable system could be attacked when connecting to an open Wi-Fi network. A DHCP client typically requests and gets an IP address from a DHCP server, but it can also be provided a series of additional options. A malicious DHCP server could provide, in one of these options, a string crafted to execute code on a vulnerable workstation or laptop.^[9]

Note of offline system vulnerability

The bug can potentially affect machines that are not directly connected to the Internet when performing offline processing, which involves the use of Bash.^{[citation needed]}

Initial report (CVE-2014-6271)

This original form of the vulnerability involves a specially crafted environment variable containing an exported function definition, followed by arbitrary commands. Bash incorrectly executes the trailing commands when it imports the function.^[22] The vulnerability can be tested with the following command:

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

In systems affected by the vulnerability, the above commands will display the word "vulnerable" as a result of Bash executing the command "echo vulnerable", which was embedded into the specially crafted environment variable named "x".^[23][24]

There was an initial report of the bug made to the maintainers of Bash (Report# CVE-2014-6271). The bug was corrected with a patch to the program. However, after the release of the patch there were subsequent reports of different, yet related vulnerabilities. On 26 September 2014, two open-source contributors, David A. Wheeler and Norihiro Tanaka, noted that there were additional issues, even after patching systems using the most recently available patches. In an email addressed to the oss-sec list and the bash bug list, Wheeler wrote: "This patch just continues the 'whack-a-mole' job of fixing parsing errors that began with the first patch. Bash's parser is certain [to] have many many many other vulnerabilities".^[25]
On 27 September 2014, Michal Zalewski announced his discovery of several other Bash vulnerabilities,^[26] one based upon the fact that Bash is typically compiled without address space layout randomization.^[27] Zalewski also strongly encouraged all concerned to immediately apply a patch made available by Florian Weimer.^[26][27]

CVE-2014-6277

CVE-2014-6277 relates to the parsing of function definitions in environment variables by Bash. It was discovered by Michał Zalewski.^{[26][27][28][29]}

This causes a segfault.

() { x() { _; }; x() { _; } <<a; }

CVE-2014-6278

CVE-2014-6278 relates to the parsing of function definitions in environment variables by Bash. It was discovered by Michał Zalewski.^[30][29]

() { _; } >_[$($())] { echo hi mom; id; }

CVE-2014-7169

On the same day the bug was published, Tavis Ormandy discovered a related bug which was assigned the CVE identifier CVE-2014-7169.^[21] Official and distributed patches for this began releasing on 26 September 2014.^{[citation needed]} Demonstrated in the following code:

env X='() { (a)=>\' sh -c "echo date"; cat echo

which would trigger a bug in Bash to execute the command "date" unintentionally. This would become CVE-2014-7169.^[21]

Testing example

Here is an example of a system that has a patch for CVE-2014-6271 but not CVE-2014-7169:

$ X='() { (a)=>\' bash -c "echo date"
bash: X: line 1: syntax error near unexpected token `='
bash: X: line 1: `'
bash: error importing function definition for `X'
$ cat echo
Fri Sep 26 01:37:16 UTC 2014

The patched system displays the same error, notifying the user that CVE-2014-6271 has been prevented. However, the attack causes the writing of a file named 'echo', into the working directory, containing the result of the 'date' call. The existence of this issue resulted in the creation of CVE-2014-7169 and the release patches for several systems.

A system patched for both CVE-2014-6271 and CVE-2014-7169 will simply echo the word "date" and the file "echo" will not be created.

$ X='() { (a)=>\' bash -c "echo date"
date
$ cat echo
cat: echo: No such file or directory

CVE-2014-7186

CVE-2014-7186 relates to an out-of-bounds memory access error in the Bash parser code.^[31] While working on patching Shellshock, Red Hat researcher Florian Weimer found this bug.^[23]

Testing example

Here is an example of the vulnerability, which leverages the use of multiple "<<EOF" declarations:

bash -c 'true <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF' ||
echo "CVE-2014-7186 vulnerable, redir_stack"

A vulnerable system will echo the text "CVE-2014-7186 vulnerable, redir_stack".

CVE-2014-7187

CVE-2014-7187 relates to an off-by-one error, allowing out-of-bounds memory access, in the Bash parser code.^[32] While working on patching Shellshock, Red Hat researcher Florian Weimer found this bug.^[23]

Testing example

Here is an example of the vulnerability, which leverages the use of multiple "done" declarations:

(for x in {1..200} ; do echo "for x$x in ; do :"; done; for x in {1..200} ; do echo done ; done) | bash ||
echo "CVE-2014-7187 vulnerable, word_lineno"

A vulnerable system will echo the text "CVE-2014-7187 vulnerable, word_lineno".

Frequently Asked Questions about the Shellshock Bash flaws

Sep 26, 2014 | securityblog.redhat.com

Why are there four CVE assignments?

The original flaw in Bash was assigned CVE-2014-6271. Shortly after that issue went public a researcher found a similar flaw that wasn't blocked by the first fix and this was assigned CVE-2014-7169. Later, Red Hat Product Security researcher Florian Weimer found additional problems and they were assigned CVE-2014-7186 and CVE-2014-7187. It's possible that other issues will be found in the future and assigned a CVE designator even if they are blocked by the existing patches.

... ... ...

Why is Red Hat using a different patch then others?

Our patch addresses the CVE-2014-7169 issue in a much better way than the upstream patch, we wanted to make sure the issue was properly dealt with.
I have deployed web application filters to block CVE-2014-6271. Are these filters also effective against the subsequent flaws?

If configured properly and applied to all relevant places, the "() {" signature will work against these additional flaws.

Does SELinux help protect against this flaw?

SELinux can help reduce the impact of some of the exploits for this issue. SELinux guru Dan Walsh has written about this in depth in his blog.

Are you aware of any new ways to exploit this issue?

Within a few hours of the first issue being public (CVE-2014-6271), various exploits were seen live, they attacked the services we identified at risk in our first post:

• from dhclient,
• CGI serving web servers,
• sshd+ForceCommand configuration,
• git repositories.

We did not see any exploits which were targeted at servers which had the first issue fixed, but were affected by the second issue. We are currently not aware of any exploits which target bash packages which have both CVE patches applied.

Why wasn't this flaw noticed sooner?

The flaws in Bash were in a quite obscure feature that was rarely used; it is not surprising that this code had not been given much attention. When the first flaw was discovered it was reported responsibly to vendors who worked over a period of under 2 weeks to address the issue.

This entry was posted in Vulnerabilities and tagged bash, CVE-2014-6271, CVE-2014-6277, CVE-2014-6278, CVE-2014-7169, CVE-2014-7186, CVE-2014-7187, shellshocked by Huzaifa Sidhpurwala. Bookmark the permalink.

https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/

Update 2014-09-25 16:00 UTC

Red Hat is aware that the patch for CVE-2014-6271 is incomplete. An attacker can provide specially-crafted environment variables containing arbitrary commands that will be executed on vulnerable systems under certain conditions. The new issue has been assigned CVE-2014-7169.

We are working on patches in conjunction with the upstream developers as a critical priority. For details on a workaround, please see the knowledgebase article.

Red Hat advises customers to upgrade to the version of Bash which contains the fix for CVE-2014-6271 and not wait for the patch which fixes CVE-2014-7169. CVE-2014-7169 is a less severe issue and patches for it are being worked on.

---

Bash or the Bourne again shell, is a UNIX like shell, which is perhaps one of the most installed utilities on any Linux system. From its creation in 1980, Bash has evolved from a simple terminal based command interpreter to many other fancy uses.

In Linux, environment variables provide a way to influence the behavior of software on the system. They typically consists of a name which has a value assigned to it. The same is true of the Bash shell. It is common for a lot of programs to run Bash shell in the background. It is often used to provide a shell to a remote user (via ssh, telnet, for example), provide a parser for CGI scripts (Apache, etc) or even provide limited command execution support (git, etc)

Coming back to the topic, the vulnerability arises from the fact that you can create environment variables with specially-crafted values before calling the Bash shell. These variables can contain code, which gets executed as soon as the shell is invoked. The name of these crafted variables does not matter, only their contents. As a result, this vulnerability is exposed in many contexts, for example:

• ForceCommand is used in sshd configs to provide limited command execution capabilities for remote users. This flaw can be used to bypass that and provide arbitrary command execution. Some Git and Subversion deployments use such restricted shells. Regular use of OpenSSH is not affected because users already have shell access.
• Apache server using mod_cgi or mod_cgid are affected if CGI scripts are either written in Bash, or spawn subshells. Such subshells are implicitly used by system/popen in C, by os.system/os.popen in Python, system/exec in PHP (when run in CGI mode), and open/system in Perl if a shell is used (which depends on the command string).
• PHP scripts executed with mod_php are not affected even if they spawn subshells.
• DHCP clients invoke shell scripts to configure the system, with values taken from a potentially malicious server. This would allow arbitrary commands to be run, typically as root, on the DHCP client machine.
• Various daemons and SUID/privileged programs may execute shell scripts with environment variable values set / influenced by the user, which would allow for arbitrary commands to be run.
• Any other application which is hooked onto a shell or runs a shell script as using Bash as the interpreter. Shell scripts which do not export variables are not vulnerable to this issue, even if they process untrusted content and store it in (unexported) shell variables and open subshells.

Like "real" programming languages, Bash has functions, though in a somewhat limited implementation, and it is possible to put these Bash functions into environment variables. This flaw is triggered when extra code is added to the end of these function definitions (inside the enivronment variable). Something like:

$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
 vulnerable
 this is a test

The patch used to fix this flaw, ensures that no code is allowed after the end of a Bash function. So if you run the above example with the patched version of Bash, you should get an output similar to:

 $ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
 bash: warning: x: ignoring function definition attempt
 bash: error importing function definition for `x'
 this is a test

We believe this should not affect any backward compatibility. This would, of course, affect any scripts which try to use environment variables created in the way as described above, but doing so should be considered a bad programming practice.

Red Hat has issued security advisories that fixes this issue for Red Hat Enterprise Linux. Fedora has also shipped packages that fixes this issue.

We have additional information regarding specific Red Hat products affected by this issue that can be found at https://access.redhat.com/site/solutions/1207723

Information on CentOS can be found at http://lists.centos.org/pipermail/centos/2014-September/146099.html.

[Sep 29, 2014] Shellshock: How to protect your Unix, Linux and Mac servers By Steven J. Vaughan-Nichols

Fortunately, all the major Linux vendors quickly issued patches, including Debian, Ubuntu, Suse and Red Hat.

zdnet.com

The only thing you have to fear with Shellshock, the Unix/Linux Bash security hole, is fear itself. Yes, Shellshock can serve as a highway for worms and malware to hit your Unix, Linux, and Mac servers, but you can defend against it.

The real and present danger is for servers. According to the National Institute of Standards (NIST), Shellshock scores a perfect 10 for potential impact and exploitability. Red Hat reports that the most common attack vectors are:

• httpd (Your Web server): CGI [Common-Gateway Interface] scripts are likely affected by this issue: when a CGI script is run by the web server, it uses environment variables to pass data to the script. These environment variables can be controlled by the attacker. If the CGI script calls Bash, the script could execute arbitrary code as the httpd user. mod_php, mod_perl, and mod_python do not use environment variables and we believe they are not affected.

• Secure Shell (SSH): It is not uncommon to restrict remote commands that a user can run via SSH, such as rsync or git. In these instances, this issue can be used to execute any command, not just the restricted command.

• dhclient: The Dynamic Host Configuration Protocol Client (dhclient) is used to automatically obtain network configuration information via DHCP. This client uses various environment variables and runs Bash to configure the network interface. Connecting to a malicious DHCP server could allow an attacker to run arbitrary code on the client machine.

• CUPS (Linux, Unix and Mac OS X's print server): It is believed that CUPS is affected by this issue. Various user-supplied values are stored in environment variables when cups filters are executed.

• sudo: Commands run via sudo are not affected by this issue. Sudo specifically looks for environment variables that are also functions. It could still be possible for the running command to set an environment variable that could cause a Bash child process to execute arbitrary code.

• Firefox: We do not believe Firefox can be forced to set an environment variable in a manner that would allow Bash to run arbitrary commands. It is still advisable to upgrade Bash as it is common to install various plug-ins and extensions that could allow this behavior.

• Postfix: The Postfix [mail] server will replace various characters with a ?. While the Postfix server does call Bash in a variety of ways, we do not believe an arbitrary environment variable can be set by the server. It is however possible that a filter could set environment variables.

So much for Red Hat's thoughts. Of these, the Web servers and SSH are the ones that worry me the most. The DHCP client is also troublesome, especially if, as it the case with small businesses, your external router doubles as your Internet gateway and DHCP server.

Of these, Web server attacks seem to be the most common by far. As Florian Weimer, a Red Hat security engineer, wrote: "HTTP requests to CGI scripts have been identified as the major attack vector." Attacks are being made against systems running both Linux and Mac OS X.

Jaime Blasco, labs director at AlienVault, a security management services company, ran a honeypot looking for attackers and found "several machines trying to exploit the Bash vulnerability. The majority of them are only probing to check if systems are vulnerable. On the other hand, we found two worms that are actively exploiting the vulnerability and installing a piece of malware on the system."

Other security researchers have found that the malware is the usual sort. They typically try to plant distributed denial of service (DDoS) IRC bots and attempt to guess system logins and passwords using a list of poor passwords such as 'root', 'admin', 'user', 'login', and '123456.'

So, how do you know if your servers can be attacked? First, you need to check to see if you're running a vulnerable version of Bash. To do that, run the following command from a Bash shell:

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

If you get the result:

vulnerable this is a test

Bad news, your version of Bash can be hacked. If you see:

bash: warning: x: ignoring function definition attempt bash: error importing function definition for `x' this is a test

You're good. Well, to be more exact, you're as protected as you can be at the moment.

http://support.novell.com/security/cve/CVE-2014-6271.html

Updated information on the bash fixes.

26 Sep 2014 | support.novell.com

We have fixed the critical issue CVE-2014-6271 (http://support.novell.com/security/cve/CVE-2014-6271.html) with updates for all supported and LTSS code streams.

SLES 10 SP3 LTSS, SP4 LTSS, SLES 11 SP1 LTSS, SLES 11 SP2 LTSS, SLES 11 SP3, openSUSE 12.3, 13.1.

The issue CVE-2014-7169 ( http://support.novell.com/security/cve/CVE-2014-7169.html) is less severe (no trivial code execution) but will also receive fixes for above. As more patches are under discussions around the bash parser, we will wait some days to collect them to avoid a third bash update.

Recommended Links

Softpanorama Recommended

Top articles

Sites

• https://en.wikipedia.org/wiki/Shellshock_(software_bug)
• How to scan Linux for vulnerabilities - Linux FAQ
• Linuxaria – How to scan Linux for vulnerabilities with lynis
• Lynis
• Nessus Vulnerability Scanner
• Scan vulnerability by using Nessus Linux Blog
• FreeScan Qualys, Inc.

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March, 03, 2020