Nytro

Haaa, warn si ban

Introducing Registry Explorer Registry Explorer is a new approach to interacting with Registry hives. It has several unique capabilities not found in other programs. The version being discussed here is 0.0.1.8 (some of the screenshots may reflect v0.0.1.7). It is an early beta version of RE compared to where it will be but the features discussed below are ready for general use. Known issues: Large hives (SOFTWARE hives especially) can be slow to load in RE due to the number of keys that exist (often hundreds of thousands). Give RE a few minutes to load them tho and it will work. This is being addressed. Getting started To get started, lets take a look at the main interface. There is of course a standard menu bar at the top of the screen. Most of the options are self-explanatory, but lets look at a few of them. View | Messages The Messages window is automatically displayed when RE starts. It will contain information about loading hives, warnings, errors, etc. If you have used ShellBags Explorer, it looks and feels pretty much the same as in SBE. Download: binary foray: Software Sursa: binary foray: Introducing Registry Explorer

Posted by James Forshaw currently impersonating NT AUTHORITY\SYSTEM. Much as I enjoy the process of vulnerability research sometimes there’s a significant disparity between the difficulty of finding a vulnerability and exploiting it. The Project Zero blog containsnumerousexamples of complex exploits for seemingly trivial vulnerabilities. You might wonder why we’d go to this level of effort to prove exploitability, surely we don’t need to do so? Hopefully by the end of this blog post you’ll have a better understanding of why it’s often the case we spend a significant effort to demonstrate a security issue by developing a working proof of concept. Our primary target for a PoC is the vendor, but there are other benefits for developing one. A customer of the vendor’s system can use the PoC to test whether they’re vulnerable to the issue and ensure any patch has been correctly applied. And the security industry can use it to develop mitigations and signatures for the vulnerability even if the vendor is not willing or able to patch. Without the PoC being made available only people who reverse engineer the patch are likely to know about it, and they might not have your best interests in mind. I don’t want this blog post to get bogged down in too much technical detail about the bug (CVE-2015-0002 for reference). Instead I’m going to focus on the process of taking that relatively simple vulnerability, determining exploitability and developing a PoC. This PoC should be sufficient for a vendor to make a reasonable assessment of the presented vulnerability to minimize their triage efforts. I’ll also explain my rationale for taking various shortcuts in the PoC development and why it has to be so. Reporting a Vulnerability One of the biggest issues with vulnerability research on closed or proprietary systems is dealing with the actual reporting process to get a vulnerability fixed. This is especially the case in complex or non-obvious vulnerabilities. If the system is open source, I could develop a patch, submit it and it stands a chance of getting fixed. For a closed source system I will have to go through the process of reporting. To understand this better let’s think about what a typical large vendor might need to do when receiving external security vulnerability reports. This is a really simplified view on vulnerability response handling but it’s sufficient to explain the principles. For a company which develops the majority of their software internally I would have little influence over the patching cycle, but I can make a difference in the triage cycle. The easier I can make the vendor’s life the shorter the triage cycle can be and the quicker we can get a patch released. Everyone wins, except hopefully the people who might be using this vulnerability already. Don’t forget just because I didn’t know about this vulnerability before doesn’t mean it isn’t already known about. In an ideal vulnerability research world (i.e. one in which I have to do the least amount of non-research work) if I find a bug all I’d need to do is write up some quick notes about it, send it to a vendor, they’ll understand the system, they’ll immediately move heaven and earth to develop the patch, job done. Of course it doesn’t work that way, sometimes just getting a vendor to recognize there’s even a security issue is an important first step. There can be a significant barrier between moving from the triage cycle to the patch cycle, especially as they’re usually separate entities inside a company. To provide for the best chance possible I’ll do two things: Put together a report of sufficient detail so the vendor understands the vulnerability Develop a PoC which unequivocally demonstrates the security impact Writing up a Report Writing up a report for the vendor is pretty crucial to getting an issue fixed, although it isn’t sufficient in many cases. You can imagine if I wrote something like, “Bug in ahcache.sys, fixit, *lol*” that doesn’t really help the vendor much. At the very least I’d want to provide some context such as what systems the vulnerability affects (and doesn’t affect), what the impact of the vulnerability is (to the best of my knowledge) and what area of the system the issue resides. Why wouldn’t just the report be sufficient? Think about how a large modern software product is developed. It’s likely developed between a team of people who might work on individual parts. Depending on the age of the vulnerable code the original developer might have moved on to other projects, left the company entirely or been hit by the number 42 bus. Even if it’s relatively recent code written by a single person who’s still around to talk to it doesn’t mean they remember how the code works. Anyone who’s developed software of any size will have come across code they wrote, a month, week or even a day ago and wondered how it works. There’s a real possibility that the security researcher who’s spent time going through the executable instruction by instruction might know it better than anyone in the world. Also you can think about the report in a scientific sense, it’s your vulnerability hypothesis. Some vulnerabilities can be proven, for example a buffer overflow can typically be proven mathematically, placing 10 things into space for 5 doesn’t work. But in many cases there’s nothing better than empirical proof of exploitability. If done right it can be experimentally validated by both the reporter and the vendor, this is the value of a proof-of-concept. Correctly developed the vendor can observe the effects of the experiment, converting my hypothesis to a theory which no-one can disprove. Proving Exploitability through Experimentation So the hypothesis posits that the vulnerability has a real-world security impact, we’ll prove it objectively using our PoC. In order to do this we need to provide the vendor not just with the mechanism to prove that the vulnerability is real but also clear observations that can be made and why those observations constitute a security issue. What observations need to be made depend on the type of vulnerability. For memory corruption vulnerabilities it might be sufficient to demonstrate an application crashing in response to certain input. This isn’t always the case, some memory corruptions don’t provide the attacker any useful control. Therefore demonstrating control over the current execution flow, such as controlling the EIP register is usually the ideal. For logical vulnerabilities it might be more nuanced, such as you can write a file to a location you shouldn’t be able to or the calculator application ends up running with elevated privileges. There’s no one-size-fits-all approach, however at the very least you want to demonstrate some security impact which can be observed objectively. The thing to understand is I’m not developing a PoC for the purposes of being a useful exploit (from an attacker perspective) but to prove it’s a security issue to a sufficient level of confidence that it will get fixed. Unfortunately it isn’t always easy to separate these two aspects and sometimes without demonstrating local privilege escalation or remote code execution it isn’t taken as seriously as it should be. Developing a Proof of Concept Now let’s go into some of the challenges I faced in developing a PoC for the ahcache vulnerability I identified. Let’s not forget there’s a trade off between the time spent developing a PoC and the chance of the vulnerability being fixed. If I don’t spend enough time to develop a working PoC the vendor could turn around and not fix the vulnerability, on the other hand the more time I spend the longer this vulnerability exists which is potentially as bad for users. Vulnerability Technical Details Having a bit of understanding of the vulnerability will help us frame the discussion later. You can view the issue here with the attached PoC that I sent to Microsoft. The vulnerability exists in the ahcache.sys driver which was introduced in Windows 8.1 but in essence this driver implements the Windows native system call NtApphelpCacheControl. This system call handles a local cache for application compatibility information which is used to correct application behaviour on newer versions of Windows. You can read more about application compatibility here. Some operations of this system call are privileged so the driver does a check of the current calling application to ensure they have administrator privileges. This is done in the function AhcVerifyAdminContext which looks something like the following code: BOOLEAN AhcVerifyAdminContext() { BOOLEAN CopyOnOpen; BOOLEAN EffectiveOnly; SECURITY_IMPERSONATION_LEVEL ImpersonationLevel; PACCESS_TOKEN token = PsReferenceImpersonationToken( NtCurrentThread(), &CopyOnOpen, &EffectiveOnly, &ImpersonationLevel); if (token == NULL) { token = PsReferencePrimaryToken(NtCurrentProcess()); } PSID user = GetTokenUser(token); if(RtlEqualSid(user, LocalSystemSid) || SeTokenIsAdmin(token)) { return TRUE; } return FALSE; } This code queries to see if the current thread is impersonating another user. Windows allows a thread to pretend to be someone else on the system so that security operations can be correctly evaluated. If the thread is impersonating a pointer to an access token is returned. If NULL is returned from PsReferenceImpersonationToken the code queries for the current process’ access token. Finally the code checks whether either the access token’s user is the local system user or the token is a member of the Administrators group. If the function returns TRUE then the privileged operation is allowed to go ahead. This all seems fine, so what’s the issue? While full impersonation is a privileged operation limited to users which havethe impersonate privilege in their token, a normal user without the privilege can impersonate other users for non-security related functions. The kernel differentiates between privileged and unprivileged impersonation by assigning a security level to the token when impersonation is enabled. To understand the vulnerability there’s only two levels of interest, SecurityImpersonation which means the impersonation is privileged and SecurityIdentification which is unprivileged. If the token is assigned SecurityIdentification only operations such as querying for token information, such as the token’s user is allowed. If you try and open a secured resource such as a file the kernel will deny access. This is the underlying vulnerability, if you look at the code the PsReferenceImpersonationToken returns a copy of the security level assigned to the token, however the code fails to verify it’s at SecurityImpersonation level. This means a normal user, who was able to get hold of a Local System access token could impersonate at SecurityIdentification and still pass the check as querying for the user is permitted. Proving Trivial Exploitation Exploiting the bug requires capturing a Local System access token, impersonating it and then calling the system call with appropriate parameters. This must be achievable from normal user privilege otherwise it isn’t a security vulnerability. The system call is undocumented so if we wanted to take a shortcut could we just demonstrate that we can capture the token and leave it at that? Well not really, what this PoC would demonstrate is that something which is documented as possible is indeed possible. Namely that it’s possible from a normal user to capture the token and impersonate it, as the impersonation system is designed this would not cause a security issue. I knew already that COM supports impersonation, that there’s a number of complex system privileged services (for example BITS) we can communicate with as a normal user that we could convince to communicate back to our application in order to perform the impersonation. This wouldn’t demonstrate that we can even reach the vulnerable AhcVerifyAdminContext method in the kernel let alone successfully bypass the check. So starts the long process of reverse engineering to work out how the system call works and what parameters you need to pass to get it to do something useful. There’s some existing work from other researchers (such as this) but certainly nothing concrete to take forward. The system call supports a number of different operations, it turned out that not all the operations needed complex parameters. For example the the AppHelpNotifyStart and AppHelpNotifyStop operations could be easily called, and they relied on the AhcVerifyAdminContext function. I could now produce a PoC which we can verify bypasses the check by observing the system call’s return code. BOOL IsSecurityVulnerability() { ImpersonateLocalSystem(); NTSTATUS status = NtApphelpCacheControl(AppHelpNotifyStop, NULL); return status != STATUS_ACCESS_DENIED; } Is this sufficient to prove exploitability? History has taught me no, for example this issue has almost the exact same sort of operation, namely you can bypass an administrator check through impersonation. In this case I couldn’t produce sufficient evidence that it was exploitable for anything other than information disclosure. So in turn it was not fixed, even though it was effectively a security issue. To give ourselves the best chance of proving exploitability we need to spend more time on this PoC. Improving the Proof-of-Concept In order to improve upon the first PoC I would need to get a better understanding of what the system call is doing. The application compatibility cache is used to store the lookup data from the application compatibility database. This database contains rules which tell the application compatibility system what executables to apply “shims” to in order implement custom behaviours, such as lying about the operating system’s version number to circumvent an incorrect check. The lookup is made every time a process is created, if a suitable matching entry is found it’ll be applied to the new process. The new process will then lookup the shim data it needs to apply from the database. As this occurs every time a new process is created there’s a significant performance impact in going to database file every time. The cache is there to reduce this impact, the database lookup can be added to the cache. If that executable is created later the cached lookup can quickly eliminate the expensive database lookup and either apply a set of shims or not. Therefore we should be able to cache an existing lookup and apply it to an arbitrary executable. So I spent some time working out the format of the parameters to the system call in order to add my own cached lookup. The resulting structure for Windows 8.1 32 bit looked like the following: struct ApphelpCacheControlData { BYTE unk0[0x98]; DWORD query_flags; DWORD cache_flags; HANDLE file_handle; HANDLE process_handle; UNICODE_STRING file_name; UNICODE_STRING package_name; DWORD buf_len; LPVOID buffer; BYTE unkC0[0x2C]; UNICODE_STRING module_name; BYTE unkF4[0x14]; }; You can see there’s an awful lot of unknown parts in the structure. This causes a problem if you were to apply this to Windows 7 (which has a slightly different structure) or 64 bit (which has a different sized structure) but for our purposes it doesn’t matter. We’re not supposed to be writing code to exploit all versions of Windows, all we need to do is prove the security issue to the vendor. As long as you inform the vendor of the PoC limitations (and they pay attention to them) we can do this. The vendor’s still better placed to determine if this PoC proves exploitability across versions of the OS, it’s their product after all. So I could now add an arbitrary cached entry but what can we actually add? I could only add an entry which would have been the result of an existing lookup. You could modify the database to do something like patch running code (the application compatibility system is also used for hotfixes) but that would require administrator privileges. So I needed an existing shim to repurpose. I built a copy of the SDB explorer tool (available from here) so that I could dump the existing database looking for any useful existing shim. I found that for 32 bit there’s a shim which will cause a process to start the executable regsvr32.exe passing the original command line. This tool will load a DLL passed on the command line and execute specific exported methods, if we could control the command line of a privileged process we could redirect it and elevate privileges. This again limits the PoC to only 32 bit processes but that’s fine. The final step, and what caused a lot of confusion was what process to choose to redirect. I could have spent a lot of time investigating other ways of achieving the requirement of starting a process where I control the command line. I already knew one way of doing it, UAC auto elevation. Auto elevation is a feature added to Windows 7 to reduce the number of UAC dialogs a typical user sees. The OS defines a fixed list of allowed auto elevating applications, when UAC is at it’s default setting then requests to elevate these applications do not show a dialog when the user’s an administrator. I can abuse this by applying a cache entry for an existing auto elevating application (in this case I chose ComputerDefaults.exe) and requesting the application runs elevated. This elevated application redirects to regsvr32 passing our fully controlled command line, regsvr32 loads my DLL and we’ve now got code executing with elevated privileges. The PoC didn’t give someone anything they couldn’t already do through various other mechanisms (such as this metasploit module) but it was never meant to. It sufficiently demonstrated the issue by providing an observable result (arbitrary code running as an administrator), from this Microsoft were able to reproduce it and fix it. Final Bit of Fun As there was some confusion on whether this was only a UAC bypass I decided to spend a little time to develop a new PoC which gets local system privileges without any reliance on UAC. Sometimes I enjoy writing exploits, if only to prove that it can be done. To convert the original PoC to one which gets local system privileges I need a different application to redirect. I decided the most likely target was a registered scheduled task as you can sometimes pass arbitrary arguments to the task handler process. So we’ve got three criteria for the ideal task, a normal user must be able to start it, it must result in a process starting as local system and that process must have an arbitrary command line specified by the user. After a bit of searching I found the ideal candidate, the Windows Store Maintenance Task. As we can see if runs as the local system user. We can determine that a normal user can start it by looking at the task file’s DACL using a tool such as icacls. Notice the entry in the following screenshot for NT AUTHORITY\Authenticated Users with Read and Execute (RX) permissions. Finally we can check whether a normal user can pass any arguments to the task by checking the XML task file. In the case of WSTask it uses a custom COM handler, but allows the user to specify two command line arguments. This results in the executable c:\windows\system32\taskhost.exe executing with an arbitrary command line as the local system user. It was just a case of modifying the PoC to add a cache entry for taskhost.exe and start the task with the path to our DLL. This still has a limitation, specifically it only works on 32 bit Windows 8.1 (there’s no 32 bit taskhost.exe on 64 bit platforms to redirect). Still I’m sure it can be made to work on 64 bit with a bit more effort. As the vulnerability is now fixed I’ve made available the new PoC, it’s attached to the original issue here. Conclusions I hope I’ve demonstrated some of the effort a vulnerability researcher would go to in order to ensure a vulnerability will be fixed. It’s ultimately a trade off between the time spent developing the PoC and the chances of the vulnerability being fixed, especially when the vulnerability is complex or non-obvious. In this case I felt I made the right trade-off. Even though the PoC I sent to Microsoft looked, on the surface to only be a UAC bypass combined with the report they were able to determine the true severity and develop the patch. Of course if they’d pushed back and claimed it was not exploitable then I would have developed a more robust PoC. As a further demonstration of the severity I did produce a working exploit which gained local system privileges from a normal user account. Disclosing the PoC exploit is of value to aid in a user’s or security company’s mitigation of a public vulnerability. Without a PoC it’s quite difficult to verify that a security issue has been patched or mitigated. It also helps to inform researchers and developers what types of issues to look out for when developing certain security sensitive applications. Bug hunting is not the sole approach for Project Zero to help secure software, education is just as important. Project Zero’s mission involves tackling software vulnerabilities, and the development of PoCs can be an important part of our duty to help software vendors or open source projects take informed action to fix vulnerabilities. Posted by Chris Evans at 5:27 PM Sursa: http://googleprojectzero.blogspot.co.uk/2015/02/a-tokens-tale_9.html

Attackers Using New MS SQL Reflection Techniques By Bill BrennerFebruary 12, 2015 6:30 AM The bad guys are using a fairly new technique to tamper with the Microsoft SQL Server Resolution Protocol (MC-SQLR) and launch DDoS attacks. In an advisory released this morning, Akamai's Prolexic Security Engineering & Response Team (PLXsert) described it as a new type of reflection-based distributed denial of service (DDoS) attack. PLXsert first spotted attackers using the technique in October. Last month, researcher Kurt Aubuchon studied another such attack and offered an analysis here. PLXsert replicated this attack by creating a script based on Scapy, an open-source packet manipulation tool. Download the full advisory How it works The attack manifests in the form of Microsoft SQL Server responses to a client query or request via abuse of the Microsoft SQL Server Resolution Protocol (MC-SQLR), which listens on UDP port 1434. MC-SQLR lets clients identify the database instance with which they are attempting to communicate when connecting to a database server or cluster with multiple database instances. Each time a client needs to obtain information on configured MS SQL servers on the network, the SQL Resolution Protocol can be used. The server responds to the client with a list of instances. Attackers abuse SQL servers by executing scripted requests and spoofing the source of the query with the IP address of the intended target. Depending on the number of instances present in the abused SQL server, the amplification factor varies. The attack presents a specific payload signature, producing an amplification factor of nearly 25x. In this case, the attacker's request totaled 29 bytes, including IP and UDP headers, and triggered a response of 719 bytes including headers. Some servers may produce a larger or smaller response depending on their configuration. Other tools publicly available on the Internet could reproduce this attack as well. Replicating this attack does not require a high level of technical skill. A scripted attack would only require a list of SQL servers exposed on the Internet that respond to the query. Attackers could use a unicast client request 0x03 or a broadcast request 0x02. Both are requests with a data length of 1 byte that will produce the same type of response from SQL servers. PLXsert identified a tool on GitHub on January 26, 2015, that weaponizes this type of attack for mass abuse. Defensive measures Server hardening procedures should always be applied to servers that are exposed to the Internet. As a general rule, services and protocols that are unnecessary should be disabled or blocked. This attack can only be performed by querying SQL servers with exposed SQL Server Resolution Protocol ports to the Internet. The following best practices can help mitigate this type of DDoS attack. These recommendations are by no means exhaustive and affected organizations should refine and adapt them further based on specific infrastructure and exposed services. Follow Microsoft Technet Security Best Practices to Protect Internet Facing Web Servers. The use of ingress and egress filters applied to SQL server ports at firewalls, routers, or edge devices may prevent this attack. If there is a business case for keeping UDP 1434 open, it should be filtered to only allow trusted IP addresses. Block inbound connections from the Internet, if ports are not needed for external access or administration. SQL Server Resolution Protocol service is not needed in servers that have only one database instance. This has been disabled by default since Microsoft SQL Server 2008. It is not disabled in earlier or desktop engine versions. Disable this service to prevent the abuse of SQL server for this type of attack. If the use of SQL Server Resolution Protocol service is needed, add an additional layer of security before the service is accessed, such as authentication via secure methods (SSH, VPN) or filtering as described above. Sursa: https://blogs.akamai.com/2015/02/plxsert-warns-of-ms-sql-reflection-attacks.html

gosms Your own local SMS gateway What's the use ? Can be used to send SMS, where you don't have access to internet or cannot use Web SMS gateways or want to save some money per SMS, or have minimal requirements for personal / internal use and such deploy in less than 1 minute supports Windows, GNU\Linux, Mac OS works with GSM modems provides API over HTTP to push messages to gateway, just like the internet based gateways do takes care of queuing, throttling and retrying supports multiple devices at once deployment Update conf.ini [DEVICES] section with your modem's COM port. for ex. COM10 or /dev/USBtty2 Run Sursa: https://github.com/haxpax/gosms

INFERNAL-TWIN This is the tool created to automate Evil Twin attack and capturing public and guest credentials of Access Point infernal-twin What this tool will do ? Set up monitoring interface Set up DB Scan wireless network in the range Connect to the network selected SSID Obtain login page of authentication Modify the login page with attacker controlled php script to obtain the credentials Set up Apache Server and serve fake login page Give a victim an IP Set up NAT table Dump the traffic Source && Download Sursa: infernal-twin - This is evil twin attack automated

3VILTWINATTACKER – ROGUE WI-FI ACCESS POINT This tool create an rogue Wi-Fi access point , purporting to provide wireless Internet services, but snooping on the traffic. 3vilTwinAttacker dependencies: Recommended for 3vilTwinAttacker – Kali linux. Ettercap. Sslstrip. Airbase-ng include in aircrack-ng. DHCP. Ubuntu $ sudo apt-get install isc-dhcp-serverKali linux $ echo "deb Index of /debian wheezy main " >> /etc/apt/sources.list $ apt-get update && apt-get install isc-dhcp-serverFedora $ sudo yum install dhcp 3vilTwinAttacker Options: Etter.dns: Edit etter.dns to loading module dns spoof. Dns Spoof: Start dns spoof attack in interface ath0 fake AP. Ettercap: Start ettercap attack in host connected AP fake Capturing login credentials. Sslstrip: The sslstrip listen the traffic on port 10000. Driftnet: The driftnet sniffs and decodes any JPEG TCP sessions, then displays in an window. Source && Download Sursa: 3vilTwinAttacker - Rogue Wi-Fi Access Point

WAIDPS – WIRELESS AUDITING AND IPS/IDS WAIDPS is an open source wireless swissknife written in Python and work on Linux environment. This is a multipurpose tools designed for audit (penetration testing) networks, detect wireless intrusion (WEP/WPA/WPS attacks) and also intrusion prevention (stopping station from associating to access point). Apart from these, it will harvest all WiFi information in the surrounding and store in databases. This will be useful when it comes to auditing a network if the access point is ‘MAC filtered’ or ‘hidden SSID’ and there isn’t any existing client at that moment. WAIDS may be useful to penetration testers, wireless trainers, law enforcement agencies and those who is interested to know more about wireless auditing and protection. The primarily purpose for this script is to detect intrusion. Once wireless detect is found, it display on screen and also log to file on the attack. Additional features are added to current script where previous WIDS does not have are : automatically save the attack packets into a file interactive mode where users are allow to perform many functions allow user to analyse captured packets load previously saved pcap file or any other pcap file to be examine customizing filters customize detection threshold (sensitivity of IDS in detection) At present, WAIDS is able to detect the following wireless attacks and will subsequently add other detection found in the previous WIDS. Association / Authentication flooding Detect mass deauthentication which may indicate a possible WPA attack for handshake Detect possible WEP attack using the ARP request replay method Detect possible WEP attack using chopchop method Detect possible WPS pin bruteforce attack by Reaver, Bully, etc. Detection of Evil-Twin Detection of Rogue Access Point WAIDPS Requirements No special equipment is required to use this script as long as you have the following : Root access (admin) Wireless interface which is capable of monitoring and injection Python 2.7 installed Aircrack-NG suite installed TShark installed TCPDump installed Mergecap installed (for joining pcap files) xterm installed Documentation <span style="font-family: Rajdhani"><strong> Source && Download Sursa: WAIDPS - Wireless Auditing and IPS/IDS

Microsoft Internet Explorer 9-11 Windows 7-8.1 Vulnerability (patched in late 2014) Feb 12, 2015 • suto I. Vunerability Description: Uninitialized Memory Corruption Lead to Code Execution. II.Analysis: I crafted an HTML file called 1.html and opened it with IE11/Windows 8.1, the following crash happened: The call tree lead to there : The root cause of problem is wrong assumtion and memory not clearly reset. When execute javascript line: document.getElementsByTagName('tr')[0].insertCell(); The function CTableRowLayout::EnsureCells will be called: Because adding a cell to row, it need to expand the memory to hold new row. First it will reAlloc memory in CimplAry::EnsureSizeWorker to enough for new tableRowLayout. The function success alloc memory as below: But it never reset memory to zero: The line: while ( v2 > v4 ) { --v2; *(_DWORD *)(*(_DWORD *)(v3 + 76) + 4 * v2) = 1; } Will mark if it exist a cell in that row. And the memory at the moment will be likely: 0xheap: 0x1 0x1 0x1 ……. 0xc0c0c0c0 The value 0xc0c0c0c0 is from uninitialized memory. So if we parepare some holes in memory by our string fit with that size, freed before it reallocate our value will be in that location like below ( when our string is 0x40404040 ) That happend because when javascript trying to add a new Row to Table: document.getElementsByTagName(‘table’)[0].insertRow(); But that piece of above memory will never be reset to 1 to indicate that has a cell in there. So after all, IE will trying to access that address,It saw our value as a Pointer to a Table’s Cell Object in Heap. From there it will calculation and Change some memory, with can be lead to Write to controlled memory and highly possible lead to bypass ASLR ( if the address overwrote is Array Lenght ) and Code execution. For full PoC code please email to suto@vnsecurity.net Happy hunting Sursa: Microsoft Internet Explorer 9-11 Windows 7-8.1 Vulnerability (patched in late 2014)

Decrypting TLS Browser Traffic With Wireshark – The Easy Way! Intro Most IT people are somewhat familiar with Wireshark. It is a traffic analyzer, that helps you learn how networking works, diagnose problems and much more. One of the problems with the way Wireshark works is that it can’t easily analyze encrypted traffic, like TLS. It used to be if you had the private key(s) you could feed them into Wireshark and it would decrypt the traffic on the fly, but it only worked when using RSA for the key exchange mechanism. As people have started to embrace forward secrecy this broke, as having the private key is no longer enough derive the actual session key used to decrypt the data. The other problem with this is that a private key should not or can not leave the client, server, or HSM it is in. This lead me to coming up with very contrived ways of man-in-the-middling myself to decrypt the traffic(e.g. sslstrip). Session Key Logging to the Rescue! Well my friends I’m here to tell you that there is an easier way! It turns out that Firefox and the development version of Chrome both support logging the symmetric session key used to encrypt TLS traffic to a file. You can then point Wireshark at said file and presto! decrypted TLS traffic. Read on to learn how to set this up. Setting up our Browsers So if you prefer to use Chrome you must use the Chrome dev channel for this to work, or the default firefox will work too. Next we need to set an environmental variable. On Windows: Go into your computer properties, then click “Advance system settings” then “Environment Variables…” Add a new user variable called “SSLKEYLOGFILE” and point it at the location that you want the log file to be located at. On Linux or Mac OS X: [TABLE=width: 704] [TR] [TD=class: gutter] 1 [/TD] [TD=class: code]$ export SSLKEYLOGFILE=~/path/to/sslkeylog.log[/TD] [/TR] [/TABLE] You can also add this to the last line of your [TABLE=width: 704] [TR] [TD=class: gutter] 1 [/TD] [TD=class: code]~/.bashrc[/TD] [/TR] [/TABLE] on Linux, or [TABLE=width: 704] [TR] [TD=class: gutter] 1 [/TD] [TD=class: code]~/.MacOSX/environment[/TD] [/TR] [/TABLE] on OS X so that it is set every time you log in. The next time that we launch Firefox or the dev channel of Chrome they will log your TLS keys to this file. Setting up Wireshark You need at least Wireshark 1.6 for this to work. We simply go into the preferences of Wireshark Expand the protocols section: Browse to the location of your log file The Results This is more along the lines of what we normally see when look at a TLS packet, This is what it looks like when you switch to the “Decrypted SSL Data” tab. Note that we can now see the request information in plain-text! Success! Conclusion I hope you learned something today, this makes capturing TLS communication so much more straightforward. One of the nice things about this setup is that the client/server machine that generates the TLS traffic doesn’t have to have Wireshark on it, so you don’t have to gum up a clients machine with stuff they won’t need, you can either have them dump the log to a network share or copy it off the machine and reunite it with the machine doing the packet capture later. Thanks for stopping by! References: Mozilla Wiki Imperial Violet Photo Credit: Mike Sursa: https://jimshaver.net/2015/02/11/decrypting-tls-browser-traffic-with-wireshark-the-easy-way/

Totusi, ce cauta "black_death_c4t" acolo?

And about 1000$ budget or even more. You must have at least 50 posts in order to buy something.

Da, nasol, incearca sa ii dai parametru de la -1 la 100 in timp ce testezi (Buffering...), sa apelezi la fiecare secunda sa zicem: Timer 1 sec: -> for(i = -1 to 100) { x = sop.GetState(i); writetofile("i = " & i & "state = " & x) Si sa verifici daca se schimb ceva...

Concerns regarding the security of biometric authentication February 2, 2015 Daniel Tomescu More and more gadgets that we use these days (smart phones, smart watches, etc) try to make a personal connection with the owner via his biometric characteristics.Using biometric measures for authentication purposes is a fast growing trend in the IT world, but there are genuine security concerns regarding the maturity level of these methods and their security faults. How safe is it to use biometrics for authentication? Can they be bypassed? Let’s find out! How to find a good biometric characteristic? At this moment, we have 3 main possibilities for verifying a user’s identity: something that the user knows (like a code or a passphrase), something that the user has (a smart card or a token) or something that the user is (a biometric characteristic).For a biometric characteristic to be considered a valid authentication method, it should have the following properties: Universality, meaning that the feature must be present on all individuals; Measurability, meaning that the feature can be measured and the individuals are willing to share it for measurement purposes; High accuracy, meaning that the feature can be measured with an acceptable error rate; Uniqueness, meaning that the feature should be different for every individual; Robustness, meaning that the feature should not vary in time for the same individual; Circumvention, meaning that the feature should not be easily altered, imitated or replicated by third parties. Although the standards might seem too restrictive, there are a big number of biometric characteristics that meet the requirements above (or at least most of them) and can be used in user recognition. Articol complet: Concerns regarding the security of biometric authentication – Security Café

Minim 50 de posturi pentru tranzactii.

Nu are nicio metoda/proprietate care sa iti returneze acel status? Posteaza-l aici si ma uit si eu daca am timp.

Nu ar fi rau nici un astfel de serviciu.

Ar fi utila o optiune de descarcare ca MP3 a unui playlist de muzica.

Demonstrati ca e infectat.

Super. Pacat ca e limitat. if ("#{major}.#{minor}.#{build}" == "5.2.3790" && revision < 5440) return Exploit::CheckCode::Vulnerable end

E un forum pentru teste. O sa dezactivez email-urile. Daca aflu de unde Pe cele de pe /forum le primesti? Primesti de doua ori? Edit: Sa imi zici daca e ok de acum.

Exploiting “BadIRET” vulnerability February 2, 2015 / Rafal Wojtczuk Exploiting “BadIRET” vulnerability (CVE-2014-9322, Linux kernel privilege escalation) Introduction CVE-2014-9322 is described as follows: arch/x86/kernel/entry_64.S in the Linux kernel before 3.17.5 does not properly handle faults associated with the Stack Segment (SS) segment register, which allows local users to gain privileges by triggering an IRET instruction that leads to access to a GS Base address from the wrong space. It was fixed on 23rd November 2014 with this commit. I have seen neither a public exploit nor a detailed discussion about the issue. In this post I will try to explain the nature of the vulnerability and the exploitation steps as clearly as possible; unfortunately I cannot quote the full 3rd volume of Intel Software Developer’s Manuals, so if some terminology is unknown to the reader then details can be found there. All experiments were conducted on Fedora 20 system, running 64bit 3.11.10-301 kernel; all the discussion is 64bit-specific. Short results summary: With the tested kernel, the vulnerability can be reliably exploited to achieve kernelmode arbitrary code execution. SMEP does not prevent arbitrary code execution; SMAP does prevent arbitrary code execution. Digression: kernel, usermode, iret The vulnerability In a few cases, when Linux kernel returns to usermode via iret, this instruction throws an exception. The exception handler returns execution to bad_iret function, that does /* So pretend we completed the iret and took the #GPF in user mode.*/ pushq $0 SWAPGS jmp general_protection As the comment explains, the subsequent code flow should be identical to the case when general protection exception happens in user mode (just jump to the #GP handler). This works well in case of most of the exceptions that can be raised by iret, e.g. #GP. The problematic case is #SS exception. If a kernel is vulnerable (so, before kernel version 3.17.5) and has “espfix” functionality (introduced around kernel version 3.16), then bad_iret executes with a read-only stack – “push” instruction generates a page fault that gets converted into double fault. I have not analysed this scenario; from now on, we focus on pre 3.16 kernel, with no “espfix”. The vulnerability stems from the fact that the exception handler for the #SS exception does not fit the “pretend-it-was-#GP-in-userspace” schema well. In comparison with e.g. #GP handler, the #SS exception handler does one extra swapgs instruction. In case you are not familiar with swapgssemantics, read the below paragraph, otherwise skip it. Digression: swapgs instruction When memory is accessed with gs segment prefix, like this: mov %gs:LOGICAL_ADDRESS, %eax the following actually happens: BASE_ADDRESS value is retrieved from the hidden part of the segment register memory at linear address LOGICAL_ADDRESS+BASE_ADDRESS is dereferenced The base address is initially derived from Global Descriptor Table (or LDT). However, there are situations where GS segment base is changed on the fly, without involving GDT. Quoting SDM: “SWAPGS exchanges the current GS base register value with the value contained in MSR address C0000102H (IA32_KERNEL_GS_BASE). The SWAPGS instruction is a privileged instruction intended for use by system software. (…) The kernel can then use the GS prefix on normal memory references to access [per-cpu]kernel data structures.” For each CPU, Linux kernel allocates at boot time a fixed-size structure holding crucial data. Then, for each CPU, Linux loads IA32_KERNEL_GS_BASE with this structure address. Therefore, the usual pattern of e.g. syscall handler is: swapgs (now the gs base points to kernel memory) access per-cpu kernel data structures via memory instructions with gs prefix swapgs (it undos the result of the previous swapgs, gs base points to usermode memory) return to usermode Naturally, kernel code must ensure that whenever it wants to access percpu data with gs prefix, the number of swapgs instructions executed by the kernel since entry from usermode is noneven (so that gs base points to kernel memory). Triggering the vulnerability By now it should be obvious that the vulnerability is grave – because of one extra swapgs in the vulnerable code path, kernel will try to access important data structures with a wrong gs base, controllable by the user. When is #SS exception thrown by the iret instruction? Interestingly, the Intel SDM is incomplete in this aspect; in the description of iret instruction, it says: 64-Bit Mode Exceptions: #SS(0) If an attempt to pop a value off the stack violates the SS limit. If an attempt to pop a value off the stack causes a non-canonical address to be referenced. None of these conditions can be forced to happen in kernel mode. However, the pseudocode foriret (in the same SDM) shows another case: when the segment defined by the return frame is not present: IF stack segment is not present THEN #SS(SS selector); FI; So, in usermode, we need to set ss register to something not present. It is not straighforward: we cannot just use mov $nonpresent_segment_selector, %eax mov %ax, %ss as the latter instruction will generate #GP. Setting the ss via debugger/ptrace is disallowed; similarly, the sys_sigreturn syscall does not set this register on 64bits system (it might work on 32bit, though). The solution is: thread A: create a custom segment X in LDT via sys_modify_ldt syscall thread B: ss:=X_selector thread A: invalidate X via sys_modify_ldt thread B: wait for hardware interrupt The reason why one needs two threads (both in the same process) is that the return from the syscall (including sys_modify_ldt) is done via sysret instruction that hardcodes the ss value. If we invalidated X in the same thread that did “ss:=X instruction”, ss would be undone. Running the above code results in kernel panic. In order to do something more meaningful, we will need to control usermode gs base; it can be set via arch_prctl(ARCH_SET_GS) syscall. Achieving write primitive If we run the above code, then #SS handler runs fine (meaning: it will not touch memory at gs base), returns into bad_iret, that in turn jumps to #GP exception handler. This runs fine for a while, and then calls the following function: 289 dotraplinkage void 290 do_general_protection(struct pt_regs *regs, long error_code) 291 { 292 struct task_struct *tsk; ... 306 tsk = current; 307 if (!user_mode(regs)) { ... it is not reached 317 } 318 319 tsk->thread.error_code = error_code; 320 tsk->thread.trap_nr = X86_TRAP_GP; 321 322 if (show_unhandled_signals && unhandled_signal(tsk, SIGSEGV) && 323 printk_ratelimit()) { 324 pr_info("%s[%d] general protection ip:%lx sp:%lx error:%lx", 325 tsk->comm, task_pid_nr(tsk), 326 regs->ip, regs->sp, error_code); 327 print_vma_addr(" in ", regs->ip); 328 pr_cont("\n"); 329 } 330 331 force_sig_info(SIGSEGV, SEND_SIG_PRIV, tsk); 332 exit: 333 exception_exit(prev_state); 334 } It is far from obvious from the C code, but the assignment to tsk from current macro uses memory read with gs prefix. Line 306 is actually: 0xffffffff8164b79d : mov %gs:0xc780,%rbx This gets interesting. We control the “current” pointer, that points to the giant data structure describing the whole Linux process. Particularly, the lines 319 tsk->thread.error_code = error_code; 320 tsk->thread.trap_nr = X86_TRAP_GP; are writes to addresses (at some fixed offset from the beginning of the task struct) that we control. Note that the values being written are not controllable (they are 0 and 0xd constants, respectively), but this should not be a problem. Game over ? Not quite. Say, we want to overwrite some important kernel data structure at X. If we do the following steps: prepare usermode memory at FAKE_PERCPU, and set gs base to it Make the location FAKE_PERCPU+0xc780 hold the pointer FAKE_CURRENT_WITH_OFFSET, such that FAKE_CURRENT_WITH_OFFSET= X – offsetof(struct task_struct, thread.error_code) trigger the vulnerability Then indeed do_general_protection will write to X. But soon afterwards it will try to access other fields in the current task_struct again; e.g. unhandled_signal() function dereferences a pointer from task_struct. We have no control what lies beyond X, and the result will be a page fault in kernel. How can we cope with this? Options: Do nothing. Linux kernel, unlike e.g. Windows, is quite permissive when it gets an unexpected page fault in kernel mode – if possible, it kills the current process, and tries to continue (while Windows bluescreens immediately). This does not work – the result is massive kernel data corruption and whole system freeze. My suspicion is that after the current process is killed, the swapgs imbalance persists, resulting in many unexpected page faults in the context of the other processes. Use the “tsk->thread.error_code = error_code” write to overwrite IDT entry for the page fault handler. Then the page fault (triggered by, say, unhandled_signal()) will result in running our code. This technique proved to be successful on a couple of occasions before. This does not work, either, for two reasons: Linux makes IDT read-only (bravo!) even if IDT was writeable, we do not control the overwrite value – it is 0 or 0xd. If we overwrite the top DWORDS of IDT entry for #PF, the resulting address will be in usermode, and SMEP will prevent handler execution (more on SMEP later). We could nullify the lowest one or two bytes of the legal handler address, but the chances of these two addresses being an useful stack pivot sequence are negligible. [*]We can try a race. Say, “tsk->thread.error_code = error_code” write facilitates code execution, e.g. allows to control code pointer P that is called via SOME_SYSCALL. Then we can trigger our vulnerability on CPU 0, and at the same time CPU 1 can run SOME_SYSCALL in a loop. The idea is that we will get code execution via CPU 1 before damage is done on CPU 0, and e.g. hook the page fault handler, so that CPU 0 can do no more harm. I tried this approach a couple of times, with no luck; perhaps with different vulnerability the timings would be different and it would work better. [*]Throw a towel on “tsk->thread.error_code = error_code” write. With some disgust, we will follow the last option. We will point “current” to usermode location, setting the pointers in it so that the read dereferences on them hit our (controlled) memory. Naturally, we inspect the subsequent code to find more pointer write dereferences. Achieving write primitive continued, aka life after do_general_protection Our next chance is the function called by do_general_protection(): int force_sig_info(int sig, struct siginfo *info, struct task_struct *t) { unsigned long int flags; int ret, blocked, ignored; struct k_sigaction *action; spin_lock_irqsave(&t->sighand->siglock, flags); action = &t->sighand->action[sig-1]; ignored = action->sa.sa_handler == SIG_IGN; blocked = sigismember(&t->blocked, sig); if (blocked || ignored) { action->sa.sa_handler = SIG_DFL; if (blocked) { sigdelset(&t->blocked, sig); recalc_sigpending_and_wake(t); } } if (action->sa.sa_handler == SIG_DFL) t->signal->flags &= ~SIGNAL_UNKILLABLE; ret = specific_send_sig_info(sig, info, t); spin_unlock_irqrestore(&t->sighand->siglock, flags); return ret; } The field “sighand” in task_struct is a pointer, that we can set to an arbitrary value. It means that the action = &t->sighand->action[sig-1]; action->sa.sa_handler = SIG_DFL; lines are another chance for write primitive to an arbitrary location. Again, we do not control the write value – it is the constant SIG_DFL, equal to 0. This finally works, hurray ! with a little twist. Assume we want to overwrite location X in the kernel. We prepare our fake task_struct (particularly sighand field in it) so that X = address of t->sighand->action[sig-1].sa.sa_handler. But a few lines above, there is a line spin_lock_irqsave(&t->sighand->siglock, flags); As t->sighand->siglock is at constant offset from t->sighand->action[sig-1].sa.sa_handler, it means kernel will call spin_lock_irqsave on some address located after X, say at X+SPINLOCK, whose content we do not control. What happens then? There are two possibilities: memory at X+SPINLOCK looks like an unlocked spinlock. spin_lock_irqsave will complete immediately. Final spin_unlock_irqrestore will undo the writes done by spin_lock_irqsave. Good. memory at X+SPINLOCK looks like a locked spinlock. spin_lock_irqsave will loop waiting for the spinlock – infinitely, if we do not react. This is worrying. In order to bypass this, we will need another assumption – we will need to know we are in this situation, meaning we will need to know the contents of memory at X+SPINLOCK. This is acceptable – we will see later that we will set X to be in kernel .data section. We will do the following: initially, prepare FAKE_CURRENT so that t->sighand->siglock points to a locked spinlock in usermode, at SPINLOCK_USERMODE force_sig_info() will hang in spin_lock_irqsave at this moment, another usermode thread running on another CPU will change t->sighand, so that t->sighand->action[sig-1].sa.sa_handler is our overwrite target, and then unlock SPINLOCK_USERMODE spin_lock_irqsave will return. force_sig_info() will reload t->sighand, and perform the desired write. A careful reader is encouraged to enquire why cannot use the latter approach in the case X+SPINLOCK is initially unlocked. This is not all yet – we will need to prepare a few more fields in FAKE_CURRENT so that as little code as possible is executed. I will spare you the details – this blog is way too long already. The bottom line is that it works. What happens next? force_sig_info() returns, and do_general_protection() returns. The subsequent iret will throw #SS again (because still the usermode ss value on the stack refers to a nonpresent segment). But this time, the extra swapgs instruction in #SS handler will return the balance to the Force, cancelling the effect of the previous incorrect swapgs. do_general_protection() will be invoked and operate on real task_struct, not FAKE_CURRENT. Finally, the current task will be sent SIGSEGV, and another process will be scheduled for execution. The system remains stable. Digression: SMEP SMEP is a feature of Intel processors, starting from 3rd generation of Core processor. If the SMEP bit is set in CR4, CPU will refuse to execute code with kernel privileges if the code resides in usermode pages. Linux enables SMEP by default if available. Achieving code execution The previous paragraphs showed a way to overwrite 8 consecutive bytes in kernel memory with 0. How to turn this into code execution, assuming SMEP is enabled? Overwriting a kernel code pointer would not work. We can either nullify its top bytes – but then the resulting address would be in usermode, and SMEP will prevent dereference of this pointer. Alternatively, we can nullify a few low bytes, but then the chances that the resulting pointer would point to an useful stack pivot sequence are low. What we need is a kernel pointer P to structure X, that contains code pointers. We can overwrite top bytes of P so that the resulting address is in usermode, and P->code_pointer_in_) call will jump to a location that we can choose. I am not sure what is the best object to attack. For my experiments, I choose the kernel proc_rootvariable. It is a structure of type struct proc_dir_entry { ... const struct inode_operations *proc_iops; const struct file_operations *proc_fops; struct proc_dir_entry *next, *parent, *subdir; ... u8 namelen; char name[]; }; This structure represents an entry in the proc filesystem (and proc_root represents the root of the /proc filesystem). When a filename path starting with /proc is looked up, the “subdir” pointers (starting with proc_root.subdir) are followed, until the matching name is found. Afterwards, pointers from proc_iops are called: struct inode_operations { struct dentry * (*lookup) (struct inode *,struct dentry *, unsigned int); void * (*follow_link) (struct dentry *, struct nameidata *); ...many more... int (*update_time)(struct inode *, struct timespec *, int); ... } ____cacheline_aligned; proc_root resides in the kernel data section. It means that the exploit needs to know its address. This information is available from /proc/kallsyms; however, many hardened kernels do not allow unprivileged users to read from this pseudofile. Still, if the kernel is a known build (say, shipped with a distribution), this address can be obtained offline; along with tens of offsets required to build FAKE_CURRENT. So, we will ovewrite proc_root.subdir so that it becomes a pointer to a controlled struct proc_dir_entry residing in usermode. A slight complication is that we cannot overwrite the whole pointer. Remember, our write primitive is “overwrite with 8 zeroes”. If we made proc_root.subdirbe 0, we would not be able to map it, because Linux does not allow usermode to map address 0 (more precisely, any address below /proc/sys/vm/mmap_min_addr, but the latter is 4k by default). It means we need to: map 16MB of memory at address 4096 fill it with a pattern resembling proc_dir_entry, with the inode_operations field pointing to usermode address FAKE_IOPS, and name field being “A” string. configure the exploit to overwrite the top 5 bytes of proc_root.subdir Then, unless the bottom 3 bytes of proc_root.subdir are 0, we can be sure that after triggering the overwrite in force_sig_info() proc_root.subdir will point to controlled usermode memory. When our process will call open(“/proc/A”, …), pointers from FAKE_IOPS will be called. What should they point to? If you think the answer is “to our shellcode”, go back and read again. We will need to point FAKE_IOPS pointers to a stack pivot sequence. This again assumes the knowledge of the precise version of the kernel running. The usual “xchg %esp, %eax; ret” code sequence (it is two bytes only, 94 c3, found at 0xffffffff8119f1ed in case of the tested kernel), works very well for 64bit kernel ROP. Even if there is no control over %rax, this xchg instruction operates on 32bit registers, thus clearing the high 32bits of %rsp, and landing %rsp in usermode memory. At the worst case, we may need to allocate low 4GB of virtual memory and fill it with rop chain. In the case of the tested kernel, two different ways to dereference pointers in FAKE_IOPS were observed: %rax:=FAKE_IOPS; call *SOME_OFFSET(%rax) %rax:=FAKE_IOPS; %rax:=SOME_OFFSET(%rax); call *%rax In the first case, after %rsp is exchanged with %rax, it will be equal to FAKE_IOPS. We need the rop chain to reside at the beginning of FAKE_IOPS, so it needs to start with something like “add $A_LOT, %rsp; ret”, and continue after the end of FAKE_IOPS pointers. In the second case, the %rsp will be assigned the low 32bits of the call target, so 0x8119f1ed. We need to prepare the rop chain at this address as well. To sum up, as the %rax value has one of two known values at the moment of the entry to the stack pivot sequence, we do not need to fill the whole 4G with rop chain, just the above two addresses. The ROP chain itself is straightforward, shown for the second case: unsigned long *stack=0x8119f1ed; *stack++=0xffffffff81307bcdULL; // pop rdi, ret *stack++=0x407e0; //cr4 with smep bit cleared *stack++=0xffffffff8104c394ULL; // mov rdi, cr4; pop %rbp; ret *stack++=0xaabbccdd; // placeholder for rbp *stack++=actual_shellcode_in_usermode_pages; Digression: SMAP SMAP is a feature of Intel processors, starting from 5th generation of Core processor. If the SMAP bit is set in CR4, CPU will refuse to access memory with kernel privileges if this memory resides in usermode pages. Linux enables SMAP by default if available. A test kernel module (run on an a system with Core-M 5Y10a CPU) that tries to access usermode crashes with: [ 314.099024] running with cr4=0x3407e0 [ 389.885318] BUG: unable to handle kernel paging request at 00007f9d87670000 [ 389.885455] IP: [ffffffffa0832029] test_write_proc+0x29/0x50 [smaptest] [ 389.885577] PGD 427cf067 PUD 42b22067 PMD 41ef3067 PTE 80000000408f9867 [ 389.887253] Code: 48 8b 33 48 c7 c7 3f 30 83 a0 31 c0 e8 21 c1 f0 e0 44 89 e0 48 8b As we can see, although the usermode page is present, access to it throws a page fault. Windows systems do not seem to support SMAP; Windows 10 Technical Preview build 9926 runs with cr4=0x1506f8 (SMEP set, SMAP unset); in comparison with Linux (that was tested on the same hardware) you can see that bit 21 in cr4 is not set. This is not surprising; in case of Linux, access to usermode is performed explicitely, via copy_from_user, copy_to_user and similar functions, so it is doable to turn off SMAP temporarily for the duration of these functions. On Windows, kernel code accesses usermode directly, just wrapping the access in the exception handler, so it is more difficult to adjust all the drivers in all required places to work properly with SMAP. SMAP to the rescue! The above exploitation method relied on preparing certain data structures in usermode and forcing the kernel to interpret them as trusted kernel data. This approach will not work with SMAP enabled – CPU will refuse to read malicious data from usermode. What we could do is to craft all the required data structures, and then copy them to the kernel. For instance if one does write(pipe_filedescriptor, evil_data, ... then evil_data will be copied to a kernel pipe buffer. We would need to guess its address; some sort of heap spraying, combined with the fact that there is no spoon^W effective kernel ASLR, could work, although it is likely to be less reliable than exploitation without SMAP. However, there is one more hurdle – remember, we need to set usermode gs base to point to our exploit data structures. In the scenario above (without SMAP), we used arch_prctl(ARCH_SET_GS) syscall, that is implemented in the following way in the kernel: long do_arch_prctl(struct task_struct *task, int code, unsigned long addr) { int ret = 0; int doit = task == current; int cpu; switch (code) { case ARCH_SET_GS: if (addr >= TASK_SIZE_OF(task)) return -EPERM; ... honour the request otherwise Houston, we have a problem – we cannot use this API to set gs base above the end of usermode memory ! Recent CPUs feature wrgsbase instruction, that sets the gs base directly. This is a nonprivileged instruction, but needs to be enabled by the kernel by setting the FSGSBASE bit (no 16) in CR4. Linux does not set this bit, and therefore usermode cannot use this instruction. On 64bits, nonsystem entries in GDT and LDT are still 8 bytes long, and the base field is at most 4G-1 – so, no chance to set up a segment with base address in kernel space. So, unless I missed another way to set usermode gs base in the kernel range, SMAP protects 64bit Linux against achieving arbitrary code execution via exploiting CVE-2014-9322. Sursa: http://labs.bromium.com/2015/02/02/exploiting-badiret-vulnerability-cve-2014-9322-linux-kernel-privilege-escalation/

Toledo Atomchess Game By January 28, 2015 came to my knowledge a new chess program written in 487 bytes of x86 assembly code. I don't ever ran it and moved to another things as I was kind of busy. Nevertheless my friends from JS1K and Twitter encouraged me to do something, and I've some notions of x86 machine code. So I started coding my own chess program in x86 assembler, I finished it in 24 hours and went for another 24 hours debugging it. After this I gave a look to the documentation of the other chess program and I was surprised it made illegal movements and doesn't even has a search tree, for me that is like not playing any chess. So here it is, my game is Toledo Atomchess and it is 481 bytes of x86 assembly code and it plays very reasonably under the limitations. Plays basic chess movements (no en passant, no castling and no promotion) Enter your movements as basic algebraic (D2D4) Your movements aren't checked for legality Search depth of 3-ply How to run it To run it you need a 1.44 MB floppy disk and put the 512 byte into the boot sector using an utility like Rawrite, also available as a COM file runable in MS-DOS or Wind*ws command-line. Download Toledo Atomchess package (5.8K) The source code Here is the full source code [FONT=Verdana] ;[/FONT] ; Toledo Atomchess ; ; by Óscar Toledo Gutiérrez ; ; © Copyright 2015 Óscar Toledo Gutiérrez ; ; Creation: 28-ene-2015 21:00 local time. ; Revision: 29-ene-2015 18:17 local time. Finished. ; Revision: 30-ene-2015 13:34 local time. Debugging finished. ; Features: ; * Basic chess movements. ; * Enter moves as algebraic form (D2D4) (note your moves aren't validated) ; * Search depth of 3-ply ; * No promotion of pawns. ; * No castling ; * No en passant. ; * 481 bytes size (fits in a boot sector) ; Note: I'm lazy enough to write my own assembler instead of ; searching for one, so you will have to excuse my syntax code16 ; Change to org &0100 for COM file org &7c00 ; Housekeeping mov sp,stack cld push cs push cs push cs pop ds pop es pop ss ; Create board mov bx,board sr1: mov al,bl and al,&88 ; 0x88 board jz sr2 mov al,&07 ; Frontier sr2: mov [bx],al inc bl jnz sr1 ; Setup board mov si,initial sr3: lodsb ; Load piece mov [bx],al ; Black pieces or al,8 mov [bx+&70],al ; White pieces mov al,&01 mov [bx+&10],al ; Black pawn mov al,&09 mov [bx+&60],al ; White pawn inc bx cmp bl,&08 jnz sr3 ; ; Main loop ; sr21: call display_board call key2 push di call key2 pop si movsb mov byte [si-1],0 call display_board mov ch,&08 ; Current turn (0=White, 8=Black) call play jmp short sr21 ; ; Computer plays ; play: mov bp,-32768 ; Current score push bp ; Origin square push bp ; Target square xor ch,8 ; Change side mov si,board sr7: lodsb ; Read square xor al,ch ; XOR with current playing side dec ax cmp al,6 ; Ignore if frontier jnc sr6 or al,al ; Is it pawn? jnz sr8 or ch,ch ; Is it playing black? jnz sr25 ; No, jump sr8: inc ax sr25: dec si mov bx,offsets push ax xlat mov dh,al ; Movements offset pop ax mov bl,total&255 xlat mov dl,al ; Total movements of piece sr12: mov di,si ; Restart target square mov bl,displacement&255 mov al,dh xlat mov cl,al sr9: add di,cx and di,&ff or di,board mov al,[si] ; Content of: origin in al, target in ah mov ah,[di] or ah,ah ; Empty square? jz sr10 xor ah,ch sub ah,&09 ; Valid capture? cmp ah,&06 mov ah,[di] jnc sr18 ; No, avoid cmp dh,14 ; Pawn? jc sr19 test cl,1 ; Straight? je sr18 ; Yes, avoid jmp short sr19 sr10: cmp dh,14 ; Pawn? jc sr19 test cl,1 ; Diagonal? jne sr18 ; Yes, avoid sr19: push ax ; Save for restoring in near future mov bl,scores&255 mov al,ah and al,7 cmp al,6 ; King eaten? jne sr20 cmp sp,stack-(3+8+3)*2 ; If in first response... mov bp,20000 ; ...maximum score (probably checkmate/slatemate) jne sr26 mov bp,7811 ; Maximum score sr26: add sp,6 ; Ignore values jmp short sr24 sr20: xlat cbw ; cmp sp,stack-(3+8+3+8+3+8+3+8+3)*2 ; 4-ply depth cmp sp,stack-(3+8+3+8+3+8+3)*2 ; 3-ply depth ; cmp sp,stack-(3+8+3+8+3)*2 ; 2-ply depth ; cmp sp,stack-(3+8+3)*2 ; 1-ply depth jbe sr22 pusha movsb ; Do move mov byte [si-1],ah ; Clear origin square call play mov bx,sp sub [bx+14],bp ; Substract BP from AX popa sr22: cmp bp,ax ; Better score? jg sr23 ; No, jump mov bp,ax ; New best score jne sr27 in al,(&40) cmp al,&55 ; Randomize it jb sr23 sr27: pop ax add sp,4 push si ; Save movement push di push ax sr23: pop ax ; Restore board mov [si],al mov [di],ah sr18: dec ax and al,&07 ; Was it pawn? jz sr11 ; Yes, check special cmp al,&04 ; Knight or king? jnc sr14 ; End sequence, choose next movement or ah,ah ; To empty square? jz sr9 ; Yes, follow line of squares sr16: jmp short sr14 sr11: and cl,&1f ; Advanced it first square? cmp cl,&10 jnz sr14 sr15: or ah,ah ; Pawn to empty square? jnz sr17 ; No, cancel double-square movement mov ax,si cmp al,&20 ; At first top row? jb sr14 ; Yes, jump cmp al,&60 ; At first bottom row? jb sr17 ; No, cancel double-square movement sr14: inc dh dec dl jnz sr12 sr17: inc si sr6: cmp si,board+120 jne sr7 pop di pop si cmp sp,stack-2 jne sr24 cmp bp,-16384 ; Illegal move? (always in check) jl sr24 ; Yes, doesn't move movsb mov byte [si-1],0 sr24: xor ch,8 ret display_board: ; Display board call display3 mov si,board sr4: lodsb mov bx,chars xlat call display2 sr5: cmp si,board+128 jnz sr4 ret key2: mov di,board+127 call key add di,ax call key shl al,4 sub di,ax ret key: push di mov ah,0 int &16 push ax call display pop ax and ax,&0f pop di ret display2: cmp al,&0d jnz display display3: add si,7 mov al,&0a call display mov al,&0d display: push si mov ah,&0e mov bh,&00 int &10 pop si ret initial: db 2,5,3,4,6,3,5,2 scores: db 0,10,50,30,90,30 chars: db ".prbqnk",&0d,".PRBQNK" offsets: db 14,18,8,12,8,0,8 total: db 4, 4,4, 4,8,8,8 displacement: db -33,-31,-18,-14,14,18,31,33 db -16,16,-1,1 db 15,17,-15,-17 db -16,-32 db 15,17,16,32 ; 29 bytes to say something db "Toledo Atomchess" db "nanochess.org" ; ; This marker is required for BIOS to boot floppy disk ; ds &7dfe-* ; Change to &02fe for COM file db &55,&aa board: ds 256 ds 256 stack: [FONT=arial][FONT=Verdana] end[/FONT][/FONT] Sursa: Toledo Atomchess Game

a12axis@hotmail.com 95.211.174.70 Muie.

Asta e prost. E ca si cum ar veni acum Italia sa zica ca jumatate din Europa e a lor pentru ca a apartinut Imperiului Roman.