Leaderboard

Recent google ia in considerare protocolul https:// mai mult decat pana acum, iar efectele le-am simtit si eu. Totusi nu recomand certificatele free care tot circula pe net. Studiu de caz: Pe protocol http:// In acelasi timp, certificatul SSL luat la infiintarea site-ului incepe sa dea roade. Desi aveam ambele versiuni up, nu fortam protocolul https:// din .htaccess, google a decis sa-mi rankeze versiunea https:// in schimbul protocolului normal.

Chiar deloc, de prin 2014 am renuntat la tool-uri minune care te puneau pe primul loc in google si prefer sa-mi fac off-page prin mini-PBN-ul pe care il am construit ceea ce ma ajuta la niste backlink-uri de calitate la care doar eu am acces. ~$10 de la GeoTrust, la care primesc o asigurare de $10k in caz ca este spart ssl-ul.

In caz ca doriti ceva moca si bun, folositi https://blog.cloudflare.com/introducing-universal-ssl/ Pe langa SSL, ofera si alte facilitati super.

GPS hacking (PART 1) Author: virustracker Time: February 4, 2016 Category: default Author: Kevin2600 From: http://drops.wooyun.org/tips/11155 0x00 Preface GPS hacking has alway been a hot topic on security conferences over the past few years. But the contents are over academic and the cost for necessary equipment is too high, which stops many fans from getting started. The appearance of some open source projects, such as GPS-SDR-SIM, and the Keynote speech given by @Wang Kang on Blackhat Europe 2015 have pierced the veil of GPS. This means any user who is interested in this topic will truly be able to have a try on GPS hacking. I believe many of you have heard of a powerful tool called Software Defined Radio (SDR) in GPS research. But a new USRP is very expensive, until we found an amazing TV Dongle named RTL-SDR. Some time ago, everyone enjoys using it to watch “adult channels”. In view of its hardware constraints, it can only be used to received data. However, HackRF and BladeRF support both receiving and sending data, besides they are cheaper than USRP. Of course, HackRF and BladeRF support different frequency and sample rate. Therefore, this two become the first choice of radio fans. The most important part about BladeRF is that it is full duplexed. Here is a comparison between several SDR equipment. You may purchase as you need. Brief introduction of GPS system GPS system is very complex and involve many fields from satellite communications. Here is just a brief introduction. The GPS we are talking about is built by U.S. Department of Defense. Currently there are 31 satellites working simultaneously in space. Normally we need at least 4 satellites to complete triangulation positioning. All satellites broadcast both L1 signals for civil use and L2 signals for military use at the same time. What we often use is a 1575.42MHz ultra high frequency which is an unencrypted L1 signals for civil use. GPS signals include 3 kinds of information. Pseudorandom code: a simple ID code used to identify each satellite. Ephemeris data: include information about the time and status of satellites, which plays an important role in calculating the position of each satellite. Almanac data: include information about satellite orbits and the specific position that a satellite will be at in a given time. 0x01 Processes to forge BladeRF GPS signals 1.1 Install a BladeRF tool on Ubuntu 14.04.3 install the header file install BladeRF firmware & FPGA image After installation, you may notice a hostedX40.rbf and a bladerf_fw.img in /usr/share/nuand/BladeRF/. Here you can insert the BladeRF to a USB interface. Normally system will automatically load the FPGA image. Or it can be manually loaded by inputingbladerf_cli -l /path/hostedX40.rbf in command line. When the image is loaded successfully, 3 LED lights on BladeRF board will illuminate, meanwhile, we can add a -p parameter to further verify if system installation is successful. 1.2 Install GPS-SDR-SIM git clone https://github.com/osqzss/gps-sdr-sim.git cd gps-sdr-sim gcc gpssim.c -lm -O3 -o gps-sdr-sim Set up latitude and longitude, then generate a data sample. Note that the I/O baseband signal here is 16. Afterwards, gps-sdr-sim will generate data files with latitude and longitude data in a automatic way. Then we will be able to send the forged GPS data through bladerf_cli. 1.3 Running time issue of GPS-SDR-SIM In practical test, @Wangwang find that GPS simulator can only work continuously for five minutes by default. By viewing its source code, we realized this problem is caused by default settings of the program. The program is designed to use less hard drive space and will only generate 300-second data by default. We could modify its parameter to extend working time. But data of 15 minutes will be up to 5GB. 0x02 Forge GPS signals in practice @Wangwang has shared several practical test cases here. Whoever is interested may have a try. 2.1 Search for girls through Wechat People Nearby I heard that a lot of programmers have little time to hang out with their queen in heart due to working pressure and introvert personality. And Wechat People Nearby perfectly solves this problem for people like that. All you need is to turn on the GPS of your phone, then you’ll have a change to say hello to the girls near by. But the drawback is the maximum range is limited within dozen miles away. For those kings of emotion, the stage is too small. Here @Wangwang presents the first case on forging GPS signals-search girls through Wechat People Nearby. Rumor says a campaign held several days ago in Sanya, Hainan gathered a town of beauties. @Wangwang can’t help but wonder how they look like. Let’s try Wechat people nearby! Before sending the forged GPS coordinate, @Wangwang only got the girls in the same city. Then @Wangwang started to send the forge GPS coordinate. 5 minutes later, the girls in Sanya turned up. LOL…@Wangwang signed a tech geek can change his life. 2.2 Forge Nike+ step counts Many friends who are found of mobile security must have read a post called “using AnDroid Hook to cheat Wechat sports” (http://drops.wooyun.org/tips/8416) written by @Zheng Mi. In this post, he mentioned that he used Android Hook to cheat on step counts so that to beat his friends’ record. But this method needs you to root your phone and install some relevant cheating plugins. For other step counting software, these plugins require to be modified accordingly. Here the test target is Nike+ Running. Let’s see a video first. This video is expedited to save time. http://player.youku.com/player.php/sid/XMTQwMzAxMTk4OA==/v.swf By browsing the home page of GPS-SDR-SIM, we learn that the forged GPS latitude and longitude data can be static or dynamic. To succeed in simulating motion trail, we have to forge dynamic GPS latitude and longitude data, which can be completed by the following parameters. gps-sdr-sim -e brdc3540.14n -u circle.csv -b 16 As you can see, step counting App-Nike+ is fooled through directly forging GPS signals. You’ll be the top scorer even you are in bed. But, of course, @Wangwang wish you could really join in running and enjoy the joy of sports. 2.3 Range test on forge signals From the aforementioned experiments, we know that GPS receiver can accept software simulated signals within a short distance. Then what about the performance of the GPS receiver in a larger scale? How far does effective distance can reach? Of course, it connects with output power, antenna gain and signal interference from nearby signals. So @Wangwang only presents a simple indoor test here. Actual condition prevails. Please watch this video first. http://player.youku.com/player.php/sid/XMTQwMzAwNzMxNg==/v.swf As can be seen from the video, the latitude and longitude of the GPS receiver is successfully changed in a 25-meter long linear corridor without any obstacles. Normally, real GPS signals coming from 20,000 meters high are already weak, and almost no signal is detected indoors. Therefore, indoor GPS signals forging attack can be pretty effective. 0x03 Summaries Based on the above cases, I believe you have more or less learned something about forging GPS signals. But as far as GPS itself, this is a very funny and esoteric area. More GPS related products emerge in market and each will respond different towards GPS deceiving attacks. Everybody can use your imagination and try different tricks. Finally, I’d like to extend my thanks to @osqzss, @Wang Kang and countless GNURadio enthusiasts for their unselfish sharing. It’s because of them that we’ll have chance to experience the charm of software defined radio. I recommend you the home page of GPS-SDR-SIM Project and the presentation given by @Wang Kang on Blackhat. Those who have HackRF equipment can read the post “Hijack GPS positioning & hijack WIFI positioning” by @lxj616. 0x04 References http://drops.wooyun.org/tips/10580 https://github.com/osqzss/gps-sdr-sim https://en.wikipedia.org/wiki/GPS_signals “Time and Position Spoofing with Open Source Projects” Kang Wang http://www.taylorkillian.com/2013/08/sdr-showdown-hackrf-vs-bladerf-vs-usrp.html Sursa: http://en.wooyun.io/2016/02/04/41.html

Salut , m-am hotarat sa impart cu voi experienta din urmatoarea perioada de optimizat campanii, dupa cum spune tiltlu am sa incerc sa monetizez ofertele CPA (Cost per action) promovandule cu ceva recmala ieftina. ZIUA 1 M-am ingresitrat pe https://adpad-v3.ezanga.com de aici o sa cumpar reclama. Am aplicat pentru https://peerfly.com/ de aici o sa iau ofetele CPA. Astept cu nerbdare sa apara HEITARII !

Asta inseamna sa fi mafiot,sa ai valoare.

Eu cumpar de aici de obicei: https://www.ssls.com/ssl-certificates/comodo-positivessl (15$/3ani).

Cu placa ta video poti juca jocuri in detalii minime, dezvoltate pana in 2013.... Iar jocuri mai vechi de 2006 le joci de la mediu in sus. De exemplu San Andreas merge bine (nu excelent), Fifa 2010 merge la calitate minima spre mediu. Filmele FullHD merg brici. Daca folosesti MPC poti rula si un 4k.... Ti-am dat cateva repere vagi. Iti recomand inca 4Gb de RAM, nu conteaza frecventa ca oricum coboara dupa prima. Ce laptop este mai exact ?

From Macro to SSL with Shellcode A Detailed Deconstruction petez on ‎03-09-2016 09:30 AM During the era of Windows 3.1 where “www” was just a repeated consonant and the internet was yet to enter the vernacular, Microsoft Office annoy-ware was already using macros within Office documents to cause mischief. It wasn’t until Mick Jagger’s “Start me up!” ushered in Windows95 (with Trumpet winsock for networking) that saw Office macros in the media with the Melissavirus. Back in those early days of Netscape, “co-operative multitasking,” and Doom II, the functionality of these macros was either parasitic or mass-mailing, but seldom did the complexity increase beyond the functionality offered by VBAScript. Why would they? The language was rich enough to write self-replicating code, send emails, and download files – more than enough to declare an undying love, as in the “I love you” virus. String obfuscation is cheap to perform but can quickly become far from trivial to detect generically. Much like the fashions of the late 1990’s, macro viruses fell out of vogue. Then in the last couple of years, macro viruses have returned. This article aims to deconstruct what is currently the new kid on the block. While not strictly necessary, I prefer to glance at one-off samples, such as incident responses, with a trusty hex-editor. This not only helps me familiarize myself with the file format, but it also presents an opportunity to spot hints on where to direct my attention next. The sample I chose to analyze clearly begins with the typical D0 CF 11 E0 magic, confirming this to indeed be an Office document file. Further strings below hint at this being a Microsoft Word file as opposed to an Excel spreadsheet or PowerPoint presentation. Figure 1 – Hex Workshop view of the sample Continuing to glance the hex dump, the presence of Auto-Open related strings hints that a macro and not some other form of exploit is the likely trigger mechanism. Figure 2 – Hex Workshop view showing Auto-Open related strings If the system does have macros enabled, this would not have been shown. When macros are not enabled (the default setting) the document employs a bit of social engineering. The warning and helpful instructions invite the recipient to enable macros, upon doing so invoking the malicious macro functionality. I do not however fall victim to this ruse. Figure 3 - Getting the user to enable macrosInstead I attempt to view the embedded macros using the Office Visual Basic editor. Clearly the macros are present but annoyingly have been password protected and so are not made visible.  Figure 4 Protected mode Although Office itself prevents the viewing of the Visual Basic macro without the password, this security feature is easily circumvented. Where are the macros? To extract the VBA macro for further study, I first tried some handy Python tools I have available. The comprises a handful of stand-alone, task-specific components designed to extract various information from an OLE container.  While the metadata and time information tools have their value, the oleid.py and olevba.py are the most useful for payload analysis. The olevba.py script not only allows for rapid triage and dumping of macro code but can also perform some basic analysis.  Another useful OLE tool used is oledump.py by Didier Stevens, which also has several options to show increasingly more detail. The stream hierarchy is a good overview, which makes the large macro at #8 and smaller one at #9 easy to spot for extraction. If Python is not your cup of tea, it may possible to manually extract the macro code with a hex editor – provided the OLE data is not compressed. However, care must be taken to ensure any artifacts get correctly handled. This is not recommended for the inexperienced.  Having extracted the macros into a separate file for convenience I can now clearly discern two main parts: an auto-open stub and the core functionality. Random names and various other obfuscations in macros is often indicative of maliciousness. Macro malware is often arranged this way thwart naïve macro analyzers relying on string matching. I can further break down the core functionality contained in function “tatata” into a few key logical blocks; declaration of variables, a shell call-out and some ‘glue’. The obvious long string of mostly base64 and a lightly obfuscated “POWERSHELL.EXE” are practically directing the analysis.  It is easy work to determine that the (randomly named) tatata function simply invokes powershell.exe and passes it the large string. The -enc flag is not used as a poor man’s obfuscator but actually for security circumvention for PowerShell. Peeling back the base64 layer is clearly the next step in deconstructing the sample, and I'm employing GNU's base64 on only the necessary part to reveal the PowerShell script. Macro gives rise to PowerShell As I glance the resulting script, three functional regions become apparent: setup, data, and glue. Of these, only the large blob of what is easily recognizable as hex data piques my interest. It is almost certainly going to be invoked as 32bit x86 code – hinted by the accompanying reference to win32 APIs. In addition, the ‘glue’ residing near the end does not appear to mangle the $z array, which means no additional transformation will be required.  PowerShell hexbytes condense to x86 Before being able to analyze this code, I need to massage the byte array from its textual form into an equivalent binary form conducive to disassembly. I achieve this thru nothing more than some fancy copy-paste (using the “interpret as hex” feature) into hex workshop to produce a 448 byte binary file I arbitrarily named sc.bin. Even for those familiar with x86 opcodes, the above hex-dump is unlikely to resemble valid code. This is mainly evident due to lack of 0x00's and common opcodes (a familiarity gained after many years). A quick peek with x86dis, an open-source x86 disassembler, reveals why:  The apparently absent call-pop, typically E8 00 00 00 00 58, is actually implemented using the FPU fnstenv instruction in conjunction with another preceding floating-point instruction (fcmovnb) then the ‘POP EDI’. Now I can establish EDI’s relative value after the fpu-call-pop. The fnstenv instruction saves the FPU state (including the EIP of the last FPU instruction) to some address, which here is ESP-0xC. The POP EDI then retrieves what is in effect the FPU states EIP member. This is how the shellcode locates itself in memory. After the POP, EDI will be the address of the first FPU instruction. I can now use this value to compute the target of the "XOR [EDI+0x18]" placing it a few (0x18 to be exact) bytes further.  I immediately realize that 0x18 is smack-bang in the middle of the shellcode I’m examining! More importantly, the XOR will modify the code as I see it. This reveals a classic snippet of self-modifying code. Navigating such self-modifying code in a disassembler is tedious, even for an experienced researcher and consequently, it's time to find a debugger or emulator. Of the abundant debuggers at hand, such as OllyDbg, WinDbg, IDA's own, gdb, etc., I found the x86emulator IDA plugin to be the most convenient for this particular task. Using a debugger would require too much faffing about with setup.  Now that I know what to expect, I carefully step thru just past the "XOR [EDI+0x18]" instruction as it patches the code just following. Revealed is a new backward “LOOP” that now forms a familiar decryptor.  Allowing the loop to run until completion reveals a second, similar decryptor at 0x2B, which I similarly overcame to finally reveal the inner workings of the shellcode. At this point I revert back to the analysis and annotation of the shellcode (made seamless by my choice to use the x86emul plugin). Figure 5 - IDA view of encoded shellcode being worked on by x86Emul plugin Swimming through the shellcode I continue the deconstruction at offset 0x37 as this is just after the second decryption loop. My analysis now follows execution-flow rather than linear address order, switching as may be required. I begin by observing a CALL which I determine must be to the body. I infer this by recognizing the alternate flow as a typical get-kernel32 and api-hash routine. Since I’m already expecting some form of API resolver, I ignore the code below the CALL and direct my attention to the target of the call, namely “body”.  As expected, the “POP EBP” at 0xBE confirms the “CALL body” does not return, serving only to get the address of the API-resolver into EBP. The next two immediate PUSHes collectively put the string 'ws2_32' on the stack (recalling that the stack grows down) while the “PUSH ESP” effectively puts the address of that string.  The final push of an unfamiliar 32bit value before “CALL EBP” must then be the hash of kernel32!LoadLibraryA by inference (‘ws2_32’ is the name of the windows networking library, and libraries are typically loaded by the LoadLibrary API). I confirm this assumption by later analyzing the code hashing code immediately following the “CALL body”.  The next part takes a leap of faith, or a decade of analysis experience. Knowing the following lets me speed ahead: A successful call of ‘WSAStartup’ returns zero in EAX The ‘socket’ API is required to transmit or receive network data A zero in the protocol argument of socket is acceptable (from MSDN: “…user does not wish to specify a protocol….”).  Working on the premise that the previous API was indeed ‘socket’, and noticing that this shellcode is thus far well-constructed, I’m left with two alternatives for the next API: either ‘connect’ to establish an outbound connection or 'bind' in preparation to accept an inbound connection. The choice is not a difficult one – following the execution flow in my minds-eye I observed no constructs resembling bind-listen-accept; so I chose ‘connect’. On that stride, what must be pushed is then the contents of the sockaddr_in structure, its size and subsequent address, socket descriptor, and lastly the APIs hash:  Using the sockaddr_in structure definition (remembering to byte-reverse where appropriate), I can identify the call-home IP and port number as [redacted] aaa.bbb.ccc.ddd where xxx=dec(xx), port 0x1bb (443, or the SSL port). As a reminder, here’s a basic picture of stack layout showing how the bytes map out to show the order and thus confirms the correct interpretation of the IP address.  Continuing the dissection, the next API-by-hash is reasoned to be ‘recv’. I already know it is socket related thru EDI, and an essentially undefined buffer is being passed in ESI. The hash value is also referenced later by fragments that only make sense for ‘recv’.  When the ‘recv’ API returns (assuming no error) ESI will point to a 4byte (32bit word, aka dword) value received from the network. The code will then xor the recv'd dword by some 32bit constant. This is likely done to obfuscate and/or avoid null bytes.  The next API is easily recognized by its arguments as ‘VirtualAlloc’, and since the previously xor’ed dword is directly passed to it as the size argument (ECX), it reveals it to be just that – the size of data to receive.  The alloc’d pointer in EAX is nudged by 0x100 and some registers saved. For now, I skip over this and expect the purpose will reveal itself in due time.  Now the already familiar hash for ‘recv’ (0x5FC8D902) makes understanding the next fragment simple - receive from the socket until the required number of bytes have been obtained.  Did that look like SSL? The astute reader will at this point have realized that despite the SSL port being contacted, there is a distinct lack of typical SSL negotiation traffic being sent or expected. Whereas real SSL negotiation should begin with a well-defined ClientHello message, the data actually observed (and expected by the malware) has a different structure. Real SSL traffic has a specific structure that differs from what is observed. A leading dword specifying size followed by ‘size’ bytes of RC4 encrypted data; as derived from the code that manipulates the content of the received buffer. Figure 6 - Redacted TCP reconstruction So what happens with the data? Realizing that the network exchange does not appear to be SSL, I continue analysis to learn how the received data is to be utilized. This must be the code when the exit condition of the recv-loop is met (all expected bytes received) at 0x164. Here we find a CALL to a function a short distance away that is recognizable as RC4. The key is in-lined immediately following the CALL and obtained by the pop into ESI.  That bit of code strongly resembles RC4 but caution! I say “resembles” since minor variations on the theme are difficult to spot, and would fail to decrypt with RC4-proper. I’ve not gone the extra mile to verify however, since 99% of the time it is unnecessary. How did I identify this as (likely) RC4? Easily! RC4 consists of three parts: initialize sbox, permute sbox with a key, and encrypt/decrypt data. More importantly, the sbox is 0x100 bytes, and is initialized with the index stored at each respective location. This also explains the nudge by 0x100 earlier. Application to data capture To decrypt the data-stream I had previously captured, I simply loaded the shellcode into a debugger, grafted the data at some nearby address, fixed up the relevant registers and ran it until the ‘RET’ at +0x1BF. Voila! An “MZ” appears! But wait – where does execution continue? Examining the shellcode leads me to conclude that the address of the buffer (now containing a PE file) is what remains on the stack prior to the ‘RET’… And so resulting in returning execution at the MZ header!? Why sure! The IDA window shows the loader executing “dec ebp ; pop edx” (aka “MZ”) in clever code-data alias. It is this loader stub hidden inside the MZ header that does the ReflectiveLoader call. Figure 7 - Ida view showing the “MZ” header as instructions (0x4d => ‘M’, 0x5a => ‘Z’) It turns out that without too much effort, the first function being called by this stub is ReflectiveLoader, and the module is metsrv.dll of Metasploit fame. Sanity-checking also confirms the modules size matching exactly the payload size. I leave to the reader to confirm the api_by_hash function is as suggested, and perhaps a topic for another day. Conclusion Use of Office auto-action macros made even more successful by a simple ruse was only the first step in this complex chain of events. The malware then obfuscated VBA by invoking Powershell to construct and launch non-obvious self-modifying shellcode. It then masqueraded as an outbound SSH connection to fly below-the-radar in order to download a Metasploit module. Once this agent has been deployed, there is no telling what else it had brought with it! Astute readers may have noticed that deep-packet inspection would probably have caught this non-conforming-ssl-attempt, but I’m sure the next revision will have a fix for that! Sursa: http://community.hpe.com/t5/Security-Research/From-Macro-to-SSL-with-Shellcode-A-Detailed-Deconstruction/ba-p/6839623#.VuE2wfl96Uk

The perils of Java deserialization alvaro_munoz on ‎03-04-2016 12:43 PM Java provides a mechanism called object serialization, which allows an object to be represented as a sequence of bytes that includes the object's data as well as information about the object's type and the types of data stored in the object. The sequence of bytes can be used to deserialize the object graph by using the type information and bytes that represent the object and its data to recreate the object in memory. Java serialization is used by applications for multiple purposes; furthermore, Java serialization is not only used explicitly in application code. It is also used behind the scenes in many known and popular protocols. Security issues with Java deserialization have been known for years. However, interest in the issue intensified greatly in 2015, when classes that could be abused to achieve remote code execution were found in a popular library (Apache Commons Collections). These classes were used in zero-days affecting IBM WebSphere, Oracle WebLogic, and other products, and the details were disclosed publically with no previous notification to vendors. The security community focused on exploring these issues, and as a result mitigation advice was published describing various ways to protect against this kind of attack. Understanding where and why Java serialization is used in your applications, libraries, and frameworks will greatly help you to design an architecture to prevent this kind of attack. While it is possible (although not always easy) to protect the cases in which Java serialization is explicitly used in your application code, the cases in which it is used by frameworks and libraries may require additional security controls, as we document in this paper. In our paper, we review the basics of the Java deserialization process and explain how and why it becomes vulnerable. We will show how different Java classes – referred to as gadgets throughout the paper – can be abused by attackers during the deserialization process to compromise or attack applications and servers. We explain how attackers can leverage these gadget classes for their own purposes. We examine several remote code execution gadgets to show how these attacks chain multiple pieces of code to craft the malicious payload. We review available mitigation advice and present a new technique to bypass some of the recommended protections. Finally, we conclude by reviewing how the problem affects similar libraries, and wrap up by offering our own mitigation strategies to more effectively protect against this problem. Paper: HPE-SR whitepaper java deserialization RSA2016.pdf ‏2580 KB Sursa: http://community.hpe.com/t5/Security-Research/The-perils-of-Java-deserialization/ba-p/6838995#.VuE1pfl96Ul