For my first post to Salted Hash, I figured I'd start by way of an introduction. So without any further ado, here goes. Hi. My name's Steve. I'm new here.
For the curious, I'm a father of two, geek, hacker, and journalist. This is my fourth month with CSO, but before that, I helped start and manage The Tech Herald, and I've worked for a few other news outlets along the way. I've been a journalist for many years now, but at my core, I'm an IT guy with a strong background in security. For the most part, with one exception, I worked with SMBs and mid-level enterprises.
Most of you reading these words are at work. I know, it's cheating because that's an easy guess to make, but my point is that I know from firsthand experience what it's like to sit at the desk and deal with the constant flood of requests that come into the work queue. Moreover, I remember the stress and frustration that came along with many of those requests and learned to treasure the serenity those few moments of mindless Web surfing offered, even if I was limited to news sites and domains not blocked by the Web filters.
My aims for Salted Hash are simple. I'll focus on news and information, as well as mix in some interesting stuff that can make life simple along the way for those of you in the trenches. I'll also focus on the various types of threats that are circulating on the Web, and wherever possible, tell you exactly how to address them or point you in the right direction. Sometimes, I may just offer a list of articles that I found useful / interesting / helpful / amusing, and present a round-up type of post.
I'll also welcome thoughts and suggestions, and I encourage you to make use of the comment section to add to a given topic, rip it to bits, or suggest additional (relevant) things to research and report on. Likewise, my contact information is widely available, so feel free to reach out.
With that said, while I'm open to discussions and ideas on what to cover on Salted Hash, there are a few things I won't be doing. I won't cover product news, and I won't cover general corporate news. This isn't a gossip blog, so industry drama, or pitches about so-and-so getting a promotion won't cut it. Likewise, version x.4.b of Widget Inc.'s super secure appliance is never going to hold a feature place here. The way I see it, you're pitched enough as it is during the work day. However, this also follows the general rule of coverage on CSO, so I'm not really doing anything out of the ordinary.
Tools however, well those are a different story - especially scripts that make life within the NOC / SOC easier, or help IT teams better manage their resources. I plan on researching and covering as many of those as I can.
To start, I'm going to cover a BASH script I discovered years ago, and used on all the LAMP (Linux, Apache, MySQL, PHP / Perl / Python) deployments I managed.
The script is called SploitFinder, and it's useful for scanning user directories for uploaded webshells. Granted, by the time you looking for webshells, there's already been a breach, but if you patch the vulnerability and leave the backdoor standing wide open, then you still have a problem. However, it will locate many of the common backdoors that attackers use when they target CMS installations, and other vulnerable scripts.
This script was most useful when it monitored directories where applications such as Joomla, WordPress, or Drupal were installed, as the website owners didn't really work to keep the core installations or add-ons updated. It's a simple script, and I admit it isn't the most efficient, but it works. In fact, it's saved my bacon many times during incident response.
The downside is the speed of the scans. On a highly populated webserver that was split into chunks for webhosting resellers, the script didn't drain resources, but it was slow when ran at peak times.
SploitFinder scans for 20 different kinds of webshells, but the search parameters can be edited in the script itself. There are various reporting levels to pick from within the script, but it's often easier to do an initial scan, with the results delivered via email, and then create a CRON to run it regularly. Each morning, I would read the scan results with a cup of coffee, and if needed examine a file by hand.
If you just want to see the suspect file and where it is located, then use the -m switch in SploitFinder with your email address. Otherwise, if you use the -acm switches along with your email address, you'll get a full report with file location, and the exact lines in the source code where the red flag was raised. I'd also recommended that you use the reset flag (-r) weekly or monthly, in order to keep scans fresh.
Feel free to leave thoughts, suggestions, or recommendations on additional resources below in the comment section.