Showing posts with label opsec. Show all posts
Showing posts with label opsec. Show all posts

Sunday, August 28, 2016

The Dark Side and Physical Security.


I recently saw a vine on Twitter, that joking shows someone plugging a USB keyboard into a USB charger, acting like the Hollywood style of hacking. The amateur didn't wear gloves. I myself have pictured a cute, spunky bubble-gum chewing teen with pink and black hair, completing a hack, then turning to the camera, pulling the gum from her mouth and shoving it into the RJ45 port she was using on the wall, whispering in a sultry voice, something along the lines of “always cover your tracks.” While the saliva on the gum might short something, it’s not the real threat. Physical security is a real necessity; watch Twitter and Facebook and you see RJ45 connections, open USB ports, and all sorts of other connections just waiting for the right person, with the right know-how to steal or manipulate information in systems acting as things like standalone ATM machines, voting machines, and Point-of-sale terminals. Undetectable in some cases, these are real threats.

There are a lot of articles out there about key loggers and computers on a stick that people can plug into systems and television sets, but there is a dark side to physical security as well; the people who don’t want information, but rather to cause downtime, expense, confusion, chaos, and distraction. Anyone who has soldered wire understands about heat and protective coatings. When I worked IT, I never patched a cable into a network switch where I wasn’t expecting a live connection. Too many people can sit down with a personal laptop and plug in, but it’s not the real threat to the machines on the other end unless it’s the right person.

Often, a real threat is less than a meter away.
See, the electronic world we live in runs on low voltage and amperage. It expects 5v, 2 volts, and a single volt on a connection sometimes. It’s not designed for someone to take an extension cord with an RJ45 tip on it, and shove it into the socket. A couple of things happen: if that cable is connected to anything that makes a short, it will likely trip the breaker, depending on the device, but prior to that it sends a surge of electricity down the line that can melt the jackets off of thin UTP CAT-5 cable, potentially causing a fire, and additionally it can pop multiple resistors, capacitors, and switches in expensive, highly-sensitive equipment. Plugged into a disconnected battery back-up, it can produce a charge that repeats with a simple reset. This can fry motherboards, breadboards, and simple circuits with ease.

In terms of operation security, or opsec, someone may use a device such as this to plug into USB ports to short motherboards, CAT 5e to damage network connections and network hardware, and even phone terminals, shorting switchboards. Additionally, someone could melt components in cell phone, rendering data unreadable, inaccessible, or very difficult to obtain in a time of need. Can’t call in emergency with no working devices.

I’ve seen homemade devices as well, where someone takes the guts from a $5 disposable camera with flash, and uses the step-up transformer and high-output capacitor to deliver a charge to electronics. It’s some scary things to consider. So if it doesn’t need to be connected, disconnect it, and cover unnecessary ports on open machines. Additionally, remember not to leave portable devices laying around. While someone could use your phone to take obscene pictures, they can also prevent you from making a call if you’re being set up.

Monday, July 6, 2015

44 practices for #security & #IT professionals, post #HackingTeam hack. #infosec #opsec #appsec #devsec

Go easy on me, but this should serve as a list of good security practices and habits for security practitioners and professionals, and even some IT professionals who are up for the challenge.

Okay, so call me paranoid, but I’ve been around the block a few times on this stuff.

General guidelines
  1. Use strong passwords. I can’t stress this enough. This should go without saying, but don’t use a password like “kittens.”
  2. If you’re storing passwords salt them. If you can, use unique salts.
  3. Change passwords regularly. Added layer of protection. Also works to defeat rainbow tables in the event you don't salt.
  4. Encrypt your volumes. If you’re not using it, then lock it. Nobody needs 400gb of online hacking wares at any one moment, unless of course they’re stealing it from you.
  5. Use unique passwords. If someone gets your one password, then you’re pwnd. If you have multiple passwords, then it’s harder for someone to gain access to your multiple systems and do things like pivot. Yeah, it's not as easy as the one login for domain controller, but if you're breached, you'll thank me.
  6. Don’t trust anything. I see people plug random stuff into their machines. If you are someone who is out in the field, then definitely don’t bring any foreign contaminants back into your domain.
  7. "Check this out" <-- famous last words.
  8. Test with a VM. If you hose the Virtual Machine's snapshot you can always revert to a safe snapshot. Make a snapshot of a clean system first.
  9. Use a good Antivirus. This should go without saying, but a system that connects to other systems and networks needs other defenses than the ones built directly into the OS, unless of course you’ve written your own OS, then nevermind. While AV doesn't protect against everything, not having AV is going without protection.
  10. Don’t trust end nodes. If you’re not physically there, you don’t know what you’re on.
  11. Never use warez. If you're a pro, then buy the apps and write them off.
  12. Use a connection other than your main office network connections to get to the web for work like pentesting. If you’re using the connection your servers get updates on for hacking a target you are asking for trouble. “Someone’s hacking us; and their IP reverse look-up has an Exchange Server.”
  13. Use a read-only image for core systems. If you’re using a laptop, don’t put anything on the harddrive that can be used to monitor the system, instead use an image on a thumbdrive for the OS. It’s a lot “safer” because if someone gets your gear they don’t get your work. Also you can pocket a thumbdrive or store them in a safe when they’re not in use.
  14. If you’re doing forensics work, store the results on removable drive. This helps to keep the evidence clean from contaminants. Also encrypt this device. See #4.
  15. Keep records and logs. If something looks out of the ordinary it will be easy to spot. If you don’t, then you can’t tell what happened. And those types of postmortems are exactly that, a real postmortem.
  16. In case of a hardware breach, sweep for foreign signals coming from the infiltrated system. If it’s off, yet broadcasting then that’s a hint that something is up.
  17. Restoring a backup does not fix the issue that allowed a breach.
  18. Be careful what you say or post, you never know when someone will paraphrase something or something might be used against you.
  19. Use two-factor authentication where possible.
  20. If you’re using social media, don’t use it from your operations center. "Look they has a Twitter, I wonder if I can get them to click on this malicious link?" Now they have your IP and your User Agent. Spearphishing anybody?
  21. Use a different MAC Address than the one embedded in your card. Switch this from time to time and scan to make sure nothing has cloned your MAC. "I thought you change it?" This little trick can help throw off a would-be attacker from the type of device you're using if they're using your MAC to pinpoint.
  22. If you’re connecting to foreign networks use a throw-away wifi card if you can’t change your MAC. This also helps with driver issues if someone knows the type of hardware you roll with and they are specifically targeting you.
  23. If your operations don’t need web access, then keep them off of the web. Download patches on a different machine and rebuild the system image.
  24. Stay up-to-date where possible. If some application, driver, system, or piece of hardware prevents this, then at least update everything else. Nobody likes getting nailed because of a 3-year-old exploit.
  25. In regard to peripherals, if you’re not using it, turn it off. For example some bluetooth devices and systems only look for services. They don’t prevent attacks from non-disclosed services. Eg. My computer looks like your Bluetooth headset to your computer, but your computer gives me access to your computer because it trusts your headset. This could also work for mobile phones and other devices.
  26. Also see #6. I’m not one for paranoia, but if it looks like it’s been tampered with, then you don’t want to trust it.
  27. Mark your drives: just like bags at the airport, all thumb drives look alike. This goes for external hard drives as well. Think permanent and unique.
  28. If you’re researching a specific piece of hardware use gloves. You don’t know where the user has been or in the case of a laptop, where the device has been. Also it helps to maintain the integrity of the scene and evidence in the event of escalation.

Offsite operations
  1. Use a tunnel like a strong VPN, this way when you’re remote, you can at least make it harder for something to access your system. Also the bonus is your traffic is "encrypted."
  2. Encrypt your traffic. If TLS is an option then use it.
  3. Everybody can be traced. It simply takes time, but don’t ever assume a multilayered encrypted connection is non-exploitable.
  4. Use Faraday bags where necessary. If it broadcasts you can stop fix that pretty quick.

Onsite systems
  1. Use a RAID. So many times I go into an office and there is no redundancy for the important volumes.
  2. Keep offline backups. If you’re working on a hot project, definitely keep offline backups. If you’re infiltrated and someone wipes your data you need to know what you had access to at that moment. Also this helps with issues like ransomware.
  3. Keep offsite secured backups. This protects against fire, raids, and that odd instance where all of your equipment and assets are seized pending clearance.
  4. Watch for unwanted traffic on your network (assuming you have one). If someone gets in to your system, then you are pwnd.
  5. If you don’t have gloves and must use an infected system, then use your own keyboard and pointing device. Also this isn't a bad idea either because if the machine has a device with a keylogger built in, this is an added layer of protection. (I've seen employees fake an incident to capture an admin password on one of these devices). Found out because the Admin account was logged right back in 2 minutes after the admin left for the day. When asked, the employee confirmed they intended to install pirated software that required administrative privileges. 
  6. Clone the drive you’re investigating before accessing (if possible). If you trigger something on that drive it may try to cover its tracks.
  7. Just because it’s in a foreign language doesn’t indicate a foreign act. Stuff like Google translate lets people make stuff that looks foreign all the time. If you don’t speak the language ask someone else if it’s legit. It may be an attempt at obfuscation or even gibberish to throw off an investigation.
  8. Scan the traffic and memory prior to disconnecting an infected system, unless the infiltrators are in the process of removing data, then immediately disconnect the system. If you can run memory forensics analysis on a system, then it might give clues as to how it was infected, what it is doing, who it was contacting or even simply what type of infection it is.
  9. If something is removing data actively on a drive, then take the system offline (not down). If it’s memory resident attempt to kill the process. If that doesn’t work, try to break the process with injections.
  10. Learn what everything on your network does and what its habits are. If something looks out of the ordinary it will be easy to spot. An example might be a VOIP phone trying to gain SSH access to other resources.
  11. If at all possible use a Faraday cage to prevent external wireless intrusion. You don't really need to access your wifi from the parking lot do you? With a booster someone can access your network from a greater distance. If you can use exclusively wired networks in a setup, then that's the "safest" bet.
  12. Layer your defenses, why only use one firewall? I mean if it's that important, then it's okay to have a little lag from proper countermeasures.
Hope this helps somebody. This security stuff can be a can of worms at times. Got anything to add or think I got something wrong, shoot me a message on Twitter: @cpattersonv1

Update:
While 44 is a good start, as I think of more I'll add them here. These are more for closely related to Good IT practices.
  1. Know what's in the network rack physically. If something looks like it doesn't belong then it likely doesn't. This could be anything from battery back-ups to switches, routers, and I've even seen extra servers in a rack before. Famous last words "I thought it was ours?"
  2. Take an inventory of known, purchased equipment. This helps with #45.
  3. If systems are checked out, inspect them for exploits prior to checking them in. If the operating systems on the devices aren't using read-only images they could be infected.
  4. Develop acceptable use policies for equipment and network access and enforce these policies.
  5. If it's infected, then clean it. Nobody likes to be reinfected because someone found a spare drive laying around.
  6. Record all of the MAC addresses for internal hardware expected to be on the network. For virtual machines document any custom MAC addresses as well. This helps in situations where someone has planted an extra device. Also it helps to see if an employee might have an unsecured device on the network by using an app like Wireshark.
  7. Clean up the cable nest. It's a lot easier to spot a cable in rack that's out of place if the cables are grouped in an intuitive way for spot checking. All too often with a cable nest or wad it's difficult to find unwanted physical intrusion; especially in a place like a shared hosting rack space where an extra cable can find its way through the floor panels or from the overhead wire tray. While they might only be stealing bandwidth, they could be passive scanning.
  8. Setup a camera on the server room: motion-activated "critter" cams that work in low light work well. Have it transmit to a service or device offsite when the system is triggered immediately, this will help with tampering. If at all possible, hide this in a different housing.
  9. Use managed switches that support port isolation on the network. Get the kind that allow passive scanning at the switch level. While traffic might be encrypted you can tell where it's going at least. 
  10. Actually configure SNMP and utilize it. This management protocol can really help with detecting intrusions and failed equipment which can present symptoms similar to certain attacks like DoS and floods.
  11. If a network port is not being used, disconnect that node from the system at the rack or in the switch room. This way extra device access can be limited as an added layer of protection.

Tuesday, March 17, 2015

How a custom virus caught a liar.

I don’t remember the names. It was sometime in the late nineties when I received a phone call from an ex-girlfriend who worked for a military contractor. She said she was sort of on the rebound from a relationship, but needed my assistance with a “computer issue.” I drove for over five hours to get to her house. Here I find that she’s cohabitating with her current “boyfriend,” but they are separated momentarily; and they also have another roommate, a girl, who she wanted to introduce to me. He was a computer science major, if I recall correctly, which is why she needed some “training to teach him a lesson”; rather unintentionally she was provided with a method of making a self replicating virus.

When I arrived we went out to dinner with her roommates to a local sports bar. We had a good time until someone started hitting the sauce. After we returned to the house, she pulled me aside and explained the issue: her ex, or soon to be ex- or whatever his status was at the time, had allegedly been looking at pornographic material on his computer. I didn't think this was a crime, but they had an agreement that he was not to look for pornography because apparently it had been an issue in her last relationship to the point that it haunted her. Her other roommate had heard him, clued her in, and when confronted, he lied in response about looking at it; and so she wanted to prove he was lying, but didn’t know how. She didn’t know where to look, and was afraid that any attempt for her to show him would backfire as he could say it wasn’t his, too many roommates. It was sort of a communal terminal.

I felt sorry for her, so rather reluctantly, I decided to enable her to prove, rather embarrass him with, evidence that he’d been looking at the things he was not supposed to be. Had he not been a jerk most of the evening (mean drunk), I probably wouldn’t have gotten involved, but at the time I still had weekends, so it was a mini-holiday.

For the record, I never touched his computer, and never touched her computer. I simply conveyed to her, a computer science major at the time, in theory how to write a couple of scripts that could modify the Windows auto-execute batch file to make something that worked like a virus, on her computer; theoretical stuff really.

First I explained to her that she needed to not touch the computer. If it at all seemed like she had any time with the machine, then the game would be up. I theorized on how she could write a little batch file that would write another batch file and clean up after itself. This other batch file could scour the Temporary Internet Items directory for video files and porn-sounding jpg names. Any files it located could then be copied to a new hidden directory of some obscure name, completely random even. The file extensions could then be changed, so they would not look like videos if someone were to do a search for videos on the hard drive, this way the batch could replicate them again into the startup and IE temporary items folder, by searching for their new unique extensions upon restart.

After searching for the files and copying them to their new location, the system would then, in theory, copy them to the startup folder in the start menu; then the batch file could patch the Windows registry runonce menu to trigger a new instance of itself, just in case the batch wasn’t called on the next restart.

The poor guy was using Windows 95 without service packs.

Upon loading Windows, a little snippet could be placed about 1000 lines down in the autoexec.bat file. If this sort of script was able to install itself from a floppy on insertion (not really a batch file, but something like autorun.inf), it would be much more detrimental of course. So in theory, all someone had to do was pop in the floppy, let Windows access the  disk, then they could eject it. Smeary fingerprint on the eject button would be the only indication of tampering, if someone tried to determine an origin.

The next day, after having me sleep on the floor in her room to further boil the poor guy’s blood, we spent the morning watching television in the main room snickering about my theories. He was hung over; his computer was in the hallway, waiting. When he came back from the gym he turned his computer on. My friend walked down the hallway and popped a floppy into the drive after he had booted the machine up. She then asked "are you going to use your computer," to which he said, "You've had all morning to use it, I just turned it on, so yeah, I'm going to use it." She promptly removed disk and turned the volume all the way up on the guy’s Labtec speakers. All of this happened with him watching, but nothing suspicious. The computer had become a dynamic of control in their arrangement.

About 30 minutes later he comes over to the computer and reboots it; it had locked up; no service pack was installed, it was poorly maintained, that sort of thing. Five minutes later we hear this blaring cacophony of multiple moans and grunts overlapping with the soundtracks of roughly 10 adult videos featuring who knows what, all playing simultaneously. Windows was nice enough to tile their display when the system started; we could see it from the couch, raunchy stuff.

Leaning back in his metal folding chair, he slams his chair forward and turns off the speakers. “What are you watching hon?” she says from the living room, the guy’s face is beet red. He closes all of the windows with alt-f4 repeatedly before she makes it down the hallway to “get a drink” from the kitchen. Then he proceeds to delete all of the items from his startup folder. He looks at me, he was about twice my size and I was 220lbs at the time, and says, “You had better not touch my computer again.” I told him I hadn’t touched it, and that he probably had a virus from looking at porn sites. I gave a plausible response and told the truth, having not touched his machine, omitted a couple of details, but didn't lie, technically.

About 30 minutes later he restarted his computer. Surprisingly the same thing happens again. He looks at me and says “what did you do?” I truthfully said “I haven’t touched your computer man,” with one of those smirks to make him wonder. He calls his friend, The Computer Guru.

This guy shows up, he walks over to the computer, looks back at me and glares. I don’t know what her boyfriend at the time knew about me, but whatever it was, he had his suspicions about what he didn’t know after that day. The computer guru guy goes in and deletes all of the IE history and temp internet items. Then deletes the items in the startup folder. “Watch this though,” her boyfriend says, as he reboots the computer. Same thing happens again. Computer guru goes in and removes all of the items as before, and this time does a search for videos, finds nothing oddly enough. He restarts the computer. Same thing happens again. Then he restarts it again, problem is compounded because there was no theoretical statement to check for existing video and picture files. He tells her boyfriend, “don’t reboot it again, I’ll be back.”

Enter Windows 95 for Dummies

The computer guru guy shows up with his tattered copy of Windows 95 for Dummies in-hand and a box of 3.5in floppies containing antivirus and Norton disk utilities; I always wondered why that book was so popular. He boots from a floppy, runs chkdsk, tells the guy he’s searching for hard drive errors that could cause the system to not be deleting the items from the temporary internet items folder, I'm off the hook at this point, so they relax around me. He also runs defrag. An hour goes by. Her, her other roommate, and myself go to the bookstore, hang for an hour, then we come back. They’re still at it. “I don’t know man, we’ve done everything I can think of.” the guru says. He pops in the Windows 95 recovery disk, rebuilds the system to factory defaults, without reformatting. This defiles the registry. Windows loads for the first time after the reinstall, videos all still in place. Mad, he throws the keyboard.

They reformat.

2 hours later, “where did all of my files go?” the boyfriend says. “I told you I was reformatting,” replies the guru. He looks at my friend “got any spare floppies?” She replies, “Yeah I’ve got one.” Brings him the disk. I grinned, gave her a hug, told her she was evil, and promptly left. The next week she calls me to tell me that he bought another computer, Windows 98 this time, and "geez, if it didn’t develop the same sort of characteristics a couple of days after he bought it." Poor guy... if only he hadn't lied to her.

So I've been thinking to myself, ethically, was it wrong to help her? Knowledge in the wrong hands... I'm glad I was on her good side.