Phith0n · 2015/10/08 to teach
0 x00 background
XDCTF2015 is a CTF that I think is very powerful. The difficulty of the topic is moderate, and there is no trouble, and it is successfully concluded.
CTF is always prone to trouble, sometimes from their own, such as one year XDCTF’s preliminary competition was halted for several hours due to a power outage in the school computer room. More trouble, of course, comes from “hackers”. Because CTF is a safety-related competition, it naturally attracts the attention of many security researchers. A “hacker” here is a person who, through various means, makes it impossible for other contestants to do their homework properly.
These players usually call themselves “poops.” Hey. Of course, I do not mean to condemn them, the game is the process of competing with others, through various means to prevent opponents from scoring, I think is also a kind of ability. However, as the organizer, we need to try our best to make all the competitors compete normally to ensure a certain level of fairness. So I wrote this document to record my approach to the competition.
0x01 Ensure the quality of the questions
This is the source of all defence.
The questions need to be of moderate difficulty. If too tricky, easy to let people give up, and revenge, give up the rest of the time is to give you mischief time. Also can’t be too idiotic, too idiotic topic was minute second, the rest of the time is also used to trick.
I know this question, I should do this, but there seems to be a hole, LET me think about how to get around it… After a period of hard work, the problem is done; Or maybe the question didn’t come up at the right time, and then saw writeUp.
Such a topic, will let everyone have a sense of achievement, learn something, grateful to the organizers. In this way, we can reduce a lot of trouble, one is that we don’t want to give the organizers any more trouble, the other is that we are very tired and have no time to think about other problems.
0x02 First defense — Code layer
Some permissions are limited, and defense is ok in the code.
Web2-100, for example, is an arbitrary user password modification vulnerability. After discovering the bug and successfully changing the password of the front desk administrator, contestants can log in and see the Flag. Flags are stored in user files, and xDsec-CMS normally allows itself to delete its own files. So, if the first student to do this problem gets flag and deletes the file, there will be no second one.
So I added a judgment to the deleted code:
If the user is an administrator, return false to disallow deletion. Add, delete, change and check four operations, delete, change to add this judgment. Of course, the hero can write a script, add 999999 false files, flag style are similar, no one knows which is the real flag, but also affect the next contestant to do the problem. So strictly speaking, “add” also need to add this judgment.
Another common tool used by the churn is “violent competition law”.
For example, a problem requires two steps: the first step is to change the user name XXX, and the second step is to trigger a second injection to get the injection result. So I write a script that takes 50 threads to change the user name to an unrelated name so that no other user can perform the second step properly. (The first step was corrected by others just after completion.) In this case, other contestants will generally think that their own operation method is wrong, which directly leads to the deviation of the direction of the problem. Even if the contestant discovers that someone is stirring the shit, they have to write the same script and run it in 100 threads to continue working on the problem.
I think such a BUG can be avoided when setting questions. In my example, we could have created a multi-user environment where different users could only use their own usernames, thus avoiding the above problems. Failing that, we should do what 12306 did to the ticketing industry with competitive scummers – use captcha. This makes competing scripts very difficult to write, and can generally be avoided.
0x03 Second Defense: Service Permission Layer
Aside from PWN, the WEB certainly involves some system services: WEB services, database services, caching services, and so on. Among them, Web services also involve middleware permissions and script permissions. Here I use Nginx + PHP as an example, database mysql as an example.
In many CTF preliminaries, the Web questions are “small”, so there are often multiple Web questions on one server. In this case, permissions are extremely important. If a match does not have permissions set, causing players to use an arbitrary file read vulnerability for one title, or a root injection +load_file directly reads the source files for all titles. As a result, a good CTF suddenly becomes a code audit contest.
So a sandbox environment is essential for this type of CTF. It can be a recent Docker, a “virtual host” from a few years ago, or just plain old Open_basedir. Something is better than nothing. Specific how to decorate the Linux box can read my article: www.leavesongs.com/PENETRATION… I will not repeat it. The suggestion is to put a topic in a separate virtual host.
In the same context, service permissions are also extremely important.
For example, if the topic is to hide the flag in the background administrator password location, then you can use the method described in 0x02, so as to guard against the stirring machine:
- The administrator cannot change the password
- Administrators cannot be deleted
- Cannot add an administrator
It’s a tragedy when you forget something. Then, might as well fundamentally solve this problem: directly remove the current database user for the administrator table “add”, “delete”, “change” permission. GRANT select ON db. Admin [email protected]. Of course, a more detailed authority plan can be formulated based on a case-by-case analysis.
In PWN, we have the same problem. We came across a problem that required the user to execute the command. After the contestant successfully completed the goal of executing the command, she wrote a loop kill to kill PWN’s own service, so that other teams could not continue to work on the problem. This is a tricky problem, because PWN forks the same process as PWN, so no matter how much you do, you can’t avoid the user killing the PWN process.
I can think of three solutions:
- Rename or delete executables such as kill, pkill, skill, etc
- Example Set the other permission of /usr/bin, /bin, and /usr/local/bin to 0
- Using selinux, set the Security context
Method 1 is the simplest, but probably ill-considered, given the number of Linux commands. Method 2 is harsh and may cause that normal operations cannot be performed. Method 3 should be the most suitable, but it is also the most troublesome to configure. This depends on individual ability and the complexity and importance of CTF.
0x04 Defense 3: File Permission Layer
If CTF involves file operations (read, upload, delete, modify, rename), you need to set file permissions properly.
First, you need to know exactly how much your topic allows you to do with files: read, modify, and getShell. Here is a piece of advice, CTF preliminary ichthyosaur mix, try not to allow players getshell. After Getshell, the churn has a million ways to stop your game from progressing.
But sometimes, the topic of the examination point is the file upload vulnerability, or any file operation vulnerability, without getshell how to verify whether the player meets the requirements? Here I take web2 as an example: the ultimate purpose of web2-400 is user getshell, which exploits an arbitrary file renaming vulnerability, renaming normal files to.php after getShell. In fact, the final test for this question is “did the contestant successfully rename the file to the.php suffix”.
So it’s actually possible not to allow players to actually getshell. Here’s what I did:
-
Only requests to index.php and th3r315adm1n.php files are sent to FastCGI as a whole:
This effectively ensures that no other PHP files can be executed. This step is mainly for server security.
-
For all other requests with a.php suffix, if the file exists, I consider the user successfully getshell. Rewrite the request into the flag text file, and the user gets flag:
Because of my environment, there are only two PHP files in the entire Web directory. If there is a third PHP file, it must be the user’s Webshell.
-
For all requests that start with flag- and end with. TXT, 403 is returned. This is in case anyone guessed the flag filename directly:
These three steps complete the configuration of a “getshell” vulnerability that simulates getshell but is not really getShell.
So, a file operation caused by getshell, other than to prevent the player really getshell, what else need to guard against?
Guard against the churn, of course. There are a thousand ways to make a game unplayable: delete/overwrite/rename a healthy file, mv a healthy file, or even “help” the host to change the flag, or fix a buggy file. It was also easy to deal with, I changed the permissions of all existing files (normal files) to 755 and owner to root:
So even if there is any file operation vulnerability, there is no permission to modify the normal file.
However, most CMS involve caches, upload directories, backup directories, and other directories that need to be written. If the CMS is also set to unwritable, the CMS will not work. For example, there is a static file download function in the background. I had to set the owner of CSS, JS, img etc to WWW to make the static directory writable.
Those familiar with Linux permissions should know that whether a file can be deleted depends on the permissions of the directory in which it resides. If I have write permission to his directory, I can delete it, even if the file doesn’t belong to me. Therefore, through the deletion function of the background, the stirring stick can “delete all the static files” on the website, directly affecting the experience of the contestants behind.
What about this situation? Linux files have some “hidden attributes” that can be viewed using lsattr and modified using chattr:
As shown above, this is the hidden permission for the JS directory file that I configured.
I have marked all existing JS files with an I (chattr + I *), which means that no modification (including deletion) is allowed on the file.
At this point we can try rm:
The root user can no longer delete flag files.
This effectively ensures the safety of the site’s files, and puddles can’t destroy the site’s structure and normal functions. Smart use of these systems with their own access control capabilities, you can effectively prevent puddles!
0x05 Defense # 4 — Fight revenge Social Scumbag
This kind stir excrement stick is the real “bad man”, does not benefit oneself at the expense of others, is directly to trouble. For example, after taking down Flag, they tell everyone about it through official QQ groups, IRC and other channels, directly destroying the gameplay and fairness of the game. And the guy who attacked the match server during the match. For this kind of person, I think there is nothing to say, the number of the number, the screen of the screen, try to make him unable to contact the contestants. At the same time, the server log to see more, abnormal state can be found in time. A real-time log viewing tool is recommended — ngxtop:
The source code and usage can be found on Github.
If the organizers maintain a good attitude, show respect and patience to the contestants, this kind of dog will not appear. At the end of the day, CTF is a fun and learning event, and both the organizers and participants can learn a lot from the competition. Maintain a good attitude to deal with problems, slowly accumulate experience, harvest will be great.
Writeup for XDCTF2015
- Writeup: t.cn/RyleXYm Password: imwg
- Web2 writeup:github.com/phith0n/XDC…