What does a malware analyst do? Find out on today’s episode featuring Dr. Richard Ford, Chief Technology Officer of Cyren. Richard talks about breaking into the field, whether a computer science degree is or isn’t essential for the role, and an early program he wrote to brag about his high score to his classmates!
0:00 - Intro 2:30 - Richard’s cybersecurity origin story 6:07 - Being an IBM anti-malware researcher in the 90s 9:18 - How malware has evolved 11:27 - Major career milestones 18:14 - Two types of malware analysts 21:42 - How to get hired as an entry-level analyst 25:45 - Day-to-day malware analyst tasks 29:40 - Transitioning to an analyst role without any experience 34:30 - What does Cyren do? 37:25 - Outro
Dr. Richard Ford is the Chief Technology Officer of Cyren. He has over 25 years’ experience in computer security, working with both offensive and defensive technology solutions. During his career, Ford has held positions with Forcepoint, Virus Bulletin, IBM Research, Command Software Systems and NTT Verio. Dr. Ford has also worked in academia, having held an endowed chair in Computer Security, and worked as Head of the Computer Sciences and Cybersecurity Department at the Florida Institute of Technology. Ford holds a bachelor’s, master’s and D.Phil. in Physics from the University of Oxford. In addition to his work, he is an accomplished jazz flutist and instrument rated private pilot.
About Infosec Infosec believes knowledge is power when fighting cybercrime. We help IT and security professionals advance their careers with skills development and certifications while empowering all employees with security awareness and privacy training to stay cyber-safe at work and home. It’s our mission to equip all organizations and individuals with the know-how and confidence to outsmart cybercrime. Learn more at infosecinstitute.com.
Learn how mentors in the cybersecurity community can help launch your career on today’s episode featuring Mike Gentile, the Founder and CEO of CISOSHARE. Mike discusses the CyberForward program, which creates a mentorship and support system for new students of cybersecurity — often those with diverse cultural or economic backgrounds! CyberForward addresses not just skills training, but quality of life issues that might prevent entrance to the security field. If you’re feeling blocked and unsure how to enter the industry, you’ll really want to hear this episode!
0:00 - Intro 2:24 - Starting a career in cybersecurity 5:39 - Creating CISOHandbook.com 7:35 - What is CISOSHARE? 9:38 - What is CyberForward? 11:15 - Thoughts on the cybersecurity skills gap 17:40 - Mentoring students through CyberForward 25:13 - The training value system is broken 29:33 - Creating a network of support 32:44 - Helping the “beaten down” break through 36:52 - What’s next for CyberForward? 39:15 - Advice for getting started in cybersecurity 43:28 - Outro
Mike Gentile is the Founder, President and CEO of CISOSHARE, headquartered in San Clemente, CA. He has led the company since inception to become a global leader in security program services and solutions. Initially an experiment, the CISOSHARE culture centers around learning and teaching to make the confusing security discipline understandable.
In 2019, Mike founded CyberForward Academy by CISOSHARE using this learning and teaching culture to address both the cybersecurity resource shortage and the livable wage gap issues felt in many communities. This partner-enabled professional development program identifies and then rapidly develops effective job-ready cybersecurity professionals.
About Infosec Infosec believes knowledge is power when fighting cybercrime. We help IT and security professionals advance their careers with skills development and certifications while empowering all employees with security awareness and privacy training to stay cyber-safe at work and home. It’s our mission to equip all organizations and individuals with the know-how and confidence to outsmart cybercrime. Learn more at infosecinstitute.com.
CompTIA’s Security+, the most popular cybersecurity certification in the world, is getting an overhaul for 2021! The updated exam (from SY0-501 to SY0-601) re-aligns the certification to match the most in-demand entry-level cybersecurity skills and trends of 2021.
Get insights into the changes directly from the source, Patrick Lane, Director of Products at CompTIA, as he explains how Security+ is evolving to remain the “go-to” certification for anyone trying to break into cybersecurity.
0:00 - Intro 4:10 - What is the CompTIA Security+ certification? 5:05 - Security+ baseline technical skills 16:00 - Security+ helps solve an industry problem 21:35 - Security+ job roles 31:45 - Job role skills and exam release 37:35 - CompITA Cybersecurity Career Pathway 47:27 - SY0-601 vs SY0-501: 6 big changes 52:10 - Security+ exam details 56:48- Live Q&A 1:02:13 - Outro
Patrick directs IT workforce skills certifications for CompTIA, including Security+, PenTest+, CySA+ and CASP+. He assisted the U.S. National Cybersecurity Alliance (NCSA) to create the “Lock Down Your Login” campaign to promote multi-factor authentication nationwide. He has implemented a wide variety of IT projects, including an intranet and help desk for 11,000 end users. Patrick is an Armed Forces Communications and Electronics Association (AFCEA) lifetime member, born and raised on U.S. military bases, and has authored and co-authored multiple books, including “Hack Proofing Linux: A Guide to Open Source Security.”
About Infosec Infosec believes knowledge is power when fighting cybercrime. We help IT and security professionals advance their careers with skills development and certifications while empowering all employees with security awareness and privacy training to stay cyber-safe at work and home. It’s our mission to equip all organizations and individuals with the know-how and confidence to outsmart cybercrime. Learn more at infosecinstitute.com.
Last year I got this idea that I should attempt to pay for my holidays to Japan by hunting for bounties in security appliances while in the plane. A full 10 hours of uninterrupted focus on one solution seemed like it should yield interesting results. So I started reverse engineering the Firewall of a relatively common brand which has a private bug bounty. Due to this reason, I won’t be giving out the full details of the issue I discovered, but I find the vulnerability to be quite interesting and worth discussing. So I attempt to do this here without breaching any disclosure terms…
This happened relatively shortly after I had discovered some issues in Sonicwall appliances (there may well be more of them discussed here in the short future), so I was still investigating SSL VPNs and searching for ways to compromise them.
One of the features that most SSL VPNs offer is the ability to provide single sign-on for internal applications once a user is authenticated to the VPN device. Unless a fancier protocol like OAuth2 or SAML is used, a VPN admin might be required to specify a URL that allows the user to “seamlessly” authenticate to the back-end server. This might look like the following:
When the user attempts to access the back-end application, a templating engine will automatically replace the username and password with the user’s data and thus authenticate successfully with the back-end server.
In other cases, the back-end server might accept Basic, Digest, NTLM or other types of authentication, which could also be configured by a VPN admin.
The first vulnerability I discovered was a pretty straightforward stack-based buffer overflow in the way the SSL VPN parsed the Negotiate authentication header. However, it was only exploitable from a back-end server. Worst case scenario, a server administrator (or any person who could tamper with internal communications) could potentially compromise the SSL VPN device. I wasn’t particularly enthusiastic about this finding as in practice, I didn’t really see many cases where I’d be able to exploit it. But I did continue researching how the device parsed these authentication headers in order to achieve single sign-on.
It turns out that the device did a pretty simple pattern match and replace on the {{username}} and {{password}} strings that were detected in the HTTP request. Where it got interesting, is when I noticed that these patterns were also replaced in the headers of the server’s Response for some reason. Not quite sure whether there is a legitimate reason to do so, or if this is an oversight, but I was wondering whether there was a way to exploit this in order to recover a user’s password.
Essentially, as an attacker we would need to find a way to get a specific pattern in the headers of the HTTP response from an application which is accessed through the VPN (even if no SSO is configured for it by the way). Unfortunately, I couldn’t find a generic way of doing so, but it is possible if one of the back-end applications is vulnerable to an insecure redirect.
When exploiting such a vulnerability, an attacker has to convince a user to click on a malicious link which will redirect the user to another location. Unless it is done in JavaScript, the redirection is generally done with a Location HTTP header containing the new location to visit.
This is very convenient in our case, as it allows us to recover the user’s VPN password as long as we can achieve the two following things:
Know the location of an insecure redirect on any application accessed through the VPN
Convince an authenticated user to visit a maliciously prepared URL
For instance, if I can get a user to click on the following link:
The user will end up visiting SCRT’s website while providing his or her username and password in the URL, since the browser will see the following response from the application.
HTTP/1.1 302 Found
Location: https://www.scrt.ch/?user=USER&password=Password01
Obviously this is not the most serious vulnerability to be discovered but I thought it was quite different from what I usually see and worth presenting quickly. There might be other devices out there vulnerable to similar flaws or templating issues.
Unfortunately, it’s only after I did the research and reported the various issues that I noticed that the bug bounty program was no longer issuing any rewards, so I wasn’t even close to paying for my trip.
Elie Bursztein joins us on today’s episode to talk all about his role as chief research lead for anti-abuse at Google! Along with Infosec Founder Jack Koziol and Cyber Work Podcast host Chris Sienko, they discuss the difference between the practices of security and anti-abuse, the difference between protecting Google the company and Gmail the product, and the aspects of security and anti-abuse that AI will never be able to do.
0:00 - Intro 2:35 - Starting a career in cybersecurity 12:57 - Entering the industry today 19:09 - Career progression 42:18 - Tech and academia collaboration for anti-abuse research 52:26 - Getting hired in anti-abuse and cybersecurity 1:01:09 - Future of machine learning as AI hacking 1:16:26 - Outro
Have you seen our new, hands-on training series Cyber Work Applied? Tune in every other week as expert Infosec instructors teach you a new cybersecurity skill and show you how that skill applies to real-world scenarios. You’ll learn how to carry out different cyberattacks, practice using common cybersecurity tools, follow along with walkthroughs of how major breaches occurred, and more. And it's free! Click the link below to get started.
Elie Bursztein leads the Security and Anti-Abuse Research team at Google. He focuses on deep learning and cryptography research, and among many other accomplishments, broke SHA-1. His website, elie.net, is packed with informative articles and online talks he’s given over the years, a veritable master-class for any cybersecurity aspirants. He also describes himself as a wearer of berets and a purveyor of magic tricks in his spare time.
About Infosec Infosec believes knowledge is power when fighting cybercrime. We help IT and security professionals advance their careers with skills development and certifications while empowering all employees with security awareness and privacy training to stay cyber-safe at work and home. It’s our mission to equip all organizations and individuals with the know-how and confidence to outsmart cybercrime. Learn more at infosecinstitute.com.
Diana Kelley of The Analyst Syndicate is on the podcast to chat about her 25-year-long career in security. She touches on artificial intelligence and machine learning ethics, sneaking into DARPA in the '70s and much more.
0:00 - Intro 3:14 - Getting into cybersecurity 11:51 - Cybersecurity changes in the past 25 years 15:34 - Choosing exciting cybersecurity projects 19:49 - What is The Analyst Syndicate? 23:00 - Editorial process at The Analyst Syndicate 26:26 - Changes in security from the pandemic 32:22 - Combating fatigue at home 34:35 - Digital transformation 39:25 - Bringing more women into cybersecurity 43:08 - Tips for hiring managers 46:16 - Using AI and ML ethically 51:50 - Tips to get into cybersecurity 55:15 - Kelley's next projects 56:18 - Learn more about Kelley 57:08 - Outro
Diana Kelley’s security career spans over 30 years. She is co-founder and CTO of SecurityCurve and donates much of her time to volunteer work in the cybersecurity community, including serving on the ACM Ethics & Plagiarism Committee, as CTO and board member at Sightline Security, board member and Inclusion Working Group champion at WiCyS, cybersecurity committee advisor at CompTIA, Advisory Council, Bartlett College of Science and Mathematics, Bridgewater State University and RSAC US Program Committee. Kelley produces the #MyCyberWhy series and is the host of BrightTALK’s The (Security) Balancing Act and co-host of the Your Everyday Cyber podcast. She is also a principal consulting analyst at TechVision Research and a member of The Analyst Syndicate. She was the Cybersecurity Field CTO for Microsoft, global executive security advisor at IBM Security, GM at Symantec, VP at Burton Group (now Gartner) and a manager at KPMG. She is a popular keynote speaker, the co-author of the books "Practical Cybersecurity Architecture" and "Cryptographic Libraries for Developers," has been a lecturer at Boston College's Masters program in cybersecurity, the EWF 2020 Executive of the Year and one of Cybersecurity Ventures 100 Fascinating Females Fighting Cybercrime.
About Infosec Infosec believes knowledge is power when fighting cybercrime. We help IT and security professionals advance their careers with skills development and certifications while empowering all employees with security awareness and privacy training to stay cyber-safe at work and home. It’s our mission to equip all organizations and individuals with the know-how and confidence to outsmart cybercrime. Learn more at infosecinstitute.com.
Today we're talking about security awareness, specifically about the role of a security awareness manager, with Tiffany Franklin of Optiv. We talk about the importance of C-suite buy-in to a security awareness program, how to create challenging phishing simulators without making employees feel like victims of a gotcha attack and how being a fifth-grade math teacher can make you a better security awareness manager.
0:00 - Intro 2:13 - Getting into cybersecurity 3:57 - Instructional design and technology 4:58 - Primary responsibilities in her role 6:38 - Security awareness work 9:40 - What is the division of work? 11:55 - Skills needed for this role 15:04 - Helping people when they fail 17:12 - Daily tasks 18:15 - Highs and lows of the job 22:00 - COVID phishing emails 22:40 - GoDaddy phishing and ethics 26:20 - Creating security awareness campaigns 31:14 - Optimal combo of tech and savvy 34:20 - How to get into cybersecurity 37:10 - Outro
Tiffany Franklin has over 13 years’ experience as a learning and development professional and is currently a Manager of Cybersecurity Education at Optiv. Tiffany and her team develop solutions that address the unique challenges of global organizations facing a wide array of cybersecurity risks, including security awareness training program courses, simulated phishing attacks, and training reinforcement materials. She has a background in education and has a Masters in Instructional Design & Technology.
About Infosec Infosec believes knowledge is power when fighting cybercrime. We help IT and security professionals advance their careers with skills development and certifications while empowering all employees with security awareness and privacy training to stay cyber-safe at work and home. It’s our mission to equip all organizations and individuals with the know-how and confidence to outsmart cybercrime. Learn more at infosecinstitute.com.
This episode we chat with Jackie Olshack, a project management professional, about the role of project management in cybersecurity. We break down the specific functions of some major project management certifications, discuss things you can do tonight to start your project management training and hear why every security breach story on CNN is a cause for reflection.
0:00 - Intro 3:09 - Getting into cybersecurity project management 4:30 - What does a cybersecurity project manager do? 5:56 - Identity access management 8:35 - Average day for a project manager 9:57 - Managing project resources 11:36 - Getting into project management 12:54 - What happens without a project manager? 14:30 - Highs and lows of the job 17:22 - Training needed for the role 20:18 - What is identity access management? 24:12 - Preferred job experiences 28:02 - Interests and skills to succeed 31:17 - Where do I begin with tech lingo? 33:18 - What can I do to change careers? 35:00 - Has remote work changed workflow? 35:55 - Outro
Jackie Olshack worked almost 20 years as legal secretary/paralegal for multiple patent corporate law firms. In the late 1990s, she began to recognize it was becoming harder to break the ceiling on her $58,000 salary as more and more attorneys were typing their own documents, managing their own calendars and making their own travel arrangements, putting the future of her career in jeopardy. After some introspection, she decided to go back to college and pursue a science degree with plans to go to law school to become a patent attorney — but couldn’t get her LSAT higher to get into even a fourth-tier law school. She now proudly thanks all the law schools that turned her down, preventing the dreaded $150,000-$200,000 law school debt she would have incurred. She is now an analytical, top performing SAFe trained senior project management professional with 14+ years of experience managing and implementing IT programs and projects successfully.
About Infosec Infosec believes knowledge is power when fighting cybercrime. We help IT and security professionals advance their careers with skills development and certifications while empowering all employees with security awareness and privacy training to stay cyber-safe at work and home. It’s our mission to equip all organizations and individuals with the know-how and confidence to outsmart cybercrime. Learn more at infosecinstitute.com.
This episode we welcome back Emily Miller of Mocana to discuss infrastructure security! We discuss the water supply hack in Oldsmar, Fla., the state of the nation’s cybersecurity infrastructure and brainstorm a TikTok musical that will make infrastructure security the next Hamilton!
0:00 - Intro 3:02 - The last two years 5:54 - The impact of COVID 10:10 - The Florida hack 15:50 - Scope and scale of safety systems 18:50 - State and local government responses 23:20 - Logistical issues of security for infrastructure 26:45 - Ideal solutions to security 31:33 - How to improve infrastructure security 39:42 - Aiming toward state and local government 43:20 - Skills to learn for this work 48:13 - Future proofing this role 52:54 - Work and upcoming projects 55:55 - Outro
Miller is the Vice President of Critical Infrastructure and National Security with Mocana Corporation. Miller has over 15 years of experience protecting our nation’s critical infrastructure in both physical and cybersecurity, focusing on control systems, industrial IoT and other operational technology. Prior to joining Mocana, Miller was a federal employee with the Department of Homeland Security’s Industrial Control Systems Cyber Emergency Response Team (ICS-CERT).
On our previous episode back in early 2019, Miller and I talked about IoT security and infrastructure security, and how strengthening IoT and the security systems of our electrical, water and internet infrastructures isn’t just good business, it’s saving lives.
In the last two years, these issues have become even more noticeable and pronounced. Earlier this year, hackers were able to break into the network of a water purification system in a small town in Florida. By changing cleaning and purification levels in the town’s water supply, they could have realistically poisoned the whole town. Miller and I will be discussing not only how to address the problems we have now, but to help the new generation of cybersecurity professionals lead the charge to reverse a 50+ year trend of neglect against our country’s vital infrastructure, from power grids to roads.
About Infosec
Infosec believes knowledge is power when fighting cybercrime. We help IT and security professionals advance their careers with skills development and certifications while empowering all employees with security awareness and privacy training to stay cyber-safe at work and home. It’s our mission to equip all organizations and individuals with the know-how and confidence to outsmart cybercrime. Learn more at infosecinstitute.com.
In simple terms, it’s a function that is called through a function pointer. When we pass a function pointer to the parameter where the callback function is required, once that function pointer is used to call that function it points to it’s said that a call back is made. This can be abused to pass shellcode instead of a function pointer. This has been around a long time and there are so many Win32 APIs we can use to execute shellcode. This article contains few APIs that I have tested and are working on Windows 10.
Analyzing an API
For example, let’s take the function EnumWindows from user32.dll. The first parameter lpEnumFunc is a pointer to a callback function of type WNDENUMPROC.
Whether you’re looking for first-time work in the cybersecurity field, still studying the basics or considering a career change, you might feel overwhelmed with choices. How do you know you have the right knowledge? How do you make yourself stand out in the resume pile? How do you get jobs that require experience without having any experience?
Join a panel of past Cyber Work Podcast guests including Gene Yoo, CEO of Resecurity, and the expert brought in by Sony to triage the 2014 hack; Mari Galloway, co-founder of Women’s Society of Cyberjutsu and Victor “Vic” Malloy, General Manager, CyberTexas.
They provide top-notch cybersecurity career advice for novices, including questions from Cyber Work Live viewers.
0:00 - Intro 3:38 - I'm tech-savvy. Where do I begin? 10:55 - Figuring out the field for you 19:16 - Returning to cybersecurity at 68 23:30 - Finding a cybersecurity mentor 29:39 - Non-technical roles in the industry 36:21 - Breaking into the industry 43:46 - Standout resume and interview 51:31 - Is a certification necessary? 56:50 - Related skills beginners should have 1:04:35 - Outro
This episode was recorded live on March 25, 2021. Want to join the next Cyber Work Live and get your career questions answered? See upcoming events here: https://www.infosecinstitute.com/events/
About Infosec Infosec believes knowledge is power when fighting cybercrime. We help IT and security professionals advance their careers with skills development and certifications while empowering all employees with security awareness and privacy training to stay cyber-safe at work and home. It’s our mission to equip all organizations and individuals with the know-how and confidence to outsmart cybercrime. Learn more at infosecinstitute.com.
Digital forensics professional Ondrej Krehel talks about the work of digital forensics in federal and government locations, the things he learned during a months-long attempt at decrypting a well-secured Swiss bank file and why finishing the research beats any degree you could ever have.
0:00 - Intro 2:11 - Ondrej's cybersecurity journal 5:33 - Career stepping stones 9:55 - The Swiss job 16:02 - Chasing the learning and experience 20:01 - Digital forensics on a government and federal scale 28:07 - Forensics collaboration on a case 30:46 - Favorite work stories 31:33 - How to improve infrastructure security 36:01 - Skills needed to enter digital forensics in government 41:31 - Unheard activities of digital forensics 43:48 - Where do I get work experience? 47:05 - Tips for digital forensic job hunters 52:19 - Work with LIFARS 57:50 - Outro
Have you seen our new, hands-on training series Cyber Work Applied? Tune in every other week as expert Infosec instructors teach you a new cybersecurity skill and show you how that skill applies to real-world scenarios. You’ll learn how to carry out different cyberattacks, practice using common cybersecurity tools, follow along with walkthroughs of how major breaches occurred, and more. And it's free!
Ondrej Krehel is a Digital forensics and cybersecurity professional. His background includes time with special cyber operations, cyber warfare and offensive missions and a court expert witness. His Forensic Investigation matters have received attention from Forbes, CNN, NBC, BBC, ABC, Reuters, The Wall Street Journal and The New York Times.
As you can see, Ondrej has a deep background in digital forensics and ethical hacking. He tells us about time spent as a guest lecturer at the FBI Training Academy, the current state of digital forensics in a federal and government context and gives us some info about how that realm differs from similar work done in for-profit or private companies.
About Infosec Infosec believes knowledge is power when fighting cybercrime. We help IT and security professionals advance their careers with skills development and certifications while empowering all employees with security awareness and privacy training to stay cyber-safe at work and home. It’s our mission to equip all organizations and individuals with the know-how and confidence to outsmart cybercrime. Learn more at infosecinstitute.com.
In this episode we explore supply-chain security with Manish Gupta. We’re going to learn about risks and cyberattacks related to the continuous integration/continuous deployment or CI/CD pipeline, which, given high-profile attacks like SolarWinds, will give us plenty to discuss this week!
0:00 - Intro 2:21 - Manish's origin story 4:58 - Major career stepping stones 8:45 - Lessons when ahead of the curve 11:21 - Average day as a servant leader CEO 14:54 - Concerns with supply chain security 21:22 - Federal supply chain action 26:20 - What supply chain policy should focus on 28:40 - Skills needed for supply chain jobs 32:48 - What should be on my resume? 34:03 - Showing supply chain aptitude 36:04 - Future projects 38:29 - Outro
Manish Gupta is the founder and CEO of ShiftLeft, an innovator in automated application security and the leader in application security for developers. He previously served as the chief product and strategy officer at FireEye, where he helped grow the company from approximately $70 million to more than $700 million in revenue, growing the product portfolio from two to more than 20 products. Before that he was vice president of product management for Cisco’s $2 billion security portfolio. He also served as a vice president/general manager at McAfee and iPolicy networks.
Manish has an MBA from the Kellogg Graduate School of Management, MS in engineering from the University of Maryland and a BS in engineering from the Delhi College of Engineering.
About Infosec Infosec believes knowledge is power when fighting cybercrime. We help IT and security professionals advance their careers with skills development and certifications while empowering all employees with security awareness and privacy training to stay cyber-safe at work and home. It’s our mission to equip all organizations and individuals with the know-how and confidence to outsmart cybercrime. Learn more at infosecinstitute.com.
In 2018, James Forshaw published an article in which he briefly mentioned a trick that could be used to inject arbitrary code into a PPL as an administrator. However, I feel like this post did not get the attention it deserved as it literally described a potential Userland exploit for bypassing PPL (which includes LSA Protection).
Introduction
I was doing some research on Protected Processes when I stumbled upon the following blog post: Windows Exploitation Tricks: Exploiting Arbitrary Object Directory Creation for Local Elevation of Privilege. This post was written by James Forshaw on Project Zero’s blog in August 2018. As the title implies, the objective was to discuss a particular privilege escalation trick, not a PPL bypass. However, the following sentence immediately caught my eye:
Abusing the DefineDosDevice API actually has a second use, it’s an Administrator to Protected Process Light (PPL) bypass.
As far as I know, all the public tools for bypassing PPL that have been released so far involve the use of a driver in order to execute arbitrary code in the Kernel (with the exception of pypykatz as I mentioned in my previous post). In his blog post though, James Forshaw casually gave us a Userland bypass trick on a plate, and it seems it went quite unnoticed by the pentesting community.
The objective of this post is to discuss this technique in more details. I will first recap some key concepts behind PPL processes, and I will also explain one of the major differences between a PP (Protected Process) and a PPL (Protected Process Light). Then, we will see how this slight difference can be exploited as an administrator. Finally, I will introduce the tool I developed to leverage this vulnerability and dump the memory of any PPL without using any Kernel code.
When the PP model was first introduced with Windows Vista, a process was either protected or unprotected. Then, beginning with Windows 8.1, the PPL model extended this concept and introduced protection levels. The immediate consequence is that some PP(L)s can now be more protected than others. The most basic rule is that an unprotected process can open a protected process only with a very restricted set of access flags such as PROCESS_QUERY_LIMITED_INFORMATION. If they request a higher level of access, the system will return an Access is Denied error.
For PP(L)s, it’s a bit more complicated. The level of access they can request depends on their own level of protection. This protection level is partly determined by a special EKU field in the file’s digital certificate. When a protected process is created, the protection information is stored in a special value in the EPROCESS Kernel structure. This value stores the protection level (PP or PPL) and the signer type (e.g.: Antimalware, Lsa, WinTcb, etc.). The signer type establishes a sort of hierarchy between PP(L)s. Here are the basic rules that apply to PP(L)s:
A PP can open a PP or a PPL with full access if its signer type is greater or equal.
A PPL can open a PPL with full access if its signer type is greater or equal.
A PPL cannot open a PP with full access, regardless of its signer type.
For example, when LSA Protection is enabled, lsass.exe is executed as a PPL, and you will observe the following protection level with Process Explorer: PsProtectedSignerLsa-Light. If you want to access its memory you will need to call OpenProcess and specify the PROCESS_VM_READ access flag. If the calling process is not protected, this call will immediately fail with an Access is Denied error, regardless of the user’s privileges. However, if the calling process were a PPL with a higher level (WinTcb for instance), the same call would succeed (as long as the user has the appropriate privileges obviously). As you will have understood, if we are able to create such a process and execute arbitrary code inside it, we will be able to access LSASS even if LSA Protection is enabled. The question is: can we achieve this goal without using any Kernel code?
PP vs PPL
The PP(L) model effectively prevents an unprotected process from accessing protected processes with extended access rights using OpenProcess for example. This prevents simple memory access, but there is another aspect of this protection I did not mention. It also prevents unsigned DLLs from being loaded by these processes. This makes sense, otherwise the overall security model would be pointless as you could just use any form of DLL hijacking and inject arbitrary code into your own PPL process. This also explains why a particular attention should be paid to third-party authentication modules when enabling LSA Protection.
There is one exception to this rule though! And this is probably where the biggest difference between a PP and a PPL lies. If you know about the DLL search order on Windows, you know that, when a process is created, it first goes through the list of “Known DLLs”, then it continues with the application’s directory, the System directories and so on… In this search order, the “Known DLLs” step is a special one and is usually taken out of the equation for DLL hijacking exploits because a user has no control over it. Though, in our case, this step is precisely the “Achille’s heel” of PPL processes.
The “Known DLLs” are the DLLs that are most commonly loaded by Windows applications. Therefore, to increase the overall performance, they are preloaded in memory (i.e. they are cached). If you want to see the complete list of “Known DLLs”, you can use WinObj and take a look a the content of the \KnownDlls directory within the object manager.
WinObj – Known DLLs
Since these DLLs are already in memory, you should not see them if you use Process Monitor to check the file operations of a typical Windows application. Things are a bit different when it comes to Protected Processes though. I will take SgrmBroker.exe as an example here.
Known DLLs loaded by a Protected Process
As we can see in Process Explorer, SgrmBroker.exe was started as a Protected Process (PP). When the process starts, the very first DLLs that are loaded are kernel32.dll and KernelBase.dll, which are both… …”Known DLLs”. Yes, in the case of a PP, even the “Known DLLs” are loaded from the disk, which implies that the digital signature of each file is always verified. However, if you do the same test with a PPL, you will not see these DLLs in Process Monitor as they behave like normal processes in this case.
This fact is particularly interesting because the digital signature of a DLL is only verified when the file is mapped, i.e. when a Section is created. This means that, if you are able to add an arbitrary entry to the \KnownDlls directory, you can then inject an arbitrary DLL and execute unsigned code in a PPL.
Adding an entry to \KnownDlls is easier said than done though because Microsoft already considered this attack vector. As explained by James Forshaw in his blog post, the \KnownDlls object directory is marked with a special Process Trust Label as you can see on the screenshot below.
KnownDlls directory Process Trust Label
As you may imagine, based on the name of the label, only protected processes that have a level higher than or equal to WinTcb – which is actually the highest level for PPLs – can request write access to this directory. But all is not lost as this is exactly where the clever trick found by JF comes into play.
MS-DOS Device Names
As mentioned in the introduction, the technique found by James Forshaw relies on the use of the API function DefineDosDevice, and involves some Windows internals that are not easy to grasp. Therefore, I will first recap some of these concepts here before dealing with the method itself.
As suggested by its name, the purpose of the DefineDosDevice is to literally define MS-DOS device names. An MS-DOS device name is a symbolic link in the object manager with a name of the form \DosDevices\DEVICE_NAME (e.g.: \DosDevices\C:) as explained in the documentation. So, this function allows you to map an actual “Device” to a “DOS Device”. This is exactly what happens when you plug in an external drive or a USB key for example. The device is automatically assigned a drive letter, such as E:. You can get the corresponding mapping by invoking QueryDosDevice.
In the above example, the target device is \Device\HarddiskVolume5 and the MS-DOS device name is E:. But wait a minute, I said that an MS-DOS device name was of the form \DosDevices\DEVICE_NAME. So, this cannot be just a drive letter. No worries, there is an explanation. For both DefineDosDevice and QueryDosDevice, the \DosDevices\ part is implicit. These functions automatically prepend the “device name” with \??\. So, if you provide E: as the device name, they will use the NT path \??\E: internally. Even then, you will tell me that \??\ is still not \DosDevices\, and this would be a valid point. Once again, WinObj will help us solve this “mystery”. In the root directory of the object manager, we can see that \DosDevices is just a symbolic link that points to \??. As a result, \DosDevices\E: -> \??\E:, so we can consider them as the same thing. This symbolic link actually exists for legacy reasons because, in older versions of Windows, there was only one DOS device directory.
WinObj – DosDevices symbolic link
Local DOS Device Directories
The path prefix \??\ itself has a very special meaning. It represents the local DOS device directory of a user and therefore refers to different locations in the object manager, depending on the current user’s context. Concretely, \?? refers to the full path \Sessions\0\DosDevices\00000000-XXXXXXXX, where XXXXXXXX is the user’s logon authentication ID. There is one exception though, for NT AUTHORITY\SYSTEM, \?? refers to \GLOBAL??. This concept is very important so I will take two examples to illustrate it. The first one will be the USB key I used previously and the second one will be an SMB share I manually mount through the Explorer.
In the case of the USB key, we already saw that \??\E: was a symbolic link to \Device\HarddiskVolume5. As it was mounted by SYSTEM, this link should exist within \GLOBAL??\. Let’s verify that with WinObj.
WinObj – \GLOBAL??\E: symbolic link
Everything is fine! Now, let’s map an “SMB share” to a drive letter and see what happens.
Mapping a Network Drive
This time, the drive is mounted as the logged-on user, so \?? should refer to \Sessions\0\DosDevices\00000000-XXXXXXXX, but what is the value of XXXXXXXX? To find it, I will use Process Hacker and check the advanced properties of my explorer.exe process’ primary access token.
Process Hacker – Explorer’s token advanced properties
The authentication ID is 0x1abce so the symbolic link should have been created inside \Sessions\0\DosDevices\00000000-0001abce. Once again, let’s verify that with WinObj.
WinObj – SMB share symbolic link
There it is! The symbolic link was indeed created in this directory.
Why DefineDosDevice?
As we saw in the previous part, the device mapping operation consists of a simple symbolic link creation in the caller’s DOS device directory. Any user can do that as it affects only their session. But there is a problem, because low-privileged users can only create “Temporary” kernel objects, which are removed once all their handles have been closed. To solve this problem, the object must be marked as “Permanent“, but this requires a particular privilege (SeCreatePermanentPrivilege) which they do not have. So, this operation must be performed by a privileged service that has this capability.
The symbolic link is marked as “Permanent”
As outlined by JF in his blog post, DefineDosDevice is just a wrapper for an RPC method call. This method is exposed by the CSRSS service and is implemented in BaseSrvDefineDosDevice inside BASESRV.DLL. What is special about this service is that it runs as a PPL with the protection level WinTcb.
CSRSS service runing as a PPL (WinTcb)
Although this is a requirement for our exploit, it is not the most interesting fact about DefineDosDevice. What is even more interesting is that the value of lpDeviceName is not sanitized. This means that you are not bound to provide a drive letter such as E:. We will see how we can leverage this to trick the CSRSS service into creating an arbitrary symbolic link in an arbitrary location such as \KnownDlls.
Exploiting DefineDosDevice
In this part, we will take a deep dive into the DefineDosDevice function. We will see what kind of weakness lies inside it and how we can exploit it to reach our goal.
The Inner Workings of DefineDosDevice
In his article, JF did all the heavy lifting as he reversed the BaseSrvDefineDosDevice function and provided us with the corresponding pseudo-code. You can check it out here. If you do so, you should note that there is slight mistake at step 4 though, it should be CsrImpersonateClient(), not CsrRevertToSelf(). Anyway, rather than copy-pasting his code, I will try to provide a high-level overview using a diagram instead.
Overview of BaseSrvDefineDosDevice
In this flowchart, I highlighted some elements with different colors. The impersonation functions are in orange and the symbolic link creation steps are in blue. Finally, I highlighted the critical path we need to take in red.
First, we can see that the CSRSS service tries to open \??\DEVICE_NAME while impersonating the caller (i.e. the RPC client). The main objective is to delete the symbolic link first if it already existed. But there is more to it, the service will also check whether the symbolic link is “global”. For that purpose, an internal function, which is not represented here, simply checks whether the “real” path of the object starts with \GLOBAL??\. If so, impersonation is disabled for the rest of the execution and the service will not impersonate the client prior to the NtCreateSymbolicLinkObject() call, which means that the symbolic link will be created by the CSRSS service itself. Finally, if this operation succeeds, the service marks the object as “Permanent” as I mentioned earlier.
A Vulnerability?
At this point you may have realized that there is a sort of TOCTOU (Time-of-Check Time-of-Use) vulnerability. The path used to open the symbolic link and the path used to create it are the same: \??\DEVICE_NAME. However, the “open” operation is always done while impersonating the user whereas the “create” operation might be done directly as SYSTEM if impersonation is disabled. And, if you remember what I explained earlier, you know that \?? represents a user’s local dos device directory and therefore resolves to different paths depending on the user’s identity. So, although the same path is used in both cases, it may well refer to completely different locations in reality!
In order to exploit this behavior, we must solve the following challenge: we need to find a “device name” that resolves to a “global object” we control when the service impersonates the client. And this same “device name” must resolve to \KnownDlls\FOO.dll when impersonation is disabled. This sounds a bit tricky, but we will go through it step by step.
Let’s begin with the easiest part first. We need to determine a value for DEVICE_NAME in \??\DEVICE_NAME such that this path resolves to \KnownDlls\FOO.dll when the caller is SYSTEM. We also know that \?? resolves to \GLOBAL?? in this case.
If you check the content of the \GLOBAL??\ directory, you will see that there is a very convenient object inside it.
WinObj – The “real” GLOBALROOT
In this directory, the GLOBALROOT object is a symbolic link that points to an empty path. This means that a path such as \??\GLOBALROOT\ would translate to just \, which is the root of the object manager (hence the name “global root”). If we apply this principle to our “device name”, we know that \??\GLOBALROOT\KnownDlls\FOO.DLL would resolve to \KnownDlls\FOO.dll when the caller is SYSTEM. This is one part of the problem solved!
Now, we know that we should supply GLOBALROOT\KnownDlls\FOO.DLL as the “device name” for the DefineDosDevice function call (remember that \??\ will be automatically prepended to this value). If we want the CSRSS service to disable impersonation, we also know that the symbolic link object must be considered as “global” so its path must start with \GLOBAL??\. So, the question is: how do you transform a path such as \??\GLOBALROOT\KnownDlls\FOO.DLL into \GLOBAL??\KnownDlls\FOO.dll? The solution is actually quite straightforward as this is pretty much the very definition of a symbolic link! When the service impersonates the user, we know that \?? refers to the local DOS device directory of this particular user, so all you have to do is create a symbolic link such that \??\GLOBALROOT points to \GLOBAL??, and that’s it.
To summarize, when the path is opened by a user other than SYSTEM:
There is one last thing that needs to be taken care of. Before checking whether the object is “global” or not, it must first exist, otherwise the initial “open” operation would just fail. So, we need to make sure that \GLOBAL??\KnownDlls\FOO.dll is an existing symbolic link object prior to calling DefineDosDevice.
WinObj – Permissions of \GLOBAL??
There is a slight issue here. Administrators cannot create objects or even directories within \GLOBAL??. This is not really a problem; this just adds an extra step to our exploit as we will have to temporarily elevate to SYSTEM first. As SYSTEM, we will be able to first create a fake KnownDlls directory inside \GLOBAL??\ and then create a dummy symbolic link object inside it with the name of the DLL we want to hijack.
The Full Exploit
There is a lot of information to digest so, here is a short recap of the exploit steps before we discuss the last considerations. In this list, we assume we are executing the exploit as an administrator.
Elevate to SYSTEM, otherwise we will not be able to create objects inside \GLOBAL??.
Create the object directory \GLOBAL??\KnownDlls to mimic the actual \KnownDlls directory.
Create the symbolic link \GLOBAL??\KnownDlls\FOO.dll, where FOO.dll is the name of the DLL we want to hijack. Remember that what matters is the name of the link itself, not its target.
Drop the SYSTEM privileges and revert to our administrator user context.
Create a symbolic link in the current user’s DOS device directory called GLOBALROOT and pointing to \GLOBAL??. This step must not be done as SYSTEM because we want to create a fake GLOBALROOT link inside our own DOS directory.
This is the centerpiece of this exploit. Call DefineDosDevice with the value GLOBALROOT\KnownDlls\FOO.dll as the device name. The target path of this device is the location of the DLL but I will get to that in the next part.
Here is what happens inside the CSRSS service at the final step. It first receives the value GLOBALROOT\KnownDlls\FOO.dll and prepends it with \??\ so this yields the device name \??\GLOBALROOT\KnownDlls\FOO.dll. Then, it tries to open the corresponding symbolic link object while impersonating the client.
Since the object exists, it will check if it’s global. As you can see, the “real” path of the object starts with \GLOBAL??\ so it’s indeed considered global, and impersonation is disabled for the rest of the execution. The current link is deleted and a new one is created, but this time, the RPC client is not impersonated, so the operation is done in the context of the CSRSS service itself as SYSTEM:
Here we go! The service creates the symbolic link \KnownDlls\FOO.dll with a target path we control.
DLL Hijacking through Known DLLs
Now that we know how to add an arbitrary entry to the \KnownDlls directory, we should come back to our original problem, and our exploit constraints.
Which DLL to Hijack?
We want to execute arbitrary code inside a PPL, and ideally with the signer type “WinTcb”. So, we need to find a suitable executable candidate first. On Windows 10, four built-in binaries can be executed with such a level of protection as far as I know: wininit.exe, services.exe, smss.exe and csrss.exe. smss.exe and csrss.exe cannot be executed in Win32 mode so we can eliminate them. I did a few tests with wininit.exe but letting this binary run as an administrator with debug privileges is a bad idea. Indeed, there is a high chance it will mark itself as a Critical Process, meaning that when it terminates, the system will likely crash with a BSOD.
This leaves us with only one potential candidate: services.exe. As it turns out, this is the perfect candidate for our purpose. Its main function is very easy to decompile and understand. Here is the corresponding pseudo-code.
int wmain()
{
HANDLE hEvent;
hEvent = OpenEvent(SYNCHRONIZE, FALSE, L"Global\\SC_AutoStartComplete");
if (hEvent) {
CloseHandle(hEvent);
} else {
RtlSetProcessIsCritical(TRUE, NULL, FALSE);
if (NT_SUCCESS(RtlInitializeCriticalSection(&CriticalSection))
SvcctrlMain();
}
return 0;
}
It first tries to open a global Event object. If it worked, the handle is closed, and the process terminates. The actual main function SvcctrlMain() is executed only if this Event object does not exist. This makes sense, this simple synchronization mechanism makes sure services.exe is not executed twice, which is perfect for our use case as we don’t want to mess with the Service Control Manager (services.exe is the image file used by the SCM).
WinObj – SC_AutoStartComplete global Event
Now, in order to get a first glimpse at the DLLs that are loaded by services.exe, we can use Process Monitor with a few filters.
Process Monitor – DLLs loaded by services.exe
From this output, we know that services.exe loads three DLLs (which are not Known DLLs) but this information, on its own, is not sufficient. We need to also find which functions are imported. So, we need to take a look at the PE’s import table.
IDA – Import table of services.exe
Here, we can see that only one function is imported from dpapi.dll: CryptResetMachineCredentials. Therefore, this is the simplest DLL to hijack. We just have to remember that we will have to export this function, otherwise our crafted DLL will not be loaded.
But is it that simple? The short answer is “no”. After doing some testing on various installations of Windows, I realized that this behavior was not consistent. On some versions of Windows 10, dpapi.dll is not loaded at all, for some reason. In addition, the DLLs that are imported by services.exe on Windows 8.1 are completely different. In the end, I had to take all these differences into account in order to build a tool that works on all the recent versions of Windows (including the Server editions) but you get the overall idea.
DLL File Mapping
In the previous parts, we saw how we could trick the CSRSS service into creating an arbitrary symbolic link object in \KnownDlls but I intentionally omitted an essential part: the target path of the link.
A symbolic link can virtually point to any kind of object in the object manager but, in our case, we have to mimic the behavior of a library being loaded as a Known DLL. This means that the target must be a Section object, rather than the DLL file path for example.
As we saw earlier, “Known DLLs” are Section objects which are stored in the object directory \KnownDlls and this is also the first location in the DLL search order. So, if a program loads a DLL named FOO.dll and the Section object \KnownDlls\FOO.dll exists, then the loader will use this image rather than mapping the file again. In our case, we have to do this step manually. The term “manually” is a bit inappropriate though as we do not really have to map the file ourselves if we do this in the “legitimate way”.
A Section object can be created by invoking NtCreateSection. This native API function requires an AllocationAttributes argument, which is usually set to SEC_COMMIT or SEC_IMAGE. When SEC_IMAGE is set, we can specify that we want to map a previously opened file as an executable image file. Therefore, it will be properly and automatically mapped into memory. But this means that we have to embed a DLL, write it to the disk, open it with CreateFile to get a handle on the file and finally invoke NtCreateSection. For a Proof-of-Concept, this is fine, but I wanted to go the extra mile and find a more elegant solution.
Another approach would consist in doing everything in memory. Similarly to the famous Process Hollowing technique, we would have to create a Section object with enough memory space to store the content of our DLL’s image, then parse the NT headers to identify each section inside the PE and map them appropriately, which is what the loader does. This a rather tedious process and I did not want to go this far. Though, while doing my research, I stumbled upon a very interesting blog post about “DLL Hollowing” by @_ForrestOrr. In his Proof-of-Concept he made use of Transactional NTFS (a.k.a TxF) to replace the content of an existing DLL file with his own payload without really modifying it on disk. The only requirement is that you must have write permissions on the target file.
In our case, we assume that we have admin privileges, so this is perfect. We can open a DLL in the System directory as a transaction, replace its content with our payload DLL and finally use the opened handle in the NtCreateSection API function call with the flag SEC_IMAGE. But I did say that we still need to have write permissions on the target file, even though we don’t really modify the file itself. This is a problem because system files are owned by TrustedInstaller, aren’t they? Since we assume we have admin privileges, we could well elevate to TrustedInstaller but there is a simpler solution. It turns out some (DLL) files within C:\Windows\System32\ are actually owned by SYSTEM, so we just have to search this directory for a proper candidate. We should also make sure that its size is large enough so that we can replace its content with our own payload.
Exploiting as SYSTEM?
In the exploit part, I insisted on the fact that the DefineDosDevice API function must be called as any user other than SYSTEM, otherwise the whole “trick” would not work. But what if we are already SYSTEM and we don’t have an administrator account. We could create a temporary local administrator account, but this would be quite lame. A better thing to do is simply impersonate an existing user. For instance, we can impersonate LOCAL SERVICE or NETWORK SERVICE, as they both have their own DOS device directory.
Assuming we have “debug” and “impersonate” privileges, we can list the current processes, find one that runs as LOCAL SERVICE, duplicate the primary token and temporarily impersonate this user. It’s as simple as that.
No matter if we are executing the exploit as SYSTEM or as an administrator, in both cases, we will have to go back and forth between two identities without losing track of things.
Conclusion
In this post, we saw how a seemingly benign API function could be leveraged by an administrator to eventually inject arbitrary code into a PPL with the highest level using some very clever tricks. I implemented this technique in a new tool – PPLdump – in reference to ProcDump. Assuming you have administrator or SYSTEM privileges, it allows you to dump the memory of any PPL, including LSASS when LSA Protection is enabled.
This “vulnerability”, initially published in 2018, is still not patched. If you wonder why, you can check out the Windows Security Servicing Criteria section in the Microsoft Bug Bounty program. You will see that even a non-admin to PPL bypass is not a serviceable issue.
Windows Security Servicing Criteria
By implementing this technique in a standalone tool, I learned a lot about some Windows Internals which I did not really have the opportunity to tackle before. In return, I covered a lot of those aspects in this blog post. But this would have certainly not been possible if great security researchers such as James Forshaw (@tiraniddo) did not share their knowledge through their various publications. So, once again, I want to say a big thank you to him.
If you want to read the original publication or if you want to learn more about “DLL Hollowing“, you can check out the following resources.
@tiraniddo – Windows Exploitation Tricks: Exploiting Arbitrary Object Directory Creation for Local Elevation of Privilege – link
@_ForrestOrr – Masking Malicious Memory Artifacts – Part I: Phantom DLL Hollowing – link
Christina Van Houten talks about Women@Work and women in cybersecurity on this week's episode. We discuss tactics for bringing more women and diverse candidates into cybersecurity, the importance of a well-balanced and skills-diverse team, and how the work of Chief Strategy Officer is like an ever-evolving game of Tetris!
0:00 - Intro 2:30 - Van Houten's origin story 4:13 - Strategies cybersecurity was lacking 7:05 - Accomplishments that helped bolster her career 13:46 - Average day as chief strategy officer 18:03 - Entering cybersecurity in different ways 20:37 - Women@Work and trying to help 26:27 - Bringing more women into cybersecurity 29:20 - Making careers accessible to women 34:14 - Diversifying upper management 36:22 - Success stories mentoring women 41:01 - Men@Work book and men in cybersecurity 46:33 - Roadblocks women in cybersecurity face 50:47 - Projects from Mimecast 54:37 - Outro
Christina Van Houten is a veteran of the enterprise technology industry, having spent two decades with some of the world’s largest firms, including Oracle, IBM and Infor Global Solutions as well as Netezza and ProfitLogic, the entrepreneurial companies that were acquired by them. Currently, Christina is chief strategy officer for Mimecast, a global leader in cybersecurity, where she leads product management, market strategy, corporate development, and M&A. She also serves on the board of directors for TechTarget and has been involved as an advisory board member of several emerging technology firms. In 2017, Christina launched Women@Work, a resource platform dedicated to the economic advancement and self-reliance of women and girls around the world.
About Infosec Infosec believes knowledge is power when fighting cybercrime. We help IT and security professionals advance their careers with skills development and certifications while empowering all employees with security awareness and privacy training to stay cyber-safe at work and home. It’s our mission to equip all organizations and individuals with the know-how and confidence to outsmart cybercrime. Learn more at infosecinstitute.com.
This episode we welcome Jeff Schmidt of Covail to discuss security and risk management, working at the FBI to create the InfraGard program, and what cybersecurity can learn from physical security controls and fire safety and protection.
0:00 - Intro 2:30 - Origin story 4:31 - Stepping stones throughout career 8:00 - Average work day 12:14 - Learning from physical security 17:18 - Deficiencies in detection 22:17 - Which security practices need to change? 24:15 - How massive would this change be? 27:37 - Skills needed for real-time detection 32:00 - Strategies to get into cybersecurity 34:30 - Final words on the industry 37:16 - What is Covail? 38:40 - Outro
Jeff Schmidt, VP and Chief Cyber Security Innovator at Covail is an accomplished cybersecurity expert with a background in security and risk management. He founded JAS Global Advisors LLC, a security consulting firm in Chicago, and Authis, a provider of innovative risk-managed identity services for the financial sector. Jeff is a board member for Delta Risk LLC. In 1998, he worked with the FBI to create the InfraGard program, receiving commendations from the Attorney General and the Director of the FBI. He is an adjunct professor of systems security engineering at the Stevens Institute of Technology and a Zurich Cyber Risk Fellow, Cyber Statecraft Initiative, at The Atlantic Council. Jeff received a Bachelor of Science in computer information systems and an MBA from the Fisher College of Business at The Ohio State University.
Jeff came to us with an intriguing topic. He proposes what he calls a Detect, Defend, and Respond Posture in Cybersecurity, and postulates that cybersecurity can learn lessons from “the mature sciences of physical security and fire protection.” No matter how you’re securing your system now, there’s often room for improvement, and always room for taking in new ideas, so let’s take a closer look!
About Infosec Infosec believes knowledge is power when fighting cybercrime. We help IT and security professionals advance their careers with skills development and certifications while empowering all employees with security awareness and privacy training to stay cyber-safe at work and home. It’s our mission to equip all organizations and individuals with the know-how and confidence to outsmart cybercrime. Learn more at infosecinstitute.com.
This episode we welcome Rita Gurevich, CEO and founder of Sphere Technology Solutions. She talks about what it’s like to start her own company, why it is important to know your assets when setting policy, and what skills and experiences set applicants apart when they look to hire. Plus, she has plenty of data governance strategies to chat about.
0:00 - Intro 2:47 - Origin story 4:51 - The creation of Sphere 7:14 - Working solo at Sphere 9:12 - What would you change going back? 10:30 - Pricing your business activities 12:36 - Average day as a CEO 13:32 - Favorite parts of the job 14:50 - What is data governance? 17:40 - Factors driving data growth 19:28 - First steps to form data strategy 22:07 - Data governance best practices 23:40 - Time frame to get a master inventory 25:17 - What does good data governance do 26:12 - Skills I need for data governance and management 27:47 - Importance of collaboration and mentorship 30:26 - Skills and experiences for Sphere candidates 32:48 - Tips to get into cybersecurity work 34:06 - Outro
As the CEO and Founder of Sphere, Rita Gurevich is charged with leading the strategic growth of the organization in providing business critical governance, security and compliance solutions to customers spanning multiple geographic locations and industry verticals.
Gurevich founded Sphere after gaining a massive amount of experience in a short time period during the Lehman bankruptcy, the economic downturn of 2008, and the enhanced regulatory environment that dominated the industry. Being in a unique position from this experience, Gurevich founded Sphere as a single contributor, and worked strategically to grow the company into the entity it is today.
Gurevich is the recipient of multiple honors and awards including recognition from her Entrepreneurial skills from Ernst & Young, and SmartCEO, along with being on the 40 Under 40 list in 2017. In addition, Gurevich sits on the Board of Directors for the New Jersey Technology Council.
This week’s topic is data governance strategies in 2021. As more of what we do goes online and into the cloud, and as more people need access to information, making sure that entrance points aren’t more accessible than they need to be is more important than ever. We’re going to talk about the issues around this topic, and also job strategies for people who want to do this type of work.
About Infosec Infosec believes knowledge is power when fighting cybercrime. We help IT and security professionals advance their careers with skills development and certifications while empowering all employees with security awareness and privacy training to stay cyber-safe at work and home. It’s our mission to equip all organizations and individuals with the know-how and confidence to outsmart cybercrime. Learn more at infosecinstitute.com.
Ginny Morton, project management professional at Dell and veteran in the U.S. Army, takes us through the practice of cybersecurity project management in both for-profit and military sectors on today’s episode. We talk about Scrum and Agile certifications, building the best team for the project and tapping into your personal power in your work.
0:00 - Intro 2:04 - Origin story 4:47 - What does a cybersecurity project manager do? 6:10 - Average work day as a project manager 7:40 - Best and worst parts of project management 9:30 - How does a PM improve cybersecurity work? 10:40 - Dell team management 12:50 - Being the team’s first manager 14:36 - Best project management certifications 21:02 - PM work for Dell versus the military 23:00 - Military clearances for PM work 24:08 - Skills and experiences necessary for high-level PM 22:52 - Skills and interests for a successful career 27:04 - Tips for those who want to transition careers 27:38 - Changes to PM work during COVID 28:40 - Adjustments to work from home 29:55 - Will PM work change? 31:04 - Outro
Ginny Morton is a senior cyber security advisor, program management at Dell, and has spent much of her career in the project management space for cybersecurity, previously working at TekSystems and in both the Texas Army National Guard and the U.S. Army.
Our recent guest, project manager Jackie Olshack, recommended Morton for the show, and as we had a ton of people tune in to see Jackie’s episode, we realize that our listeners are passionate about learning more about project management in IT and cyber as a career path, so I’m looking forward to talking with Morton about her career path as well as the unique aspects of doing project management work on a federal/military level.
About Infosec Infosec believes knowledge is power when fighting cybercrime. We help IT and security professionals advance their careers with skills development and certifications while empowering all employees with security awareness and privacy training to stay cyber-safe at work and home. It’s our mission to equip all organizations and individuals with the know-how and confidence to outsmart cybercrime. Learn more at infosecinstitute.com.
Splunk is a Data-to-Everything Platform designed to ingest and analyze all kind of data. They can be visualized and correlated through Splunk searches, alerts, dashboards, and reports. Splunk is the #1 of 2020 Gartner Magic Quadrants in SIEMs for its performant analysis and visionary in Application Performance Management category.
Splunk and SCRT Analytics Team
SCRT provides its Splunk-based SIEM solution focused in first place on suspicious behavior detection through a custom library of use cases based on its on-field experience and know-how in Cyber Security.
SCRT chose Splunk Enterprise and Splunk Enterprise Security providing an integration with customer infrastructure and providing all the Splunk power to ingest, correlate, analyse and display valuable information for anomaly detection.
Nevertheless, Splunk has a lack of a viable solution for a proper whitelisting strategy that would enable users to delete part of their search results. For this purpose, SCRT has developed a custom Splunk app called “Event Masker” that provides filtering functionalities with a simple and powerful whitelist rules editor.
Event Masker
Event Masker provides filtering functionalities in Splunk, thereby permitting you to whitelist the events of your choice. Even though you can use Event Masker on any dashboard or query in the Splunk search bar, it was primarily built to reduce the number of false positives in Splunk Enterprise Security by better controlling its notable events.
Event Masker provides:
Rules management through an advanced interface that permits to create, import, export and edit rules properties. Each Rule contains a set of conditions, applied when Event Masker is called in a Splunk search command or correlation search.
Rules list interface
Rule’s properties
Rule’s conditions
The custom search command “mask” which permits to call Event Masker from the command line.
Some dashboards to audit the masked events and check the underlying rules.An audit log that permits to further track events that were masked over time
Event Masker Overview dashboardMasked events over timeRule logs
We are pleased to provide this app freely to the Splunker’s community with a public GitHub repository https://github.com/scrt/event_masker/. Feel free to co-develop with us on this app to improve the Splunk experience and the efficiency of threats detections.
Many thanks to the whole SCRT Analytics team for its expertise and performance that permitted to achieve this great project.
Dirk Schrader of New Net Technologies talks about healthcare security and legacy systems. We discuss the millions of pieces of health data left out in the open, the issues with closing these holes and the need for professional legacy system-whisperers.
0:00 - Intro 2:56 - What drew Dirk to security 4:46 - Did your Dad’s role inspire you? 5:55 - Stepping stones to your current job 9:35 - What is it like to be a security research manager 14:38 - Unprotected healthcare records 21:50 - Unprotected systems in the U.S. 25:20 - Using better security in hospitals 31:55 - Logistical issues of security for hospitals 37:48 - Best solution for hospital cybersecurity 39:30 - How to prepare for change 42:32 - What skills do you need for this work? 46:00 - Will people pursue these changes? 49:40 - Projects Dirk’s working on 52:10 - Outro
Dirk Schrader is the global VP of New Net Technologies (NNT). A native of Germany, Dirk’s work focusses on advancing cyber resilience as a sophisticated, new approach to tackle cyberattacks faced by governments and organizations of all sizes for the handling of change and vulnerability as the two main issues to address in information security.
Dirk has worked on cybersecurity projects around the globe, including more than four years in Dubai. He has published numerous articles in German and English about the need to address change and vulnerability to achieve cyber resilience, drawing on his experience and certifications as CISSP (ISC²) and CISM (ISACA). His recent work includes research in the area of medical devices, where he found hundreds of systems unprotected in the public internet, allowing access to sensitive patient data. This is going to be the topic of today’s episode, and we’re also going to talk about unprotected or poorly protected legacy systems in general, and how we start to build some coverage over this vast swath of unprotected information.
About Infosec Infosec believes knowledge is power when fighting cybercrime. We help IT and security professionals advance their careers with skills development and certifications while empowering all employees with security awareness and privacy training to stay cyber-safe at work and home. It’s our mission to equip all organizations and individuals with the know-how and confidence to outsmart cybercrime. Learn more at infosecinstitute.com.
French Caldwell of The Analyst Syndicate talks about his role as founder and chief researcher of the group. We also talk about Caldwell’s time at Gartner research, and his passion for cybersecurity research as a whole.
00:00 - Intro 03:43 - Caldwell’s background in cybersecurity 07:25 - Knowledge management 09:55 - Protecting digital trash 12:33 - Risk assessment and day-to-day work life 18:00 - How has research changed since 1999? 22:48 - Founding The Analyst Syndicate 26:45 - What is your day like at the Syndicate? 28:11 - What is your research like now? 29:33 - Disruptive technology and public policy 31:09 - Disruptive trends 34:30 - Advice to students in disruptive technologies 38:58 - Tell us about your simulator 46:22 - Cyberterrorism and risk to municipalities and hospitals 50:18 - Learn more about Caldwell and the Syndicate 51:54 - Outro
French Caldwell is the leading strategist and thought leader in RegTech, including GRC and ESG, cybersecurity, social and digital risks and regulation and the impact of disruptive technologies on policy and strategy. He is a former Gartner Fellow, and following Gartner he became the global head of marketing at a Silicon Valley firm that delivers regtech solutions for governance, risk and compliance analytics and reporting. Skilled at the alignment of strategy, communications, technology, processes, analysis, policy and people to improve business and mission outcomes. Experienced at advising senior executives and corporate directors on disruptive technology, strategic risk management, cybersecurity and public policy issues.
About Infosec Infosec believes knowledge is power when fighting cybercrime. We help IT and security professionals advance their careers with skills development and certifications while empowering all employees with security awareness and privacy training to stay cyber-safe at work and home. It’s our mission to equip all organizations and individuals with the know-how and confidence to outsmart cybercrime. Learn more at infosecinstitute.com.
Jonathan Tanner of Barracuda talks about his time moving up the ladder at Barracuda, how he still enjoys computer science competitions like DEFCON Wireless Capture the Flag (CTF), and Barracuda’s revolutionary malware detection ATP platform he built.
0:00 - Intro 3:04 - Origin story in cybersecurity 5:45 - Major accomplishments and moving up with Barracuda 7:55 - Daily work as senior security researcher 10:36 - Was this always what you were interested in? 12:42 - How did you expand your skills and position 14:30 - Cyber security resume tips 17:20 - Becoming a cybersecurity professional 19:01 - How can hackathons and conferences help you? 22:33 - Improving the hiring process 25:33 - How to prepare for cyber security interview 27:46 - Working long term with a tech company 29:27 - What’s next for you at Barracuda? 30:26 - Where should security professionals begin? 33:46 - What’s happening at Barracuda 34:33 - Where can I find out more about you? 35:06 - Outro
About Infosec Infosec believes knowledge is power when fighting cybercrime. We help IT and security professionals advance their careers with skills development and certifications while empowering all employees with security awareness and privacy training to stay cyber-safe at work and home. It’s our mission to equip all organizations and individuals with the know-how and confidence to outsmart cybercrime. Learn more at infosecinstitute.com.
Alyssa Miller of S&P Global Ratings discusses the easiest pentest she ever ran on an app and the importance of diversity of hiring, not just “diversity of thought.” She also gives some of the best advice we’ve heard yet on picking your cybersecurity path.
0:00 - Intro 2:44 - Miller’s origin story 5:53 - Experiences working while at school 8:20 - Pursuing a degree 10:57 - How has cybersecurity changed? 12:58 - Coming into cybersecurity from a different perspective 13:55 - Moving to pentesting versus programming 18:52 - Penetration testing through the years 20:46 - A big change in your industry 25:27 - Specifics of a business information security officer 29:09 - Skills for a business information security officer role 32:34 - “Cyber Defenders’ Career Guide” book 35:08 - What surprised you about writing the book? 41:46 - Equity and inclusion in cybersecurity 47:11 - Who is doing equity correctly? 49:12 - Long term equity strategies? 52:45 - Final cybersecurity career advice 55:40 - Outro
Alyssa Miller is a hacker, security researcher, advocate and international public speaker with over 15 years of experience in cybersecurity. From a young age, she has enjoyed exploring and deconstructing technology to learn more about how it works. At 12 years old, she bought her first computer. From that $1,000 purchase, she launched a hobby that would later become her career. Just seven years later, she was hired to her first full-time salary job as a programmer. Alyssa is also passionate that doing better in security begins with sharing knowledge and learning from each other. She regularly presents her perspectives through public speaking engagements. She speaks at various industry conferences, vendor and customer hosted events and non-security related events. Alyssa’s mission is to improve all aspects of the security community. Therefore, her topics range from technical to strategic to higher level community and policy issues.
Alyssa is a member of Women in Cyber Security (WiCyS) Racial Equity Committee. Additionally, she participates in other organizations designed to build a more welcoming and cooperative culture in security. As a member of ISACA, Alyssa currently holds a Certified Information Security Manager (CISM) certification. She is also the author of "The Cyber Defenders’ Career Guide," published by Manning in May 2021. We’re going to be discussing all of Alyssa’s fascinating story, her career journey, the work of demystifying cybersecurity and her work helping to create a more inclusive and welcoming space in the cybersecurity industry.
About Infosec Infosec believes knowledge is power when fighting cybercrime. We help IT and security professionals advance their careers with skills development and certifications while empowering all employees with security awareness and privacy training to stay cyber-safe at work and home. It’s our mission to equip all organizations and individuals with the know-how and confidence to outsmart cybercrime. Learn more at infosecinstitute.com.
Veracode CEO Sam King is an icon in the realms of secure coding and application security, and she joins the podcast, along with Infosec CEO Jack Koziol, to discuss her cybersecurity journey, the President’s directive on software security and so, so many more topics. You really don’t want to miss this one, folks.
0:00 - Intro 3:10 - Origin story 5:05 - Ground floor of cybersecurity 7:54 - The “aha!” moments 12:30 - Point were you thought industry would grow 14:28 - Changes implemented at Veracode 19:52 - Nation’s approach to cybersecurity 24:10 - Federal government security 26:25 - Government oversight 28:14 - Secure coding practices 31:52 - Veracode’s app security report 40:04 - How to learn web application security 43:46 - Mistakes to avoid when applying 47:13 - Bringing in more diverse candidates 51:36 - Maintaining Veracode’s edge 54:25 - Advice to move into a new cybersecurity role 56:24 - Outro
Sam King is the chief executive officer of Veracode and a recognized expert in cybersecurity, DevSecOps and business management. A founding member of Veracode, Sam has played a significant role in the company’s growth trajectory over the past 15 years, helping to mature it from a small startup to a company with a billion dollar plus valuation. Under her leadership, Veracode has been recognized with several industry distinctions including a seven-time consecutive leader in the Gartner Magic Quadrant, leader in the Forrester SAST Wave and a Gartner Peer Insights Customer Choice for Application Security. Sam has been a keynote speaker at events such as Gartner Security Summit, RSA and the Executive Women’s Forum, on topics ranging from cybersecurity to empowering women and creating diverse and resilient corporate cultures. She has been profiled in business publications such as the Huffington Post, CNNMoney, Financial Times, InfoSecurity Magazine and The Boston Globe.
Sam received her masters of science and engineering in computer and information science from University of Pennsylvania. She earned her BS in computer science from University of Strathclyde in Glasgow, Scotland, where she earned the prestigious Charles Babbage Award, awarded to the student with the highest academic achievement in the graduating class. She currently sits on the board of Progress Software. Sam is also a member of the board of trustees for the Massachusetts Technology Leadership Council, where she was a charter member of the 2030 Challenge: a Tech Compact for Social Justice in efforts to bring more diversity to the local workforce.
About Infosec Infosec believes knowledge is power when fighting cybercrime. We help IT and security professionals advance their careers with skills development and certifications while empowering all employees with security awareness and privacy training to stay cyber-safe at work and home. It’s our mission to equip all organizations and individuals with the know-how and confidence to outsmart cybercrime. Learn more at infosecinstitute.com.
Becky Robertson joins us from Booz Allen to discuss creating remote work situations that address modern requirements but don’t sacrifice security. We discuss the ways in which COVID-19 helped the federal sector reconsider every aspect of the workflow process and what that means for future remote roles.
0:00 - Intro 2:21 - Cybersecurity origin story 4:58 - Changes from the early days of cybersecurity 6:24 - Staying in the same organization for 25 years 8:56 - Day-to-day work as a VP 10:56 - Security and working from home 13:18 - Technical hurdles to work remotely 15:15 - Changing the nature of work post pandemic 16:58 - Employees working remotely 19:04 - Security concerns when working remotely 22:55 - How to pursue a federal cybersecurity career 25:18 - Federal cybersecurity positions in demand 27:42 - Skills needed to work in federal government 29:33 - Federal skills gaps 32:05 - Career advice 32:57 - Finding mentors
About Infosec Infosec believes knowledge is power when fighting cybercrime. We help IT and security professionals advance their careers with skills development and certifications while empowering all employees with security awareness and privacy training to stay cyber-safe at work and home. It’s our mission to equip all organizations and individuals with the know-how and confidence to outsmart cybercrime. Learn more at infosecinstitute.com.
Before I get started I want to clearly state that I am in no way affiliated, sponsored, or endorsed with/by Palo Alto Networks. All graphics are being displayed under fair use for the purposes of this article.
I recently encountered several unpatched Palo Alto firewall devices during a routine red team engagement. These particular devices were internet facing and configured as Global Protect gateways. As a red teamer/bug bounty rookie, I am often asked by customers to prove the exploitability of vulnerabilities I report. With bug bounty, this will regularly be a stipulation for payment, something I don’t think is always necessary or safe in production. If a vulnerability has been proven to be exploitable by the general security community, CVE issued, and patch developed, that should be sufficient for acceptance as a finding. I digress…
The reason an outdated Palo Alto Global Protect gateway caught my eye was because of a recent blog post by DEVCORE team members Orange Tsai(@orange_8361) and Meh Chang(@mehqq_). They identified a pre-authentication format string vulnerability (CVE-2019-1579) that had been silently patched by Palo Alto a little over a year ago (June 2018). The post also provided instructions for safely checking the existence of the vulnerability as well as a generic POC exploit.
Virtual vs Physical Appliance
If you’ve made it this far, you’re probably wondering why there’s need for another blog post if DEVCORE already covered things. According to the post, “the exploitation is easy”, given you have the right offsets in the PLT and GOT, and the assumption that the stack is aligned consistently across versions. In reality however, I found that obtaining these offsets and determining the correct instance type and version to be the hard part.
Palo Alto currently markets several next generation firewall deployments, that can be broadly categorized into physical or virtual. The focus of the exploitation details in the article are based on a virtual instance, AWS in this scenario. How then do you determine whether or not the target device you are investigating is virtual or physical? In my experience, one of the easy ways is based on the IP address. Often times companies do not setup reverse DNS records for their virtual instances. If the IP/DNS belongs to a major cloud provider, then chances are it’s a virtual appliance.
If you determine that the firewall type is an AWS instance, then head over to AWS marketplace and spin up a Palo Alto VM. One of the first things you’ll notice here is that you are limited to only the newest releases of 8.0.x, 8.1.x, 9.0.x.
Don’t worry, you can actually upgrade and downgrade the firmware from the management web interface once it has been launched… if you have a valid support license for the appliance. There are some nuances however, if you launch 9.0.x, it can only be downgraded to 8.1.x. Another very important detail is to ensure you select a “m4” instance or when you downgrade to 8.x.x or the AWS instance will be unreachable and thus unusable. For physical devices, the firmware supported can be found here
Getting ahold of a valid support license varies in difficulty and price. If you are using the AWS Firewall Bundle, the license is included. If it’s a physical device, it can get complicated/expensive. If you buy the device new from an authorized reseller, you can activate a trial license. If you buy one through something like Ebay and it’s a “production” device, make sure the seller transfers the license to you otherwise you may have to pay a “recertification” fee. If you get really lucky and the device you buy happens to be a RMA-ed device, when you register it it will show as a spare and you get no trial license, you have to pay a fee to get it transferred to production, and then you have to buy a support license.
Once you have the appliance up and running with the version you want to test, you will need to install a global protect gateway on one of the interfaces. There’s a couple youtube videos out there that go over some of the installation steps but you basically just have to step your way through it until it works. Palo Alto provides some documentation that you can use as a reference if you get stuck. One of the blocking requirements is to install a SSL certificate for the Global Protect gateway. The easiest thing here is to just generate a self signed certificate and import it. A simple guide can be found here. Supposedly one can be generated on the device as well.
If you are setting up an AWS instance, you will need to change a key setting on the network interface or the global protect gateway will not be accessible. Goto the network interface that is being used for the Global Protect interface in AWS. Right click and select “Change Source/Dest Check”. Change the value to “Disabled” as shown below.
Exploitation
Alright, the vulnerable device firmware is installed and the global protect gateway is configured, we’re at the the easy part right??? Well not exactly… When you SSH into the appliance you’ll find you are in a custom restricted shell that has very limited capabilities.
In order to get those memory offsets for the exploit we need access to the sslmgr binary. This is going to be kinda hard to pull off in a restricted shell. Previous researchers found at least one way, but it appears to have been fixed. If only there was another technique that worked, then theoretically you could download each firmware version, copy it from the device, and retrieve the offsets.
What do we do if we can’t find such a jailbreak… for every version??? Well it turns out we may be able to use some of the administrative functions of the device and the nature of the vulnerability to help us. One of the features that the limited shell provides is the ability to increase the verbosity of the logs generated by key services. It also allows you to tail the log files for each service. Given that the vulnerability is a format string bug, could we leak memory into the log and then read it out? Let’s take a look at the bug(s).
And immediately following, is the exact code we were hoping for. It must be our lucky day.
So as long as we populate those four parameters, we can pass format string operators to dump memory from the process to the log. Why is this important? This means we can dump the entire binary from memory and retrieve the offsets we need for the exploit. Before we can do that, first we need to identify the offsets to the buffers on the stack for each of our parameters. I developed a script that you can grab from Github that will locate the specified parameters on the stack and print out the associated offsets.
The script should output something like the screenshot below. Each one of these offsets points to a buffer on the stack that we control. We can now select one and populate it with whatever memory address we like and then use the %s format operator to read memory at that location.
As typically goes, there are some problems we have to work around to get accurate memory dumps. Certain bad characters will cause unintended output: \x00, \x25, and \x26.
Null bytes cause a problem because sprintf and strlen recognize a null byte as the end of a string. A work around is to use a format string to point to a null byte at a known index, e.g. %10$c.
The \x25 character breaks our dump because it represents the format string character %. We can easily escape it by using two, \x25\x25.
The \x26 character is a little trickier. The reason this character is an issue is because it is the token for splitting the HTTP parameters. Since there aren’t a prevalence of ampersands on the stack at known indexes, we just write some to a known index using %n, and then reference it whenever we encounter an address with a \x26.
Putting this all together, I modified my previous script to write a user-supplied address to the stack, deference it using the %s format operator, and then output the data at that address to the log. Wrapping this logic in a loop combined with our handling of special characters allows us to dump large chunks of memory at any readable location. You can find a MIPS version of this script on our Github and executing it should give you output that looks something like the screenshot below.
Now that we have the ability to dump arbitrary memory addresses, we can finally dump the strlen GOT and system PLT addresses we need for the exploit, easy… except, where are they??? Without the sslmgr binary how do we know what memory address to start dumping to get the binary? We have a chicken or the egg situation here and the 64 bit address space is pretty big.
Luckily for us, the restricted shell provides us one more break. If a critical service like sslmgr crashes, a stack trace and crash dump can be exported using scp. At this point I’ve gotten pretty good at crashing the service so we’ll just throw some %n format operators at arbitrary indexes.
I learned something new about IDA Pro during this endeavor. You can use it to open up ELF core dumps. Opening up the segmentation view in IDA we could finally see where the binary is being loaded in memory. Another interesting detail we noticed while debugging our payloads was that it appeared ASLR was disabled on our MIPS physical device as the binary and loaded libraries were always loaded at the same addresses.
Finally, let’s start dumping the binary so we can get our offsets. We have roughly 0x40000 bytes to dump, at approximately 4 bytes/second. Ummm, that’s going to take… days. If only there was a shortcut. All we really need are the offsets to strlen and system in the GOT and PLT.
Unfortunately, even if we knew exactly were the GOT and PLT were, there’s nothing in the GOT or PLT that indicates the function name. How then does GDB or IDA Pro resolve the function names? It uses the ELF headers. We should be able to dump the ELF headers and a fraction of the binary to resolve these locations. After an hour or two, I loaded up my memory dump into Binary Ninja, (IDA Pro refused to load my malformed ELF). Binary Ninja has proven to be invaluable when analyzing and manipulating incomplete or corrupted data.
A little bit of research on ELF reveals that the PT_DYNAMIC program header will hold a table to other sections that hold pertinent information about an executable binary. Three of which are important to us, the Symbol Table (DT_SYMTAB-06), the String Table (DT_STRTAB-05), and the Global Offset Table (DT_PLTGOT-03). The Symbol Table will list the proper order of the functions in the PLT and GOT sections. It also provides an offset into the String Table to properly identify each function name.
With the offsets to the SYMBOL and STRING tables we can properly resolve the function names in the PLT & GOT. I wrote a quick and dirty script to parse through the symbol table dump and output a reordered string table that matches the PLT. This probably could have been done using Binary Ninja’s API, but I’m a n00b. With the symbol table matched to the string table, we can now overlay this with the GOT to get the offsets we need for strlen and system. We have two options for dumping the GOT. We can either use the crash dump from earlier, or manually dump the memory using our script.
I decided to go with the crash dump to save me a little time. The listing above shows entries in the GOT that point to the PLT (0x1001xxxx addresses) and several library functions that have already been resolved. Combined with our string table we can finally pull the correct offsets for strlen and system and finalize our POC. Our POC is for the MIPS based physical Palo Alto appliance but the scripts should be useful across appliance types with minor tweaking. Wow, all done, easy right?
Important Note
While the sslmgr service has a watchdog monitor to restart the process when it crashes, if it crashes more than ~3 times in a short amount of time, it will not restart and will require a manual restart. Something to keep in mind if you are testing your shiny new exploit against a customer’s production appliance.
Earlier last year I came across an article by Provadys (now Almond) highlighting several bugs they had discovered based on research by James Forshaw of Google’s Project Zero. The research focused on the exploitation of Windows elevation of privilege (EOP) vulnerabilities using NTFS junctions, hard links, and a combination of the two Forshaw coined as Windows symlinks. James also released a handy toolset to ease the exploitation of these vulnerabilities called the symbolic testing toolkit. Since they have done such an excellent job describing these techniques already, I won’t rehash their inner workings. The main purpose of this post is to showcase some of our findings and how we exploited them.
Findings
My initial target set was software covered under a bug bounty program. After I had exhausted that group I moved on to Windows services and scheduled tasks. The table below details the vulnerabilities discovered and any additional information regarding the bugs.
Obligatory statement: This blog post is in no way affiliated, sponsored, or endorsed with/by Synack, Inc. All graphics are being displayed under fair use for the purposes of this article.
Over the last few months Synack has been running a user engagement based competition called Red vs Fed. As can be deduced from the name, the competition was focused on penetration testing Synack’s federal customers. For those of you unfamiliar with Synack, it is a crowd-sourced hacking platform with a bug bounty type payment system. Hackers (consultants) are recruited from all over the planet to perform penetration testing services through Synack’s VPN-based platform. Some of the key differences marketed by Synack between other bounty platforms are a defined payout schedule based on vulnerability type and a 48 hour triage time.
Red Vs Fed
This section is going to be a general overview of my experience participating in my first hacking competition with Synack, Red Vs Fed. At times it may come off as a diatribe so feel free to jump forward to the technical notes that follow. In order for any of this to make sense we first have to start off with the competition rules and scoring. Points were awarded per “accepted” vulnerability based on the CVSS score determined by Synack on a scale of 1-10. There were also additional multipliers added once you passed a certain number of bugs accepted. The important detail here is the word “accepted”, which means you have to pass the myriad of exceptions, loopholes, and flat-out dismissal of submitted bugs as it goes through the Synack triage process. The information behind all of these “rules” is scattered across various help pages accessible by red team members. Example of some of these written, unwritten, and observed rules that will be referenced in this section:
Shared code: If a report falls within about 10 different permutations of what may be guessed as shared code/same root issue, the report will be accepted at a substantially discounted payout or forced to be combined into a single report.
24 hour rule: In the first 24 hours of a new listing, any duplicate reports will be compared by triage staff and they will choose which report they feel has the highest “quality“. This is by far the most controversial and abused “feature” as it has led to report stuffing, favoritism, and even rewards given after clear violation of the Rules of Engagement.
Customer rejected: Even though vulnerability acceptance and triage is marketed as being performed internally by Synack experts within 48 hours, randomly some reports may be sent to the customer for determination of rejection.
Low Impact: Depending on the listing type, age of the listing, or individual triage staff, some bugs will be marked as low impact and rejected. This rule is specific to bugs that seem to be some-what randomly accepted on targets even though they all fall into the low impact category.
Dynamic Out-of-Scope: Bug types, domains, and entire targets can be taken out of scope abruptly depending on report volume. There are loopholes to this rule if you happen to find load balancers or CNAME records for the same domain targets.
Target Analytics: This is a feature not a rule but it seemed fitting for this list. When a vulnerability is accepted by Synack on a target, details like the bug type and location are released to all currently enrolled on the target.
About a month into the competition I was performing some rudimentary endpoint discovery (dirsearch, Burp intruder) on one of the legacy competition targets and had a breakthrough. I got a hit on a new virtual host on a server in the target scope, i.e. a new web application. When I come across a new application, one of the first things I try to do is to tune my wordlist for the next round of endpoint enumeration. I do this using endpoints defined in the source of the page, included javascript files, and identification of common patterns in naming, e.g. prefix_word_suffix.ext. On the next round of enumeration I hit the error page below.
A bug hunter can’t ask for an easier SQL injection vulnerability, verbose error messages, the actual SQL query with database names, tables names, and column names. I whipped up a POC, (discussed further down) and starting putting together a report for the bug. After a little more recon, I was able to uncover and report a handful of additional SQLi vulns over the next couple days. While continuing to discover and “prove” SQLi on more endpoints, I was first introduced to (5) as the entire domain was taken out of scope for SQLi. No worries, at least my bugs were submitted so no one else should be able to swoop in and cleanup my leftovers. Well not exactly, it just so happened that there was a load balancer in front of my target as well as a defined CNAME (alias) for my domain. This meant thanks to (6) another competitor saw my bugs, knew about this loophole and was able to submit an additional 5 SQLi on this aliased domain before another dynamic OOS was issued.
At this point, the race was on to report as many vulnerabilities on this new web application now that my discovery was now public to the rest of the competitors via analytics. I managed to get in a pretty wide range of vulnerabilities on the target but they were pretty well split with the individual that was already in second place, putting him into first place. With this web application pretty well picked through I began looking for additional vhosts on new subdomains in hopes of finding similar vulnerable applications. I also began to strategize about how best to submit vulnerabilities in regards to timing and grouping given my last outcome realizing these nuances could be the difference between other competitors scooping them up, Synack taking them out of scope, or forcing reports to be combined.
A couple weeks later I caught a lucky break. I came across a couple more web applications on a different subdomain that appeared to be using the same web technologies as my previous find and hopefully similarly buggy code. As I started enumerating the targets the bugs started stacking up. This time I took a different approach. Knowing that as soon as my reports hit analytics it would be a feeding frenzy amongst the other competitors, I began queuing up reports but not submitting them. After I had exhausted all the bugs I could find, I began to submit the reports in chunks. Chunks sized close to what I expected the tolerance for Synack to issue the vulnerability class OOS but also in small enough windows that hopefully other competitors wouldn’t be able to beat me to submission by watching analytics. Thankfully, I was able to slip in all of the reports just before the entire parent domain was taken OOS by Synack.
Back to the grind… After the last barrage of vulnerability submissions I managed to get dozens of websites taken out of scope so I had to set my sights on a new target. Luckily I had managed to position myself in first place after all of the reports had been triaged.
Nothing new here, lots of recon and endpoint enumeration. I began brute-forcing vhosts on domains that were shown to host multiple web applications in an attempt to find new ones. After some time I stumbled across a new web application on a new vhost. This application appeared to have functionality broken out into 3 distinct groupings. Similar to my previous finds I came across various bug types related to access control issues, PII disclosure, and unauthorized data modification. I followed my last approach and began to line-up submissions until I had finished assessing the web application. I then began to stagger the submissions based on the groupings I had identified.
Unfortunately things didn’t go as well this time. The triage time started dragging on so I got nervous I wouldn’t be able to get all of my reports in before the target was put out of scope. I decided to go ahead and submit everything. This was a mistake. When the second group of reports hit, the triage team decided that they considered all 6 of the reports stemmed from an access control issue. They accepted a couple as (1) shared code for 10% payout, then pushed back a couple more to be combined into one report. I pleaded my case to more than one of the triage team members but was overruled. After it was all said and done they distilled dozens of vulnerabilities across over 20 endpoints into 2 reports that would count towards the competition and then put the domain OOS (5). Oh well… I was already in first so I probably shouldn’t make a big stink right?
Over the next month it would seem I was introduced to pretty much any way reports could be rejected unless it was a clear CVSS 10 (This is obviously an exaggeration but these bug types are regularly accepted on the platform).
1. User account state modification (Self Activation/Auth Bypass, Arbitrary Account Lockout) – initially rejected, appealed it and got it accepted
2. PII Disclosure – Rejected as (3). Claimed as customer won’t fix
3. User Login Enumeration on target with NIST SP 800-53 requirement – Rejected as (3) and (4) – Even though a email submission captcha bypass was accepted on the same target… Really???
4. Phpinfo page – Rejected as (4) even though these are occasionally accepted on web targets
5. Auth Bypass/Access Control issue – Endpoint behind a site’s login portal allowed for the live viewing of CC feeds – Rejected as (4) with the following
6. Unauthenticated, On-demand reboot of network protection device – Rejected as (3) even though the exact same vulnerability had been accepted on a previous listing literally 2 days prior with points awarded toward the competition. The dialog I had with the organizer about the issue below:
At this point it really started to feel like I was fighting a unwinnable battle against the Synack triage team. 6 of my last 8 submissions had been rejected for some reason or another and the other 2 I had to fight for. Luckily the competition would be over shortly and there were very few viable targets eligible for the competition. With 2 days remaining in the competition I was still winning by a couple bugs.
I wish I could say everything ended uneventfully 2 days later but what good Synack sob story doesn’t talk about the infamous 24 hour rule (2). To make things interesting a web target was released roughly 2 days before the end of the competition. I mention “web” because the acceptance criteria for “low impact” (4) bugs is typically lowered for these assessment types which means it could really shake up the scoreboard. Well here we go…
I approached the last target like a CTF, only 48 more hours to hopefully secure the win. Ironically, the last target had a bit of a CTF feel to it. After navigating the application a little, it became obvious that the target was a test environment that had already undergone similar pentests. It was littered with persistent XSS payloads that had been dropped from over a year prior. These “former” bugs served as red herrings as the application was no longer vulnerable to them even though the payloads persisted. I presume they also served as a time suck for many as under the 24 hour rule (1) any red teamer could win the bug if their report was deemed the “best” submission. Unfortunately however, with only a few hours into the test the target became very unstable. The server didn’t go down but it became nearly impossible to login to, regularly returning an unavailable message as if being DOS-ed. Rather than continue to fight with it I hit the sack with hopes that it would be up in the morning.
First thing in the morning I was back on it. With only 12 hours left in the 24 hr rule ( or so I thought) I needed to get some bugs submitted. I came a across an arbitrary file upload with a preview function that looked buggy.
The file preview endpoint contained an argument that specified the filename and mimetype. Modifying these parameters changed the response Content-Type and Content-Disposition (whether the response is displayed or downloaded) headers.
I got the vulnerability written up and submitted before the end of the 24 hour rule. Since persistent XSS has a higher payout and higher CVSS score on Synack, I chose this vulnerability type rather than arbitrary file upload. Several hours after my submission, an announcement was made that due to the unavailability of the application the night previous ( possible DOS) that the 24 hour rule would be extended 12 hours. Well that sux… that means I will now be competing with more reports of possibly better quality for the bug I just submitted because of the extension. Time to go look for more bugs and hopefully balance it out.
After some more trolling around, I found an endpoint that imported records into a database using a custom XML format. Features like this are prime for XXE vulnerabilities. After some testing I found it was indeed vulnerable to blind XXE. XXE bugs are very interesting because of the various exploit primitives they can provide. Depending on the XML parser implementation, the application configuration, system platform, and network connectivity, these bugs can be used for arbitrary file read, SSRF, and even RCE. The most effective way to exploit XXEs is if you have the XML specification for the object being parsed. Unfortunately, for me the documentation for the XML file format I was attacking was behind a login page that was out-of-scope. I admit I probably spent too much time on this bug as the red teamer in me wanted RCE. I could get it to download my DTD file and open files but I couldn’t get it to leak the data.
Since I couldn’t get LFI working, I used the XXE to perform a port scan on the internal server to at least ensure I could submit the bug as SSRF. I plugged in the payload to Burp Intruder and set it on its way to enumerate all the open ports.
After I got the report written up for SSRF I held off on submission in hopes I could get the arbitrary file read (LFI) to work and maybe pull off remote code execution. Unfortunately about this time the server started to get unstable again. For the second night in a row it appeared as if someone was DOS-ing the target and it was between crawling and unavailable. Again I decided to go to bed in hopes by morning it would be usable.
Bright and early I got back to it, only 18 hours left in the competition and the target was up albeit slow. I spent a couple more hours on my XXE but with no real progress. I decided to go ahead and submit before the extended 24 hour rule expired to again hopefully ensure at least a chance at winning a possible “best” report award. Unsurprisingly, a couple hours later the 24 hour rule was extended again (because of the DOS) with it ending shortly before the end of the competition. On this announcement I decided I was done. While the reason behind the extension made sense, this could effectively put the results of the competition in the hands of the triage team as they arbitrarily chose best reports for any duplicated submissions.
The competition ended and we awaited the results. Based on analytics and my report numbers I determined that the bug submission count on the new target was pretty low. As the bugs started to roll in, this theory was confirmed. There were roughly 8 or so reports after accounting for combined endpoints. My XXE got awarded as a unique finding and my persistent XSS got duped under the 24 hour rule that was extended to 48. Shocking, extra time leads to better reports. Based on the scoreboard, the person in second must have scored every other bug on the board except 1, largely all reflective XSS. For those, familiar with Synack, this would actually be quite a feat because XSS is typically the most duped bug on the platform meaning they likely won best report for several other collisions. I’d like to say good game but certainly didn’t feel like it.
Technical Notes of Interest
The techniques used to discover and exploit most of the vulnerabilities I found are not new. That said, I did learn a few new tricks and wrote a couple new scripts that seemed worth sharing.
SQL Injection
SQL injections bugs were my most prevalent find in the competition. Unlike other bug bounty platforms, Synack typically requires full exploitation of vulnerabilities found for full payout. With SQL injection, typically database names, columns, tables, and table dumps are requested to “prove” exploitation rather than basic injection tests or SQL errors. While I was able to get some easy wins with sqlmap on several of the endpoints, some of the more complex queries required custom scripts to dump data from the databases. This necessity produced two new POCs I will describe below.
In my experience a large percentage of modern SQL injection bugs are blind. By blind, I’m referring to SQLi bugs that are not able to return data from the database in the request response. That said, there are also different kinds of blind SQLi. There are bugs that return error messages and those that do not ( completely blind). The first POC is an example of a HTTP GET, time-based boolean exploit for a completely blind SQL injection vulnerability on an Oracle database. The main difference between this POC and previous examples in my github repository is the following SQL query.
Copy to Clipboard
The returned table is two columns of type string and this query performs a boolean test against a supplied character limit, if the test passes, then the database will sleep for a specified timeout. The response time is then measured to verify the boolean test.
The second POC is an example of a HTTP GET, error-based boolean exploit for a partially blind SQL injection vulnerability on an Oracle database. This POC is targeting a vulnerability that can be forced to produce two different error messages.
Copy to Clipboard
The error message used for the boolean test is forced by the payload in the event that the “UTL_INADDR.get_host_name” function is disabled on the target system. Both of the POCs extract strings from the database a character at a time using the binary search algorithm below.
Copy to Clipboard
Remote Code Execution (Unrestricted File Upload)
Probably one of the more interesting of my findings was a file extension blacklist bypass I found for a file upload endpoint. This particular endpoint was on a ColdFusion server and appeared to have no allowedExtensions defined as I could upload almost any file types. I say almost because a small subset of extensions were blocked with the following error.
Further research found that the ability to upload arbitrary file types was allowed up until recently when someone reported it as a vulnerability and it was issued CVE-2019-7816. The patch released by Adobe created a blacklist of dangerous file extensions that could no longer be uploaded using cffile upload.
This got me thinking, where there is a blacklist, there is the possibility of a bypass. I googled around for a large file extension list and loaded it up into Burp Intruder. After burning through the list I reviewed the results to see a 500 error on the “.ashx” extension with a message indicating the content of my file was being executed. A little googling later, I replaced my file with this simple ASHX webshell from the internet and passed it a command. Bingo.
Wrap Up
Overall the competition proved to be a rewarding experience, both financially and academically. It also helped knowing that each vulnerability found was one less that could be used to attack US federal agencies. The prevailing criticism I have for the competition is that it was unfortunate that winning became more about exploiting the platform, its policies, and people more than finding vulnerabilities. In CTF this isn’t particularly unusual for newer contests which seem to forget (or not care) about the “meta” surrounding the competition itself. Hopefully, in future competitions some of the nuanced issues surrounding vulnerability acceptance and payout can be detached from the competition scoring. My total tally of vulnerabilities against Federal targets is displayed below.
Bug Type
Count
CVSS (Competition Metric)
SQL Injection
12
10
Access Control
8
5-9
Remote Code Execution
6
10
Persistent XSS
5
9
Authentication Bypass
2
8-9
Local File Include
2
8
Path Traversal
1
8
XXE
1
5
Rejected/Combined/Duped
16
0
On June 8th it was announced that I had taken 2nd place in the competition and won $15,000 in prize money.
Given the current global pandemic, we decided to donate the prize money to 3 organizations who focus on helping the less fortunate: Water Mission, Low Country Foodbank, and Build Up. For any of you reading this that may have a little extra in these trying times, consider donating to your local charities to support your communities.
Last month was Defcon and with it came the usual rounds of competitions and CTFs. With work and family I didn’t have a ton of time to dedicate to the Defcon CTF so I decided to check out the Red Team Village CTF. The challenges for the qualifier ranged pretty significantly in difficulty as well as category but a couple challenges kept me grinding. The first was the fuzzing of a custom C2 server to retrieve a crash dump, which I could never get to crash (Feel free to leave comments about the solution). The second was a two part challenge called “Seeding” in the programming category that this post is about.
Connecting to the challenge service returns the following instructions:
We are also provided with the following code snippet from the server that shows how the random string is generated and how the PRNG is seeded.
The challenge seemed pretty straight forward. With the given seed and code for generating the random string, we should be able to recover the key given enough examples. The thing that made this challenge a little different than other “seed” based crypto challenges I’ve seen is that the string is constructed using random.choice() over the key rather than just generating numbers. A little tinkering with my solution script shows that the sequence of characters generated by random.choice() varies based on the length of the parameter provided, aka the key.
This means the first objective we have is to determine the length of the key. We can pretty easily determine the minimal key length by finding the complete keyspace by sampling outputs from the service until we stop getting new characters in the oracle’s output. However, this does not account for multiples of the same character in the key. So how do we get the full length of the key? We have to leverage the determinism of the sequence generated by random. If we relate random.choice() to random.randint() we see they are actually very similar except that random.choice() just maps the next number in the random sequence to an index in the string. This means if we select a key with unique characters, we should be able to identify the sequence generated by the PRNG by noting the indexes of the generated random characters in the key. It also means these indexes, or key positions, should be consistent across keys of the same length with the same seed.
Applying this logic we create a key index map using our custom key and then apply it to the sample fourth iteration string provided by the server to reveal the positions of each character in the unknown key. Assuming the key is longer than our keyspace, we will replace any unknown characters with “_” until we deduce them from each sample string.
Now we have the ability to derive a candidate key based on the indexes we’ve mapped given our key and the provided seed. Unfortunately this alone doesn’t bring us any closer to determining the unknown key length. What happens if we change the seed? If we change the seed we get a different set of indexes and a different sampling of key characters.
In the example above, you’ll notice that no characters in our derived keys conflict. This is because we know that the key length is 10, since we generated it. What happens if we try to derive a candidate key that is not 10 characters long using the generated 4th iteration random string from a 10 character key?
It appears if the length of the key used to generate the random string is not the same length as our local key, then characters in our derived keys do not match for each index. This is great news because that means we can find the server key length by incrementing our key length from the length of our key space until our derived keys don’t conflict.
Unfortunately, this is where I got stumped during the CTF. When I looped through the different key lengths I never got matching derived keys for the server key. After pouring over my code for several hours I finally gave up and moved on to other challenges. After the CTF was over I reached out to the challenge creator and he confirmed my approach was the right one. He was also kind enough to provide me with the challenge source code so I could troubleshoot my code. Executing the python challenge server and running my solution code yielded the following output.
So what gives??? Now it works??? I chalked it up to some coding mistake I must have magically fixed and decided to go ahead and finish out the solution. The next step is to derive the full server key by sampling the random output strings from different seeds. I simply added a loop around my previous code with an exit condition when there are no more underscores (“_”) in our key array. Unfortunately when I submitted the key I got an socket error instead of the flag.
Taking a look at the server code I see the author already added debugging that I can use to troubleshoot the issue. The logs show a familiar python3 error in regards to string encoding/decoding.
Well that’s an easy fix. I’ll just run the server with python3 and we’ll be back in business. To my surprise re-running my script displays the following.
This challenge just doesn’t want to be solved. Why don’t my derived keys match-up anymore? This feels familiar. Is it possible that different versions of python affect the sequences produced by random for the same seed?
Well there ya have it. Depending on the version of python you are running you will get different outputs from random for the same seed. I’m going to assume this wasn’t intentional. Either that or the author wanted to inflict some pain on all of us late adopters Finishing up the solution, and running the server and solution code with python3 finally gave me the flags.
Even with all of the frustration I’d say it was a very satisfying challenge and I learned something new. Feel free to download the challenge and give it a go. Shout outs to @RedTeamVillage_, @nopresearcher, and @pwnEIP for hosting the CTF and especially the challenge creator @waldoirc.
