Wireshark for Security Professionals PDF

Table of Contents Cover Title Page Introduction Overview of the Book and Technology How This Book Is Organized Who Should Read This Book Tools You Will Need What’s on the Website Summary Chapter 1: Introducing Wireshark What Is Wireshark? The Wireshark User Interface Filters Summary Exercises Chapter 2: Setting Up the Lab Kali Linux Virtualization VirtualBox The W4SP Lab Summary Exercises Chapter 3: The Fundamentals Networking Security Packet and Protocol Analysis Summary Exercises Chapter 4: Capturing Packets Sniffing Dealing with the Network Loading and Saving Capture Files Dissectors Viewing Someone Else’s Captures Summary Exercises Chapter 5: Diagnosing Attacks Attack Type: Man-in-the-Middle Attack Type: Denial of Service Attack Type: Advanced Persistent Threat Summary Exercises Chapter 6: Offensive Wireshark Attack Methodology Reconnaissance Using Wireshark Evading IPS/IDS Exploitation Remote Capture over SSH Summary Exercises Chapter 7: Decrypting TLS, Capturing USB, Keyloggers, and Network Graphing Decrypting SSL/TLS USB and Wireshark Graphing the Network Summary Exercises Chapter 8: Scripting with Lua Why Lua? Scripting Basics Setup Tools Creating Dissectors for Wireshark Extending Wireshark Summary End User License Agreement List of Illustrations Chapter 1: Introducing Wireshark Figure 1-1: The Wireshark home screen Figure 1-2: The Packet List pane Figure 1-3: The Packet Details pane Figure 1-4: Field information in the status bar Figure 1-5: ARP packet Opcode Figure 1-6: Filter results of ARP from a source address Figure 1-7: Complex display filter example Chapter 2: Setting Up the Lab Figure 2-1: Getting SHA-256 file hash in PowerShell Figure 2-2: VirtualBox SHA-256 checksums Figure 2-3: VirtualBox installation window Figure 2-4: VirtualBox feature selection Figure 2-5: VirtualBox shortcut creation Figure 2-6: VirtualBox networking warning Figure 2-7: VirtualBox installation window Figure 2-8: VirtualBox installation status Figure 2-9: VirtualBox driver installation prompt Figure 2-10: VirtualBox installation finished Figure 2-11: VirtualBox GUI and restart window Figure 2-12: VirtualBox Extension Pack download Figure 2-13: VirtualBox Extension Pack preferences Figure 2-14: VirtualBox Extension Pack installation Figure 2-15: Successful VirtualBox Extension Pack installation Figure 2-16: Kali download web page Figure 2-17: Creating a new virtual machine Figure 2-18: Selecting virtual machine memory Figure 2-19: Creating virtual disk Figure 2-20: Selecting virtual disk type Figure 2-21: Storage on physical disk Figure 2-22: Virtual disk size Figure 2-23: Enabling PAE Figure 2-24: Selecting start-up disk Figure 2-25: Kali boot menu Figure 2-26: Possible temporary error Figure 2-27: Entering a hostname Figure 2-28: Skipping the domain Figure 2-29: Entering a root password Figure 2-30: Partitioning the disk Figure 2-31: Confirming the disk Figure 2-32: Confirming a single partition Figure 2-33: Writing changes to the disk Figure 2-34: Confirming disk changes Figure 2-35: The installation progress bar Figure 2-36: The option for a network mirror Figure 2-37: Network connection proxy Figure 2-38: GRUB boot loader Figure 2-39: Installation is complete Figure 2-40: System settings Figure 2-41: New user w4sp-lab Figure 2-42: Firefox to GitHub Figure 2-43: Saving the W4SP Lab file Figure 2-44: Opening Terminal Figure 2-45: Unzipping the W4SP Lab Figure 2-46: Running the W4SP Lab installation script Figure 2-47: Running the W4SP Lab setup Figure 2-48: The full W4SP Lab network Chapter 3: The Fundamentals Figure 3-1: OSI layers in Wireshark Figure 3-2: VirtualBox networking options Figure 3-3: Malware signature code Figure 3-4: Small Incoming Layer 2 frame Figure 3-5: Smaller outgoing Layer 2 frame Figure 3-6: Gratuitous ARP Figure 3-7: TCP’s 3-way handshake Chapter 4: Capturing Packets Figure 4-1: The Capture interfaces list Figure 4-2: Superuser warning Figure 4-3: New traffic Figure 4-4: Renaming a network interface Figure 4-5: Sample localhost ICMP traffic Figure 4-6: Installing the loopback adapter on Windows Figure 4-7: RawCap loopback sniffing Figure 4-8: RawCap pcap in Wireshark Figure 4-9: VirtualBox bridging Figure 4-10: Wireshark sniffing bridged network Figure 4-11: Capturing packets with a hub Figure 4-12: Traffic when sniffing on a hub Figure 4-13: SPAN sniffing connections Figure 4-14: Throwing star LAN tap Figure 4-15: Traffic flow when sniffing a Linux bridge Figure 4-16: Raw wireless packets in Wireshark Figure 4-17: The File Save dialog box Figure 4-18: Properties of a capture file Figure 4-19: Multiple file settings Figure 4-20: Stop capture options Figure 4-21: Setting multiple files and ring buffer Figure 4-22: Resultant ring buffer files Figure 4-23: Mergecap verbose Figure 4-24: Mergecap complete Figure 4-25: Clearing recent files Figure 4-26: Changing the number of recent files shown Figure 4-27: Wireshark’s Decode As window Figure 4-28: Wireshark’s Decode As window Figure 4-29: Packet list filtering for SMB Figure 4-30: SMB packets referencing a file Figure 4-31: Packet list filtered for NT Create calls Figure 4-32: Adjusting packet colors Figure 4-33: Colorizing conversations Chapter 5: Diagnosing Attacks Figure 5-1: Man-in-the-middle position Figure 5-2: Ping and ARP transaction Figure 5-3: W4SP Lab network Figure 5-4: W4SP’s vic1 Figure 5-5: LOCALSIP Figure 5-6: Exploit in progress Figure 5-7: ARP packets fly Figure 5-8: FTP credentials to attacker Figure 5-9: Expert information Figure 5-10: Noting your IP address Figure 5-11: DHCP module options Figure 5-12: DHCP running Figure 5-13: DNS settings done Figure 5-14: DNS queries Figure 5-15: Quieter fake DNS Figure 5-16: FTP capturing Figure 5-17: Mirai password list Figure 5-18: Pingbed Figure 5-19: Gh0st Figure 5-20: Xinmic Figure 5-21: Malware analysis practice Chapter 6: Offensive Wireshark Figure 6-1: W4SP Lab network Figure 6-2: Nmap port scan Figure 6-3: Nmap port scan in Wireshark Figure 6-4: Open port in Wireshark Figure 6-5: Metasploitable and its IP Figure 6-6: Searching for the VSFTPD exploit Figure 6-7: Exploit success but no shell Figure 6-8: Exploit attempt in Wireshark Figure 6-9: Exploit success with shell Figure 6-10: Root shell command WHOAMI Figure 6-11: Root in packet bytes Figure 6-12: Metasploit RMI data Figure 6-13: Metasploit HTTP JAR data Figure 6-14: Metasploit hex dump Figure 6-15: Unanswered SYNs Figure 6-16: Filter for tcp/4444 Figure 6-17: Encrypted traffic Figure 6-18: ELK Figure 6-19: Time-field name Figure 6-20: SSHdump install Chapter 7: Decrypting TLS, Capturing USB, Keyloggers, and Network Graphing Figure 7-1: Browsing to ftp1.labs Figure 7-2: Follow TCP stream on SSL/TLS traffic Figure 7-3: Wireshark SSL/TLS protocol options Figure 7-4: Setting up SSL/TLS decryption Figure 7-5: Decrypting TLS traffic in Wireshark Figure 7-6: Adding SSLKEYLOGFILE Figure 7-7: Decrypted SSL/TLS data Figure 7-8: USB device overview Figure 7-9: usbmon interfaces Figure 7-10: Connecting USB device to Kali VM Figure 7-11: Wireshark usbmon error Figure 7-12: Capturing on usbmon2 Figure 7-13: USBPcap device list Figure 7-14: USBPcap running a capture Figure 7-15: Filtering USB traffic to host Figure 7-16: HID key codes Figure 7-17: TShark key sniffer Figure 7-18: TShark-generated network graph Chapter 8: Scripting with Lua Figure 8-1: Lua Interactive Interpreter Figure 8-2: Wireshark About page Figure 8-3: Lua in Tools menu Figure 8-4: Lua Console in Wireshark Figure 8-5: Wireshark Evaluate Lua Figure 8-6: Wireshark without a dissector Figure 8-7: Our protocol fields Figure 8-8: Sample protocol hexdump Figure 8-9: Tree items in Wireshark Figure 8-10: Running direction script Figure 8-11: Finding a suspicious packet List of Tables Chapter 1: Introducing Wireshark Table 1-1: Comparison Operators Table 1-2: Logical Operators Chapter 4: Capturing Packets Table 4-1: Common Wireshark Capture File Formats Chapter 5: Diagnosing Attacks Table 5-1: Exploit Options Table 5-2: Well-Known DoS Tools Wireshark® for Security Professionals Using Wireshark and the Metasploit® Framework Jessey Bullock Jeff T. Parker Introduction Welcome to Wireshark for Security Professionals. This was an exciting book for us to write. A combined effort of a few people with varied backgrounds—spanning information security, software development, and online virtual lab development and teaching—this book should appeal and relate to many people. Wireshark is the tool for capturing and analyzing network traffic. Originally named Ethereal but changed in 2006, Wireshark is well established and respected among your peers. But you already knew that, or why would you invest your time and money in this book? What you’re really here for is to delve into how Wireshark makes your job easier and your skills more effective. Overview of the Book and Technology This book hopes to meet three goals: Broaden the information security professional’s skillset through Wireshark. Provide learning resources, including labs and exercises, to apply what you learn. Demonstrate how Wireshark helps with real-life scenarios through Lua scripting. The book isn’t only for reading; it’s for doing. Any Wireshark book can show how wonderful Wireshark can be, but this book also gives you opportunities to practice the craft, hone your skills, and master the features Wireshark offers. These opportunities come in a few forms. First, to apply what’s in the text, you will practice in labs. You build the lab environment early on the book and put it to use throughout the chapters that follow. The second opportunity for practice is at the end of each chapter, save the last Lua scripting chapter. The end-of-chapter exercises largely build on the labs to challenge you again, but with far less hand- holding. Between the labs and exercises, your time spent with Wireshark ensures time spent reading is not forgotten. The lab environment was created using containerization technology, resulting in a fairly lightweight virtual environment to be installed and run on your own system. The whole environment was designed specifically for you, the book reader, to practice the book’s content. These labs were developed and are maintained by one of the authors, Jessey Bullock. The source code for the labs is available online. See Chapter 2 for specifics. In short, this book is a hands-on, practice-oriented Wireshark guide created for you, the information security professional. The exercises will help you to keep you advancing your Wireshark expertise long after the last page. How This Book Is Organized The book is structured on the assumption that readers will start from the beginning and then work through the main content. The initial three chapters not only introduce the title application Wireshark but also the technology to be used for the labs, along with the basic concepts required of the reader. Readers already familiar with Wireshark should still work through the lab setup chapter, since future chapters depend on the work being done. These first three chapters are necessary to cover first, before putting the following chapters to use. The majority of the book that follows is structured to discuss Wireshark in the context of information security. Whether capturing, analyzing, or confirming attacks, the book’s main content and its labs are designed to most benefit information security professionals. The final chapter is built around the scripting language Lua. Lua greatly increases Wireshark’s flexability as an already powerful network analyzer. Initially, the Lua scripts were scattered thoughout chapters, but they were later combined into a single chapter all their own. It was also appreciated that not all readers are coders, so Lua scripts are better served through one go-to resource. Here’s a summary of the book’s contents: Chapter 1, “Introducing Wireshark,” is best for the professional with little to no experience with Wireshark. The main goal is to help you avoid being overwhelmed, introduce the interface, and show how Wireshark can be your friend. Chapter 2, “Setting Up the Lab,” is not to be skipped. Starting with setting up a virtualized machine, this chapter then sets up the W4SP Lab, which you will use several times in upcoming chapters. Chapter 3, “The Fundamentals,” covers basic concepts and is divided into three parts: networking, information security, and packet analysis. The book assumes most readers might be familiar with at least one or two areas, but the chapter makes no assumptions. Chapter 4, “Capturing Packets,” discusses network captures, or the recording of network packets. We take a deep dive into how Wireshark captures, manipulates capture files, and interprets the packets. There’s also a discussion around working with the variety of devices you encounter on a network. Chapter 5, “Diagnosing Attacks,” makes good use of the W4SP Lab, re-creating various attacks commonly seen in the real world. Man in the middle attacks, spoofing various services, denial of service attacks and more are all discussed. Chapter 6, “Offensive Wireshark,” also covers malicous traffic, but from the hacker’s perspective. Wireshark and the W4SP Lab are again relied on to launch, debug, and understand exploits. Chapter 7, “Decrypting TLS, Capturing USB, Keyloggers, and Network Graphing,” is a mash-up of more activities as we leverage Wireshark. From decrypting SSL/TLS traffic to capturing USB traffic across multiple platforms, this chapter promises to demonstrate something you can use wherever you work or play. Chapter 8, “Scripting with Lua,” contains about 95% of the book’s script content. It starts simple with scripting concepts and Lua setup, whether you’re working on Windows or Linux. Scripts start with “Hello, World” but lead to packet counting and far more complex topics. Your scripts will both enhance the Wireshark graphic interface and run from the command line. Who Should Read This Book To claim this book is for security professionals might be specific enough to the general IT crowd. However, to most information security professionals, it’s still too broad a category. Most of us specialize in some way or another, and identify ourselves by our role or current passion. Some examples include firewall administrator, network security engineer, malware analyst, and incident responder. Wireshark is not limited to just one or two of those roles. The need for Wireshark can be found in roles such as penetration tester or ethical hacker—roles defined by being proactive and engaging. Additional roles like forensics analyst, vulnerability tester, and developer also benefit from being familiar with Wireshark. We’ll show this through examples in the book. Regarding expectations on the reader, the book makes no assumptions. Information security specializations vary enough so that someone with 15 years of experience in one field is likely a novice in other fields. Wireshark offers value for anyone in those fields, but it does expect a basic understanding of networking, security and how protocols work. Chapter 3 ensures we’re all on the same page. Any reader must be technically savy enough to install software or understand systems are networked. And since the book targets security professionals, we presume a fundamental level for information security. Still, as far as “fundamentals” go, Chapter 3 acts as a refresher for what’s necessary around networking, information security, and packet and protocol analysis. Further in the book, Wireshark is used in the context of various roles, but there’s no experience requirement for grasping the content or making use of the labs. For example, the tools used in Chapter 6, “Offensive Wireshark” might be already familiar to the penetration tester, but the chapter assumes zero experience when instructing setup. To sum up, we understand there is a wide spectrum of possible roles and experience levels. You might be employed in one of these roles and want to use Wireshark more. Or you might be getting ready to take on one of these roles, and recognize Wireshark as essential tool to use. In either case, this book is for you. Tools You Will Need The one tool required for this book is a system. Your system does not need to be especially powerful; at the most a few years old would be best. Your system will be first used in Chapter 2, “Setting Up the Lab.” You first install and set up a virtualized machine. Then upon that virtual machine you will set up the labs. Of course, this book can benefit those without a system, but a system is needed to perform the labs referenced throughout the book. What’s on the Website The primary website needed for this book is the GitHub repository for the W4SP Lab code. The GitHub repo and its contents are explained further in Chapter 2, “Setting Up the Lab,” where you first download and build the virtual lab environment. Then the Lab files are installed onto your virtual machine. Other websites are cited throughout the book, mostly as pointers for additional resources. For example, some sites hold hundreds of network capture files that are available for analysis. Summary This is where the authors are at the edge of our seats, hoping you will leap into and enjoy the book, its materials, and the labs. A lot of thought and effort went into this book. Our only desire was to create a resource that inspired more people to have a deeper appreciation of Wireshark. Being information security professionals ourselves, we crafted this book for our peers. Chapter 1 Introducing Wireshark Welcome to Wireshark for Security Professionals. This introductory chapter covers three broad topics. In the first part, we discuss what Wireshark is used for and when to use it. The second part of this chapter introduces the popular graphic user interface (GUI). The GUI for Wireshark can appear quite busy at first, so we immediately want to get familiar with its layout. We break down the different areas of the interface, how they relate to one another, and the reasoning for needing each one. We also discuss how and when each part of the interface helps you maximize your use of Wireshark. In the third part of this chapter, we discuss the way Wireshark filters data presented on the interface. Being familiar with Wireshark’s interface helps you appreciate all the data presented, but the amount of data can still be overpowering. Wireshark offers ways to filter or separate what you need from all that is presented. The last part is about different types of filters and how you can customize these filters. Wireshark can appear to be a complicated tool, but by the end of this first chapter, the hope is you have a much higher comfort level with the tool’s purpose, interface, and ability to present you with what you want to see. What Is Wireshark? Wireshark, in its most basic sense, is a tool to understand data you capture from a network. The captured data is interpreted and presented in individual packet form for analysis, all within Wireshark. As you probably already know, packets are the chunks of data streaming on a network. (Technically, depending on the context level of where in the system the data is interpreted, chunks are called frames, datagrams, packets, or segments, but we’ll just use “packets” for now.) Wireshark is a network and protocol analyzer tool, free for download and use on a variety of platforms, spanning many flavors of Unix and Windows. Wireshark first captures the data from a network interface and then breaks the capture into the frames, segments, and packets, understanding where they begin and end. Wireshark then interprets and presents this data in the context of addressing, protocols and data. You can analyze the captures immediately or save them to load later and share with others. In order for Wireshark to view and capture all packets, not just those involving the capturing system, the network interface is placed in promiscuous mode (also called monitor mode) in the context of capturing on a wireless network. Finally, what grants you the ability to analyze packets in Wireshark are the dissectors. All these basic elements are discussed in more detail in Chapter 4, in the context of “sniffing” or capturing data, and how that captured data is interpreted. A Best Time to Use Wireshark? Wireshark is an immensely powerful tool with quite a bit of deep and complex functionality. It is capable of handling a wide range of known (and unknown) protocols. But although the functionality range is broad, most of it aligns to one end: to capture packets and analyze them. Being able to take the bits and bytes and present them in an organized, familiar, and human-readable format is what brings people to think of using Wireshark. Before launching Wireshark, it’s important to understand when to use it and when not to use it. Sure, it’s a great tool, but like any tool, it’s best used when it’s the right tool for the job. Here are scenarios when it’s ideal to use Wireshark: To look for the root cause of a known problem To search for a certain protocol or stream between devices To analyze specific timing, protocol flags, or bits on the wire And while not ideal, Wireshark can also be used: To discover which devices or protocols are the top talkers To see a rough picture of network traffic To follow a conversation between two devices You get the idea. Wireshark is ideal for determining a root cause of an understood problem. While not ideal for browsing network traffic or making high-level judgments about the network, Wireshark does have some features to show those statistics. But Wireshark can’t and shouldn’t be the first tool thought of early on in discovering a problem. Someone who opens Wireshark to skim through the list of packets to assess network health would soon be overwhelmed. Instead, Wireshark is for problem solvers, for the detectives who already know their suspects well. Avoiding Being Overwhelmed The majority of people who walk away from Wireshark do so because they find it overwhelming after only a few early experiences. To label Wireshark as overwhelming is misleading, however. What really paralyzes new users is the traffic, the list of packets flying by, not the application’s functionality. And, fair enough, once you start a capture and the packets scroll by in real time, it’s definitely intimidating. (But that’s what filters are for!) To avoid being overwhelmed, consider two aspects of Wireshark before diving into it: The interface—how it’s laid out and why Filters—how they work to reveal what you want Once you get a quick appreciation of the tool’s interface and how to write a filter, Wireshark suddenly appears intuitive and shows its power, without the scare factor. And that’s what we focus on for the rest of this chapter. The following sections are on the most important aspects that you need immediately to be comfortable using Wireshark. If you are already familiar with Wireshark, as well as filters, feel free to skim this chapter as a refresher so that you can be sure you are on the same page for the rest of the book. The Wireshark User Interface We start with the busy Wireshark GUI, which is packed with features. We provide a high-level overview of where you need to look to start seeing some packet data. With packet capturing covered, we then discuss the more powerful features of Wireshark, starting with dissectors. In Wireshark, dissectors are what parse a protocol and decode it for presenting on the interface. They enable Wireshark to give the raw bits and bytes streaming across the wire some context by displaying them into something more meaningful to the human analyst. We then round off the chapter by covering the various filters available to help limit and zero in on just the network data you are interested in. The home screen appears when you open Wireshark. On this screen are shortcuts you can use to start a new capture or open a previous capture file. For most newcomers to Wireshark, the brightly colored Capture button is the most attractive option. Starting a capture leads to a flurry of scrolling packets, which for the newcomer then leads to overwhelm. But let’s go back to the home screen. There are also links to online documentation that you can use to figure out how to accomplish a certain task. On the top of the screen, as shown in Figure 1-1, is the menu bar in the classic format you are probably familiar with. These menus have settings and other features like statistics that can be accessed when needed. (Don’t worry—we aren’t really worried about statistics.) Below these menus is the Main toolbar, which has quick access icons for the functionality you will use most while analyzing network traffic. These icons include things like starting or stopping a capture, and the various navigation buttons for finding your way around captured packets. Icon buttons are typically grayed if not applicable or usable— for example, without a capture yet. Figure 1-1: The Wireshark home screen Icons change over time from version to version. At the time this book was written, the blue shark fin starts a capture and the red square stops a capture. The shark fin is gray until the network interface is chosen, and we cover that soon. Also note that this toolbar area gives you a visual indication of the capture process. Again, many options are grayed out in Figure 1-1 because we are not yet capturing or don’t have a capture completed. As you go through this chapter, pay attention to this area to understand how it changes and how it reflects the various capture states. In many respects, Wireshark has an intuitive user experience. The Filter toolbar, which is below the Main toolbar, is a vital part of the Wireshark UI. You will soon fall in love with this little box, as you often find yourself drowning in a torrent of traffic. The Filter toolbar lets you remove whatever is uninteresting to the task at hand and presents just what you’re looking for (or takes out what you’re not looking for). You can enter display filters in the Filter text box that help you drill down what packets you see in the Packet List pane. We discuss filters in detail later in this chapter, but for now just trust me: They will be your new best friends. Packet List Pane The largest portion in the middle of the interface is reserved for the packet list. This list shows all the packets captured along with useful information, such as source and destination IP, and the time difference between when the packets were received. Wireshark supports color coding various packets to make sorting of traffic and troubleshooting easier. You can add custom colors for packets of interest, and the columns within the Packet List pane display useful information such as the protocol, packet length, and other protocol-specific information (see Figure 1-2). Figure 1-2: The Packet List pane This window is the bird’s-eye view into the network you are sniffing or the packet capture you have loaded into Wireshark. The last column, by default labeled “Info,” offers a quick summary of what that packet contains. Of course, it depends on the packet, but it might be the URL for an HTTP request or the contents of a DNS query, which is really useful for getting a quick handle on important traffic in your capture. Packet Details Pane Below the Packet List pane is the Packet Details pane. The Packet Details pane shows information for the selected packet in the Packet List pane. This pane contains a ton of information, down to what the various bytes are within the packet. Information such as the source and destination MAC address is included here. The next row contains IP information. The next row reveals the packet is sending to UDP port 58351. The next row reveals what information is contained in that UDP packet. These rows are ordered by the headers as they are ordered when sending data on the network. That means they are subject to change if you are capturing on a different type of network, such as a wireless network, that has different headers. The DNS column, which is the application data encapsulated within UDP, is expanded in Figure 1-3. Notice how Wireshark allows you to easily pull out information, such as the actual DNS query that was made within this DNS packet. This is what makes Wireshark the powerful network analysis tool that it is. You don’t have to memorize the DNS protocol to know which bits and bytes at what offset translate into a DNS query. Figure 1-3: The Packet Details pane Subtrees Because the details would be overwhelming if shown all at once, the information is organized and collapsed into sections. The sections, called subtrees, can be collapsed and expanded to display only what you need. (In Figure 1-2, the subtrees are collapsed; in Figure 1-3, they are expanded.) NOTE You might hear the message sent between devices referred to as a data frame or a packet. But what’s the difference? When referring to the message at the OSI layer 2 (the data link layer, where the MAC address is used), the whole message is called a frame. When referring to the message at OSI model layer 3 (the network layer, for example, using the IP address), then the message is called a packet. If you’re already familiar with how a data frame is structured, you recognize how the packet details subtrees are divided. Details are structured into subtrees along the lines of the data frame’s headers. You can collapse/expand a subtree by clicking the arrow sign next to the relevant section. The arrow is pointing to the right if the subtree is collapsed. Once you click on the arrow to expand that subtree, you’ll see the arrow points down (refer to Figure 1-3). And, of course, you’ll always have the option to expand or collapse all subtrees by right-clicking anywhere in the Packet Details pane to launch its pop-up menu. In Figures 1-2 and 1-3, packet number 7 is selected. Whatever packet is selected in the Packet List pane is the packet presented in the panes below it. In this case, it’s packet number 7 showing within the Packet Details pane. NOTE Packets are usually numbered based on the time they are received, although this isn’t guaranteed. The packet capture (pcap) library determines how to order the packets. If you double-click this packet, a separate window appears, to open the packet details. This is useful when you want to visually compare two different packets quickly. The Packet Details area in Figure 1-3 shows various rows of information that can be expanded or collapsed. Capturing Enough Detail The first row contains metadata regarding the packet, such as the number of the packet, when it was captured, on what interface it was captured, and the number of bytes captured versus the number of bytes that were on the wire. That last part might sound a little strange. Wouldn’t you always capture all the bytes that go across the wire? Not necessarily. Some network capture tools allow you to capture only a subset of the bytes that are actually transmitted across the wire. This is useful if you only want to get an idea of the type of packets that are going across the wire but not what actual data those packets have, which can greatly reduce the size of the packet capture. The downside, of course, is that you get only a limited amount of information. If disk space is not an issue, feel free to capture it all. Just be mindful that you are capturing and storing all traffic traversing that network cable, which can quickly become a significant amount. There are ways to limit the size of the capture. For example, instead of truncated packet data, capture only specific packet types and not all traffic. If someone wants to send you a capture, or if you want to see specific traffic, you can have Wireshark capture only the traffic you want, saving space. Everything is done using the right filters—and that section is coming soon enough! Packet Bytes Pane What follows the Packet Details pane is the Packet Bytes pane. This pane is at the bottom of the screen and wins the award for least intuitive. At first glance, it simply looks like gibberish. Bear with me for a couple of paragraphs; it will all make sense soon. Offsets, Hex, and ASCII You can see the Packet Bytes pane is divided into three columns. The first, left- most column simply counts incrementally: 0000, 0010, 0020, and so on. That’s the offset (in hexadecimal) of the selected packet. Here, offset simply means the number of bits off from the beginning—again, counting in hexadecimal (where 0x0010 = 16 in decimal). The middle column shows information, in hexadecimal, at that offset. The right-hand column shows the same information, but in ASCII. For example, the total amount of information from the very beginning (offset 0000) to offset 0010 is 16 bytes. The middle column shows each of the 16 bytes in hex. The right-hand column shows each of the 16 bytes in ASCII characters. When a hexadecimal value doesn’t translate to a printable ASCII character, only a “.” (period), is shown. So the Packet Bytes pane is actually the raw packet data as seen by Wireshark. By default, it is displayed in hex bytes. Right-clicking the pane gives you the option to convert the hex bytes into bits, which is the purest representation of the data, though often this might not be as intuitive as the hex representation. Another neat feature is that any row you highlight within the Packet Details pane causes the corresponding data within the Packet Bytes pane to be highlighted. This can be helpful when troubleshooting Wireshark’s dissection, as it allows you to see exactly which packet bytes the dissector is looking at. Filters When you start your first packet capture, a lot will probably be going on in the Packet List pane. The packets move across the screen too fast to make sense of anything meaningful. Fortunately, this is where filters can help. Filters are the best way to quickly drill down to the information that matters most during your analysis sessions. The filtering engine in Wireshark allows you to narrow down the packets in the packet list so that communication flows or certain activity by network devices becomes immediately apparent. Wireshark supports two kinds of filters: display filters and capture filters. Display filter are concerned only with what you see in the packet list; capture filters operate on the capture and drop packets that do not match the rules supplied. Note that the syntax of the two types of filters is not the same. Capture filters use a low-level syntax called the Berkeley Packet Filter (BPF), whereas display filters use a logic syntax you will recognize from most popular programming languages. Three other packet-capturing tools—TShark, Dumpcap, and tcpdump—also use BPF for capture filtering, as it’s quick and efficient. TShark and Dumpcap are both command-line packet-capturing tools and provide analysis capabilities, the former being the command-line counterpart to Wireshark. TShark, covered more deeply with example output, is introduced in Chapter 4. The third, tcpdump, is strictly a packet-capturing tool. Generally, you use capture filters when you want to limit the amount of network data that goes into processing and is getting saved; you use display filters to drill down into only the packets you want to analyze once the data has been processed. Capture Filters There are times when capturing network traffic that you can limit the traffic you want beforehand; at other times you will have to because the capture files will grow too large too fast if you don’t start filtering. Wireshark allows you to filter traffic in the capture phase. This is somewhat similar to the display filters, which you will read about later in this chapter, but there are fewer fields that can be used to filter on, and the syntax is different. It’s most important to understand that a capture filter screens packets before they are captured. A display filter, however, screens what saved packets are displayed. Therefore, a restrictive capture filter means your capture file will be small (and thus a smaller number of displayed packets, too). But using no capture filter means capturing every packet, and thus a large capture file, on which display filters can be used to narrow the list of packets shown. While it makes sense for Wireshark to capture everything by default, it does actually use default capture filters in some scenarios. If you are using Wireshark on a remote session, such as through Remote Desktop or through SSH, then capturing every packet would include many packets relaying the session traffic. Upon startup, Wireshark checks to see whether a remote session is in use. If so, a capture filter to filter out remote session traffic is in use by default. The building blocks of a capture filter are the protocol, direction, and type. For example, tcp dst port 22 captures only TCP packets with a destination port of 22. The possible types are: host port net portrange Direction can be set using src or dst. As you suspect, src is for capturing from a specified source address, while dst can specify the destination address. If it is not specified, both will be matched. In addition to specifying one direction, the following combined direction modifiers can be used: src or dst and src and dst. In a similar way, if a type is not specified, a host type will be assumed. Note that you need to specify at least one object to compare to; the host modifier will not be assumed if you would only specify an IP address as filter and will result in a syntax error. The direction and protocol can be omitted to match a type in both source and destination across all protocols. For example, dst host 192.168.1.1 would only show traffic going to the specified IP. If dst is omitted, it would show traffic to and from that IP address. The following are the most commonly used BPF protocols: ether (filtering Ethernet protocols) tcp (filtering TCP traffic) ip (filtering IP traffic) ip6 (filtering IPv6 traffic) arp (filtering ARP traffic) In addition to the standard components, there is a set of primitives that do not fit in one of the categories: gateway (matches if a packet used the specified host as gateway) broadcast (for broadcast, not unicast, traffic) less (less than, followed by a length) greater (greater than, followed by a length) These primitives can be combined with the other components. For example, ether broadcast will match all Ethernet broadcast traffic. Capture filter expressions can be strung together using logical operators. Again, with both the English and the logical notation: and (&&) or (||) not (!) For example, here are some filters for systems named alpha and beta: host beta (captures all packets to and from the alpha system) ip6 host alpha and not beta (captures all IP packets between alpha and any host except beta) tcp port 80 (captures all TCP traffic across port 80) Debugging Capture Filters Capture filters operate on a low level of the captured network data. They are compiled to processor opcodes (processor language) in order to ensure high performance. The compiled BPF can be shown by using the -d operator on tcpdump, Dumpcap, or TShark, and in the Capture Options menu in the GUI. This is useful when debugging a problem where your filter is not doing exactly what you were expecting. The following is an example output of a BPF filter: localhost:~$ dumpcap -f "ether host 00:01:02:03:04:05" -d Capturing on 'eth0' (000) ld (001) jeq #0x2030405 jt 2 jf 4 (002) ldh (003) jeq #0x1 jt 8 jf 4 (004) ld (005) jeq #0x2030405 jt 6 jf 9 (006) ldh (007) jeq #0x1 jt 8 jf 9 (008) ret #65535 (009) ret #0 As previously mentioned, using the -d operator will show the BPF code for the capture filter. And, used in the example above, the -f operator will show the libpcap filter syntax. Following is a line-by-line explanation of the BPF: Line 0 loads the offset for the second part of the source address. Line 1 compares the packet at the offset to 2030405 and jumps to line 2 if it matches, or line 4 if it doesn’t match. Lines 2 and 3 load the offset for the first part of the source address and compare it to 0001. If this also matches, it can return 65535 to capture this packet. Lines 4 through 7 do the same as lines 0 through 3 but for the destination address. Lines 8 and 9 are instructions to return. You can use this method of analyzing the filter step by step to verify where the filter is going wrong. Capture Filters for Pentesting We suspect you already know this, but we’ll add this, just in case: “Pentesting” is short for penetration testing, the art of testing a computer, network, or application to search for vulnerabilities. Any pentesters reading this book are familiar with the concept that you end up getting blamed for every problem that happens on the network even if you aren’t connected to it at the time. As such capturing data on a pentest is helpful when you need to prove to upset clients that you genuinely had nothing to do with the switch dying or a business-critical SCADA system exploding. It is also helpful when you need to review your packet captures for general information gathering or post-test analysis and reporting. The following snippet would capture all your outgoing traffic to serve as a logbook for your actions on the network. It captures only traffic coming from your network card identified by the MAC address and saves it split up in multiple time- stamped files prefixed by pentest. Notice that Dumpcap was used here instead of the GUI or TShark. dumpcap -f "ether src host 00:0c:29:57:b3:ff" -w pentest -b filesize:10000 You can run this snippet in the background, as running an entire instance of Wireshark would tie up too much of the system resources. Saving only the outgoing traffic is not much use for pentest analysis. To capture all traffic going to and from your testing machine combined with broadcast traffic, use the following snippet: dumpcap -f "ether host 00:0c:29:57:b3:ff or broadcast" -w pentest -b filesize:10000 As you can see, only the src directive was dropped, and a broadcast expression was combined with the Ethernet expression using the or statement. The following pentesting snippet can also be used to capture traffic to and from a list of IP addresses, such as all the IPs that are in scope for your pentest. This applies to cases where you are using multiple virtual machines and thus MAC addresses, but you want to be able to log all relevant traffic. dumpcap -f "ip host 192.168.0.1 or ip host 192.168.0.5" The list of hosts could get a little large to type by hand, so it is more practical to store your in-scope targets in a hosts.txt file and use it instead. To generate the filter itself, use the following one-liner and strip the last or: cat hosts.txt | xargs -I% echo -n "ip host % or " Display Filters To get started with display filters, we begin with a brief explanation of the syntax and available operators, followed by a walkthrough of a typical use that should get you up to speed in no time. The display filter syntax is based on expressions returning true or false by using operators for comparison. This can be combined with Boolean logic operators to combine several expressions so that you can really drill down your results. See Table 1-1 for the most common comparison operators. Table 1-1: Comparison Operators ENGLISH C-LIKE DESCRIPTION eq == Equal ne != Not equal gt > Greater than lt < Less than ge >= Greater than or equal to le 173.194.67.103 TCP 74 48231 > http [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=926223 TSecr=0 WS=1024 32 5.074492000 192.168.178.30 -> 194.109.6.66 DNS 75 Standard query 0x56dc A forums.kali.org 33 5.074987000 192.168.178.30 -> 46.51.197.88 TCP 74 59132 > https [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=926226 TSecr=0 WS=1024 34 5.082801000 192.168.178.30 -> 46.228.47.115 TCP 74 33138 > http [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=926228 TSecr=0 WS=1024 35 5.103958000 192.168.178.30 -> 91.198.174.192 TCP 66 47282 > http [ACK] Seq=1 Ack=1 Win=29696 Len=0 TSval=926233 TSecr=3372083284 36 5.104123000 192.168.178.30 -> 173.194.67.103 TCP 66 48231 > http [ACK] Seq=1 Ack=1 Win=29696 Len=0 TSval=926233 TSecr=1173326044 37 5.104411000 192.168.178.30 -> 91.198.174.192 HTTP 378 GE/favicon.ico HTTP /1.1 Like all the Wireshark tools, TShark runs on both Linux and Windows operating systems. With Windows, it isn’t added to your working path, so you won’t be able to run TShark from an open command prompt without first changing your working directory to the Wireshark installation folder. To avoid this little bit of extra typing, you can just add the Wireshark installation folder to your PATH variable, as outlined in Chapter 2. Like most *nix command-line tools, supplying the -h flag displays some general help about how to use TShark. Additionally, if you want to check your version, and whether it supports Lua scripting, you can provide the -v flag: localhost:~$ tshark -v TShark 1.10.2 (SVN Rev 51934 from /trunk-1.10) Copyright 1998-2013 Gerald Combs and contributors. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled (32-bit) with GLib 2.32.4, with libpcap, with libz 1.2.7, with POSIX capabilities (Linux), without libnl, with SMI 0.4.8, with c-ares 1.9.1, with Lua 5.1, without Python, with GnuTLS 2.12.20, with Gcrypt 1.5.0, with MIT Kerberos, with GeoIP. Running on Linux 3.12-kali1-686-pae, with locale en_US.UTF-8, with libpcap version 1.3.0, with libz 1.2.7. Built using gcc 4.7.2. The most important flag is going to be the -i flag, which specifies the interface on which to start capturing. Before the -i flag can be used, however, you will need to know how the interface you want to use is named. To help with figuring out which interface to use, TShark provides the -D flag. This flag prints all of the interfaces that are available for capture, as shown in the following code: localhost:~$ tshark -D 1. em1 2. wlan1 3. vmnet1 4. wlan2 5. vmnet8 6. any (Pseudo-device that captures on all interfaces) 7. lo To start capturing on a specific interface, use the -i flag along with the interface you are interested in capturing on. The -i flag is followed by either the specific interface or the number given by the list provided by the -D flag. If you do not specify an interface, TShark will begin capturing on the first non-loopback interface in the list. In the preceding example, the first non-loopback interface is em1. So, to capture on that interface, you would type: localhost:~$ tshark -i em1 Capturing on em1 Frame 1: 66 bytes on wire (528 bits), 66 bytes captured (528 bits) on interface 0 Often, when scripting with TShark, you don’t actually want to see all the packets that TShark is capturing because your script is already printing the data you want to see. Using the -q flag will suppress the majority of output so that you can clearly see the script output you are interested in. The reverse scenario is when you want to not just see what kinds of packets TShark is capturing but also the actual packet contents. Again, TShark provides the -V flag that will dump all the details of packets captured by TShark, as shown in the following example: localhost:~$ tshark -V Capturing on em1 Frame 1: 66 bytes on wire (528 bits), 66 bytes captured (528 bits) on interface 0 Interface id: 0 WTAP_ENCAP: 1 Arrival Time: May 12, 2014 04:52:57.103458000 CDT [Time shift for this packet: 0.000000000 seconds] Epoch Time: 1399888377.103458000 seconds [Time delta from previous captured frame: 0.000000000 seconds] [Time delta from previous displayed frame: 0.000000000 seconds] [Time since reference or first frame: 0.000000000 seconds] Frame Number: 1 Frame Length: 66 bytes (528 bits) Capture Length: 66 bytes (528 bits) [Frame is marked: False] [Frame is ignored: False] [Protocols in frame: eth:ip:tcp] Ethernet II, Src: Alfa_6d:a0:65 (00:c0:ca:6d:a0:65), Dst: Tp- LinkT_eb:06:e8 (00:1d:0f:eb:06:e8) Destination: Tp-LinkT_eb:06:e8 (00:1d:0f:eb:06:e8) Address: Tp-LinkT_eb:06:e8 (00:1d:0f:eb:06:e8) …...0. …. …. …. …. = LG bit: Globally unique address (factory default) …. …0 …. …. …. …. = IG bit: Individual address (unicast) Source: Alfa_6d:a0:65 (00:c0:ca:6d:a0:65) Address: Alfa_6d:a0:65 (00:c0:ca:6d:a0:65) …...0. …. …. …. …. = LG bit: Globally unique address (factory default) …. …0 …. …. …. …. = IG bit: Individual address (unicast) Type: IP (0x0800) Internet Protocol Version 4, Src: 192.168.1.127 (192.168.1.127), Dst: 64.4.44.84 (64.4.44.84) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport)) 0000 00.. = Differentiated Services Codepoint: Default (0x00) …...00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable Transport) (0x00) Total Length: 52 Identification: 0x46db (18139) Flags: 0x02 (Don't Fragment) 0… …. = Reserved bit: Not set.1.. …. = Don't fragment: Set..0. …. = More fragments: Not set Fragment offset: 0 Time to live: 64 Protocol: TCP (6) Header checksum: 0xc569 [correct] [Good: True] [Bad: False] Source: 192.168.1.127 (192.168.1.127) Destination: 64.4.44.84 (64.4.44.84) [Source GeoIP: Unknown] [Destination GeoIP: Unknown] Transmission Control Protocol, Src Port: 53707 (53707), Dst Port: https (443), Seq: 1, Ack: 1, Len: 0 Source port: 53707 (53707) Destination port: https (443) [Stream index: 0] Sequence number: 1 (relative sequence number) Acknowledgment number: 1 (relative ack number) Header length: 32 bytes Flags: 0x019 (FIN, PSH, ACK) 000. …. …. = Reserved: Not set …0 …. …. = Nonce: Not set …. 0… …. = Congestion Window Reduced (CWR): Not set …..0.. …. = ECN-Echo: Not set …...0. …. = Urgent: Not set …. …1 …. = Acknowledgment: Set …. …. 1… = Push: Set …. …..0.. = Reset: Not set …. …...0. = Syn: Not set …. …. …1 = Fin: Set [Expert Info (Chat/Sequence): Connection finish (FIN)] [Message: Connection finish (FIN)] [Severity level: Chat] [Group: Sequence] Window size value: 41412 [Calculated window size: 41412] [Window size scaling factor: -1 (unknown)] Checksum: 0x1917 [validation disabled] [Good Checksum: False] [Bad Checksum: False] Options: (12 bytes), No-Operation (NOP), No-Operation (NOP), Timestamps No-Operation (NOP) Type: 1 0… …. = Copy on fragmentation: No.00. …. = Class: Control (0) …0 0001 = Number: No-Operation (NOP) (1) No-Operation (NOP) Type: 1 0… …. = Copy on fragmentation: No.00. …. = Class: Control (0) …0 0001 = Number: No-Operation (NOP) (1) Timestamps: TSval 1972083, TSecr 326665960 Kind: Timestamp (8) Length: 10 Timestamp value: 1972083 Timestamp echo reply: 326665960 Note that this is effectively what you see in the Wireshark GUI if you were to expand all the fields in the Packet Details pane. As you can imagine, with the -V flag set, any amount of network traffic will result in a fast-scrolling screen of capture output. If the volume of packets is too high to control, or if you discover packets are being dropped before they can be written to disk, remember that Wireshark allows you to change the buffer size. By default, the buffer is 2 MB for each interface. Increasing the buffer offers more room to scroll back for packet review. This concludes the introduction to TShark. For the majority of the chapters, we’ll use the GUI interface. Chapter 8 delves deep into programming with Lua, the scripting language that enables you to extend Wireshark, both at the command line and in the GUI. We also play a lot more with TShark. Dealing with the Network Earlier you experimented with a short capture (or is it still running?). Whether you use the Wireshark GUI or the TShark command-line interface, the packets visible to your device might be limited by the topology of your network. This is the common, fundamental challenge to anyone seeking to capture packets. And that’s what this section is all about. What good is a packet analyzer if you can’t get the packets you want to analyze? The answer is pretty simple: It isn’t! In this section, we go over different ways to capture packets to make sure you don’t ever have the problem of not being able to get the network data you need for your task. Capturing packets on Ethernet networks wasn’t much of a problem until the rise of switched networks. Before the switch, the main tool for connecting multiple networked devices was a hub. A hub just copied every packet it received to all ports except the one it was received on to prevent loops. This meant everyone with enough privileges on a connected computer could capture all the traffic passing through the hub. Today it is more complicated; capturing packets requires anything from configuration changes to specialized equipment or dedicated packet-capturing features on network devices. This section describes methods for capturing packets and, where applicable, provides explicit instructions on how to perform the capture. One warning, however: We are going to be talking about tools other than what is available with Wireshark. While this may seem blasphemous, we need to be clear on the Wireshark use case. The majority of Wireshark functionality is geared toward analyzing packets. Also, there are situations where you do not want to install any additional software but still need to gather packet data. We address these situations by discussing some other tools and scripts that are capable of recording a network into pcap format for later, offline analysis by Wireshark. Local Machine At times, it seems just capturing packets from your host machine isn’t of much use, although you would be surprised at the information you can salvage from a network analyzer by just plugging it in and having it listen. Additionally, seeing what your network applications are actually doing on the network often tells you more than a thousand error messages can. In this section, we go over some techniques for capturing traffic on the local machine. In particular, we cover how to capture packets from the local machine using tools that are native to Windows and Linux as well as how to capture traffic that is just going over localhost. Native Packet Capture Native packet capture refers to capturing packets from a machine without having to install any additional tools. As mentioned in the introduction to this section, it is useful to be aware of the methods to capture traffic from a local machine without having to install additional software. A good example of a situation like this is when software is installed that prevents the installation or running of software that is not preapproved or included by default with the operating system installation. Another example is if you are trying to analyze a potentially compromised machine and want to avoid tipping your hand to the bad guy or muddling your results by installing additional software. Luckily, there are options for both Linux and Windows that enable you to get packet data without having to install any additional tools. Native Windows Capture We cover native packet capture in Windows first. Capturing traffic on Windows 10 and below without installing additional software is all but impossible. We don’t say it is completely impossible, because if working in this industry has taught us anything, it is that anything is possible. The reason this is fortuitous is that newer versions of Windows actually provide functionality that can be leveraged to get packet captures without having to install any additional tools. We are going to look at the netsh command-line tool. This tool has been available on Windows for several versions, and Windows 10 has only grown its feature set. In particular, it has the netsh trace command, which we will leverage to get some packet data. NOTE netsh trace was introduced starting with Windows 7/Windows 2008. The full command-line options for netsh trace can be found at https://technet.microsoft.com/en-us/library/cc754516(v=ws.10).aspx. There are a lot of awesome resources on the Internet for how you can really use netsh trace, so we are not going to go into too much detail of all the options this tool supports. For starters, at a command prompt, type netsh trace /? to view the options. Sniffing Localhost When we say localhost, we are usually talking about the loopback adapter, which is basically a virtual interface that isn’t physically connected to an actual network. Localhost is actually just a hostname. By convention, however, localhost almost always resolves to the reserved 127.0.0.1 IPv4 address and the ::1 IPv6 address. Generally, applications use this loopback interface for inter- process communication between applications running on the same host machine. Localhost is also often used by services that do not need to be exposed to a larger network. A prime example is a database server running on the same machine as the web application connecting to that database. Because the database is potentially accessible from outside of the web application machine, it poses a security risk. In such situations, simply bind the database to localhost so that the local web server can still communicate with it but the database is inaccessible from processes outside the local machine. It should be noted that occasionally you will see applications that mess this up. For example, if your machine has an IP address of 192.168.56.101 and you bind a service to that IP specifically, then processes running on your local machine will be able to communicate with that service, much like they can if the service was bound to 127.0.0.1. The difference, however, is that anyone who can access the 192.168.56.101 from the local network at large can also interact with the service. This is why it is important to make sure that services that do not need to be exposed to the network at large are not binding to 0.0.0.0 (which is shorthand for all IP addresses) or any other interface that has a reachable IP address. On Linux-based operating systems the loopback interface is generally the lo interface. Wireshark can easily attach to this interface and sniff packets destined to localhost only. Figure 4-5 shows some sample ICMP traffic to the IP address 127.0.0.1. Figure 4-5: Sample localhost ICMP traffic Windows and Localhost In networking, every system has a hostname. The hostname identifies that specific system for services or connections. And while the hostname is unique compared to other systems, every system has the same name “local” to itself: localhost. The hostname localhost refers to the system you’re currently on. Connecting to localhost connects you to services running on the local system. If you have a web server running locally to serve the web files in a browser, simply type http://localhost to browse the locally running web service. Similar to the local system’s hostname, the network adapter used to connect to localhost is also special. It is called the loopback adapter. The loopback adapter is not a physical network adapter, but only a logical one. Wireshark is able to sniff and capture network traffic from the loopback adapter, provided it is installed. However, for Windows, the loopback adapter is not installed by default. Adding a Loopback Adapter to Windows The loopback adapter is not present by default on Windows systems. This does not mean that it is not using the loopback principle to transmit traffic to the local machine. To be able to capture this traffic, you need to add the loopback interface manually. Once the loopback adapter is available for Wireshark to present as an option, you can select it and capture from it. Follow these steps to add the loopback interface to your Windows sniffing host: 1. Run hdwwiz in a command prompt. This should open the Add Hardware Wizard. 2. Click Next and select the manual device selection option (Advanced). 3. Select Network Adapters as the type of hardware and click Next. 4. Select Microsoft as the manufacturer and select Microsoft Loopback Adapter as the network adapter (see Figure 4-6). Click Next. Figure 4-6: Installing the loopback adapter on Windows 5. Click Next again to install the driver. 6. Click Finish to close the Add Hardware Wizard. You should now have a new interface using the loopback driver. NOTE Beginning with Windows 8 and Server 2012, the loopback adapter is labeled “Microsoft KM-TEST Loopback Adapter” in the list of available Microsoft network adapters in the hardware wizard. Once installed, Windows renames the new device “Loopback.” On older Windows installations, the newly added adapter might be named “Local Area Connection (2)” or similar. This does not make interface selection easier in the Wireshark dialog boxes. However, you can rename the interface, like any folder or file in Windows, by highlighting the name and editing its friendly name. Sniffing without a Loopback Adapter on Windows You can sniff traffic destined for the localhost on Windows without installing a loopback adapter. Netresec has a public tool called RawCap that can be used to sniff any interface on a Windows machine that has an IP address, and specifically can sniff traffic destined for 127.0.0.1. RawCap outputs to pcap format, which can then be easily loaded into Wireshark. You can review the RawCap web page on the Netresec site for a full explanation of how to use RawCap, but for our purposes we are just going to demonstrate how to use it to sniff localhost traffic. This is accomplished by double-clicking RawCap.exe, which displays the prompt shown in Figure 4-7. Select the appropriate network interface number—in this case, number 6 was chosen to sniff on the localhost. (Keep in mind that while it says Loopback, this isn’t an interface installed on the machine, like in the previous section.) We then chose the name loopback_dump.pcap, which is saved in the current working directory. Figure 4-7: RawCap loopback sniffing If you don’t have any traffic on the localhost of your machine, you can generate some by pinging 127.0.0.1. After you capture a decent amount of traffic, press Ctrl+C to kill RawCap.exe and save your file. Figure 4-8 shows opening the pcap created by RawCap in Windows, which displays packets sent to localhost. Figure 4-8: RawCap pcap in Wireshark NOTE You can download RawCap from http://www.netresec.com/?page=RawCap. The site also contains more detailed information regarding the RawCap application. It’s important to note that, at the time of this writing, RawCap still cannot work with IPv6. If you want to use RawCap with localhost, it is best to type the IPv4 address 127.0.0.1. If you typed localhost, it might resolve to ::1 on the IPv6 loopback adapter, and RawCap will not behave as expected. Sniffing on Virtual Machine Interfaces Security researchers, whether offensive like pentesters or defensive like malware analysts, have a habit of using a lot of virtual machines (VMs). You generally carry only a laptop to the job, but you might need to reconstruct an entire network of computers to test something in your portable lab of VMs. You also almost always need varying versions of the most popular operating systems ready to go. Debugging complicated lab setups while testing your exploits or looking for vulnerabilities can take a lot of time. It always helps if you can take a look at what an application is actually doing on the network. This is especially helpful when error messages are missing and/or nondescriptive. Which interface to sniff on in a VM environment depends a lot on your specific setup and the use case. Each of the common networking setups for VirtualBox is explored in detail in this section. Note that while other virtualization solutions may use different names for their network types, they are all generally implemented the same way, and the following information can be applied for how to capture traffic. Bridge Connecting your VMs with the bridged setup means connecting them on the same layer 2 network as your host machine. This means that the interface to which you have bridged will be responding to multiple MAC addresses—the MAC address of the physical interface as well as the MAC address for every virtual machine that has been bridged to the physical interface. All the traffic passing through the bridge can be sniffed on the interface to which the virtual machine has been bridged. This is especially useful if you are running multiple virtual machines and you want to see all the network traffic they are generating. Figure 4-9 shows bridging a Kali Linux VM to a Windows host physical interface Realtek PCIe gigabit. Note the MAC address within the VirtualBox configuration window (which is configurable when the VM is powered off). Figure 4-9: VirtualBox bridging For my setup, the VM interface has an IP address of 192.168.2.12, and my host machine has an IP address of 192.168.2.14. Figure 4-10 shows the Wireshark output from the em1 interface (our host interface). These ICMP packets show that from a network standpoint the VM is attached to the physical interface and uses its own MAC address for Ethernet communication. Again, this means that as far as the network is concerned, there are two distinct Ethernet devices with only one physical interface. Figure 4-10: Wireshark sniffing bridged network BRIDGED NETWORKING AND WIFI VirtualBox handles bridged networking differently when dealing with wireless adapters. Due to the lack of promiscuous mode support for some wireless drivers, VMs do not use their MAC address. So, VirtualBox performs a type of MAC-NATing on-the-fly by replacing the MAC address on incoming frames that have an IP destined for a VM with that VM’s MAC address. If you want to capture only VM traffic and not traffic generated by your actual host, you could use a capture filter. The following capture filter would apply to our previous example and capture only traffic destined for the Kali virtual machine: ether src host d8:cb:8a:99:33:8b || ether dst host08:00:27:5b:78:bb The downside is that you are exposing your VMs to whichever network the interface you have bridged is connected to. When deploying labs, you may want to ensure that the traffic is properly isolated, which is why you would use the host- only networking option, as discussed in the following section. Host-only For host-only networking in Oracle VirtualBox, a virtual network interface (for example, vboxnet0) is created on the host machine that acts as a switch. The VMs are then transparent to the host, attached to this virtual host-only switch interface. This is handy when you want communication between VMs and the host machine, such as virtual servers offered privately to the host. In host-only mode, the VMs do not have access to the Internet, like they do in a NAT network. Host-only mode is also commonly used when you are setting up a lab environment that you want to isolate for analysis. When using host-only networking, it is often helpful to sniff all the traffic of the host-only network traffic from the host itself. One would initially think that sniffing on the host- only network interface with Wireshark would give you all the traffic on the host- only network. Remember, however, that this interface is acting as a switch, so it only receives broadcast traffic or traffic that is actually destined for that host interface. Therefore, when sniffing from the host, you will not see traffic between VMs. Obviously, you can run Wireshark within each VM to sniff traffic generated by that VM, but this gets cumbersome with a lab setup of more than two VMs. Unfortunately, there isn’t an easy way to capture all the traffic on a host-only network. Because the unicast traffic between VirtualBox VMs connected as host- only mode cannot be captured by the host, VirtualBox offers a workaround (https://www.virtualbox.org/wiki/Network_tips). However, being a command-line solution and requiring effort on each VM to be captured, this is no simple fix. You can create your own host-only network by using the Linux bridging utilities and running your own DHCP server, or by just using static IP addresses. We discuss Linux bridging in more detail later in this chapter. NOTE While it may be possible to create a similar setup in Windows using loopback adapters and the ICS/bridging features of Windows, doing so is not covered in this book. Ultimately, the flexibility of Linux networking makes it the standard host operating system to use when dealing with any kind of network analysis. NAT Network address translation (NAT) is the default method of networking for connecting VMs to the outside world. When you configure NAT as the method for VM connections, your host machine is routing all the packets onto the network. It is a layer 3 connection, so you will not be able to analyze layer 2 traffic on the host side of the network. All traffic generated by your VMs will look like it originated from your host machine to the target network, and the VMs will receive all traffic forwarded by the host machine. The NAT engine needs to keep track of all the connections made by the VMs in order to know where to send replies to these packets. This can generate problems when the VMs are generating a lot of connections (that is, port scanning). In these cases it might be a better idea to switch to bridged networking. If your network access is limited to one MAC address, for example, or if you change your network configuration repeatedly, it might save you trouble if you stick to NAT networking. This ensures the configuration for your virtual machines doesn’t have to be updated each time you change networks, and it will fool the network into thinking only one machine is connected. When you have a VM configured in NAT mode, you can sniff all the traffic the machine sends to the outside network by sniffing on whatever interface your default gateway is accessible on. The downside is that you are not able to easily distinguish between VMs, which are both using NAT. You also cannot easily distinguish between traffic generated by your host and those packets generated by VMs. Often NAT is useful only when you want to get access to the Internet from your VMs and you are not too concerned with getting good packet data from the traffic that VM sends. Sniffing with Hubs In the earlier days of networking, the typical method of connecting machines on a network was with a hub. Today’s method is with a switch. As you know, the primary difference between switches and hubs is the traffic from one system is repeated out all other ports on a hub, whereas a switch is intelligent enough to direct the traffic only out the needed port. Switches learn what systems (known by their layer 2 MAC address) are hanging off of which ports. Hubs broadcast all traffic everywhere. Remembering this key difference explains why sniffing with hubs means getting all the traffic, whereas sniffing off a switch can mean hearing only some of the conversation. It’s also important to remember the OSI model, the representative layering of how data travels and is handled between systems. Bits from the Physical layer get switched, routed, error-checked, authenticated, presented, and formatted, eventually leading to the top layer (Application). Discussion about switches and hubs is at layer 2, the Data Link layer, where network traffic is split into frames. Switches versus Hubs The difference between these two network devices was briefly mentioned in the introduction of this section. It boils down to the fact that a hub does not do anything intelligent with the frame. A hub operates on layer 1 (the Physical layer) of the OSI model. All bits are copied to every other port except the receiving one. This last bit of intelligence is essential in the case of two hubs connected to each other with one cable. If it would copy a broadcast frame to all ports, including the receiving one, it would cause a broadcast storm, amplifying that single broadcast frame. Switches are more intelligent devices. They operate on layer 2 of the OSI model and thereby understand Ethernet (MAC) addresses. This enables a switch to decide to which port to send traffic by keeping a table that lists ports and MAC addresses. Broadcast frames are still forwarded to all ports except the receiving port. This behavior is the reason some (ethical) hackers still bring an old hub to consulting jobs. The fact that it keeps a table of MAC addresses means that you are not able to see traffic not addressed to you. This is generally a good thing, but not for those in the security crowd if they are investigating suspicious activity or are in an offensive role. Sniffing from a Hub To capture network traffic passing through a specific Ethernet cable, you need an Ethernet hub and two extra cables. After connecting all the cables, there is a Y- formed connection, as shown in Figure 4-11. Figure 4-11: Capturing packets with a hub Packets should now be repeated on all three sides of the connection. A few things have changed in the network, though. Most connections automatically negotiate their physical connections to full-duplex, allowing both transmitting and receiving at the same time when connected normally. When you connect a hub, all connections negotiate to half-duplex and therefore re-enable collision- detection protocols. This is an anomaly in modern switched networks. Full-duplex connections were not possible before switched networks because the collision domain of the connection contained more than one device. NOTE Keep in mind your own traffic can now also be seen on all connections to the hub. This might be a problem when stealth is important. As shown in Figure 4-12, a frame coming in to port number 1 will be duplicated to ports 2 and 3. This is similar to the behavior of a switch without Spanning Tree Protocol (STP) enabled, meaning all traffic is directed out, without regard to a possible looping. Figure 4-12: Traffic when sniffing on a hub OBTAINING A HUB Ethernet hubs are a bit of a dying breed. Basically, they are obsolete for general use because of increased bandwidth usage and high-speed Ethernet networks. On the other hand, if you are strapped for cash, there is almost no better alternative to a good old-fashioned hub for intercepting network traffic. Go through the boxes of old electronic devices you probably have lying around to find one, or find it on one of the online auction/marketplace sites. If you cannot source a hub for a reasonable price, review the following section on SPAN ports. Managed switches are quickly getting smaller and cheaper. SPAN Ports Switched Port Analyzer (SPAN) is a feature found on most managed switches or routers. Not every manufacturer uses the proprietary name SPAN, but the functionality is more or less the same. Another common term for the same principle is port mirroring. Sniffing on a SPAN port is explained in the following sections along with the configuration of a SPAN port on the most common network devices. Sniffing on a SPAN Port The traffic you see on your SPAN port depends on the configuration and capabilities of your capturing device. For this example, assume you want to capture the traffic of one device, as that is the simplest case. Sniffing on the SPAN port is extremely versatile. Most of the time you can listen- enable the mirroring of packets from a list of interfaces or even an entire virtual LAN (VLAN). There is a serious pitfall, however: If you are sniffing multiple ports or an entire VLAN, there is a high chance you will get duplicate packets. This is a side effect of sniffing on a VLAN or multiple ports, so if you absolutely have to do this to capture all the traffic you need, there is no other option. There is also the question of connectivity for the listening system. Depending on the vendor of the switch, connectivity may be disabled for a mirror destination port. This is a sensible default, because your own connectivity would only contaminate the network traffic you are capturing, which could be problematic in a mobile pen-testing scenario. So, be prepared and investigate the options your switch supports. Figure 4-13 shows a diagram of the connections in a SPAN-sniffing setup. The dotted line represents the copied packet originally destined for another client also being transmitted to the attacker. Figure 4-13: SPAN sniffing connections NOTE SPAN ports can cause duplicate packets to be captured. To remove the duplicates, you can use editcap—for example, editcap -d capture.pcap dedup.pcap. Configuring SPAN on Cisco To monitor all the traffic coming in or out from FastEthernet port 1/1, use the following snippet. This is the syntax for most of the Catalyst series of Cisco switches: Switch#conf t Switch(config)#monitor session 1 source interface fastethernet 1/1 Switch(config)#monitor session 1 destination interface fastethernet 1/2 Switch(config)#exit You can check the results of your commands with the following: show monitor session 1. By default, there are two assumptions in the previous configuration. The first monitor statement assumes that both directions should be monitored. This can be overridden by specifying both | rx | tx. The second assumption is probably less expected. In a Cisco SPAN configuration, a destination monitor port by default does not accept any incoming traffic. You are only able to receive the monitored traffic, and no connection to the network can be made. To enable incoming traffic on the destination port, you can append ingress vlan vlanid to specify the VLAN incoming traffic should be sent to. For example, to capture traffic received on the monitored port and allow normal traffic on the destination port, enter the following: Switch(config)#monitor session 1 source interface fastethernet 1/1 rx Switch(config)#monitor session 1 destination interface fastethernet 1/2 ingress vlan 5 Switch(config)#exit Different models of the Catalyst switch series will have different syntax. Cisco routers are also not covered by this example. The general idea will be the same, however, so refer to the references and examples from Cisco if you are trying to configure port mirroring on a specific model and the previous examples do not seem to apply. Configuring SPAN on HP HP ProCurves are a common alternative to Cisco or Juniper network hardware. Their syntax is similar to Cisco, but there are small differences as well as completely different terms for the same features. The following statements enable port mirroring on an HP switch: Procurve(config)# mirror-port 6 Procurve(config)# interface 2 Procurve(eth-2)# monitor Procurve(eth-2)# exit Procurve(config)# In this case, port 6 is the port where monitored traffic is duplicated. You can specify the monitor keyword for multiple interfaces. All the traffic will be sent to the mirror port. In the switch we used for testing, it was impossible to specify only capturing sent or received packets. You can show the current monitoring configuration by executing: Procurve# show monitor The output will show both a list of ports being monitored as well as the interface the packets are being mirrored to. Remote Spanning Sometimes the person responsible for analyzing spanned traffic is unable to have the monitoring device directly off of the spanned port. In another case, a person might want to monitor spanned ports on more than one switch. In both cases, you just need to use remote spanning. Remote spanning allows you to monitor a switch port from a device on another switch port. And you can set up remote spanning to span ports from multiple switches. In both cases, the spanned traffic gets sent to the destination switch port (typically over a dedicated VLAN to isolate the traffic and prevent possible collision or loop issues). The monitoring device is expected at the destination port. Network Taps Network taps are devices dedicated to capturing traffic on a network. They are available for different types of networks and/or cables used. A lot of network taps are passive devices, meaning they perform the capture without any software or intelligence by making a bypass connection to the RX wire pair, for example. Because you are tapping into a network line and not as a connected device, there might be some confusion about the direction of traffic. Be assured that, even when connected only to the RX wire pair, you are still capturing traffic intended for all. The bits are still traveling on the wire, regardless of what originating device’s traffic you are capturing. If you choose to aggregate traffic, then also be mindful of how much traffic you’re receiving. If your tap is more than 50% utilized, you’re likely dropping packets. Unlike SPAN ports, taps can capture network traffic at 100% utilization very well. This is in part due to the fact that a tap does not change in the operation of the network (aside from the fact that it leaks traffic to someone other than the intended recipient). A tap generally does not combine the mirrored traffic into one port for easy sniffing. It merely replicates incoming traffic on both of the interfaces to separate monitoring ports. In order to capture all traffic on a tapped link, you need two sniffing interfaces on your monitoring workstation. There are a few advantages to using taps compared to other methods of capturing network traffic. Because most taps are passive devices, it is unlikely they will disrupt network connectivity because of hardware failure. For the same reason, they are completely invisible on the network. They do not participate on the network, so they cannot be detected or change its behavior, except on negligible physical levels (for example, degrading signal quality). Most passive network taps degrade the connection to 100BASE-TX on purpose because a passive device cannot tap a 1000BASE-T connection. This is due to the fact that it uses all four wire pairs and auto-negotiates a clock source. A passive tap might allow two devices to continue operating on 1000BASE-T but would not be able to sniff the packets because it would be unaware of the clock source. Active switches solve this problem and allow you to capture up to 10GBASE-T, while keeping the redundancy features that do not interrupt the connection when the device fails. For the reasons just mentioned, taps are useful for applications like intrusion detection systems and similar monitoring, where the traffic only needs to be read. Professional-Grade Taps An enterprise-level network tap is an expensive network device that can be rack mounted most of the time, just like any other high-capacity network device. This makes these types of taps a good fit for permanent sniffing solutions as might be needed for an IDS. These taps can often be configured dynamically, and most claim not to interrupt the tapped connection in the event of device or power failure. The use of these taps as well as an overview of the types available is out of the scope of this book. Suffice to say that these devices are available in all types and flavors for every physical network media in use in modern networks. Throwing Star LAN Taps The throwing star is a popular LAN tap available either in kit form to assemble yourself or as an assembled device. It is completely passive and quite inexpensive. It is primarily used by enthusiasts and is a common addition to the pentester’s kit bag. As shown in Figure 4-14, the throwing star is a portable device, so there is no excuse for not keeping it in your set of default equipment. Like the other types of passive Ethernet taps, the throwing star splits the Rx and Tx traffic to separate Ethernet cables. It also uses its circuitry to force the speed to auto-negotiate to 100 Mbps in order for the wiring to be correct, as described earlier in this section. Figure 4-14: Throwing star LAN tap Source: Great Scott Designs Transparent Linux Bridges If you own a machine capable of running Linux with two or more network interfaces, you can transform it into a powerful networking tool. This section shows you the basics of Linux bridges and how to sniff traffic with them. Using a bridge is very versatile because you can use packet filtering provided by the operating system. This allows you to block certain traffic or even change packets and redirect them to a malicious destination, which is covered in Chapter 6 when dealing with man-in-the-middle attacks. NOTE If you don’t own a device with enough network interfaces, inexpensive USB Ethernet adapters are available. These always come in handy if you find yourself low on available Ethernet connections and a switch might be overkill or not suitable for the configuration. Look on the regular auction sites to see what’s available. Sniffing on a Linux Bridge Linux bridge support is built into the Kernel, but to start using it you need to install the support utilities. For Debian/Ubuntu-based systems, install the package bridge-utils: localhost# apt-get install bridge-utils And do the following for Red-Hat based systems: localhost# yum install bridge-utils After installing the bridging utilities, yo can manage bridges by using the brctl command. This command allows you to add a bridge with the addbr command, which appears as an extra interface. Then you use the addif or delif commands to add interfaces to the bridge. If the interfaces are up and in promiscuous mode, packets will be forwarded between the interfaces. To create a bridge named testbr using eth1 and eth2 of your machine, use the following commands: root@pickaxe:~# brctl addbr testbr root@pickaxe:~# brctl addif testbr eth1 root@pickaxe:~# brctl addif testbr eth2 root@pickaxe:~# ifconfig eth1 up promiscuous root@pickaxe:~# ifconfig eth2 up promiscuous root@pickaxe:~# ifconfig testbr up Packets should now be forwarded from one interface to the other. This also means that the packets being processed by your machine can now be sniffed. All you have to do is set up Wireshark to listen on the bridge with a device directly attached to it, and it will receive every packet that passes through. Figure 4-15 illustrates the flow of traffic. Figure 4-15: Traffic flow when sniffing a Linux bridge Hiding the Bridge In the default configuration, a Linux bridge is not the stealthiest of options. A number of issues might negatively affect the network you are sniffing, contaminate your traffic samples, or give away your presence. This section highlights some of the troubles you might encounter while trying to sniff using a transparent Linux bridge. Linux bridges support Spanning Tree Protocol (STP). STP uses Bridge Protocol Data Unit (BPDU) packets to detect loops in the network. BPDU packets can be thought of as scouts sent to detect anomalies, particularly loops, in the topology. Loops in a network are very bad because broadcast packets can propagate around and get re-sent, cascading into a network-crippling broadcast storm. BPDU packets that detect a loop will instruct the STP-enabled switch to disable the offending switch port. If you connect a switch for the purpose of sniffing, you generally do not want this feature, especially if you are sniffing a workstation or similar non-networking device that would not send BPDU packets in normal operation. For these reasons, you should verify that STP is disabled on your bridge. The following code snippet shows how you can check if STP is enabled and how to disable it: root@pickaxe:~# brctl show bridge name bridge id STP enabled interfaces stpbr 8000.000000000000 yes root@pickaxe:~# brctl stp stpbr off root@pickaxe:~# A cautionary note: A bridge interface generates traffic. Traffic originating from the bridge will have layer 2 (MAC) information in the IP header. Even when you don’t configure an IP address on the bridge, it can generate traffic in some cases. Unless you specifically configured your bridge to run in a “transparent” mode or “stealth” mode, your bridge’s MAC information will be used. This traffic not only gives away your presence on the network, but traffic with an unfamiliar MAC address might even disable the switchport if the settings are restrictive enough or if there is a form of Network Access Control (NAC) in place. A good way to prevent these problems is by filtering all traffic from the host going out the bridge entirely using iptables. The following iptables statements block all outgoing traffic originating from the host. This has to be done on the bridge interfaces as well because some kernel modules (like the IPv6 stack) generate traffic on all connected interfaces in an attempt to autoconfigure or because of multicast protocols. root@pickaxe:~# iptables -A OUTPUT -o stpbr -j DROP root@pickaxe:~# iptables -A OUTPUT -o eth1 -j DROP root@pickaxe:~# iptables -A OUTPUT -o eth2 -j DROP Remember that this disables your connection to the network if you are using the bridging interfaces for other purposes (like browsing the Internet). If it is essential for you to be stealthy, take extra care to disable IPv6 functions that try to automatically configure. It is best to disable IPv6 altogether in a sniffing setup because it is hard to limit the transmission of packets on an IPv6 interface that are related to the IP protocol itself. Wireless Networks Wireless communications result in unique challenges to safeguard confidentiality. A cable gives at least some idea of the recipient. In the case of wireless communications, the recipient can be anywhere within a given radius. For this reason, there are multiple ways to secure the packets traveling through the airwaves. Some of these protocols have been broken, exposing the users of these deprecated protocols to sniffing. Others choose to leave the WiFi Access Points unsecured for ease of access or to run a restaurant hotspot. The full scope of sniffing wireless networks is beyond this book, but this section gives you a primer on the possibilities when sniffing WiFi connections. WiFi sniffing on Windows is very challenging because WinPcap, the library used by Wireshark, does not support monitor mode, also called rfmon mode for wireless. If you need a monitor mode for Wireshark on Windows, you will need to change the driver, at a minimum. At the time of this writing, one possible driver option is Riverbed AirPcap. In general, getting wireless monitoring working in Wireshark is highly dependent on the version of Windows, Wireshark, the model of wireless adapter, and, of course, the driver. Therefore, this section focuses on sniffing wireless connections on Linux. Unsecured WiFi Transmitting packets through an unsecured wireless connection is much like a shouting conversation across a city square: You can’t really blame people for listening in. The same applies to sniffing on a wireless link. All you need is a wireless network card that supports promiscuous mode to hear everything that is shouted across that busy café hotspot. Promiscuous mode for a wireless card is called monitor mode or rfmon mode. The easiest way to check if your wireless card supports this mode, and to enable it if it does, is the Aircrack-ng suite of tools. Go to http://www.aircrack- ng.org/doku.php?id=faq for up-to-date information. Currently, an expensive but known working option is the Alfa AWUS036H, a USB wireless card with high output that makes it ideally suited for sniffing and security applications. Follow these steps to enable monitor mode on your wireless interface and analyze the packets with Wireshark: 1. Connect the WiFi card. Make sure it is detected in dmesg output. 2. Disable all programs that might interfere with the card’s operation (for example, dhclient and NetworkManager). Airmon-ng will also warn you about this. 3. Execute the following command: airmon-ng wlan0 start (where wlan0 is the name of your supported wireless card). Note that you will have to run this command as root. 4. Airmon-ng creates a new interface called mon0. 5. Start Wireshark and select the new interface mon0 to sniff the packets in Wireshark. NOTE How do you know if a wireless card is connected in Linux? By checking for it in dmesg output. The Linux dmesg command can provide information about hardware device drivers loaded during boot, as well as drivers connected on- the-fly. There are many resources available online about the dmesg command for your research, but first try by typing: cat /var/log/dmesg | less By checking with dmesg command, you can verify your wireless card’s driver was loaded. As shown in Figure 4-16, Wireshark shows you all the raw packets it receives. In the case of unsecured WiFi connections, as used in public hotspots, this means you can see all the traffic if the signal quality is good enough. Figure 4-16: Raw wireless packets in Wireshark Identifying base stations with airodump is also possible. Using the tool airodump is left outside the scope of this book, as there are several resources online. The wireless card is tuned to a specific channel and you will only see packets that are transmitted in the frequency range belonging to that channel. The allowed channel numbers differ by region but are in the range of 1 to 14. To change the channel the card is listening to, use the following command: root@pickaxe:~# iwconfig channel 6 MAN-IN-THE-MIDDILE ATTACKS Sometimes when performing a security review of a product, you don’t have the opportunity to configure network interfaces or even install Wireshark. This is when offensive techniques like man-in-the-middle (MitM) attacks can come in handy. Placing your monitoring system physically between the communicating devices or executing techniques to mimic one of the other devices will allow you to monitor their traffic without Wireshark. Chapter 5 takes a deep-dive look into how to perform various types of MitM attacks. In the most basic terms, an MitM attack is a way to leverage unauthenticated network traffic or physical access to trick a victim machine into connecting to your attacker machine. This can be done with protocols like ARP and DNS (see Chapter 5). To perform an MitM attack, you might need to spoof your target’s identity by sending fake ARP or DNS messages to redirect response traffic to you. In reality, the previous section that talked about using a Linux bridge is an example of using physical access (to the network cable and NIC) to sniff traffic from a victim machine. Loading and Saving Capture Files Viewing packets in the GUI using Wireshark or watching them scrolling by you in TShark is great. Sometimes, however, Wireshark isn’t the only tool you want to use for packet analysis. Packet captures can come from varying sources generated by different tools and saved to different formats. Wireshark supports both saving out to the common pcap formats and reading/saving various proprietary formats. You cannot save a running capture, so in order to save your traffic, you need to stop the capture using the menu or by clicking the Stop button in the toolbar; otherwise, the Save button or menu options are grayed out. After stopping a running capture session, you can save it by selecting File ⇨ Save or pressing Ctrl+S. This presents a Save dialog box, where you can select the filename, destination path, and output format for the packet capture. Likewise, there are very interesting packet captures available online for loading and analyzing. While most traces are kept at a minimal size and common format, you might find a few needing extra attention. File Formats Since Wireshark version 1.8, the default output format is PcapNG, a newer format being developed by WinPcap. PcapNG has support for saving metadata in the capture file, such as comments; it also supports higher precision timestamps and name resolution. If you intend to view the capture with a different, much older tool, you will want to save in the older pcap format to ensure compatibility. As shown in Figure 4-17, Wireshark can support file formats for a wide range of tools. Figure 4-17: The File Save dialog box Table 4-1 summarizes the different formats that Wireshark supports. Depending on which version Wireshark is running or produced the capture file, the capture will be one of the two primary supported file formats. Table 4-1: Common Wireshark Capture File Formats FORMAT/EXTENSION INFORMATION SUPPORT PcapNG This is the next-generation New default for format supported by libpcap Wireshark, from version 1.1.0 and onward. tcpdump, and other tools using libpcap. Pcap The original pcap format. This is the most supported pcap

Wireshark for Security Professionals PDF

Document Details

Tags

Related

Summary

Full Transcript

Upgrade to continue