Good point, the report calls out that the root password for 40+ servers was the same, and that a large number of employees knew or used it. Seems sensible to transfer that same mentality across to other sensitive accounts.
851 karma · joined May 29, 2014
Email: graham@grh.am
Once they identified the vulnerability to exploit, it seems they used genuine credentials to then place webshells on the server which gave them persistence - a low-level reverse shell if you will, allowing them to traverse the file system, execute commands as if they had genuine access. Next up, a quick grep for plaintext credentials that they can then pivot with. There are still questions around how those credentials were obtained, but they'd don't specifically call them out as being default.
The report then jumps to the person accessing databases (including payment card info.. whoops) - the question here is why did a Wordpress instance have access to such data? I can't imagine it would have needed it, so I suspect that they either had one huge DB server containing the backend for this WordPress instance, plus their customer data & payment info databases/tables. Or, the malicious actor traversed the internal network, using the WordPress as a pivot point.
Last point worth calling out, is that they are unsure how much of the data was actually exfiltrated - "[...] the transaction/payment card information referred to above was located and accessed: it cannot be ascertained whether or not some or all of that information was indeed exported, but that is a very realistic possibility." This is a common problem with breaches, and an area what active monitoring can help. By planting unique details/tokens into the database (users, payment information etc.), you can start scanning for them on the clear and dark web. As and when they appear, you can confirm if the data was exfiltrated (and with many honeypots, pinpoint time of the breach). This is one of the many reasons I put BreachInsider[0] together.
Great for bug bounties, or in UpGuard’s situation, a tonne of publicity from private data being accessible from public buckets.
[0]https://docs.google.com/spreadsheets/d/184wcDt9I9TUNFFbsAVLp...
* They became aware of it Dec 11th – do they have an estimate of when this occurred?
* They mention what types of information has likely been affected, yet for some reason they mention “no payment details have been breached” right at the end of the Q&A? I’d have expected that to be much higher up the announcement.
* Not needed in the general announcement, but knowing how is always a point of interest (that may just be me, being in the business) – third party? SQLi? etc.
* How did they become aware of this? Did they discover this internally? Or did an outsider give them the heads up.
I’d like to think that one day, that last question can be answered by my startup[0], detecting breaches with a high degree of confidence with pseudo/honey users.
It also has sane defaults, which means scriptkiddies chancing their luck with it should be easily spotted in your access.log, or depending on your environment a WAF/IDS/IPS should block/detect quickly.
Very interesting. I wonder if any private organisations setup a pseudo/canary repositories, that when pulled triggered an alarm? Or simply contained some monitored API keys or credentials to spot any activity/Insider threats.
Might be a neat idea for those businesses that are concerned about their private repos (either cloud hosted or self hosted).
May have picked up if anyone was able to exploit this.
Very interesting. I wonder if any private organisations setup a pseudo/canary repositories, that when pulled triggered an alarm? Or simply contained some monitored API keys or credentials to spot any activity/Insider threats.
Might be a neat idea for those businesses that are concerned about their private repos (either cloud hosted or self hosted).
May have picked up if anyone was able to exploit this.
Seems I may need to reconsider Facebook Ads...
He has been working for IBM since they acquired Resilient Systems where Schneier was CTO.
http://www.virten.net/2016/06/additional-usb-nic-for-intel-n...
Edit: Bug fixed, really sorry about that! I've sent an email to the insiders address, to give you an example alert.
In terms of mobile numbers, they are definitely prone to this, and that is why we make them optional - depends if you want to risk any false positive alarms. Some countries are more prone than others - US mobile get reused a lot it seems!
In terms of why a mid-sized SaaS should go this route - I would like to think that Breach Insider is a slightly more cost-effective option. To do detection and correlation properly, you’re looking at a SIEM with the right logs and hopefully some well formed rules. However at this stage, I’d argue that to get the absolute most out of this, you’re looking at supporting & monitoring this with at least one dedicated employee, else all those logs will be wasted.
1. The unique email address assigned to the Insider is contacted. We gather forensic evidence of the email along with any attachments. Useful to identify specific attacks against your users too.
2. An optional real mobile number assigned to your Insider is contacted. Again, we store all of the details, including the original SMS details or even call recordings.
3. Your Insider shows up on the Internet or dark web somewhere - we check a number of common sources for dumps, such as Pastebin for any references to the Insider. We currently keep a copy of the contents of the paste, as the original details could be removed at any time. However, we are working on better captures (full page screenshots, entire copy of the DOM etc.)
We are working a few more detection methods too, which we shall reveal soon...
If you’ve got or know of a site using 2fa, definitely put in a pull request to show your support.
Additionally, I have multiple alerts setup for any signs of downtime, so that any deployment can be invoked as soon as possible.
However, I completely understand your perspective, and if this was a different type of startup or industry, I would probably implement it the way you mentioned.
In terms of infrastructure, this meant using Ansible for quickly deploying new servers where needed and adding them to the right load balancer. Currently all I need to do is spin up a new instance with the right tag & run the relevant Ansible script - this will grab a copy of the site from git, sort out dependencies and any other apps needed (supervisord and so on), and add it to the nginx loadbalancer config as a new upstream server.
Same applies for things like billing. Yes I could have started off doing billing manually, sending out invoices etc, but these take time and realistically need to be automated to avoid any errors.
These things definitely meant I didn’t get my MVP out in weeks, but meant I could still do this as a solo-bootstrapper and look after a young family and such.
Arq for Mac Vulnerabilities Fixed
Mark Wadham (thank you Mark for all your help identifying and helping to resolve this!) identified a vulnerability in Arq 5 for Mac where an attacker could become "root" user. The issue was the way Arq applied the set-user-ID-on-execution bit to helper apps (for auto-updating, backup using administrator privileges, and restoring). The affected helper apps were arq_updater (for auto-update), arqcommitter (for backing up) and standardrestorer, arqglacierrestorer and arqs3glacierrestorer (for restoring). The fix for this issue is implemented in Arq 5.10:
When you double-click the Arq icon in the DMG, Arq copies itself to /Applications and sets the permissions on the application bundle to prevent non-root users from modifying it.
Arq will only set the set-user-ID-on-execution bit on the helper apps if the Arq app bundle is installed in /Applications.It is however in my profile, if anyone feels so inclined..