Archive

Posts Tagged ‘security’

Don’t get-mousejacked

March 4, 2016 Leave a comment

[UPDATED: April 14th, 2016:

Good news everyone! MSFT has released an optional update that resolves this issue:

]

This morning, my boy Bruce Schneier posted about Bastille’s February 23rd published attacks on various wireless mouse/keyboard dongles.

I’ve written a quick Powershell script to get a full inventory of affected computers (deal with the output yourself).

Worth noting that this is clearly novel, but, as of this time, MSFT hasn’t released a patch, which is weird given that Bastille disclosed the vulnerabilities to them November 24th, 2015. The recommended solution (from Bastille) is to move to a wired keyboard. Nice! But aren’t those vulnerable as well?! Is Tom Cruise crawling in my ceiling tiles?!!1

Here are the details and links to attack code: https://www.bastille.net/affected-devices

Advertisements

Workflow: Palo Alto Wildfire positive on incoming SMTP => Check Ironport for delivery status => ? => Profit.

February 24, 2015 Leave a comment

Palo Alto Wildfire positive alert on incoming SMTP.
Message tracking by source server IP (provided within Wildfire positive alert) = delivery status?
If delivered, trigger email alert to user and to admins with Email subject. Possibly move email to different store with EWS.

Search an offline Windows event/application log quickly

October 22, 2014 Leave a comment
get-winevent -FilterHashTable @{path="pathto:\dc4secevent.evtx";logname='Security';ID=628}

Querying for and uninstalling evil KBs with Powershell Remoting

August 18, 2014 3 comments

You haven’t enabled Powershell Remoting yet? C’mon! Check out this blog post and this verbose guide (Secrets of Powershell Remoting).

Disregarding security flaw edge cases, Powershell Remoting defaults follow good security practices, such as Kerberos cert based authentication (much like accessing an admin share), and fully encrypted TCP pipe.

This past week, two KBs made news for cause BSODs. Although none of our systems (workstations or servers) had BSODs caused, we still wanted to get a grasp on where the KBs were installed.

Powershell Remoting made this very simple. (old version)

In this case, the block starting with `get-wmiobject` queries computer objects (by OU) to check if the two given KBs are installed. A report is output to my desktop.

The block starting with `Invoke-Command` runs `wusa.exe` synchronously, and returns once the given KB is uninstalled. It will create a restore point. Before I did this, I took a look at WSUS to verify that the patch was pulled (and it was).

Note that if you use WSUS, you can find the update, and go to it’s Approval option and select Approve for Removal.

SElinux coloring book, and MSOpenTech

April 27, 2014 Leave a comment

I subscribe to DevOps Weekly. Not sure why, since I’m not in an agile system development or continuous delivery environment, but I guess I figure I can glean some useful stuff out of it.

This week, the dude linked to two useful things:

Yep.

keybase.io invites [are gone]

February 27, 2014 16 comments

The DigitalOcean is boiling… wocka wocka

December 30, 2013 Leave a comment
There are some errors here, corrected at the end

A little while ago (8 hours), it became clear that the framework utilized by DigitalOcean doesn’t enforce a secure deletion method when a user deletes a droplet (VMs). This means that previous data is recoverable by new users who are allocated the same space. As Jed Smith states, this data leakage vector is common among hosting providers.

Here is a valuable exchange:

As far as I can tell here, there is no unexpected behavior that isn’t documented or stressed. In both our API documentation, and our control panel, we note that you must either pass a flag or check the box to security delete the data. As far as I can tell, the flag is currently functionally correctly.

Is the complaint that customer data is being leaked from VMs? That the flag being passed via our API/Dash isn’t actually working? Or, that our policy on not doing a secure delete by default isn’t something you agree with?

John Edgar (Chief Tech Evangelist)

To frame full disclosure as irresponsible is unprofessional. There is nothing irresponsible about full immediate disclosure.

It’s also a red herring. You yourself said that this is a design decision, working as intended, and that I should tell people about it to raise understanding and awareness.

https://mobile.twitter.com/jedgar/status/417515507018129408?screen_name=jedgar

This is simply a case of Digital Ocean using dark patterns and user-hostile defaults. No other major cloud provider charges their customers extra to not give their data to the next user.

You don’t take security seriously, as this design and your tweets show.

Jeffrey Paul (owner datavibes.net and eeqj.com)

@sneak I appreciate your product feedback.

I think it’s valuable, and I’ll be sharing it with the rest of our company, including our whole C-team, tomorrow morning at our weekly kick-off meeting. I’ll report back with what the result of that is. Like I’ve said 100000 times, and can’t be any more clear about, we do take security seriously.

If you’d like, I’ll happy give you a call tomorrow.

— John Edgar

Show me any other vps provider that silently provides access to customer A’s data to customer B after receiving commands from customer A to destroy their instance and then I’ll believe you guys aren’t at the very bottom of the “takes security seriously” list.

A single counterexample would convince me you’re not totally insane to think this a reasonable default.

— Jeffrey Paul

So… use `shred`, and stop trusting third parties, with their own interests in mind, to take care of what you should take care of with your own internal policies.

Infuriating Update:
Okay… So maybe I shouldn’t post before I drink coffee (particularly to a github issue), but I did misunderstand the problem. It appears that DigitalOcean changed a default value for a setting in their API, and that’s the extent of the controversy. The github ticket was opened with a single API user, fog.io; which is basically host management magic that allows users to easily manage systems with many IaaS providers.

I’m happy that I don’t look like a jackass, because my point on user/dev accountability still holds true. The fog.io developers didn’t hard code a value in their API call, and this allows a few fog.io devs and users to call DigitalOcean “shitty?” Hell no. It’s your responsibility to code securely, and that means you don’t get to code all “shitty” like and then blame someone else for the screw up, particularly if that screw up is so critical to you.

This point goes beyond the general acceptance of risk when dealing with a third party [hosting provider]; it is up to you to understand and reduce the introduced risk. That responsibility, and all failures therein, should always be left on you and on no one else. You should be accountable always, for everything you do.

%d bloggers like this: