Increasing Public Awareness
People are starting to get the message that there are risks involved with using public Internet connection terminals, such as those at Internet kiosks found at airports, Internet cafes, and public terminals at education institutions. Recently, a member of the Australian Federal Police's Cyber Crime Unit went on record saying that they were starting to observe more cases of keylogging software being installed in these locations. The basic rule of thumb that should be followed by anyone who is looking at using a public Internet terminal, is to not access any online finance sites, nor to use any sites that require a login / password that you don't want to have compromised. For some people, their webmail password may not be all that important, however, their banking account details are. Unfortunately, some people use the same login / password combination (or same password at least) across multiple sites and online accounts, thus increasing the potential risk that they face. Basically, if you are accessing the Internet from a computer that is not your own, then you should consider that there may be something on the system which could be capturing all of your input. Even your own system is not safe, as many spyware / adware applications now install keyloggers.
A briefing recently released by the UK NISCC appears to have caused a ripple amongst other reporting bodies, with a number rushing to release their own derivative from the NISCC original. The advisory, 08/2005, relates to the growing trend of targeted trojans. What this means is that there are more trojan horse software attacks being specifically constructed to go after a company / government agency / industry group membership. What initially seems strange about the briefing is that there does not appear to have been a specific trigger which prompted the release of the report, i.e. there were no major attacks in the last couple of weeks that were announced. However, there have been continued attacks which have formed a trend, and it is the analysis of this trend which has prompted the release of this information. The initial reporting is suggesting that these attacks are arriving from China, North Korea and Russia, and the sophistication represents either state sponsored actions, or high powered organised crime.
Next week's column will cover in depth the issues surrounding this development, but the continued advice which will defeat this attack is to NEVER open attachments in emails that you are not expecting. If this simple action is followed, then there is little chance of the trojan affecting you (unless other people in your organisation open attachments readily, and thus get infected).
Just recently, it was announced that there have been almost 60 reported security breaches of personal financial information held by US corporations, affecting 13.5 million US citizens, to date in 2005. This figure probably shouldn't shock regular readers of this column, but it does present in a single sentence exactly how many people get affected by this issue. This figure doesn't account for other cases of personal privacy information that has been leaked by companies, which is also significant. The mechanisms for financial information loss include compromise of computer systems, loss of backup tapes, and employee theft. For Americans this is only the tip of the iceberg, as more and more personal privacy, medical and financial data is being sent overseas for processing and storage. In a case from 2003, transcripts of medical records of patients from the UCSF's medical centre were held for ransom by an unpaid Pakistani transcriber, who had been sub-sub-contracted the work from an American outsourcer who had themselves been sub-contracted to the original contractor. The transcriber was threatening to release the contents onto the Internet if they were not paid. This case took place even though the HIPAA Act was in place, supposedly to prevent cases like this. The actual content of that Act does not prevent this from happening, however. It is designed to prevent the sale of information to third parties, but not to prevent the offshoring of information for processing.
Even now, Americans do not have to be notified whenever their information is being sent overseas for handling, and the list of corporations and agencies making use of this is long and scary, including:
- Major financial institutions
- Various State and Federal government agencies
- Accounting firms sending financial data overseas for tax return preparation
- Hospitals that are sending radiology data to India for diagnosis without notifying patients.
There have been several US laws enacted aimed at addressing various privacy related issues, such as Sarbannes-Oxley (SOX), Gramm-Leach-Bliley (GLB), HIPAA, SB 1386, along with the Data Protection Directive (1998) from the EU, and the Data Protection Act from the UK, but the corresponding laws in the countries where the information ends up are lacking in protections for the originators of the information.
This issue is not restricted to Americans with many Western companies engaged in outsourcing various components of their business activities which relate to their customers' privacy data.
As an addendum to the above, in the period between writing and publishing this column further breaches were identified with Equifax Canada (a credit processing firm), and a number of credit card providers. The Equifax breach apparently was the result of misuse of account login details. In fairly pleasing news, only 600 records were accessed, and the affected people have all been given access to a credit alert system to help them identify whether their credit record is being accessed without their permission. The credit card provider breach is more serious, with possibly more than 40 million credit card details from multiple credit card providers exposed. Of that, almost 14 million were MasterCard branded cards. MasterCard claim to have discovered the breach through the use of fraud detecting tools, which identified a third party processing firm, CardSystems Solutions, as the point of exposure. Apparently the breach was the result of a network compromise at CardSystems Solutions, and the firm has been given a limited amount of time by MasterCard to come into line with their security requirements. This single reported breach quintuples the number of people exposed to financial record theft this year, with some unfortunate people who will actually have had their financial record data exposed through more than one of the breaches.
There are many different types of threats to websites and web applications, with continual research being made into new attack techniques and vectors. A recent announcement of a new attack mechanism could have major implications for the way that the Internet, as a whole, works. The newly described attack mechanism is called HTTP Request Smuggling. Before being able to understand what this attack is, it is necessary to understand what an HTTP request actually is.
Network communications are like sending letters in the mail. Let's say that you want to send a multi-volume Encyclopedia from where you are, to your friend in another city. It is possible to send all of the volumes at once, in a massive package, but there are risks. If the package gets lost, then neither you, or your friend, have access to any of the information in the encyclopedia. Large packages also take a long time for delivery, and attract significant shipping costs. A safer solution is to send one or two volumes at a time, allowing them to move through the system faster, and costing less for shipping. If one or two packages get lost, it doesn't mean the loss of the whole encyclopedia, allowing your friend to at least get some information from the rest of it. This is what some protocols use - sending of packages of information (packets) without waiting for confirmation of delivery. This allows them to have rapid delivery of packets, but risks loss of information which can not be retrieved if a packet does not arrive. It can also be sent to multiple addresses at once (a benefit for online gaming). With other protocols, if a packet that was expected goes missing the recipient sends a request to have it retransmitted. For example, your friend doesn't receive volume G of your encyclopedia within two weeks of you sending it, so they send you a message to send another copy of volume G. This slows down the information transfer, as the recipient is expecting packets to arrive in order, and sends queries if packets are missing. As the packets pass through intermediate network points on the journey to your system, the intermediate systems can add the equivalent of postmarks to identify that the package passed through them, and where it is headed next. Sometimes they even make local copies of the information (caching) in order to reduce the time required for retrieval of information - this is why the HTTPS protocol is slower than standard HTTP, as it explicitly disallows caching of content - forcing fresh copies direct from the server for every request.
In normal use, an HTTP request is a single packet of information. What happens with HTTP request smuggling is a second HTTP request is being squashed into the available space of the main request, with this strange double request arriving as a single packet. Using the mail analogy, it is like you sending a volume of your encyclopedia to your friend, but the package also contains a magazine for them that is illegal in their city. This allows the package to get past people who are monitoring the mail, looking for content like the magazine which is not permitted. Similarly, the HTTP request being smuggled is an attempt at getting a request through which would otherwise be stopped by tools such as Web Application Firewalls (proxy based firewalls that are making a resurgence due to the implicit bad security of many online applications). In some respects this is similar to the techniques that some email-borne worms use to get past anti-virus software, by naming their extensions .exe.scr, in an attempt to be identified as a screensaver (.scr), and not the executable file (.exe) which they actually are. The HTTP smuggled request provides the opportunity for a lot of attacks that have been prevented to suddenly become functional again.
The correct way for devices to handle different HTTP packet formats is outlined in RFC 2616, and it is the deviation from these suggestions which is causing the problem with HTTP request smuggling. In one particular example, filling a request with more than a certain number of bytes forces IIS 5 (Microsoft's Internet Server) to process the request as two requests. For it to be successful, the attack requires a second, paired device which processes HTTP requests as well, and exploits the difference in how requests are handled between the two devices. The second device may be a caching device, such as an ISP may use to create local copies of popular web content to save on their outbound bandwidth. In the above example, where IIS is treating an oversized request as two distinct requests, then it can cause the cache server to cache the wrong page for a particular address. This is because the cache server thinks it has sent through one request, while IIS has seen two requests. As a result, the second page that IIS sends back will then be associated with the next request from the cache server. Thus, it is possible that what appears to be http://www.safebank.com in the cache, may actually be http://www.evilbank.com
20 June 2005
Social bookmark this page at eKstreme.
Alternatively, Bookmark or Share via AddThis
Do you like how we cover Information Security news? How about checking out our company services, delivered the same way our news is.
Let our Free OS X Screen Saver deliver the latest security alerts and commentary to your desktop when you're not at your system.
Comments will soon be available for registered users.
Subscribe to our feed.