Linux: Recovering files deleted using "rm -rf"

Removed python script file by accident. Following two methods worked for me in retrieving the file.

Trick 1:

This was posted on askubuntu.com

$grep -a -B 40 -A 80 'string_from_file' /dev/sda1 > save_here.txt

-A 100 save 80 lines after match
-B 40 save 40 lines before match
string_from_file at least one unique string you remembered from deleted file
save_here.txt    retrieved content is copied here

Trick 2:

$lsof | grep -i "/path/to/file"
progname 1234 user_name 44 8,1 43219876 432890 /path/to/file

$cp /proc/1234/fd/44 /restore/file/tothis/path

Retrieved files might have unnecessary data or few lines might be arranged in reverse order.

FinTech, Mobile Applications and Vulnerabilities

MOBILE APPLICATION VULNERABILITIES

Reverse Engineering: Applications published on Google Play or Apple App Store can be reverse engineered by malicious users and create similar applications. Companies can lose their intellectual property.

Insecure Data Storage: FinTech related applications save sensitive data like personally identifiable information (PII), card data (PCI), health information etc. Sensitive personal information saved on mobile should be encrypted.

SSL Pinning bypass: SSL Pinning will

One Time Password: OTP is used as second level of authentication.

OTP Spamming: OTP Spamming is requesting an API/URL which generates OTP by spoofing mobile number to victims phone number. If there is no proper validation, attacker can send many OTP SMS’s to victim phone

OTP Bypass:

-       Modifying checks: OTP validation can be bypassed by modifying checks in the request payload or URI parameters

-       Bypassing SS7

-       Malicious mobile apps sniffing OTP’s

WEB APPLICATION VULNERABILITIES

All OWASP Top 10 or SANS Top 25 Vulnerabilities will be applicable.

- Cross Site Scripting (XSS): If the input values from user is not validated it might lead to java script execution vulnerabilities which might lead to cookie theft, redirection to malicious websites, DDoS attacks on other sites etc..

- SQL Injection: Improper input validation might lead to SQL Injection.

Privilege Escalation: If the authorization is not enforced properly, one user can access other users data.

- Authentication bypass

            SQL Injection

            Session ID Guessing

            Cookie values

- Command Execution: Improper input validation might lead to OS command execution

- Serialization/Deserialization: Data interpreted as code because of improper validation. This might lead to code execution in Java, PHP, Python

- CSRF

- WAF Bypass

- Ratelimiting Issues

            Important API’s

            Forgot/Reset Password

            Login page

            Other important/sensitive API’s

- XXE (XML External Entity) Attack

- SSRF (Server Side Request Forgery)

- JSON Injection

- DoS/DDoS (Layer 3, Layer 4 and Layer 7 attacks)

AWS INFRA

- Public S3 buckets: Will have files

- Public EBS Volumes: Might have sensitive information like SSH Keys, Server Keys, passwords etc.

- No Multi Factor Authentication (MFA, 2FA) to AWS

- Root logins

- Token Disclosure

            Slack

            Git

MISCELLANEOUS       

Crypto Currency based exploitation in future

Sub-domain takeover

Vulnerabilities in protocols

-->

Vulnerabilities in Hardware

Vault7: Malware and Disk I/O (Input Output)

aa
Following were the guidelines given to Malware authors at CIA, how to deal with Disk I/O and steps taken to save data on to disk or deleting saved date from disk.

Directive	Rationale
DO explicitly document the "disk forensic footprint" that could be potentially created by various features of a binary/tool on a remote target.	Enables better operational risk assessments with knowledge of potential file system forensic artefacts.
DO NOT read, write and/or cache data to disk unnecessarily. Be cognizant of 3rd party code that may implicitly write/cache data to disk.	Lowers potential for forensic artefacts and potential signatures.
DO NOT write plain-text collection data to disk.	Raises difficulty of incident response and forensic analysis.
DO encrypt all data written to disk.	Disguises intent of file (collection, sensitive code, etc) and raises difficulty of forensic analysis and incident response.
DO utilize a secure erase when removing a file from disk that wipes at a minimum the file's filename, datetime stamps (create, modify and access) and its content. (Note: The definition of "secure erase" varies from filesystem to filesystem, but at least a single pass of zeros of the data should be performed. The emphasis here is on removing all filesystem artefacts that could be useful during forensic analysis)	Raises difficulty of incident response and forensic analysis.
DO NOT perform Disk I/O operations that will cause the system to become unresponsive to the user or alerting to a System Administrator.	Avoids unwanted attention from the user or system administrator to tool's existence and behavior.
DO NOT use a "magic header/footer" for encrypted files written to disk. All encrypted files should be completely opaque data files.	Avoids signature of custom file format's magic values.
DO NOT use hard-coded filenames or filepaths when writing files to disk. This must be configurable at deployment time by the operator.	Allows operator to choose the proper filename that fits with in the operational target.
DO have a configurable maximum size limit and/or output file count for writing encrypted output files.	Avoids situations where a collection task can get out of control and fills the target's disk; which will draw unwanted attention to the tool and/or the operation.

Vault7: Malware evasion and Reverse Engineering difficulty Comparison

This is basically Do's and Don'ts for a Malware author. Below table explains how a malware author can bypass different AntiVirus engines, by reversing the logic we can use similar concepts to detect the malware. Below pointers apply to PE files, Mach-O, ELF and other binaries.

Evasion	Rationale/Detection
DO obfuscate or encrypt all strings and configuration data that directly relate to tool functionality. Consideration should be made to also only de-obfuscating strings in-memory at the moment the data is needed. When a previously de-obfuscated value is no longer needed, it should be wiped from memory.	String data and/or configuration data is very useful to analysts and reverse-engineers.
DO NOT decrypt or de-obfuscate all string data or configuration data immediately upon execution.	Raises the difficulty for automated dynamic analysis of the binary to find sensitive data.
DO explicitly remove sensitive data (encryption keys, raw collection data, shellcode, uploaded modules, etc) from memory as soon as the data is no longer needed in plain-text form. DO NOT RELY ON THE OPERATING SYSTEM TO DO THIS UPON TERMINATION OF EXECUTION.	Raises the difficulty for incident response and forensics review.
DO utilize a deployment-time unique key for obfuscation/de-obfuscation of sensitive strings and configuration data.	Raises the difficulty of analysis of multiple deployments of the same tool.
DO strip all debug symbol information, manifests(MSVC artefact), build paths, developer usernames from the final build of a binary.	Raises the difficulty for analysis and reverse-engineering, and removes artefacts used for attribution/origination.
DO strip all debugging output (e.g. calls to printf(), OutputDebugString(), etc) from the final build of a tool.	Raises the difficulty for analysis and reverse-engineering.
DO NOT explicitly import/call functions that is not consistent with a tool's overt functionality (i.e. WriteProcessMemory, VirtualAlloc, CreateRemoteThread, etc - for binary that is supposed to be a notepad replacement).	Lowers potential scrutiny of binary and slightly raises the difficulty for static analysis and reverse-engineering.
DO NOT export sensitive function names; if having exports are required for the binary, utilize an ordinal or a benign function name.	Raises the difficulty for analysis and reverse-engineering.
DO NOT generate crash dump files, core dump files, "Blue" screens, Dr Watson or other dialog pop-ups and/or other artefacts in the event of a program crash. DO attempt to force a program crash during unit testing in order to properly verify this.	Avoids suspicion by the end user and system admins, and raises the difficulty for incident response and reverse-engineering.
DO NOT perform operations that will cause the target computer to be unresponsive to the user (e.g. CPU spikes, screen flashes, screen "freezing", etc).	Avoids unwanted attention from the user or system administrator to tool's existence and behaviour.
DO make all reasonable efforts to minimize binary file size for all binaries that will be uploaded to a remote target (without the use of packers or compression). Ideal binary file sizes should be under 150KB for a fully featured tool.	Shortens overall "time on air" not only to get the tool on target, but to time to execute functionality and clean-up.
DO provide a means to completely "uninstall"/"remove" implants, function hooks, injected threads, dropped files, registry keys, services, forked processes, etc whenever possible. Explicitly document (even if the documentation is  "There is no uninstall for this ") the procedures, permissions required and side effects of removal.	Avoids unwanted data left on target. Also, proper documentation allows operators to make better operational risk assessment and fully understand the implications of using a tool or specific feature of a tool.
DO NOT leave dates/times such as compile timestamps, linker timestamps, build times, access times, etc. that correlate to general US core working hours (i.e. 8am-6pm Eastern time)	Avoids direct correlation to origination in the United States.
DO NOT leave data in a binary file that demonstrates CIA, USG, or its witting partner companies involvement in the creation or use of the binary/tool.	Attribution of binary/tool/etc by an adversary can cause irreversible impacts to past, present and future USG operations and equities.
DO NOT have data that contains CIA and USG cover terms, compartments, operation code names  or other CIA and USG specific terminology in the binary.	Attribution of binary/tool/etc by an adversary can cause irreversible impacts to past, present and future USG operations and equities.
DO NOT have "dirty words" in the binary.	Dirty words, such as hacker terms, may cause unwarranted scrutiny of the binary file in question.

CIA - Central Intelligence Agency
USG - United States Government