A big selling point of security on many Linux or Unix systems is the distinction of Execute permissions. A downloaded file will not have the execute bit set. This means that, within a window manager, double-clicking will only attempt to read the file so the desktop system may ask what you want to do with it. Only by either explicitly telling this prompt to execute or by editing the permissions of the file from the command line can you execute this file. In either case this is an explicit action that the user must think about.

However, many distributions of Linux use a standardized .desktop ^[1] file format. These files are often used as menu items or program launcher shortcuts: they have an Exec parameter that can take an arbitrary command string to run when clicked.

[Desktop Entry]
Encoding=UTF-8
Type=Application
Terminal=false
Exec=bash -c "touch ~/haxxored"
Name=Write to an arbitrary file.

Users and developers of these distributions have recently been arguing for re-evaluation of this specification for that very reason: they allow arbitrary code execution without the need for an executable bit set on the file.

This opens up the same vulnerability in Linux systems that had previously been avoided. An inexperienced user used to double click to open might download a .desktop file and try to open it. Even a more experienced user might not realize this issue and (expecting the previously mentioned behavior of simply reading the contents of the file) click on it to see the contents.

Even more troubling is the behavior of these Desktop files when used in the menuing system for many distributions: important system applications often have menu entries in /usr/share/applications. However, menu entries with the same name in ~/.local/share (the user’s local directory) with the same Name option will override the system one! A malicious script (perhaps even started by the exploit above) could shadow the desktop entry from one of the important system applications such as the Synaptic Package Manager. Users are used to typing their passwords at the gksu prompt when clicking on Synaptic so they would do so; now a malicious script has root access to the user’s machine.

Possible Solution

The biggest part of a solution to this problem would be requiring that .desktop files simply have execute permission set. On installation of a normal program this would be a trivial addition, but downloaded .desktop files would not be run. In case of some other malicious script gaining user access, normal users should not be able to override root owned .desktop files (like Synaptic).

These solutions are extremely simple, but they have not been implemented yet due to the desire for compatibility between
different distributions. It may take time for these changes to be made.

^[1] Desktop File Specification: http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html

This change was proposed to combat vandalism. As it is now, a user could maliciously and instantaneously change the content of any article in an arbitrary way. For example, the article announcing the proposed change noted an instance of vandalism where a Wikipedia user vandalized Senator Ted Kennedy’s article to say that he had died after President Obama’s inauguration. According to Wikipedia’s page on Vandalism, the current method of dealing with vandalism is to delete the changes, and possibly take action against the user who posted the changes. A user believed to have vandalized an article could be given a warning, or blocked from making any further edits by an administrator. This current policy still allows the flawed article to be seen (and possibly taken as fact). The flagged revision system would mean that malicious edits might never be seen at all.

Another way to discourage vandalism might be to impose more draconian penalties on users thought to be maliciously altering articles, such as banning both the user and the computer from accessing Wikipedia in the future. This would be too harsh, since foolish edits could possibly be innocent mistakes, and there could be more than one person using a given computer. Another alternative would be to only allow users who are already considered trustworthy to make edits. This would be too restrictive, and does not allow for as broad a community of editors as Wikipedia has currently. The only methods that seem to allow for a reasonable amount of freedom for users are the current reactive system, and the flagged revision proposal.

With the proposed system, Wikipedia is trying to ensure the correctness of the content of its articles. Vandalism could potentially hurt users by spreading false information. This is especially troublesome for people such as this author, who generally trusts Wikipedia to be accurate. Vandalism also harms Wikipedia’s reputation for accuracy, perhaps deterring potential users from using the website at all.

The flagged revision idea does seem to be a good way to prevent vandalism, assuming there is a reasonable system for selecting which users are considered “trusted.” However, it also reduces the freedom of the Wikipedia users to make edits. Also, since all changes are subject to the perceptions of the trusted users, it is possible for those trusted users to exercise censorship against other users. In addition, the proposed system would place a very large burden on the trusted users to inspect others edits so that they can be added to the article within a reasonable amount of time. It would limit the ability of Wikipedia’s editors to modify articles to keep up with current events, something that has been a useful feature. Despite the flaws of the current more permissive system, it might be better for Wikipedia to leave it as it is.

With billions of dollars being shifted from retail to e-commerce every year, web site up-time has become mission-critical to many companies. Any sort of web site failure for even extremely small periods of time can directly affect a 21st century company’s bottom line. Network Solutions has the very important task of serving as the gateway between customers’ web browsers and companies’ web sites. As the man in the middle, they are a very clear target for attackers. A malicious user has a clear path to disrupt service without ever having to attack a customer or the company itself. This scenario makes top-level security imperative to Network Solutions and Worldnic. A single successful attack could disrupt millions of transactions across millions of web sites.

Assets/Security Goals

In the case of Worldnic, the security goals are more directly quantifiable than the assets. The company provides a service, and its assets are the ability to provide that service at all times and to provide that service accurately.

• The primary security goal of Worldnic is to keep attackers from disrupting their service. As mentioned in the summary, companies depend on a level of ‘9’s of up-time (e.g., 99.999%) for their websites. Even if these companies’ websites are functional this percentage of the time, Worldnic is responsible for providing at least this level of name-resolution service. To the user, down time due to name-resolution failure is no different than down time due to bugs or other functionality errors.
• A close second security goal is to maintain the integrity of the name resolution database. The pair-wise relationship of domain names and IP addresses is not secret and is not a direct asset to protect. The integrity of this mapping, however, is a serious asset, and protecting it is a huge security goal. If some of these mappings were changed, a legitimate domain name could be mapped to an evil website that attacked visitors.
• A major asset that lies in the hands of Worldinc is their customers’ good names. Companies spend millions of dollars in marketing and branding. They also spend a large amount of time and energy protecting their names in the form of trademarks and copyrights. If Worldinc was compromised and a companies’ URL was mapped to an evil website that attacked users or slandered users or slandered other companies or was otherwise offensive or objectionable, it is often impossible to disassociate this to consumers, even after the problem has been resolved. Often times no amount of explanation is good enough if a customer was thoroughly put off, and incidents to this extent could cost the victim company a customer for life.

Potential Adversaries/Threats

Most of the potential threats involve disabling Worldnic’s service or altering it somehow. Threats involving the theft of information are much less of a concern in this business model.

• A potential adversary could be a rival company. In the cutthroat world of business it is not unthinkable for a rogue company to try to sabotage another. The threats these adversaries pose include disabling the DNS service for a particular company or group of companies, or changing their translations to route to websites that harm the victim companies image or reputation.
• Another potential adversary could be a computer hacker seeking fame or some other personal satisfaction. Because of the widespread impact a successful attack would have across the internet, there is a lot of motivation to attack this service. The threat these adversaries pose are service disruption or changing translations to websites with malicious code.
• A third potential adversary could be an attacker looking to steal money or personal information. This type of attacker would not pose the threat of disrupting service, but would be focusing on changing domain name resolutions to point to web sites under their control. From here they could use phishing techniques to steal unsuspecting users’ passwords or private information, or to lure them into paying for items sold off of the real websites.

Potential Weaknesses

There are already several known attacks against DNS servers.
• The DNS cache poisoning attack proposed by security researcher Dan Kaminsky. Kaminsky’s DNS poisoning attack on DNS servers that involves sending specially crafted packets to DNS servers to trick them into improperly changing the name-to-IP binding discussed above, violating the fundamental trust and purpose of the domain name system. This attack can take place in as little as 10 seconds. Servers that have a patch applied to combat the problem fare better, but are still susceptible to a high-bandwidth attack, failing in as little as 10 hours.
• A Distributed Denial-of-Service (DDoS) attack to prevent domain names from resolving for most legitimate users, as took place recently against Network Solutions. Modern widely-distributed malware (such as the Storm bot net) can easily mount crippling attacks against the DNS infrastructure of a particular company, effectively bringing down the web sites of their customers.
• A combination of modern MD5-collisions and DNS cache poisoning exploits could even be used to transparently hijack an entire SSL-secured site, such as an online banking site or e-commerce site. By faking a certificate authority through an MD5 collision attack and changing the DNS entries, users could believe everything on “on the level” when visiting their online bank, even if each user was careful to check certificates and other indications of security. Quite simply, a combined attack like this could be indistinguishable from the real site, expect that passwords and account information would be stolen.

Potential Defenses

There are already several proposed defenses for protecting against DNS cache poisoning attacks. Protecting against denial-of-service attacks may be more difficult, however, because it is hard to tell legitimate queries from queries that are part of an attack, and denying legitimate queries is just as bad as failing due to being swamped by an attacker.

• To protect against DNS poisoning, DNS servers can apply a patch that randomizes the ports they use, making attacking the server much more difficult. However, servers are still vulnerable to a motivated attacker in as little as a matter of hours, so attacks must be recognized early and shut down using other methods to prevent poisoning.
• Clients and servers could switch to the DNSSEC protocol. However, DNSSEC has been around for a while and has not seen widespread adoption due to backwards-comparability issues, issues of compatibility between a large and diverse set of distributed clients and servers (including many operating systems and DNS server implementations).
• A new domain name resolution protocol could be developed from the ground up with a focus on security and usability. However, based on the lackluster adoption of IPv6 and DNSSEC, it may take a major security incident to sufficiently motivate enough parties on the Internet to achieve the critical mass necessary to the transition to another system.

Risks

• Brand name degradation via denial of service attacks
• Uptime targets for mission-critical services missed by no fault of the service provider
• Sophisticated phishing attacks using DNS cache poisoning and MD5 collisions
• A fundamental building block of the Internet is fundamentally flawed and susceptible to a variety of attacks

Conclusion

DNS cache poisoning attacks and Distributed Denial-of-Service attacks against DNS servers such as Network Solutions’ WorldNic pose some fairly major security vulnerabilities, but so far little has been done to address these issues. Fortunately, there have not yet been widespread attacks against the Internet’s DNS infrastructure; nevertheless, the risk remains and as time goes on and attacks become more sophisticated, the chances of an attack will only increase.

A collaboration with Vince Zanella

This is a security review of “Smart Guns,” a general class of locking/use prevention mechanisms for firearms that rely on biometrics or other authentication indicators (such as “smart” chips embedded in the gun and in rings or other tokens worn by the intended user) to identify a person who is authorized to use the firearm, while preventing unauthorized persons from discharging the weapon. The Wikipedia article has some further broad overview information regarding the subject.

Assets

• Accessibility. Ideally, one security goal is for the firearm to be capable of being used in short order by the authorized user.
• Personal safety. The other security goal is that an unauthorized individual should not be able to use the gun to injure or kill the owner or any other person.

Adversaries

• The most obvious potential adversary is a criminal intent on using someone else’s gun to do harm; e.g., a criminal struggling with a police officer or a burglar breaking into someone’s house.
• Another “adversary” could be the small children of the owner of such a firearm; if a child somehow gains access to the firearm, the locking mechanism should be capable of preventing them from discharging the weapon and possibly killing or injuring themselves or others.

Possible Weaknesses

• If the locking system requires a battery to operate, one major problem that could compromise one of the security assets is a dead battery. If the battery is dead and the gun cannot be unlocked, it is useless to its owner, whether that be a police officer in the line of duty, or a civilian trying to defend himself from an attacker.
• If the system relies on biometrics to identify the owner (such as grip style, pulse, or other such indicators), a stressful situation (such as a shootout) might substantially change those indicators in the user, resulting in the owner being unable to use the firearm.
• Further, if the owner of a firearm is killed or injured in a gunfight, a partner, family member, or other ally will be unable to use their weapon against the attackers.

Possible Defenses

• To guard against the “dead battery” problem, one option is to design the lock so that the default (unpowered)  state is unlocked. This prevents the accessibility of the firearm from being compromised, but it also poses a major problem itself: when the battery dies, it is no longer protected against unauthorized use, and it might be possible for an adversary to damage or disable the battery, thus unlocking the firearm. A better solution might be to devise a system that does not require internal power, although this poses a significant technological challenge.
• Situations where an ally might need to use another’s gun to continue a fight arise more often in law enforcement; agencies might be able to employ a system where all officers could be issued tokens (e.g., rings) that would grant access to use all of the department’s issued firearms.

Risks

As with anything involving firearms, the risks are quite substantial:

• If the battery dies or another circumstance renders the gun unusable, the consequences could be quite dire, depending on the situation: if the user is practicing at the range, the result would be an annoying delay while the battery was replaced; if, on the other hand, the user is attempting to defend his or her life against an attacker, the result could easily be serious injury or death.
• On the other side of the issue, if an unauthorized user gains access to a firearm that is not protected (e.g., the firearm was unprotected, or the battery has died and the mechanism defaults to unlocked), they could use it to kill or seriously injure the intended user or others, or in the case of a small child, themselves.

Conclusions

While “Smart Gun” technology proposes to address a good security goal (namely, preventing a bad guy from turning someone’s gun against them), reliability is a major issue. In most of the eventualities when such a locking system becomes important, absolute reliability and speed of access are also critically important for the user. For this reason, many people do not consider the technology to be worthwhile at the present time. Ultimately, a better solution for most people is to employ other methods of keeping the firearm out of undesirable hands in the first place, rather than trying to defend against an adversary who already has physical access.

Car GPS navigation systems are handy tool for finding one’s way on the road. With features like local points of interest, address book and SD card backup it would not be surprising if becomes a common everyday item soon. Here is a review for a GPS navigation system similar to the Magellan Maestro 4200:

Assets and Security Goals

• Addresses stored on the device
• Location of the car
• The route the car is driving on as well as the destination
• The GPS system functioning properly

Potential Adversaries

• A person seeking to follow the user
• A person wanting access personal addresses and information
• A person trying to make the user lost (or drive somewhere unsafe)

Potential Weaknesses

• No passwords for use or backup (stealing is easy if there is access to the device)
• Possibility to eavesdrop information from the GPS communication (route, destination address, location)
• Possibility of sending the device incorrect information either directly or through compromising a server
• Possibly making another device with the same id as the user’s and confusing the system as to the actual location of car

Potential Defenses

• Passwords for startup of the machine
• Good encryption & integrity checks for all data sent back and forth

Risks and Conclusion

            If only a couple addresses are stored on the machine, it probably isn’t worthwhile for someone to do a complicated tracking scheme to find out information that could be figured out by simply following the car. However, as more people depend on the system to get around in the future, it may be reasonable to do harm by messing with the system. Therefore the security features of GPS Tracking system will be an important factor to consider when buying such systems in the future.

Used by websites like Twitter and SmugMug, S3 aims to provide a robust, pay-as-you-go interface for storing virtually unlimited amounts of data on the web. It is powered by Amazon’s global storage infrastructure and its design requirements includes the goal of storing data at “99.99% availability” with “no single points of failure.”

Despite the high stakes, S3 did reveal a weak link as a result of the outage: authenticated requests, due to their use of cryptography, used more resources than a typical request. The description of the cause posted in Amazon’s forums states that it was due to “elevated levels of authenticated requests from multiple users in one of our locations” at 3:30am followed by “several other users significantly increase their volume of authenticated calls,” causing the authentication service to reach capacity at around 4:00am.

So was this a coincidence or a planned attack? Amazon does not say, but they do indicate that the issue was resolved by moving more capacity online, implicitly suggesting that it was due to an increase in usage. However, especially in the case of a natural cause, this incident has exposed a large vulnerability in the authentication system: a competing service could explicitly send large amounts of authenticated calls to S3 in an attempt to overload it. Fortunately, Amazon plans to address this, stating that they will add “additional defensive measures around the authenticated calls.”

The outage puts Amazon’s suggested benefit of “no single point of failure” to question. Had the companies hosted on S3 been on separate hosts, the overall impact on consumers would have been far smaller. As the IT sector continues to see a significant number of mergers take place, this incident may prove to be a valuable warning about the robustness of our computing infrastructure. Even for a company as large and experienced as Amazon, the idea of the infallible system seems to be elusive. As the small IT firms of the dot-com era are being merged and consolidated into larger conglomerates, it would behoove the industry to keep in mind that even the largest of companies cannot guarantee 100% uptime. Thus, if a large content host goes down, the effect is not only on its own business, but that of many others. The effect is far from the ideal of distributed redundant systems. While an outage of Twitter might not be particularly significant to the lives of its users, had critical infrastructure or banking information been involved, the impact would have been far more pronounced. Next time, it might.

Round 1

The BitTorrent community’s reaction to this initial infringement was Protocol Encryption (also called Message Stream Encryption), which encrypted the protocol headers and data streams so that ISPs have a very hard time identifying P2P traffic. Unfortunately, ISPs have found ways around this by applying methods that involve pattern analysis. For example, if a particular customer is receiving multiple incoming connections for the same non-standard port, and a significant amount of upload traffic is coming from that customer, then chances are very good that a torrent is being seeded or some file is being shared via another P2P protocol. The ISP proceeds to either throttle the connections or to send TCP RST (reset) segments. While setting your firewall to drop reset segments prevents the latter from killing connections entirely (assuming all peers involved do so), not much can be done about ISP throttling. That is, until soon…

Round 2

The latest weapon in the BitTorrent arsenal will be an extension to the protocol called “Tracker Peer Obfuscation.” When a peer connects to a “swarm”, which includes all peers that are currently involved in exchanging a certain set of files, it contacts the “tracker” and obtains a list of all IP-port pairs associated with all peers in the swarm. This is how a peer knows who to download from. ISPs have found ways to intercept this exchange and use the IP-port pairs to know what connections to throttle or kill. Tracker Peer Obfuscation, should a BitTorrent client application choose to support it, states that this exchange between the tracker and a peer will be encrypted using RC4. Although only a modest level of encryption, it should prove enough to prevent ISPs from intercepting that data and using it in their pattern analysis. How effective this will be, especially in combination with Protocol Encryption/Message Stream Encryption, is still to be seen.

Motivations

Since it was discovered that ISPs actively throttle and destroy identified P2P connections last Summer, service providers have outright denied the latter and have used the excuse that throttling these connections makes the Internet faster for everyone. Opponents to these view say that ISPs need to stop throttling throughput and upgrade their infrastructure instead. They argue that the new age of the Internet is only going to bring with it demands for enormous amounts of bandwidth, so ISPs ought to make sure they are ready to meet those demands.

Links

The latest from torrentfreak.

The actual proposal for Tracker Peer Obfuscation by the BitTorrent development community.

Wikipedia on Protocol Encryption (Message Stream Encryption).

A video (avi) illustrating a seeder (using utorrent) losing connectivity seconds after others connect to him. [47.3MB @ 45KB/s max ~ 16.5 minutes]

Assets

• The privacy of the individual monitored
• The ability of the system to respond when an emergency occurs

Potential Adversaries

• A stalker interested in information about the individual’s daily behavior.
• A thief wanting to break in undetected by the person or the system.
• A disgruntled worker at Quiet Care
• A rival company that wishes to give Quiet Care a bad name

Potential Weaknesses

• The wireless activity sensors are wireless so signals from these devices can probably be easily picked up from outside the home, compromising the individual’s privacy
• The analysis of the patterns in behavior and contacting of caregivers is done on the server. If that server is taken down and an emergency occurs, the monitored individuals can be in life danger.
• If there is no encryption of data, a person could intercept and interfere with information going to the server. This could be used to create many false emergency alerts which would frustrate the caregivers and give the company a bad name.

Potential Defenses

• Using wired instead of wireless activity sensors
• An effective encryption
• Backup servers

Risk

The wireless part of this system makes very open to attacks. This risk can possibly be life threatening.

Conclusion

It is difficult to draw a balance between monitoring an individual closely enough to detect an emergency yet not invade a person’s privacy. This is a problem inherent in all home monitoring systems. For Quiet Care’s system, wiring up the detectors and using a good encryption should help with the privacy leaks that a wireless system has. As electronic home monitoring systems develop, it will be interesting to see what will be used to achieve this balance.

However, in the last few days, two more cables have been cut. An illuminating internet traffic report is here.

The probability of all of these events being random accidents seems vanishingly small. Could this be a new sort of attack intended to black out an entire region? If so – what could the motivations be and who could be behind this? Could this be done for commercial reasons? Could this be a government or terrorist organization about to mount an attack?

Some other enlightening posts can be found here: part I, part II, part III

After reading this article, it occurs to me how insecure online profiles are. For example, the article also mentions various security holes that MySpace previously had. As more social network websites are created for various purposes, more and more types of assets will be compromise. If LinkedIn have any security breach, then the assets aren’t simply just pictures anymore. Adversaries will be able to steal information about users that are much more valuable. I believe one way to prevent such problem is design the security aspect heavily during the same design phase of the application. If they include a security review of the design of the application, there will be less security vulnerabilities. The way MySpace handled this attack makes me a worry that social networks might not care about the most important assets to the social networks, which are the users information.

http://www.wired.com/politics/security/news/2008/01/myspace_torrent