Click an Ad
If you find this blog helpful, please support me by clicking an ad!
Friday, April 25, 2014
Facebook edits are visible?
Just a quickie: Did you know that Facebook edits are visible? You will see a link titled "Edited" under the name of the poster; comments and posts will have this link if they get edited. Click on it and you can see the original. Kind of disturbing, really. Look through your feed and I'm sure you find a couple. No takebacks. Be careful before posting....
Thursday, April 10, 2014
HeartBleed made me finally make the leap... LastPass here I come
The HeartBleed SSL vulnerability has been at the forefront of tech news for the past couple of days now. This new vulnerability has shaken my person password policy and management to its core. I knew it would happen someday, but I just kept kicking the can down the road.
I've had a pretty good run with KeePass. My KeePass database spans 5 years of creating passwords on the internet. Are all of my passwords original? Nope. I have several variations and combinations of very strong passwords. I've also simply used generic passwords at sites that I don't care about. To my knowledge, nothing has been compromised yet.
HeartBleed leapfrogs current password harvesting methods. Until now, hackers have typically compromised servers, and then pilfer improperly secured password databases. Every time this happens, more and more passwords are added to hackers' dictionaries. Hackers use dictionaries to try and guess passwords, and these lists are getting better and better. With HeartBleed, hackers don't have to mess around with password database security, or salted hashed, or anything like that. They can just scrape the unencrypted, non-salted passwords directly out of the server's memory. Awesome. Oh wait it gets better! This vulnerability has been wide open for a couple of months!
I used my most complex combo passwords on my most important sites: Facebook, Gmail, Dropbox, etc. The ones I don't want people to get into. Facebook, Gmail, and Dropbox were all vulnerable. For an example, let's say my awesome strong passwords consist of 1-4 different words:
M0t0b0at
Gr@v1t33
L3tsGO
M@RVEL-us
Since I value my GMail account's security, my password would have been gM0t0b0atGr@v1t33L3tsGOM@RVEL-us. On other less important sites, it would have been just one, like L3tsGO.
I admit it. This is not good security practice. All my passwords should be strong. And different. The problem is I have too many passwords, and my brain just isn't big enough. I've been fighting the monster for so long.... and now I'm done.
The problem now is that some enterprising hacker can now take my passwords that they've harvested and add them to their dictionary. Most password cracking programs have the ability to do all kinds of neat things, like change all e's to 3's, try both upper and lower-case letters, etc. They can also put passwords together in different combinations. So, my risk has increased quite a bit.
Yesterday I plunked down the $13 for LastPass and started changing my passwords. They're all different now; random and 20 characters long. If a site's password database gets hacked, I'll just change the password for that site and be done with it. I can't take the worry or the management overhead anymore. I have thrown in the towel. Take my money, LastPass.
I recommend that you check out this link on mashable to find out where you should be changing your passwords.
I've had a pretty good run with KeePass. My KeePass database spans 5 years of creating passwords on the internet. Are all of my passwords original? Nope. I have several variations and combinations of very strong passwords. I've also simply used generic passwords at sites that I don't care about. To my knowledge, nothing has been compromised yet.
HeartBleed leapfrogs current password harvesting methods. Until now, hackers have typically compromised servers, and then pilfer improperly secured password databases. Every time this happens, more and more passwords are added to hackers' dictionaries. Hackers use dictionaries to try and guess passwords, and these lists are getting better and better. With HeartBleed, hackers don't have to mess around with password database security, or salted hashed, or anything like that. They can just scrape the unencrypted, non-salted passwords directly out of the server's memory. Awesome. Oh wait it gets better! This vulnerability has been wide open for a couple of months!
I used my most complex combo passwords on my most important sites: Facebook, Gmail, Dropbox, etc. The ones I don't want people to get into. Facebook, Gmail, and Dropbox were all vulnerable. For an example, let's say my awesome strong passwords consist of 1-4 different words:
M0t0b0at
Gr@v1t33
L3tsGO
M@RVEL-us
Since I value my GMail account's security, my password would have been gM0t0b0atGr@v1t33L3tsGOM@RVEL-us. On other less important sites, it would have been just one, like L3tsGO.
I admit it. This is not good security practice. All my passwords should be strong. And different. The problem is I have too many passwords, and my brain just isn't big enough. I've been fighting the monster for so long.... and now I'm done.
The problem now is that some enterprising hacker can now take my passwords that they've harvested and add them to their dictionary. Most password cracking programs have the ability to do all kinds of neat things, like change all e's to 3's, try both upper and lower-case letters, etc. They can also put passwords together in different combinations. So, my risk has increased quite a bit.
Yesterday I plunked down the $13 for LastPass and started changing my passwords. They're all different now; random and 20 characters long. If a site's password database gets hacked, I'll just change the password for that site and be done with it. I can't take the worry or the management overhead anymore. I have thrown in the towel. Take my money, LastPass.
I recommend that you check out this link on mashable to find out where you should be changing your passwords.
Friday, April 4, 2014
MalwareBytes Blocked IP Reporting
We had a spate of malware attacks on our website recently. We run MalwareBytes Anti-Malware on the box. In the log file, I see that it's blocking IP addresses. Shouldn't there be some reporting? I think so. I start poking around the interface, but there are no reporting options.
Surprisingly, it doesn't even write to the event logs. Only log files. So much for alerting us when there's an issue. I talk to my network admin and we decide that we'd like a daily report that tells us what IPs have been blocked, and then he can investigate further and decide if he wants to block the IP at the Firewall.
On a daily basis, we need to pull yesterday's log file, select any lines with "IP-BLOCK" in them, and send him an email with the entries so he can look into the IP addresses. Sounds like a job for Powershell!
As it happens, MalwareBytes writes their log files using a weird encoding format. My Get-Content fails miserably, resulting in text output where there appears to be a space between every single character. In Notepad++, the text looks fine, but I notice that in the bottom right-hand side it says "UCS-2 LE w/o BOM". Weird, this must be encoded differently. Get-Content works with some encoding schemes, but this one is not in the list. After much Googling, trial, and error, I am able to figure out that I need to read the file using get-content, then output to file using different encoding by using the -Encoding UTF8 switch. Now, however, the text file I have contains a bunch of NUL characters. To get rid of these I have to do a -replace "`0","". That's a zero, and the backtick zero symbolizes the NUL character. NOW I have some data to work with!
Great, so I put it all together, test it, and schedule it to run nightly at 12:01AM.
Here's the script:
#---------------------- BEGIN SCRIPT -----------------------
#Path to Malwarebytes Log Files
$PathToLogs = "C:\ProgramData\Malwarebytes\Malwarebytes' Anti-Malware\Logs\"
#Temp File
$TempFile = "C:\Temp\TempFile.txt"
#Yesterday date, as a string formatted yyyy-MM-dd
$date = (Get-Date).AddDays(-1).ToString('yyyy-MM-dd')
#Put together the filename we'll be looking for
$FileName = "protection-log-" + $date + ".txt"
#Put together the entire path
$FileFullPath = $PathToLogs + $FileName
#Read the content from the log file, and send it out with UTF8 encoding to the Temp File
Get-Content $FileFullPath | out-file -Encoding UTF8 $TempFile
#Read the new content
$UTF8File = Get-Content $TempFile
#Delete the Temp File, since we've read it now
Remove-Item $TempFile -Force
#Specify the character to be removed
$RemoveString = "`0"
#Remove the null characters from the file, creating a usable file
$CleanedLog = $UTF8File -replace $RemoveString,""
#Get the lines that have blocked IPs
$BlockedIPs = $CleanedLog | select-string -pattern "IP-BLOCK"
#Convert BlockedIPs to a string, so I can use it in the body of my email
$BlockedIPs = $BlockedIPs | out-string
#Send an email if there are greater than 0 IP Block messages
If ((($BlockedIPs | measure-object).count) -gt 0){
Send-MailMessage -To netadmin@contoso.com -Subject "PS Report - IPs Blocked by MalwareBytes" -Body $BlockedIPs -From "helpdesk@contoso.com" -SmtpServer "mailserver.contoso.com"
}
Surprisingly, it doesn't even write to the event logs. Only log files. So much for alerting us when there's an issue. I talk to my network admin and we decide that we'd like a daily report that tells us what IPs have been blocked, and then he can investigate further and decide if he wants to block the IP at the Firewall.
On a daily basis, we need to pull yesterday's log file, select any lines with "IP-BLOCK" in them, and send him an email with the entries so he can look into the IP addresses. Sounds like a job for Powershell!
As it happens, MalwareBytes writes their log files using a weird encoding format. My Get-Content fails miserably, resulting in text output where there appears to be a space between every single character. In Notepad++, the text looks fine, but I notice that in the bottom right-hand side it says "UCS-2 LE w/o BOM". Weird, this must be encoded differently. Get-Content works with some encoding schemes, but this one is not in the list. After much Googling, trial, and error, I am able to figure out that I need to read the file using get-content, then output to file using different encoding by using the -Encoding UTF8 switch. Now, however, the text file I have contains a bunch of NUL characters. To get rid of these I have to do a -replace "`0","". That's a zero, and the backtick zero symbolizes the NUL character. NOW I have some data to work with!
Great, so I put it all together, test it, and schedule it to run nightly at 12:01AM.
Here's the script:
#---------------------- BEGIN SCRIPT -----------------------
#Path to Malwarebytes Log Files
$PathToLogs = "C:\ProgramData\Malwarebytes\Malwarebytes' Anti-Malware\Logs\"
#Temp File
$TempFile = "C:\Temp\TempFile.txt"
#Yesterday date, as a string formatted yyyy-MM-dd
$date = (Get-Date).AddDays(-1).ToString('yyyy-MM-dd')
#Put together the filename we'll be looking for
$FileName = "protection-log-" + $date + ".txt"
#Put together the entire path
$FileFullPath = $PathToLogs + $FileName
#Read the content from the log file, and send it out with UTF8 encoding to the Temp File
Get-Content $FileFullPath | out-file -Encoding UTF8 $TempFile
#Read the new content
$UTF8File = Get-Content $TempFile
#Delete the Temp File, since we've read it now
Remove-Item $TempFile -Force
#Specify the character to be removed
$RemoveString = "`0"
#Remove the null characters from the file, creating a usable file
$CleanedLog = $UTF8File -replace $RemoveString,""
#Get the lines that have blocked IPs
$BlockedIPs = $CleanedLog | select-string -pattern "IP-BLOCK"
#Convert BlockedIPs to a string, so I can use it in the body of my email
$BlockedIPs = $BlockedIPs | out-string
#Send an email if there are greater than 0 IP Block messages
If ((($BlockedIPs | measure-object).count) -gt 0){
Send-MailMessage -To netadmin@contoso.com -Subject "PS Report - IPs Blocked by MalwareBytes" -Body $BlockedIPs -From "helpdesk@contoso.com" -SmtpServer "mailserver.contoso.com"
}
#---------------------- BEGIN SCRIPT -----------------------
Thursday, April 3, 2014
Exchange Calendar Issues
A coworker of mine went to Exchange World in Austin, TX this week, and we have finally figured out why we've been having such strange calendar behavior! Apparently, there are many issues between third-party vendors' ActiveSync software and Exchange Servers.
This article over at Network World gives a great description of the problem and what IT needs to do to resolve it.
This article over at Network World gives a great description of the problem and what IT needs to do to resolve it.
Subscribe to:
Posts (Atom)