Stories
Slash Boxes
Comments

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

Did Russian Hackers Crash Skype?

Posted by kdawson on Sat Aug 18, 2007 06:59 PM
from the flicking-a-domino dept.
An anonymous reader sends us to the www.xakep.ru forum where a poster claims that the worldwide Skype crash was caused by Russian hackers (in Russian). The claim is that they found a local buffer overflow vulnerability caused by sending a long string to the Skype authorization server. You can try Google's beta Russian-to-English translation, but the interesting part is the exploit code, and that's more readable in the original. The Washington Post reports that Skype has denied this rumor.
+ -
story

Related Stories

[+] Skype Blames Microsoft Patch Tuesday for Outage 286 comments
brajesh writes to tell us that Skype has blamed its outage over the last week on Microsoft's Patch Tuesday. Apparently the huge numbers of computers rebooting (and the resulting flood of login requests) revealed a problem with the network allocation algorithm resulting in a couple days of downtime. Skype further stressed that there was no malicious activity and user security was never in any danger.
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More
Loading... please wait.
  • by ghost4096 (661448) on Saturday August 18 2007, @07:06PM (#20281129)
    The loop body will never execute....
  • Look (Score:4, Interesting)

    by TheRealMindChild (743925) on Saturday August 18 2007, @07:13PM (#20281203) Homepage Journal
    strncpy
    • Re: (Score:2, Informative)

      You think that strncpy is safe??

      The following code snippets assume pszSrc is smaller or equal to 50 chars

      // Example #1

      #define MAX (50)
      char *pszDest = malloc(sizeof(pszSrc));
      strncpy(pszDest,pszSrc,MA X);

      // Example #2

      #define MAX (50)
      char szDest[MAX];
      strncpy(szDest,pszSrc,MAX);

      // Example #3

      #define MAX (50)
      char szDest[MAX];
      strncpy(szDest,pszSrc,MAX);
      pszDest [MAX] = '\0';

      // Example #4

      #define MAX (50)
      char szDest[MAX];
      strncpy(szDest,pszSrc,MAX-1);
      strnc at(szDest,pszSrc,MAX-1);

      // Example #5

      char

      • Are you actually arguing with me, buy providing idiot code examples? What good is strncpy and its brothers if you use strlen()? Is it MY fault the person writing your code doesn't understand sizeof()? You may as well teach me how to fill up a car by siphoning gas from another car while smoking a blunt.
      • Re: (Score:3, Insightful)

        If you use strncpy(), you make sure the string has a terminator if you're going to need one.

        It's really that simple. Every specification which explains strncpy() says as much.

        Using strncpy() as specified is infinitely safer than using a function which blindly copies characters forever irrespective of your buffer size.

        Posting five examples of "the author doesn't understand C arrays or strncpy()" isn't an argument for strncpy() being horrifically unsafe, it's an argument that for every single programming cons
      • The problem with those examples isn't strncat. It's that whoever wrote them had a very poor understanding of C.

        Tards who don't learn the language they're writing in are going to write buggy code no matter what language they use. You're complaining about the wrong thing.

    • Re:Look (Score:4, Insightful)

      by PhrostyMcByte (589271) <phrosty@gmail.com> on Saturday August 18 2007, @08:03PM (#20281621) Homepage
      It's very rare for it to be okay to not write a trailing 0 terminator, or need unused buffer space padded with 0's. and that's exactly what the 'n' functions can do - the number of coders who don't know this and choose to blindly assume the functions protect them is astounding.

      Really, though. If you need the buffer space, you need the buffer space. Truncation is usually not an option. This is sloppy coding, but not due to lack of using 'n' functions. Resize as needed or reject the request if it gets too big.
      • Strncpy and friends can truncate, and worse they can silently truncate. That is why it is recommended to you strlcpy. Sadly, the idiots who maintain glibc, refused to accept the patches because it's 'inefficient BSD crap,' making it very hard to write secure code that also works on GNU/Linux.
        • Re: (Score:3, Informative)

          s/inefficient BSD crap/functions that result in silent loss of data [redhat.com]/
        • If you really want to silently truncate data, go ahead:

          #define strlcat(dst, src, size) snprintf(size, dest, "%s", src)

          Aren't you usually better off dynamically allocating these things anyway? asprintf works well. Python works better yet. :-)
          • err, strlcpy.

            #define strlcpy(dst, src, size) snprintf((size), (dst), "%s", (src))
            #define strlcat(dst, src, size) snprintf((size) - strlen(dst), (dst) + strlen(dst), "%s", (src))
  • Translation (Score:5, Informative)

    by ACS Solver (1068112) on Saturday August 18 2007, @07:14PM (#20281217)
    Here's the article's introductory part properly translated.

    "The reason for yesterday's downtime of the Skype network is research of Russian crackers, as reported by one of our readers.

    While searching for a local buffer overflow, a possibility was found to send a long string to the server, overflowing its buffer and causing the server to go down. Its place is taken by another server from the P2P network, the error arises on it in the same way, and so on. As a result, the entire Skype network refused service for several hours and the developer team was forced to turn off authentication.

    Here's the exploit code:"
    • Re:Translation (Score:5, Informative)

      by mobby_6kl (668092) on Saturday August 18 2007, @07:38PM (#20281427)
      You've got to be kidding, I was about to submit my own translation! :)

      Anyway, your version is probably a little better, so I'll contribute with something else. The script is very short too, so here it is:

      #!/usr/bin/perl
      # Simle Code by Maranax Porex ;D
      # Ya Skaypeg!!
       
      for ($i=256; $i>xCCCCC; $i=$i+256)
      {
      $eot='AAAA' x $i;
      call_sp();
      }
      exit;
       
      sub call_sp()
      {
      $str="\"C:\\Program Files\\Skype\\Phone\\Skype.exe\" \"/uri:$eot\"";
      system("$str");
      }
      The first page of comments seems to be just the usual bunch of trolls, assholes, and simply useless posts, except for one that claims the code has been shown not to do anything on a dedicated security site [securitylab.ru]. The Skype article on the front page doesn't contain any additional information. The attack looks almost too simple to work, but I wasn't able to find any strong evidence that would suggest that it doesn't, at least not with a few quick searches.
    • by Burz (138833) on Saturday August 18 2007, @10:22PM (#20282621) Journal
      It probably has more to do with Skype retooling for eavesdropping requirements under the new wiretap law. Skype handles a lot of international traffic, encrypted and often in a P2P fashion, so a major change is necessary in order to comply.

      From what little I know about Skype, the network can cause both parties in a Skype-Skype call to route through a third party, a supernode (this is done to defeat firewall complications). So perhaps they would be able to start routing all USA-international traffic through in-house supernodes where the stream could be tapped. (Anyone want to correct me? Clarify?)
      • Why USA-international? International-international is more interesting.

        This approach allows picking up traffic between two ids of interest to someone with a suitable request. If some unspecified USA institution wants to know all conversations between XXXZZZ in Russia and ZZZXCC in France they can do it and there is dickshit any of these can do about it besides stopping to use Skype.

        By the way, personally, I think that Skype has had that for a very long time and it is indeed bogus coding of the auth module t
        • The law says any traffic routed through USA can be eavesdropped, so I was being simplistic when I said USA-International.

          AFAIK the surveillance Skype could do up to this point was only at a POTS interface (SkypeOut or SkypeIn). Otherwise, the P2P calls were 'secure' with only the source & dest identities and call length being known to 3rd parties.
      • It probably has more to do with Skype retooling for eavesdropping requirements under the new wiretap law. Skype handles a lot of international traffic, encrypted and often in a P2P fashion, so a major change is necessary in order to comply.

        You remind me of my mother. Every time she hears a click on the phone, she thinks it's the CIA spying on her.

        What she doesn't seem to get is that the CIA isn't some kid hanging from her drainpipe and fiddling with alligator clips. When they listen in on your phone, you

        • Re: (Score:3, Insightful)

          What she doesn't seem to get is that the CIA isn't some kid hanging from her drainpipe and fiddling with alligator clips. When they listen in on your phone, you don't know about it.

          Unless, of course, they want her to know about it, in order to encourage self-censorship.

          Same with Skype. If they were to install CALEA compliance software, it would certainly not result in two days of downtime. There would be no outside sign that it had ever happened.

          Again, you're assuming that secrecy is desired. It is

        • One of the reasons the gov't is panicking over non-telephony (non-POTS) traffic is that much of it is encrypted and cannot be spied on without extremely complicated measures employed by all/any digital carriers involved.

          So, of COURSE the NSA can tap POTS lines without callers having the slightest suspicion. But as soon as the connections become IP-IP (and P2P) with strong modern encryption, then they are sent flat on their asses. In Skype's case nothing will help them with that signal other than a significa
          • In Skype's case nothing will help them with that signal other than a significant re-working of the service which allows, say, a supernode to act as a man-in-the-middle between what would otherwise be an uncrackable P2P link.

            1) Uncrackable my ass.

            2) What on earth makes you think that the only way to make these changes is to knock the whole system offline for two days? I cannot conceive of any situation in which that would be necessary or even helpful.

  • by rpp3po (641313) on Saturday August 18 2007, @07:21PM (#20281295)
    Skype's login servers usually don't carry much load compared to the mass of traffic routed directly between all nodes via P2P. My guess is they just got overrun because they were not prepared for the worst case: ALL clients trying to connect AT THE SAME TIME to their master. I bet Slashdot wouldn't be prepared for all of its users connecting at the same time, either. But it needs not to. It is never going to happen (why should it? - well how about December 1st, 1AM UTC everybody?). With Skype it's different. They should have been prepared for the case, that whenever their network would be down for whatever reason all clients would try to connect concurrently! Obviously they weren't prepared. If you watched the aftermath closely you could see that they started filtering by IP on day two. Only a certain number of clients were allowed to connect per IP range. They probably hired super expensive DoS emergency contractors to get this back up. A hack is still possible, but I rather guess that it brought the network down, but did not keep it from coming back up. That was Skype's own fault.
    • I find the "technical glitch" explanation quite a bit more plausible than the "Russian hacker" story. I use Skype a fair amount, and I find it rather flaky. Part of the problem is certainly on the user end (people with mediocre internet connections drop out frequently), but a large part is also the fault of Skype. For instance the Linux client lags significantly behind the Windows/Mac version, both in terms of features (e.g. video support) and bugfixes (e.g. random audio dropout). The network is also routin
      • Re: (Score:3, Informative)

        I use Skype a fair amount, and I find it rather flaky.

        Why don't you switch to an open protocol which might not be so flakey?

        If anyone has had good experiences with alternatives to Skype, that are multi-platform and support voice conferencing of 4-8 people, please let me know!

        Set up a CallWeaver server. I use CallWeaver as my server and Ekiga as my softphone and it works fine (also a UTStarCom F1000G as a WiFi phone, but I have all sorts of problems with that owing to UTStarCom's flakey firmware which they
    • I bet Slashdot wouldn't be prepared for all of its users connecting at the same time, either. But it needs not to. It is never going to happen (why should it?)

      I believe you are discounting the possibility of the actuality of Natalie Portman and Hot Grits.

    • My guess is they just got overrun because they were not prepared for the worst case: ALL clients trying to connect AT THE SAME TIME to their master.

      This is a pretty good example of why centralised network topologies such as Skype, MSN, etc. are a really Bad Idea. It doesn't take much to take down the entire network.

      SIP, XMPP, SMTP, etc are all examples of distributed topologies - there is centralised service required(*) for these networks - if one service provider's network falls over it only affects a small number of users rather than taking out *all* the users using that protocol.

      (* Yes, they all require the root name servers, but these days the root name server architecture is pretty resillient through the use of technologies such as anycase. Certainly a lot more resillient than any one organisation could hope to achieve for their own propriatory protocols).

      They should have been prepared for the case, that whenever their network would be down for whatever reason all clients would try to connect concurrently!

      This is not really a question of preparation - it's a question of a sensible network design. The Skype network (and most other propriatory services) is a flawed design _because_ they want to have control of every aspect of the network. Open protocols are generally designed to allow interoperation of independent autonomous networks so an outage of this magnetude is pretty much impossible.
  • fake? (Score:5, Informative)

    by arghblubber (948051) on Saturday August 18 2007, @07:33PM (#20281381)
    • They seem to be picking apart the perl script as not working. But whos to say they attacker didn't just run the command manually, then write the perl script afterwards (albeit with bugs) as a means of 'publishing' the exploit. It's a pretty common thing to do. Work out an exploit by hand and run it a few times, and then try and wrap it up nicely in a script for the kiddies and publishing etc.
  • by goldspider (445116) <ardrake79 @ g m a i l .com> on Saturday August 18 2007, @07:38PM (#20281431) Homepage
    They were just expressing their frustration with the expanding influence of capitalism. In the future, we should try to react to protests like this with a little understanding.
  • coincidence? (Score:5, Informative)

    by TheSHAD0W (258774) on Saturday August 18 2007, @07:44PM (#20281477) Homepage
    I bet people are trying exploits against Skype (and other popular servers and services) all the time. If someone tries something funny, and the system crashes a few seconds afterwards, they may assume they were the cause.
  • In Soviet Russia we crash Skype. Wait... that doesn't seem right.
  • by Anonymous Coward
    It wouldn't surprise me to learn that Skype shut down their OWN servers at the request of
    a "big Brother" agency, for the purpose of installing "Big Brother" software on both the
    server(s) and eventually the clients (because now a trojan is installed) into everyone's
    system with a "knock knock" protocol that would activate a "wiretap" to capture your
    voice, images, and text. That's why we had to DL that "new copy" they wanted us to have.

    Now I know you folks think I'm full if shit... I hope the heck I am but
    • Interesting. You should be able to detect outbound traffic though. Since it is a p2p system, there is not central location to tap. If your call is being sent somewhere else, you will see additional traffic when making calls. Now taking a trace of skype while it is in hub mode is pretty messy, but there would be enough of a pattern to detect if you made a few calls. Like, hmmm, why does skype always connect to 198.81.129.100 in addition to the person I am calling, no matter who I call? Something like that wo
  • by vistic (556838) <corbyz@gm3.14159ail.com minus pi> on Sunday August 19 2007, @04:29AM (#20284363)
    The Skype blog [skype.com] had info being posted all during the outage, and will have a summary of what happened soon. They never indicated it was anything related to any outside intrusion.
    • Re: (Score:3, Insightful)

      The Skype blog had info being posted all during the outage, and will have a summary of what happened soon. They never indicated it was anything related to any outside intrusion.

      Then you know it's true; nobody's ever lied on a blog before.

    • LOL. "American school system". What is it, an oxymoron contest? :)
        • In the modern world "education" is a chiefly Russian word. Not only Russinas have good education, they are just about the only ones who still do. That's why USA is crawling across former USSR territories on its knees tearfully begging people to come to work for the USA.

          And it's also why all the jobs are in the USA?

    • Re: (Score:3, Informative)

      Man, you ever notice that return key on your keyboard? You should use it once in a while...