Introduction
The Padvish Bug hunting award program was announced publically on the first of Mordad 1997 and cash prizes will be awarded to researchers and enthusiasts of the security field, who succeed to find vulnerability holes in Padvish and report it.
In this document, some common terms of the security field that participants need to know about the bug award program and some common mistakes will be introduced.
Terms and definitions
Vulnerability |
This term means there is a weakness or bug in the software that lets an intruder exploit it. Non-computer allegory: assume a military castle that aims to stop attackers from intrusion. Now assume that one of the castle’s walls has a crack that lets the attackers cross it and enters the castle. If we assume castle is the software, this crack is equal to that “vulnerability” concept in the software. |
Exploit |
Exploiting means manipulation and seducing a “vulnerability” of software. Vulnerability is a potential scheme that enabled exploitation. Non-computer allegory: in the example of the military castle, when attackers cross the crack of the castle, we call it exploitation. |
RCE: Remote code execution |
A special kind of “vulnerability” in the software is known as “remote code execution”. This kind of vulnerability lets the attacker so to deceive a software – its goal is not to code execution- in a way that leads to executing the desired code. in this issue, it is very important that: First) the software does not mean to execute the code. For example, if the duty of software is to remotely receive an order and execute it (like remote desktop) and this software is used in its normal field of duties; this is not a vulnerability and as a result, it is not RCE either. Second) the execution was remotely executed. In this case, consider that being remote means the execution executed without the necessity of login or having other accesses. For instance: consider a web server that must search for a phrase and display its results. If an attacker can send some values to this web server that instead of searching it, execute it as a code, it will be an RCE vulnerability. Reverse example: an attacker accessed an admin password and executed its code by remote desktop. This is not RCE, because the attacker has logged in to the system and as a result, now he can access the system with the access level of the local admin user. Therefore, the however attacker is behind the system and remotely connected to the system, but the code that he executed is locally or with local access. Reverse example 2: the attacker sent backdoor malware to the client and convinced the client to execute it. The attacker will remotely control the system by using a backdoor. This example essentially does not show the vulnerability of the system and is some kind of social engineering. The software acted correctly, but the system client was misguided and has given the wrong answer to the software. Also, the backdoor is executed locally and with the aforementioned definitions, it is not remote access. Another important note: is in the Code execution definition itself. Pay attention that the code execution in the debate of vulnerability is about the place where the execution of the code is not expected. For instance, when you run an exe file, normally you expect it to be executed and this is not a vulnerability. But if opening a Word file leads to the execution of a code on your system, a very dangerous vulnerability is occurred, because it is not expected to encounter this problem by opening a simple word file. Similarly, if an attacker encourages a client in a way to execute an exe file, this will be included in the phishing and social engineering field and is not a technical bug. But it will be needed to train the client and apply restrictive policies (for instance preventing from emailing an exe or like that by some sites and software) |
LPE: Local privilege escalation |
There is a special type of “vulnerability” in software named “local privilege escalation”. Normally, this kind of vulnerability will be used when the attacker could access the system in some way and now want to escalate its access from client to admin. For example, an attacker could log in to the system in some way (for example stealing the client password) and now wants to change one of the system settings. For this, the attacker must have admin or root access. As a result, he uses an LPE exploit to change his limited and not admin user to admin user. Pay attention that in this scenario it is possible that the attacker is sitting behind the system, remotely controlling the system, or even sending a Trojan to the user and the user will unintentionally execute it. In all these cases, the access of the attacker considers local, because this attacker took complete control of the system (as a normal user) before. |
To know more and view real examples of all types of LPE and RCE vulnerabilities, you can search these works online and study topics and technical reports of other security researchers.
Also to become familiar with the main definition and scoring procedure of secure bugs, we recommended you study CVSS documents.
Checklist before sending the report to Padvish
Before reporting your bug to Padvish, please consider this item:
- Is your bug part of the bug-hunting program? Please study the text of the Padvish bug hunting award program. Pay attention that your bug must be relevant to Padvish itself. Just not diagnosing malware does not mean it is vulnerable and simply can change by changing signatures, as a result, it is not relevant to this program. Please study the following rule of thumb.
Rule of thumb for reporting the bug to Padvish:
When reporting your bug to Padvish, pay attention that the Padvish bug-hunting program is just relevant to detecting security bugs in Padvish. If you doubt that your bug has any relation with Padvish or not, read follow the rule of thumb:
“Is your bug applicable on a system without Padvish?
If your answer is yes, then the bug you found does not belong to Padvish and naturally will not be a part of the Padvish bug-hunting program. But you have to refer it to its proper place.
- Check the validity of your data– after checking the bug and in case of acceptance, it is necessary to contact you. So make sure to enter your personal information (name, email, etc.) correctly.
- Choose your exact title– the bug-hunting program has 4 specific titles mentioned in the relevant table (above). Exactly add that your report is presenting under which kind of these titles, when sending your reports.
- Using the last version of Padvish-if your bug has been explored before and fixed in the last version of Padvish, you will get no points. So, before sending the report, download the last version of Padvish and text your bug on it.
- Exactly specifies the product with vulnerability– please exactly add the under test Padvish version number (the version number is a for digit number such as 1.2.333.4444).
- Exact introduction of bug scenario– most of the sending bugs are without a simple text describing the subject which makes the reviewing process harder. If you do not have the patience to explain what you did, do not expect others to know what you mean. So every sending report must exactly explain the scenario that leads to bug reproduction, step by step.
- Sending necessary files by attachment– in most cases in addition to textual explanation, it is necessary to send your exploit files.
- Security of sending information– according to the importance of the issue to client security, please send the report only to the mentioned email address and send all attached files encoded.