Skip navigation

Internet infrastructure

warning: Creating default object from empty value in /var/www/vhosts/ on line 33.
Original author: 
Peter Bright

Sven Olaf Kamphuis waving the Pirate Party flag in front of CyberBunker's nuclear bunker.

Sven Olaf Kamphuis

Over the last ten days, a series of massive denial-of-service attacks has been aimed at Spamhaus, a not-for-profit organization that describes its purpose as "track[ing] the Internet's spam operations and sources, to provide dependable realtime anti-spam protection for Internet networks." These attacks have grown so large—up to 300Gb/s—that the volume of traffic is threatening to bring down core Internet infrastructure.

The New York Times reported recently that the attacks came from a Dutch hosting company called CyberBunker (also known as cb3rob), which owns and operates a real military bunker and which has been targeted in the past by Spamhaus. The spokesman who the NYT interviewed, Sven Olaf Kamphuis, has since posted on his Facebook page that CyberBunker is not orchestrating the attacks. Kamphuis also claimed that NYT was plumping for sensationalism over accuracy.

Sven Olaf Kamphuis is, however, affiliated with the newly organized group "STOPhaus." STOPhaus claims that Spamhaus is "an offshore criminal network of tax circumventing self declared internet terrorists pretending to be 'spam' fighters" that is "attempt[ing] to control the internet through underhanded extortion tactics."

Read 40 remaining paragraphs | Comments

Your rating: None

In a series of posts on his blog, military theorist John Robb outlines what he thinks will be the next big thing — "as big as the internet," as he puts it. It's DRONENET: an internet of drones to be used as an automated delivery service. The drones themselves would require no futuristic technology. Modern quadrotor drones are available today for a few hundred dollars, and drone usage would be shared across an open, decentralized network. Robb estimates the cost for a typical delivery at about $0.25 every 10 miles, and points out that the drones would fit well alongside many ubiquitous technologies; the drone network shares obvious parallels with the internet, the drones would use GPS already-common GPS navigation, and the industry would mesh well with the open source hardware/software community. Finally, Robb talks about the standards required for building the DRONENET: "Simple rules for drone weight, dimensions, service ceiling, and speed. Simple rules for battery swap and recharging (from battery type, dimension, etc.). Simple rules for package containers. Simple rules for the dimensions and capabilities of landing pads. ... Decentralized database and transaction system for coordinating the network. Rules for announcing a landing pad (information from GPS location and services provided) to the network. Rules for announcing a drone to the network (from altitude to speed to direction to destination). Cargo announcement to the network, weight, and routing (think: DNS routing). A simple system for allocating costs and benefits (a commercial overlay). This commercial system should handle everything from the costs of recharging a drone and/or swapping a battery to drone use."

Share on Google+

Read more of this story at Slashdot.

Your rating: None

Syria’s Internet infrastructure remains almost entirely dark today. Almost.

The folks at Renesys, who were the first to notice that something was amiss with the telecom infrastructure of the war-torn Middle Eastern nation, have been hard at work sifting through their data — and they’ve found something interesting.

At least five networks operating outside Syria, but still operating within Syrian-registered IP address spaces, are still working, and are apparently controlled by India’s Tata Communications.

These same networks, Renesys says, have some servers running on them that were implicated in an attempt to deliver Trojans and other malware to Syrian activists. The payload was a fake “Skype Encryption Tool” — which is, on its face, kind of silly, because Skype itself is already encrypted to some degree — that was actually a spying tool. The Electronic Frontier Foundation covered the attempted cyber attack at the time.

Cloudflare has also been monitoring the situation in Syria and has made a few interesting observations.

First, pretty much all Internet access in the country is funneled through one point: The state-run, state-controlled Syrian Telecommunications Establishment. The companies that provide this capacity running into the country are PCCW and Turk Telekom as the primary providers, with Telecom Italia and Tata providing additional capacity.

There are, Cloudflare notes, four physical cables that bring Internet connectivity into Syria. Three of them are undersea cables that land in the coastal city of Tartus. A fourth comes in from Turkey to the north. Cloudflare’s Matt Prince says it’s unlikely that the cables were physically cut.

Cloudflare put together a video of what it looked like watching the changes in the routing tables happen live. It’s less than two minutes long.

For what it’s worth, Syria’s information minister is being quoted in various reports as blaming the opposition for the shutdown.

So the question is: Why now? Clearly, the Syrian regime is under more pressure than ever before. Previously, it tended to view the country’s Internet as a tool to not only get its own word out to the wider world, but also to try and spy on and monitor the activities of the rebels and activists.

With fighting intensifying in and around the capital and the commercial city of Aleppo, the decision to throw the kill switch might indicate a decision to try to disrupt enemy communications. Or it might mask a seriously aggressive military action that it wants to keep as secret as possible. We don’t know yet.

Your rating: None

As Bruce Schneier spent the past decade watching the growing rash of phishers, malware attacks, and identity theft, a new Internet threat has emerged that poses even greater risks, the security expert said.

Unlike the security risks posed by criminals, the threat from government regulation and data hoarders such as Apple and Google are more insidious because they threaten to alter the fabric of the Internet itself. They're also different from traditional Internet threats because the perpetrators are shielded in a cloak of legitimacy. As a result, many people don't recognize that their personal information or fortunes are more susceptible to these new forces than they ever were to the Russian Business Network or other Internet gangsters.

Read the rest of this article...

Read the comments on this post

Your rating: None

I don't usually do news and current events here, but I'm making an exception for the CWE/SANS Top 25 Most Dangerous Programming Errors list. This one is important, and deserves a wide audience, so I'm repeating it here -- along with a brief hand-edited summary of each error.

If you work on software in any capacity, at least skim this list. I encourage you to click through for greater detail on anything you're not familiar with, or that piques your interest.

  1. Improper Input Validation

    Ensure that your input is valid. If you're expecting a number, it shouldn't contain letters. Nor should the price of a new car be allowed to be a dollar. Incorrect input validation can lead to vulnerabilities when attackers can modify their inputs in unexpected ways. Many of today's most common vulnerabilities can be eliminated, or at least reduced, with strict input validation.

  2. Improper Encoding or Escaping of Output

    Insufficient output encoding is at the root of most injection-based attacks. An attacker can modify the commands that you intend to send to other components, possibly leading to a complete compromise of your application - not to mention exposing the other components to exploits that the attacker would not be able to launch directly. When your program generates outputs to other components in the form of structured messages such as queries or requests, be sure to separate control information and metadata from the actual data.

  3. Failure to Preserve SQL Query Structure (aka 'SQL Injection')

    If attackers can influence the SQL that you send to your database, they can modify the queries to steal, corrupt, or otherwise change your underlying data. If you use SQL queries in security controls such as authentication, attackers could alter the logic of those queries to bypass security.

  4. Failure to Preserve Web Page Structure (aka 'Cross-site Scripting')

    Cross-site scripting (XSS) is a result of combining the stateless nature of HTTP, the mixture of data and script in HTML, lots of data passing between web sites, diverse encoding schemes, and feature-rich web browsers. If you're not careful, attackers can inject Javascript or other browser-executable content into a web page that your application generates. Your web page is then accessed by other users, whose browsers execute that malicious script as if it came from you -- because, after all, it did come from you! Suddenly, your web site is serving code that you didn't write. The attacker can use a variety of techniques to get the input directly into your server, or use an unwitting victim as the middle man.

  5. Failure to Preserve OS Command Structure (aka 'OS Command Injection')

    Your software acts as a bridge between an outsider on the network and the internals of your operating system. When you invoke another program on the operating system, and you allow untrusted inputs to be fed into the command string, you are inviting attackers into your operating system.

  6. Cleartext Transmission of Sensitive Information

    Information sent across a network crosses many different nodes in transit to its final destination. If your software sends sensitive, private data or authentication credentials, beware: attackers could sniff them right off the wire. All they need to do is control one node along the path to the final destination, any node within the same networks of those transit nodes, or plug into an available interface. Obfuscating traffic using schemes like Base64 and URL encoding offers no protection.

  7. Cross-Site Request Forgery (CSRF)

    Cross-site request forgery is like accepting a package from a stranger -- except the attacker tricks a user into activating a HTTP request "package" that goes to your site. The user might not even be aware that the request is being sent, but once the request gets to your server, it looks as if it came from the user -- not the attacker. The attacker has masqueraded as a legitimate user and gained all the potential access that the user has. This is especially handy when the user has administrator privileges, resulting in a complete compromise of your application's functionality.

  8. Race Condition

    A race condition involves multiple processes in which the attacker has full control over one process; the attacker exploits the process to create chaos, collisions, or errors. Data corruption and denial of service are the norm. The impact can be local or global, depending on what the race condition affects - such as state variables or security logic - and whether it occurs within multiple threads, processes, or systems.

  9. Error Message Information Leak

    Chatty error messages can disclose secrets to any attacker who misuses your software. The secrets could cover a wide range of valuable data, including personally identifiable information (PII), authentication credentials, and server configuration. They might seem like harmless secrets useful to your users and admins, such as the full installation path of your software -- but even these little secrets can greatly simplify a more concerted attack.

  10. Failure to Constrain Operations within the Bounds of a Memory Buffer

    The scourge of C applications for decades, buffer overflows have been remarkably resistant to elimination. Attack and detection techniques continue to improve, and today's buffer overflow variants aren't always obvious at first or even second glance. You may think that you're completely immune to buffer overflows because you write your code in higher-level languages instead of C. But what is your favorite "safe" language's interpreter written in? What about the native code you call? What languages are the operating system API's written in? How about the software that runs Internet infrastructure?

  11. External Control of Critical State Data

    If you store user state data in a place where an attacker can modify it, this reduces the overhead for a successful compromise. Data could be stored in configuration files, profiles, cookies, hidden form fields, environment variables, registry keys, or other locations, all of which can be modified by an attacker. In stateless protocols such as HTTP, some form of user state information must be captured in each request, so it is exposed to an attacker out of necessity. If you perform any security-critical operations based on this data (such as stating that the user is an administrator), then you can bet that somebody will modify the data in order to trick your application.

  12. External Control of File Name or Path

    When you use an outsider's input while constructing a filename, the resulting path could point outside of the intended directory. An attacker could combine multiple ".." or similar sequences to cause the operating system to navigate out of the restricted directory. Other file-related attacks are simplified by external control of a filename, such as symbolic link following, which causes your application to read or modify files that the attacker can't access directly. The same applies if your program is running with raised privileges and it accepts filenames as input. Similar rules apply to URLs and allowing an outsider to specify arbitrary URLs.

  13. Untrusted Search Path

    Your software depends on you, or its environment, to provide a search path (or working path) to find critical resources like code libraries or configuration files. If the search path is under attacker control, then the attacker can modify it to point to resources of the attacker's choosing.

  14. Failure to Control Generation of Code (aka 'Code Injection')

    While it's tough to deny the sexiness of dynamically-generated code, attackers find it equally appealing. It becomes a serious vulnerability when your code is directly callable by unauthorized parties, if external inputs can affect which code gets executed, or if those inputs are fed directly into the code itself.

  15. Download of Code Without Integrity Check

    If you download code and execute it, you're trusting that the source of that code isn't malicious. But attackers can modify that code before it reaches you. They can hack the download site, impersonate it with DNS spoofing or cache poisoning, convince the system to redirect to a different site, or even modify the code in transit as it crosses the network. This scenario even applies to cases in which your own product downloads and installs updates.

  16. Improper Resource Shutdown or Release

    When your system resources have reached their end-of-life, you dispose of them: memory, files, cookies, data structures, sessions, communication pipes, and so on. Attackers can exploit improper shutdown to maintain control over those resources well after you thought you got rid of them. Attackers may sift through the disposted items, looking for sensitive data. They could also potentially reuse those resources.

  17. Improper Initialization

    If you don't properly initialize your data and variables, an attacker might be able to do the initialization for you, or extract sensitive information that remains from previous sessions. If those variables are used in security-critical operations, such as making an authentication decision, they could be modified to bypass your security. This is most prevalent in obscure errors or conditions that cause your code to inadvertently skip initialization.

  18. Incorrect Calculation

    When attackers have control over inputs to numeric calculations, math errors can have security consequences. It might cause you to allocate far more resources than you intended - or far fewer. It could violate business logic (a calculation that produces a negative price), or cause denial of service (a divide-by-zero that triggers a program crash).

  19. Improper Access Control (Authorization)

    If you don't ensure that your software's users are only doing what they're allowed to, then attackers will try to exploit your improper authorization and exercise that unauthorized functionality.

  20. Use of a Broken or Risky Cryptographic Algorithm

    Grow-your-own cryptography is a welcome sight to attackers. Cryptography is hard. If brilliant mathematicians and computer scientists worldwide can't get it right -- and they're regularly obsoleting their own techniques -- then neither can you.

  21. Hard-Coded Password

    Hard-coding a secret account and password into your software is extremely convenient -- for skilled reverse engineers. If the password is the same across all your software, then every customer becomes vulnerable when that password inevitably becomes known. And because it's hard-coded, it's a huge pain to fix.

  22. Insecure Permission Assignment for Critical Resource

    Beware critical programs, data stores, or configuration files with default world-readable permissions. While this issue might not be considered during implementation or design, it should be. Don't require your customers to secure your software for you! Try to be secure by default, out of the box.

  23. Use of Insufficiently Random Values

    You may depend on randomness without even knowing it, such as when generating session IDs or temporary filenames. Pseudo-Random Number Generators (PRNG) are commonly used, but a variety of things can go wrong. Once an attacker can determine which algorithm is being used, he can guess the next random number often enough to launch a successful attack after a relatively small number of tries.

  24. Execution with Unnecessary Privileges

    Your software may need special privileges to perform certain operations; wielding those privileges longer than necessary is risky. When running with extra privileges, your application has access to resources that the application's user can't directly reach. Whenever you launch a separate program with elevated privileges, attackers can potentially exploit those privileges.

  25. Client-Side Enforcement of Server-Side Security

    Don't trust the client to perform security checks on behalf of your server. Attackers can reverse engineer your client and write their own custom clients. The consequences will vary depending on what your security checks are protecting, but some of the more common targets are authentication, authorization, and input validation.

Of course there's nothing truly new here; I essentially went over the same basic list in Sins of Software Security almost two years ago. The only difference is the relative priorities, as web applications start to dominate mainstream computing.

This list of software security mistakes serves the same purpose as McConnell's list of classic development mistakes: to raise awareness. A surprisingly large part of success is recognizing the most common mistakes and failure modes. So you can -- at least in theory -- realize when your project is slipping into one of them. Ignorance is the biggest software project killer of them all.

Heck, even if you are aware of these security mistakes, you might end up committing them anyway. I know I have.

Have you?

[advertisement] Did your buddy just get his ear chewed off for another server crash? Help him out by recommending PA Server Monitor. He just might buy you lunch. Download the Free Trial!

Your rating: None