scottpiper
It was a very well built setup that I assumed (as did everyone) that it was put there by the gov in some capacity, such as for weather observations. It wasn't hidden or hard to find by any means and on a fairly popular trail. I would bet during nice summer weather a few hundred people per week walked past it.
Denial of Wallet Attacks on AWS
AWS Security Maturity Roadmap for 2020 [pdf]
Show HN: CloudTracker – Helps implement least privilege on AWS
Show HN: CloudMapper, open-source tool for visualizing AWS environments
- Downclimb (my own), for weekly infosec news summaries: https://summitroute.com/blog/2017/03/12/downclimb/
- Bulletproof TLS, monthly, for crypto and TLS news: https://www.feistyduck.com/bulletproof-tls-newsletter/issue_...
- Mobile security news, monthly: http://www.mulliner.org/blog/blosxom.cgi/security/mobile_sec...
- This week in 4n6, weekly DFIR: https://thisweekin4n6.com/2017/03/12/week-10-2017/
I used openssl because I find GPG on servers is awkward to use.
The full article is more clear that I have only one private key, and for all the nightly backups I'm generating AES keys and encrypting them with the public key.
For 1, I ensure that an attacker can not modify my archives after they've been uploaded by giving the backup service "put" only privileges. This is not possible with GCE from the article unfortunately, as I point out in a warning banner there, but is with AWS that I'll post soon. My use case is primarily to have a backup in the event of a devops mistake, or malicious attacker (ransomware), so I assume if someone has write-access to my archives they would just delete them, so authenticating them isn't as big of a concern, but although this would be a good idea just to ensure the files aren't corrupt in some other way.
For 2, my storage needs currently aren't expensive (100GB archives per day, which means pennies per day for all of them), but eventually I plan on sending just diffs. I also wanted to create and send backups in the simplest possible way to help people get up and running as fast as possible, which meant limiting myself to the "openssl" command and other basic commands. The other, smarter, solutions I'm aware of are either tied to a service (ex. tarsnap) or don't maintain the data as encrypted at the backup location.
[1] https://summitroute.com/blog/2016/12/25/creating_disaster_re...
[2] https://summitroute.com/blog/2016/12/25/using_google_for_bac...
The original purpose of HBGary's tool was for fingerprinting malware, but what it really was doing was just extracting out info from malware author's build environments that could be learned from the executables they created.
Other things you would want to check for though are: - Are the executables code signed? - When run, look in ProcessExplorer (for Windows) to see if it runs with DEP/ASLR/CFG/x64 and ensure every DLL it loads has ASLR and CFG. - Run with wireshark on and ensure any network traffic is HTTPS.
There are thousands of ways for all these checks to give incorrect information with regard to whether the developers follow best practices or not, but if you do enough steps they'll add up to a decently accurate understanding.
These mitigations are "free" to add to programs in the sense that they are just compiler flags. Usually the reason these aren't being used is because the build process for a tool is really old and isn't using the latest version of Visual Studio or some other compiler. Some examples of this are Google Drive, which is still compiled with Visual Studio 2008, or 7-zip which seems to use VS 2005.
https://summitroute.com/blog/ - (mine) Infosec news.
http://ben-evans.com/#newsletter - Email only newsletter from Benedict Evans of A16Z mostly related to large mobile business moves.
https://www.feistyduck.com/bulletproof-tls-newsletter/ - TLS crypto news (monthly)
http://golangweekly.com/ - Golang links
When evaluating, it's important to look at past vulnerabilities. The following links are to posts from Exodus Intelligence about a vuln they found in i2p in July, 2014. - http://blog.exodusintel.com/2014/07/23/silverbullets_and_fai... - http://blog.exodusintel.com/2014/08/25/tails-from-the-cri2p/
On the one hand you could say it is more secure now because Exodus Intelligence reviewed it, and said "I2P had many cross-site scripting vulnerabilities" of which all were fixed. Also the way in this could be exploited is a little unique (by using XSS to hit the internal I2P router configuration intranet), so it's hard to fault the developers too much for overlooking those XSS problems originally.
On the other hand, there is the view that the more vulns that are found, the more likely it is there are more as yet undiscovered vulns.