Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 04/22/16 in Posts

  1. Since @brutelogic and I have had a lot of fun bypassing filters, creating challenges and finding new XSS methods and payloads in the past we thought we should try our luck on Chrome’s Auditor. You can read about the results of our research here. The bypasses we found can be used in many cases but there might be some situations where you can’t use them, for example when there’s no closing script tag or with some special chars after the actual payload like > or ?. However, there are some uncommon ways you could try. No closing script tag: When there’s no closing script tag our bypasses won’t work. They need at least one ” somewhere after the payload and </script> anywhere on the page after our injection. But there’s still a way to defeat the filter. We just have to use HTML imports. They will also be important for an uncommon bypass I’ll explain later. Their syntax is very simple: <link rel = "import" href = "/path/to/file.html"> In href we can specify any link we want as long as it doesn’t violate SOP. CORS might help here. Any link except one to a local resource is usually blocked by Chrome’s auditor. However if we use our known bypass we used with script src we are able to include a data: url. Our new payload would be <link rel = "import" href = "data:text/html&comma;&lt;script&gt;alert(document.domain)&lt;&sol;script&gt; We have to use html entities, otherwise our payload is flagged. This is possible as we are inside an href attribute now. [test] Working without being flagged This actually works in the sites context and would alert the domain name. No user interaction or closing script tag required. Local html inclusion This also relies on our link tag, but this time we play by the rules of the auditor. As I mentioned earlier we are only allowed to include local resources. The content type isn’t really important as this would also work with X-Content-Type-Options: nosniff. This gives us an interesting bypass opportunity. When we have an upload feature on the website where we want to inject our payload we can use it to upload a file with html code in its source. For example a .gif file with the content GIF89a<script>alert(1)</script> More info about that here, here and here. Even imgur would accept such a file (even though it can’t be displayed). Here’s the proof: imgur accepts this as a valid gif file Now let’s include it. We do this with <link rel = "import" href = "test.gif"> And there we go. It works! [test] Working great (DOM view) Multiple reflections That’s a whole different class of bypasses than the ones we’ve seen before. It’s not working due to an unclosed quote or the fact that the auditor trusts local resources that are passed without parameters. It is possible because the auditor sees a request with some html tags that look harmless on their own, but can be malicious if they occur more than once. This is usually achieved with script tags. A simple example where this would work is this: <a href = "INJECTION">INJECTION</a> You see, our injection is reflected two times i the same line. All we have to do now is this: \">"</script><script>alert(document.domain)-"\ What did we do here? Let me explain: First we break out of the href with \”>. The \ is required as it will escape the ” later in the script context. After that we have another “. This is going to mark the end of our string. Then we have a simple closing script tag. This won’t be recognized as malicious by the auditor as we have no starting script tag before. Now we start our new script with an opening script tag and write our payload after it. We now have to get rid of everything what’s behind our payload, otherwise we’d get a syntax error. We simply do this with a -“\. The ” will mark a new string and the \ will escape the quote that’s left of our payload. This is really hard to describe, so better see for yourself how the payload looks in the end: Some art right here Again this will alert. [click] Unfortunately this isn’t a common case. When we have multiple reflections they are often separated with newlines and other tags like here: This one looks harder, but is in fact easy We can’t use the trick we just used here. Simply because we have a newline that’s separating our payloads. So what would be a post about filter bypasses without template strings? I can’t even imagine it. As we know they allow multi-line strings which is exactly what we need here. Unfortunately the auditor knows about them and won’t allow them when there’s any character between an opening script tag and a template string. So what can we do about it? It’s really easy: ">`;alert(1)</script><script>` That way there’s no character between our template string and the script tag and we can enclose everything that would produce a syntax error. To be honest that same payload would also work on the first example of a double injection. Even a ‘ instead of the template string would. But it was a great challenge to try it with double quotes and backslashes. Here is our payload in action: [click] The ` makes it work in a multiline scenario All this is possible due to the fact that the auditor searches for the same dangerous string in a the request and response body, trusts local resources, doesn’t consider multi-injections and is not really strict to avoid false positives, which is important for a browser with such a market share. I’m sure there are some other bypasses just waiting to be found. You can try everything I showed you earlier when using this link: https://poc.asdizzle.com/auditor-tests/?mode=plain&q=INJECTION There’s different modes you can try: plain inline event image double double2 multi Have fun testing and Bye SOURCE : https://blog.asdizzle.com
    3 points
  2. https://docs.google.com/uc?id=0Bw5jU-IDyXM5RkFGUG1lSmZoSE0 https://docs.google.com/uc?id=0Bw5jU-IDyXM5REdCSEJDVHl6X1U Have Funk!
    1 point
  3. 1) AntiVirusi si Firewall 2) cryptere 3) DOS IRC 4) Dosers 5) Downloaders 6) Keyloggers 7) Other 8) pass stealers 9) RATs 10) stealer Download : https://disk.yandex.com/public/?hash=/brZCYweZdji80E7W3NHUeJ%2B1/5ai0zPimQ%2BulVk4pU%3D Folositi sandbox!
    1 point
  4. Close enough. Uite la ce ma gandisem eu ca ar fi un raspuns complet: Se indenteaza putin codul: main(_) { _^448 && main(-~_); putchar(--_%64 ? 32 | -~7[__TIME__-_/8%8][">'txiZ^(~z?"-48] >> ";;;====~$::199"[_*2&8|_/64]/(_&2?1:8)%8&1 : 10); } Se introduc ceva variabile pentru a face codul putin mai readable: main(int i) { if(i^448) main(-~i); if(--i % 64) { char a = -~7[__TIME__-i/8%8][">'txiZ^(~z?"-48]; char b = a >> ";;;====~$::199"[i*2&8|i/64]/(i&2?1:8)%8; putchar(32 | (b & 1)); } else { putchar(10); // newline } } A se nota ca -~i == i + 1 deci avem: main(int i) { if(i != 448) main(i+1); i--; if(i % 64 == 0) { putchar('\n'); } else { char a = -~7[__TIME__-i/8%8][">'txiZ^(~z?"-48]; char b = a >> ";;;====~$::199"[i*2&8|i/64]/(i&2?1:8)%8; putchar(32 | (b & 1)); } } Acum, a se nota faptul ca a[ b ] e acelasi lucru ca si b[ a ], iar aplicand -~ == 1+ avem: main(int i) { if(i != 448) main(i+1); i--; if(i % 64 == 0) { putchar('\n'); } else { char a = (">'txiZ^(~z?"-48)[(__TIME__-i/8%8)[7]] + 1; char b = a >> ";;;====~$::199"[(i*2&8)|i/64]/(i&2?1:8)%8; putchar(32 | (b & 1)); } } Facand trecere de la recursivitate la un loop + incercand sa simplificam putin codul, obtinem: main() { int i; for(i=447; i>=0; i--) { if(i % 64 == 0) { putchar('\n'); } else { char t = __TIME__[7 - i/8%8]; char a = ">'txiZ^(~z?"[t - 48] + 1; int shift = ";;;====~$::199"[(i*2&8) | (i/64)]; if((i & 2) == 0) shift /= 8; shift = shift % 8; char b = a >> shift; putchar(32 | (b & 1)); } } } Asta va afisa cate un caracter per iteratie. Fiecare al 64-lea caracter va printa un new-line. Altfel, foloseste o pereche de valori dintr-un table pentru a-si da seama ce sa printeze si pune ori caracterul 32(space) sau caracterul 33 ( '!' ). Primul tabel ( ">'txiZ^(~z?" ) este un set de 10 bitmaps care descriu aparitia fiecarui caracter, iar cel de-al doilea tabel: ( ";;;====~$::199" ) selecteaza bit-ul necesar din bitmap. Al doilea tabel: int shift = ";;;====~$::199"[(i*2&8) | (i/64)]; i/64 -> este numarul linie (6-0) i&2&8 -> 8 daca i = 4, 5, 7 mod 8. if((i & 2) == 0) shift /= 8; shift = shift % 8 - linia de mai sus selecteaza ori "the high octal digit" (pentru i%8 = 0,1,4,5) sau "the low octal figit" (pentru i%8 = 2,3,6,7). Deci tabelul va arata cam asa: rand col val 6 6-7 0 6 4-5 0 6 2-3 5 6 0-1 7 5 6-7 1 5 4-5 7 5 2-3 5 5 0-1 7 4 6-7 1 4 4-5 7 4 2-3 5 4 0-1 7 3 6-7 1 3 4-5 6 3 2-3 5 3 0-1 7 2 6-7 2 2 4-5 7 2 2-3 3 2 0-1 7 1 6-7 2 1 4-5 7 1 2-3 3 1 0-1 7 0 6-7 4 0 4-5 4 0 2-3 3 0 0-1 7 Sau, intr-o forma mai tabulara: 00005577 11775577 11775577 11665577 22773377 22773377 44443377 A se observa ca s-a folosit null terminator pentru primele doua valori din tabel Primul tabel: __TIME__ este un macro special definit de preprocesor. Aceasta este folosita ca un constant string continand timpul la care preprocesorul a fost rulat, in forma: "HH:MM:SS". Mai pe romaneste, odata cu fiecare compilare, programul va arata ora exacta a compilarii. A se observa ca ora nu se schimba atunci cand dati Run. De sesizat faptul ca HH:MM:SS contine exact 8 caractere. De notat ca 0-9 in ASCII inseamna 48-57 iar semnul ":" are valoarea 58 in tabelul cu valori ASCII. Outputul contine 64 caractere / linie => 8 chars / caracter din __TIME__. 7 - i/8%8 este indexul lui __TIME__ care este de fapt outputul ( 7- este necesar pentru ca iteram valoarea lui i invers). Deci, t este ceea ce __TIME__ printeaza. a sfarsteste prin a fi egal cu una din urmatoarele valori binare, in functie de inputul t: 0 00111111 1 00101000 2 01110101 3 01111001 4 01101010 5 01011011 6 01011111 7 00101001 8 01111111 9 01111011 : 01000000 Din moment ce caracterele sunt 7-bit ASCII, cel mai mare bit va fi mereu clearuit => 7 va fi printat mereu ca blank. Deci, al doilea tabel va arata asa, dupa ce 7 = blank 000055 11 55 11 55 116655 22 33 22 33 444433 Deci, de exemplu, 4 = 01101010 (bits 1,3,5, si 6 set) care e printat astfel: ----!!-- !!--!!-- !!--!!-- !!!!!!-- ----!!-- ----!!-- ----!!-- Ca sa vedem ca am inteles cu adevarat codul, sa ajustam putin outputul folosind acest tabel: 00 11 55 11 55 66 22 33 22 33 44 Asta este encodat ca: "?;;?==? '::799\x07" In scop artistic, vom adauga 64 la cateva caractere (din moment ce doar ultimii 6 biti sunt folositi, asta nu va afecta ouputul); asta va rezulta in: "?{{?}}?gg::799G" ( de notat ca al 8-lea caracter nu este folosit -> deci practic putem sa il transformam in orice dorim).
    -1 points
  5. (moderat) Pentru detalii, dați-mi un PM!
    -1 points
×
×
  • Create New...