Information Security News
Yesterday, Rob discussed Collecting Workstation / Software Inventory Several Ways, including PowerShell. I don't spend nearly as much time as I used to going hands-on with systems, but everytime I need to solve a problem on Windows hosts, PowerShell is there for me. Sadly my PowerShell fu is weak as compared to where I'd like it to be, but as an assimilated minion (1 of 7) of the Redmond Empire I have the benefit of many resources. Luckily much content is publicly available and you have Lee Holmes to help you with PowerShell mastery. Lee really is the man on the PowerShell front, you'll note his Windows PowerShell Pocket Reference in it's rightful place on my desk.
Amongst my many pet peeves are overly permissive file shares with the likes of Everyone, Domain Users, Domain Computers, and Authenticated Users granted unfettered access. No one every leaves PII, config files, and user name password lists on a share, right? And no one with unauthorized or inappropriate access ever makes their way on to enterprise networks, right? Sure, Russ, sure. :-) Back in the real world, where would we be without an entire industry sector dedicated to DLP (data leak prevention solutions)? Oh yeah, probably in a world with less SPAM and cold calls, but I digress.
Step 1: We admitted we were powerless over misconfigurationâthat our networks had become unmanageable.
Step 2: Came to believe that PowerShell could restore us to sanity.
I have fallen deeply, unmanageably, irrevocably in love with the Revoke-SmbShareAccess cmdlet available on Windows Server 2012 R2 and Windows 8.1 systems (Windows PowerShell 4.0). Having tried to solve this issue with the likes of Set-Acl and requiring serious counseling thereafter, Revoke-SmbShareAccess (and it's friends Block, Unblock, Get, and Grant) allowed me to do in three lines what could not be otherwise done easily or elegantly.
"The Revoke-SmbShareAccess cmdlet removes all of the allow access control entries (ACEs) for a trustee from the security descriptor of the Server Message Block (SMB) share." Sweet!
Examples? You bet. The terms
server are used generically here; you'll need to apply the appropriate nomenclature.
Local (single share, single account):
Revoke-SmbShareAccess -Name share -AccountName "Everyone" -force
Local (single share, multiple accounts):
Revoke-SmbShareAccess -Name share -AccountName "Everyone","Domain Users","Domain Computers","Authenticated Users" -force
Remote (single share, single account):
Revoke-SmbShareAccess -name share -CimSession server -AccountName Everyone -Force
Remote (single share, multiple accounts):
Revoke-SmbShareAccess -name share -CimSession server -AccountName "Everyone","Authenticated Users","Domain Users","Domain Computers" -Force
For Remote (multiple share, multiple servers, multiple accounts), where you want to use a list of servers and/or shares you can build a small script and define variables that pull from text lists.
$servers = Get-Content -Path C:\powershell\data\servers.txt
$shares = Get-Content -Path C:\powershell\data\shares.txt
Revoke-SmbShareAccess -name $shares -CimSession $servers -AccountName "Everyone","Authenticated Users","Domain Users","Domain Computers" -Force
Obviously, you'll want to tune, experiment, and optimize but hopefully this may help get you started on the cleanup process. You'll want to overly communicate with your user base advising them to create security groups granting share access only to those people (and systems) embedded in the appropriate group. Don't just go removing these permissions without an awareness campaign. You don't want that call: "You broke my entire service when you removed Everyone share permissions!" Argh. Remember also the nuances (they are many) between share permissions and NTFS permissions.
Good luck and cheers!
So you reckon you're a leet infosec warrior. Now you can prove it, pal
Defend Blighty from malware, show online crooks who's boss, bank a pay cheque, and sip a martini. It's not quite James Bond, but if you reckon you're up to the job, good news: Cyber Security Challenge UK launches today, on Friday, and is supposed to ...
Last weekend's hack of cryptocurrency repository Doge Vault was worse than previously thought because it gave attackers full access to the underlying system, including the databases that stored private keys for all user wallet addresses and cryptographically protected user passwords.
The exposure means that users should presume all Doge Vault addresses are compromised and immediately cease using any of them to transfer funds, Doge Vault officials advised in a brief announcement posted Thursday. Although the announcement said that passwords were protected by a "strong one-way hashing algorithm," users should presume the large majority of them will be converted into plaintext in a matter of hours, days, or weeks, depending on the specifics of the Doge Vault hashing regimen. As a result, people should stop using the passwords on all sites. Doge Vault users should also be on the lookout for highly targeted phishing attacks, since the hack exposed user account data that may be considered sensitive.
"It is believed the attacker gained access to the node on which Doge Vault’s virtual machines were stored, providing them with full access to our systems," Thursday's announcement stated. "It is likely our database was also exposed containing user account information; passwords were stored using a strong one-way hashing algorithm. All private keys for addresses are presumed compromised, please do not transfer any funds to Doge Vault addresses."
For infosec career success, do security certifications trump all?
Despite a middling economy and high unemployment rates, the information security field has been a bastion of hope for IT job-seekers, with conservative estimates from organizations like (ISC)2 showing that hundreds of thousands of new infosec positions ...