Clean code, easy to develop code, … Does the programmer know about safe code ??? (Part 1)

Tram Ho

Opening text

Surely the students, when studying programming subjects in school, have heard more or less about the concept of Clean Code – Clean code : the way of naming variables, function names; how to code so that it is easy to read and understand.

=> Avoid other people reading your code do not understand anything. Worse, reread my old code 3 months ago, “Whoever code the A # [email protected] * & what?” – Oh, it turned out to be my code “.

When we graduate, we will be familiar with object-oriented languages ​​(our school teaches Java OOP), then we have to practice more ways that Code is easy to develop and upgrade . It is shown through the division of the function; usage of inheritance, implements; public, private, protected, static, …

But more often than not we will not, or less know , Secure Code – Secure coding . Security code is the set of rules to avoid creating security holes that can be exploited by bad guys. Lots of dangerous security holes can be easily prevented if we know how to code safely.

If on the business side, when the code is secure, they can save a lot of costs from the problems caused by attackers exploiting vulnerabilities on the web, on mobile applications, and on products. technology products that the company is using.

=> Secure coding is very important, right.

Introducing Secure coding CTF

Secure coding CTF is a contest organized by The National Cybersecurity Student Association . The competition took the form of finding vulnerabilities in websites, focusing mainly on programming languages: PHP , Java and Python . For each lesson, contestants will be provided with the necessary source code files to search for vulnerabilities and exploit them.

The contest took place at https://ctf.vford.com/ and at the time of writing this article, the contest website is still active.

The contest is divided into 4 weeks with a total of 20 exams. The tests are only easy – average, the content of knowledge about Information Security is not too much, so even programmers who do not know much about Information Security can understand and do it. .

In this article, I will gather articles in the form of vulnerabilities first, then articles with specific vulnerabilities, and finally the articles that are less related to vulnerabilities in reality. Those who want to see write up of their own articles can Ctrl + F find the article title to read.

Now it’s the write up of Secure coding CTF

1. Disclosure of important information and functions

This vulnerability occurs because programmers carelessly reveal important information in code, and have not turned off debugging functions when the service is officially running. When an attacker technically reads a part of the source code, finds important information and functions, he or she can use this information to attack, sabotage or steal data.

1.1. Revealing debug functionality in the official release

Information:

In the carefully commented code, we need to notice the code from lines 26-35:

Accordingly, the author of the code says that when entering param /?debug_cmd_now_you_see_me= with the command ls or cat , the server will execute and return the results to us.

For example, when we want to see the result of ls command, we will add param ?debug_cmd_now_you_see_me=ls

Once you have a list of files, just read flag11.txt file. To do the same as above, to execute the cat command we pass the param ?debug_cmd_now_you_see_me=cat flag11.txt

Failure to disable the debug functionality prior to the release of the official release can lead to an attack on the website through these functions. If in the above case, the programmer designing the debug function can execute arbitrary system commands, the attacker can use his technique to hijack the server. Even if these commands are executed by a user with high authority, it is no different that we are giving away the server to them.

Even if the debug functions are very well hidden, located at a path that is extremely hard to find, there is no 100% guarantee that no one will find it. We need to consider the worst case to come up with a solution.

So, before releasing the official version, we need to double check the source code and make sure all debugging functions have been removed / disabled .

1.2. Reveal important log files

Information:

Lines 41 – 43 define 3 accessible paths and how the server behaves when a user accesses the path as follows:

At first glance, we can easily see that / is the path for the index page, while /login/ is the path for the login page, and /auth.log is quite strange because of the .log extension.

The .log files can contain some important information during the system’s operation. And usually when a file is provided like this, when we access it, we can read it or download it, in case it is blocked, 403 will be returned.

To be sure what happens when accessing the /auth.log path, we can check out the LogHandler class below:

So clear, when accessing the /auth.log path, the server will not check for permissions, but will read the auth.log file and return the results for us. After accessing, I found a username / password pair, beatrix / do-you-want-to-build-a-hack-land?

And using this username / password pair, we can successfully /login/ at /login/ and get the flag.

Log files often contain a lot of important information of the system, some common important log files are: access.log , error.log , mysql.log , … Not just .log files. Come on, files .txt , .md , text files, … can also contain system logs.

Any file, which only contains important information or can assist an attacker in exploiting security vulnerabilities on our website, should be kept strictly confidential, out of reach of hackers. bad.

Therefore, it is important to perform regular checks to see if any files containing important data have been exposed or not. This can check in source code, or view access history for important files. If so, remove and troubleshoot measures should be taken as soon as possible.

1.3. Expose Git log

Information:

The code from lines 52 – 68 shows how the server behaves when passing in the git param:

The code shows 2 ways of passing the param:

  • Pass the git param with the value log: /?git=log
    => Returns history git commit
  • Pass git param with the value checkout, and param hash with the value of the commit hash: /?git=checkout&hash={commit-hash-id}
    => Returns the content of the committed file

When passing param /?git=log , we have the entire commit history with nearest-farthest order. After looking backwards, we can see immediately a special commit with the message “Add password and username in challenge”

Now we will copy the hash id to see what this commit is about using param /?git=checkout&hash=c1dce57829668b82678d4868ec58917fa37cfeab . Easily find username and password in code.

Using this username / password pair, we can login and get the flag.

Git commit log is one of the very important types of logs, when exposed, it can greatly aid an attacker by recording the entire process of changing and upgrading our source code.

As in this article, initially the programmer attaches the username and password to the code. After that, it was immediately removed and moved to a separate file. However, when removed, the programmer still does not change the username and password. So when exposing git log, the attacker can use that username / password to log in normally.

Therefore, it is absolutely forbidden to reveal git log.

2. Save files with insecure ID

This vulnerability occurs when programmers want to shorten paths to files, and users who have access to any file only send the user IDs of those files. The purpose is to limit access, but the programmer does not make permissions for the file.

So, when we know the rule for ID tagging, we can access any file we want.

2.1. Use incremental IDs

Information:

  • Week 1
  • Posts: Real ID 1
  • Programming language: PHP
  • Source Code: Yes, but not required

In this article we do not need the source code to do just look at the web interface. And here is a web interface, there is only 1 table with file name and access information. Any file that is accessible will appear in purple and have the word “YES” next to it. Any file that cannot be accessed will have white text.

Clicking on the purple files will redirect to another link and the file will be downloaded. Of course the flag.txt file we need cannot be clicked.

Now we use the function Inspect Element (Ctrl + Shift + C on Chome, Edge) up and point at the file names to check the links that we will be navigated to.

When we further examined the paths of some other files, it was easy to see that the files were sorted by increasing ID. So the flag.txt file will have an ID in the range of 10 -> 23. We can try these IDs in turn, because it is likely that the server checks that there is no access, so the link is not attached. Direct access can still download the file.

Finally, we can get the flag.txt yes with id = 21 at http://insecure.vford.com:8008/files.php?id=21

2.2. Hash ID is not secure enough

Information:

  • Week: 4
  • Post: Real ID 2
  • Programming language: PHP
  • Source Code: Yes, but not required

The way to do this is similar to lesson Real ID 1. However, this time, the programmer has assigned ID for the file better. ID no longer uses ascending natural numbers, instead uses a 13-character code snippet of numbers and lowercase characters.

Look here, CTF players or those who know Information Security will immediately think of Hash. Specifically, they can guess the ID that was the result of the hash of the filename, the hash of the file’s contents, or the hash ID found in post Real ID 1 (?) by some sort of hash algorithm.

If you look up google, there is no hash algorithm that outputs 13 characters with the same format. It should be possible for the programmer to use a common hashing algorithm, then take the first 13 characters of the output as the ID.

At this point we can either see the hint, or we can guess, or try with the popular hashing algorithms. Result: the hash algorithm used was MD5 . Once we know it’s MD5, we keep trying to hash with the elements mentioned above. And of course not unexpectedly, this ID is the hash of the filename by MD5 and then takes the first 13 characters of the output .

Thus, the ID of the flag.txt file is 159df48875627 , access the link http://insecure.vford.com:8010/files.php?id=159df48875627 will download flag.txt to your device.

Actually, it’s not difficult to guess, right, if you have the patience and the time to try each one in turn, you can find the principle of creating ID. And a malicious attacker is impatient and has enough time to try it.

So when we need to assign IDs to files we can use strong hashing algorithms, hash with more unpredictable elements, use more salt when hash. And it is best to strictly decentralize the file access, so that even if you guess the ID, those who are not allowed cannot access.

I would like to end part 1 here. Through the article, we have seen the dangers of insecure code and some principles to avoid information disclosure vulnerabilities, insecure ID typing.

In part 2, I will present safe coding principles to avoid PHP Type Juggling, Hard Coded Credentials, Credentials handling of critical data, Using insecure random number generator. ..

Share the news now

Source : Viblo