T06 · System Persistence
- Location
cron_setup.sh:7- Finding
Persistent Scheduled Execution Through User Crontab
- Content
View full analysis
/dev/null | grep -v "tender_analyzer"; echo "0 * * * * $SCRIPT_PATH >> $(pwd)/logs/cron.log 2>&1") | crontab - # 每2小时重点汇报 (crontab -l 2>/dev/null; echo "0 */2 * * * $SCRIPT_PATH --report >> $(pwd)/logs/report.log 2>&1") | crontab - ``` ### Technical Analysis The setup script directly modifies the invoking user's crontab and installs two jobs that execute `run.sh` every hour and every two hours. These jobs survive the initiating process and future login sessions, establishing cross-session persistence. Periodic execution is related to the declared monitoring functionality, and the README explicitly instructs users to run this setup script. However, persistent modification of the user's scheduler is not necessary for one-time tender analysis and exceeds the minimum privileges required for ordinary execution. The operation also occurs without confirmation, a preview of the exact changes, or an uninstall mechanism. The scheduled command points to files in the project directory. Any process or account capable of replacing or modifying `run.sh` or `tender_analyzer.py` can cause attacker-controlled code to execute automatically under the account that installed the cron jobs. If setup is performed by a privileged account, the scheduled execution inherits that account's privileges. ### Attack Path 1. The user follows the installation instructions and executes `cron_setup.sh`. 2. The script writes two persistent entries into the user's crontab. 3. The cron daemon subsequently invokes the project-controlled `run.sh` without further user approval. 4. A party that can alter the project directory, repository update, `run.sh`, or `tender_analyzer.py` can place arbitrary commands in the scheduled execution path. 5. At the next ...[truncated 678 chars]- Remediation
View remediation
