Document freedom : what is it and why is it important
Paper. Paper has been with us for thousands of years. With paper, once you learnt how to read a language, you could read any document.
We are now entering the age of electronics. This is a world where most new documents are electronic in form. You cannot read them directly, they are machine readable only and we need hardware and software to do so.
Because we are still at the beginning of this era , we see many and very rapid changes. There are changes in the hardware, in the media and in the form or format of the documents. Even fairly recent documents are at risk of being inaccessible due to changes in technology, for example 5inch floppies are recently used but now difficult to access.
The problem arises when you become dependent on a particular vendor to read a document. Should you need/have to buy a particular machine or licence from a particular vendor to read your phone bill or to file your income tax return?
No.We must be free to use any software we want (including software that we have written ourselves) to handle our documents . This is a basic economic freedom. Any restriction on this is a tax on us and as good Pakistanis we all know that we should avoid taxes :-)
If your vendor needs to increase sales they will release a new incompatible version of their product. For example MS Word 2007 produces documents that are unreadable in MS Word 2000.
If the vendor of your proprietary software decides to discontinue support for their proprietary formats then your documents soon become unusable, unaccesible. This is why truly OPEN standards are important now. This is why we support the use of ODF and the aims of the
ODF Alliance=======================
26 April 2008 is
Document Freedom DayLabels: Economic and Political Security, News Article
I found an interesting website all about VPNs over at
vpntools.com. It has a lot of articles, but mostly at a basic, introductory level.
Labels: News Article, VPN
This is an article on how to break the security on fingerprint enabled 'secure' USB memory sticks. The sticks basic design is insecure.
To cut to the chase:
both sticks use something that's said to be very secure: fingerprint scanning. Then, why did they fail?The answer is simple: the key to the encryption has to be stored on the stick in some way.This is how it works: If you have a program doing encryption with a password as a key, the program doesn't have to know the password itself when not used. You run the program, enter the password, and the password is used to decrypt the info. Close the program and it will forget the password: it's stored nowhere on your computer. It's not needed: you yourself can enter the exact password when you want to have access to your data anymore. But you must enter exactly the password you've chosen: you can't make any mistake like using a capital-A instead of a lowercase one.Fingerprints aren't that precise. If you scan your fingerprint two times, the scans will always be subtly different. Pressure differences, the way you slide your finger over the sensor, interference, loss of skin cells... they all contribute to a certain amount of noise to the picture. You can't encrypt something with that: you need something that never changes. As far as I know, it's not possible to distill from a fingerprint a certain piece of data that never changes, but still has variation enough to make it impervious to brute-force-attacks.So, all systems have to take another route: encrypt the disk with a certain random key and hide that key somewhere together with the fingerprint of the user of the stick. As soon as the stick is inserted, the user is asked for his fingerprint and it is then compared to the stored copy. If they match, the disk is decrypted using the stored key.The problem with that is simple: if the program handing out the key to the decryption routine can be hacked, the hacker can, one way or another, get the key. There's no way around that: the program can access the key and the hacker can access the program: that means the hacker can access the key. There are two ways around this: The first one is not to allow the program access to the key. Truecrypt and other password-based programs do this, but as I explained, it's difficult for a fingerprint-based solution to do this. The other way is: don't allow the hacker access to the program. This would mean embedding a controller in the stick which should do all the fingerprint-comparing itself. While a really skilled hacker could still try and get into the microcontroller, it would be much, much more difficult to get to the data than with a software-based solution. Unfortunately, this solution is way more expensive than a PC-software-based solution.Labels: crypto, Hack, News Article
Feeling insecure about who might be trying to access your RFIDs? Here is a portable firewall from Melanie Rieback to provide a modicum of protection. The project web site is
rfidguardian and the below article is from Ars Technica.
=====================================================================
The RFID Guardian: a firewall for your tagsBy Nate Anderson | Published: May 01, 2007 - 11:53PM CT
Here, there, and everywhere
Don't carry RFID? You might be surprised; the short-range ID technology is currently found in everything from US passports to swipeless credit cards to public transit passes to World Cup tickets to car keys to the building access pass for your office building. A few of the digerati even elect to have RFID implants from VeriChip slipped beneath their skin in order to use them as cashless payment systems.
Much of the information on these chips can be read without exotic equipment, assuming an attacker can get within several feet with a concealed RFID reader. Unfortunately, most tags give users no control over when they respond to queries, and they offer no notification, which means that sensitive data could be at risk in public places.
The solution, for those concerned about such things, has so far been low-tech: smashing the chip with a hammer appears to be the preferred method for passports, but it is technically illegal and could lead to unpleasantness at customs.
A new tool from a graduate student at the Vrije Universiteit in Amsterdam offers the first real-time cloak of protection to users concerned about security, and no hammer blows are required. The RFID Guardian is essentially a firewall that can prevent or allow RFID queries, and can do so on a per-tag basis. Melanie Rieback, the Guardian's designer, describes it as a portable, battery-powered device for personal RFID privacy—but even if you aren't concerned about men in dark sunglasses snatching your passport data, the selective jamming tech in this diminutive device is fascinating stuff.
I had a chance to sit down with Rieback during her recent trip to the United States, and she explained how the device works, what's coming in version 3.0, and why she has no plans to profit from the technology.
"I'm definitely not anti-RFID," she explains. "I think there's a lot of great things you can do with it, but I just think that like any other technology, they need to take security and privacy into consideration."
Here's how the RFID Guardian gives that power to the people.
And I need this... why?
RFID got its start as an antitheft tool that soon became important for inventory management. Using RFID chips, it was suddenly simple for shippers to know how many pallets were in a trailer, and retailers could see how many razors were on a store shelf without keeping employees all night to do inventory. RFID received a massive boost when Wal-Mart required RFID tags to be used by all of its suppliers.
Because such commercial deployments emphasize cost over security, most tags still have no access controls, so grabbing a tag's information is relatively simple. Some specialized tags do employ basic cryptography, but this is not always robust. When researchers looked into the encryption found in the ExxonMobil SpeedPass, for instance, the algorithm turned out to use a 40-bit key and was cracked easily by a brute force attack. Tags with stronger cryptography tend to be prohibitively expensive, and thus are not often used.
As the tags showed up in increasingly sensitive applications, security became more of a concern—at least to researchers and privacy advocates. Rieback was one of those people. As a graduate student searching for a Ph.D. dissertation topic, she spent eight months reading computer science research papers and discovered that the number of published works on RFID security could be counted on both hands. "It became painfully obvious that there was a deficiency in the area of RFID, and there is so much work to be done," she says.
So Rieback turned herself into one of the foremost academic authorities on RFID security and went on to develop the first RFID virus as a proof of concept. That got the industry's attention. As Rieback tactfully puts it, there was a "mixed reaction" that even included some personal attacks. But other companies approached her team for consulting assistance within days of publishing the paper.
After doing her part to publicize these security shortcomings of many RFID implementations, Rieback moved on to the RFID Guardian project, which would give people a measure of control over their tags. It became her Ph.D. project, and when she finalizes the next version in the next eight months or so, she should earn her doctorate. Even when that happens, though, she has no plans to drop the project. "I think this is important enough that we should finish it," she says. "We should get it out there."
Eventual plans call for the Guardian to be incorporated into cell phones and PDAs, but the current model is a pocket-sized device that runs on its own battery and provides a circular 1m field of control over RFID tags, jamming any tags that the user does not want read. It sounds simple, but the technology behind it is surprisingly complex—complex enough that the current model uses what Rieback refers to as a "beast" of a CPU, an Intel XScale PXA270. Here's what all that power is for.
Guts and boltsThe Guardian has four basic components: an RFID reader, a radio transceiver, an XScale processor with flash memory, and a power source. Rieback has implemented two common RFID protocols in software (ISO 15693 and 14443), both of which operate at 13.56MHz. Passive tags using these protocols can be read from up to one meter away; higher-frequency tags and those with an active power source extend much further.
The Guardian polls all the tags in its vicinity, along with all queries that might come from other RFID readers. Whenever the Guardian detects a query, it looks up the requested tag's ID number in its internal Access Control List (ACL). The Guardian currently has no external interface for adjusting the ACL in the field, but it does have an RS-232 port for a connection to a PC, which can then be used to update the ACL.
Entries in the ACL can tell the Guardian to prohibit access to a specific tag, or to allow it, or to allow it only to specific readers. The Guardian needs to do this lookup quickly, since it must make a decision about whether or not to jam the tag's response within 320.9µs—the amount of time between the RFID reader's request and the beginning of the tag's transmission back to the reader.
Actually, the Guardian has even less time than this, since 23µs are needed to wake up the software thread that monitors the receiver and another 5µs are needed to to fire up the transmitter before sending a jamming signal. That leaves only 292.9µs for the Guardian to decide about jamming.
This is where the "beast" of a processor comes in handy. In tests, the 520MHz XScale processor looked up a tag's ID number in the ACL in far less time than this, even when the ACL contained hundreds of entries and the sort algorithm was unoptimized.
If the tag in question in supposed to be blocked, the Guardian then jams the tag's response. RFID tags use an anti-collision protocol (called "Slotted Aloha" in this case) so that their responses do not overlap with those from other tags in the area. The system recognized by the Guardian uses 16 timing slots to transmit responses; the tag chooses a slot after running a XOR function on the reader's anticollision mask and the tag's own ID number. The Guardian does the same calculation in order to know which time slot needs to be jammed.
When the time slot comes up, the Guardian generates a relatively massive burst of noise in the two sideband channels used by each tag for data transfer. This is easy to do, since most tags are inductively-powered and are therefore weak; the battery-powered Guardian simply swamps their response with noise. The anticollision system goes on to vary the time slot over the next few query rounds, hoping to find a clear channel to the tag—but the Guardian blocks them each time until the reader simply gives up.
Blocking only the time slots belonging to a specific tag can reveal the presence of that tag to a canny attacker, though, so the Guardian also creates a few collisions when the requested tag isn't actually firing. As Rieback puts it, this "throws in some chaff with the wheat."
Because all of this activity must take place in real-time, the Guardian uses the open-source e-Cos Real-Time Operating System to handle low-level tasks for the Guardian. The software that runs on top of the OS consists of device drivers for the RFID hardware, protocol stacks for various RFID flavors, and data storage libraries. The complete code is 12,694 lines long; for those who want to see it in operation, the project
web site contains high- and low-resolution videos that illustrate how the jamming system works .
Of "kill queries" and DOS attacksThe Guardian provides real-time protection of RFID tags, limiting access only to trusted readers; it can also keep all tags blocked until the user switches it off. But there are a few things it can't do.
One of the most important limitations of the Guardian stems from the way it works. The device can't block queries, only responses. This normally is no big deal, but some RFID tags can respond to special "kill queries" that can permanently disable a tag. The Guardian cannot jam these queries.
The most likely active attack against a device like the Guardian would be a denial-of-service attack that attempts to overload some part of the device—likely its limited radio bandwidth or flash memory capacity. Simple tweaks to the code prevent the Guardian from locking up in most of these situations, though, and attacks against the radio bandwidth would also confuse the tags, which depend on precisely-timed signals.
So despite its limitations, the device looks like a powerful new privacy tool. But will the technology be used by black-hat hackers, especially since the libraries and protocol stacks will be open-sourced? "Of course," says Rieback, but notes that if she doesn't build such a device, others will. The hardware in question isn't even particularly complicated; she just happens to have put it together first.
"There aren't that many privacy-enhancing technologies out there for RFID right now," she says. The Guardian provides one of the first, but it also sends an important message to industry: these tags are not as secure as you think. Tag jamming and spoofing, both of which the Guardian does, are possible with off-the-shelf components. Security needs to be taken more seriously.
Guardians of the futureVersion 3.0 of the device is already being drawn up in Rieback's Amsterdam lab. High on the list of priorities for the new design is a more modular design where the analog electronics would be contained on plug-in baby boards that could be easily removed and altered. That's because the v2.0 Guardian had everything soldered to a single board; when Rieback had a problem with impedance matching, "it was a pain in the butt to try and fix it."
The new version also features an upgraded interface that allows that Guardian to be controlled using Bluetooth and a custom Java applet designed to run on cell phones and PDAs.
Once the design is complete, the board will be professionally produced and then offered—at cost—to the public.
Getting the tech incorporated into cell phones and PDAs would be the next step, though Rieback notes that this would require the design and production of a custom chip, and that she has neither the time or facilities to do that at the moment. "We're taking it one step at a time," she says.
But for a grad student, she's already taken quite a few important steps and produced the only functioning RFID tag protection system. The project has now swollen to include 15 people, three of them full-time employees. Future versions of the Guardian will include more protocols and different frequency ranges, but the basic tech is already in place and working—putting it ahead of most similar projects.
So put away the hammers; if you're worried about the privacy implications of insecure RFID implementations, you'll soon be able to take back a measure of control.
Labels: Firewall, News Article, Wireless
Cyber-mobsters drop DoS attacks
Extortion technique no longer profitable, say experts
Shaun Nichols in California, vnunet.com 27 Apr 2007
The practice of holding websites hostage under the threat of denial-of-service (DoS) attacks is declining, according to security researchers at Symantec.
DoS attacks are carried out by botnet operators using armies of remotely controlled PCs to flood a site with traffic and information requests. The attacks can cause sites and web services to run slowly or shut down altogether.
Criminals use the attacks to extort money from organisations by launching a first DoS attack and then threatening to launch further attacks unless the company pays up.
The tactic has recently drawn the attention of legislators, who passed laws last November allowing for tougher punishments for the crime.
Symantec said that it has seen a steady decline in the number of reported DoS incidents in the past six months, and believes that much of it is due to the inefficiency of the practice.
The problem for the criminals, according to Symantec security engineer Yazan Gable, is that the brute-force attacks are often costly and inefficient for the botnet operator.
"Whenever a botnet owner carries out a DoS attack they run the risk of losing some of their bots," Gable said in an article for the company's security response blog.
"This could happen either because an attacking computer is identified and disinfected, or simply blocked by its ISP from accessing the network.
"Furthermore, if the botnet owner is not careful they could lose their entire network if their command and control server is identified."
Another problem for botnet operators arises when the victim calls the attacker's bluff and refuses to pay.
"Since the target has refused to pay, it is likely that they will never pay. As a consequence, the attacker has spent time and resources on a lost cause," wrote Gable.
The security engineer added that the drop in DoS extortion may also be due to the increased use of botnets to deliver large-scale spam mailings.
Gable noted that the drop in DoS attacks has coincided with a
dramatic rise in spam volumes, suggesting that the lower-risk, more lucrative spam market may be luring botnet owners away from the DoS attack business.
Labels: Botnet, DoS, News Article, Spam
Mar 29 2007
Nikolay Grebennikov
'Keyloggers, phishing and social engineering are currently the main methods being used in cyber fraud.'In February 2005, Joe Lopez, a businessman from Florida, filed a suit against Bank of America after unknown hackers stole $90,000 from his Bank of America account. The money had been transferred to Latvia.
An investigation showed that Mr. Lopez’s computer was infected with a malicious program, Backdoor.Coreflood, which records every keystroke and sends this information to malicious users via the Internet. This is how the hackers got hold of Joe Lopez’s user name and password, since Mr. Lopez often used the Internet to manage his Bank of America account.
However the court did not rule in favor of the plaintiff, saying that Mr. Lopez had neglected to take basic precautions when managing his bank account on the Internet: a signature for the malicious code that was found on his system had been added to nearly all antivirus product databases back in 2003.
Joe Lopez’s losses were caused by a combination of overall carelessness and an ordinary keylogging program.
Full article
hereLabels: Backdoor, News Article, Social Engineering, Trojan
Web Application Auditing Over LunchMarch 22nd, 2007
By Dr. Johannes B. Ullrich
Version 1.0
Web applications are frequently the Achilles heel of a network. A Web application has to be accessible to all of your customers. Ports 80 and 443 have to be open to the world to provide ubiquitous access to the Web application. On the other hand, a full-featured Web application is connected to a corporation′s database storing customer, order, and pricing information. In short: A Web application is the shortest path for an attacker to take to reach the organization′s crown jewels. Securing Web applications is critical and not easy. This paper outlines some simple steps to audit the security of a Web application. Sadly, while this audit is simple and incomplete, a lot of applications will fail the test. A more comprehensive audit will include source code reviews and more advanced techniques to circumvent security measures.
NOTE: You will need WRITTEN permission from your company to perform this audit. Failure to obtain such permission may get you fired, prosecuted, or worse: your GIAC certifications may be revoked.
First StepsDon't forget the obvious. A quick portscan with nmap may reveal an unprotected VNC server or a database server with no password. Any penetration test should start with a quick portscan, likely followed by a vulnerability scan with a tool like Nessus. The use of a more Web-specific scanner (like Nikto) will save you a lot of tedious work. Nikto, in particular, is good at scanning for common problems like default installations of vulnerable tools, outdated versions, and left-over backup and configuration files.
ToolsBefore we get started, let's talk about some tools. In order to perform your audit, you need appropriate tools to attack the application under test. You already have the most important tool for auditing Web applications: a browser. If you use Firefox, you will be able to use a number of free toolbars that will make it much easier to launch the attacks outlined below. We recommend the following plugins:
Web Developer toolbar (https://addons.mozilla.org/firefox/60/) A Swiss Army knife-like extension every Web developer should have installed. For our purposes, the important feature is the ability to modify forms on the fly to remove some of the restrictions imposed by forms. For example, you are able to enter strings beyond the designed length, or you are able to edit locked fields.
Hackbar (https://addons.mozilla.org/firefox/3899/) Nice tool to decode Base64 and URL Encoding. It is also helpful in obfuscating SQL injection attacks.
SwitchProxy Tool (https://addons.mozilla.org/firefox/125/) If you decide to use a proxy server like WebScarab, Switch Proxy allows you to quickly switch proxies.
Add N Edit Cookies (https://addons.mozilla.org/firefox/573/) The Add N Edit Cookies cookie editor will allow you to edit cookies on the fly. This tool gives you one less reason to require a full proxy server to intercept requests.
Tamper Data (https://addons.mozilla.org/firefox/966/) This extension, much like a proxy server, will allow you to intercept requests and responses. Either may be manipulated at will.
These toolbars allow you to do most of what is required to quickly test a Web application. However, for some of the more advanced techniques, a proxy server can be helpful. Probably the most full-featured free proxy server for auditing purposes is
WebScarab (http://www.owasp.org/index.php/Category:OWASP_WebScarab_Project). The Open Web Application Security Project (OWASP) Web site is also a good resource to learn more about Web application security.
PreparationBefore you start, configure your browser to show hidden fields and comments and to ignore form limits. This will make some of the tests discussed later a bit easier to complete. Here is how to adjust the Web Developer toolbar:
In the Options menu, select Persist Features. This will make your selections stick, so you don't need to adjust them for each new page.
Now move to the Miscellaneous menu and select Show Hidden Elements as well as Show Comments.
In Forms, select Make Form Fields Writeable and Remove Maximum Length. Later, you may want to use the Convert POST to GET function to make it easier to manipulate form content.
As a quick test, start browsing the site you are testing and become familiar with it. You will see yellow exclamation marks within the web page displayed by Firefox whenever there is a comment. The current version of the Web Developer toolbar appears to have a bug in that the hidden fields are not shown all the time. It may be easier to use WebScarab if you find a lot of hidden fields, because WebScarab will make them editable.
In a worst case scenario, you will find things like passwords or account names in comments listed in the Web Developer toolbar. At this point, your quick audit would likely be complete. There is no need to go any further if the goal is just to show that a side is vulnerable.
The AuditWith browser and toolbars ready and armed, we are all set to dive into the actual audit. The steps below are listed in the order in which they are most likely to deliver results, staying with our theme to find problems quickly.
robots.txt: A vulnerability roadmap. The robots.txt file is often misunderstood by Web developers. The file will not protect or hide content. It is only used by well-behaved search engines to avoid indexing content that should not be indexed. A good robots.txt file includes content like image directories or locations that are generated dynamically and do not work if a search engine accesses the page. A bad robots.txt file, on the other hand, will list admin pages, Web logs, and similar locations. Access all the locations listed in robots.txt and see what you find. If, as part of this experiment, you hit a page with Web logs, browse the Web logs for any administrative pages. If they are not obviously named /admin, look for pages hit by only very few hosts. Your quest to prove that the web application is vulnerable may already be over if you find a non-password-protected admin page. For each password-protected admin page, try a few obvious username/password combinations. But don′t spend too much time on it. After all, we only have 1 hour to break the site.
XSS: trial and error. Cross site scripting (XSS) is probably the most common vulnerability. Not all XSS issues are easily exploitable. However, the presence of these errors demonstrates lack of attention to input validation and output sanitation. The most likely place to find XSS is in the search function. Enter a "e;>"e; as a search string and see what you get. In particular, watch for pieces of HTML code that may all of the sudden be visible or for skewed formatting in forms. As a next step, enter ">. Even if you don't see the popup message, try to find the string in the result. See how the application dealt with the quote. As a note, many applications will escape single quotes (′) but not double quotes ("). If you try to inject JavaScript, you may need to use double quotes only. Again, for this 1 hour exercise, we are only trying to find XSS problems. Exploiting them may take a bit more time. More dangerous XSS issues arise if content is stored in a database and not escaped properly if returned. The most likely location for this XSS vulnerability is any mailing or shipping address. Try to set up an account with the Web site, and use > or similar strings as street or city name. These issues are almost always exploitable to retrieve administrator cookies because they retrieve addresses for order fulfillment or customer service.
SQL Injection: trial and error. The procedure to find SQL injection is similar to what we did for XSS. Start by entering a single quote in various form fields. As an indication of SQL injection is going to be possible, you may see a database error returned. Once you have the database error, it should tell you more about the nature of the problem. Some Web sites do a decent job of hiding the error messages. In this case, SQL injection is a bit more tricky. Try to guess a valid, but bad, SQL query. For example if you get an error for page.html?id=1′ , try page.html?id=1%20or%201 and page.html?id=1′%20or′1′=′1 or page.html?id=1-- to see if you still get the error page. This can easily be the most time-consuming part of the audit. If you suspect SQL injection issues, try to use a tool like Paros, which can assist you in finding SQL injection problems. In addition to the obvious quotes, try to use characters like double-dash (--), semi-colon (;) or comma (,). Blind SQL injection, which is frequently necessary if no error messages are displayed, is a more advanced topic and is beyond the scope of this paper.
Cookies and Hidden Fields. Cookies and hidden form fields are just another form of user-provided input. However, a lot of Web developers don't see it that way and treat cookies and hidden fields as trusted data. So, if you are still looking for vulnerabilities, try to inject some single quotes and XSS characters and see what you get. The Add N Edit Cookies toolbar is all you need for this. The Web Developer toolbar will allow you to edit hidden fields that you find.
Sessions. With sessions, you will find developers who are using a standard toolkit, in which case the sessions are likely reasonably secure, or you will find developers using homemade toolkits that are frequently flawed. Take a look at the session ID. Does it look like a long random string? Start playing with it. Remove and add characters. Again, try to add a single quote or XSS. Is the text cleaned up? If your session ID is numeric: Try to replace the session ID with the next number. Also, try and increment the last two numbers by 1 each (in case the last digit is a checksum). Are you able to get someone else's session? At the very least, your session ID should change after you log in. In the best case scenario, the session ID should change on each page view. Webscarab can help with session ID analysis if you need to dive in deeper. Webscarab is a proxy server. It can be configured to intercept all data passed to the server or to the browser. Before it passes the data to the server or browser, the user can edit the data at will. Webscarab offers a large number of additional features to analyze the content passing between browser and server. The session ID analysis is one of these features. Session ID analysis will graph session Ids collected from the website to make it easy to spot patterns.
Google Hacking. Take a look at Google and check what it knows about the site. You can limit Google's focus by adding a?site:example.comato the search. Strings to search for include: "sql", "error", "password", "cvv2".
Spidering.Run wget -m http://www.example.com to retrieve a mirror of the site. This will cause wget to create a directory called www.example.com. Use grep to find any errors or other odd contents like error messages or comments. This is essentially the same thing the Google search will do, but grep is more complete. Note that Google as well as wget obey robots.txt. At this point, you are likely a bit more familiar with the application you are testing. Google can help to find default locations for configuration files (e.g. global.asa) or administrative consoles for the particular Web application.
ConclusionThese tests will only find obvious problems and are less likely to find more complex issues. We totally neglect some common problems like response-splitting or secondary SQL injection issues, and we spent little time on actually exploiting these problems. See this 1 hour audit as a due diligence test that should be done periodically. It is also a great learning tool for Web developers. By involving them in such an audit, they will find out more about how easy it can be to exploit some of the problems the audit identifies. Have them actually perform the test or perform the test with them. If they are part of the audit team it will be much easier to explain what is going on and they won't see the test in a confrontational manner.
In order to do a more exhaustive test, it is highly advisable to use the source code for the Web application. Again, this is easy if you have cooperating Web developers. With source code, it is much easier to validate a problem and estimate its impact.
We did not say much about how to defend against each of these tests. However, the overall approach should not be to fix vulnerabilities one at a time as they are found, but to develop strategies and procedures that will prevent these vulnerabilities in the first place. It is imperative for a Web application to create a library of authentication, access control, session handling, and validation functions that are used consistently throughout the application.
Referenceshttp://www.owasp.org: Open Web Application Security Project.
http://www.cgisecurity.com/articles/xss-faq.shtml: The Cros Site Scriptin (XSS) FAQ
http://www.spidynamics.com/papers/SQLInjectionWhitePaper.pdf": SQL Injection White Paper
http://www.robotstxt.org: The Web Robots Page
http://johnny.ihackstuff.com: The Google Hacking Database
Many thanks to the ISC handlers, in particular Jason Lam, for the discussions that led to this paper.
Labels: Attack Tools, http, News Article
An interesting analysis of the costs (to end users) of protecting (media companies) intellectual property from their customers.
This includes:
Disabling of Functionality
Decreased Playback Quality
Denial-of-Service via Driver/Device Revocation
Decreased System Reliability
Increased Hardware Costs
Unnecessary CPU Resource Consumption (to quote "In order to prevent active attacks, device drivers are required to poll the underlying hardware every 30ms for digital outputs and every 150 ms for analog ones to ensure that everything appears kosher. This means that even with nothing else happening in the system, a mass of assorted drivers has to wake up thirty times a second just to ensure that… nothing continues to happen (commenting on this mechanism, Leo Laporte in his Security Now podcast with Steve Gibson calls Vista “an operating system that is insanely paranoid”).
Unnecessary Device Resource Consumption
Read the entire
article here.
Labels: Microsoft, News Article
As with any new Microsoft product, OneCare Anti-virus has problems. However the competition should not take this to mean that they can rest easy. Microsoft has the staying power and determination to develop their products into world beaters. Once MS has come into a market they will keep spending money until they dominate it.
Best quotes from this article:
"Usually Microsoft doesn't develop products, we buy products. It's not a bad product, but bits and pieces are missing,"
"OneCare is a new product — they shouldn't have rolled it out when they did, but they're fixing the problems now,"
"Microsoft is not a security company. Security is important, but it's just a little part of Microsoft,"
Ouch.
===================================
Microsoft: OneCare should not have been rolled outTom Espiner ZDNet UK
Published: 16 Mar 2007 13:03 GMT
Microsoft has said that its OneCare security suite has "a problem" with the underlying antivirus code, and admitted that security is just "a little part of Microsoft".
Speaking to ZDNet UK exclusively at the CeBIT show in Hanover, a senior manager for the software giant said that its consumer security product is far from perfect and that pieces are actually "missing".
OneCare has been dogged by controversy since its launch last May. Signs that the software was not up to scratch came earlier this month when OneCare failed to achieve certification in an independent test of security products. Shortly before that, it emerged that the product did not sufficiently protect users of Microsoft's Vista operating system against malware.
But the latest and most serious problems arose in March this year after the product mistakenly quarantined and even deleted Outlook and Outlook Express files for the second time.
Microsoft apologised for the problems and has issued an update that has now been automatically pushed out to OneCare customers, to halt the false positive identification as malware of Outlook .pst and Outlook Express .dbx files.
Asked about these problems, Arno Edelmann, Microsoft's European business security product manager, told ZDNet UK on Thursday that the code itself has pieces missing.
"Usually Microsoft doesn't develop products, we buy products. It's not a bad product, but bits and pieces are missing," said Edelmann.
The problem lies with a core technology of OneCare, the GeCAD antivirus code, and how it interacts with Microsoft mailservers. According to Edelmann, the Microsoft updates and mailserver infrastructure do not harmonise.
"It's a problem with the updates, and it's a problem with the implementation," said Edelmann.
If mail is received from a server running Exchange 2007, users are unlikely to encounter problems. However, if mail is received from servers running Exchange 2000 or 2003, the likelihood of quarantining is high, said Edelmann.
"OneCare is a new product — they shouldn't have rolled it out when they did, but they're fixing the problems now," said Edelmann.
According to the security manager, security is only a small part of what Microsoft does, suggesting it does not have as much security expertise as established security vendors.
"Microsoft is not a security company. Security is important, but it's just a little part of Microsoft," said Edelmann.
Security vendor Kaspersky said that it was not acceptable for two Microsoft products — such as OneCare and Exchange 2007 — to be incompatible, especially as Microsoft has market dominance.
"Microsoft, welcome to our business," said Eugene Kaspersky, the founder of the company. "All in all it's a bad thing. It's not acceptable for Microsoft products to do that. Microsoft dominates the market. If they do that it creates a big noise, many affected people, and happy lawyers."
This is not the first time Microsoft has had a problem with OneCare and Outlook. In January OneCare also erroneously quarantined Outlook files. However, Kaspersky said that although the problems then and now were the same, the cause of the problems in January was different.
"They fixed the first false positive, and now they have the next one," said Kaspersky.
Kaspersky said that false positives are not just a problem for Microsoft, but for the whole antivirus industry. He said that about 1 percent of Kaspersky records were false positives, but they were almost totally stopped by the company's test robots. He added, however, that sometimes false positives are released by Kaspersky.
Microsoft purchased the Romanian GeCAD company in 2003.
Labels: Anti-Virus, Microsoft, News Article
More and more businesses are experimenting with Bluetooth advertisements. In doing so they are doing consumers a disservice - because it is almost impossible to tell where a Bluetooth message comes from, they are smoothing the way for the distribution of mobile viruses.
In the age of fast mobile communication, marketing is also becoming ever more flexible, so it comes as no surprise that advertisers are attempting to make use of Bluetooth. After all, Bluetooth opens up new ways of sending advertising messages to mobile phones and PDAs. These adverts can include images, videos, java games or applications, which can be transmitted to passers-by at trade shows, exhibitions, airports and stations or in the vicinity of restaurants or shopping centres.
full story
hereLabels: News Article, Symbian, Virus
ElcomSoft released an Enterprise version of its award-winning Advanced PDF Password Recovery software. This program makes it easy to remove both password encryption and usage restrictions from Adobe Acrobat PDF files. APDFPR Enterprise now comes with support of all Adobe Acrobat versions (up to 8.0), including those that use AES encryption, and super-fast guaranteed recovery of PDF files with 40-bit encryption using state-of-the-art "time-memory trade-off" technology.
With the increasing popularity of PDF formatted file, comes an increasing number of problems which occur when authors forget the passwords to their source documents. ElcomSoft has revised version 3.0 of all three editions of its Advanced PDF Password Recovery software (Enterprise, Professional, and Standard) to allow the seemingly impossible recovery of passwords for these documents. This software package handles both owner and user passwords used to protect PDF documents. The latest addition to ElcomSoft's family of password recovery software allows business managers to recover lost and destroyed passwords. It also helps in dealing with employees who, intentionally or unintentionally, are unable to edit and print password-protected PDF files.
APDFPR is also a state-of-the-art computer forensics tool that could be used by law enforcement, military and intelligence agencies to open secure documents. PDF documents protected with access restriction passwords can be decrypted instantly, allowing full access to the document. For documents with "user" passwords (that could not be opened without that password), the program blazes through brute-force password attempts at a rate of a few hundred thousand passwords per second!
The code has been effectively optimized for most CPUs such as Pentium II/III, Pentium 4, Intel Core/Core 2 (Duo) and Athlon. More sophisticated methods are available, such as applying all words from a dictionary. ElcomSoft's website has dictionaries for more than 20 different languages, from English to Swahili.
Even if the above methods fail because the password is too long and complex, the program runs a special key search attack which gives a 100% success rate on files with 40-bit encryption (used in all Adobe Acrobat 4 files, and most files from more recent versions). This may take some time to run, but is well worth the time if your document is very important. If you have a dual processor system, APDFPR takes advantage of it to double the performance of this software.
On modern systems with Intel Core Duo CPUs, the document can be recovered in maximum 3-4 days, regardless of the password length and complexity. And in APDFPR Enterprise, ElcomSoft has introduced a new "rainbow attack" subsystem -- it is shipped with a DVD that contains special pre-computed hash tables that will allow you to decrypt most (an estimated 99.6 percent) PDF files in just minutes instead of days, even on slow computers.
Advanced PDF Password Recovery Enterprise costs $999(US) for a single-user license and includes express delivery worldwide. Professional and Standard versions, with reduced feature sets, are available at affordable prices. The program runs under Windows 95/98/Me/NT4/2000/XP/2003/Vista.
Labels: Attack Tools, News Article
Windows insecurity leads to the creation of botnets which are used to send oceans of spam to everyone. This is about a proposal to try to stem that tide. Of course if spam is stopped the botnets will still be there and used by the criminal gangs for other purposes. Ed.
=====================================
Spam storm needs ISP action, urges security chiefBy Will Sturgeon
Published: Wednesday 14 March 2007
Ispa, the UK's internet service providers' association, will today make a presentation to the House of Lords science and technology committee on computer security and spam.
The session, which follows the submission of a written response, coincides with claims the number of compromised PCs – known as botnets – in the UK has tripled over the past year.
And one security expert claims ISPs are still shirking their responsibilities.
These criminals have a very advanced command and control structure.
Speaking about the growing problem of botnets and the deluge of spam they create, David Rand, CTO of security company Trend Micro, told silicon.com: "I absolutely believe this is the ISPs' responsibility. Yet top ISPs still aren't doing anything."
Rand said: "It's not like the ISPs can't tell this is going on. They can see all this on their networks."
Many leading ISPs currently refuse to take measures such as blocking port 25 traffic, a move which Rand claimed would affect very few users sending legitimate email, while blocking the port used to relay email via the internet on compromised machines.
And he expressed doubts that ISPs would ever volunteer such measures to legislators because they fear taking greater responsibility for the use of their networks and the implications of increased operating costs.
A spokesman for Ispa said it understands the majority of spam originates from compromised PCs connected to its members' broadband services - and those of other ISPs - often unbeknownst to customers. But he said it is not the ISPs' lone responsibility to solve the problem, suggesting legislation and end-user education are essential tools in the fight.
The Ispa spokesman told silicon.com: "No ISP wants to tolerate any criminal activity on their network."
He also denied suggestions ISPs have been slow or unwilling to act on the matter. "If there was a flick-switch solution to this, we would have done it," he said.
Trend Micro's Rand told silicon.com the number of infected PCs has tripled in the UK over the past year, according to his company's research.
This means more UK homes and businesses are operating compromised PCs which - as well as sending vast volumes of spam - could potentially be plundered for sensitive data such as passwords or bank details.
Rand told silicon.com one reason for the upsurge in rogue activity on European networks dates back to a major fibre cut between China and Taiwan in December 2006. At that time botnet activity switched dramatically from China to Europe within around six minutes, he said.
Rand said millions of infected machines in Europe were brought online by the criminals who control them remotely, showing not only a vast amount of redundancy built into these criminal networks but also "highly sophisticated" business continuity plans.
He said: "These criminals have a very advanced command and control structure. We've got a real challenge ahead of us to take that down. And we've not managed it yet."
Labels: Botnet, News Article, Spam
When is a backdoor really a backdoor?By John Leyden
Published Thursday 15th February 2007 16:46 GMT
Workplace smoking bans may be good for workers' health, but could open the back door to hackers.
In a recent social engineering test undertaken by UK-based security consultancy NTA Monitor, a tester was able to easily gain access to a corporate building through a back door that was left open for smokers. Once inside, the penetration tester was able to easily bluff his way into a meeting room, claiming the IT department had sent him. Even without a pass, he gained access unchallenged and was then able to connect his laptop to the firm's VoIP network via a telephone connection point.
NTA Monitor technical director Roy Hills comments: "It used to be that companies 'left the back door open' in terms of internet security. Now they are literally leaving their buildings open to accommodate smokers.
"Once inside a corporate building, an attacker can use social methods on employees to gain access to restricted areas and information unless a rigid staff pass system is in place," he added.
Smoking will be banned in all indoor public spaces in the UK in July 2007. In many other European countries, such as Spain, workplace smoking restrictions have already been applied. ®
Labels: Backdoor, Insecurity, News Article