Just how bad is it? Really bad. I will include links to references so that you can see for yourself the impact and nature of these breaches. Let’s take a look at breaches just in the past few months:

• 1.29 million Sega accounts
• 100 million or more Sony accounts
• Potetnailly the email accounts of over 2,500 companies serviced by Epsilon
• 360,083 bank accounts at Citigroup
• Tens of thousands of accounts at Codemasters
• 25,000 accounts or more at Square Enix
• 280,000 accounts at Honda
• 1.2 million accounts at the Texas Comptroller’s office
• 10,000 credit cards at the St. George Bank in Australia
• 114,000 accounts of iPad 3G owners
• 200,000 accounts or more at Bethesda Softworks
• $500,000 worth of Bitcoin currency
• 8.63 million patients’ information at the National Health Service Facility in London (UK’s largest employer)
• 18,000 Bioware accounts
• 40 million or more RSA SecurID tokens issued by EMC to over 30,000 companies and government agencies, including half of US banks that use SecurID tokens

This list doesn’t even include the numerous other sites and companies that have been attacked in this time period as well: the Labour Party, CNN, Automatic Data Processing (ADP), Lockheed Martin, the US Senate, the CIA, the IMF, PBS, Epic Games, L-3 Communications, Google, and almost 50 others.

The personal information compromised in these breaches include anything from social security numbers to credit card numbers to just email addresses, usernames, and passwords. Covering up these blunders costs companies millions. The case of the Texas comptroller alone has already cost $1.8 million. As one states, 2011 is set to be the worst year ever for security breaches.

The groups Anonymous and LulzSec have been linked to a number of recent attacks, though certainly the network of hackers is much larger. In response to the significant amount of online plundering, legislation known as the Data Security and Breach Notification Act will require companies to notify authorities and customers within 24 hours of a breach. Hopefully, new legislation will be a catalyst to better security policies.

It has been said that the only secure computer is one that is not on a network. Though it is true that most businesses could not sustain sophisticated attacks, like the one on EMC’s RSA, most of the attacks are not sophisticated. The majority of attacks focus on basic loopholes like SQL injection, security loopholes in servers that haven’t been upgraded (Sony), unencrypted data (Sony, Citigroup, etc), and passing data insecurely through URLs (Citigroup).

Even keeping up to date on the latest security breaches on Yahoo Pipes, the Web Hacking Incident Database, or the DataLossDB, can give network administrators insight into what security loopholes to look for in their own networks. To avoid a PR nightmare and a huge cleanup bill, organizations need to take their online security much more serious.

A panel of SC Magazine‘s readers made that determination, giving Sourcefire’s product the most votes.  And that’s an important detail, since it means real-world users, and not just one or two deskbound editors, put their knowledge and experience to work.

Otherwise, an official statement released by Sourcefire explained, “The SC Awards Readers Trust Voting Panel is comprised of security and technology experts from large, medium and small enterprises throughout major vertical markets.  The panel weighs nominees against a number of key criteria including functionality, manageability, ease of use and scalability of the product, as well as the customer service and support provided for it.”

Next, John Burris, the CEO of Sourcefire, outlined his product’s benefits by adding, “Organizations require an IPS that adapts in real-time to defend their networks, users and applications from the latest targeted attacks.  Providing users with increased visibility and contextual awareness, the Sourcefire IPS has the power to stop today’s sophisticated threats, while also offering intelligent automation for simplified and accurate protection.”

More specifically, key Sourcefire IPS features include contextual awareness that is supposed to pick up on common network usage patterns.  Then it can reduce intrusion alerts, block suspicious behavior, and identify users judging from their IP addresses.

So it seems that Sourcefire is on a roll.  (The company’s actually received recognition from SC Magazine under a couple other circumstances in the last little while, was named to the Deloitte Technology Fast 500, and received a five-star rating in the Everything Channel Partner Program Guide.)

Network professionals interested in reading more about the Sourcefire IPS can do so here.  A seven-minute demo of the Sourcefire 3D system is also available in the event anyone really wants to dive in.

The relevant products include Cisco SecureX Architecture, the Cisco Adaptive Security Appliance, and Cisco AnyConnect 3.0.  As for what the upgrades involve, Cisco was quick to explain in a statement.

The company said, “To enable companies to conduct business without borders, Cisco is introducing a new highly distributed security architecture that manages enforcement elements like firewalls, Web proxies and intrusion-prevention sensors with a higher-level policy language that is context-aware to accommodate business needs.”

Then the statement continued, “These next-generation scanning elements are independent of the physical infrastructure and can be deployed as appliances, modules and cloud services.  Better suited to address today’s security challenges, they are designed to know exactly who a user is, what role that user plays in the organization, and whether that user should be allowed access.”

Those could be valuable capabilities, depending on the organization.  Here’s hoping they prove useful to system administrators and don’t come at too high a price.

Dave’s Answer:

You’re right, you’ve become a good network citizen, and just in time. Cities are starting to establish laws that define leeching off another person’s wireless wifi network without permission as an illegal act of theft. How you’d get caught I don’t know, but you can imagine that from the other party’s point of view, it’d be alarming if you were, say, pirating movies and it was their computer network that was tagged!

Like many other computer systems (think Windows Vista, for example) the Mac OS X system is smart and tries to simplify your life by remembering what you’re doing and automate the process subsequently. Sometimes that’s a pain.

What happened was that you have a setting in your “Network” System Preferences that tells your computer to remember networks you’ve joined and prefer them over new ones that it hasn’t seen before. Since your neighbor’s network is now marked as a “preferred” network, well, you know the problem you’re seeing!

I actually had a similar problem in a hotel room during the Consumer Electronics Show recently, where the first night I was there I used the hotel network “Encore – Rooms – Wireless”, but then set up a wireless router so my roommate and I could share a single connection.

In the pull-down menu from the wifi icon on the menu bar, I saw this:

The shortcut to get the right spot to change or forget the preferred wireless network can be reached by choosing “Open Network Preferences…” at the bottom of that menu, which takes you here:

Don’t worry about what network it shows you as connected to at this point. You want to click on the “Advanced” button:

Now scroll down and find the network in question. It’ll be somewhere on the list:

Click on the “-” button and that wifi network is no longer on the preferred list. Also notice that right below it is the option to “Remember networks this computer has joined”: if you want to choose a network each and every time just unselect it.

Done? Just click on the red button on the top left and it’ll ask if you want to save the changes:

That’s all there is to it. Good luck, and thanks for not stealing bandwidth.

Comments

I recently spoke with Statton Hammock, Senior Director, Law, Policy & Business Affairs, of Network Solutions, about invalid WHOIS data and how Network Solutions deals with invalid WHOIS on domain names. asked Mr. Hammock if Network Solutions has you ever suspended or deleted a domain name due to invalid WHOIS information on a customer’s domain. Here is what Network Solutions said:

Yes. Network Solutions investigates all allegations of invalid WHOIS information on domains under our management, and has suspended names when the registrant fails to respond to notices that they are in violation of contractual obligations.

I then asked Network Solutions if they have ever suspended or deleted a domain name due to an email address listed in the WHOIS bouncing or being invalid? Even though the other information on the WHOIS is correct?

Mr. Hammock commented, “If we receive a complaint that a domain’s listed email address is invalid and the customer does not respond to our requests via other channels to correct the data, the name will be suspended. Once inactive, the customer very often contacts our customer service department, corrects the inaccurate information, and the domain name is restored.”

According to Network Solutions, they “believe that some exaggerate the magnitude of the invalid WHOIS data issue. ICANN’s own research has shown that approximately 80% of the registrants studied were located or accurately provided deliverable addresses. In fact, we support the positions articulated by the Registrar Stakeholder Group’s public comments on ICANN’s Draft Report on WHOIS Accuracy (see http://forum.icann.org/lists/whois-accuracy-study/msg00019.html).

Network Solutions also told me that “Network Solutions supports the Registrar Stakeholder Group’s positions articulated in public comments on ICANN’s Draft Report on WHOIS Accuracy, including that “ICANN focus its resources on improving and publicizing awareness of the WDPRS [WHOIS Data Problem Reporting System] rather than commissioning expensive research into further WHOIS accuracy studies which lead to unrealistic and cost prohibitive conclusions.””.

Godaddy also had some comments about about invalid WHOIS . I spoke with Camille Ede, Go Daddy Director of Domain Services. According to Ms. Ede, “When Go Daddy receives a complaint of invalid WHOIS information, we launch an investigation. If we find the WHOIS information to be invalid, we contact the customer and ask him or her to update the information. If the information is not updated within 8 days, Go Daddy places the domain name on “Registrar Hold” (which suspends the domain name). If this happens, a reminder goes out to the customer to update his or her information. On the 15th day, if the information is still not updated, Go Daddy sends another reminder to the customer. The domain name then remains suspended until the customer makes the update.”

Camille also went on to say that “Per ICANN rules, the email address listed in the WHOIS information is required to be valid. Therefore, if the email address is invalid Go Daddy would take steps to suspend the domain name. However, if the email bounced due to a storage issue, then Go Daddy would take additional steps to validate the information before taking any action.”

I specifically asked Camille Ede whether Godaddy considers invalid WHOIS data to be a common problem or is it fairly minor at this point. She said, “Yes, invalid WHOIS data does appear to be a common problem. Go Daddy has a dedicated, 24/7 staff who deal specifically with these types of complaints in order to ensure that our customers are compliant with ICANN requirements.” She also went on to say that “All registrars should follow ICANN’s policy and actively investigate all invalid WHOIS complaints.”

So, at this point, I do believe that invalid WHOIS complaints are still an issue that needs to be addressed. Many domain owners do not take this issue seriously enough and realize that it is very important to keep your WHOIS data up to date: it must be accurate or you risk losing your domain names. In the case of Nikki Craft, it appears that the WHOIS data that was not accurate was an email address. Upon notification that this was the case, Ms. Craft told me that she corrected the issue and provided an up-to-date email address. But the registrar, Gandi.net, took their time to correct the issue; just before the 15th day they released the domain names back to Ms. Craft, who was able to then move the domains to another registrar.

If you have not done so recently, take a look at your domain names’ WHOIS record. Make sure the data is accurate. If it’s not, then correct it. Trust me, it is not worth the hassle to lose your domain names because of invalid WHOIS data. Just ask Nikki Craft.

Comments

As outlined in more detail by Michael Coates on DevWebPro, FireSheep utilizes a program called Winpcap that sniffs the unsecured network for session identifiers. With these session identifiers, FireSheep can pretend to be the user who actually belongs to the stolen session identifier, and thus gains access to the particular website. BlackSheep utilizes the same Winpcap tool. However, BlackSheep instead seeks out evidence of a FireSheep sniffer. Upon finding this evidence, BlackSheep notifies you that there is a FireSheep user on the network.

The key word is "notifies". That’s all BlackSheep is capable of doing. In fact, it is all that anyone is capable of doing as long as these authentication systems are in use. However, as mentioned in any number of articles about FireSheep, this vulnerability only exists on unsecured wifi networks. The path that data typically takes over traditional Ethernet and secured wireless networks does not allow this method of sniffing for session identifiers. BlackSheep can not encrypt or protect your session from getting hijacked – attempting to do so would break the communication between you and the website you’re attempting to access. Thus, in the end, BlackSheep merely notifies – it does not protect.

Despite its failure to block FireSheep from gaining access, BlackSheep is the best solution to protecting yourself from hijacked sessions when using unsecured wireless networks.

Firesheep is a Firefox add-on that does the hacker’s work for any laymen computer user. By sniffing the unencrypted data in wireless networks, Firesheep grabs users’ authentication cookies from thin-air, and then does the necessary work to allow an user to utilize these cookies to gain unauthorized access to website accounts. This process is nothing new, and is just one of the many perils of the unsecured wifi network. Although this plugin appears to have been developed for awareness purposes, it will now give additional people the capability to cause serious harm. Not all sites can be hacked in this way, but a long list of sites that can be are found in the options menu of the plugin. This same options menu allows additional sites to be configured given the proper information.

Although computer users can easily do things to combat these issues on unsecured wireless networks (VPN), there are still a vast majority of unaware computer users that would see no problem with using an unsecured wireless network. Giving the ability to a larger base of evil doers to exploit these computer users is not a good thing. Although sites like Facebook may eventually put in place authentication and session methods to combat this particular security issue, this tool still equips malicious users the ability to do damage now until that point and on other/future sites that fail to make changes themselves.

This also brings up the question: is it a website’s or user’s responsibility to make the connection between them secure? How far does the obligation of either party to foster this secure connection reach?

If you’re not already restricting your workstation’s user rights, then, as my colleague Bryan Young put it, "shame on you." However, there are some scenarios where you may feel that a user needs administrative rights, and this report will certainly encourage you to second guess that thought. These numbers shouldn’t be surprising. Malicious code typically gains access via an opened file or application. Thus, this bad code will run initially as the particular user that accessed the host file. If that user doesn’t have the necessary access to change system files or settings, then it makes the life of malicious code that much more difficult. Obviously, some exploits allowed this malicious code to be run as the administrator, and thus why restricting user rights is not an end-all solution.

For Beyond Trust’s study, they examined the list of vulnerabilities posted in the last years worth of Microsoft Security Bulletins. Going over each vulnerability, Beyond Trust determined whether or not a user’s rights had any effect on the vulnerability. After these tests, the results were broken down to, not only general Microsoft vulnerabilities, but also Microsoft Office and Internet Explorer security issues.

For Microsoft Office, a surprising 100% of vulnerabilities could be thwarted by restricting user access. For Internet Explorer, almost all security holes could be resolved via rights. In IE 8, 100% were fixed, but only 94% of exploits were thwarted when you included all versions of IE. In OS related vulnerabilities, only 53% are mitigated when restricting user access. I say "only 53%", but in reality this is a significant addition of security – potentially doubling your security holes if you fail to restrict user access.

Be advised that though these numbers look really strong, simply restricting user access is not an alternative to staying up-to-date on your system updates and patches. It is, however, a standard practice that should be practiced in all networks, companies, and even personal desktop environments.

Network neutrality is the philosophy that all things related to the network of the internet be neutral, i.e. unregulated. In a completely neutral network, there would be no regulations on what can connect to that network and what data can be transferred across that network. This is the environment in which the Internet has grown in and thrived upon, and thus the environment that most Internet purists strive to maintain.

However, the issue with this idea of neutrality is the Internet is now a vessel of capitalism. Capitalism revolves around the creation and protection of wealth. Therefore, it has become in the best interests of many players in this industry to begin to protect their wealth. An example of where this protection of this wealth clashes against net neutrality is the Comcast and BitTorrent issues. As you may recall, Comcast began capping the rates at which their subscribers could use BitTorrent transfers. In Comcast’s defense, it was a matter of protecting their services for all their subscribers. The bandwidth required to support BitTorrent had never existed previously, and was a strain Comcast was not ready to support. On the net neutral end of things, what gave Comcast the right to dictate what John Q. Public could or could not do on the Internet?

Like many political documents, Google and Verizon attempt to avoid clearly defining their stance on net neutrality. It doesn’t appear that Google and Verizon intentionally sought any policies to hinder net neutrality, but by omitting language to specifically foster net neutrality, they opened the flood gates of opposition. For example, a specific clause of “Network Management” was introduced, encouraging the right of an ISP to “engage in reasonable network management.” This clause was skillfully crafted in such a manner to ride the fence of net neutrality. If this was a legal language that existed when Comcast decided to control BitTorrent usage, the outcome of that situation would not have been any more clearly defined than it was without this kind of guideline.

Google’s position shown in this document, is somewhat of an identity crisis. Google’s lifeline is this free and open Internet. However, Google must work with the other big players in the net to create a framework in which Google’s capital interests can be protected. It will be interesting to continue to follow how and what legal entities get involved. One thing is for certain: despite any goodwill shown by any of the parties involved, network neutrality is at risk.

See also:

http://googlepublicpolicy.blogspot.com/2010/08/joint-policy-proposal-for-open-internet.html

http://googleblog.blogspot.com/2010/08/facts-about-our-network-neutrality.html

While Brandon’s example is great, and Ray Camden also has some details to add, neither example had all the pieces I needed, particularly an example of not just authenticating a Flex application properly with a CFC but also how to log out again (and to jump ahead, simply running a cflogout tag did not work…).

I ended up using a combination of what Ray did, plus roughly the logic Brandon deployed, and added a Flex example to show (like Ray) how to call a secured and an unsecured CFC method. In addtion I added a separate, explicit call to Flex’s setRemoteCredentials() on the RemoteObject class in order to trigger the cflogin logic in ColdFusion’s Application.cfc.

Unfortunately I cannot show you a working example, but I am providing the sources for the Flash Builder project and CF files. Note that my example is set up to run on localhost, and I also specified a compiler flag of -locale en_US -services “services-config.xml” in Flash Builder. My services-config file is also included.

Here’s how I structured my example:

1) Application.cfc: this file contains an onRequestStart which gets invoked on every request to this application, including cfm pages as well as cfcs. It contains a cflogin tag which executes only if the user making the request has *not* yet been authenticated. Inside the cflogin tag is a cfif tag which logs the current user in as long as the necessary credentials are passed in – this happens by using setRemoteCredentials() on RemoteObject in Flex/ActionScript.

2) MyComponent.cfc: This file contains all the remote methods we call from Flex. One method (called ‘normalMethod’) can be called by any user (unauthenticated), another can only be called once logged in, and a third is used to log out (more details on that below).
Access control is provided by using the CFC’s built-in roles attribute. An authenticated user is assigned a role of ‘Client’ and the ‘secureMethod’ in the CFC is locked down by specifying that role.

3) The Flex Application: this is slightly more complex than it needed to be for the purposes of this example, but hopefully it’s not too confusing. Rather than trying to explain the classes in detail please feel free to post any questions you may have in the comments below.

Log Out Issues
In detail, what I was seeing was that I could still invoke the secure method from Flex after I had run the CFC’s logout method and included cflogout tag. Switching directly to the browser – keeping the Flex app open in another tab – did NOT allow me to invoke the secure CFC method, so from that angle the cflogout tag appeared to had done its job.
To really ‘kill’ the user’s session inside the Flex app itself I had to explicitly call setRemoteCredentials again from Flex passing invalid login credentials. I have a theory on what is happening: the logout method does do its job as described and the user is actually logged out, but only until he tries to invoke another CFC method via the Flex app. As soon as that happens, Flex will re-send the previously set credentials (username, password) and re-authenticate the user using the cflogin tag in Application.cfc. This can apparently be confirmed by invoking the CFC method directly using a web browser both after the logout method has been called and then again after another CFC method has been invoked via Flex. Calling it via the browser after invoking logout in Flex results in a failed request, but after the next call from Flex it succeeds in the browser. For that reason I recommend to send a setRemoteCredentials(null, null) if you don’t want the Flex user to be able to call any further methods unless he re-authenciates (bascially logs in again via some sort of login form which re-runs setRemoteCredentials() using valid credentials.

I tried to find other ways for logging the user out and looking through some of the AS sources in Flex, it appeared that ro.channelSet.authenticated may be a good flag for deciding if a user is logged in or not, however it always returned false for me regardless of whether or not the user was logged on… I tried logging the user out via ro.channelSet.logout() as well as ro.logout() but neither function seemed to actually do anything. If you have any idea if and how this is used with Remoting please let me know.

So all in all, keeping the slight caveats above in mind, the combination of CFCs with role based ecurity applied and the setRemoteCredentials() method on the RemoteObject class in ActionScript work well and are easy to implement. Unfortunately the documentation in Flash Builder only covers part of the process, and the CF docs cover another part – the CF side. It takes some work to string both parts together, but once implemented the process works pretty well. Now that I got my head around it I am ready to hook this into my control panel application.

Comments