This is a story about like-minded individuals working for a company that was hired to hack a target and not get caught.

Picture “an open-plan kind of windowless room in the back of a building, with a bunch of techie guys banding together.” Think of “hackers away from society, not being influenced by the outside world” each working feverishly at his own desk, but with a good deal of banter going on between them.

Sitting in this anonymous room among the others is a guy we’ll call Louis. He grew up in a small, insular city in the north of England, began fiddling with computers about the age of seven when his parents bought an old computer so the children could start learning about technology. He started hacking as a schoolkid when he stumbled on a printout of staff usernames and passwords and found his curiosity stirred. His hacking landed him in trouble early, when an older student (a “prefect,” in British terminology) turned Louis in. But getting caught didn’t deter him from learning the secrets of computers.

Now grown tall, with dark hair, Louis no longer finds much time for the “very English sports” — cricket and soccer — that he cared so much about as a schoolboy.

Any company that describes itself using the word “security” must seem like a particularly hot challenge. If they’re involved with security, does that mean they’re so security-conscious that there would be no way to break in? To any group of guys with a hacker mentality, it must seem like an irresistible challenge, especially when, as here, the guys had nothing to start out with beyond the name of their target company.

“We treated it as a problem to be solved. So, the first thing we did was to find out as much information about this company as we could,” Louis says. They began by googling the company, even using Google to translate, since none of the group spoke the language of the country.

The automated translations were close enough to give them a feel for what the business was all about and how big it was. Though they aren’t very comfortable with social engineering attacks, that possibility was ruled out anyway because of the language barrier.

They were able to map what IP address ranges were publicly assigned to the organization from the IP addresses of the company’s Web site and its mail server, as well as from the European IP address registry, Reseaux IP Europeens (RIPE), which is similar to American Registry of Internet Numbers (ARIN) in the United States. (ARIN is the organization that manages IP address numbers for the United States and assigned territories. Because Internet addresses must be unique, there is a need for some organization to control and allocate IP address number blocks. The RIPE organization manages IP address numbers for European territories.)

The main Web site, they learned, was external, with a third-party hosting company. But the IP address of their mail server was registered to the company itself and was located within their corporate address range. So, the guys could query the company’s authoritative Domain Name Service (DNS) server to obtain the IP addresses by examining the mail exchange records.

Louis tried the technique of sending an e-mail to a nonexistent address. The bounce-back message would advise him that his e-mail could not be delivered and would show header information that revealed some internal IP addresses of the company, as well as some email routing information. In this case, though, what Louis got was a “bounce” off of their external mailbox; his e-mail had only gotten to the external mail server, so the “undeliverable” reply provided no useful information.

Brock and Louis knew it would make life easier if the company was hosting its own DNS. In that case they would try to make inquiries to obtain more information about the company’s internal network, or take advantage of any vulnerability associated with their version of DNS. The news was not good: Their DNS was elsewhere, presumably located at their ISP (or, to use the British terminology, their “telecoms”).

They noticed that “there were quite informative names coming back from some of the systems,” which was a clue to what function those systems had within the company. This also provided insight into the mindset of the company’s IT people. “It just looked like the administrators had not got full control over the information that is available about their network, and that’s the first stage of intuition about whether you’re going to be able to get access or not.” Brock and Louis thought the signs looked favorable.

This is an example of trying to psychoanalyze the administrators, trying to get into their heads about how they would architect the network. For this particular attacker, “it was based in part on the knowledge of the networks and companies that we had seen in the particular European country and the level of IT knowledge and the fact that the people in this country were maybe a year and a half to two years behind the UK.”

This information gave them a clue that the mail server was either on the DMZ, or all the systems behind the firewall were on the same network. (The DMZ is a so-called demilitarized zone — an electronic no-man’s-land network that sits between two firewalls and that is ordinarily accessible from both the internal network and the Internet. The purpose of the DMZ is to protect the internal network in case any of the systems exposed to the Internet are compromised.)

They knew the mail server had port 25 open, and by doing a traceroute, they also knew they could actually penetrate the firewall to communicate with the mail server. “We saw that that path actually took us through this router device, and then through the next hop that seemed to disappear, which was actually the firewall and then one hop behind that we saw the mail server, so we had a rudimentary idea about how the network was architected.”

Louis said they often begin by trying a few common ports that they know are likely to be left open by firewalls, and he named a few services like port 53 (used by the DNS); port 25 (the SMTP mail server); port 21 (FTP); port 23 (telnet); port 80 (HTTP); port 139 and 445 (both used for NetBIOS, on different versions of Windows).

In this case they found only three open ports: a mail server, a Web server with all the security patches installed that was apparently not being used, and on port 23, the telnet service. When they tried to telnet in on the device, they got the typical “User Access Verification” Cisco password prompt. So they were seeing a little bit of progress — at least they had identified the box as a Cisco device.

On a Cisco router, Louis knew from experience, the password is quite often set to something quite obvious. “In this case we tried three passwords — the name of the company, blank, and cisco, and we could not get into that router. So instead of creating too much noise at this point, we decided to stop attempting to access the service.”

They tried scanning the Cisco device for a few common ports but got nowhere.

The sum total of their results for a whole day of effort didn’t go much beyond having identified one single router.

Then, using the Nmap program, a standard tool for port scanning, they did a scan with the program’s default services file that looked for some 1,600 ports; again they came up with the empty bag — nothing significant.

“So what we did was a complete full port scan, scanning both the router and the mail servers.” A full port scan meant examining more than 65,000 ports. “We were scanning every single TCP port and looking for any possible services on these hosts that we had on our target list at that point.”

This time they found something interesting, yet strange and a little perplexing.

Port 4065 was open; it’s unusual to find such a high port in use. Louis explained, “What we thought at that point was that maybe they’ve got a telnet service configured on port 4065. So, what we did was telnet into that port and see if we could verify that.” (Telnet is a protocol for remotely controlling another machine anywhere on the Internet. Using telnet, Louis connected to the remote port, which then accepted commands from his computer and responded with output displayed directly to his screen.)

When they tried to connect to it, they got back a request for a login name and password. So they were right that the port was being used for telnet service — but the dialog for user authentication was very different than presented by a Cisco telnet service. “After a while, we identified it as some 3COM device. This then really tweaked our enthusiasm for the job because it isn’t often you find a Cisco box that looks like some other device, or find some other service listed on a high TCP port.” But the fact that the telnet service on port 4065 was running as a 3COM device didn’t make sense to them.

Brock found the high TCP port and connected to it using telnet. “Once he got a log-in prompt, I shouted back to try admin [for the username], with the usual suspect passwords like password, admin, and blank. He tried various combinations of these three as the username and password, and hit gold after only a few attempts: the username and password on the 3COM device were both admin. “At that point he shouted that he got in,” Louis said, meaning that they were now able to get telnet access to the 3COM device. The fact that it was an administrative account was icing on the cake.

Through the command-line interface, they were able to query information about the device. “We figured that maybe someone had plugged the console cable from this 3COM device into the Cisco device and inadvertently enabled access.” That would make sense, as a convenient way employees could telnet into the 3COM device through the router. “Maybe there weren’t enough monitors or keyboards in the Data Center,” Louis guesses, and they had jury-rigged a cable as a temporary fix. When the need was over, the administrator who has strung the cable had forgotten all about it. He had walked away, Louis figured, “quite unaware of the consequences of his actions.”

Now that they had access to the 3COM console, they looked at the configuration records, including the unit’s assigned IP address, and protocols being used for virtual private network connectivity. But they discovered that the device also sat on the same address range as the mail server and outside of an internal firewall, on the DMZ. “We concluded that it actually sat behind the perimeter firewall and was protected from the Internet using some sort of filtering rules.”

They tried to look at the configuration of the device itself to see how the incoming connections were set up, but through that interface they couldn’t get enough information. Still, they guessed that when any user connected to port 4065 on the Cisco router from somewhere on the Internet, the connection was likely being made to the 3COM device that was plugged into the Cisco router.

Curious about this 3COM device, they had set up to capture the real-time console log. If any activity happened overnight, they would be able to see it when they came in the next morning.

They tried to set up their own personal VPN interface on the 3COM device by bringing up another interface on the 3COM box, with a different IP address, one that the firewall wasn’t explicitly filtering.

It didn’t work. They found that the device couldn’t be configured without disrupting legitimate services. They couldn’t bring up an identically configured VPN system, and the way the architecture was set up, it restricted enough so that they couldn’t do what they wanted to.

They were in the DMZ of the company’s network, but when they tried getting connections out to their own systems, they were stymied. They also tried doing a ping sweep (trying to ping every system on the network) on the entire network, but from the 3COM system behind the firewall, to identify any potential systems to add to their target list. If they were any machine addresses in the cache, it meant that some device was blocking access to the higher-level protocol. “After several attempts,” Louis said, “we did see entries in the ARP cache, indicating that some machines had broadcast their machine address.” (ARP, the Address Resolution Protocol, is a method for finding a host’s physical address from its IP address. Each host maintains a cache of address translations to reduce the delay in forwarding data packets.)

So there were definitely other machines in the domain, “but [they] weren’t responding to pings — which is a classic sign of a firewall.”

(For those not familiar with pinging, it’s a network scanning technique that involves transmitting certain types of packets — Internet Control Message Protocol, or ICMP — to the target system to determine whether the host is “alive” or up. If the host is alive, it will respond with an “ICMP echo reply” packet.) Louis continues, “This seemed to confirm our impression that there was another firewall, there was another layer of security between the 3COM device and their internal network.”

Louis was beginning to feel they had reached a dead end.

They decided to investigate the IP addresses that they had discovered in the console log. “We kind of saw that a next step was to have a look and see what was remotely communicating to this 3COM device, because if you could break into that device, you might be able to hijack an existing connection to the network.” Or they might be able to obtain the necessary authentication credentials to masquerade as a legitimate user.

They knew some of the filtering rules, Louis said, and were looking for ways of bypassing these rules on the firewall. His hope was that they’d be able to “find systems that were trusted and maybe had the leverage to actually pass through this firewall. The IP addresses that were coming up were of great interest to us.”

When they were connected to the 3COM system console, he explained, anytime a remote user connected or a configuration change was made, it flashed up an alert message at the bottom of the screen. “We were able to see the connections going on in these IP addresses.”

The registration records detailed the organization that particular IP addresses were registered to. Additionally, these records also include the contact information for administrative and technical personnel responsible for the organization’s network. Using these addresses, they again turned to the registration database records on RIPE, which gave them information on what company these IP addresses were assigned to.

In fact, this search brought another surprise. “We found the addresses were registered to a big telecommunications provider within this particular country. At this point we couldn’t completely put it all together, we couldn’t really understand what these IP addresses were, why people were connecting from a telecoms company,” Louis said, using the British term for what we call an ISP. The two guys began to wonder if the VPN connections were even from remote users of the company, or something entirely different that they couldn’t at the moment even guess at.

Louis wondered who besides the internal employees might also need to have access to this network. This was a company proud of its technological innovation, so Louis and Brock thought that maybe they had developed a “really great distribution application” that would enable guards to log in after they had made a delivery, and then find out what their next pickup would be. This application may have been programmed to make the process idiot-proof through automation. Maybe the driver would click an icon, which would tell the application to connect to the application server and obtain his orders.

They thought about a dial-up service, “perhaps from a laptop computer in the cabin [the driver’s compartment]. And the company would either have to host these servers that we’d gotten into, or they would have to outsource them with a third party. We hypothesized that the third party was a telecoms company, and information would have to pass from the telecoms company to our target company, and that had to pass over the Internet through a VPN tunnel.” They conjectured that the guards would call into the ISP and authenticate there, before being allowed to connect into the target company’s network.

But there was also another possibility. Louis went on:

They also thought about how the company was going about authenticating users. If a guard has to dial up to one of these systems located at the telecoms company and authenticate to the telecoms company, they reasoned, then the authentication services were simply being outsourced. Maybe there was another solution, they figured, whereby the authentication servers were actually hosted by the target company rather than the telecoms provider.

Often the authentication task is passed off to a separate server that provides this function. Maybe the 3COM device was being used to access an authentication server on the internal network of the target company. Calling from a cellular modem, a guard would connect to the ISP, be passed to the 3COM device, and his username and password would then be sent off to the other server for authentication.

So their working hypothesis at this point was that when a security guard initiated a dial-up connection, he established a VPN between himself and the 3COM device.

Louis and Brock figured that to gain access to the internal network, they first had to gain access to the telecommunications system at the ISP that the van drivers connected with. But “one thing we didn’t know was the phone numbers of these dial-up devices. They were located in a foreign country and we didn’t know what kind of phone lines they were, and we didn’t have much chance to find that information on our own. The big thing we knew was that the type of protocol for the VPN was PPTP.” The reason this was significant is because Microsoft’s default VPN installation just uses a shared secret, which is usually the Windows login and password to the server or domain.

They had had a few drinks by this time, and they decided on a “no-holds-barred approach” to solving the problem.

My own view of the subject is that hackers gain insight into how networks and systems are usually configured in the business environment just by poking around. With experience, you gain an awareness of how system administrators and implementers think. It’s like a game of chess, in which you’re trying to outthink or outsmart your opponent.

So I believe what’s actually at play here is based on experience of how system administrators set up networks and the common mistakes they make. Maybe Louis was right at the beginning of his remarks on the subject: What some people call intuition is better labeled experience.

They found that these connections came up for maybe a minute or so and then disconnected. If they were right, a guard would dial in, pick up his work order, then go right back offline again. Which meant they would have to move very quickly. “When we saw these IP addresses flash up, we’d really bash the client system hard,” Louis commented, using “bash” in the sense of pounding the keys with adrenaline running, as in playing an exciting computer game.

They picked out some ports for services that might be vulnerable, hoping to find one that could be attacked, such as a telnet or FTP server, or an insecure Web server. Or perhaps they could gain access to open shares over NetBIOS. They also looked for GUI-based remote desktop programs such as WinVNC and PC Anywhere.

But as the morning dragged on, they couldn’t see any services running beyond a couple of hosts.

The application PC Anywhere allows taking control of a computer remotely. But this is only possible when the other computer is also running the program.

Louis called the effort to connect to a PC Anywhere system “a very defining moment.” He joined the other guy at his machine as a window appeared on the screen. “It’s initially a black background,” Louis said, “and one of two things happens — either a gray password prompt is displayed, or the background goes blue and a Windows desktop comes into view.”

So they were now successfully into the client that connected to the 3COM device.

The first thing to do was to open the PC Anywhere session and hit two on-screen buttons, that Louis referred to as the “Blank the screen button” and the “Lock the user out of the console button.” He explained:

They did this, gaining control of the session, also making sure the user couldn’t see what they were doing because they had blanked his screen. Louis knew that it wouldn’t take the user long to get suspicious or think he had a computer problem, and shut the machine down, meaning that the guys didn’t have very long.

The first thing he suggested was looking at the password list (PWL) file. (This file, used under Windows 95, 98, and ME, contains sensitive information such as dial-up and network passwords. For example, if you use dial-up networking under Windows, all the authentication details, including the dial-up number, username, and password, are likely stored in a PWL file.)

Before downloading the file, they had to turn off the antivirus software so it wouldn’t detect the tools they were using. Then they tried using the document-transfer capability in PC Anywhere to transfer the PWL file from the driver’s machine to themselves. It didn’t work. “We weren’t sure why, but didn’t have time to sit around and discuss it. We had to get the PWL information off that machine immediately, while the driver was still on line.”

What else could they do? One possibility: upload a cracking tool, crack the PWL file on the driver’s machine and extract the information into a text file, and then send the text file to themselves. They tried to login into an FTP server to download the PWL craking tool. But they realized a difficulty: The keyboard mappings on the driver’s machine were for the foreign language, which would explain the problems they were having trying to authenticate. “We kept getting a ‘Login Incorrect’ message because of the foreign keyboard mappings.”

The clock was ticking.

Here they were, facing a hugely pressured time crunch, and none of the guys in the room had an answer for the foreign-keyboard problem. Maybe as a workaround they could enter the username and password in ASCII code instead of actual letters and numbers. But nobody knew offhand how to enter characters using the equivalent ASCII code.

So, what does anyone do in today’s world when they need an answer in a hurry? That’s what Louis and Brock did: “We opted to jump on to the Internet and do some research to find a way of entering letters without using the letters on the keyboard.”

In short order, they had their answer: Activate the Num Lock key, then hold down the <Alt> key and type the number of the ASCII character on the numeric keypad. The rest was easy:

Instead of pictures of pinup girls, these guys had ASCII charts on the walls. “ASCII pinups,” Louis described them.

With a little scribbling down of information, and one guy typing at the keyboard while the other read him what to type, they successfully entered the username and password. They were then able to transfer the PWL cracking tool and run it to extract the information from the PWL file into a text file, which they then transferred off the driver’s laptop to an FTP server under their control.

When Louis examined the file, he found the authentication credentials he had been looking for, including the dial-up number and logon information being used by the driver when connecting to the company’s VPN service. That, Louis thought, was all the information he needed.

While cleaning up to be sure they didn’t leave any traces of their visit, Louis inspected the icons on the desktop and noticed one that seemed to be for the application being run for the guards to pick up their information from the company. And so they knew that these machines were, in fact, connecting through to the company and querying an application server to obtain information needed by the drivers in the field.

A couple of seconds later, they noticed that their PC Anywhere connection dropped — the guard had disconnected. Louis and the crew had extracted the information from the PWL file just in the nick of time.

Louis and Brock now had a phone number, which they expected to be for one of the dial-up devices that they had drawn on their diagram in the pub the night before. But again, it was foreign number. Using a Windows system of the same kind that the guard had been using, they dialed up to the company’s network, entered the username and password and “We found that we’ve successfully established a VPN session.”

The way the VPN was configured, they were given a virtual IP address within the company’s DMZ, so they were behind the first firewall but still facing the firewall guarding the internal network that they previously discovered.

This IP address assigned by the VPN was on DMZ range and was likely trusted by some machines on the internal network. Louis expected that penetrating the internal network would be much, much easier, since they had gotten past the first firewall. “At this point,” he says, “we expected it would easy to get through the firewall, into the internal networks.” But when he tried, he found that he couldn’t get in directly to an exploitable service on the machine running the application server. “There was a very strange TCP port that was allowed through the filtering, that we guessed was for the application that the guards were using. But we didn’t know how it worked.”

Louis wanted to find a system on the company’s internal network that they could access from the IP address that had been assigned. He adopted the “usual hacker rules” to try to find a system they could exploit on the internal network.

They were hoping to find any one system inside the network that was never remotely accessible, knowing it would probably not be patched against these vulnerabilities, since it was “more likely to be treated as an internal-use-only system.” They used a port scanner to scan for any accessible Web server (port 80) across the entire IP address range of the internal network, and found a Windows server they could communicate with that was running Internet Information Server (IIS), but an older version of the popular server software — IIS4. That was great news, since they were likely to find some unpatched vulnerability or configuration error that would give them the keys to the kingdom.

The first thing they did was to run a Unicode vulnerability detection tool against the IIS4 server to see if it was vulnerable, and it was. (Unicode is a 16-bit character set for encoding characters from many different languages using a single character set.) “So we were able to use the Unicode exploit to execute commands on that IIS Web server,” exploiting security vulnerabilities on a system past the second filtering firewall on their internal network, “deep inside trusted territory, as it were,” in Louis’s description. The hackers in this case crafted a Web request (HTTP) that used these specially encoded characters to bypass the security checks of the Web server, allowing them to execute arbitrary commands with the same privileges as the account the Web server was running under.

Stuck because they did not have the ability to upload files, they now saw an opportunity. They used the Unicode vulnerability to run the “echo” shell command to upload an Active Server Pages (ASP) script — a simple file uploader that made it easy to transfer more hacking tools to a directory under the webroot that was authorized to run server-side scripts. (The webroot is the root directory of the Web server, as distinguished from the root directory of a particular hard drive, such as C:.) The echo command simply writes any arguments passed to it; the output can be redirected to a file instead of the user’s screen. For example, typing “echo owned > mitnick.txt” will write the word “owned” in the file mitnick.txt. They used a series of echo commands to write out the source code of an ASP script to an executable directory on the Web server.

They then uploaded other hacking tools, including the popular networking tool netcat, which is a very useful utility for setting up a command shell to listen on an incoming port. They also uploaded an exploit tool called HK that exploited a vulnerability in older version of Windows NT to obtain system administrator privileges.

They uploaded another simple script to run the HK exploit and then used netcat to open a shell connection back to themselves, enabling them to enter commands to the target machine, much like getting a “DOS prompt” in the days of the DOS operating system. “We tried to initiate an outgoing connection from the internal web server to our computer on the DMZ,” Louis explained. “But that didn’t work, so we had to use a technique called ‘port barging.’” After executing the HK program to gain privileges, they configured netcat to listen on port 80; to “barge” the IIS server out of the way temporarily, watching for the first incoming connection to port 80.

Louis explained barging by saying, “You essentially temporarily push IIS out of the way, to steal a shell, and allow IIS to sneak back in at the same time you maintain access to your shell.” In the Windows environment, unlike Unix-type operating systems, it’s permissible to have two programs use the same port simultaneously. An attacker can take advantage of this feature by finding a port that’s not filtered by the firewall and then “barging” onto the port.

That’s what Louis and Brock did. The shell access they already had on the IIS host was limited to the rights permitted to the account that the Web server was running under. So they ran HK and netcat, and were able to gain full system privileges — running as the system user, which is the highest privilege on the operating system. Using standard methodologies, this access would allow them to get full control of the target’s Windows environment.

The server was running Windows NT 4.0. The attackers wanted to get a copy of the Security Accounts Manager (SAM) file, which contained the details of user accounts, groups, policies, and access controls. Under this older version of the operating system, they ran the “rdisk /s” command to make an emergency repair disk. This program initially creates several files in a directory named “repair.” Among the files was an updated version of the SAM file that contained the password hashes for all the accounts on the server. Earlier Louis and Brock recovered the PWL file containing sensitive passwords from a security guard’s laptop; now they were extracting the encrypted passwords of users on one of the servers of the company itself. They simply copied this SAM file into the webroot of the Web server. “Then, using a web browser, we retrieved it from the server to our machine back in our office.”

When they had cracked the passwords from the SAM file, what they noticed was that there was another administrator account on the local machine that was different than the built-in administrator account.

Step-by-step. The local account was simply an administrator on the Web server and didn’t have privileges to the entire domain. But by recovering the password on that local Web server account, thanks to a careless, lazy administrator, they were now able to compromise the domain administrator account. The responsibility of a domain administrator is to administer or manage an entire domain, as distinguished from being an administrator on your local desktop or laptop (single machine). In Louis’s view, this administrator wasn’t an exception.

Or “Pick up this prisoner A, take him to this location, deliver him to the custody of this person,” and you’ve just gotten your cousin’s best friend out of jail.

Or a terrorist.

They had in their hands a tool for getting rich, or creating havoc. “It was kind of shocking because they didn’t see the possibility of what could have happened had we not brought this to their attention,” Louis says.

What that company considers “security,” he believes, “is actually suspect security.”

From the sound of it, the company had been seriously remiss. They hadn’t gone through a risk analysis step-by-step — “If the first machine gets compromised, what could a hacker do from that point?” and so on. They considered themselves secure because with a few configuration changes, they could close the gap Louis had pointed out. Their assumption was that there weren’t other faults except this one that Louis and Brock had managed to find and use.

Louis sees this as a common arrogance within the business sector — an outsider can’t come along and preach security to them. Company IT people don’t mind being told about a few things that need to be fixed, but they won’t accept anyone telling them what they need to do. They think they know it already. When a breach occurs, they figure they just dropped the ball on this one occasion.

We’ve already addressed the issue more than once in these pages about the folly of any security decision based on this attitude. The stories in this book demonstrate again and again that if you leave a single gap, some attacker will sooner or later find it. The best security practice is to ensure that the access points of all systems and devices, obscure or not, be filtered from any untrusted network.

IT policy drafters should consider a requirement that client systems maintain a certain level of security before being allowed to connect to the corporate network. Products are available that install agents onto the client systems to ensure security controls are commensurate with company policy; otherwise, the client system is denied access to corporate computing resources. The bad guys are going to analyze their targets by examining the whole picture. This means trying to identify whether any users connect remotely, and if so, the origin of those connections. The attacker knows if he or she can compromise a trusted computer that is used to connect to the corporate network, it’s highly likely that this trust relationship can be abused to gain access to corporate information resources.

Even when security is being well handled within a company, there is too often a tendency to overlook the laptops and home computers used by employees for accessing the corporate network, leaving an opening that attackers can take advantage of, as what happened in this story. Laptops and home computers that connect to the internal network must be secure; otherwise, the employee’s computer system may be the weak link that’s exploited.

If you were asked to name important steps to defend against the most common vulnerabilities that allow attackers to gain entry, based on the stories in this book, what would some of your choices be?

Please think about your answer briefly before reading on; then go to the next page.

Whatever items you came up with as some of the most common vulnerabilities described in this book, I hope you remembered to include at least some of these: