How Script Kiddies Use Open-Source Code

Are you a software engineer or a script kiddie?

One of my post that may later become a book on Secure Code. Also one of my posts on Application Security.

Free Content on Jobs in Cybersecurity | Sign up for the Email List

Do you copy and paste open-source code?

Have you ever found a piece of code that did what you needed — you think — and copied and pasted it into your own codebase? Magic! Just like that, it works. Problem solved. You move on. This is the root of some security problems involving open-source code.

I despised PHP when it first came out. It wasn’t because PHP was a bad language. It was because PHP made it easy for people who didn’t know what they were doing to tack pieces of code together into a house of cards that did something. People would call me and try to hire me when I ran my prior software development business, Radical Software, and tell me, “I’ve built this thing and it pretty much works but I just need someone to ‘finish it.’” I knew what that meant. It was a tangled mess that would take hours and hours to unravel and engineer properly. I almost always declined.

Often those web applications were sources of the latest security breach of the day. Because the website owners were just grabbing code and sticking it together without really understanding it, these sites were often full of vulnerabilities leveraged by attackers to infiltrate applications, servers, steal data, and perform other mischief.

PHP made programming easier and these newbie programmers could grab code snippets and tack them together into something functional. That’s great — except when those snippets contain security vulnerabilities. Sometimes attackers purposefully planted code to solve problems that included bugs they knew they could exploit.

How a script copied off the web can take over your cloud account

My security class, currently undergoing revisions, included a lab with a vulnerability in a Wordpress (written in PHP) site running on a cloud server with a particular template that allowed an attacker to insert a web shell and send commands to the server from a web page.

In other words, my students would inject (i.e. copy and paste) some code to perform an attack on the web server. Then they could open a web page hosted by that site in their browser and type Linux commands like ‘ls’ to list all the files on the server in their browser. From there, they could go on to steal the credentials of the host with a bit more work, and do whatever the credentials assigned to that webserver had permission to do.

If your web application contained that flaw, and you gave your webserver too many permissions and misconfigured it, an attacker could take over your entire cloud account.

Those are the things I taught in my security class and test for when my company performs cloud and application penetration tests. And that is the danger when copying and pasting open source code into your web applications without understanding what it can do, on top of what you want it to do.

In this scenario, a website developer used a WordPress theme in their website they probably didn’t fully understand or review. The attacker copied and pasted some code to exploit a vulnerability. None of that is what I would consider “software engineering.”

Reverse-Engineering

To use open-source code safely, first and foremost, you need to become a good software engineer so you understand what is and is not good software programming. You need to understand how to program and what the lines of code do as you use or write them. Once you know what constitutes good code and write your own well-engineered code, you start to develop the skills to evaluate other people’s code. You will be able to read and understand the code you come across as you build and fix systems.

The ability to look at someone else’s code and figure out what it is doing is called reverse engineering. That is an important skill for any top-notch software engineer. A lot of my work over the years involved reverse-engineering other people’s code.

Back when I was running Radical Software, I got called in to fix a failing licensing site once for an F5 product when a programmer took a trip to Europe. I had to reverse-engineer the code to determine the point of failure and how to fix it. As it turns out, when a particular database error occurred, the application failed to properly close the database connection and that would use up system memory. At some point, the system running the application ran out of memory and would crash at random times. To solve problems like that. you need to be able to read other people’s code and figure out what it is doing.

Now I use reverse-engineering to attack websites when performing penetration tests. I know how you write code. I’m going to try to break it! Security researchers use advanced reverse-engineering to dissect malware. I’ve done some of that myself while writing research reports for a security vendor and creating attacks to test customer applications to try to break into their cloud systems and accounts.

Some security researchers reverse engineer malware full time, turning compiled application code into assembly code with tools like IDA Pro or Ghidra. That’s some serious reverse-engineering and I can tell you it is some of the most complicated reverse-engineering I’ve had to do over the course of my career.

It takes time to learn to code properly and to get to the point where you can read other people’s code and dissect it. Often it’s easier to write your own code than to reverse-engineer someone else’s. That’s why sometimes programmers want to write a new application rather than fix an existing one. And sometimes, they will find some code that solves their particular problem and use it, failing to take the time to inspect or understand it completely. That can easily lead to security problems.

At times, the pressure of getting things done impressed upon people by business owners, managers, executives, product and program managers is the root cause. They would rather launch a product than take the time to review the code in it properly or perform a penetration test and fix the findings. So the blame is not always entirely on the programmers involved. 

Even when programmers speak up about problems, sometimes the executives will not listen. If you face this issue as a programmer, your best course of action document it and move on. I wrote about an issue I faced like this in my prior book on cybersecurity for executives. I documented an issue that later came to fruition. I was able to convince the organization to resolve it when proved problematic based on production data at a later point in time.

Don’t be a script kiddie!

Just because you can tack some scripts you found on the Internet together and make something work doesn’t make you a software engineer or a good programmer. In the cybersecurity industry, we call these types of programmers “script kiddies.”

Script kiddies can be amazingly successful at attacking a poorly engineered or secured web application. They find some scripts and run them against a host and like magic they break into your webserver. Script kiddies don’t need to worry about software engineering, understanding the code, or security. They are trying to break things, after all. Their job is much easier than yours as a software developer and often too easy because an organization did not invest the time to properly secure their systems.

Those script kiddies are often only the initial attackers. The more advanced attackers can do much worse once they get a foothold on your network. Sometimes the script kiddies sell their findings on the dark web to more dangerous attackers.

Your applications are the front door to those attacks. You want to make sure the code you use and write is not the source of these attacks. Copying and pasting random code off the web like a script kiddie is asking for trouble!

The first step to writing more secure code is to learn how to engineer solid code. Anyone can learn to program if they are interested. I learned how to program from a book when I was 12. That’s not hard. Learning some syntax and making things “work” is not software engineering.

To become a software engineer, I continued reading about software programming (and now security) from that day on and never stopped. I went on to learn Microsoft Access, Visual Basic, and later picked up a book on object-oriented programming. That’s when I realized the impact of software design on the quality of an application.

If you want to further advance your knowledge you can get a software engineering degree. I did that as well — basically to prove I knew how to program, or so I thought. When I went to get my degree I learned about things like proper relational database structures, design patterns, algorithms, Big-O Notation (which I am still to this day not absolutely sold on), and discrete math. In a good software engineering program you are usually not simply learning to write code. You learn how to design and architect systems and manage software projects.

Read books by software architects and programmers on software design and engineering, not just books that show you how to write code in a particular language. As you read more and more books on the topic you start to understand what is and is not good software when you see it. Here are some of the books I’ve read that may help you become a better programmer and software engineer. Some may be older but will give you context and history as well as a basis for the engineering designs and architectures that exist today.

These books may be best digested in paperback form due to the diagrams and code samples they contain. Note that you do not need to program in the particular language the book is about to understand the concepts. They apply to any language. The same topics may exist in other languages if you prefer, but these are books I can recommend because I read them.

A great book on becoming a better programmer:

A classic on design patterns:

A friendly version on design patterns with lots of pictures:

Classic on algorithms such as linked lists.

These are just a few of the books I’ve explored to further my understanding of good software architecture and design. When I started architecting a cloud solution for a security vendor, I read numerous books, websites, and watched YouTube videos on newer technology options for our design. For example, Sam Newton’s book on Building Microservices is excellent.

However, I always combine my exploration of the latest technology to fully understand it with tried and true software engineering principles. In addition, I leverage knowledge of how attackers break into systems to reduce the risk of an attack— something I’ll address later.

Next Steps?

• Delve into the principles of solid software engineering by studying information on the topic.
• Don’t just copy and paste code. Understand what it is doing first.
• Incorporate the principles of solid software engineering into your work.
• Practice reviewing and reverse-engineering other people’s code.
• Exercise your skills: If your organization uses Java, have you searched your codebase for other source that uses JNDI similar to the log4j library? Do you understand why it exists and what sort of harm it may be able to cause?

Follow for updates.

Teri Radichel | © 2nd Sight Lab 2021

About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
⭐️ Author: Cybersecurity Books
⭐️ Presentations: Presentations by Teri Radichel
⭐️ Recognition: SANS Award, AWS Security Hero, IANS Faculty
⭐️ Certifications: SANS ~ GSE 240
⭐️ Education: BA Business, Master of Software Engineering, Master of Infosec
⭐️ Company: Penetration Tests, Assessments, Phone Consulting ~ 2nd Sight Lab

Need Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for Presentation

Follow for more stories like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
❤️ Sign Up my Medium Email List
❤️ Twitter: @teriradichel
❤️ LinkedIn: https://www.linkedin.com/in/teriradichel
❤️ Mastodon: @teriradichel@infosec.exchange
❤️ Facebook: 2nd Sight Lab
❤️ YouTube: @2ndsightlab