Secure Computing: Sec-C

Lately I have been working on a few new image analysis tools. One of them is based on the "copy-move" algorithm (PDF).

About Copy-Move

The algorithm is kind of neat: a discrete cosine transformation (DCT) is used to create a fingerprint over a region, such as a 16x16 square. Every DCT is created (that's a lot of DCT's!) and then they are sorted uniquely. The basic concept: duplicate DCTs suggest a copy-paste since they have the same results. However, duplicates can happen. So, the algorithm tracks the vector (direction and length) between all duplicate DCTs. If there are enough duplicates with the same vector, then we can conclude that it is a copy-paste; a region in the picture was cloned to another region in the same picture.

As cool as it is, the algorithm has some big limitations. (Those are what I was fixing by applying additional algorithms and tweaking how the main algorithm works.)

John Graham-Cumming has an implementation of the algorithm. While this is a good proof-of-concept, it has some serious limitations. For example, it allocates over 1032 BYTES PER PIXEL. A small picture that is 300x300 will require more than 92,880,000 bytes (92 Megs)! Small pictures take minutes to analyze. Medium pictures take hours. Large pictures? Segfault due to not enough memory. (While copymove.c is licensed under the GPL, I used no part of this code. My implementation is based off Fridrich's paper with my own optimizations.)

Busting Myths

I was trying my implementation against a test suite of images, looking for any corner issues. What I found was... surprising.



On September 15, 2000, reporter Dan Rodricks wrote in the The Baltimore Sun about a boat that had been bisected by a channel marker. In 2007, the TV show Mythbusters tested whether a boat traveling at 25 miles per hour could cause that kind of damage; they showed that it could not happen (myth busted).

The picture above claims to show the boat bisected by the pole. But there are some problems:

• The accident reportedly happened around 2:00am. The picture shows bright daylight. Did they really wait most of the day without touching the boat? And in six hours, the tide would have changed by as much as two feet. But there is no sign of scraping on the pillar.
  
• The center of the boat appears to be under water, but it does not look flooded. Perhaps it is just the angle...
  
• Is the pillar made out of wood or metal? If it is wood, then were is the damage to the pillar? If it is metal, then wouldn't it be even a little dented?

However, observations are only speculations. Let's use the image clone detection tool... (Mouse over the image to see the analysis!)



The analysis shows a large region that is cloned between the red and blue sections. This is a copy-and-paste in the image.

The algorithm normally uses a 16x16 DCT, leading to a very tight alignment with few false matches. However, it can miss things, like matches that are 15x15 or smaller:

original 16x16 15x15 13x13 12x12 11x11

The small matches at the top are spurious. However, the big matches in the water below the boat are definite: the water has been cut-and-pasted. Now that you know where to look, you can actually see rectangles where the waves stop abruptly -- the water is fake. In fact, the reflection of the pillar in the water was created through a series of replications.

Given that the water is fake, we need to question whether the boat and the rest of the picture is fake... or did someone try to cover up something in the water? In any case, the photo is not real because the water has been digitally manipulated.

Tracing the Origins

This report has all of the markings of an urban legend: a great story, a fake photo, and implausible physics. Adding to this, the first citation that I found was incorrect. (It identifies the source as "Baltimore Sun, 9/18/2000", but it was actually 9/15/2000.)

However, I did get a reply from the author of the report (Dan Rodricks, columnist). He was very kind and sent me the entire text. Unfortunately, when I asked him for the source of the story, he wrote, "Do some legwork. Contact the Maryland DNR police." The Maryland DNR police have not responded to my query. Right now, I don't know if the incident actually happened, or if the picture is actually from the incident. (It could be an artist's recreation, a sanitized photo, or something else.)

In any case, the picture is fake, the detection algorithm definitely does work, and all of this is very cool. (As an aside, copymove.c took 20 minutes and found some of these matches when using a threshold of 1. My tool took 18 seconds and found many more matches.)

The diary entry at the Internet Storm Center had great timing today. The ISC pointed out that brute-force SSH attacks are on the rise.

As it just happens, some of my associates found out today that their external server was not allowing anyone to login. The cause? The Secure-Shell server was denying all connections due to too many failed login attempts. While this meant that nobody could login (a denial-of-service), it did nothing to compromise the host, expose any data (not that there was any data to expose; this wasn't that kind of system), and the DoS did not prevent the rest of the system from functioning properly.

The default installation of the SSH server (sshd) sets in /etc/ssh/sshd_config the following parameter: MaxStartups 10:30:60. As the man page says:

sshd will refuse connection attempts with a probability of "rate/100" (30%) if there are currently "start" (10) unauthenticated connections. The probability increases linearly and all connection attempts are refused if the number of unauthenticated connections reaches "full" (60).

Or in plain English: if there are too many simultaneous connections trying to log into the system (like from a botnet trying a brute-force login attack), then the server will block all connections.

As network protocols go, SSH is one of the best. I know of nothing outside of time-based profiling that can compromise an SSH connection. The brute-force attack is one of the few vulnerabilities, and it really attacks poor user accounts and not SSH itself. However, there are many things you can do to better reduce your risk profile.

My #1 advice? Change the port number for SSH! While internal system can use the default ssh port (22/tcp), external servers should use some other high-order port number.

I suggest using the ISC's "port/ip lookup/search" to find something not heavily scanned. For example, SSH is being scanned at a rate of about 100,000 targets per day. That means, if you run sshd on port 22/tcp, then you are likely to be discovered and attacked. In contrast, port 34921/tcp is being scanned at a rate of 4 to 9 hosts per day. Running the external sshd on 34921 will lower the likelihood of discovery. And even if it is discovered, the likelihood is really good that the attacker will not probe to find out what is running on that port. (How did I come up with "34921"? I just made it up. Choose any number between 2000 and 65535 and see if it isn't being heavily scanned.)

While moving the port is security-by-obscurity, it will significantly cut down on the number of blind attacks.

My #2 advice is to download the source code for the latest SSH release. Edit sshd.c and change the string identifier. Normally when you connect to port 22 (`telnet localhost 22`), you see a string that lists the operating system. Why? Who knows... but it isn't very secure to tell attackers what they are attacking. I usually change it to simply say "SSH-2.0-SecretSSH" or some other operating system, like "SSH-2.0-OpenSSH_3.1p1 Debian-8". (Why give no information when you can give misinformation!) The minimum needed for the protocol to function is "SSH-version-string".

if ((options.protocol & SSH_PROTO_1) &&

    (options.protocol & SSH_PROTO_2)) {

        major = PROTOCOL_MAJOR_1;

        minor = 99;

} else if (options.protocol & SSH_PROTO_2) {

        major = PROTOCOL_MAJOR_2;

        minor = PROTOCOL_MINOR_2;

} else {

        major = PROTOCOL_MAJOR_1;

        minor = PROTOCOL_MINOR_1;

}

snprintf(buf, sizeof buf, "SSH-%d.%d-FakeSSH FakeOS\n", major, minor);

Beyond security-by-obscurity comes the standard "real security" advice:

• Disable remote root logins. (This is the default, but some people enable it.)
  
• Disable logins without passowrds. Every account should have a password.
  
• Restrict remote logins to accounts that need it. This can be done using groups or listing specific users in the sshd_config file.
  
• Enable public key authentication. Multi-part authentication is best.
  
• If possible restrict remote logins by IP address. For example, if remote users should only be coming from your subnet, then restrict access to your subnet. (I prefer to do this in iptables rather than in sshd_config.)
  
• Consider installing DenyHosts to mitigate brute-force attacks.

For any programmers out there, there are other fun things you can do:

• Alter the SSH protocol. For example, swap the values of SSH2_MSG_IGNORE and SSH2_MSG_KEXINIT in ssh2.h. This way, only your client can talk to your server. (For even more fun, alter the key exchange computation!)
  
• Implement your own SSH authentication system. For example, I have a system that displays a random encoded string that must be decoded and appended to the password -- and you have 10 seconds to do it! Sure the protocol is simple... if you know it!
  
• Configure a knock-knock protocol for enabling sshd.

Between moving the server's port (so blind attackers won't find the server), restricting who can connect, and limiting the type of clients that can connect, you'll be much less vulnerable to brute-force attacks.

Every family has their traditions for Mother's Day. Some let mom sleep in, while others wake her up with breakfast in bed. Families may give cards or flowers, and kids may assist with household chores. My neighborhood has a different annual tradition: Wake her up with motorcycles!

In our neighborhood, Mother's Day starts the annual "Run For The Wall" motorcycle ride. This year, a group of twenty bikers met at 7:00am. They will be riding from Colorado to California and then to the Vietnam Memorial in Washington, D.C. on Memorial Day, before returning home safely.



In case you have not heard of the Run For The Wall:

Mission Statement: To promote healing among ALL veterans and their families and friends, to call for an accounting of all Prisoners of War and those Missing in Action (POW/MIA), to honor the memory of those Killed in Action (KIA) from all wars, and to support our military personnel all over the world.

Our local group starts without about 20 riders, but then they will join up with other groups. It won't take long before they form a pack of 500 to 800 bikes. In about two weeks, they will reach Washington DC with a few hundred thousand bikers!



Having a large group of riders start in our neighborhood every Mother's Day is always a special event. Although they try to keep it quiet (as the pack leader said, "Since this is a residential area, please keep the RPMs down if you have loud pipes."), there are 20 bikes and you can feel the noise. Someday I hope to be in DC on Memorial Day -- if this is what 20 bikes sounds and feels like, I can hardly imagine 300,000.

This morning, we had neighbors come out at 7am to stand in the 33-degree cold and wave as the bikers rode out. Many people shouted words of encouragement, but nobody was funnier than my octogenarian neighbor who came out in her blue robe and slippers. This little old lady shouted out: "When you get to DC, kick George Bush's ass!"



Watching them ride off is very emotional. It is a combination of entertainment, surprise, sadness, and happiness, but most of all: pride. I wish them a safe ride to the Memorial, and back home. You have our support and we will not forget.

Currently, the Democratic party is split between two contenders: Clinton and Obama. Meanwhile, McCain is running uncontested for the Republicans. So, why is McCain still screwing up? His most recent mistake concerns Carly Fiorina. Carly is currently McCain's economic advisor -- ironic since she has a habit of driving companies into the ground. But now, Carly has made McCain's short list of Vice President candidates!

Granted, Carly is "one of the nation's best-known business leaders". However, let's look at what she is best known for, starting with her list of positive accomplishments:

Now let's look at what she is better known for:

• She dropped out of UCLA's law school.
  
• She spun off Lucent from AT&T. During her tenure at Lucent, she was at the center of a series of financial scandals including off-the-books discounts to large customers that nearly sank Lucent. She left the company just as these scandles surfaced.
  
• From Lucent, she went to Hewlett-Packard, where she crippled the company and it still has not recovered. Among her accomplishments at HP, she:
  
  • Introduced "layoffs" to a company that had never had layoffs.
    
  • Forced the HP-Compaq merger, amid a massive lack of support.
    
  • Removed the "Invent" attitude from HP.
    
  • Change the stock symbol from "HWP" to "HPQ". Officially, this was to reflect the merger with Compaq. Unofficially, it was to create a distance with the stock's recent, bad history. (Sites like Yahoo! Finance track stock by symbol. If you change the symbol, then you lose the history.)
    
  • I'm sure most people remember the Enron accounting scandal. Enron inflated earnings by reporting pro forma earnings. This led to a series of financial scandals in 2001 and "pro forma" became the evil word of the day. So, it is no surprise that in late 2001, Carly reported pro forma earnings for Hewlett-Packard. This was met with harsh criticism and she even attacked the mass media. As a result...
    
  • Carly tanked HP's stock for two years. The "History" page at HP even reflects this. Nearly every year concludes with the revenue and number of employees. However, these metrics are abscent for the final Carly years (2003-2005).
    
  • She established a company that spied on the phone records of its own board members! While this hit the news shortly after she left HP, the illegal phone access began in early 2005, when Carly was still running the company. It is reported that Carly repeatedly authorized this type of spying.
    
  • Finally, she left HP after being forcefully ousted as CEO and Chairman.

Now, let's see how Carly Fiorina's performance aligns with the Bush Administration:

• At Lucent, Carly's scandal involved off-the-books discounts to large customers. With the Bush administration, we have preferential treatment to government contractors, like Halliburton.
  
• At HP, the phone records of board members were illegally accessed. The Bush administration is still defending warrantless wiretaps.
  
• Carly tanked stock at Lucent and HP. Bush has headed the country into one of the biggest recessions (slowdowns, etc.) that the country has ever seen. The stock market is falling, inflation is rising, and the price of gas is at an all-time high and still rising.
  
• Carly brought layoffs to Hewlett-Packard. Bush has seen an increase in layoffs around the country.
  
• Carly has a degree in medieval history. George W. Bush has a degree in history.
  
• Carly dropped out of law school. Bush wasn't even accepted into the University of Texas law school.

Regardless of how you feel about the issues surrounding the Bush administration, there is no doubt that these issues have divided the country. Should McCain choose Carly as his running-mate, or even as a member of his staff, there is no doubt that these same issues will continue to divide the country. Things will not get better, and the status quo is clearly unacceptable.

While Carly may be well known, it isn't for her positive track record. And if she can make a mess of Lucent and Hewlett-Packard in just a few years, imagine what she could do with four years in the White House...

Full disclosure: I was an HP employee during the Carly years. I saw her destroy the company.

I was going to save this as part of a paper I am working on, but I feel that the information is too important to save for a later release...

There are many problems with the payment card industry. One of the problems comes from vendors.

Defining Terms

In the food industry, terms such as "Sugar Free", "Low Fat", and "High Fiber" are well-defined. Products that use these terms incorrectly can face fines or legal actions. Not all terms are as well-defined as others. For example, "light" (or "lite") can refer to nutritional content or food coloring.

Even with some ambiguous definitions, the food industry still has defined terms. The same cannot be said for the payment card industry. Terms such as "PCI DSS Compliant" are not clearly defined and regulated. This can lead to misleading information from vendors. As an example, consider Summit Data Communications.

This week, the wireless network vendor Summit Data Communications released a white paper titled "Ensuring PCI DSS Compliance on Wi-Fi Client Devices". This paper provides recommendations for using wireless networks in a PCI-compliant environment. However, many of the recommendations are misleading. For example, the paper states:

WPA and, better still, WPA2 protect all sensitive data, including credit card information, and the networks that house that data. Reliance on WPA or WPA2 is a foundational element of a WLAN security strategy for PCI DSS compliance.

In the PCI DSS (Section 2.1.1), compliance requires the use of "WiFi protected access (WPA and WPA2) technology for encryption and authentication when WPA-capable." In other words, if you can use WPA or WPA2, then you should use it. However, if you cannot use either security protocol, then they are not required. Similarly, PCI DSS Section 4.1 discusses options including SSL/TLS, IPsec, and even WEP. WPA and WPA2 are not a "foundational element ... for PCI DSS compliance."

However, even if you do use WPA or WPA2, neither the PCI DSS nor Summit Data Communications mention the downside of these protocols. While WPA and WPA2 do authenticate clients and employ strong encryption, they are still vulnerable to attacks. Anyone who can receive the wireless radio signal has the potential to be an attacker. Due to this vulnerability, these protocols do not "protect all sensitive data".

Cracking WPA and WPA2

Brandon Teska has an excellent writeup on techniques for cracking WPA and WPA2. In the basic approach, an attacker only has to listen to the key exchange when a wireless client initially authenticates with the WiFi server.

WPA and WPA2 authentication packets are vulnerable to brute force attacks such as dictionary searches and Rainbow tables (pre-computed hash tables). Poor keys based on dictionary words can usually be cracked in minutes. More complicated word variations and short phrases may take days.

Truly random keys may take centuries of computing time. However, if you are a big enough target, then there is a larger incentive for an attacker. Distributed networks can be used to reduce the real-world time for cracking the keys. Moreover, alternate algorithm implementations, such as using FPGAs, greatly reduces computation time.

Since the attack depends on the initial network connection, an attacker has a variety of options. First, they can wait and monitor the wireless network until a new client connects. Second, the attacker can perform an active attack and force a connected client to disconnect. This is accomplished by sending "deauthentication" packets to an established client, or by MAC-spoofing with the established client's MAC address. In either case, the disconnected client will reconnect, ensuring that the attacker can see the authentication's key exchange.

Bad Advice

The Summit Data Communications paper gives many other pieces of bad advice. For example, on Page 4 it says:

PCI DSS requirements are applicable if a Primary Account Number (PAN) is stored, processed, or transmitted. If a PAN is not stored, processed, or transmitted, PCI DSS requirements do not apply.

This advice is misleading and inaccurate. The PCI DSS 1.1 does state in the preface that "If a PAN is not stored, processed, or transmitted, PCI DSS requirements do not apply." However, the PCI DSS version 1.1 was published in September 2006. In 2007, card providers and banks revised the list of who must be PCI compliant. Effective 1-January-2008 (five months before Summit's white paper), PCI DSS compliance became mandatory for any company that performs any kind of payment card transaction, regardless of whether they store the PAN. Failure to comply can lead to steep fines.

Another example of bad advice is seen on page 7, where the recommendation is to "Use a minimum number of Wi-Fi client configurations and, ideally, Wi-Fi radios." The effectiveness of an attack against a wireless network is independent of the number of wireless clients. As long as there is at least one client, the network is vulnerable to the attack. Having more clients does not alter the complexity.

Real Security

As I described in my book, Introduction to Network Security, the correct way to secure a network connection is to use a defense-in-depth approach. For example, using IPsec (either IPv4 with IPsec or IPv6 with security enabled) protects packets at the network layer. Encrypting the data payload (application layer) adds another level of security. Using IPsec with encrypted application data over an open and unprotected wireless network is generally secure enough. Cracking IPsec can take years, and cracking application layer encryption can take even longer (depending on the application). Adding in extra security layers, such as Kerberos and SSH effectively makes the data impregnable. (Any attacker who sees encrypted application data wrapped in SSH, encapsulated by Kerberos, and sent over IPsec will think twice about trying to crack the security. More security protocols directly leads to more protection.)

Regardless of the number of other security protocols, the PCI DSS requires the use of wireless encryption (see PCI DSS section 4.1.1). In a layered security approach, the wireless encryption provides additional security around the already-encrypted data. Using WPA or WPA2 on top of other secure protocols only adds to the security.

The whole concept is that an attacker cannot just crack one system and gain access. Instead, the attacker must crack multiple layers of security. Sadly, the PCI DSS only says that data in transit must be encrypted. It does not explicitly say anything about encrypting the data at multiple layers in the network stack.

Unfortunately, a defense-in-depth methodology is not mentioned by this vendor, nor explicitly stated by the PCI DSS. The paper's assertion is that using this vendor's secure WiFi equipment will make merchants PCI DSS compliant. (The paper is titled "Ensuring PCI DSS Compliance on Wi-Fi Client Devices" and the vendor sells Wi-Fi devices.)

The PCI DSS's other network recommendation, to use a firewall, is independent of the network encryption. If a valid host can get through the firewall, then so can an attacker.

Far from the Summit

With regards to Summit Data Communications: as a wireless network vendor, it is in their best interest to claim that their products can provide PCI DSS compliance. This claim will help them sell more products. However, there is nothing in their products that explicitly provides PCI DSS compliance.

The press release that Summit Data Communications submitted to BusinessWire is titled "PCI DSS Compliance on Wi-Fi Devices? Easy as 1-2-3: White Paper Reveals Three Best Practices to Meet Credit Card Security Requirements". However, this paper is misleading, provides bad advice, and does not ensure PCI DSS compliance even if the advice in the paper is followed to the letter. The three steps recommended by Summit Data Communications are as follows:

• Use a minimum number of Wi-Fi client configurations and, ideally, Wi-Fi radios.
  Unfortunately, more wireless clients does not alter the complexity of a brute-force attack on the authentication system. The entire attack only needs to see one client authenticate with the network.
  
  
• Use WPA or, preferably, WPA2 with a strong EAP type on every Wi-Fi client device.
  WPA and WPA2 is certainly better than WEP or an unprotected network. However, neither are required by the PCI DSS. The PCI DSS does recommend using strong wireless authentication when it is available, but does not require it to be available.
  
  
• Ensure that each Wi-Fi client device includes software that makes it easy to configure the device for non-broadcast SSIDs and WPA or WPA2 with your organization's preferred EAP type.
  This is snake oil. Nothing in the PCI DSS says anything about "easy to configure". And while disabling SSID broadcasts is generally a good idea (and specified by the DSS section 2.1.1), it does virtually nothing to deter attacks against wireless networks.

I certainly cannot blame Summit Data Communications for spreading misinformation. They're just trying to sell products. If their advertising campaign is based on false information and bad advice, then so be it.

Instead, I blame the payment card industry for not better regulating their industry, not defining compliance terms, not enforcing compliance, and not providing better minimal security standards. The PCI industry should provide vendor certification, and ensure that those companies claiming to provide "PCI DSS compliance" really provide compliance.

In case this blog entry's title was too obscure: Wile E. Coyote used highly technical products to try to catch the road runner. These products never worked as intended. The fictional company that created these high-tech gadgets? Acme Corporation. "Acme" is a synonym for "Summit".