Nytro

ExploitRemotingService © 2014 James Forshaw A tool to exploit .NET Remoting Services vulnerable to CVE-2014-1806 or CVE-2014-4149. It only works on Windows although some aspects might work in Mono on *nix. Usage Instructions: ExploitRemotingService [options] uri command [command args] Copyright © James Forshaw 2014 Uri: The supported URI are as follows: tcp://host:port/ObjName - TCP connection on host and portname ipc://channel/ObjName - Named pipe channel Options: -s, --secure Enable secure mode -p, --port=VALUE Specify the local TCP port to listen on -i, --ipc=VALUE Specify listening pipe name for IPC channel --user=VALUE Specify username for secure mode --pass=VALUE Specify password for secure mode --ver=VALUE Specify version number for remote, 2 or 4 --usecom Use DCOM backchannel instead of .NET remoting --remname=VALUE Specify the remote object name to register -v, --verbose Enable verbose debug output --useser Uses old serialization tricks, only works on full type filter services -h, -?, --help Commands: exec [-wait] program [cmdline]: Execute a process on the hosting server cmd cmdline : Execute a command line process and display stdout put localfile remotefile : Upload a file to the hosting server get remotefile localfile : Download a file from the hosting server ls remotedir : List a remote directory run file [args] : Upload and execute an assembly, calls entry point user : Print the current username ver : Print the OS version This tool supports exploit both TCP remoting services and local IPC services. To test the exploit you need to know the name of the .NET remoting service and the port it's listening on (for TCP) or the name of the Named Pipe (for IPC). You can normally find this in the server or client code. Look for things like calls to: RemotingConfiguration.RegisterWellKnownServiceType or Activator.CreateInstance You can then try the exploit by constructing an appropriate URL. If TCP you can use the URL format tcp://hostname:port/ServiceName. For IPC use ipc://NamedPipeName/ServiceName. A simple test is to do: ExploitRemotingService SERVICEURL ver If successful it should print the OS version of the hosting .NET remoting service. If you get an exception it might be fixed with CVE-2014-1806. At this point try the COM version using: ExploitRemotingService -usecom SERVICEURL ver This works best locally but can work remotely if you modify the COM configuration and disable the firewall you should be able to get it to work. If that still doesn't work then it might be an up to date server. Instead you can also try the full serialization version using. ExploitRemotingService -useser SERVICEURL ls c:\ For this to work the remoting service must be running with full typefilter mode enabled (which is some, especially IPC services). It also only works with the commands ls, put and get. But that should be enough to compromise a box. I've provided an example service to test against. Sursa: https://github.com/tyranid/ExploitRemotingService

Stupid is as Stupid Does When It Comes to .NET Remoting Finding vulnerabilities in .NET is something I quite enjoy, it generally meets my criteria of only looking for logic bugs. Probably the first research I did was into .NET serialization where I got some interesting results, and my first Blackhat USA presentation slot. One of the places where you could abuse serialization was in .NET remoting, which is a technology similar to Java RMI or CORBA to access .NET objects remotely (or on the same machine using IPC). Microsoft consider it a legacy technology and you shouldn't use it, but that won't stop people. One day I came to the realisation that while I'd talked about how dangerous it was I'd never released any public PoC for exploiting it. So I decided to start writing a simple tool to exploit vulnerable servers, that was my first mistake. As I wanted to fully understand remoting to write the best tool possible I decided to open my copy of Reflector, that was my second mistake. I then looked at the code, sadly that was my last mistake. TL;DR you can just grab the tool and play. If you want a few of the sordid details of CVE-2014-1806 and CVE-2014-4149 then read on. .NET Remoting Overview Before I can describe what the bug is I need to describe how .NET remoting works a little bit. Remoting was built into the .NET framework from the very beginning. It supports a pluggable architecture where you can replace many of the pieces, but I'm just going to concentrate on the basic implementation and what's important from the perspective of the bug. MSDN has plenty of resources which go into a bit more depth and there's always the official documentation MS-NRTP and MS-NRBF. A good description is available here. The basics of .NET remoting is you have a server class which is derived from the MarshalByRefObject class. This indicates to the .NET framework that this object can be called remotely. The server code can publish this server object using the remoting APIs such as RemotingConfiguration.RegisterWellKnownServiceType. On the client side a call can be made to APIs such as Activator.GetObject which will establish a transparent proxy for the Client. When the Client makes a call on this proxy the method information and parameters is packaged up into an object which implements the IMethodCallMessage interface. This object is sent to the server which processes the message, calls the real method and returns the return value (or exception) inside an object which implements the IMethodReturnMessage interface. When a remoting session is constructed we need to create a couple of Channels, a Client Channel for the client and a Server Channel for the server. Each channel contains a number of pluggable components called sinks. A simple example is shown below: The transport sinks are unimportant for the vulnerability. These sinks are used to actually transport the data in some form, for example as binary over TCP. The important things to concentrate on from the perspective of the vulnerabilities are the Formatter Sinks and the StackBuilder Sink. Formatter Sinks take the IMethodCallMessage or IMethodReturnMessage objects and format their contents so that I can be sent across the transport. It's also responsible for unpacking the result at the other side. As the operations are asymmetric from the channel perspective there are two different formatter sinks, IClientChannelSink and IServerChannelSink. While you can select your own formatter sink the framework will almost always give you a formatter based on the BinaryFormatter object which as we know can be pretty dangerous due to the potential for deserialization bugs. The client sink is implemented in BinaryClientFormatterSink and the server sink is BinaryServerFormatterSink. The StackBuilder sink is an internal only class implemented by the framework for the server. It's job is to unpack the IMethodCallMessage information, find the destination server object to call, verify the security of the call, calling the server and finally packaging up the return value into the IMethodReturnMessage object. This is a very high level overview, but we'll see how this all interacts soon. The Exploit Okay so on to the actual vulnerability itself, let's take a look at how the BinaryServerFormatterSink processes the initial .NET remoting request from the client in the ProcessMessage method: IMessage requestMsg; if (this.TypeFilterLevel != TypeFilterLevel.Full) { set = new PermissionSet(PermissionState.None); set.SetPermission( new SecurityPermission(SecurityPermissionFlag.SerializationFormatter)); } try { if (set != null) { set.PermitOnly(); } requestMsg = CoreChannel.DeserializeBinaryRequestMessage(uRI, requestStream, _strictBinding, TypeFilterLevel); } finally { if (set != null) { CodeAccessPermission.RevertPermitOnly(); } } We can see in this code that the request data from the transport is thrown into the DeserializeBinaryRequestMessage. The code around it is related to the serialization type filter level which I'll describe later. So what's the method doing? internal static IMessage DeserializeBinaryRequestMessage(string objectUri, Stream inputStream, bool bStrictBinding, TypeFilterLevel securityLevel) { BinaryFormatter formatter = CreateBinaryFormatter(false, bStrictBinding); formatter.FilterLevel = securityLevel; UriHeaderHandler handler = new UriHeaderHandler(objectUri); return (IMessage) formatter.UnsafeDeserialize(inputStream, new HeaderHandler(handler.HeaderHandler)); } For all intents and purposes it isn't doing a lot. It's passing the request stream to a BinaryFormatter and returning the result. The result is cast to an IMessage interface and the object is passed on for further processing. Eventually it ends up passing the message to the StackBuilder sink, which verifies the method being called is valid then executes it. Any result is passed back to the client. So now for the bug, it turns out that nothing checked that the result of the deserialization was a local object. Could we instead insert a remote IMethodCallMessage object into the serialized stream? It turns out yes we can. Serializing an object which implements the interface but also derived from MarshalByRefObject serializes an instance of an ObjRef class which points back to the client. But why would this be useful? Well it turns out there's a Time-of-Check Time-of-Use vulnerability if an attacker could return different results for the MethodBase property. By returning a MethodBase for Object.ToString (which is always allowed) as some points it will trick the server into dispatching the call. Now once the StackBuilder sink goes to dispatch the method we replace it with something more dangerous, say Process.Start instead. And you've just got arbitrary code to execute in the remoting service. In order to actually exploit this you pretty much need to implement most of the remoting code manually, fortunately it is documented so that doesn't take very long. You can repurpose the existing .NET BinaryFormatter code to do most of the other work for you. I'd recommand taking a look at the github project for more information on how this all works. So that was CVE-2014-1806, but what about CVE-2014-4149? Well it's the same bug, MS didn't fix the TOCTOU issue, instead they added a call to RemotingServices.IsTransparentProxy just after the deserialization. Unfortunately that isn't the only way you can get a remote object from deserialization. .NET supports quite extensive COM Interop and as luck would have it all the IMessage interfaces are COM accessible. So instead of a remoting object we instead inject a COM implementation of the IMethodCallMessage interface (which ironically can be written in .NET anyway). This works best locally as they you don't need to worry so much about COM authentication but it should work remotely. The final fix was to check if the object returned is an instance of MarshalByRefObject, as it turns out that the transparent COM object, System.__ComObject is derived from that class as well as transparent proxies. Of course if the service is running with a TypeFilterLevel set to Full then even with these fixes the service can still be vulnerable. In this case you can deserialize anything you like in the initial remoting request to the server. Then using reflecting object tricks you can capture FileInfo or DirectoryInfo objects which give access to the filesystem at the privileges of the server. The reason you can do this is these objects are both serializable and derive from MarshalByRefObject. So you can send them to the server serialized, but when the server tries to reflect them back to the client it ends up staying in the server as a remote object. Real-World Example Okay let's see this in action in a real world application. I bought a computer a few years back which had pre-installed the Intel Rapid Storage Technology drivers version 11.0.0.1032 (the specific version can be downloaded here). This contains a vulnerable .NET remoting server which we can exploit locally to get local system privileges. A note before I continue, from what I can tell the latest versions of these drivers no longer uses .NET remoting for the communication between the user client and the server so I've never contacted Intel about the issue. That said there's no automatic update process so if, like me you had the original insecure version installed well you have a trivial local privilege escalation on your machine Bringing up Reflector and opening the IAStorDataMgrSvc.exe application (which is the local service) we can find the server side of the remoting code below: public void Start() { BinaryServerFormatterSinkProvider serverSinkProvider new BinaryServerFormatterSinkProvider { TypeFilterLevel = TypeFilterLevel.Full }; BinaryClientFormatterSinkProvider clientSinkProvider = new BinaryClientFormatterSinkProvider(); IdentityReferenceCollection groups = new IdentityReferenceCollection(); IDictionary properties = new Hashtable(); properties["portName"] = "ServerChannel"; properties["includeVersions"] = "false"; mChannel = new IpcChannel(properties, clientSinkProvider, serverSinkProvider); ChannelServices.RegisterChannel(mChannel, true); mServerRemotingRef = RemotingServices.Marshal(mServer, "Server.rem", typeof(IServer)); mEngine.Start(); } So there's a few thing to note about this code, it is using IpcChannel so it's going over named pipes (reasonable for a local service). It's setting the portName to ServerChannel, this is the name of the named pipe on the local system. It then registers the channel with the secure flag set to True and finally it configures an object with the known name of Server.rem which will be exposed on the channel. Also worth nothing it is setting the TypeFilterLevel to Full, we'll get back to that in a minute. For exploitation purposes therefore we can build the service URL as ipc://ServerChannel/Server.rem. So let's try sending it a command. In this case I had updated for the fix to CVE-2014-1806 but not for CVE-2014-4149 so we need to pass the -usecom flag to use a COM return channel. Well that was easy, direct code execution at local system privileges. But of course if we now update to the latest version it will stop working again. Fortunately though I highlighted that they were setting the TypeFilterLevel to Full. This means we can still attack it using arbitrary deserialization. So let's try and do that instead: In this case we know the service's directory and can upload our custom remoting server to the same directory the server executes from. This allows us to get full access to the system. Of course if we don't know where the server is we can still use the -useser flag to list and modify the file system (with the privileges of the server) so it might still be possible to exploit even if we don't know where the server is running from. Mitigating Against Attacks I can't be 100% certain there aren't other ways of exploiting this sort of bug, at the least I can't rule out bypassing the TypeFilterLevel stuff through one trick or another. Still there are definitely a few ways of mitigating it. One is to not use remoting, MS has deprecated the technology for WCF, but it isn't getting rid of it yet. If you have to use remoting you could use secure mode with user account checking. Also if you have complete control over the environment you could randomise the service name per-deployment which would at least prevent mass exploitation. An outbound firewall would also come in handy to block outgoing back channels. Posted by tiraniddo at 15:14 Sursa: Tyranid's Lair: Stupid is as Stupid Does When It Comes to .NET Remoting

phpBB <= 3.1.1 deregister_globals() Function Bypass phpBB <= 3.1.1 deregister_globals() Function Bypass Taoguang Chen <[@chtg](http://github.com/chtg)> - 2014.11.18 When PHP's register_globals configuration directive set on, phpBB will call deregister_globals() function, all global variables registered by PHP will be destroyed. But deregister_globals() functions can be bypassed. ``` $input = array_merge( array_keys($_GET), array_keys($_POST), array_keys($_COOKIE), array_keys($_SERVER), array_keys($_SESSION), array_keys($_ENV), array_keys($_FILES) ); foreach ($input as $varname) { if (isset($not_unset[$varname])) { if ($varname !== 'GLOBALS' || isset($_GET['GLOBALS']) || isset($_POST['GLOBALS']) || isset($_SERVER['GLOBALS']) || isset($_SESSION['GLOBALS']) || isset($_ENV['GLOBALS']) || isset($_FILES['GLOBALS'])) { exit; } else { $cookie = &$_COOKIE; while (isset($cookie['GLOBALS'])) { if (!is_array($cookie['GLOBALS'])) { break; } .... } } unset($GLOBALS[$varname]); } ``` In the above code we see, when request $_COOKIE['GLOBALS'] = 1, $GLOBALS['GLOBALS'] will be destroyed by unset(). This means $GLOBALS array will be destroyed. This also means you will not be able to use $GLOBALS['key'] to access or control a global variable in all scopes throughout a script. Because the binding between the $GLOBALS array and the global symbol table has been broken. All global variables registered by PHP form $_COOKIE, $_SERVER, $_SESSION, $_ENV, and $_FILES arrays will be not unregistered. Proof of Concept ``` $_COOKIE['GLOBALS'] = 1; $_COOKIE['ryat'] = $ryat = 'ryat'; deregister_globals(); var_dump($GLOBALS); var_dump($ryat); $GLOBALS['ryat'] = 'hi'; var_dump($GLOBALS); var_dump($ryat); ``` P.S. I had reported the issue to the phpBB developers, but they do not consider this a security issue. Sursa: http://80vul.com/phpbb/vul.txt

[h=2]The Backdoor Factory (BDF)[/h] For security professionals and researchers only. The goal of BDF is to patch executable binaries with user desired shellcode and continue normal execution of the prepatched state. DerbyCon 2014 Presentation: Contact the developer on: IRC: irc.freenode.net #BDFactory Twitter: @Midnite_runr Under a BSD 3 Clause License See the wiki: https://github.com/secretsquirrel/the-backdoor-factory/wiki Dependences: Capstone, using the 'next' repo until it is the 'master' repo: https://github.com/aquynh/capstone/tree/next Pefile, most recent: https://code.google.com/p/pefile/ INSTALL: ./install.sh This will install Capstone with the 'next' repo and use pip to install pefile. UPDATE: ./update.sh Supporting: Windows PE x86/x64,ELF x86/x64 (System V, FreeBSD, ARM Little Endian x32), and Mach-O x86/x64 and those formats in FAT files Packed Files: PE UPX x86/x64 Experimental: OpenBSD x32 Some executables have built in protections, as such this will not work on all binaries. It is advisable that you test target binaries before deploying them to clients or using them in exercises. I'm on the verge of bypassing NSIS, so bypassing these checks will be included in the future. Many thanks to Ryan O'Neill --ryan 'at' codeslum <d ot> org-- Without him, I would still be trying to do stupid things with the elf format. Also thanks to Silvio Cesare with his 1998 paper (Silvio Cesare 'Unix ELF parasites and virus' (VX heaven)) which these ELF patching techniques are based on. From DerbyCon: Video: Injection Module Demo: Slides: Patching Windows Executables with the Backdoor Factory | DerbyCon 2013 Sursa: https://github.com/secretsquirrel/the-backdoor-factory

Regin: Giving IT security reason to hope NSA is waaaay ahead on malware Computerworld | Nov 24, 2014 11:20 AM PT Security pros don't need screaming headlines to put them on alert about a dangerous new piece of malware."New" and "present" are usually enough to do it, though "stealthy" and "nasty" will open their eyes a little wider. So think what the impact would be of this snippet about a new bit of malware called Regin that Symantec Corp. announced over the weekend: "In the world of malware threats, only a few rare examples can truly be considered groundbreaking and almost peerless," reads the opening sentence of Symantec's white paper on Regin." What we have seen in Regin is just such a class of malware." The phrase "class of malware," in this case referred to the sophistication level of the software, not its origin or intent – which appears to be long-term corporate and political espionage committed by a major national intelligence agency. Regin's architecture is so complex and programming so sophisticated, Symantec researchers concluded, that it is most likely to have been developed by a state-sponsored intelligence agency like the NSA or CIA, rather than hackers or malware writers motivated by profit or commercial developers such as the Italian company Hacking Team that sell software designed for espionage to governments and law enforcement agencies worldwide. Far more important than the polish or architecture on the newly discovered malware, however, is the consistency in targets and approach, which are similar to those of previously identified apps designed for international espionage and sabotage including Stuxnet, Duqu, Flamer, Red October and Weevil – all of which have been blamed on the U.S. National Security Agency or CIA, though only Stuxnet has been confirmed to have been developed by the U.S "Its capabilities and the level of resources behind Regin indicate that it is one of the main cyber-espionage tools used by a nation state," according to Symantec's report, which did not suggest which state might have been responsible. But who? "The best clues we have are where the infections have occurred and where they have not," Symantec researcher Liam O'Murchu told Re/Code in an interview yesterday. There have been no Regin attacks on either China or the U.S. Russia was the target of 28 percent of attacks; Saudi Arabia (a U.S. ally with which relations are often tense) was the target of 24 percent of Regin attacks. Mexico and Ireland each netted 9 percent of attacks. India, Afghanistan, Iran, Belgium, Austria and Pakistan got 5 percent apiece, according to Symantec's breakdown. Nearly half of attacks were aimed at "private individuals and small businesses;" telecom and Internet backbone companies were the target of 28 percent of attacks, though they likely served only as a way for Regin to get to businesses it had actually targeted, O'Murchu told Re/Code. "It looks like it comes from a Western organization," Symantec researcher Sian John told the BBC. "It's the level of skill and expertise, the length of time over which it was developed." The approach of Regin resembles Stuxnet less than it does Duqu, a sly, shape-shifting Trojan designed to "steal everything" according to a 2012 Kaspersky Lab analysis. One consistent feature that led to John's conclusion is the hide-and-stay-resident design of Regin, which is consistent for an organization wanting to monitor an infected organization for years rather than penetrate, grab a few files and move on to the next target – a pattern that is more consistent with the approach of the known cyberspy organizations of China's military than with that of the U.S. Stuxnet and Duqu showed obvious similarities in design China's cyberespionage style is much more smash-and-grab, according to security firm FireEye, Inc., whose 2013 report "APT 1: Exposing One of China's Cyber Espionage Units" detailed a persistent pattern of attack using malware and spear phishing that allowed one unit of the People's Liberation Army to steal "hundreds of terabytes of data from at least 141 organizations." It's unlikely the incredibly obvious attacks of PLA Unit 61398 – five of whose officers were the subject of an unprecedented espionage indictment of active-duty members of a foreign military by the U.S. Department of Justice earlier this year – are the only cyberspies in China, or that its lack of subtlety is characteristic of all Chinese cyberespionage efforts. Though its efforts at cyberespionage are less well known than those of either the U.S. or China, Russia has a healthy cyber-spy and malware-producing operation of its own. Malware known as APT28 has been traced to "a government sponsor based in Moscow," according to an October, 2014 report from FireEye. The report described APT28 as "collecting intelligence that would be useful to a government," meaning data on foreign militaries, governments and security organizations, especially those of former Soviet Bloc countries and NATO installations. The important thing about Regin – at least to corporate infosecurity people – is that the risk that it will be used to attack any U.S.-based corporation is low. The important thing to everyone else is that Regin is another bit of evidence of an ongoing cyberwar among the big three superpowers and a dozen or so secondary players, all of whom want to demonstrate they've got game online, none of which want a demonstration so extravagant it will expose all their cyber powers or prompt a physical attack in response to a digital one. It also pushes the envelope of what we knew was possible from a bit of malware whose primary goal is to remain undetected so it can spy for a long time. The ways it accomplishes that are easily clever enough to inspire admiration of its technical accomplishments – but only from those who don't have to worry about having to detect, fight or eradicate malware that qualifies for the same league and Regin and Stuxnet and Duqu, but plays for another team. Sursa: Regin: Giving IT security reason to hope NSA is waaaay ahead on malware | Computerworld

Highly advanced backdoor trojan cased high-profile targets for years "Backdoor Regin" bears a resemblance to Stuxnet, was developed by a wealthy nation. by Dan Goodin - Nov 23 2014, 7:01pm GTBST Enlarge / The five stages of Regin. Symantec Researchers have unearthed highly advanced malware they believe was developed by a wealthy nation-state to spy on a wide range of international targets in diverse industries, including hospitality, energy, airline, and research. Backdoor Regin, as researchers at security firm Symantec are referring to the trojan, bears some resemblance to previously discovered state-sponsored malware, including the espionage trojans known as Flame and Duqu, as well as Stuxnet, the computer worm and trojan that was programmed to disrupt Iran's nuclear program. Regin likely required months or years to be completed and contains dozens of individual modules that allowed its operators to tailor the malware to individual targets. To remain stealthy, the malware is organized into five stages, each of which is encrypted except for the first one. Executing the first stage triggers a domino chain in which the second stage is decrypted and executed, and that in turn decrypts the third stage, and so on. Analyzing and understanding the malware requires researchers to acquire all five stages. Regin contains dozens of payloads, including code for capturing screenshots, seizing control of an infected computer's mouse, stealing passwords, monitoring network traffic, and recovering deleted files. Other modules appear to be tailored to specific targets. One such payload included code for monitoring the traffic of a Microsoft IIS server. Another sniffed the traffic of mobile telephone base station controllers. Symantec researchers believe Regin was a sprawling framework that was used in multiple campaigns that data back to 2008 and possibly several years earlier. Liam O'Murchu, manager of operations for Symantec Security Response, told Ars that the roster of modules used against one target was often unique, an indication that Regin was used in multiple campaigns. "Essentially, what we think we're looking at is different campaigns where in one infection they needed to sniff your keyboard whereas in another infection they wanted grab the user name and password of the admin connected to a base station controller," O'Murchu said. While almost half of the computers known to be infected by Regin were inside Internet service providers, Symantec believes they were attacked so the operators could spy on specific customers who used the ISPs. Similarly, telecommunication backbone providers, which at 28 percent accounted for the second biggest category of infected computers, were likely chosen so attackers could gain access to calls being routed through their infrastructure. There is still much Symantec doesn't know about Regin. So far, company researchers are aware of only about 100 infections, a number that seems small for such a sprawling framework of malware. The researchers have yet to uncover the command and control system the attackers used to communicate with infected computers, and they still don't have any educated hunches about the country behind the malware. The malware is known to have been active from 2008 until 2011, when it was abruptly pulled by its operators for unknown reasons. Regin, which is the name Microsoft assigned to the underlying trojan, resurfaced in 2013. Symantec researchers became aware of the malware in December of that year. Sursa: Highly advanced backdoor trojan cased high-profile targets for years | Ars Technica

UK, US behind Regin malware, attacked European Union networks Summary: Two governments working together are said to have developed the state-sponsored malware that attacked the European Union. Guess what? One of the makers was an EU country. By Zack Whittaker for Zero Day | November 24, 2014 -- 18:12 GMT (10:12 PST) Blame the British and American spy agencies for the latest state-sponsored malware attack, say reporters at The Intercept. The publication, which in the wake of Glenn Greenwald's departure from The Guardian continued to publish documents leaked by Edward Snowden, said on Monday the recently discovered malware, known as Regin, was used against targets in the European Union. One of those targets included Belgian telecommunications company Belgacom, which had its networks broken into by the British spy agency the Government Communications Headquarters (GCHQ). Regin was first publicly talked about over the weekend after Symantec discovered the "sophisticated" malware, though is understood to have been in circulation since 2008. Compared to Stuxnet, the state-sponsored malware whose creators have never been confirmed, the recently-discovered trojan steals data from machines and networks it infects, disguised as Microsoft software. Some began to point the finger at Russia and China, but these were quickly discounted by industry experts. Others suspected the U.S. and Israel — a deal already exists that allows the Middle Eastern allied state to access raw and "unchecked" U.S. collected intelligence. They weren't far off. According to Monday's report, the U.S. working in conjunction with Britain, a European member state (though perhaps not for much longer) attacked Belgacom using the Regin malware. Though the Belgacom hack was disclosed by Snowden's leaks, the malware used had never been revealed. The new details from The Intercept show how GCHQ embarked upon its "hacking mission," known as Operation Socialist, by accessing Belgacom's networks in 2010. By targeting engineers through a faked LinkedIn page, GCHQ was able to get deep inside the Internet provider to steal data. One of Belgacom's main clients was the European Commission, the European Parliament, and the European Council of member state leaders. Exactly how member states of the European Union — there are 28 of them including the U.K. — will react to one of its own member states launching a successful hacking attack against their executive body, remains unknown. But while members of the Parliament and Commission staff have, over the years, seen the U.S. as one of the greatest threats to the region's data protection and privacy policies, they should have been looking a little closer to home. Sursa: UK, US behind Regin malware, attacked European Union networks | ZDNet

Secret Malware in European Union Attack Linked to U.S. and British Intelligence By Morgan Marquis-Boire, Claudio Guarnieri, and Ryan Gallagher Complex malware known as Regin is the suspected technology behind sophisticated cyberattacks conducted by U.S. and British intelligence agencies on the European Union and a Belgian telecommunications company, according to security industry sources and technical analysis conducted by The Intercept. Regin was found on infected internal computer systems and email servers at Belgacom, a partly state-owned Belgian phone and internet provider, following reports last year that the company was targeted in a top-secret surveillance operation carried out by British spy agency Government Communications Headquarters, industry sources told The Intercept. The malware, which steals data from infected systems and disguises itself as legitimate Microsoft software, has also been identified on the same European Union computer systems that were targeted for surveillance by the National Security Agency. The hacking operations against Belgacom and the European Union were first revealed last year through documents leaked by NSA whistleblower Edward Snowden. The specific malware used in the attacks has never been disclosed, however. The Regin malware, whose existence was first reported by the security firm Symantec on Sunday, is among the most sophisticated ever discovered by researchers. Symantec compared Regin to Stuxnet, a state-sponsored malware program developed by the U.S. and Israel to sabotage computers at an Iranian nuclear facility. Sources familiar with internal investigations at Belgacom and the European Union have confirmed to The Intercept that the Regin malware was found on their systems after they were compromised, linking the spy tool to the secret GCHQ and NSA operations. Ronald Prins, a security expert whose company Fox IT was hired to remove the malware from Belgacom’s networks, told The Intercept that it was “the most sophisticated malware” he had ever studied. “Having analyzed this malware and looked at the [previously published] Snowden documents,” Prins said, “I’m convinced Regin is used by British and American intelligence services.” A spokesman for Belgacom declined to comment specifically about the Regin revelations, but said that the company had shared “every element about the attack” with a federal prosecutor in Belgium who is conducting a criminal investigation into the intrusion. “It’s impossible for us to comment on this,” said Jan Margot, a spokesman for Belgacom. “It’s always been clear to us the malware was highly sophisticated, but ever since the clean-up this whole story belongs to the past for us.” In a hacking mission codenamed Operation Socialist, GCHQ gained access to Belgacom’s internal systems in 2010 by targeting engineers at the company. The agency secretly installed so-called malware “implants” on the employees’ computers by sending their internet connection to a fake LinkedIn page. The malicious LinkedIn page launched a malware attack, infecting the employees’ computers and giving the spies total control of their systems, allowing GCHQ to get deep inside Belgacom’s networks to steal data. The implants allowed GCHQ to conduct surveillance of internal Belgacom company communications and gave British spies the ability to gather data from the company’s network and customers, which include the European Commission, the European Parliament, and the European Council. The software implants used in this case were part of the suite of malware now known as Regin. One of the keys to Regin is its stealth: To avoid detection and frustrate analysis, malware used in such operations frequently adhere to a modular design. This involves the deployment of the malware in stages, making it more difficult to analyze and mitigating certain risks of being caught. Based on an analysis of the malware samples, Regin appears to have been developed over the course of more than a decade; The Intercept has identified traces of its components dating back as far as 2003. Regin was mentioned at a recent Hack.lu conference in Luxembourg, and Symantec’s report on Sunday said the firm had identified Regin on infected systems operated by private companies, government entities, and research institutes in countries such as Russia, Saudi Arabia, Mexico, Ireland, Belgium, and Iran. The use of hacking techniques and malware in state-sponsored espionage has been publicly documented over the last few years: China has been linked to extensive cyber espionage, and recently the Russian government was also alleged to have been behind a cyber attack on the White House. Regin further demonstrates that Western intelligence agencies are also involved in covert cyberespionage. GCHQ declined to comment for this story. The agency issued its standard response to inquiries, saying that “it is longstanding policy that we do not comment on intelligence matters” and “all of GCHQ’s work is carried out in accordance with a strict legal and policy framework, which ensures that our activities are authorised, necessary and proportionate.” The NSA said in a statement, “We are not going to comment on The Intercept’s speculation.” The Intercept has obtained samples of the malware from sources in the security community and is making it available for public download in an effort to encourage further research and analysis. (To download the malware, click here. The file is encrypted; to access it on your machine use the password “infected.”) What follows is a brief technical analysis of Regin conducted by The Intercept’s computer security staff. Regin is an extremely complex, multi-faceted piece of work and this is by no means a definitive analysis. In the coming weeks, The Intercept will publish more details about Regin and the infiltration of Belgacom as part of an investigation in partnership with Belgian and Dutch newspapers De Standaard and NRC Handelsblad. Origin of Regin In Nordic mythology, the name Regin is associated with a violent dwarf who is corrupted by greed. It is unclear how the Regin malware first got its name, but the name appeared for the first time on the VirusTotal website on March 9th 2011. Der Spiegel reported that, according to Snowden documents, the computer networks of the European Union were infiltrated by the NSA in the months before the first discovery of Regin. Industry sources familiar with the European Parliament intrusion told The Intercept that such attacks were conducted through the use of Regin and provided samples of its code. This discovery, the sources said, may have been what brought Regin to the wider attention of security vendors. Also on March 9th 2011, Microsoft added related entries to its Malware Encyclopedia: Alert level: Severe First detected by definition: 1.99.894.0 Latest detected by definition: 1.173.2181.0 and higher First detected on: Mar 09, 2011 This entry was first published on: Mar 09, 2011 This entry was updated on: Not available Two more variants of Regin have been added to the Encyclopedia, Regin.B and Regin.C. Microsoft appears to detect the 64-bit variants of Regin as Prax.A and Prax.B. None of the Regin/Prax entries are provided with any sort of summary or technical information. The following Regin components have been identified: Loaders The first stage are drivers which act as loaders for a second stage. They have an encrypted block which points to the location of the 2nd stage payload. On NTFS, that is an Extended Attribute Stream; on FAT, they use the registry to store the body. When started, this stage simply loads and executes Stage 2. The Regin loaders that are disguised as Microsoft drivers with names such as: serial.sys cdaudio.sys atdisk.sys parclass.sys usbclass.sys Mimicking Microsoft drivers allows the loaders to better disguise their presence on the system and appear less suspicious to host intrusion detection systems. Second stage loader When launched, it cleans traces of the initial loader, loads the next part of the toolkit and monitors its execution. On failure, Stage 2 is able to disinfect the compromised device. The malware zeroes out its PE (Portable Executable, the Windows executable format) headers in memory, replacing “MZ” with its own magic marker 0xfedcbafe. Orchestrator This component consists of a service orchestrator working in Windows’ kernel. It initializes the core components of the architecture and loads the next parts of the malware. Information Harvesters This stage is composed of a service orchestrator located in user land, provided with many modules which are loaded dynamically as needed. These modules can include data collectors, a self-defense engine which detects if attempts to detect the toolkit occur, functionality for encrypted communications, network capture programs, and remote controllers of different kinds. Stealth Implant The Intercept’s investigation revealed a sample uploaded on VirusTotal on March 14th 2012 that presents the unique 0xfedcbafe header, which is a sign that it might have been loaded by a Regin driver and it appears to provide stealth functionality for the tool kit. This picture shows the very first bytes of the sample in question, showing the unique 0xfedcbafe header at the beginning. In order to access information stored in the computer’s memory, programs use objects that reference specific locations in memory called pointers. This binary file contains some of such pointers initialized, which corroborates the hypothesis that the file was dumped from memory during a forensic analysis of a compromised system. The sample has the following SHA256 hash: fe1419e9dde6d479bd7cda27edd39fafdab2668d498931931a2769b370727129 This sample gives a sense of the sophistication of the actors and the length of the precautions they have been taking in order to operate as stealthily as possible. When a Windows kernel driver needs to allocate memory to store some type of data, it creates so called kernel pools. Such memory allocations have specific headers and tags that are used to identify the type of objects contained within the block. For example such tags could be Proc, Thrd or File, which respectively indicate that the given block would contain a process, thread or file object structure. When performing forensic analysis of a computer’s memory, it is common to use a technique called pool scanning to parse the kernel memory, enumerate such kernel pools, identify the type of content and extract it. Just like Regin loader drivers, this driver repeatedly uses the generic “Ddk “ tag with ExAllocatePoolWithTag() when allocating all kernel pools: This picture shows the use of the “ddk “ tag when allocating memory with the Windows ExAllocatePoolWIthTag() function. The generic tag which is used throughout the operating system when a proper tag is not specified. This makes it more difficult for forensic analysts to find any useful information when doing pool scanning, since all its memory allocations will mix with many generic others. In addition, when freeing memory using ExFreePool(), the driver zeroes the content, probably to avoid leaving traces in pool memory. The driver also contains routines to check for specific builds of the Windows kernel in use, including very old versions such as for Windows NT4 Terminal Server and Windows 2000, and then adapts its behavior accordingly. Windows kernel drivers operate on different levels of priority, from the lowest PASSIVE_LEVEL to the highest HIGH_LEVEL. This level is used by the processor to know what service give execution priority to and to make sure that the system doesn’t try to allocate used resources which could result in a crash. This Regin driver recurrently checks that the current IRQL (Interrupt Request Level) is set to PASSIVE_LEVEL using the KeGetCurrentIrql() function in many parts of the code, probably in order to operate as silently as possible and to prevent possible IRQL confusion. This technique is another example of the level of precaution the developers took while designing this malware framework. Upon execution of the unload routine (located at 0xFDEFA04A), the driver performs a long sequence of steps to remove remaining traces and artifacts. Belgacom Sample In an interview given to the Belgian magazine MondiaalNiews, Fabrice Clément, head of security of Belgacom, said that the company first identified the attack on June 21, 2013. In the same interview Clément says that the computers targeted by the attackers included staff workstations as well as email servers. These statements confirm the timing and techniques used in the attack. From previously identified Regin samples, The Intercept developed unique signatures which could identify this toolkit. A zip archive with a sample identified as Regin/Prax was found in VirusTotal, a free, online website which allows people to submit files to be scanned by several anti-virus products. The zip archive was submitted on 2013-06-21 07:58:37 UTC from Belgium, the date identified by Clément. Sources familiar with the Belgacom intrusion told The Intercept that this sample was uploaded by a systems administrator at the company, who discovered the malware and uploaded it in an attempt to research what type of malware it was. The archive contains: Along with other files The Intercept found the output of a forensic tool, GetThis, which is being run on target systems looking for malware. From the content of the GetThis.log file, we can see that a sample called “svcsstat.exe” and located in C:\Windows\System32\ was collected and a copy of it was stored. The malware in question is “0001000000000C1C_svcsstat.exe_sample ”. This is a 64bit variant of the first stage Regin loader aforementioned. The archive also contains the output of ProcMon, “Process Monitor”, a system monitoring tool distributed by Microsoft and commonly used in forensics and intrusion analysis. This file identifies the infected system and provides a variety of interesting information about the network. For instance: USERDNSDOMAIN=BGC.NET USERDOMAIN=BELGACOM USERNAME=id051897a USERPROFILE=C:\Users\id051897a The following environment variable shows that the system was provided with a Microsoft SQL server and a Microsoft Exchange server, indicating that it might one of the compromised corporate mail server Fabrice Clément mentioned to Mondiaal News: Path=C:\Program Files\Legato\nsr\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files\Microsoft Network Monitor 3\;C:\Program Files\System Center Operations Manager 2007\;c:\Program Files (x86)\Microsoft SQL Server\90\Tools\binn\;D:\Program Files\Microsoft\Exchange Server\bin Below is a list of hashes for the files The Intercept is making available for download. Given that that it has been over a year since the Belgacom operation was publicly outed, The Intercept considers it likely that the GCHQ/NSA has replaced their toolkit and no current operations will be affected by the publication of these samples. Regin Samples 32-bit Loaders 20831e820af5f41353b5afab659f2ad42ec6df5d9692448872f3ed8bbb40ab92 7553d4a5914af58b23a9e0ce6a262cd230ed8bb2c30da3d42d26b295f9144ab7 f89549fc84a8d0f8617841c6aa4bb1678ea2b6081c1f7f74ab1aebd4db4176e4 fd92fd7d0f925ccc0b4cbb6b402e8b99b64fa6a4636d985d78e5507bd4cfecef 225e9596de85ca7b1025d6e444f6a01aa6507feef213f4d2e20da9e7d5d8e430 9cd5127ef31da0e8a4e36292f2af5a9ec1de3b294da367d7c05786fe2d5de44f b12c7d57507286bbbe36d7acf9b34c22c96606ffd904e3c23008399a4a50c047 f1d903251db466d35533c28e3c032b7212aa43c8d64ddf8c5521b43031e69e1e 4e39bc95e35323ab586d740725a1c8cbcde01fe453f7c4cac7cced9a26e42cc9 a0d82c3730bc41e267711480c8009883d1412b68977ab175421eabc34e4ef355 a7493fac96345a989b1a03772444075754a2ef11daa22a7600466adc1f69a669 5001793790939009355ba841610412e0f8d60ef5461f2ea272ccf4fd4c83b823 a6603f27c42648a857b8a1cbf301ed4f0877be75627f6bbe99c0bfd9dc4adb35 8d7be9ed64811ea7986d788a75cbc4ca166702c6ff68c33873270d7c6597f5db 40c46bcab9acc0d6d235491c01a66d4c6f35d884c19c6f410901af6d1e33513b df77132b5c192bd8d2d26b1ebb19853cf03b01d38afd5d382ce77e0d7219c18c 7d38eb24cf5644e090e45d5efa923aff0e69a600fb0ab627e8929bb485243926 a7e3ad8ea7edf1ca10b0e5b0d976675c3016e5933219f97e94900dea0d470abe a0e3c52a2c99c39b70155a9115a6c74ea79f8a68111190faa45a8fd1e50f8880 d42300fea6eddcb2f65ffec9e179e46d87d91affad55510279ecbb0250d7fdff 5c81cf8262f9a8b0e100d2a220f7119e54edfc10c4fb906ab7848a015cd12d90 b755ed82c908d92043d4ec3723611c6c5a7c162e78ac8065eb77993447368fce c0cf8e008fbfa0cb2c61d968057b4a077d62f64d7320769982d28107db370513 cca1850725f278587845cd19cbdf3dceb6f65790d11df950f17c5ff6beb18601 ecd7de3387b64b7dab9a7fb52e8aa65cb7ec9193f8eac6a7d79407a6a932ef69 e1ba03a10a40aab909b2ba58dcdfd378b4d264f1f4a554b669797bbb8c8ac902 392f32241cd3448c7a435935f2ff0d2cdc609dda81dd4946b1c977d25134e96e 9ddbe7e77cb5616025b92814d68adfc9c3e076dddbe29de6eb73701a172c3379 8389b0d3fb28a5f525742ca2bf80a81cf264c806f99ef684052439d6856bc7e7 32-bit Rootkit fe1419e9dde6d479bd7cda27edd39fafdab2668d498931931a2769b370727129 32-bit Orchestrator e420d0cf7a7983f78f5a15e6cb460e93c7603683ae6c41b27bf7f2fa34b2d935 4139149552b0322f2c5c993abccc0f0d1b38db4476189a9f9901ac0d57a656be 64-bit Loader (Belgacom) 4d6cebe37861ace885aa00046e2769b500084cc79750d2bf8c1e290a1c42aaff Photo credit: Winfried Rothermel/AP Sursa: https://firstlook.org/theintercept/2014/11/24/secret-regin-malware-belgacom-nsa-gchq/

[h=1]Adrien de Beaupre - Making Pen-Testing Analysis Sexy[/h] n-PUPDQ0H&index=6Publicat pe 24 nov. 2014 This talk was recorded at BSides Winnipeg 2013. More information can be found at BSides Winnipeg 2013. This presentation will discuss information security penetration testing methodology, and how portions of the test process may be automated. The analysis of test results can be made more efficient through development of additional tools to assist the analyst. The Open Source Security Assessment Management System (OSSAMS) will be presented, which is a framework for the automation, data collection, analysis, and reporting in penetration testing and vulnerability assessment efforts. OSSAMS is written in Python and allows for the processing of tool results, parsing and normalizing the data, extraction of meaningful information via query, and more effective analysis. Adrien is a senior Information Security Consultant with Intru-Shun.ca Inc., experienced in penetration testing and incident response. He also holds the ISC2 CISSP, GXPN (GIAC Exploit Researcher and Advanced Penetration Tester), GWAPT (GIAC Web Application Penetration Tester), GPEN (GIAC Penetration Tester), GCIH (GIAC Certified Incident Handler), GCIA (GIAC Certified Intrusion Analyst), GSEC (GIAC Security Essentials), OPST (OSSTMM Professional Security Tester), and OPSA (OSSTMM Professional Security Analyst) certifications. As a volunteer member of the SANS Internet Storm Center (isc.sans.edu) he performs incident handling and threat analysis duties. When not geeking out Adrien can be found with his family, or at the dojo.

[h=1]Michael Zapp - SSD Security Risks[/h] n-PUPDQ0H&index=7Publicat pe 24 nov. 2014 This talk was recorded at BSides Winnipeg 2013. More information can be found at BSides Winnipeg 2013. Solid state storage devices provide many performance improvements but they also change how data is managed at the physical layer. Those changes lead to new opportunities for the extraction of sensitive data. This talk will outline how SSDs work, how they are managed, how this can be exploited, and what we can do to mitigate the risks. Michael is a Senior Instructor in the Department of Computer Science at the University of Manitoba. In addition to being the best Computer Science instructor around (opinions may differ), he has developed a number of vehicular embedded systems, including transmission controllers and instrument clusters. Michael also developed a go kart engine controller that receives commands via a custom designed handheld device, over a radio protocol of his own design.

[h=1]Michael Legary - NFC & RFID Harvesting for REDACTED[/h] n-PUPDQ0H&index=8Publicat pe 24 nov. 2014 This talk was recorded at BSides Winnipeg 2013. More information can be found at BSides Winnipeg 2013. Mike will discuss areas of experimentation and research for NFC and RFID harvesting including the best ways to make your own long range antennas for NFC reading, and the most interesting hardware builds that you can create to harvest data for close or wide range target applications. Physical hardware examples will be made available throughout the day for experimentation. Michael is an entrepreneur in the security industry who focuses on innovative approaches to building things that secure large enterprise. As a security practitioner, Michael spends his time on researching topics that impact security architecture, risk assessment and forensic procedure, working with folks across the globe to try making things better one day at a time.

[h=1]Mark Jenkins - Auditable Offline Bitcoin Wallet Implementation[/h] n-PUPDQ0H&index=11Publicat pe 24 nov. 2014 This talk was recorded at BSides Winnipeg 2013. More information can be found at BSides Winnipeg 2013. Motivations for operating an offline bitcoin wallet will be explained and security risks associated with obtaining and relying on such software will be examined. The practicality of performing software audits will be discussed, with the size of Armory's code as an example. A small, offline bitcoin wallet implementation will be demonstrated and auditability examined. The presentation will conclude with the potential useful role for self-programmable retro computers under more paranoid circumstances.

[h=1]Richard Rodd & Chris Otto - USB: A Look Inside[/h] Publicat pe 24 nov. 2014 This talk was recorded at BSides Winnipeg 2013. More information can be found at BSides Winnipeg 2013. This talk will be an introduction to the USB protocol at the packet level, leading into an overview of a hardware device that sniffs the USB data of a connection by sitting on the wire between the two endpoints - host and device. Also covered will be the analysis of a USB device through PCAP analysis. Richard has his P. Eng., and is an instructor at the University of Manitoba's School of Medical Rehabilitation. While his courses and research are primarily in the field of assistive technology, information security and reverse engineering have been of interest to him since his early days of programming on the TRS-80, Commodore VIC-20, and Apple IIe. Chris is a senior developer at Novra Technologies in Winnipeg. He has over 15 years of experience, both personal and professional, designing and developing various systems and products ranging from embedded controllers and interfaces, mobile Android application development, to developing parts of DB2.

Link: https://nsa.gov1.info/dni/nsa-ant-catalog/index.html

L-am descarcat si ma uit peste el. Pare scris cu picioarele. Un jeg. Dar il testam si daca pare ok il lasam.

Regin: Nation-state ownage of GSM networks "Beware of Regin, the master! His heart is poisoned. He would be thy bane..." By GReAT on November 24, 2014. 2:00 pm Incidents Research GReAT Kaspersky Labs' Global Research & Analysis Team @e_kaspersky/great Motto: "Beware of Regin, the master! His heart is poisoned. He would be thy bane..." "The Story of Siegfried" by James Baldwin Introduction, history Download our full Regin paper (PDF). In the spring of 2012, following a Kaspersky Lab presentation on the unusual facts surrounding the Duqu malware, a security researcher contacted us and mentioned that Duqu reminded him of another high-end malware incident. Although he couldn't share a sample, the third-party researcher mentioned the "Regin" name, a malware attack that is now dreaded by many security administrators in governmental agencies around the world. For the past two years, we've been tracking this most elusive malware across the world. From time to time, samples would appear on various multi-scanner services, but they were all unrelated to each other, cryptic in functionality and lacking context. It's unknown exactly when the first samples of Regin were created. Some of them have timestamps dating back to 2003. The victims of Regin fall into the following categories: Telecom operators Government institutions Multi-national political bodies Financial institutions Research institutions Individuals involved in advanced mathematical/cryptographical research So far, we've observed two main objectives from the attackers: Intelligence gathering Facilitating other types of attacks While in most cases, the attackers were focused on extracting sensitive information, such as e-mails and documents, we have observed cases where the attackers compromised telecom operators to enable the launch of additional sophisticated attacks. More about this in the GSM Targeting section below. Perhaps one of the most publicly known victims of Regin is Jean Jacques Quisquater (https://en.wikipedia.org/wiki/Jean-Jacques_Quisquater), a well-known Belgian cryptographer. In February 2014, Quisquater announced he was the victim of a sophisticated cyber intrusion incident. We were able to obtain samples from the Quisquater case and confirm they belong to the Regin platform. Another interesting victim of Regin is a computer we are calling "The Magnet of Threats". This computer belongs to a research institution and has been attacked by Turla, Mask/Careto, Regin, Itaduke, Animal Farm and some other advanced threats that do not have a public name, all co-existing happily on the same computer at some point. Initial compromise and lateral movement The exact method of the initial compromise remains a mystery, although several theories exist, which include man-in-the-middle attacks with browser zero-day exploits. For some of the victims, we observed tools and modules designed for lateral movement. So far, we have not encountered any exploits. The replication modules are copied to remote computers by using Windows administrative shares and then executed. Obviously, this technique requires administrative privileges inside the victim's network. In several cases, the infected machines were also Windows domain controllers. Targeting of system administrators via web-based exploits is one simple way of achieving immediate administrative access to the entire network. The Regin platform In short, Regin is a cyber-attack platform which the attackers deploy in the victim networks for ultimate remote control at all possible levels. The platform is extremely modular in nature and has multiple stages. Regin platform diagram The first stage ("stage 1") is generally the only executable file that will appear in victim' systems. Further stages are stored either directly on the hard drive (for 64 bit systems), as NTFS Extended Attributes or registry entries. We've observed many different stage 1 modules, which sometimes have been merged with public sources to achieve a type of polymorphism, complicating the detection process. The second stage has multiple purposes and can remove the Regin infection from the system if instructed so by the 3rd stage. The second stage also creates a marker file that can be used to identify the infected machine. Known filenames for this marker are: %SYSTEMROOT%\system32\nsreg1.dat %SYSTEMROOT%\system32\bssec3.dat %SYSTEMROOT%\system32\msrdc64.dat Stage 3 exists only on 32 bit systems - on 64 bit systems, stage 2 loads the dispatcher directly, skipping the third stage. Stage 4, the dispatcher, is perhaps the most complex single module of the entire platform. The dispatcher is the user-mode core of the framework. It is loaded directly as the third stage of the 64-bit bootstrap process or extracted and loaded from the VFS as module 50221 as the fourth stage on 32-bit systems. The dispatcher takes care of the most complicated tasks of the Regin platform, such as providing an API to access virtual file systems, basic communications and storage functions as well as network transport sub-routines. In essence, the dispatcher is the brain that runs the entire platform. A thorough description of all malware stages can be found in our full technical paper. Virtual File Systems (32/64-bit) The most interesting code from the Regin platform is stored in encrypted file storages, known as Virtual File Systems (VFSes). During our analysis we were able to obtain 24 VFSes, from multiple victims around the world. Generally, these have random names and can be located in several places in the infected system. For a full list, including format of the Regin VFSes, see our technical paper. Unusual modules and artifacts With high-end APT groups such as the one behind Regin, mistakes are very rare. Nevertheless, they do happen. Some of the VFSes we analyzed contain words which appear to be the respective codenames of the modules deployed on the victim: legspinv2.6 and LEGSPINv2.6 WILLISCHECKv2.0 HOPSCOTCH Another module we found, which is a plugin type 55001.0 references another codename, which is U_STARBUCKS: GSM Targeting The most interesting aspect we found so far about Regin is related to an infection of a large GSM operator. One VFS encrypted entry we located had internal id 50049.2 and appears to be an activity log on a GSM Base Station Controller. From https://en.wikipedia.org/wiki/Base_station_subsystem According to the GSM documentation (http://www.telecomabc.com/b/bsc.html): "The Base Station Controller (BSC) is in control of and supervises a number of Base Transceiver Stations (BTS). The BSC is responsible for the allocation of radio resources to a mobile call and for the handovers that are made between base stations under his control. Other handovers are under control of the MSC." Here's a look at the decoded Regin GSM activity log: This log is about 70KB in size and contains hundreds of entries like the ones above. It also includes timestamps which indicate exactly when the command was executed. The entries in the log appear to contain Ericsson OSS MML (Man-Machine Language as defined by ITU-T) commands. Here's a list of some commands issued on the Base Station Controller, together with some of their timestamps: 2008-04-25 11:12:14: rxmop:moty=rxotrx; 2008-04-25 11:58:16: rxmsp:moty=rxotrx; 2008-04-25 14:37:05: rlcrp:cell=all; 2008-04-26 04:48:54: rxble:mo=rxocf-170,subord; 2008-04-26 06:16:22: rxtcp:MOty=RXOtg,cell=kst022a; 2008-04-26 10:06:03: IOSTP; 2008-04-27 03:31:57: rlstc:cell=pty013c,state=active; 2008-04-27 06:07:43: allip:acl=a2; 2008-04-28 06:27:55: dtstp:DIP=264rbl2; 2008-05-02 01:46:02: rlstp:cell=all,state=halted; 2008-05-08 06:12:48: rlmfc:cell=NGR035W,mbcchno=83&512&93&90&514&522,listtype=active; 2008-05-08 07:33:12: rlnri:cell=NGR058y,cellr=ngr058x; 2008-05-12 17:28:29: rrtpp:trapool=all; [TABLE=class: crayon-table] [TR=class: crayon-row] [TD=class: crayon-nums] 1 2 3 4 5 6 7 8 9 10 11 12 13 [/TD] [TD=class: crayon-code]2008-04-25 11:12:14: rxmop:moty=rxotrx; 2008-04-25 11:58:16: rxmsp:moty=rxotrx; 2008-04-25 14:37:05: rlcrp:cell=all; 2008-04-26 04:48:54: rxble:mo=rxocf-170,subord; 2008-04-26 06:16:22: rxtcp:MOty=RXOtg,cell=kst022a; 2008-04-26 10:06:03: IOSTP; 2008-04-27 03:31:57: rlstc:cell=pty013c,state=active; 2008-04-27 06:07:43: allip:acl=a2; 2008-04-28 06:27:55: dtstp:DIP=264rbl2; 2008-05-02 01:46:02: rlstp:cell=all,state=halted; 2008-05-08 06:12:48: rlmfc:cell=NGR035W,mbcchno=83&512&93&90&514&522,listtype=active; 2008-05-08 07:33:12: rlnri:cell=NGR058y,cellr=ngr058x; 2008-05-12 17:28:29: rrtpp:trapool=all;[/TD] [/TR] [/TABLE] Descriptions for the commands: rxmop - check software version type; rxmsp - list current call forwarding settings of the Mobile Station; rlcrp - list off call forwarding settings for the Base Station Controller; rxble - enable (unblock) call forwarding; rxtcp - show the Transceiver Group of particular cell; allip - show external alarm; dtstp - show DIgital Path (DIP) settings (DIP is the name of the function used for supervision of the connected PCM (Pulse Code Modulation) lines); rlstc - activate cell(s) in the GSM network; rlstp - stop cell(s) in the GSM network; rlmfc - add frequencies to the active broadcast control channel allocation list; rlnri - add cell neightbour; rrtpp - show radio transmission transcoder pool details; The log seems to contain not only the executed commands but also usernames and passwords of some engineering accounts: sed[snip]:Alla[snip] hed[snip]:Bag[snip] oss:New[snip] administrator:Adm[snip] nss1:Eric[snip] In total, the log indicates that commands were executed on 136 different cells. Some of the cell names include "prn021a, gzn010a, wdk004, kbl027a, etc...". The command log we obtained covers a period of about one month, from April 25, 2008 through May 27, 2008. It is unknown why the commands stopped in May 2008 though; perhaps the infection was removed or the attackers achieved their objective and moved on. Another explanation is that the attackers improved or changed the malware to stop saving logs locally and that's why only some older logs were discovered. Communication and C&C The C&C mechanism implemented in Regin is extremely sophisticated and relies on communication drones deployed by the attackers throughout the victim networks. Most victims communicate with another machine in their own internal network, through various protocols, as specified in the config file. These include HTTP and Windows network pipes. The purpose of such a complex infrastructure is to achieve two goals: give attackers access deep into the network, potentially bypassing air gaps and restrict as much as possible the traffic to the C&C. Here's a look at the decoded configurations: 17.3.40.101 transport 50037 0 0 y.y.y.5:80 ; transport 50051 217.y.y.yt:443 17.3.40.93 transport 50035 217.x.x.x:443 ; transport 50035 217.x.x.x:443 50.103.14.80 transport 27 203.199.89.80 ; transport 50035 194.z.z.z:8080 51.9.1.3 transport 50035 192.168.3.3:445 ; transport 50035 192.168.3.3:9322 18.159.0.1 transport 50271 DC ; transport 50271 DC [TABLE=class: crayon-table] [TR=class: crayon-row] [TD=class: crayon-nums] 1 2 3 4 5 [/TD] [TD=class: crayon-code]17.3.40.101 transport 50037 0 0 y.y.y.5:80 ; transport 50051 217.y.y.yt:443 17.3.40.93 transport 50035 217.x.x.x:443 ; transport 50035 217.x.x.x:443 50.103.14.80 transport 27 203.199.89.80 ; transport 50035 194.z.z.z:8080 51.9.1.3 transport 50035 192.168.3.3:445 ; transport 50035 192.168.3.3:9322 18.159.0.1 transport 50271 DC ; transport 50271 DC[/TD] [/TR] [/TABLE] In the above table, we see configurations extracted from several victims that bridge together infected machines in what appears to be virtual networks: 17.3.40.x, 50.103.14.x, 51.9.1.x, 18.159.0.x. One of these routes reaches out to the "external" C&C server at 203.199.89.80. The numbers right after the "transport" indicate the plugin that handles the communication. These are in our case: 27 - ICMP network listener using raw sockets 50035 - Winsock-based network transport 50037 - Network transport over HTTP 50051 - Network transport over HTTPS 50271 - Network transport over SMB (named pipes) The machines located on the border of the network act as routers, effectively connecting victims from inside the network with C&Cs on the internet. After decoding all the configurations we've collected, we were able to identify the following external C&Cs. [TABLE=width: 80%] [TR] [TD=width: 30%, align: center]C&C server IP[/TD] [TD=width: 35%, align: center]Location[/TD] [TD=width: 35%, align: center]Description[/TD] [/TR] [TR] [TD]61.67.114.73[/TD] [TD]Taiwan, Province Of China Taichung[/TD] [TD]Chwbn[/TD] [/TR] [TR] [TD]202.71.144.113[/TD] [TD]India, Chetput[/TD] [TD]Chennai Network Operations (team-m.co)[/TD] [/TR] [TR] [TD]203.199.89.80[/TD] [TD]India, Thane[/TD] [TD]Internet Service Provider[/TD] [/TR] [TR] [TD]194.183.237.145[/TD] [TD]Belgium, Brussels[/TD] [TD]Perceval S.a.[/TD] [/TR] [/TABLE] One particular case includes a country in the Middle East. This case was mind-blowing so we thought it's important to present it. In this specific country, all the victims we identified communicate with each other, forming a peer-to-peer network. The P2P network includes the president's office, a research center, educational institution network and a bank. These victims spread across the country are all interconnected to each other. One of the victims contains a translation drone which has the ability to forward the packets outside of the country, to the C&C in India. This represents a rather interesting command-and-control mechanism, which is guaranteed to raise very little suspicions. For instance, if all commands to the president's office are sent through the bank's network, then all the malicious traffic visible for the president's office sysadmins will be only with the bank, in the same country. Victim Statistics Over the past two years, we collected statistics about the attacks and victims of Regin. These were aided by the fact that even after the malware is uninstalled, certain artifacts are left behind which can help identify an infected (but cleaned) system. For instance, we've seen several cases where the systems were cleaned but the "msrdc64.dat" infection marker was left behind. So far, victims of Regin were identified in 14 countries: Algeria Afghanistan Belgium Brazil Fiji Germany Iran India Indonesia Kiribati Malaysia Pakistan Russia Syria In total, we counted 27 different victims, although it should be pointed out that the definition of a victim here refers to a full entity, including their entire network. The number of unique PCs infected with Regin is of course much, much higher. From the map above, Fiji and Kiribati are unusual, because we rarely see such advanced malware in such remote, small countries. In particular, the victim in Kiribati is most unusual. To put this into context, Kiribati is a small island in the Pacific, with a population around 100,000. More information about the Regin victims is available through Kaspersky Intelligent Services. Contact: intelreports@kaspersky.com Attribution Considering the complexity and cost of Regin development, it is likely that this operation is supported by a nation-state. While attribution remains a very difficult problem when it comes to professional attackers such as those behind Regin, certain metadata extracted from the samples might still be relevant. As this information could be easily altered by the developers, it's up to the reader to attempt to interpret this: as an intentional false flag or a non-critical indicator left by the developers. More information about Regin is available to Kaspersky Intelligent Services' clients. Contact: intelreports@kaspersky.com Conclusions For more than a decade, a sophisticated group known as Regin has targeted high-profile entities around the world with an advanced malware platform. As far as we can tell, the operation is still active, although the malware may have been upgraded to more sophisticated versions. The most recent sample we've seen was from a 64-bit infection. This infection was still active in the spring of 2014. The name Regin is apparently a reversed "In Reg", short for "In Registry", as the malware can store its modules in the registry. This name and detections first appeared in anti-malware products around March 2011. From some points of view, the platform reminds us of another sophisticated malware: Turla. Some similarities include the use of virtual file systems and the deployment of communication drones to bridge networks together. Yet through their implementation, coding methods, plugins, hiding techniques and flexibility, Regin surpasses Turla as one of the most sophisticated attack platforms we have ever analysed. The ability of this group to penetrate and monitor GSM networks is perhaps the most unusual and interesting aspect of these operations. In today's world, we have become too dependent on mobile phone networks which rely on ancient communication protocols with little or no security available for the end user. Although all GSM networks have mechanisms embedded which allow entities such as law enforcement to track suspects, there are other parties which can gain this ability and further abuse them to launch other types of attacks against mobile users. Full technical paper with IOCs. Kaspersky products detect modules from the Regin platform as: Trojan.Win32.Regin.gen and Rootkit.Win32.Regin. If you detect a Regin infection in your network, contact us at: intelservices@kaspersky.com Sursa: Regin: Nation-state ownage of GSM networks - Securelist

Understanding Crypto-Ransomware Table of Contents Executive Summary 3 Introduction 4 Dataset and Timeline 6 Analysis Methodology 8 Results 11 Droppers, anti-analysis and persistence 11 C&C communication 13 Encryption 15 Targeted file types 17 Payment options 20 Implementation, flaws and version evolution 22 Conclusion 24 References 26 Appendix A: Fake Cryptolocker C&C Server 28 and CryptDecrypt Hook Appendix B: Fake Cryptowall C&C Server 30 Appendix C: Hooking WriteProcessMemory 32 About Bromium 35 Download: http://www.bromium.com/sites/default/files/bromium-report-ransomware.pdf

Hacking RFID Payment Cards Made Possible with Android App 2:03 am (UTC-7) | by Veo Zhang (Mobile Threats Analyst) We recently encountered a high-risk Android app detected as ANDROIDOS_STIP.A in Chile. This app, found distributed through forums and blogs, can be used to hack into the user’s RFID bus transit card to recharge the credits. What is the mechanism behind this, and what is the security risk of RFID payment cards in general? Paying via RFID cards is becoming more popular nowadays as more mobile devices add NFC support. Banks, merchants or public services issue RFID cards to their customers with prepaid credits. Security Issues with RFID Cards Because it is widely used, it’s no surprise that that RFID cards have become targeted by attacks. Take for instance the recent Tarjeta bip! card hacking incident in Chile. These cards are MIFARE-based smartcards; MIFARE refers to a family of chips widely used in contactless smart cards and proximity cards. Figure 1. MIFARE devices Looking at the code of the Android app, we found that if it runs on a device equipped with NFC it can read and write to these cards. The malicious app writes predefined data onto the card, raising the user’s balance to 10,000 Chilean pesos (approximately 15 US dollars). This particular trick will only work with this particular fare card, since it relies on the format of the card in question. How was the tool’s author able to rewrite the card’s information despite not having the correct authentication keys? This is because these cards are based on an older version of the MIFARE series of cards (MIFARE Classic), which is known to have multiple security problems. An attacker is able to clone or modify a MIFARE Classic card in under 10 seconds, and the equipment (such as the Proxmark3), together with any needed support, is sold online. Figure 2. Proxmark3 for sale Using widely available tools, the attacker cracked the card’s authentication key. With the cracked key and the native NFC support in Android and the device, cloning a card and adding credits can be easily implemented in a mobile app. Figure 3. Manufacturer and memory content of a MIFARE Classic card Attacks on other kinds of MIFARE cards (specifically, MIFARE DESFire and MIFARE Ultralight) are known to exist. We know of at least three vulnerable cards which we have: a social security card with banking service, a payment card for transportation and shopping, and a dining card. The social security card has approximately seven million users. Figure 4. MIFARE DESFire-based social security card The dining card uses MIFARE Classic cards, and our testing revealed the on-card credits can be manipulated. The two other cards are MIFARE DESFire cards, which are vulnerable to side-channel attacks. The cryptosystems in these cards leak information if the power used is monitored; the keys can be recovered within seven hours. If the issued keys are not random, customer cards can be cloned or manipulated similarly to MIFARE Classic cards. Or even worse, credits can also be manipulated within a NFC-enabled mobile device. Conclusion These particular MIFARE models were discontinued years ago and supplemented with more secure models. However, it appears that card issuers have opted for cheaper solutions which put their customers at risk. NFC We recommend customers take steps to protect RFID cards in their possession. They should also periodically check the balances of their accounts as well. In addition, if possible, they should check if any cards they are currently using are vulnerable and report these to their providers. RFID/NFC attacks are a well-known risk; in the past we have provided tips both to end users and businesses on how to use NFC safely. Sursa: Hacking RFID Payment Cards Made Possible with Android App | Security Intelligence Blog | Trend Micro

Regin: Top-tier espionage tool enables stealthy surveillance Symantec Security Response Version 1.0 – November 24, 2014 OVERVIEW...................................................................... 3 Introduction................................................................... 5 Timeline.......................................................................... 5 Target profile.................................................................. 6 Infection vector........................................................ 6 Architecture................................................................... 8 Stage 0 (dropper)..................................................... 9 Stage 1...................................................................... 9 Stage 2...................................................................... 9 Stage 3...................................................................... 9 Stage 4............................................................ 11 Stage 5.................................................................... 11 Encrypted virtual file system containers ?????????????? 11 Command-and-control operations......................... 12 Logging................................................................... 12 Payloads....................................................................... 14 64-bit version............................................................... 15 File names.............................................................. 15 Stage differences................................................... 15 Conclusion.................................................................... 16 Protection..................................................................... 16 Appendix...................................................................... 18 Data files................................................................ 18 Indicators of compromise............................................ 20 File MD5s................................................................ 20 File names/paths.................................................... 20 Extended attributes............................................... 21 Registry.................................................................. 21 Download: http://www.symantec.com/content/en/us/enterprise/media/security_response/whitepapers/regin-analysis.pdf

Web Shell Detector Web Shell Detector – is a php script that helps you find and identify php/cgi(perl)/asp/aspx shells. Web Shell Detector has a “web shells” signature database that helps to identify “web shell” up to 99%. By using the latest javascript and css technologies, web shell detector has a light weight and friendly interface. Web Shell Detector is released under the MIT License The MIT License (MIT) | Open Source Initiative Console version (python): https://github.com/emposha/Shell-Detector Contributors Piotr ?uczko John Thornton Detection Number of known shells: 604 Requirements PHP 5.x, OpenSSL (only for secure file submission) Usage To activate Web Shell Detector: 1) Upload shelldetect.php and shelldetect.db to your root directory 2) Open shelldetect.php file in your browser Example: http://www.website.com/shelldetect.php 3) Inspect all strange files, if some of files look suspicious, send them to Web Shell Detector team. After submitting your file, it will be inspected and if there are any threats, it will be inserted into a “web shell detector” web shells signature database. 4) If any web shells found and identified use your ftp/ssh client to remove it from your web server (IMPORTANT: please be carefull because some of shells may be integrated into system files!). Demo http://www.emposha.com/demo/shelldetect/ Options extension - extensions that should be scanned showlinenumbers - show line number where suspicious function used dateformat - used with access time & modified time langauge - if I want to use other language directory - scan specific directory task - perform different task report_format - used with is_cron(true) file format for report file is_cron - if true run like a cron(no output) filelimit - maximum files to scan (more then 30000 you should scan specific directory) useget - activate _GET variable for easy way to recive tasks authentication - protect script with user & password in case to disable simply set to NULL remotefingerprint - get shells signatures db by remote Sursa: https://github.com/emposha/PHP-Shell-Detector

Dyre IE Hooks I recently wrapper up my analysis of Dyre. A PDF of document can be found in my papers repo. Most of the document focuses on the different stages that Dyre interacts with the operating system. There are still some areas that I'd like to dig deeper into. For now it should be a good resource for anyone trying to identify a machine infected with Dyre or wanting to know more about the family of malware. During the reversing process I found one part of Dyre functionality worthy of a post. As with most banking trojans Dyre contains functionality to hook APIs to log browser traffic. Typically to get the addresses of the APIs the sample will call GetProcAddress or manually traverse the portable executable file format to resolve symbols. If you are unfamiliar with the later technique I'd highly recommend reading section 3.3 of "Understanding Windows Shellcode" by Skape [1]. Dyre attempts to hook APIs in firefox.exe, chrome.exe and iexplorer.exe. It uses the standard GetProcAddress approach for resolving symbols in firefox.exe, is unsuccessful in chrome.exe and uses the GetProcAddress approach for the APIs LoadLibraryExW and CreateProcessInternalW in iexplorer.exe. Dyre hooks two APIs in WinInet.dll but it does it in a unique way. Dyre will read the image header timedatestamp [2] from WinInet. This value contains the time and date from when Wininet was created by the linker during compiling. It will then compare the timedatestamp to a list of timedatestamps stored by Dyre. The list contains presumably every time stamp for WinInet.dll since '2004-08-04 01:53:22' to '2014-07-25 04:04:59'. Below is an example of the values that can be found in the list. seg000:00A0C05F db 0 seg000:00A0C060 TimeStampList dd 4110941Bh ; DATA XREF: TimeStamp:_loopr seg000:00A0C064 dword_A0C064 dd 0 ; DATA XREF: TimeStamp+1Cr seg000:00A0C064 ; TimeStamp:loc_A07A0Dr ... seg000:00A0C068 dd 411095F2h <- Time stamp seg000:00A0C06C dd 0 <- WinInet index seg000:00A0C070 dd 4110963Fh seg000:00A0C074 dd 0 seg000:00A0C078 dd 4110967Dh seg000:00A0C07C dd 0 seg000:00A0C080 dd 411096D4h seg000:00A0C084 dd 0 seg000:00A0C088 dd 411096DDh seg000:00A0C08C dd 0 seg000:00A0C090 dd 41252C1Bh seg000:00A0C094 dd 0 ..... seg000:00A0C0AC dd 1 seg000:00A0C0B0 dd 435862A0h seg000:00A0C0B4 dd 2 seg000:00A0C0B8 dd 43C2A6A9h seg000:00A0C0BC dd 3 .... seg000:00A0D230 dd 4CE7BA3Fh seg000:00A0D234 dd 78h seg000:00A0D238 dd 53860FB3h seg000:00A0D23C dd 79h seg000:00A0D240 dd 53D22BCBh seg000:00A0D244 dd 7Ah Values converted to time >>> datetime.datetime.fromtimestamp(0x411095F2).strftime('%Y-%m-%d %H:%M:%S') '2004-08-04 01:53:22' >>> datetime.datetime.fromtimestamp(0x53D22BCB).strftime('%Y-%m-%d %H:%M:%S') '2014-07-25 04:04:59' If the timedatestamp is not present or an error occurs Dyre will send the hash of WinInet to the attackers server. If the hash is not found it will send WinInet back to the attackers. Below are some of the strings responsible for displaying errors for the command and control. '/%s/%s/63/file/%s/%s/%s/' "Check wininet.dll on server failed" "Send wininet.dll failed" If the timedatestamp is found in the list the next value is used as an index into another list. For example if the timedatestamp was 4802A13Ah it would be found at the 49th entry and the next value would be 0x15 or 21. Data seg000:00A0C1E8 dd 4802A13Ah <- '2008-04-13 18:11:38' seg000:00A0C1EC dd 15h <- 21 index Assembly to read index value seg000:00A07A0D movsx edx, word ptr ds:TimeStampIndex[eax*8] ; edx = 21 seg000:00A07A15 lea edx, [edx+edx*2] ; edx = 63 seg000:00A07A18 mov edx, ds:offset[edx*4] seg000:00A07A1F mov [ecx], edx ; save off value Python: calculate offset Python>hex(0x0A0D3E0 + (21+21* 2) * 4) 0xa0d4dc Read seg000:00A0D4DC dw 0F3Ch 0x0f3C offset to inline hook in wininet The value 0xF3C + the base address of WinInet is the function prologue for ICSecureSocket::Send_Fsm. Dyre uses this to know the address to place it's hooks. ICSecureSocket::Send_Fsm(CFsm_SecureSend *) 77200F37 90 NOP 77200F38 90 NOP 77200F39 90 NOP 77200F3A 90 NOP 77200F3B 90 NOP 77200F3C - E9 C7F0398A JMP 015A0008 <- Inline hook 015A0008 68 4077A000 PUSH 0A07740 015A000D C3 RETN 00A07740 55 PUSH EBP 00A07741 8BEC MOV EBP,ESP 00A07743 83EC 08 SUB ESP,8 00A07746 894D FC MOV DWORD PTR SS:[EBP-4],ECX 00A07749 68 2077A000 PUSH 0A07720 00A0774E FF75 08 PUSH DWORD PTR SS:[EBP+8] 00A07751 FF75 FC PUSH DWORD PTR SS:[EBP-4] 00A07754 FF15 94DEA000 CALL DWORD PTR DS:[A0DE94] 00A0775A 8945 F8 MOV DWORD PTR SS:[EBP-8],EAX It will also hooks ICSecureSocket::Receive_Fsm in the same fashion. Closing Rather than calling GetProcAddress Dyre stores the timedatestamp and patch offset of every known version of WinInet to avoid triggering heuristic based scanners. Seems like an arduous approach but still kind of cool. Another interesting fact is Dyre has the ability to patch Trusteer's RapportGP.dll if found in the browser memory. Dyre is actually a family of malware worthy of a deep dive. At first glance I ignored it because everything looked pretty cut & paste. I'd recommend others to check it out. If you find anything useful please shoot me an email. Cheers. Hash Analyzed 099c36d73cad5f13ec1a89d5958486060977930b8e4d541e4a2f7d92e104cd21 http://www.nologin.org/Downloads/Papers/win32-shellcode.pdf IMAGE_FILE_HEADER structure (Windows) Sursa: Hooked on Mnemonics Worked for Me: Dyre IE Hooks

Worst WordPress hole for five years affects 86% of sites Trio of XSS turns attackers into admins By Darren Pauli, 24 Nov 2014 An estimated 86 per cent of WordPress websites harbour a dangerous cross-site scripting (XSS) hole in the popular comment system plugin, in what researcher Jouk Pynnonen calls the most serious flaw in five years. The bug could provide a pathway for attacking visitors' machines. The WP-Statistics plugin lets attackers inject JavaScript into comments, which can then infect reader computers or those of administrators. The flaw has existed for about four years affecting versions between 3.0 to 3.9.2 but not version 4.0 which handles regular expressions differently. Version 4.0.1 patched a separate and also critical set of XSS flaws discovered by the internal security team, along with a cross-site request forgery hole. Klikki Oy security bod Pynnonen revealed the earlier flaw last week in technical advisory. "An attacker could exploit the vulnerability by entering carefully crafted comments, containing program code, on WordPress blog posts and pages. Under default settings comments can be entered by anyone without authentication," Pynnonen said. "Program code injected in comments would be inadvertently executed in the blog administrator's web browser when they view the comment. The rogue code could then perform administrative operations by covertly taking over the administrator account. "Such operations include creating a new administrator account (with a known password), changing the current administrator password, and in the most serious case, executing attacker-supplied PHP code on the server. This grants the attacker operating system level access on the server hosting WordPress." The unauthenticated default exploit considering the server-side impact made it "probably the most serious WordPress core vulnerability that has been reported since 2009". Pynnonen developed a proof of concept exploit that mopped up evidence of injected script before quietly using the plugin editor to write attacker-supplied PHP code on the server, changing the user's password, and creating an administrator account. Attackers could then write more PHP code to the server through the editor instantly executed using an AJAX request to gain operating system level access. Other plugins that allow unprivileged users to enter HTML text could offer more attack vectors, Pynnonen said. Pynnonen created a work-around plugin for administrators who could not upgrade their WordPress servers. Yet a third set of recently patched XSS were discovered by Sucuri researcher Marc-Alexandre Montpas. The stored and reflected XSS in versions 8.3 and below also turned attackers to admins for versions , and permitted blackhat searh engine optimisation innjection into blog posts. "... the problem is very simple," Montpas said. "The plugin fails to properly sanitise some of the data it gathers for statistical purposes, which are controlled by the website's visitors." "If an attacker decided to put malicious Javascript code in the affected parameter, it would be saved in the database and printed as-is in the administrative panel, forcing the victim's browser to perform background tasks on its behalf. SANS diary scribe Johannes B. Ullrich said the XSS vulnerability was a common underestimated problem. "XSS does allow an attacker to modify the HTML of the site," Ullrich said. "Wordpress developers did attempt to implement the necessary safeguards [since] only certain tags are allowed, and even for these tags, the code checked for unsafe attributes. "Sadly, this check wasn't done quite right. Remember that browsers will also parse somewhat malformed HTML just fine." ® Sursa: DEATH by COMMENTS: WordPress XSS vuln is BIGGEST for YEARS • The Register

Cryptology ePrint Archive: Report 2014/435 Wait a minute! A fast, Cross-VM attack on AES Gorka Irazoqui and Mehmet Sinan Inci and Thomas Eisenbarth and Berk Sunar Abstract: In cloud computing, efficiencies are reaped by resource sharing such as co-location of computation and deduplication of data. This work exploits resource sharing in virtualization software to build a powerful cache-based attack on AES. We demonstrate the vulnerability by mounting Cross-VM Flush+Reload cache attacks in VMware VMs to recover the AES keys of OpenSSL 1.0.1 running inside the victim VM. Furthermore, the attack works in a realistic setting where different VMs are located on separate cores. The modified flush+reload attack we present, takes only in the order of seconds to minutes to succeed in a cross-VM setting. Therefore long term co-location, as required by other fine grain attacks in the literature, are not needed. The results of this study show that there is a great security risk to OpenSSL AES implementation running on VMware cloud services when the deduplication is not disabled. Category / Keywords: Original Publication (with minor differences): Research in Attacks, Intrusions and Defenses Symposium - RAID 2014 Date: received 5 Jun 2014, last revised 20 Nov 2014 Contact author: teisenbarth at wpi edu Available format(s): PDF | BibTeX Citation Version: 20141120:211658 (All versions of this report) Sursa: Cryptology ePrint Archive: Report 2014/435

[h=2]IAT Patcher[/h] [h=4]My new tool, based on bearparser.[/h][h=4](Experimental version, last update: 23.11.2014: added 64bit stub!) Download: x86 , x64 *requires: Microsoft Visual C++ 2010 Redistributable Package, available here: [Redist 32bit] [Redist 64bit] NOTE: this is just "quick and dirty" PoC. Improvements and optimization in implementation will come gradualy. Also, you can expect full source code of the IAT Patcher soon! [/h] The purpose of this app is persistent IAT hooking, made fast and easy. It provides substituting any function loaded from DLL by your custom function (the only requirement it that call convention and number of parameters are the same!). See examples below. Sample libraries: https://github.com/hasherezade/IAT_patcher_samples Sursa: hasherezade's homepage

By Radu FaraVirusi(com) on November 24, 2014 Ashampoo Burning Studio 2014 este un program excelent pentru inscriptionarea CD\DVD\Blu-Ray. Este de asemenea un bun inlocuitor pentru clasicul Nero Burning Room, care are cateva dezavantaje printre care: NU este gratuit si are o multime de programele inutile care se instaleaza odata cu programul principal, ocupand spatiu si resurse. Acum puteti obtine acest software complet GRATUIT. Programul costa in mod normal 50$ si ofera multe functii: crearea CD\DVD\Blu-Ray de tip Data functie de Backup\Restore realizare de DVD-Video, Video CD si Super Video CD copiere CD\DVD\Blu-Ray inscriptionare si crearea de imagini .iso, .cue\bin, ashdisc crearea de CD-uri Audio si MP3 plus Ripping Creeaza si imprima etichete si coperti pentru disc-urile tale Iata cum obtineti licenta GRATUITA: Accesati site-ul de mai jos pentru a obtine codul de inregistrare: Ashampoo® - Full Version License - Ashampoo® Burning Studio 2014 Descarcati produsul de aici: http://bigfiles.downloadcluster.com/public/ksw/4110/ashampoo_burning_studio_2014_12.0.5_16837.exe Sursa: Ashampoo Burning Studio 2014 (alternativa Nero) – Licenta GRATUITA