Full Disclosure mailing list archives
Re: Potential security flaw in network implementation at Digitalocean.com
From: Johan Boger <jboger () gmail com>
Date: Tue, 6 Aug 2013 19:33:18 +0300
Hi, It is possible this has now been fixed. I have talked with Digitalocean and they have rolled out fixes in their network. I no longer observe the same amount, just arp as you say. The problem was that their switches dropped macs from the arp table, and the next packet was then sent onwards to all other macs in that switch. This allowed you to see quite a bit. If what you did no longer works, you did this after the fixes were rolled out. I like how DO handled this, even though I disagree with how this was setup in the first place. Arp spoofing might still be possible, but most likely they will apply fixes for that too, in the following days. All the best, Johan Boger On Mon, Aug 5, 2013 at 5:51 PM, Trevor Bergeron <mal () sec gd> wrote:
Would you mind sharing how you were getting other users' traffic? I am unable to replicate this, I see only STP and occasional ARP using # tcpdump -nni eth0 host not [my ip] mal On 08/04/2013 08:22 PM, Johan Boger wrote:Hi, Today, I discovered that a certain large ISP specializing in cloudhosting (digitalocean.com), has misconfigured their network in a way that allowsforanyone to monitor customer network traffic. Per the guidelines of responsible disclosure, I have informed the ISP in question both when I first noticed the issue, and also before going public with theinformation.As I am sure some of this info has already trickled out (or is perhaps already common knowledge - if so, I apologize), I feel it is paramount to get this information out there, so that customers and others who feelthisis not something they want, can act accordingly (or at least take counter-measures to protect their information). What happened: I ordered a cloud vps (a very affordable one at that, I must say) at digitalocean.com, using the NYC node. During the process of checkingMySQLreplication between master and slave, I noticed there was a lot of background noise in tcpdump. I kept looking and when I eliminated theportsI was using, what was left was somewhat worrying. It seems DigitalOcean has, using KVM and libvirt per their own recognition, put the libvirt-interface in an overly large bridge, and then kept applying more and more networks (multiple /24, it seems). While this might be a convenient way of assigning new networks to an ever-growing customerstock,it also sort of turns the entire thing into an amateur radio station(usingthe word amateur here to denote the activity, not the skill level of Digitalocean staff!). I want to make one thing clear. This is one of the better cloud shops I have used (and I have used a lot). They seem to have excellent support, provide what they claim to provide, and my billing there so far amountstoless than a dollar (even though I've fiddled with lots of stuff).HOWEVER,this does not mean that I want to be able to read what goes on withvariousmail, ircd, web and Microsoft sql servers, in networks far outside of my logical reach, as a customer with one IPv4. I am not an angry ex-customer. I will keep using their services, if thisisfixed. Which is exactly why I am sending this email. I hope that it might add extra motivation, before someone gets their environment hacked. Thewayit is now, anyone even remotely interested, could fire up a VPS in less than a minute, and have full sniffing capabilities with hundreds (if not thousands) of servers. All while customers are using said servers to develop what I can only assume is important enough to host in a cloud. I will not paste logs as that would add nothing to my disclosure, morethana possibility to exploit innocent users. I wish to encourage thecommunityto take a few steps back and not engage in target practice, while Digitalocean undoubtedly remedies this situation (I have been in contact with them repeatedly before coming here). I hope that this helps, for whatever it's worth. I will happily answeranyfollowups, as long as they do not include requests for additional probes. This is where my involvement ends. I leave this information in the handsofthe community, and Digitalocean (who I hope reads this list). Best Regards, _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/_______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
-- Johan Boger http://cy.linkedin.com/in/johanboger
_______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Current thread:
- Potential security flaw in network implementation at Digitalocean.com Johan Boger (Aug 05)
- Re: Potential security flaw in network implementation at Digitalocean.com Trevor Bergeron (Aug 06)
- Re: Potential security flaw in network implementation at Digitalocean.com Johan Boger (Aug 06)
- Re: Potential security flaw in network implementation at Digitalocean.com Trevor Bergeron (Aug 06)