Parrot Security 3.3 – Security GNU/Linux distribution designed with cloud pentesting and IoT security in mind

Security GNU/Linux distribution designed with cloud pentesting and IoT security in mind.It includes a full portable laboratory for security and digital forensics experts, but it also includes all you need to develop your own softwares or protect your privacy with anonymity and crypto tools.DetailsSecurityParrot Security includes a full arsenal of security oriented tools to perform penetration tests, security audits and more. With a Parrot usb drive in your pocket you will always be sure to have all you need with you.PrivacyParrot includes by default TOR, I2P, anonsurf, gpg, tccf, zulucrypt, veracrypt, truecrypt, luks and many other tecnologies designed to defend your privacy and your identity.DevelopmentIf you need a comfortable environment with updated frameworks and useful libraries already installed, Parrot will amaze you as it includes a full development-oriented environment with some powerful editors and IDEs pre-installed and many other tools installable from our repository. FeaturesSystem SpecsDebian GNU/Linux 9 (stretch)Custom hardened Linux 4.8 kernelRolling release updatesPowerful worldwide mirror serversHigh hardware compatibilityCommunity-driven developmentfree(libre) and open source projectSystem RequirementsCPU: at least 1Ghz dual core cpuARCH: 32bit, 64bit and ARMhfRAM: minimum 256Mb – 2048Mb suggestedGPU: No graphic acceleration requiredSTORAGE lite/core: 4GB / 8GBSTORAGE Full: 16GBBOOT: Legacy bios or UEFICloudCloud PentestingParrot Cloud is a special edition of our OS specifically designed for servers, it consists on a lightweight parrot system without graphic interfaces, wireless and forensic tools and any other tools that can be considered useless in a remote-controlled virtual environment.ConceptThe idea of Parrot Cloud is to have a VPS or a dedicated server with a special operating system full of useful security tools, neither relying all the dirty work to your local machine nor relying the security of your confidential data to a 3rd party provider. It can also be used to store private files (preferably encrypted), scan targets in the background and other stuff that you don’t need to do with your own machines, allowing you to go everywhere you want with just a Parrot live USB and to do great penetration tests without having confidential data physically with you. CryptographyParrot includes many cryptographic softwares which are extremely useful when it comes to protect your confidential data and defend your privacy.Parrot includes several cryptographic front-ends to work both with symmetric and asymmetric encryption, infact it natively supports volumes encryption with LUKS, TrueCrypt, VeraCrypt and the hidden TrueCrypt/VeraCrypt volumes with nested algorythms support.The whole system can be installed inside an encrypted partition to protect your computer in case of theft.Another swiss army knife of your privacy is GPG, the GNU Privacy Guard, an extremely powerful PGP software that lets you create a private/public pair of keys to apply digital signatures to your messages and to allow other people to send you encrypted messages that only your private key can decrypt, in can also handle multiple identities and subkeys, and its power resides in its ring of trust as PGP users can sign each other’s keys to make other people know if a digital identity is valid or not.Even our software repository is digitally signed by GPG, and the system automatically verifies if an update was altered or compromised and it refuses to upgrade or to install new software if our digital signature is not found or not valid.PrivacyYour privacy is the most valuable thing you have in your digital life and the whole Parrot Team is exaggeratedly paranoid when it comes to users privacy, infact our system doesn’t contain tracking systems, and it is hardened in deep to protect users from prying eyes.Parrot has developed and implemented several tricks and softwares to achieve this goal, and AnonSurf is one of the most important examples, it is a software designed to start TOR and hijack all the internet traffic made by the system through the TOR network, we have also modified the system to make it use DNS servers different from those offered by your internet provider.Parrot also includes torbrowser, torchat and other anonymous services, like I2P, a powerful alternative to TOR.ProgrammingThe main goal of an environment designed by hackers for hackers is the possibility to change it, adapt it, transform it and use it as a development platform to create new things, this is why Parrot comes out of the box with several tools for developers such as compilers, disassemblers, IDEs, comfortable editors and powerful frameworks.Parrot includes QTCreator as its main C, C++ and Qt framework. Another very useful tool is Geany, a lightweight and simple IDE which supports a huge amount of programming languages, while we also include Atom, the opensource editor of the future developed by GitHub, and many compilers and interpreters with their most important libraries are pre-installed and ready to use.And of course many other editors, development softwares and libraries are available through our software repository where we keep all the development tools always updated to their most cutting edge but reliable version. ChangelogFrom 3.2 to 3.3 (25/12/2016)include linux 4.8 kernelfix touchpad/multitouch supportfix mismatching kernel installerupdate anonsurffix minor MATE bugsinclude GCC 6.2update metasploit-framework 4.13switch to php 7upgrade most of the tools to their latest versionDownload Parrot 3.3 Full Edition

Link: http://feedproxy.google.com/~r/PentestTools/~3/ZBVxdgb-54c/parrot-security-33-security-gnulinux.html

12 Days of HaXmas: A Fireside Foray into a Firefox Fracas

Merry HaXmas to you! Each year we mark the 12 Days of HaXmas with 12 blog posts on hacking-related topics and roundups from the year. This year, we’re highlighting some of the “gifts” we want to give back to the community. And while these gifts may not come wrapped with a bow, we hope you enjoy them.  Towards the end of November, the Tor community was shaken up by the revelation of an previously unknown vulnerability being actively exploited against pedo^H^H^H^H Tor Browser users. Some further drama unfolded regarding who the source for the exploit may be, and I received questions from several reporters who wanted every single detail I could give them. While I did not participate in commenting at the time, I’ll say everything I will ever say about it now: – Yes, I’m aware of a very similar exploit which targeted Firefox- No, I didn’t write it Largely lost among all the noise are the nuances of the vulnerability and the exploit itself, which I know the author put his heart and soul into. If anonymous entrants are ever retroactively awarded Pwnies, I’d like to put his unsaid name into the hat. In this part of the 12 Days of HaXmas, I wanted to offer a high level overview to some of the more interesting parts of both the vulnerability–which in my opinion doesn’t fit cleanly into any classic category–and the exploit. I’m not going to dive into all of the gory details for a couple of reasons. Firstly, timing. Had this been leaked earlier in the year, I might have been able to do the analysis part some justice. Second, while verbose technical expositions certainly have their place, a blog is not the right spot. The content might take take another 12 days to cover, and for those seeking to learn from it, I feel your own analysis of the exploit coupled with lots of dirty work in a debugger would be your best option. In that case, hopefully this can offer you some direction along the way. The Discovery It would be remiss of me if I didn’t begin by pointing out that no fuzzer was used in the discovery of this vulnerability. The only tools employed were the Woboq Code Browser (Woboq Code Browser – Explore C++ code on the web), WinDBG, a sharp mind, and exhaustive effort. The era of low-hanging fruit is largely over in my opinion. Don’t be the gorilla, be the lemur, climb that tree. The Vulnerability In the following snippet from nsSMILTimeContainer.cpp, the pointer p is initialized to the beginning of the mMilestoneEntries array. void
nsSMILTimeContainer::NotifyTimeChange()
{
  // Called when the container time is changed with respect to the document
  // time. When this happens time dependencies in other time containers need to
  // re-resolve their times because begin and end times are stored in container
  // time.
  //
  // To get the list of timed elements with dependencies we simply re-use the
  // milestone elements. This is because any timed element with dependents and
  // with significant transitions yet to fire should have their next milestone
  // registered. Other timed elements don’t matter.
  const MilestoneEntry* p = mMilestoneEntries.Elements();
#if DEBUG
  uint32_t queueLength = mMilestoneEntries.Length();
#endif
  while (p < mMilestoneEntries.Elements() + mMilestoneEntries.Length()) {     mozilla::dom::SVGAnimationElement* elem = p->mTimebase.get();
    elem->TimedElement().HandleContainerTimeChange();
    MOZ_ASSERT(queueLength == mMilestoneEntries.Length(),
               “Call to HandleContainerTimeChange resulted in a change to the "
               "queue of milestones");
    ++p;
  }
}
 Now, consider the following two examples: Exhibit One<html>
<head>
  <title>
  Exhibit One
  </title>
</head>
<body>
    <svg id=’foo’>
        <animate id=’A’ begin=’1s’ end=’10s’ />
        <animate begin=’A.end + 5s’ dur=’15s’ />
    </svg>
</body>
</html>
 Exhibit Two<html>
<head>
  <title>
  Exhibit Two
  </title>
</head>
<body>
    <svg id=’foo’>
        <animate id=’A’ begin=’1s’ end=’10s’ />
    </svg>
    <svg id=’bar’>
        <animate begin=’A.end + 5s’ dur=’15s’ />
    </svg>
</body>
</html>
 In these examples, for each <svg> element that uses <animate>, an nsSMILTimeContainer object is assigned to it in order to perform time book keeping for the animations (<animateTransform> or <animateMotion> will also have the same behavior).  The epoch of each container is the time since the creation of the <svg> element it is assigned to relative to the creation of the page.  The nsSMILTimeContainer organizes each singular event in an animation with an entry for each in the mMilestoneEntries member array. See: nsSMILTimeContainer.h – DXR In Exhibit One, the mMilestoneEntries array will contain four entries: one for both the beginning and ending of ‘A’, in addition to another two, one being relative to A’s completion (A.end + 5s), and the other demarcating the end of the animation, in this case 30 seconds (A.end + 5s + 15s). In Exhibit Two we see two independent <svg> elements.  In this example, two separate nsSMILTimeContainer objects will be created, each of course having it’s own mMilestoneEntries array. The exploit makes a single call to the function pauseAnimation(), which in turn triggers entry into the NotifyTimeChange() method.  nsSMILTimeContainer::NotifyTimeChange() proceeds to iterate through all entries in the mMilestoneEntries array, retrieving each individual entries nsSMILTimedElement object, after which it calls the object’s HandleContainerTimeChange() method.  After some time, this method will end up making a call to the NotifyChangedInterval() method of of the nsSMILTimedElement object.  In NotifyChangedInterval(), HandleChangedInterval() will be entered if the animation being processed has a milestone relative to another animation.  In Exhibit Two, bar’s beginning is relative to the element A belonging to foo, so HandleChangedInterval() will be called. Within HandleChangedInterval(), a call to nsSMILTimeValueSpec::HandleChangedInstanceTime() will inevitably be made.  This method determines if the current animation element and the one it has a dependency on are contained within the same nsSMILTimeContainer object.  If so, as is the case with Exibit One, the pauseAnimations() function basically lives up to it’s name and pauses them.  In Exhibit Two, the animations do not share the same nsSMILTimeContainer object, so additional bookkeeping is required in order to maintain synchronization.  This occurs, with subsequent calls to nsSMILTimedElement::UpdateInstanceTime() and nsSMILTimedElement::UpdateCurrentInterval() being made, and nothing too interesting is to be seen, though we will be revisiting it very shortly. Deeper down the rabbit hole … What about the case of three or more animation elements with relative dependencies? Looking at the exploit, we see four animations split unequally among two containers.  We can modify Exhibit Two using details gleaned from the exploit to arrive at the following example. Exhibit Three<html>
<head>
  <title>
  Exhibit Three
  </title>
</head>
<body>
  <script>
     var foo = document.getElementById(‘foo’);
     foo.pauseAnimations();
  </script>
    <svg id=’foo’>
        <animate id=’A’ begin=’1s’ end=’5s’ />
        <animate id=’B’ begin=’10s’ end=’C.end’ dur=’5s’ />
    </svg>
    <svg id=’bar’>
        <animate id=’C’ begin=’0s’ end=’A.end/>
    </svg>
</body>
</html>
 In this example, C’s ending is relative to A’s end, so we end up in nsSMILTimedElement::UpdateCurrentInterval() again, except that a different branch is followed based on the example’s milestones: if (mElementState == STATE_ACTIVE) {
  // The interval is active so we can’t just delete it, instead trim it so
  // that begin==end.
  if (!mCurrentInterval->End()->SameTimeAndBase(*mCurrentInterval->Begin()))
  {
    mCurrentInterval->SetEnd(*mCurrentInterval->Begin());
    NotifyChangedInterval(mCurrentInterval, false, true);
  }
  // The transition to the postactive state will take place on the next
  // sample (along with firing end events, clearing intervals etc.)
  RegisterMilestone();
 NotifyChangedInterval() is called to resolve any milestones relative to other animations for C.  Within foo, B has milestones relative to C in bar.  This results in a recursive branch along the same code path which ultimately hits UpdateCurrentInterval(), which in turn sets the state of the nsSMILTimedElement.  mElementState can be one of four possible values: STATE_STARTUPSTATE_WAITINGSTATE_ACTIVESTATE_POSTACTIVE all of which perfectly describes their own respective meanings.  In Exhibit Three, B’s beginning is set to occur after it’s ending is set (C.end == A.end == 5s).  Since it will never start, the code marks it as STATUS_POSTACTIVE.  This results in the following code within the UpdateCurrentInterval() method creating a new interval and setting it as current. if (GetNextInterval(GetPreviousInterval(), mCurrentInterval,
                    beginTime, updatedInterval)) {

  if (mElementState == STATE_POSTACTIVE) {

    MOZ_ASSERT(!mCurrentInterval,
               "In postactive state but the interval has been set");
    mCurrentInterval = new nsSMILInterval(updatedInterval);
    mElementState = STATE_WAITING;
    NotifyNewInterval();
  }
 With this occurring, UpdateCurrentInterval() now makes a call to the RegisterMilestone() method.  This was not the case in Exhibit Two.  With a new interval having been created, the method will add a new entry in the mMilestoneEntries array of containerA’s nsSMILTimeContainer object, resulting in the array being freed and reallocated elsewhere, leaving the pointer p from nsSMILTimeContainer::NotifyTimeChange() referencing invalid memory. Exploitation Overview Just because the pointer p in NotifyTimeChange() can be forced to point to free memory doesn’t mean it’s all over.  Firefox overwrites freed memory with 0x5a5a5a5a, which effectively mitigates a lot of classic UaF scenarios.  Secondly, there is no way to allocate memory in the freed region after the milestone array is relocated.  Given these conditions, it’s becoming clear that the vulnerability cannot be exploited like a classic use-after-free bug.  If you forced me to categorize it and come up with a new buzz word as people are so apt to in this industry, I might call it a dangling index, or an iterator run-off.  Regardless of silly names, the exploit utilizes some artful trickery to overcome the hurdles inherent in the vulnerability.  As I mentioned at the offset, for the sake of brevity, I’m going to be glossing over a lot of the details with regards to heap determinism (the terms "heap grooming" and "heap massaging" irritate me more than the word "moist"). In the first step, the exploit defragments the heap by spraying 0x80 byte blocks of ArrayBuffers, and another 0x80 of milestone arrays.  Each of the milestone arrays is filled to capacity, and then one additional element is added to each.  This causes the arrays to be reallocated elsewhere, leaving 0x80 holes.  After filling these holes with vulnerable milestone arrays, assuming the <b>last element</b> of the array is the one that triggers the vulnerability, there is now a high probability that the next iteration of the NotifyTimeChange() loop will point within one of the 0x80 ArrayBuffer’s that were allocated first.  It is important that the last element be the one to trigger the bug, as otherwise, the memory would be freed and overwritten before an attacker could take advantage of it. The next obstacle in the process is bypassing the object reference count which, under normal circumstances, would cause the loop to exit.  Even if this were a full technical exposition, I’d leave this part as an exercise to the reader because of reasons.  I invite you to figure it out on your own, because it’s both quite clever and critical to the success of the exploit.  Those pesky reasons though.  Seasoned exploitation engineers will see it quickly, and astute students will have truly learned when they unravel the knot. I’d like to think that this is a good hint, but the only certainty is that it comes up on my 3 AM debugging session playlist a lot In any case, after the exploit does it’s thing, the exit condition of the loop while (p < mMilestoneEntries.Elements() + mMilestoneEntries.Length())
 will never be reached, and instead the loop will continue to iterate infinitely.  While this is great news, it also means that an attacker is unable to continue executing code.  The solution to this is one of the more brilliant aspects of this exploit, that being the use of a Javascript worker thread.   var worker = new Worker(‘cssbanner.js’);
 With the worker thread, Javascript can continue being executed while the infinite loop within the main thread keeps spinning.  In fact, it’s used to keep tabs on a lot of magical heap manipulation happening in the background, and to selectively exit the loop when need be.  From here, the exploit leverages a series of heap corruptions into a r/w primitive, and bypasses ASLR by obtaining the base address of xul.dll from said corruptions by parsing the files DOS header in memory.  This, along with resolving imports, is the main purpose of the PE(b,a) function in the leaked exploit. With ASLR defeated, all that lies ahead is defeating Data Execution Prevention, as the Tor browser doesn’t feature any sort of sandbox technology.  The exploit handles this beautifully by implementing an automatic ROP chain generation function, which can locate the addresses of required gadgets amongst multiple versions of Firefox/Tor browser.  After constructing the chain, the following shellcode is appended (I’ve converted all addresses to base 16 for readability and added comments): ropChain[i++] = 0xc4819090;   // add esp, 800h
ropChain[i++] = 0x0800;
ropChain[i++] = 0x5050c031;   // xor eax, eax ; push eax ; push eax
ropChain[i++] = 0x5b21eb50;   // push eax ; jmp eip+0x23 ; pop ebx
ropChain[i++] = 0xb8505053;   // push ebx ; push eax ; push eax
ropChain[i++] = CreateThread; // mov eax, kernel32!CreateThread
ropChain[i++] = 0xb890d0ff;   // call eax
ropChain[i++] = arrBase + 0x2040;   // mov eax, arrBase+0x2040
ropChain[i++] = 0x5f58208b;   // mov esp, dword ptr [eax] ; pop eax ; pop edi
ropChain[i++] = 0xbe905d58;   // pop eax ; pop ebp
ropChain[i++] = 0xffffff00;   // mov esi, 0xffffff00
ropChain[i++] = 0x000cc2c9;   // ret 0x0c
ropChain[i++] = 0xffffdae8;   // call eip+0x21
ropChain[i++] = 0x909090ff;   // placeholder for payload address
 The shellcode basically allocates stack space and makes a call to CreateThread with the address of the final payload, which is obtained via the jmp eip+x023 ; pop ebx line, as it’s argument.  It next performs stack cleanup and exits the current infinite NotifyTimeChange() loop to ensure clean process continuation.  At least, it’s supposed to.  Initial findings I’ve read from other researchers seem to indicate that it does not continue cleanly when used against Tor browser.  I need to investigate this myself at the first lull in the holiday festivities. "I hope I managed to prove that exploiting buffer overflows should be an art"                                                                                         – Solar Designer That wraps this up for now. Check back for updates in the future as I continue analysis on it. If you have questions about anything, feel free to ask either here or find me on Twitter @iamwilliamwebb. Happy holidays!  ReferencesOriginal leaked exploit: [tor-talk] Javascript exploit

Link: https://community.rapid7.com/community/metasploit/blog/2016/12/29/a-friendly-fireside-foray-into-a-firefox-fracas