Stay Ahead With Linux Security Features
threat detection scalability Building a SIEM is easier than scaling one. Most open-source deployments start as a simple "all-in-one" server. It is easy to set up, but that design rarely survives the transition from a lab to a production workload. . A SIEM watching 20 endpoints is not doing the same job as one watching 500. More endpoints mean more logs; more logs require more storage; more storage makes search heavier. Eventually, the very architecture that made your lab easy to deploy becomes the reason your production...
Jun 04, 2026
security advisory apache A newly disclosed attack technique called HTTP/2 Bomb is drawing attention because it targets the software that sits at the front of much of the Linux internet. Apache HTTP Server, NGINX, Envoy, and the ingress layers that many Kubernetes environments depend on can be forced into consuming disproportionate amounts of memory using relatively small amounts of attacker traffic. . For Linux administrators, the concern is not the HTTP/2 protocol itself. It is the possibility that a single...
Jun 04, 2026
security advisory important The compromise of Nx Console shows how much infrastructure now sits behind a single developer account. GitHub repositories, CI/CD pipelines, container build systems, Terraform projects, Kubernetes deployments. None of those systems was the initial target. The workstation was. . Attackers did not need a Linux privilege escalation bug or a remote code execution chain. They needed developers to trust a tool they were already using. For many organizations, that was enough. What Happened? Federal...
Jun 03, 2026
security advisory open-source You remove the malware. You rotate the compromised credentials. You patch the original vulnerability and close the ticket. Two weeks later, the attacker is back. . What happened? You didn't lose the battle at the exploit; you lost it at the cleanup. In many modern Linux intrusions, the malware you found wasn't the main problem—it was the fallback mechanisms left behind. These hooks quietly restore attacker access the moment you look away. If you clean a host but miss these persistence layers,...
Jun 02, 2026
security advisory Red Hat Researchers investigating a campaign now tracked as Miasma found that more than 30 packages in Red Hat's @redhat-cloud-services npm namespace had been altered to deliver credential-stealing malware. . The packages weren't being used to deploy ransomware or sabotage systems. From what has been reported so far, the objective appears to have been much simpler: collect credentials from developer environments and use that access elsewhere. GitHub tokens, cloud credentials, SSH keys, and other...
Jun 02, 2026
Refine features
X Clear Filters
Get the latest News and Insights
Get the latest Linux and open source security news straight to your inbox.
Community Poll
What got you started with Linux?
Loading...
Explore Latest Linux Security features
We found 0 articles for you...
102
buffer overflowvulnerability assessmentsecurity analysisMemory Adjacent Attacks: Unpacking Buffer Overwrites and Exploits
In this paper we are going to describe a kind of vulnerability that is known in the literature but also poor documented. In fact, the problem that is going to be analyzed can be reduced to a memory adjacent overwriting attack but usually it is obtained exploiting the last null byte of a buffer, hence we are going to show that the same result is still possible writing behind a buffer, under certain conditions. To fully understand the subject of this article it's necessary to describe the memory organization1 of running processes, then the memory adjacent overwrite attack, concluding with our analysis. Read PDF . The link for this article located at Angelo Rosiello is no longer available. . As cybersecurity evolves, buffer overflow vulnerabilities and memory issues are becoming key focus areas, revealing deeper ties between architecture and security.. buffer attack,memory overwrite,vulnerability analysis. . Benjamin D. Thomas
Feb 24, 2006
•
102
cyber threatsmalwaresecurity analysisEmerging Malware Trends: Analyzing Tactics and Future Industry Impact
Malware has truly evolved during the last couple of years. Its potential for financial and network based abuse was quickly realized, and thus, tactics changed, consolidation between different parties occurred, and the malware scene became overly monetized, with its services available on demand. . What are the driving forces behind the rise of malware? Whoâs behind it, and what tactics do they use? How are vendors responding, and what should organizations, researchers, and end users keep in mind for the upcoming future? These and many other questions will be discussed in this article, combining security experience, business logic, a little bit of psychology, market trends, and personal chats with knowledgeable folks from the industry. Download Malware Trends PDF The link for this article located at Dancho Danchev is no longer available. . What are the driving forces behind the rise of malware? Whoâs behind it, and what tactics do they u. malware, truly, evolved, during, couple, years, potential, financial, network. . Brittany Day
Jan 10, 2006
•
102
denial of serviceroot accesskernel flaw2004 Security Overview: Kernel Flaws And User Awareness
In 2004, security continued to be a major concern. The beginning of the year was plagued with several kernel flaws and Linux vendor advisories continue to be released at an ever-increasing rate. This year, we have seen the reports touting Window's security superiority, only to be debunked by other security experts immediately after release. Also, Guardian Digital launched the new LinuxSecurity.com, users continue to be targeted by automated attacks, and the need for security awareness and education continues to rise. . Kernel Issues 2004 started off on shaky ground with a , a piece of kernel code that controls virtual memory. It affected versions 2.2, 2.4, and 2.6. It was later discovered that the same vulnerability was used to exploit several high-profile Linux development sites in November 2003. Patches were released in early January by each of the major distributions. The flaw was fixed in further kernel releases. In February, a second mremap vulnerability was discovered by the Polish security consulting firm ISec. The was unrelated, but just as serious as the first. In theory, it could result in a denial of service or privilege escalation to root. Vendors responded much more quickly in this second instance. Fixes for 2.4 and 2.6 were released only in a matter of hours this second time. In March, Paul Starzetz of ISec released proof-of-concept exploit code for the second mremap flaw that was released in February. Several news sites failed to accurately read the report released in March and reported that a third kernel flaw as found. This was wrong, but it sparked a lot . Many were relieved to find out that the "third vulnerability" was in fact a misinterpretation. It was beginning to look like the "year of the kernel flaw," but luckily things quieted down in second quarter. The remaining portion of the year was scattered with other kernel vulnerabilities, but non received as much press as mremap. Anothernotable one was discovered in 2.6 last October. It was claimed that the vulnerability could be used to shut down 2.6-based systems remotely. It only affected those systems using iptables based firewalls, because the flaw had to do with the way 2.6 handled firewall logging. Patches were released and the problem was resolved. The volume of press generated by kernel vulnerabilities is ever increasing. With the growing number of a major enterprises adopting Linux as an operational component, trade magazines are dedicating a greater percentage of their editorial scope to it. From a journalist's perspective, flaws in the kernel make great news items. It invokes fear, causing people to pay attention. While news of the mremap vulnerability may not sway the opinion of you or me, it has great potential to make a CIO reluctant to adopt that long-term Linux project all of his techs have been begging for. This year though, the Linux community has stepped up, fixed its problems, and walked away with a lot of class. Instead of headlines reading, "Is Linux Ready for the Enterprise?," journalist were writing pieces about the efficiency of open source leading to a quick resolution. Rather than criticizing Linux because of its flaws, it was praised because of its ability to work through issues. Finally, people were starting to realize that large proprietary software companies often deny that vulnerabilities exist and sneak in security patches during upgrades. Linux is about openness and full-disclosure, a great benefit to all of its users. Linux Vulnerabilities The flip-side is that full-disclosure can be very overwhelming. For example, 35 Linux vendor security advisories were released last week alone. One can easily see this by taking a few minutes to walk through our Linux security advisory archive . Roughly 35 advisories a week for an entire year is 1,820. When other proprietary operating system vendors release a much smallnumber of advisories per year, people make quick and inaccurate conclusions. For example, suppose Microsoft released 50 advisories, and Linux vendors released 2000 in a given time period. 50 is less than 2000; therefore Windows must be more secure. Of course it is flawed logic, but in previous years people believed such numbers. Often, people failed to realized that Linux advisories are released for each individual package, for each distribution, and in many cases for very minor theoretical problems. In previous years, the full picture was not taken into account. Now, the public as well as many journalist are starting to realize that severity of vulnerability is also an important factor. Rather than the discovery of a vulnerability considered another failure for Linux, it is now seen as a success by many because it is one less unknown flaw. This year particularly, I have seen a shift in the IT community's way of thinking. Rather than ignoring vulnerabilities until they're a much bigger problem, much more emphasis is being placed on proactive resolution. In my opinion this is a major step in the right direction. Conflicting Reports While the question of Linux security vs.Windows security has always been around, 2004 has been plagued with groups of analysts, independent researchers, and analyst trying to authoritatively answer that question. British based the "most breached" OS, while Linux security experts considered the findings false because the virus/worm threat was not factored into their analysis. Windows advocates claim that Windows systems are breached more because they are a much more attractive target, Linux administrators claim that Windows systems are compromised more because they're impossible to secure. It has been a year of dueling reports. One month "Linux is less secure," the next, "." In the midst of all the swirling FUD, some truth did come out. Security depends on the administrator .Although I strongly believe that Linux has the potential to be more secure, I won't claim that it always is. The security of any system depends greatly on it's administrator. Lazy operating practices lead to stupid mistakes that can be exploited. Although high-profile vulnerabilities exist, many are only theoretical, or exploit code is not widespread. A significant number of compromises are still caused by poor configuration practices, or majorly outdated software. A proactive administrator greatly reduces the likelihood of major compromise regardless of the operating system. However, an open source operating system such as Linux provides an unmatched level of flexibility that allows a willing administrator to secure a system to any level he/she desires. Major Announcements One of the more interesting announcements in 2004 was the Mozilla Foundation offering a $500 bounty to those who discover bugs in its software. As I wrote previously, proactive measures are becoming common practice, not just a vague concept in an information security professional's dreamland. Other projects such as ethereal and several other open source projects announced updates to vulnerabilities found during a code audits. I see this as great progress. Like clockwork, SANS/FBI released its Top-20 vulnerability list. Some of the most significant Unix vulnerabilities outlined include BIND, webservers, authentication, version control systems, SNMP, SSL, misconfigured services, databases, and the kernel. ( SANS/FBI Top-20 ) The projects that we've been working on at Guardian Digital are close to my heart. 2004 has been a record year in many ways. We've announced the release of two new monthly newsletters, released new versions of EnGarde Secure Professional, the Intrusion Detection and Defense System, Secure Mail Suite, proactively protected customers from Linux kernel flaws, created and announced a worldwide partner division,continued to increase our customer base, and create a program to help companies address Sarbanes Oxley compliance. In the past month, Guardian Digital's major announcement has been the launch of the new LinuxSecurity.com . We updated the site to include all the old features many have grown to depend on while adding additional ones to better serve our readership. From a completely operational perspective this includes implementing an open source content management system, upgrading servers, as well as increasing bandwidth capacity. It has been an amazing year for us at Guardian Digital. Without your support, none of this would be possible. Security Overview 2004 has been a year of increased statistics. As predicted, security attacks are on the rise, the volume of spam has increased, viruses/worms continue to increase in severity, and security continues to grow as a concern. In the corporate world, this is mostly due to Sarbanes-Oxley . Because there are now strict penalties for negligence, executive management in most corporations are starting to get the picture and call for drastic improvements in security. From a home-user's perspective security is also playing a larger role. Windows users are adopting 'personal firewalls' at an increased rate, and others are getting disgusted by a continuously hijacked browser and increasing number of spyware applications. This constant nuisance has lead many to look for alternatives, which has fueled greater interest in Linux and Firefox. Although 2004 has been an active year in security, it has not been revolutionary. From a technological perspective the year has been semi-quiet. This past year, many have focused on improving the process of security, rather than looking for a magic bullet. Again, I think this is a sign of InfoSec's growing maturity. However, in my opinion it is mostly due to the fact that most have been working on a tightly constrained budget. Whilethere have been reports suggesting several terrorist organizations have been taking a much closer look into information security, viruses continue to run rampant in the Windows world, and DDoS attacks continue to be a major problem, I have not lost all confidence in the IT industry's ability to improve overall security. In my opinion, the single most significant factor holding back progress is user education. While companies can implement security awareness and training programs, the average home user does not stand a chance. New hacks and scams are invented each day. Unless a user is proactively aware, sooner or later they will be fooled. Although phishing attacks have existed for quite some time, they have become mainstream in 2004. I'm not sure a day goes by when I don't receive at least one email asking me to 'verify my PayPal information' or 'reactivate my Ebay account.' Although I have not fallen for any of these scams, countless others have. It is just another form of social engineering that is difficult to solve (if not impossible) purely with technology. User knowledge is as important as ever. Concluding Remarks In the Linux community, security continues to be a major concern and priority. Security is now viewed as a differentiator rather than a nuisance. While distributions like EnGarde Secure Linux, Trustix, and others have taken security seriously from the beginning, others such as Red Hat and Gentoo are looking to make SELinux an integral part of its structure. Implementation of security may differ between distributions, but everyone's goal is the same. Some users prefer greater security, other prefer ease of use. It is up to you to find the distribution which best fits your needs and goals. Also, it is important to stay informed and make implementation changes whenever necessary. Security is a road to be traveled, not a destination. . In 2004, Linux faced significant kernel vulnerabilities,underscoring the necessity for heightened advisories and user education regarding potential security threats.. Kernel Flaws, Security Awareness, Vendor Advisories, User Education, Linux Risks. . Benjamin D. Thomas
Dec 23, 2004
•
102
risk managementsecurity analysissoftware securityInterview: Gary McGraw Discusses Software Security and Exploitation
Gary McGraw is perhaps best known for his groundbreaking work on securing software, having co-authored the classic Building Secure Software (Addison-Wesley, 2002). More recently, he has co-written with Greg Hoglund a companion volume, Exploiting Software , which details software security from the vantage point of the other side, the attacker. He has graciously agreed to share some of his insights with all of us at LinuxSecurity.com.. LinuxSecurity: Gary, please give our readers a brief introduction to your new book, Exploiting Software: How to Break Code (ISBN 0-201-786-95-8). Who does the book appeal to? Where can it be purchased? Gary McGraw: Traditionally, the field of computer security has been about network and operations people -- think network administrators and IT staff. The basic idea was to build a wall around your networks, protecting your vulnerable stuff (inside) from bad people (outside). The problem with this approach is twofold. First off, "perimeter security" is, at its essence, reactive. Secondly, there is no such thing as a well-defined "perimeter" anymore now that distributed systems are so widespread. The advent of Web services, mobile code, and Internet-based computing makes the notion of perimeter security seem quaint. Furthermore, the attackers have a distinct advantage, since they only need to find one flaw to exploit, while the defenders have to find and remove them all. In the end, the vulnerable stuff is software, and a lot of software is so buggy that it's almost impossible to protect. Because of all this, there has been an increasing interest in software security. That means one of the key questions to consider is, how do you harden software against attack? The only reasonable way to do this is to deeply understand just what attacks are. After all, how can you know that your company's critical software is secure, and that it has been built with security in mind, if you really know nothing about what the attacks on it are like? In thissense, Exploiting Software is useful to operations people, and to their management. By knowing how the software living on and making up their network is likely to be attacked, a good network admin is better equipped to manage risks. Only by understanding how easily buggy software can be compromised can CIOs begin to apply the kind of risk management that business demands to the software they rely on. Our book is also useful to software developers. It is vital that the people who build our systems (including Linux) learn to look at their software creations not just as a collection of features, but as potential targets for hackers and their nefarious exploits. It only makes sense for builders to get into the mind of their attackers so they know what they are really up against. For more information about buying a copy of Exploiting Software for yourself (and your entire development staff), check out www.exploitingsoftware.com. The publisher, Addison-Wesley Professional, also has a website too. LS: Can you offer a brief description of your background and that of your co-author, Greg Hoglund? How did you two meet or decide to co-write a book? How long have you been in the software security field? How would you say this collaboration has enriched the book? GM: First, I'll answer for myself. I am a scientist at heart, and I've been playing with computers ever since I got an Apple II+ in 1981. I studied the lucrative field of Philosophy at the University of Virginia and, inspired by the Pulitzer Prize winning book by Douglas Hofstadter Godel Escher Bach , I ended up earning a dual PhD in Computer Science and Cognitive Science from Indiana University (where Doug was my thesis advisor). Around 1985, I got interested in the 'Net. In 1993 we put up one of the first 400 nodes on the Web (Yahoo was a complete list of all websites back then). In 1995, Java came out, and being a programming languages and Web junkie, I downloaded it. Investigating itsinteresting claims of being a "secure" computing platform led to my first book, Java Security , written with Ed Felten of Princeton. After that, the need for some good work in software security became obvious. In 2001 I wrote the first book in the world on software security, called Building Secure Software with John Viega. Greg Hoglund started out as a black hat. In contrast to my academic background, he was completely self taught, and has the innate ability to think like a hacker. In fact, he wrote the first rootkit for Windows NT, and started in the process. We became friends some years ago and he agreed to co-write this book just after the publication of Building Secure Software . The idea was to look at a large corpus of attacks and exploits and see if we could discern any patterns in these attacks. Greg's expertise was absolutely critical to this undertaking, and his thinking pervades the technical aspects of the book. LS: You have previously written a book called Building Secure Software , which covered the design and implementation of secure code for the software developer. Can you explain why we might also a primer for black hats, such as Exploiting Software ? GM: Actually, Greg and I call Exploiting Software the black hat book (in contrast to BSS which is the white hat book)! Together, the two books make up the "black and white series." The reason we saw the need for the black hat book is that we strongly believe that you simply cannot build a defensible, secure system without knowing how people will attack it. The bad guys already understand software. In fact, they are software people. They know how to write code, they know what bugs to look for, and they know how to exploit them. They can hold a security patch up against a broken piece of software and use it as a roadmap for writing a new exploit. Unfortunately, on the other side of the divide, most security operations people do not understand software. They are excellent firewalland router admins, but they don't code. That's a problem. LS: What are some of the most major pitfalls that software designers fall into? Can your book help to avoid these problems? GM: In the book, we provide a set of 49 attack patterns. Attack patterns are directly related to pitfalls and problems that we see in real production software today. One of the points I like to emphasize is the difference between bugs and flaws in software. Bugs are simple mistakes in code leading to problems like buffer overflows; flaws are mistakes in design. It turns out that a lot of software is flawed. In fact, if you step back and look at a multitude of security problems over time, you'll find that about 50% of them are due to bugs and 50% due to flaws. There are too many common design failures to list exhaustively here. But here are a couple of examples... Object Oriented programming is the latest, greatest widespread coding paradigm, and it can indeed be very useful. But the distributed code model has a cost: each class (and possibly every method) is expected to do its own error handling, meaning that there is not necessarily an inherently centralized error handling mechanism. This means that it becomes difficult to determine exactly what will happen at various points of failure. Keeping track of precisely what is going on in the software as it throws exceptions willy nilly is difficult at best. Error handling is complex, and complexity is a great friend to attackers. Without some ability to manage errors in a consistent system wide fashion, it becomes nearly impossible to be sure that nothing intentionally bad could be made to happen. Then there is the more general concern that software designers tend to be a very feature-oriented crowd. They build things, and things have features. So they naturally default to thinking about security as a set of features (think SSL or access control). The problem is that security is an emergent property of a complete system. Related to this "featurism," is a related problem involving trust. Developers tend to have too much trust to their users, and do not treat user input with due suspicion. They think, "users want to access these features," instead of "attackers might abuse my system in surprising ways." These are just a few high level issues that can render software insecure. There are many, many more where these came from. LS: What practical steps can be taken out of the book, from a security analyst or administrator's point of view, to further secure their systems given that their software may be riddled with flaws? Anything beyond keeping up with their vendor's patches? GM: I hope to convince operations people to intuitively distrust software. They should be equally skeptical of the claims of security software vendors to solve all of their problem with a magic whatzit (like magic crypto fairy dust). Any security person can learn to become aware of programming languages that software is written in, and think through the security implications there. If you want secure software, you cannot just rely on (spurious) claims about security. For example, in order to 'prove' that the software is secure, a security vendor might tout their EAL level. But the Common Criterion is not a fail proof approach. In fact, it is really a "least common denominator" approach to security; because ultimately all it requires is that the vendors demonstrate specific claims that they themselves make about security, such as how well the code was protected while it was being written. But this may have no relationship to real security! That is, some of the vendor claims may not be meaningful to the consumer; and there is really no way to show that any set of claims put together somehow collectively equal "secure software" for all possible situations. This is particularly confusing for the market and its constituent consumers, because the market may not be versed in the subtleties of why various claimsmay not add up to something secure enough. It is at this point that we can circle back to the point of the book---flawed software, and how it is actually exploited. Consider that it can be quite difficult to make code secure when you insist on writing it in C. Only those who need very low level functionality should use a low-level language like C, which provides too much rope for a majority of programmers. Perhaps there should be some sort of a license for writing C! In the end, an administrator or security person should understand that programs written in C are much more likely to be insecure than those written in a modern type safe language like Java or C#. The CIO and/or top operations people can keep this in mind when they decide what software to deploy to solve a particular problem. One way for administrators to deal with software they cannot completely trust is to be very careful to not give software excessive privileges. The manner in which software is installed can make all the difference in the world from a security perspective. In fact, a bad deployment can ruin otherwise pretty darn good software! LS: How difficult is it to get started? How long would it take for today's regular non-security-focused developer or administrator to use these techniques to begin to test and improve the security of the software for which they are responsible? GM: Getting started on software security can be as quick and painless as reading some of the now available books and articles. But getting things going on a really secure footing can be a large undertaking if your organization is big. Consultants like Cigital can sometimes help with this. Of course, even without achieving excellence in software security, there is plenty of value to be found in taking the first steps, such as simply regarding software with the proper dose of suspicion and keeping privileges to the minimum necessary. LS: Your book contains an entire chapter on disassembling andreverse engineering. What is your opinion of security by obscurity? Are open systems less secure because the code is freely available, without having to be disassembled? GM: Firstly, I should say that security by obscurity simply doesn't work, with one exception. That exception is that if you carefully design a new piece of software, have it tested very carefully for security and have it extensively vetted by software security experts, and then don't publish the design, then it does work to make the software harder to exploit. So, security by obscurity only helps if the software is already rock solid. On the other hand, the "open source is more secure" debate is a red herring. All the big software houses, think Microsoft, pay entire armies of people to look at the code. In fact, the economics of the situation are on the side of the closed source guys. Analyzing code for exploitable bugs is a hard job best left to professionals who like to be paid for their work. Because they have deep pockets and can pay people to work hard on software security, Microsoft has greatly improved the security of its code in recent years. Crispin Cowan tried to set up a community-based economy for security analysis of open source called Sardonix. Unfortunately, it didn't work; mostly because there are not enough really qualified people who are interested in doing security analysis for free or for brownie points. In the end it is ridiculous to say that "all bugs are shallow." That's only true for the easy bugs. Some bugs are subtle and simply not easy to detect, even by hordes of people. A related problem...at its core, open source tends to be grown organically. Open source people are feature-oriented, and as we have already discussed, security is not a feature. However, I would like to add that open source has improved from a security perspective, probably just as much as closed source. Partially because of guys like Crispin Cowan and increased scrutiny due to recentattacks. I believe that this improvement was mostly due to the efforts of companies like IBM, and, to a lesser extent, SuSE and Red Hat rather than by some non-economic, non-subsidized means. LS: Your book mentions that black box case testing software that is touted as the final solution for software security is really no panacea. Can you expand upon this point? GM: Black box application testing solutions are not worth much money! Rudimentary dynamic testing that runs 100 canned tests and declares victory is really rather silly. How can you know if the inputs you ended up testing (especially with canned tests) are the ones that would uncover defects? It's true that this sort of testing can help determine "badness." That is if a black-box test suite finds problems, you are in very big trouble indeed. But if all tests are successfully passed, that says little about your real security posture. Don't forget that the basic problem of software security is usually at least as much one of design as of implementation. Black box tests cannot find design flaws (unless they get lucky). A much more useful idea is that of code scanning, looking at source code for potential vulnerabilities. A number of open source scanners can be found (ITS4 and flawfinder to name two), but you have to make sure you understand what the scanner is scanning for in the code. Ask yourself, are you sure that the scanning rules are right? What will they catch, and what might they miss? If you understand what they are looking for and why, code scanning can be very useful. LS: One of the chapters of your book is about the infamous buffer overflow problem. Can you briefly explain to our readers what exactly a buffer overflow is, and why it has become such an issue? GM: Buffer overflows occur because of bad language design (think C) and sloppy code. The best solution is for more software to be written with better languages, like Java and C#, instead of C or C++. Essentially,a buffer overflow happens when information is written over parts of memory that were not intended to hold that information. Think about pouring too much beer in a glass. By overwriting the parts of the memory that hold critical information such as return addresses, an attacker can get an attack payload to execute, with whatever privileges the executing program may have. We explain this in great detail in the book. Direct memory manipulation comes down to us from the days when memory was exceptionally expensive and precious, and had to be used with extreme frugality. But nowadays, there is memory to waste, and programs grab huge swaths of it and rarely release it, treating it as a raw sea of bits. Handling memory properly is something that is beyond the current understanding of many programmers, and the issue is made worse by the use of common, powerful system calls whose security implications may not be well understood by those people using them. LS: In your book, you emphasize the importance of risk analysis to overall software security. Can you please explain this concept to our readers? Why should we not aim for perfectly secure software? GM: We can't just stop using software because its not absolutely provably secure. The only way to make your computer really secure is simply to turn it off. Whenever we add functionality (or turn the machine on), we open the door to security issues. You just have to ask yourself if the functionality you want to utilize is worth the risk you take on. In many cases, the answer will be that it is, but it is critical to realize the basic fundamental nature of this tradeoff. Software security is about minimizing the risk inherent in the additional functionality that software supplies. That's why it is a risk management game. LS: What concrete improvements would you like to see in the field of software design in the future? GM: Less is more in security. Turn off unnecessary functionality and services. Thefeature-oriented set tend to think more is better, but more is less secure. Bloatware is bad. I always ask developers: who plans on having less code at the end of the year as the beginning? Very few of them say they do! Less stuff would be better. Complexity, network-based design, and extensibility (involving mobile code that does stuff on the fly and arrives arbitrarily) are the friends of the attacker. I call these the Trinity of Trouble (also covered in Exploiting Software ). When the Internet toaster is finally available, it will give an attacker the chance to burn your breakfast! LS: What are your future plans? Do you plan on writing any other books/articles? GM: When I write a book, I get to a point where I am absolutely sick of writing, and I say to myself "I'll never write another book again!" And then later, I forget the pain and do it again. I'm still somewhat in the sick of writing phase, but I'm sure I'll soon forget.. Uncover valuable perspectives on application security through our unique dialogue with Gary McGraw regarding vulnerabilities in software.. Software Security, Attack Techniques, Risk Assessment, Code Vulnerabilities, Security Practices. . Brittany Day
Jul 30, 2004
•
102
intrusion detectionincident responsenetwork attackLinux Honeynet Incident Responses: Analyzing Attacks and Observations
Among other benefits, running a honeynet makes one acutely aware about "what is going on" out there. While placing a network IDS outside one's firewall might also provide a similar flood of alerts, a honeypot provides a unique prospective on what will be going on when a related server is compromised used by the intruders. . As a result of our research, many gigabytes of network traffic dumps are piling up on the hard drives, databases are filling with alerts, rootkits and exploit-pack collections are growing. This paper is an attempt to informally summarize what was happening to our exposed Linux machine connected to the Internet. The moment is even more appropriate since we are now changing the platform of the victim machine.. Our Linux honeypot survived dozens, if not more, system compromises including several massive outbound denial-of-service attacks (all blocked by the firewall!), major system vulnerability scanning and serving as an Internet Relay Chat (IRC) server for Romanian hackers - and other exciting stuff. I. Battleground: services and ports First, let us summarize the common exploits hurled at the exposed Linux machine. It won't likely be news to people who monitor activity outside their firewalls, but it may provide some insight into current security threats to others. Scans, "innocuous" connection attempts and various spam (on port TCP 25 and UDP 13x) are not included. a. RPC statd - the attack is SO ancient, that one might think that nobody will hope to find a vulnerable box with that flaw. After all, who in his right mind will be fielding (for example) Linux Red Hat 6.0 when half a dozen Red Hat releases have come out since that time. We are talking August 2000 - it was indeed during the last millennium. Heavy scanning for this vulnerability was going on all through 2001 and even parts of 2002. One might think that all machines with that hole are either secured by the owners or by the intruders, upgraded or taken offline. However, lots of "hopefuls" are still trying the longcemented "door". Thus, the log files continue to be peppered with the classic: Mar 4 11:51:31 victim 29> Mar 4 11:51:31 rpc.statd[493]: gethostbyname error for ^X...^X...^Z...^Z...%8x%8x%8x%8x% 8x%8x%8x%8x%8x%62716x%hn%51859x%hn................................................ .................................................................................. .................................................................................. .................................................................................. .................................................................................. .................................................................................. .................................................................................. ....................../1..|Y.A^P.A^H...A^D.....^A.f...^B.Y^L.A^N..A^H^P.I^D.A^D^L. ^A.f...^D.f...^E0..A^D.f......1..?.. and snort continue spewing forth the good old: Jan 24 20:46:41 bastion snort: [1:1282:1] RPC EXPLOIT statdx [Classification: Attempted Administrator Privilege Gain] [Priority: 1]: {UDP} 10.0.0.10:931 -> 1.2.3.4:1024 And here is how this attack looks to the anomaly-based Bro NIDS, recently deployed in our honeynet: 1047644757.152094 10.0.0.10/939 > 1.2.3.4/portmap: bad_RPC_program 1047644757.152094 10.0.0.10/939 > 1.2.3.4/portmap: bad_RPC Bro detects a different stage of the same attack. b. WU-FTPD - this attack can also be categorized as "Stone Agey", but it is still very popular among the amateur attackers. It is this attack that led to those impressive statistics publicized by the Project Honeynet - default Red Hat box will be "owned" within 3 days from being connected to the internet. An extremely popular choice, this attack is used in countless autorooters, exploit scanners and other "tools for beginners". Here is how the attack looks to snort: Jan 26 20:37:16 bastion snort: [1:1378:7] FTP wu-ftp file completionattempt { [Classification: Misc Attack] [Priority: 2]: {TCP} 10.0.0.10:33761 -> 1.2.3.4:21 Jan 26 20:37:16 bastion snort: [1:1622:5] FTP RNFR ././ attempt [Classification: Misc Attack] [Priority: 2]: {TCP} 10.0.0.10:33761 -> 1.2.3.4:21 and to Bro: 1048402337.496125 FTP_ExcessiveFilename 10.0.0.10/1641 > 1.2.3.4/ftp #94 excessive filename: 00000000000000000000000000000000..[494].. c. IIS exploits - we have observed dozens of different Unicode strings and .ida requests aimed to hurt the Microsoft IIS web server. Starting from the classic one used by the worms in 2001 to the more obscure modern variant: Here is the excerpt of the HTTP protocol decode by Bro: /scripts/..%2f../winnt/system32/cmd.exe?/c+dir /scripts/..%35c../winnt/system32/cmd.exe?/c+dir /scripts/..%5c%5c../winnt/system32/cmd.exe?/c+dir /scripts/..%5c../winnt/system32/cmd.exe?/c+dir /scripts/root.exe?/c+dir /scripts/..\xc0/../winnt/system32/cmd.exe?/c+dir /scripts/..\xc0\xaf../winnt/system32/cmd.exe?/c+dir /scripts/..\xc1\x1c../winnt/system32/cmd.exe?/c+dir /scripts/..\xc1\x9c../winnt/system32/cmd.exe?/c+dir /_mem_bin/..%5c../..%5c../..%5c../winnt/system32/cmd.exe?/c+dir /msadc/..%5c../..%5c../..%5c/..\xc1\x1c../..\xc1\x1c../..\xc1\x1c. ./winnt/system32/cmd.exe?/c+dir /MSADC/root.exe?/c+dir /_vti_bin/..%5c../..%5c../..%5c../winnt/system32/cmd.exe?/c+dir /default.ida?XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX%u9090%u6858%uc bd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090 %u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u0000%u00=a It is obvious that those cannot affect the Linux Apache web server of the honeypot and are provided here only due to their extreme volume. It is interesting to note that some IP addresses receive much more than their share of such hits. This phenomenon is notexplained yet. d. OpenSSL flaw that allows the non-root access is a very popular choice as of today. While not giving root, it seemingly helps the script kiddies to learn about local exploits. It is suspected that its popularity is in part due to readily available and reliable exploit openssl-too-open (...) Here is the log trace of the openssl hit in Apache errror_log: [Mon Mar 3 06:40:48 2003] [error] mod_ssl: SSL handshake failed (server ns1.bkwconsulting.com:443, client 10.0.0.10) (OpenSSL library error follows) [Mon Mar 3 06:40:48 2003] [error] OpenSSL: error:1406908F:lib(20):func(105):reason(143) And here is the snort message: Feb 2 00:45:53 bastion snort: [1:1887:1] EXPERIMENTAL WEB-MISC OpenSSL Worm traffic [Classification: Web Application Attack] [Priority: 1]: {TCP} 10.0.0.10:2328 -> 1.2.3.4:443 e. MS-SQL Slammer, while being called a flash worm, is still knocking on the UDP 1434. The volume has subsided as most of the affected hosts are taken offline, butol Slammer is till there, slamming away at closed ports of the Linux honeypot. Here is what snort says upon seeing it: Mar 10 22:01:11 bastion snort: [1:2003:2] MS-SQL Worm propagation attempt [Classification: Misc Attack] [Priority: 2]: {UDP} 10.0.0.10:1140 -> 1.2.3.4:1434 f. Here are some other less frequent attacks that flash by. A number of hits against vulnerable PHP were observed. The attack did not succeed and was seen only once or twice: Mar 10 14:57:15 bastion snort: [1:1425:6] WEB-PHP content-disposition [Classification: Web Application Attack] [Priority: 1]: {TCP} 10.0.0.10:57774 -> 1.2.3.4:80 Mar 10 14:57:15 bastion snort: [1:1423:7] WEB-PHP content-disposition memchr overlfow [Classification: Web Application Attack] [Priority: 1]: {TCP} 10.0.0.10:57777 -> 1.2.3.4:80 g. What is not there? Old bind attacks (very popular in 1999) are gone, hopefully for good, and new ones (based on the recent Bind bigs) failed tomaterialize. SSH bugs are not actively exploited, while version surveying is observed pretty often. It is not clear why this is the case. Here is a summary of all events and attacks: The color indicates alarm severity. It resembles what is reported by DShield.org. Web attacks (80,443) "top the charts", and are followed by the recent MS-SQL hits (1434) and FTP (21) - the all time favorite. Proxy scans (1080, 3128,8080) are also very popular. Strangely, SNMP (161,162) is also in the picture, though appear to be just probes and not exploit attempts. II. Artifacts - exploits, rootkits and tools Intruders who visit our friendly neighborhood honeynet, rarely come empty-handed. They bring all sorts of gifts, such as exploit scanners, autorooters, rootkits, DoS tools and other goodies. Most of the captured kits are very simple, use only publicly available technology and carry all the signs of being created by unskilled people. They often corrupt the system and utilize such amazingly "stealthy" capabilities as using the root directory of the system to store their files or changing the root password ("owned means owned, right?") Exploits and automated exploitation tools, while seeming impressive, use very old attacks (such as those described above) and are not even attempting to hide their activities. Most of those tools are designed to scan huge pools of IP addresses for one or two vulnerabilities, manifesting the ultimate "opportunity hack" of going for the "low-hanging fruit". However, new and innovative tools do get brought in by the tide. For example, the covert channeling binary or the IPv6 tunnel tool were discovered by the Honeynet Project. III. Example Incidents Here are brief descriptions of several incidents that recently occurred in our honeynet. The classic WU-FTPD incident starts from an anonymous login to the FTP server. Then in a few minutes or hours the server is hit by the TESO "wurm" exploit. It has a recognizable signature of trying to create a directory 7350 (TESO). In a fewseconds, intruder tries to get his rootkit from a drop site (often some free storage site or even a Yahoo account) which is then deployed. Most observed rootkits start a ssh daemon on high port as a main backdoor method. On the next session (which occurs within hours or even days), we often see him getting scanners and trying to exploit more machines. The more recent openssl incidents are more interesting since the attacker does not have root upon breaking into the system (such as, user "apache"). One might think that owning a system with no "root" access is useless, but we usually see active system use in these cases. Here are some of the things that such non-root attackers do on such compromised systems: 1."IRC till you drop" Installing an IRC bot or bouncer is a popular choice of such attackers. Several IRC channels dedicated entirely for communication of the servers compromised by a particular group were observed on several occasions. Running an IRC bot does not require additional privileges. 2."Local exploit bonanza" Throwing everything they have at the Holy Grail of root access seems common as well. Often, the attacker will try half a dozen different exploits trying to elevate his privileges from mere "apache" to "root". 3. "Evil daemon" A secure shell daemon can be launched by a non-root user on a high numbered port. This was observed in several cases. In some of these cases, the intruder accepted the fact that he will not have root. He then started to make his new home on the net more comfortable by adding a backdoor and some other tools in "hidden" (".. " and other non printable names are common) directories in /tmp or /var/tmp. 4. "Flood, flood, flood" While spoofed DoS is more stealthy and harder to trace, many of the classic DoS attacks do not require root access. For example, ping floods and UDP floods can be initiated by non-root users. This capability is sometimes abused by the intruders, using the fact that even when the attack is traced the only found source would be acompromised machine with no logs present. 5. "More boxes!" Similar to a root-owning intruder, those with non-root shells may use the compromised system for vulnerability scanning and widespread exploitation. Many of the scanners, such as openssl autorooter, recently discovered by us, do not need root to operate, but is still capable of discovering and exploiting a massive (thousands and more) system within a short time period. Such large networks can be used for devastating denial of service attacks (for example, such as recently warned by CERT). Worms and other automated entities are also common. We observed many different OpenSSL worms (for their taxonomy, see this), including some with novel components such as Windows OpenSSL exploit, DoS agents, IRC bot deployment by the worm, automated local exploitation via ptrace bug, different backdoors, etc. Windows worms are also on the prowl. CodeReds, MS SQL and others are not gone. Their traces surface in the logs on the regular basis. They seem to be leading their own lives with ups and downs, sudden bursts of activity, and never seem to go away. Many other "fun things" are also hitting the shores of our honeynet. Among them are such beasts as the packets from 255.255.255.255, port 31337, various kinds of spam (email, MS RPC, web forms), a lot of various reconnaissance attempts (mostly scans and pings). Scans for proxies (1080,8080, 3128) are also extremely popular, as mentioned above. Anton Chuvakin, Ph.D., GCIA, GCIH is a Senior Security Analyst with netForensics, a security information management software company that provides real-time network security management solutions. His areas of infosec expertise include intrusion detection, UNIX security, forensics, honeypots, etc. In his spare time he maintains his security portal Anton Chuvakin, Ph.D., GCIA, GCIH, GCFA Information Security Publications. . Investigations have uncovered terabytes of data packets showcasing multiple events and intrusions within our Unix honeypot.. Honeynet Research, AttackObservations, Incident Responses, Intrusion Detection, Security Threats. . Brittany Day
Apr 22, 2003
•
Get the latest News and Insights
Get the latest Linux and open source security news straight to your inbox.
Community Poll
What got you started with Linux?
Search Topics
Powered By
Linux Security - Your source for Top Linux News, Advisories, HOWTOs and Feature Releases
QUICK LINKS
subscribe to newsletters!
Like staying secure? So do we.
Sign up for updates, tips, and alerts!
Discover faster search, smarter navigation, and deeper Linux security insights. Read More