Nytro

[h=1]CP/M Source Code Released[/h] October 6, 2014 By Adam Fabio Leave a Comment To celebrate the 40th anniversary of CP/M, the Computer History Museum has released a package containing early source code for several versions of CP/M. Originally designed by [Gary Kildall] in 1973, Control Program for Microcomputers (CP/M) is an early operating system for microprocessor based computers. The OS was originally written for the Intel Intellec 8, an Intel 8008 based computer. Since it was on an Intel machine, CP/M was written in PL/M (Programming Language for Microcomputers), a language [Kildall] had previously developed for Intel . CP/M pioneered the idea of a ROM based Basic Input Output/System (BIOS) for commonly used routines on a given computer. The use of BIOS made CP/M easy to port. Eventually it was ported to thousands of different machines and architectures, including the Altair, IMSAI 8080, C-64, and C-128 and Apple II systems. Gary and his company Digital Research, were one of the top contenders for the operating system on IBM’s new personal computer. Ultimately, Microsoft got the job by purchasing 86-DOS from Seattle Computer Products. Somewhat ironically, 86-DOS itself was written based on the CP/M Application Programming interface (API). The source itself is an amazing trip back in time. Included are portions of CP/M 1.1, 1.3, 1.4, and 2.0. Portions of CP/M have been released previously. As with the previous files, this version includes modifications performed by z80-pack author [udo Munk] in 2007. Version 1.3 is especially interesting as it is primarily scanned copies of the CP/M source code. If you’re into vintage computing, and know how important CP/M was to the early days of personal computers, check out the CP/M source. If you find any interesting or clever bits of code, be sure let us know about it in the comments. [image Source: CulturaInformatica] Sursa: CP/M Source Code Released

On the Ethics of BadUSB Oct 3rd, 2014 Last Friday, Brandon Wilson and I gave a talk on BadUSB at DerbyCon - I wrote some about it yesterday. Yesterday, Wired published an article on the talk, kicking off several others - only the authors of the Wired and Threatpost articles contacted us for input. There has been some questions raised as to the responsibility of releasing the code - so I want to take a few minutes to talk about what we released, why, and what the risks actually are. What we released. We released a two patches to the existing (v1.03.53) firmware for the Phison 2251-03, and a minimal custom firmware for that same chip. The Patches First, let me briefly describe the patches: Hidden Partition - A patch to create a second hidden partition, to show that data can be hidden, and not easily accessed unless you know the trick. Password Bypass - A patch to modify the password protection mechanism to force the password to fixed value; so that any password will be accepted. Must be applied before the password is set by the user. The second patch does defeat a “security” mechanism on the device, though given that the patch must be applied before the password is set - it’s not a huge risk to users. We intentionally focused on changing behavior instead of adding composite devices, to show that the is more complex than what was displayed at the Black Hat talk. So we’ve bypassed one security feature, and added a new feature. The patches were carefully selected to make the point, while not endangering users. The Custom Firmware The custom firmware acts a HID device, typing out a pre-programmed payload when inserted to a computer. This is anything but new - this can be done with a USB Rubber Ducky, a Teensy, or a number of other devices. This was released to prove the point that the device could be reprogrammed to be something completely different. If this is a new threat to anyone - they are very out of the loop. The Tools We also released a few tools that we developed to apply patches and to make our lives easier during the effort. Most of what they do is available in other tools from Phison or the device manufactures; we built the tools we needed, so we didn’t have to use third-party tools or deal with the limitations of those tools. What we DIDN’T release Now that we’ve talked about what was released, let’s talk about what it isn’t. Self replication - There’s no self replication code anywhere, while it’s possible that it could be done, and we’ve talked about how to do it - it won’t be released. I am confident that we (Brandon and I) could build a system that would infect PCs, then infect a significant percentage of thumb drives, and then infect other PCs - but, and this is a big but - what we released doesn’t make that easier in any significant way. Your average script kiddy will never be able to do it; there’s only a small number of people that would be able to do the work needed to be able to pull it off - those people could already do it before we released what we did. The threat of this happening is the same as it has always been. Malware - There’s nothing malicious about what we’ve released here. While we did release a patch to modify the password protection feature - that’s all it does. It doesn’t modify data, infect computers with anything, or anything of that nature. It changes the way a feature works. That’s it. This is a change that anyone with the required skills could have made - by making it public, we are raising awareness that users shouldn’t blindly trust. The end of USB as we know it - Nothing, nothing, that we’ve released has suddenly made new attacks possible. The USB specification allows composite devices to do unexpected things. USB devices (thumb drives or otherwise) that allow anyone to update the firmware without any checks, means that anything can potentially be reprogrammed to change functionality or become malicious. All of these things have been true long before we released the first line of code. Anyone that believes otherwise doesn’t understand the technology. An unfixable issue that will end the world - While there isn’t quick fix for this, things can be improved quite a bit. We released simple code, that proves the issue, draws attention to the fact that users need to be more careful, while being careful to not cause more harm than good in the process. This isn’t earth shattering. Anyone that thinks that it is, should probably give up and go live in a cave. The Risks What are the real risks here - what does this expose users to that it didn’t in the past? Writing code for these devices is far from easy, especially when trying to patch the existing firmware. It’s not something that just anyone can jump into - while we have made it easier for people to apply simple patches and provided some insight to the process, these aren’t the patches that will lead to a firmware based worm or something of that nature - these are the type of patches that will make small changes to existing features, or add simple new features. Even then, it’s time consuming and difficult work. So, to do anything still requires a lot of knowledge and skill - in general, as I said earlier, the kind of people that have what it takes to do this, could do it regardless of our release. If a person (or group) was so inclined to take one of these devices and make it truly malicious - it’s unlikely that our research would have an impact. I firmly believe that by releasing this code, the risk to the average user isn’t increased at all over what it already was. Why release? Device manufactures were quick to dismiss the “BadUSB” threat - on one hand, what was presented at Black Hat was possible via other means, so wasn’t really a new threat - but they showed no indication of trying to address the issues under their control. For years devices have been sold with updatable firmware, but with no security checks at all - we had two goals with the release of the code: User awareness - As long as users implicitly trust devices, attacks will be possible and successful. Push device manufactures to implement signed updates. While it will take years for any changes made by device manufactures to have an impact because of the number of devices in circulation now - if they keep ignoring the issue, then it will never be improved. In doing this, we haven’t broken the security of these devices, but made it clear that it isn’t existent. If anyone is upset that we’ve removed the obscurity that had “protected” these devices - then to them I’m sorry that they understand so little that they believe that it’s real protection. Part of the reason we released the “hidden partition” patch was to show that this can be used to add new features, that can add value in certain cases. The Full Disclosure debate When we started on this, we were concerned that this was being touted as a new threat, yet for defenders there was no way they could even test it, much less develop defense techniques. So not only do we have something that defenders can’t test, we have something that the device manufactures are downplaying or ignoring. This is the setup for the classic full disclosure debate. The first question that we asked ourselves, before we wrote the first line of code, is what is best for users? To allow the status quo to continue, or to expand the research into new directions and publish - to help make users aware and provide defenders something to work with. The answer we came up with, is that we could develop patches that would clearly communicate the issue, without causing undue harm to end users. In the end, looking at what we intended to release, what could be done that wouldn’t have been possible before that (which is fairly minimal), and the potential benefit - we felt, and still do, that full disclosure was appropriate. In everything we’ve done, the priority has been protecting users - any media report that indicates otherwise is ill-informed, and providing bad information to the public. Breaking out of the echo chamber Given that the issue was so well known, the amount of attention - positive and negative - that this has received has really surprised us. It’s too common that when something like this is released it stays within the infosec echo chamber - this has broken out far more than I expected. Most of the negative feedback has been from people and organizations that are well outside of the echo chamber - reminding me of just how ignorant the public can be when it comes to technical issues. There are times that I wonder why we work so hard to protect these people. Has this been blown out of proportion? Yes. Posted by Adam Caudill Oct 3rd, 2014 Sursa: https://adamcaudill.com/2014/10/03/on-the-ethics-of-badusb/

ATM hacking easily with RM100 chip and a free malware by Pierluigi Paganini on October 6th, 2014 Cybercrime expert explains anyone with technical knowledge, a malware and the help of an insider could easily hack an ATM machine. A RM100 chip, specific technical knowledge and a free malware obtained over the Internet is all the necessary to hack Automated Teller Machines (ATMs), this is the opinion of a cybercrime expert, which released an exclusive interview to the FMT (freemalaysiatoday.com). The cybercrime expert was invited to report in regard to a recent hacking case of 17 ATMs, a Latin American gang of cyber criminals was able to hack and steal millions of dollars from the automated teller machines in Malaysia. The hackers steal more than $1.2 million from ATMs of at least 17 bank branches belonging to United Overseas Bank, Affin Bank, Al Rajhi Bank and Bank of Islam were reportedly hacked into by the Latin American gang. The Closed-circuit television (CCTV) footage from the banks showed that 2-3 Latin American men entered and withdraw money from these targeted ATM machines. “What you need is a mastermind, a RM100 computer chip and possibly a bank ‘insider’ to execute the attacks.” he said. The 17 ATM hacks must be a warning for the banking industry that according to the expert is loosing field in the fight against cybercrime. “Banks should look into their security seriously, and not just for the sake of compliance.”“This mentality has to be changed to build security in the DNA of the bank.” A little information is needed to the attacker, the knowledge of the targeted system could be enough to compromise a banking ATM, all this information typically provided by insiders. “He (the hacker) will know where the locks and connections are, the model of the machine, the level of security and the version of the operating system.” explained the expert. The expert also pointed out the roles of the guys captured by the surveillance cameras at the bank “The guys caught on the CCTV are not the actual criminals.” “It’s like the ‘monkey see, monkey do’ situation. They can be shown what is supposed to be done without the need for any technical knowledge. They probably do not even know what they are doing.” According to the expert, the hack of an ATM machine could be very easy using malware easy to find in the underground, a security expert has no problem to wreak havoc on the actual banking system. “It is a simple attack as there are many free malware available online. And it is definitely something that the bank has to seriously think about.” Based on his experience in the sector, the expert highlighted the wrong approach of the banking industry in the protection of ATMs machines, in many cases these machines run out dates OSs, lack of patch management or they are poorly configured. The expert is very controversial with financial institutions, he explicitly refers to the results of a series of penetration tests conducted against banking systems that succeeded to breach the “The bank I worked for was not happy that we breached the system after doing a hacking” he said. “It’s either they wanted to ensure that we couldn’t find anything, or, they will hire incompetent people who will not find anything.” The results of the penetration testing session demonstrate the presence of several weaknesses in the banking systems, in many cases the ATMs were running on outdated operating systems like Windows XP. “Banks have been taking things for granted because nothing like this has ever happened before.” the expert added.“They depended heavily on the CCTV and in some locations, they do not even have security guards. The experts involved in the test also discovered many other serious flaws in the ATM, lack of encryption could expose sensitive data to tampering advantaging the hack of these machines with a malware based attack. “It is also because of the lack of encryption technology such as the Public Key Infrastructure (PKI). “If the PKI was implemented, it wouldn’t have happened.” he added Pierluigi Paganini Sursa: ATM hacking easily with RM100 chip and a free malware | Security Affairs

I recently discovered the existence of Firechat when I heard that it was being used by thousands of protester during the ongoing "Umbrella Revolution" in Hong Kong. Firechat is said to be a messaging app which, unlike whatsapp wechat or TextSecure, can communicate from one device to another directly, without using any existing Internet connection. Wireless has so much more to offer than just being a bridge to the Internet, especially right now where it is being more and more monitored. Wireless mesh networks offer an exiting alternative: a wild, disruptive and uncontrollable network. I love mesh network so I really wanted to know more about the Firechat app. Firechat hands on Firechat is developped by a start-up company called OpenGarden. This is not the first ad-hoc application they developed since they already provided an app called Open Garden enabling wireless multi-hop connectivity to the Internet. Firechat is their last and most widely used product and is actually being used in Hong Kong. So let's try it ! Sadly, Firechat is not Free Software and is not Open Source neither so the only way to download it was either from the GooglePlay (which I don't have) or to download the apk from a third party (which I don't recommand for obvious security reason). For the purpose of the test, I installed the APK and ran the application. Second disapointment, a registration is necessary to start chatting around and it requires an Internet connection. As shown on the three pictures above, it asks for the "Real Name" "Full Name" [ndlr: FIX 06-10], a surname and an email address. The good thing is that there is no email verification mechanism so you can just enter bullshit information and it is going to work. All the communication in Firechat are public so it is strongly advised to enter false information anyway. Third disapointment, an error message appears each time I load the main window to warn me that I don't have the Google Play Services which indeed I stripped from CyanogenMod (I try to be tracker-free and to only use free software). Despite of the warning, the application still runs and the interface is then very simple, your chatroom list is divided into three parts: Everybody/Nearby: chat with people nearby, either from Internet based location (Everybody mode) or from bluetooth-based physical connectivity (nearby mode) Joined rooms: the room you joined and for which you are participating Firechats: a list with all the room You can picture Firechat as an IRC server, you have a lot of peopled connected to it and you can create and join as many room as you want. Each time you join a new room, it will be added into your "Joined" set. I don't know if it is due to the absence of Google Play Service, but I didn't find a way to search for room which is very inconvenient since there are thousands of different rooms and only ten are being shown on the "Firechats" list. Hence, the normal mode of communication of Firechat requires Internet. Every room are in fact hosted on the Firechat server and need an Internet connection to communicate with. The Nearby room however is the exception as it is dedicated for real physical colocation based on the bluetooth and the WiFi devices. I was a bit confused as how the Everyone chatroom worked. Like the Nearby room, it allows to communicate with people around you but at a much larger scale. Based on your IP address, it will connect you with the users from the same country as you which is inconvenient because if you use a VPN (like me) Firechat will connect you with the users whom their IPs are in the same country than the outer end of the tunnel. Let's get our hand dirty and see how it works from a network point of view Firechat Nearby communication Bluetooth Obviously, the Nearby room is the most interesting since it involves an original mean of communication called "adhoc networks". Nearby communication requires that either or both WiFi and Bluetooth interface to be turned on. Firechat does not enable the bluetooth interface automatically so it need to be manually turned on and set visible to every device (by default it is only visible to paired device). This can be done in the setting like the two following image : Once Bluetooth is activated, Firechat will create two RFCOMM bluetooth channel. From my Laptop, I use the awesome blucat tool to scan and interact with the channels (like netcat but for bluetooth): [root@archlinux:~] [sam. oct. 04 07:49:20] $ hciconfig hci0 up [root@archlinux:~] [sam. oct. 04 07:49:20] $ blucat devices Searching for devices +,3C8BFE5CD657, "nameless", Trusted:false, Encrypted:false Found 1 device(s) [root@archlinux:~] [sam. oct. 04 07:49:46] $ blucat services 3C8BFE5CD677 Listing all services +,3C8BFE5CD677, "nameless", Trusted:false, Encrypted:false -,"Headset Gateway", "", btspp://3C8BFE5CD677:2 -,"Handsfree Gateway", "", btspp://3C8BFE5CD677:3 -,"AV Remote Control Target", "", btl2cap://3C8BFE5CD677:0017 -,"Advanced Audio", "", btl2cap://3C8BFE5CD677:0019 -,"", "", btl2cap://3C8BFE5CD677:0017 -,"Android Network Access Point", "", btl2cap://3C8BFE5CD677:000f -,"MAP SMS/MMS", "", btgoep://3C8BFE5CD677:4 -,"MAP EMAIL", "", btgoep://3C8BFE5CD677:5 -,"OBEX Phonebook Access Server", "", btgoep://3C8BFE5CD677:19 -,"OBEX Object Push", "", btgoep://3C8BFE5CD677:12 -,"", "", btspp://3C8BFE5CD677:15 -,"FireChat", "", btspp://3C8BFE5CD677: 6 most of the channels are quiet standard Android channels except for the last two which have been created by Firechat. I tried to connect to the last one called Firechat on bluetooth port 6 but I was not able to get any response from the application so I believe this is only a "beacon" to advertise the presence of a FireChat user to the neighborhood or maybe it is used to create multi-hop route I don't really know. The second channel on bluetooth port 15 is more interesting because this is were the communication takes place. So let's first connect to it using the following blucat command blucat -url and see what happens when I send a message to the Nearby room from the Firchat application (in order to make a distinction between send and receive message, i append the [received] and [send] tags): [root@archlinux:~] [sam. oct. 04 07:50:58] $ blucat -url btspp://3C8BFE5CD677:15 [received] {"t":246039.375,"uuid":"!'AX.]!F!+:KIGJO","user":"plopinou","msg":"Lorem ipsum","firechat":"Nearby","name":"plop"} As we can see from above, first the Android phone interactively asks for the user to accept the pairing, once it is done, every message sent from the Firechat app will be sent over the bluetooth channel on port 15 to every paired devices. So when I sent the "Lorem Ipsum" message from the Firechat app, I received a string on blucat which we recognize to be a JSON format to describe the data which are : t: timestamp in seconds uuid: a unique identifier for the message (probably an armored hash) user name: real name full name [ndlr: fix 06-10] of the user msg: the message to be sent to the room Firechat: the name of the chatroom name: the surname Most interestingly, it is pretty easy to communicate with Firechat Nearby room from a Linux computer using blucat by sending a JSON formatted string. Let's send the following string in blucat and see what happens : $ blucat -url btspp://3C8BFE5CD677:15 [...] [sent] {"t":246040.0,"uuid":"123456","user":"teletrollix","msg":"trololo","firechat":"Nearby","name":"generalol"} From the screenshot, the Firechat app display the "trololo" message sent from the user "teletrollix" which goes by the name "generalol". I tried sending ridiculous long string and there doesn't seem to have any limit to the size of the string we can send. A funny thing is that every message sent from the application to a room will be forwarded by bluetooth as well. So don't except the room to be private because even if you are only two in it, every message you send to the room are forwarded to the bluetooth users. For instance if I create a room "hdhdusuwhwhsudusbshsiw" and send the message "plop" from the Firechat app, it will appear in the blucat log !! $ blucat -url btspp://3C8BFE5CD677:15 [...] [received] {"t":254533.78125,"uuid":"=G95udh9s}#uhE","user":"plopinou","msg":"Plop","firechat":"hdhdusuwhwhsudusbshsiw","name":"plop"} N ow what happens, if I send a message using blucat to a random channel, will it get forwarded by the application to Internet to every user ? Well, even though the message does appear in the room from the Firechat App, it is not forwarded to the Internet. Take another example, from the Firechat app, I will send the "Hey Joe" message and will then send from Linux using blucat the message "IMPOSSIBRU" to the room "Everyone": $ blucat -url btspp://3C8BFE5CD677:15 [...] [received] {"t":246494.15625,"uuid":"zn4!Q#4S~#X5,-mQ","user":"plopinou","msg":"Hey joe","firechat":"Everyone","name":"plop"} [sent] {"t":246500.0,"uuid":"jhzfjff","user":"teletrollix","msg":"IMPOSSIBRU","firechat":"Everyone","name":"generalol"} From the previous image we understand the following things: Firechat app does not forward message received by Internet to the bluetooth. Blucat did get the Hey Joe message but didn't get Chun Lam's message "Hi" message sent by bluetooth to a random chatroom does appear in the firechat app (the IMPOSSIBRU message) is it forwarded to the internet users ? To be sure I used Wireshark to try to understand how does Firechat app communicate to its server that's where I discovered two interesting things. Firechat Server Using wireshark and filtering on the IP of my Android phone, I was able to determine that Firechat is sending message to two different IPs: 239.192.0.0 209.237.236.194 From the first IP, I understand that Firechat is also looking to create bond between WiFi device. It periodically sends UDP packet to the multicast address 239.192.0.0 and will also forward message just as it does with bluetooth. So not only every message sent are forwarded by bluetooth, they are also forwarded by WiFi ! This is actually quiet clever if we take into assumption that every message have to be public but I find it hard to swallow that they ask to provide a Real Name Full Name [ndlr: fix 06-10] given how it is wildly broadcasted and easy to intercept. Let's keep going, the second IP is actually the Firechat server and message are sent through an SSL connection to the port 4176. And now comes the big surprise that is, if I simply connect to this IP using OpenSSL, then plenty of messages starts raining : [nameless@archlinux:~] [sam. oct. 04 08:48:06] % openssl s_client -host 209.237.236.194 -port 4176 CONNECTED(00000004) depth=0 C = US, ST = California, L = San Francisco, O = "Open Garden, Inc", CN = firechat.opengarden.com verify error:num=18:self signed certificate verify return:1 depth=0 C = US, ST = California, L = San Francisco, O = "Open Garden, Inc", CN = firechat.opengarden.com verify return:1 [... Open SSL Connexion Log message ...]] {"firechat":"Everyone","t":33.188826,"name":"Dhiraj Chainani","user":"themagicalteddy","msg":"this is cool","uuid":"K@)&:6p3]t%xW#{p","loc":"Singapore","st":1412402798} {"t":247027.21875,"name":"plop","uuid":"*y7H[:hScJ43&X>d","user":"plopinou","msg":"It is","firechat":"Everyone","loc":"Singapore","st":1412402856} {"t":72723.0703125,"name":"Lance Wong","uuid":"[Q$|p6fwHJ<:(bE=,"user":"lancey","msg":"hello","firechat":"Everyone","loc":"Singapore","st":1412402869} {"loc":"Woodlands","firechat":"Everyone","t":488.515361,"name":"Eugene","user":"cybercat","msg":"Wat make u cool","uuid":"a7!^x_Nvn<(1,Md;","st":1412402888} {"t":247153.59375,"name":"plop","uuid":">BC.y4iS.poVSa,S","user":"plopinou","msg":"It just is","firechat":"Everyone","loc":"Singapore","st":1412402982} {"t":247672.375,"name":"plop","uuid":"v:t{qA|@Y}Gn? <+","user":"plopinou","msg":"LOREM IPSUM","firechat":"Everyone","loc":"Singapore","st":1412403501} {"t":248317.859375,"name":"plop","uuid":".qdWMiU%^IA,G}~u","user":"plopinou","msg":"Anybody ?","firechat":"Everyone","loc":"Singapore","st":1412404146} {"t":4886.49169921875,"name":"MeeSiamMaiHum","uuid":"[Y$S ?-yW(b-g1gL","user":"maihum","msg":":-)","firechat":"Everyone","loc":"Singapore","st":1412404580} {"name":"Lim Chee Aun","t":101.390309,"uuid":"y%VV+CJl5*b<","msg":"Test","firechat":"Everyone","user":"cheeaun","loc":"Singapore","st":1412404734} {"name":"Valerie","t":25.014198,"uuid":"'DYJkO9s.{}ax}","msg":"ðððð","firechat":"Everyone","user":"lerie86","loc":"Singapore","st":1412404860} As we can see from the image Above : Every message we sent to the room "Everyone" is easily intercepted by just connecting to the server with OpenSSL message sent by bluetooth to the "Everyone" room to a Firechat app are not Forwarded to the Internet (see how the message from generalol are not received on the SSL). Both my Android phone and my Laptop are connected to the Internet using my broadband modem. If now I configure both of them to use my VPN in order to get to the Internet from France, we then receive message from French people: [nameless@archlinux:~] [sam. oct. 04 08:48:06] % openssl s_client -host 209.237.236.194 -port 4176 [... Open SSL Connexion Log message ...]] {"firechat":"Everyone","t":2329.514754,"name":"Jbmdb","user":"jbmdb13","msg":"Tu as instagram ?","uuid":"q$){>5=xx_f0)oK%","loc":"Martigues","st":1412404607} {"loc":"Saint-Paulien","firechat":"Everyone","t":514.790329,"name":"Morgane","user":"morgane17","msg":"Non dsl","uuid":"u+Fo32Txr%n,5bB{","st":1412404634} {"name":"Bastian","t":493.515672,"uuid":"bzk&jZEmZR($","msg":"Slt tlm","firechat":"Everyone","user":"bastain37","loc":"Amboise","st":1412404770} {"firechat":"Everyone","t":2493.639984,"name":"Jbmdb","user":"jbmdb13","msg":"Ouki ni snap je pari ?","uuid":"Q>2nQxbGNW`KF@n","loc":"Martigues","st":1412404771} Conclusion Wireless device such as bluetooth or WiFi have so much more to offer than just providing a mobility area to the Internet. It is good news to see application like FireChat popularising this exciting communication paradigm. However in the current state FireChat suffer from several flows that makes it unsuitable for an event like "Umbrella Revolution". First the application is closed source and its internal mechanism are pretty difficult to understand at first. It is hard to fully comprehend wether a message goes public or stay locally. The lack of information regarding this matter makes it irresponsable to ask users to fill in their full name before using the application. During the study, we stressed that not only every message sent are broadcasted locally (both Bluetooth and Wifi) regardless of the room, but we also show how easy it was to intercept and send information from/to Firechat users. Given the political context of the Umbrella Revolution, I would advise people to stop using Firechat or at least try to avoid leaking any information that could link to their real identity. Sursa: firechat and nearby communication

Translated from: El blog de Nutrix | RSAhack RSAhack Posted by Cristian on 05/09/201411/09/2014 Amicelli As we all know, is one of the RSA asymmetric algorithms (Public and Private Key) used and best known in recent decades. It was created by Rivest, Shamir and Adleman in 1977, The safety of this algorithm lies in the problem of factoring integers. RSA algorithm The algorithm consists basically of three steps: Key Generation Based on two distinct prime numbers, to which they are known as "p and q", which are chosen randomly. Taking primes n is calculated, which is basically the product of "pq" which makes "n" (semiprime) in the module. Now once the module having the Euler function ? (n) = (p-1) (q-1) is used, and having this calculation proceeds to choose a public exponent which is known as "e" this has two particular be less than ? (n) and is also coprime of this, usually 65 537 is used. A number that is called "d" using modular arithmetic, where "d" must be the inverse modular multiplier "e" is then determined. Then we have that: The public key is made up of "n" and "e" and the private key is composed of "n", "d", "p", "q" and these modules. encryption Using the public key (nye) A message "c" is created (Encryption) c ? m (clear message) ^ e (mod n) decryption Using the private key (n, d, p, q) is obtained from c m m ? c (encrypted message) ^ d (mod n) attacks As we saw above seems complicated operation, although there are many complicated known attacks that can be performed partially. Cyclic Encryption: Be decrypted using the same key figure is the public key, by an attack that uses only data from the victim that are public. The problem is that we present ourselves then anyone who knows the keys used in the process of figure or key exchange, could theoretically recover the secret. Dual EC DRBG: It is a generator cryptographically secure pseudo-random numbers, which was developed by the National Security Agency (NSA) and later adopted by RSA Security in your kit Bsafe which adopted double elliptic curve. However, this Backdoor was discovered in 2007, and was detailed by security expert Bruce Schneier. Birthday Paradox Most interesting of all is that for the attack only need to have the public key values ??of the victim factoring: In number theory, integer factorization or prime factorization is to decompose a composite number (not prime) in non-trivial divisors, which when multiplied give the original number. In this type of attack is try to factor n into p and q, and (p-1) (q-1) calculated by allowing you to determine d and e. Where are RSA As previously mentioned this algorithm is well known and is not implemented in a number of places. OpenSSL GnuPG PGP OpenVPN ETC RSAhack In what is developing this tool basically abusing a flaw in the implementation of RSA in OpenSSL found in all versions, the attack is done by Brute Force is made. When OpenSSL generates an RSA key uses rsa_builtin_keygen function located within /crypto/rsa/rsa_gen.c static int rsa_builtin_keygen (RSA * rsa, int bits, bignum * E_value, BN_GENCB * cb) { Bignum * r0 = NULL, * r1 = NULL, * r2 = NULL, * r3 = NULL, * tmp; Bignum local_r0, local_d, local_p; Pr0 bignum *, * d, * p; int bitsp, bitsq, k = 1, n = 0; BN_CTX * ctx = NULL; BN_CTX_new ctx = (); if (ctx == NULL) goto err; BN_CTX_start (ctx); r0 = BN_CTX_get (ctx); r1 = BN_CTX_get (ctx); r2 = BN_CTX_get (ctx); r3 = BN_CTX_get (ctx); if (r3 == NULL) goto err; bitsp = (bits + 1) / 2; bitsq = bits-bitsp; / * We need the RSA components non-NULL * / if (! RSA-> n && ((RSA-> n = BN_new ()) == NULL)) goto err; if (! RSA-> d && ((RSA-> d = BN_new ()) == NULL)) goto err; if (! RSA-> e && ((RSA-> e = BN_new ()) == NULL)) goto err; if (! RSA-> p && ((RSA-> p = BN_new ()) == NULL)) goto err; if (RSA-> q && ((RSA-> q = BN_new ()) == NULL)!) goto err; if (RSA-> DMP1 && ((RSA-> BN_new DMP1 = ()) == NULL)!) goto err; if (RSA-> dmq1 && ((RSA-> BN_new dmq1 = ()) == NULL)!) goto err; if (RSA-> iqmp && ((RSA-> BN_new iqmp = ()) == NULL)!) goto err; BN_copy (RSA-> e, E_value); *********** In the portion of the code, we see that it has a bit and then divides by 2 the length of the key, this is done to determine the length of p and q, that is, for a 1024-bit key p and q will be prime numbers 512, 5 bits and 511.5 bits. What this means it helps ?, partly because the attack is that for a 1024-bit key numbers are 512 bits. Looking at other implementations in applications such as GnuPG have realized this and corrected the lines, so that the prime numbers are not the same length, which adds another layer of complexity. But however it is not all primes to perform Superpower we lack, if this becomes quite complicated but we have several options depending on the hardware you have, the better the quality of the task simpler calculation. But to start, we can use it and extract OpenSSL primes. I pass an example: genrsa -out key 1024 openssl This command generates an RSA key with OpenSSL 1024. openssl rsa key -in -text -out key2 This further allows us to pass the RSA key text which we get the following. Private-Key: (1024 bit) modulus: 00: c7: 76: 50: d1: 5f: d3: e1: fc: 31: 3f: 7d: e6: e0: 49: 28: 75: b6: 7e: 29: c3: 3a: 1d: ce: 46: 27: 1f: e5: 60: 9b: 2d: 26: 37: 75: 80: 94: 07: 7a: 05: 87: 45: 5d: d4: ad: 6f: ce: df: 26: 23: a1: 3d: 0f: 26: 92: 0a: from: 9b: 95: 07: 55: e8: 36: 4c: 92: bf: 99: 59: 22: 7a: a2: 22: 21: 82: 4b: 90: 06: 72: 4b: 46: c3: 3f: 32: b6: c8: 3a: b6: 3c: 2f: 7e: 3f: a2: 98: fc: 60: d7: 3b: aa: 35: 14: 13: 50: 68: 0a: 4c: 84: 71: 39: e4: 47: dd: dd: 7b: 86: 85: d3: f5: 0a: 86: 34: db: 47: b1: 00: 9d: 28: from: e2: 4d: ad publicExponent: 65537 (0x10001) privateExponent: 53: 69: 08: d6: e5: a9: e7: 60: dc: ff: 5e: 19: 04: 45: d3: a3: 96: 13: 20: 47: c1: af: e1: 28: b9: 07: bf: 96: 2c: 8e: 2e: e3: 16: 42: 14: a5: 23: c3: d8: 13: 8b: ef: 7a: 2f: bd: 64: d7: c0: 22: 97: 34: 14: bf: 11: c8: 91: 6b: 3a: cc: 13: f5: 51: 04: 34: 5a: 19: 8d: 3c: 3f: bd: a9: 5c: 98: 0d: bc: 56: f8: ea: 68: da: 1c: a9: a1: d0: 05: 83: 97: e9: 29: 41: 09: 5a: 8a: 9d: 03: be: 39: 5c: 11: 44: 9e: 7f: ac: 48: d3: a1: 64: 40: b1: 5d: 8a: f9: c3: 7e: c5: e6: the 9th: 80: 8a: 00: 86: 52: 0d: 27: 73: 98: 51: 01 prime1: 00: ee: 80: 9d: af: ee: 43: e1: 41: f9: 23: 53: 39: 54: 89: 13: 43: 3d: ef: c2: db: d2: 87: the 9th: 3c: 2c: a1: d9: d4: 88: 12: 03: c6: 96: db: 2e: 3b: 52: b0: a7: 9e: 44: 0a: dc: 9c: 06: 57: e1: 50: 7b: 1d: 1d: b7: d1: 68: 00: 36: 09: 51: 7c: a3: 53: 3c: fd: a1 Prime2: 00: d6: 18: 79: 3a: bf: 95: 28: 13: 06: 03: 11: 72: b7: 8b: 9f: 2a: 5d: ec: 1e: 7b: 89: 0b: 88: dd: 67: 8e: 55: 0b: ac: af: 56: 9c: 09: 6f: 8d: 79: d1: b3: 24: 79: 5f: 82: d6: b4: 70: 6e: a3: 93: c8: af: d7: 4a: a1: c0: a6: d2: f4: 7f: cf: 72: 3d: 6d 1c: 8d exponent1: 4b: 99: cd: 62: 45: 1e: 93: 3a: bc: 64: 6c: 2f: 12: 12: d9: 5e: 49: 35: c5: 08: b5: 35: 72: b8: 7c: 55: 59: 9d: 3a: fc: aa: e1: ba: 54: 03: d5: 9e: 22: 8d: 1f: 67: e6: 21: 83: fb: a6: c3: af: 25: 37: 57: 82: 3b: 08: c2: 78: 5e: 7f: cc: 08: 61: 8c: 45: c1 exponent2: 7e: ad: 22: 65: d1: 5f: b6: c3: 72: c6: 33: f7: b5: 84: 66: 5b: d2: 10: d8: 84: 6d: b5: 26: 79: 22: 41: c4: 2e: 51: 31: b9: c4: 3f: 8d: 02: 9f: b6: a5: 11: 8a: c3: 29: 8e: 52: 5b: 48: 0b: 7f: 70: ba: 22: 5f: a5: 4f: 71: 25: d6: c7: 1c: fe: 52: 3c: 12: 2d coefficient: 00: d6: fa: 86: 0c: ff: 5f: 8c: 3d: db: 74: b2: bd: ac: 84: 1b: 86: 16: b6: 24: 98: 0b: 5b: e8: 89: 90: 38: e2: 7c: 96: ee: 3b: c1: 0e: bc: eb: 66: 64: 16: ca: e7: 6c: 85: 0a: 7b: f2: ee: e7: 4a: 39: 9c: 66: 77: fd: 34: 77: 66: b7: d1: 51: a8: 55: ca: 5f: f3 ----- BEGIN RSA PRIVATE KEY ----- MIICXAIBAAKBgQDHdlDRX9Ph / DE / febgSSh1tn4pwzodzkYnH + Vgmy0mN3WAlAd6 BYdFXdStb87fJiOhPQ8mkgrem5UHVeg2TJK / mVkieqIiIYJLkAZyS0bDPzK2yDq2 PC9 P6KY + / GDXO6o1FBNQaApMhHE55Efd3XuGhdP1CoY020exAJ0o3uJNrQIDAQAB AoGAU2kI1uWp52Dc / 14ZBEXTo5YTIEfBr + EouQe / liyOLuMWQhSlI8PYE4vvei + 9 ZNfAIpc0FL8RyJFrOswT9VEENFoZjTw / valcmA28VvjqaNocqaHQBYOX6SlBCVqK OVwRRJ5 NQO + / + cN + rEjToWRAsV2K xeaagIoAhlINJ3OYUQECQQDugJ2v7kPhQfkj UzlUiRNDPe / C29KHmjwsodnUiBIDxpbbLjtSsKeeRArcnAZX4VB7HR230WgANglR fKNTPP2hAkEA1hh5Or + VKBMGAxFyt4ufKl3sHnuJC4jdZ45VC6yvVpwJb4150bMk C1rRwbqOTyK eV + / XSqHAptL0f89yPW0cjQJAS5nNYkUekzq8ZGwvEhLZXkk1xQi1 NXK4fFVZnTr8quG6VAPVniKNH2fmIYP7psOvJTdXgjsIwnhef8wIYYxFwQJAfq0i ZdFftsNyxjP3tYRmW9IQ2IRttSZ5IkHELlExucQ / jQKftqURisMpjlJbSAt / cloi UjwSLQJBANb6hgz X6VPcSXWxxz + / X4w923SyvayEG4YWtiSYC1voiZA44nyW7jvB DrzrZmQWyudshQp78u7nSjmcZnf9NHdmt9FRqFXKX / M = ----- END RSA PRIVATE KEY ----- All we need is to extract the prime numbers that look and keep them in the same format as we see what is hexadecimal, this task can be automated so you can start playing with numbers Cousins ??Big Eye is not the only way, but if used for testing. After getting a good deal (many) primes we can start making Fuerza Bruta on a public key, and then to generate the private key. advice for driving large primes recommend using GMP Here's a video where you can see running RSAhak, in an attack on a public key of 1024 bits. video Demonstration I leave a simple module written in Python so that after the primes to generate RSA private key. You can download it from github. Later I'll post the full project RSAhack Cristian Amicelli Tagged as: Cryptography, Superpower, Python, RSA Categorized as: Cryptography 4 thoughts on "RSAhack" jorge kamlofsky says: 09/08/2014 at 13:29 Hello, Cristian. I am a mathematician: Discrete Mathematics teacher IAU. Hence I know Juan Manuel, who passed me your presentations. Excellent job! Congratulations! I will try to reproduce the attack in order to understand it better. Thanks and regards. JK Reply Cristian Amicelli says: 09/08/2014 at 17:45 Thank you Jorge, you have any questions, ideas or advice do not hesitate to perform them Reply NU11 says: 09/09/2014 at 18:24 SEAS primes not the same length == primes SEAN not the same length? Reply Cristian Amicelli says: 09/14/2014 at 19:21 Post navigation Pharming ? PHP and cURL View: Mobile | Classic Google Translate for Business:Translator ToolkitWebsite TranslatorGlobal Market Finder Sursa: OpenSSL RSA Hack: www.cristianamicelli.com.ar/blog/rsahack - Pastebin.com

Follow @DanDragomir 6 octombrie 2014 @ 11:33 Facebook Messenger va oferi posibilitatea de a transfera bani între prieteni, fiind de fapt un plan al Facebook de a deveni o afacere cu adev?rat profitabil?. De aceea a fost impus tuturor. Apropo, am descoperit c? dac? dezistalez aplica?ia de Facebook ?i o reinstalez iar, merge mesageria cum era înainte. S? vedem pentru cât timp. Codul legat de transfer de bani a fost descoperit de un student ?i publicat prima oar? de TechCrunch. Industria întreag? este tot mai interesat? s? aduc? pl??ile mobile pe telefonul mobil. Atât b?ncile ?i institu?iile financiare, cât ?i utilizatorii sunt interesa?i de asta, iar evident marile platforme care pot deveni intermediari vor avea de câ?tigat. A?a c? Facebook bate Google la interven?ii for?ate. Întâi au f?cut un studiu dubios pe spatele utilizatorilor, apoi au impus for?at Messenger cu un singur scop: s? câ?tige cât mai mul?i bani. Pentru a putea transmite ?i primi bani va trebui s? introduce?i în Facebook Messenger datele de card bancar. S? vede?i distrac?ie Sursa: https://www.computerblog.ro/business/adevarul-despre-facebook-messenger.html

C?t?lin Ni?u - 30 sep 2014 Întrucât reclamele de pe mobile nu aduc la fel de mul?i bani precum cele de pe desktop, Google pl?nuie?te s? î?i m?reasc? profiturile schimbând modul de afi?are al acestora. Asemeni ini?iativei iAds lansat? de Apple în urm? cu patru ani, noile reclame de pe Android vor beneficia de elemente multimedia care ocup? întregul ecran pentru a m?ri ?ansa de de interac?iune din partea utilizatorilor. Aparent planul este s? foloseasc? atât clipuri video de diverse dimensiuni, cât ?i mini-aplica?ii interactive. Acest gen de reclame nu este deloc nou, alte companii oferind astfel de solu?ii de mai mult? vreme în spa?iul mobil. Cum ini?iativa Apple a e?uat în mare parte, iar juc?torii de pe aceast? pia?? sunt prea mici pentru a putea acapara un procent prea mare din pia?a de publicitate online pe mobile, Google este singura companie care ar putea avea succes acum în acest spa?iu. Implementarea noilor reclame trebuie f?cut îns? într-un mod care s? nu deranjeze utilizatorii. Google pare s? condi?ioneze utilizarea lor doar în momente obi?nuite de „pauz?”. Un exemplu interesant ar putea fi integrarea unui clip video de 15-20 secunde între dou? niveluri dintr-un joc de genul Angry Birds. Interesant este faptul c? Google a decis s? foloseasc? astfel de reclame chiar dup? ce Apple a decis s? mai încerce odat? cu reclamele pe mobil, ini?iativ? confirmat? în urm? cu câteva luni. Sper?m doar ca aceste practici s? nu distrug? de tot ecosistemul de aplica?ii mobile, care este chiar ?i acum plin de reclame de tip banner ?i de micro-tranzac?ii mai mult sau mai pu?in justificate. Sursa: Reclame fullscreen în aplica?ii pentru Android de la Google ADSdroid.

Super, asta inteleg eu prin "hacking". E inutil, dar e for fun.

Nu acceptam "market" de la persoane care nu au 50 de posturi. Ban.

Ok, nu vine nimeni cu o captura de Wireshark? Cu un screenshot in care sa se vada un apel SetWindowHookEx sau GetAsyncKeyState? Adica o demonstratie. Dar ce zice acolo e mult mai mult decat un keylogger. Nu folositi asa ceva, dupa cum spun si ei, folositi doar pentru teste.

Poate cineva sa descarce si sa uploadeze in alta parte? E un jeg site-ul ala.

BadUSB the unpatchable malware code published on Github 0 By Vijay on October 3, 2014 · BadUSB : The unpatchable and unfixable USB malware Exactly two months after researcher Karsten Nohl demonstrated an attack he called BadUSB to a standing-room-only crowd at the Black Hat security conference in Las Vegas. The BadUSB was later demonstrated again by two researchers, Adam Caudill and Brandon Wilson. Caudill and Wilson presented the vulnerability at Derbycon 4.0 conference last week in Louisville. What is BadUSB? The malware which is dubbed BadUSB, reprograms embedded firmware to give USB devices new, covert and most powerful capabilities. In a demo at Black Hat security conference in Las Vegas, a USB drive was infected and showed its ability to act as a keyboard that surreptitiously types malicious commands into attached computers. Another USB was similarly be reprogrammed to act as a network card that causes connected computers to connect to malicious sites impersonating Google, Facebook or other trusted destinations. The demo showed that similar hacks could work against Android phones when attached to targeted computers. The malware is so huge that it can work on almost any USB linked devices like Web cams, keyboards, smart phones etc. BadUSB on Github Researchers Wilson and Caudill reversed-engineered USB firmware and reprogrammed it to launch various attacks. They then put the code for BadUSB on Github with a intent of letting all the users know abouts its effects. “The belief we have is that all of this should be public. It shouldn’t be held back. So we’re releasing everything we’ve got,” Caudill told the Derbycon audience on Friday. “This was largely inspired by the fact that [sR Labs] didn’t release their material. If you’re going to prove that there’s a flaw, you need to release the material so people can defend against it.” Caudill and Wilson discussed various scenarios where BadUSB can be used. Prominent among them and most deadliest is the USB device to emulate a keyboard and issue commands on behalf of a logged-in user to exfiltrate data or install malware. Unpatchable!!! BadUSB remains unpatchable at the moment. The reason according to the both the researchers, is that the USB controller chips in peripherals can be reprogrammed to spoof other devices and there’s little or no protection to prevent anyone from doing so. They also feel that since USBs are mass manufactured these days and it proves that anyone can input the code to insert the malware and take command of any system, perhaps the USB manufacturers will be under pressure to fix it soon. “If the only people who can do this are those with significant budgets, the manufacturers will never do anything about it,” Caudill told Wired. “You have to prove to the world that it’s practical, that anyone can do it…That puts pressure on the manufactures to fix the real issue.” The researchers also hope that putting teh code on Github would encourage companies and white hat researchers to find a fix for the malware. Sursa: BadUSB the unpatchable malware code published on Github

Poate tu muncesti pe 10 milioane. Lasa matura/lopata si pune mana si invata.

Nu mai are meniul ala de cacat "Metro", are butonu de start ca in imagine dar in rest nu am vazut diferente...

S-a facut. S-au gasit persoane care sa predea si s-au oferit o gramada ca participa, dar cand se preda, pula "studenti", intrau doar cativa plus alti cativa care erau "Idle". Nu meritati.

Da, de-asta am incercat si eu sa vad daca extrag toate tabelele, daca e limitat.

Ha? Si pe aia cu FinFisher de ce nu ii aresteaza? Sa le dau la muie.

user() == sqli2@localhost ? Nota: Iti pot extrage tabelele.

More Mac OS X and iPhone sandbox escapes and kernel bugs Posted by Ian Beer A couple of weeks ago Apple released OS X 10.9.5 and iOS 8 which fixed a number of sandbox escapes and privilege escalation bugs found by Project Zero. All-bar-one of these bugs were found via manual source code auditing where there was source and binary analysis where there wasn’t. As always, click through the bugs for proof-of-concept code and further details: CVE-2014-4403* [ https://code.google.com/p/google-security-research/issues/detail?id=23 ] was as issue allowing a kernel ASLR bypass on OS X due to insufficient randomization of very early kernel heap allocations, the addresses of which could be leaked using the unprivileged SGDT instruction. This bug could be exploited from within any sandbox on OS X and allowed an attacker to determine the load address of the kernel. CVE-2014-4394* [ https://code.google.com/p/google-security-research/issues/detail?id=28 ] CVE-2014-4395* [ https://code.google.com/p/google-security-research/issues/detail?id=29 ] CVE-2014-4401* [ https://code.google.com/p/google-security-research/issues/detail?id=30 ] CVE-2014-4396* [ https://code.google.com/p/google-security-research/issues/detail?id=30 ] CVE-2014-4397* [ https://code.google.com/p/google-security-research/issues/detail?id=30 ] CVE-2014-4400* [ https://code.google.com/p/google-security-research/issues/detail?id=30 ] CVE-2014-4399* [ https://code.google.com/p/google-security-research/issues/detail?id=30 ] CVE-2014-4398* [ https://code.google.com/p/google-security-research/issues/detail?id=32 ] CVE-2014-4416* [ https://code.google.com/p/google-security-research/issues/detail?id=34 ] were all bounds-checking bugs in the driver for the Intel integrated HD GPU present on all current-generation Macs. Eight of these bugs allowed controlled kernel memory corruption from with most sandboxes on OS X (those with access to the GPU such as the Safari renderer process or the Chrome GPU process.) CVE-2014-4402* [ https://code.google.com/p/google-security-research/issues/detail?id=33 ] was another case of missing bounds checks, this time in another part of the graphics acceleration pipeline. CVE-2014-4376* [ https://code.google.com/p/google-security-research/issues/detail?id=31 ] was a kernel NULL-pointer dereference when setting up IOKit shared memory. This was exploitable from within some sandboxed 32-bit processes on OS X (for example the Chrome GPU process.) As is true with all these bugs this bug also allows any unsandboxed processes to execute code in the kernel. CVE-2014-4418 [ https://code.google.com/p/google-security-research/issues/detail?id=36 ] No CVE* [ https://code.google.com/p/google-security-research/issues/detail?id=35 ] were bugs affecting OS X and iOS in the implementation of the IOKit IODataQueue class where the kernel trusted index and size fields in shared memory which was mapped into userspace and writable. Looking at the release notes for iOS 8 these bugs seem to be very similar to one used in the recent Pangu Team jailbreak which was released a few days after these bugs were reported to Apple. CVE-2014-4389 [ https://code.google.com/p/google-security-research/issues/detail?id=39 ] were integer overflows in the bounds checking code of IODataQueue allowing kernel memory corruption on iOS and OS X. CVE-2014-4390 [ https://code.google.com/p/google-security-research/issues/detail?id=37 ] was another shared memory queuing bug, this time in the bluetooth stack. CVE-2014-4404+ [ https://code.google.com/p/google-security-research/issues/detail?id=40 ] was an interesting kernel heap overflow when parsing a binary keyboard map which affected iOS and OS X and was reachable by setting an IOKit registry value. See the linked bug for more details along with a PoC demonstrating kernel instruction pointer control. CVE-2014-4379 [ https://code.google.com/p/google-security-research/issues/detail?id=42 ] was another bug in the keyboard mapping code affecting iOS and OS X allowing userspace to read arbitrary kernel memory. CVE-2014-4405+ [ https://code.google.com/p/google-security-research/issues/detail?id=41 ] was a kernel NULL pointer dereference due to incorrect error handling in the key map parsing code, again see the linked bug for a PoC demonstrating kernel instruction pointer control on OS X. Finding and eliminating sandbox escapes is an important focus for Project Zero. The attack surface to break out of a sandbox is often smaller than the attack surface available to remote attackers to gain an initial foothold inside a sandbox. Therefore, strengthening sandboxes represents a solid return on investment of time. Our research seems to indicate that sandbox break-outs on OS X and iOS are an under-researched topic. We’d encourage others to join us in bringing these sandboxes up to strength. You can keep up-to-date with the latest Project Zero research by subscribing to labels in our bug tracker: https://code.google.com/p/google-security-research/issues/subscriptions These bugs exceeded Project Zero’s standard 90-day disclosure deadline. (+) These bugs were only fixed on iOS and remain unpatched on OS X. Sursa: Project Zero: More Mac OS X and iPhone sandbox escapes and kernel bugs

October 01, 2014 Bash bug: the other two RCEs, or how we chipped away at the original fix (CVE-2014-6277 and '78) The patch that implements a prefix-based way to mitigate vulnerabilities in bash function exports has been out since last week and has been already picked up by most Linux vendors (plus by Apple). So, here's a quick overview of the key developments along the way, including two really interesting things: proof-of-concept test cases for two serious, previously non-public RCE bugs tracked as CVE-2014-6277 and CVE-2014-6278. NOTE: If you or your distro maintainers have already deployed Florian's patch, there is no reason for alarm - you are almost certainly not vulnerable to attacks. If you do not have this patch, and instead relied only on the original CVE-2014-6271 fix, you probably need to act now. See this entry for a convenient test case and other tips. Still here? Good. If you need a refresher, the basic principles of the underlying function export functionality, and the impact of the original bash bug (CVE-2014-6271), are discussed in this blog post. If you have read the earlier post, the original attack disclosed by Stephane Chazelas should be very easy to understand: HTTP_COOKIE='() { 0; }; echo hi mom;' bash -c : In essence, the internal parser invoked by bash to process the specially encoded function definitions passed around in environmental variables had a small problem: it continued parsing the code past the end of the function definition itself - and at that point, flat out executing whatever instructions it came across, just as it would do in a normal bash script. Given that the value of certain environmental variables can be controlled by remote attackers in quite a few common settings, this opened up a good chunk of the Internet to attacks. The original vulnerability was reported privately and kept under embargo for roughly two weeks to develop a fairly conservative fix that modified the parser to bail out in a timely manner and do not parse any trailing commands. As soon as the embargo was lifted, we all found out about the bug and scrambled to deploy fixes. At the same time, a good chunk of the security community reacted with surprise and disbelief that bash is keen to dispatch the contents of environmental variables to a fairly complex syntax parser - so we started poking around. Tavis was the quickest: he found that you can convince the parser to keep looking for a file name for output redirection past the boundary between the untrusted string accepted from the environment and the actual body of the program that bash is being asked to execute (CVE-2014-7169). His original test case can be simplified at: HTTP_COOKIE='() { function a a>\' bash -c echo This example would create an empty file named "echo", instead of executing the requested command. Tavis' finding meant that you would be at risk of remote code execution in situations where attacker-controlled environmental variables are mixed with sanitized, attacker-controlled command-line parameters passed to calls such as system() or popen(). For example, you'd be in trouble if you were doing this in a web app: system("echo '"+ sanitized_string_without_quotes + "' | /some/trusted/program"); ...because the attacker could convince bash to skip over the "echo" command and execute the command given in the second parameter, which happens to be a sanitized string (albeit probably with no ability to specify parameters). On the flip side, this is a fairly specific if not entirely exotic coding pattern - and contrary to some of the initial reports, the bug probably wasn't exploitable in a much more general way. Chet, the maintainer of bash, started working on a fix to close this specific parsing issue, and released it soon thereafter. On the same day, Todd Sabin and Florian Weimer have independently bumped into an off-by-one issue in the parser (CVE-2014-7186). The bug manifested in what seemed to be a non-exploitable crash, but was enough to cast even more doubt on the robustness of the underlying code. The test for this problem was pretty simple - you just needed a sequence of here-documents that overflowed a static array, say: HTTP_COOKIE='() { 0 <<a <<b <<c <<d <<e <<f <<g <<h <<i <<j <<k <<l <<m; }' bash -c : Florian also bumped into a similar issue with loop parsing (CVE-2014-7187); the proof-of-concept function definition for this is a trivial for loop nested 129 levels deep, but the effect can be only observed under memory access diagnostics tools. In any case, the practical impact of this finding wasn't particularly clear. Nevertheless, all these revelations prompted him to start working on an unofficial but far more comprehensive patch that would largely shield the parser from untrusted strings in normally encountered variables present in the environment. In parallel to Tavis' and Florian's work, I set up a very straightforward fuzzing job with american fuzzy lop. I seeded it with a rudimentary function definition: () { foo() { foo; }; >bar; } ...and simply let it run with a minimalistic wrapper that took the test case generated by the fuzzer, put it in a variable, and then called execve() to invoke bash. Although the fuzzer had no clue about the syntax of shell programs, it had the benefit of being able to identify and isolate interesting syntax based on coverage signals, deriving around 1,000 other distinctive test cases from the starting one while "instinctively" knowing not to mess with the essential "() {" prefix. For the first few hours, it kept hitting only the redirect issue originally reported by Todd and the file-creation issue discovered by Tavis - but soon thereafter, it spewed out a new crash illustrated by this snippet of code (CVE-2014-6277): HTTP_COOKIE='() { ) { _; }; ) { _; } <<a; }' bash -c : This proved to be a very straightforward use of uninitialized memory: it hit a code path in make_redirect() where one field in a newly-allocated REDIR struct - here_doc_eof - would not be set to any specific value, yet would be treated as a valid pointer later on (somewhere in copy_redirect()). Now, if bash is compiled with both --enable-bash-malloc and --enable-mem-scramble, the memory returned to make_redirect() by xmalloc() will be set to 0xdf, making the pointer always resolve to 0xdfdfdfdf, and thus rendering the bug harder to exploit (essentially depending on whether the stack or any other memory region can be grown by the attacker to overlap with this address). That said, on a good majority of Linux distros, these flags are disabled, and you can trivially get bash to dereference a pointer that is entirely within attacker's control: HTTP_COOKIE="() { ) { _; }; ) { _; } <<`perl -e '{print "A"x1000}'`; }" bash -c : bash[25662]: segfault at 41414141 ip 00190d96 sp bfbe6354 error 4 in libc-2.12.so[110000+191000] The actual fault happens because of an attempt to copy here_doc_eof to a newly-allocated buffer using a C macro that expands to the following code: strcpy(xmalloc(1 + strlen(redirect->here_doc_eof)), (redirect->here_doc_eof)) This appears to be exploitable in at least one way: if here_doc_eof is chosen by the attacker to point in the vicinity of the current stack pointer, the apparent contents of the string - and therefore its length - may change between stack-based calls to xmalloc() and strcpy() as a natural consequence of an attempt to pass parameters and create local variables. Such a mid-macro switch will result in an out-of-bounds write to the newly-allocated memory. A simple conceptual illustration of this attack vector would be: char* result; int len_alloced; main(int argc, char** argv) { /* The offset will be system- and compiler-specific */; char* ptr = &ptr - 9; result = strcpy (malloc(100 + (len_alloced = strlen(ptr))), ptr); printf("requested memory = %d\n" "copied text = %d\n", len_alloced + 1, strlen(result) + 1); } When compiled with the -O2 flag used for bash, on one test system, this produces: requested memory = 2 copied text = 28 Of course, the result will vary from system to system, but the general consequences of this should be fairly evident. The issue is also made worse by the fact that only relatively few distributions were building bash as a position-independent executable that could be fully protected by ASLR. (In addition to this vector, there is also a location in dispose_cmd.c that calls free() on the pointer under some circumstances, but I haven't really really spent a lot of time trying to develop a functioning exploit for the '77 bug for reasons that should be evident in the text that follows... well, just about now.) It has to be said that there is a bit less glamour to such a low-level issue that still requires you to go through some mental gymnastics to be exploited in a portable way. Luckily, the fuzzer kept going, and few hours later, isolated a test case that, after minimization, yielded this gem (CVE-2014-6278): HTTP_COOKIE='() { _; } >_[$($())] { echo hi mom; id; }' bash -c : I am... actually not entirely sure what happens here. A sequence of nested $... statements within a redirect appears to cause the parser to bail out without properly resetting its state, and puts it in the mood for executing whatever comes next. The test case works as-is with bash 4.2 and 4.3, but not with more ancient releases; this is probably related to changes introduced few years ago in bash 4.2 patch level 12 (xparse_dolparen()), but I have not investigated if earlier versions are patently not vulnerable or simply require different syntax. The CVE-2014-6278 payload allows straightforward "put-your-commands-here" remote code execution on systems that are protected only with the original patch - something that we were worried about for a while, and what prompted us to ask people to update again over the past few days. Well, that's it. I kept the technical details of the last two findings embargoed for a while to give people some time to incorporate Florian's patch and avoid the panic associated with the original bug - but at this point, given the scrutiny that the code is under, the ease of discovering the problems with off-the-shelf open-source tools, and the availability of adequate mitigations, the secrecy seems to have outlived its purpose. Any closing thoughts? Well, I'm not sure there's a particular lesson to be learnt from the entire story. There's perhaps one thing - it would probably have been helpful if the questionable nature of the original patch was spotted by any of the notified vendors during the two-week embargo period. That said, I wasn't privy to these conversations - and hindsight is always 20/20. Sursa: lcamtuf's blog: Bash bug: the other two RCEs, or how we chipped away at the original fix (CVE-2014-6277 and '78)

Inside The Atheros WiFi Chipset - Adrian Chadd The Qualcomm Atheros wireless chips have a variety of open source drivers available. Adrian will walk through the open Atheros HALs and ath9k-htc firmware, describing how things hold together and how to use them. Note - everything discussed will be based on what is the open source software and publicly available information. Bio: Adrian is the FreeBSD wireless maintainer and worked at Atheros for 18 months on chip bring-up and open source work. He worked with other Atheros developers to open source the USB firmware for the AR5513 and ath9k-htc hardware, as well as the AR9300 HAL. He also works on network parallelism and scaling in FreeBSD. His day job isn't anything to do with wifi. Via: Inside The Atheros WiFi Chipset - Adrian Chadd (Defcon Wireless Village 2014) (Hacking Illustrated Series InfoSec Tutorial Videos)

SDR Tricks with HackRF - Michael Ossmann HackRF and some other Software Defined Radio platforms can be used in creative ways. I'll show methods, including a dirty trick or two, for using HackRF outside the advertised frequency range. I'll also show how the HackRF design lends itself to use as an oscilloscope or function generator suitable for many hardware hacking tasks. Bio: Michael Ossmann is a wireless security researcher who makes hardware for hackers. He founded Great Scott Gadgets in an effort to put exciting, new tools into the hands of innovative people. Via: SDR Tricks with HackRF - Michael Ossmann (Defcon Wireless Village 2014) (Hacking Illustrated Series InfoSec Tutorial Videos)

Hacking 802.11 Basics - textile Hacking 802.11 Basics - textile Bio: Some dude. Via: Hacking 802.11 Basics - textile (Defcon Wireless Village 2014) (Hacking Illustrated Series InfoSec Tutorial Videos)

802.11ac Evolution: Data rates and Beamforming - Eric Johnson This session will discuss what is new in 11ac Discuss how the new data rates are derived. Where does 1.3 Gbps come from? The latest 11ac standard introduced 11ac beamforming. What is beamforming at a basic level? The practicalities of how 11ac beamforming works. Why it is not about making pretty antenna patterns? How it is different than proprietary analog solutions that proceeded the standards solution? Bio: Eric Johnson is one of Aruba's radio subject matter experts. He holds a Bachelor's and Master's degree in Electrical Engineering (Electromagnetics) from Carleton University. He has contributed solely and with teams on a total of 7 patents. His career now spans 26 years of defining, designing, building, and selling high performance radio and antenna solutions. He has contributed to and driven solutions for; space and terrestrial based remote sensing solutions; antenna designs from 30 MHz to 60 GHz; and at Nortel as architect on cellular radios, basestations, and antennas. Eric joined the Aruba Networks team in 2011 as the Product Manager for outdoor radio solutions and most recently delivered the AP-270 outdoor 11ac Access Point solutions. Via: 802.11ac Evolution: Data rates and Beamforming - Eric Johnson (Defcon Wireless Village 2014) (Hacking Illustrated Series InfoSec Tutorial Videos)

Mobile Forensics and Its App Analysis - Dr. Charline Nixon This presentation will talk about different mobile forensic tools, its uses, pros and cons. I will also use attack tree and its forensic tools comparison. The discussion also include app analysis, vulnerabilities, and breaches of mobile phone analysis. Bio: Charline F. Nixon is currently an IT Faculty at Calhoun Community College where she is responsible for teaching computer forensics, cyber terrorism and ethical hacking courses. She is currently developing a new course focused on mobile device hacking and forensics. Her previous positions include, IT School Chair and IT Faculty Lead Instructor. She holds 2 PhD’s in Education and Management and 2 Masters in Business and Cyber Security and a Black Belt Six Sigma. Charline has previously spoken at BSides Memphis and is one of the co-organizers of BSides Huntsville. In addition she holds several IT certifications, including GCIA, CEH, CHFI, ECSA, MFE,MCT, MCP,CASP (+10 others). Via: Mobile Forensics and Its App Analysis - Dr. Charline Nixon (TakeDownCon Rocket City 2014) (Hacking Illustrated Series InfoSec Tutorial Videos)