You Learn Something Every Day

...Every day you look, that is. Today I was doing another Udemy video course and the video was showing the /sbin directory on a popular Linux distro. The usual suspects were there but I noticed, in the several versions of fsck, among stalwarts like fsck.ext2, fsck.ext3, fsck.nfs and so on, one for Minix, of all things, which is indeed still around. But I noticed something even more odd, that I wasn't sure was a mistake, or a smear on my screen: fsck.cramfs.

CramFS?! Is there a filesystem by that name? Surely that's some Intercal-type April Fool joke.

It's no joke. And don't call me Shirley.

The Compressed ROM File System is, like the name suggests, designed to take up very little space. It's often used for embedded systems (the whole thing) but also as an assist for bigger systems. It's really little. A file has to be smaller than 16MB and an entire file system is restricted to about 270MB. Although it's rather old and other schemes have taken over its uses in many Linux distributions, Debian continues to use it for initrd images and I understand that one or another version of SUSE uses it for install images. To maximize smallness (or perhaps stability) it's read-only, although it ships helpfully with some utilities like mkcramfs; that and others are contained in the Util-linux package.

Due to cramfs being obsolete by some arguments, many systems now use the also-weirdly-named squashfs. The tinyness theme continues. Ubuntu, Mint, Debian, Arch and many others currently use it for LiveCDs. Utilities for squashfs are available as well, and mksquashfs and unsquashfs have been ported up to Windows 8.1 at last notice.

And on top of everything else, both cramfs and squashfs, while they exist in a compressed form, do NOT, repeat, do NOT require uncompression to operate. Wow.

So if some admin tries to blindside you with insane Linux terms like these which in an alternate universe would probably not exist, thank me later. I would have lost a bet at the bar after a meeting due to tools named this way.

But first...

Before returning you to our regularly scheduled programming (Linux issues and security complexities), I'd like to do yet another list aimed at what professionals or security advocates seem to need to do on a regular basis with respect to the other 999 out of a thousand people. Imagine, if you will, a person of general knowledge who just got worried about computer security. This person asks you "What should I do now?". I'll give two lists as answers; the first will be for general users and the second will be for small business situations.

WHAT TO DO NOW TO IMPROVE YOUR SECURITY STANCE (for the general user):

1. BACK UP ALL DATA AND APPLICATIONS- Having only one copy of something is risky. Establish a routine and specific location for copying all data on all computers to a storage device or location. An automatic cloud arrangement is better than nothing but that cloud (a cluster or network or rented storage device) is not owned or principally controlled by you. Consider ejecting hard drives or thumb drives that can be placed in a fire protection safe, either on premises or somewhere else.

2. DOCUMENT ALL CONFIGURATIONS AND SETTINGS - All the operating systems and applications that your computers run are probably not at default settings anymore. In documenting all settings, you as well will be inventorying all the applications you use. Network and internet provider information, including contact phone numbers for tech support, would be needed as well.

3. CHANGE ALL PASSWORDS - How many months has it been since you changed pw's on some things - or anything? And never EVER stick with a default password; these are known by the bad guys.

4. UPDATE ALL VERSIONS OF SOFTWARE AND APPLICATIONS - Free security updates are often available for antivirus, operating systems, apps and other aspects of what you do. In the rare case of an update breaking something, backups will be what saves you.

=======================================================

WHAT TO DO NOW TO IMPROVE YOUR SECURITY STANCE (for small business)

1. BACK UP ALL DATA AND APPLICATIONS - Separate CD/DVD copies of all apps and OS's would be good, but saves (dd or other bit-for-bit) should do. Best would be to have a copy of the backup close at hand and another offsite.

2. DOCUMENT ALL CONFIGURATIONS AND SETTINGS - Look into inventory programs for this purpose, or having your staff person write a script. Scripts may already exist that can be customized or chopped down for your situation.

3. CHANGE ALL PASSWORDS - Enable password aging and imposition of use of complexity, as with mixes of capital and lowercase letters, special characters, disallowing dictionary words and password reuse and so on.

4. UPDATE ALL VERSIONS OF SOFTWARE AND APPLICATIONS - Here's where backups are important if any update breaks something. Multiple versions of some language like PHP might be needed for some web page situations, so updating could be tricky; check with your IT person or contract webmaster. The latest PHP could be needed for one thing, while a specific earlier version could be needed for another.

By the way... latest desktop rebuild story

I was given a Windows 10 desktop due to an associate having given up and gotten a new machine after 2 or 3 years. I, king of the museum pieces, had not seen such a recent desktop so was happy to get a chance to check out what was new. This all-in-one 26-inch touchscreen-with-wireless keyboard and mouse resembles to me more of a huge phone than a computer, but I'm not looking a gift horse in the mouth.

Until seeing the user-created files and such still hanging around. So it was time to bring the OS back from the recovery partition (staying with Windows for the moment), at least to see how that would fare. In the future, other OSs like Linux could come in via one of the only two USB ports provided (no ethernet or DVD burner included) but I stayed with what was on board as an experiment.

Lenovo's recovery app behaved as advertised. BUT as will be the case often, it won't go back to Windows 10 if it wasn't already there. This "box" began life at Windows 8. So it replaces that system, which wants about 225 updates in two or three hunks to get up to speed. Now, in about two days, the computer discovered that it could be Windows 8.1, so that was another 137 updates that it needed. Then another 10 security updates after that. Then another nine optionals out of ten (I elected not to put Skype onto this computer).

Then there were the little things. Put an adhesive cover over the camera lens. Grab a few utilities I favor (like SpyBot Anti-Beacon, Spyware Blaster and Mrs. Clinton's IT company's favorite, BleachBit (available for Linux, Windows and on command line for OSX). Uninstall lots of start menu crud. Go over it with screen cleaner. Oh, and if you do something similar like this, give things about a week to settle in. Some security updates won't go in until others do, so let's not assume Redmond got everything in the right order.

No Joke

The future of spamming and other sorts of online skulduggery looks so bright, we'll have to wear shades. The gag observation about toasters having a need for IP addresses (network access) is already losing punch. Over the last few years, we've seen quite a progression. First, remember when this sort of thing began showing up?

Several cable providers have offered over the last few years security systems operated via smartphone or tablet app (and I assume a browser version optimized for a desktop/laptop situation, I don't know). Then shortly thereafter, curious experimenters found holes in the application code, vulnerabilities in the wireless capability as well as the electromechanical controllers addressed by the application and so forth.

Then a year or so later, along comes...

Here's a refrigerator that has cameras inside so you can check current stocks of food (it temporarily turns on the light in there so you can see) from your phone while you're at the grocery store. The door also has a message center, allowing the phones of everybody in the family to send to the screen and leave notes "on the door" about where they are, who needs to be doing what when, etc. I haven't heard about anybody breaking into the embedded processor serving up all these pretty graphics yet - but I haven't had time to find out, since...

Only weeks later, here we have:

This is a new kitchen oven's application that, through your wireless router, has the oven send info to your phone so that you can control the temperature setting and cooking time from anywhere your phone can get a signal. Assuming of course that you're not two floors down in the elevator of an underground parking garage with no repeater antenna in the elevator car.

NOW jump ahead to less than five days ago: I was talking to a security consultant who, I noticed after a minute, had a small bandage on her arm. I asked about the injury - but it was NOT an injury. It was a rejection problem with her implant. An implant for a medical reason? No. It was for holding information that could be scanned... like a business card. She then mentioned the possibilities involving having an implant that could do short-range scans of network activity, or simply be satisfied with passive collection...

I already use a wallet with shielding in it so as to interfere with unwanted (surreptitious) scanning of my credit card information from hidden devices (my buddy got one of his card numbers swiped at a Renaissance Festival this way recently; he did not use a shielded wallet at that time). But I digress.

The point of this musing is that the Internet Of Things is, or soon will be, bigger than any human-operated network. And that this 'thing' network is being peopled by embedded, unmanaged or lightly managed printers, appliances, phones, automotive controllers, software and who knows what else - that might have access to flash storage or even a drive somewhere. Storage + network access sounds like a nice spamming or 'bot command-and-control outpost to me. And the growth of this lightly managed ecosystem is fueled by the convenience demands of people who, to put it mildly, are not network security engineers. Nor would their kids be network security engineers, either, to whom they've given droids and iPhones as toys. From this point it looks easy (since with IPv6 everything can have an address) for lots of chaff activity to overwhelm the network maintenance people, whose staffs are minimized for cost control reasons as it is. And chaff activity is now threatening to make Email unusable, in the same way that usenet was killed by spam posts. But this time it's not just a single application or feature that could be killed - but the whole communications system that could be clogged.

As soon as I've come up with a quick, easy and cheap solution to all this, I'll post again. Gimme a few days. [EDIT: well, whaddaya know. I'd considered joking in this article about wearable Faraday cages that we might need soon, but checking my mail, I'd gotten an ad for this yesterday: The Scott eVest clothing line, now with PAN, or Personal Area Network!. It's already effing here.]

Update of the updated update: According to the Information Systems Security Association (in a recent IoT webinar soon to be documented on YouTube), the IoT numbered around 14 million devices two years ago, and by some projections will hit 50 million by 2020. Several issues on the webinar's agenda prompt me to wonder how one would control what information was being exfiltrated through, say, a home router, and whether or not you'd want that in a hyperconnected future world. Putting aside the worry that every amateur network admin would instantly be committing felonies by running afoul of export restrictions when the cheap electric toothbrush or pacemaker phoned home to China, I speculate that control of data flow and connection requests could be automated with some program resembling antivirus with firewall, operating with an agent at the router. Of course, users have been known in periods of difficulty to disable A/V, firewalls and all else (or to elect not to install such applications at the outset), so perhaps a bit more attention is needed here...

Givin' Mr. Gregg Some Love

Around six months ago a user came into one of the meetings needing assistance setting up penetration testing capability. Briefly it involved setting up some target virtual machines in a virtually networked arrangement, and as I understood it, one could simply include a VM of Kali linux or Fedora Security Lab or some such testing distribution to get a nice tool set onboard with which to look at the other "boxes", and that would complete the arrangement. The virtualization scheme (a closed-source product) had become a bit problematic in a few ways and thoughts on that predicament have stayed with me. Looking back, I see three approaches that would profitably address such a set of issues:

1. Use the free tech support included with the virtualization product to address the specific networking issues we looked at in the meeting. We're an open source club and although it's possible that we have members familiar with almost any technology, the product was from a company with which our experience was limited. Unless I and others were missing something, it seems to me that a virtualization product (Virtual Box, VM Ware's latest chopdown version, Parallels, Hyper-V, whatever) should provide a basic network out of the box. Just add an assortment of OS's plus one pentesting specialist linux distro and you're done.

2. Guaranteed: most people will hate this suggestion with a murderous passion, but if it were me, I'd eliminate the virtual layer and simply get a switch and three or four separate desktops and/or laptops. For real; no VMs. I'd hook up a Windows box, attach a Mac, add one with OpenSUSE or any general purpose distro in the top 20 over at Distrowatch (right column under the ad block for latest rankings), and the last box would run Kali. Along with a nice Network+ class over at udemy.com, this would be what I'd think would teach network penetration best. After all, building a network is what you'd need to do by yourself first, in order to understand what you propose to penetrate. To keep the electricity bill down, I wouldn't run everything at the same time. I also benefit from not currently being married, so that would get me around the exclamatory reactions surrounding all the wiring and equipment laying everywhere.

3. I only wish, when the user's question originally arose, that I'd had a particular book to hold up in my non-virtual hand: Michael Gregg's "The Network Security Test Lab: A Step By Step Guide". It goes from the physical arrangement (either real or virtual) in the vein mentioned above to dozens of additional topics that flow naturally from the reasons one builds such a capability in the first place. He understands that pen testing is not an isolated capability. One needs an initial and intimate familiarity with the real estate that one proposes to explore.

This review is a preliminary one; it will provoke further articles from me. The book constitutes a syllabus for a class that universities should be giving if they aren't already. Of eleven chapters, 'constructing the lab' is confined to Chapter One. Further chapters address the whys and hows of using what Chapter One allows you to assemble. Passive Information Gathering is given its own chapter, discussing methods from banner grabbing to dumpster diving, in order to drive home the point that all information is not on the network - or perhaps ANY network, and the point that the more noninvasive the surveillance, the better. At least at first. Results from passive gathering will tell a tester how exposed the client is, which will make important reading in the results report. Properly, network traffic analysis and system identification are given separate chapters and the analysis chapter comes first, as the questions will occur on the way in. In the traffic chapter (chapter 3) you'll find Gregg is big on Wireshark as a main tool, wireless or wired as the problem may be. He quickly proceeds from packet basics to real-world examples involving tricks like VLAN hopping and different types of LAN taps. The System Detection and Analysis chapter (4) starts with a hex refresher and proceeds to discussions of services that different OS's tend to implement differently (this is the way nmap and other tools try to ID boxes on the fly). A basic example is the TTL: Linux time-to-live for packets is 68, Windows' is 128 and many hardware devices put it out to 255 (unrestricted). But later, System Enumeration is given its own separate chapter (5). There are further ones for Encryption and Tunneling (6), Automated Tools (7), security problems peculiar to wireless networking (8), malware (9), Intrusion Detection and more malware analysis from a post-intrusion perspective (10) and Forensics (11).

Some high points of those last chapters include discussions of password tools like PassTheHash (yuk yuk) and crackers that take slang like Klingon into account (chapter 6), assessment tool scriptability as with Nessus (NASL), metasploit (ruby or perl), nmap (lua/NSE) and point/click tools like BeEF and Core Impact (chapter 7), and resources on how various entities like retailers look for your phone in order to track you within their stores (chapter 8). I should note that Chapter 9 and 10 overlap; 9 is the introductory level of Malware discussion (using tools like Rootkit Hunter, virustotal.com, etc.) and 10 gets into the heavier stuff like IDS tuning (he prefers Snort since their maintenance site has many preconfigured rules and signatures to get you started).

My compliments to the chef. This is a well-written and current resource that I'll be turning to again and again (I require much repetition to learn and Gregg repeats what I need repeated). He also writes for the Huffington Post website; check him out there.

Review: The Hacker Playbook 2: A Practical Guide To Penetration Testing
by Peter Kim
1st Edition, July 2015 / SecurePlanet LLC / ISBN-13: 9781512214567

I got a copy of this text from a class I just completed, which I'll describe in greater detail when you see me in person at the meeting. What it's important to get down in this review is some descriptions of the content (which is up to date) and that those descriptions be delivered in the proper order. For some reason this first printing either didn't get enough proofreading or the setup editor screwed up, not bolding or increasing font size on chapter headings, nor even numbering them. So I laboriously found all the chapter headings and will organize my comments by them below, for your convenience if you acquire a copy of Mr. Kim's excellent book (after figuring the headings out, I just marked them on their pages and on the Contents page with a highlighter so that they became useful). Also, the descriptive conceit of the book uses analogies to game plays and strategies in American football so as to separate concepts, so keep that in mind. By the way, the "2" designation in the title doesn't mean that you need to look up the previous one; it denotes a second edition which includes all material still useful from Kim's earlier volume, with updates and additional coverage of tools and strategy as relevant to about 10 months ago.

"Pregame - The Setup" amounts to Chapter 1. This covers the physical setup needed for pen testing. He describes your lab as needing such features as virtualization software, particular VMs representing popular OS's, and mentions particular aspects of popular systems such as Powershell in Windows. Finally a "Learning" section has some early discussion of tools and strategies like Metasploitable and issues like lack of secure form in binaries.

"Before The Snap - Scanning The Network" amounts to Chapter 2. Passive observation and discovery is the first topic, noting tools like Recon-NG, 'discover' scripts and Spiderfoot. I should mention that all versions are referring to Kali Linux inclusions. Kali Linux is one of the largest and most popular security distributions and it's referred to so much here that an interesting secondary use of Mr. Kim's book would be as a Kali manual.

IN FACT, Kali Linux is so badass, go get a copy right now if you don't have it, at this convenient location.

Coverage proceeds to password lists, looked at with Wordhound and Brutescrape, then with active tools like Masscan and Sparta. Then some vulnerability tools are introduced like Rapid7/Nexpose, Teneble Nessus and Openvas. Web apps are looked at with OWASP Zap proxy, which is available for Windows, Linux and OSX. Finally, nmap, Burp and straight Nessus are mentioned.

"The Drive - Exploiting Scanner Findings" amounts to Chapter 3. It starts with a Metasploit Framework example which, while comprehensive, assumes previous experience with Metasploit and gives links as to where to get up to speed with that. Then there's a discussion of printers, Nosqlmap and Elastic Search. Then some recent issues like Hearbleed and Shellshock are described (no doubt some stalwart professionals are still vulnerable to those).

"The Throw - Manual Web App Findings" amounts to Chapter 4. There's a general intro to web app pen testing and SQL injections as such, then a generous 15 pages on manual SQL injection methods, followed by 5 pages on Cross Site Scripting. Other topics covered are Cross Site Request Forgery, tokens and fuzzing. Then Kim gives a mention of the Top Ten vulnerability list maintained by OWASP (I'll give it here for your convenience):

OWASP Top Ten cheat sheet

"The Lateral Pass - Moving Through The Network" amounts to Chapter 5. Responder is the first tool mentioned; included in Kali, responder.py looks for multicast name resolution and NetBios information, and uses the Microsoft WPAD vulnerability (there's a TechNet article on that; evidently the service's PAC file points to a config file that's wide open, if you can find it). Then ARP poisoning is discussed from the standpoint of two Kali-included tools (ettercap and Backdoor Factory proxy) and Cain And Abel for Windows. Two methods for getting network access at this point are given, with specific steps. The methods are either 1)with any credentials or 2)with Local Admin or Domain Admin account info. Two tools for manipulating the domain controller then mentioned are SMBexec and PSExec_ndtsgrab, both in their Kali inclusion versions. The convenient strategy of creating access "persistence" is then brought up, listing popular tools for this as Golden Ticket (a Kerberos crack), Skeleton Key (a domain admin backdoor) and Sticky Keys (a sort of automation of hitting Shift five times on a Windows host; this idea uses registry settings, which seems nonstealthy to me if the registry is locked or monitored in some way but this is one of Kim's favorite tools so I'll defer to his experience).

"The Screen - Social Engineering" amounts to Chapter 5. The expected phishing and wireless methods are covered, but there's also the tale of the author's actual purchase of similar domains as targets to take advantage of typographical errors when users enter domain addresses. He links to his complete research paper but also describes this very nasty idea, popularly referred to as "doppelganger domains". If an outfit uses their subdomain for email and somebody mistypes, BANG. They go to the bad guy's location instead. To make a long story short, these similar addresses can be incorportated into links in emails or into icons on which to click. Do you want to maim somebody all of a sudden? I don't blame you. Then there's the methods that involve the risk of physical access, like planting rogue access points, dropping USB sticks with hidden file infectors in the hall or parking lot, purchased devices for smart card cracking, KonBoot on USB for at-the-host password bypass and on and on.

"The Quarterback Sneak - Evading AV" amounts to Chapter 6. BDF (backdoor factory) is included in Kali and its methods of changing the functionality of normal services is described in minute detail. Next is a method for using a tool called Evade to allow another tool (Windows Credential Editor) to cloak itself from antivirus programs and snatch cleartext passwords FROM MEMORY! Neat. Then there's a discussion of Veil, a tool that hides executables from AV detection by automatically re-coding them in Python. There's SMBExec, which is a suite that can get hashes out of a domain controller, randomize or recompile things to render the observable form unfamiliar to the AV scanner (not merely changing the filename), create reverse shells, etc. He wraps up by describing some keylogging methods.

"Special Teams - Cracking, Exploits And Tricks" amounts to Chapter 7. Lots of helpful wordlist locations are given, then particular tools John (John The Ripper, JtR, JtR Jumbo) and oclHashcat are described. oclHashcat assumes use of a GPU and is mentioned as the author's favorite password cracker... although he does refer to historical use of Rainbow Tables. Specific vulnerability searching (within Kali at least) is described in the context of Searchsploit (for default queries) and the venerable BugTraq and Exploit-DB, not to mention msfconsole. Kim also gives specifics on bypassuac_injection, NetHunter (EXCLUSIVE to Kali/Offensive Security, it's an Android pen test platform) and he adds a description of building a custom reverse shell, which can get around firewalls and IDS. He also mentions three commercial products, Cobalt Strike, Core Impact and Immunity Canvas. Although Cobalt Strike costs thousands, Kim says that it's "must-have" for professional pen testers.

"Two Minute Drill - From Zero To Hero", a kind of Chapter 8, is a rundown of what's now possible to you, once you are familiar with the tools involved. From the initial stage of "discovery" (as the lawyers say), you use a fake website to spoof their Outlook Web Access page (that hole was left open for awhile on Hillary Clinton's email server, so although little was logged, it's a promising area of concern for that organization). With a Meterpreter script to add persistence on reboot for everything done so far, you'd then run PowerUser to create a new Administrator and find all the Domain Admins. Getting at least one of their passwords, the hashes are pulled from the controller and you dump the AD environment. Persist later surrepitious entry with Sticky Key and all that's left is the documentation paperwork and to invoice your satisfied customer!

I wish I fully understood everything I described above, but luckily I've got Kim's book. This provides either clear, specific steps to do what's discussed, or where that would assume previous knowledge, Kim gives links and references on where to get the knowledge. To read this book is time well spent, if pen testing is what you need to do, or need to be able to sell to a reputable actor, of course.

But This Can't Really Happen... much?

Here's the recent story on that deletion mistake, which was a marketing ploy by somebody (HOAX), but it resembled actual incidents I recall from my days working with a hosting provider:

Guy Deletes Entire Company

Yes, it's indeed possible for somebody to come up with a script that has a mass deletion command that isn't properly limited to the current directory or restricted by file privileges (in linux, Microsoft, Unix, Mac, what have you). The Admin or root permission is really powerful, and you should remember to include in the batch file or script the highly specific location(s) that any destructive command needs to work on..

But how would you architect some protections into this? One could go on and on, but the story seems to suggest a one-man operation without a staff, meaning without a professional admin, or even admin company (outsourced). Common situation. Even such an outfit as this one-man-band could benefit from two backup servers (the one in the story had an open connection and presumably its drives were mapped/mounted, therefore got the deletion command along with all other nodes that could be reached). What I'm suggesting is that, with two backup servers, you give one a regular address and the other a private, nonrouteable IP. Script a dd or other copy command from the regular server to the private server and never connect to the private server directly. That makes the first backup server a "staging area" and the second a pseudo-offline location.

Another thing to think about is to make the two backup servers physical (not virtual) servers, since if anything went wrong at those locations (and much of everything else was virtual in order to save money), you could do recovery efforts there since you'd have exclusive access to the drive(s) on those boxes, rather than on some cloud or multiple account arrangement, which would possibly overwrite data with other customer's stuff. I'm sure there are other and possibly better ideas but the simplicity of this second server as a fail-safe is compelling for this more-than-plausible scenario. And further, the backup scheme could treat the first server (staging) as holding only the last one or two backups so they'd be at hand for rebuilds and the second pseudo-offline private server would be for the archiving of a larger number of backups.

[Edit: While the above story about the guy deleting the company with a single code line has its implausibilities, I was told by a colleague about a similar situation having actually occurred a few years back. A local bank had set up much of its capabilities virtually, not just with servers fulfilling specific duties but with virtual networking as well (at least a few virtual switches). Something went wrong in accounting and the cloud provider didn't get paid on time and about 100 boxes just disappeared. That's the way it works when you miss the rent - something else happens automatically (knock at the door, late fee, whatever). In this case, I understand backups went somewhere else (hooray) but the boxes themselves had to be rebuilt and reloaded from backup by poor Mr. Admin - which was one guy, not involved with the problem but still getting the heat. Just another day on duty!]