Nytro

Interview: Bjarne Stroustrup Discusses C++ Bjarne Stroustrup and William Wong C and C++ are the main programming languages for embedded computing and for a host of other application areas as well. C++ was developed by Bjarne Stroustrup and he was gracious enough to answer a few of my questions about C++ and its development. He not only developed the initial version of C++ but has been actively involved in updating through the latest standard, C++11. He has also taught and written about C++ with books like “Programming: Principles and Practice using C++.” Wong: How did you get started designing C++? Stroustrup: I needed a tool to help me on a project where I needed hardware access, high performance for systems programming tasks, and help with handling complexity. The project was to “split” a Unix kernel into parts that could run on a multi-processor or a high-performance local network. At the time (1979/80), no language could meet all three requirements, so I added Simula-like classes to C. The earliest designs added function argument checking and conversion (what later became C function prototypes), constructors and destructors, and simple inheritance. Interestingly, my earliest paper on “C with Classes” as it was called in the early years, used macros to implement a simple form of generic programming – later I found that didn’t scale and I had to add templates. Over the next few years, my design (and implementation) was refined until the commercial release of C++ in 1985. Performance and hardware access was very important in the early years – as it still is. I considered it essential to be able to do everything C could do and to do it at least as efficiently. For example, early on, I found that to handle copy constructors, I had introduced a 3% overhead for returning structure values compared to C. I considered that unacceptable and by the end of the week the overhead was gone. Function call inlining was introduced to be able to handle interrupts in an embedded processor without the overhead of a function call and without forcing programmers to abandon classes to handle interrupts. The idea that facilities shouldn’t just be expressive and elegant, but also needed to be affordable in the most demanding applications was very important to me. Wong: What were/are the major design goals for C++? Stroustrup: A way of mapping C++ language features to machine facilities that is at least as direct and efficient as C’s plus abstraction mechanisms that allows programmers to express ideas beyond what I can imagine with no overhead compared to hand-crafted code. This implies static (compile-time) type checking. C++ was and is meant to be a tool for professionals and for people who takes programming seriously. It can and is used by novices, but the too often heard complaint that “C++ isn’t for everybody and not every project is easily done using C++” is based on a seriously miscomprehension. There can be no programming language that is perfect for everybody and for everything. C++ doesn’t try to be everything for everybody, but it is rather good at the tasks for which it was designed – mostly systems programming, software infrastructure, and resource-constrained applications. C++ dominates the fields where its strengths are needed. The fact that you can write a simple web app easier using JavaScript or Ruby does not bother me. Basically, C++ was not primarily designed for tasks of medium complexity, medium performance, and medium reliability, written by programmers of medium skills and experience. Obviously, it can be used for that and is widely used for that, but that’s not its areas of specific strength compared to many other languages. I documented my design aims and the constraints on the design in my book “The Design and Implementation of C++” and in my two History of Programming Languages conference papers, but briefly, I aim for zero overhead compared to hand-crafted code when using abstractions, a machine model very similar to that of C, an extremely flexible set of abstraction mechanism, and static type safety. The overall aim is to help produce better code for challenging real-world tasks, and “to make programming more pleasant for the serious programmer.” Obviously, I can’t get all of what I would like in every situation. So C++ isn’t perfect. However, Despite innumerable attempts to displace it, C++ is still the best match for its stringent design criteria and for a huge range of real-world problems. Wong: You have been working with the standard since it started. How has it changed over time and where is it headed? Stroustrup: That’s hard to say. Formal standardization is a very hard and often tedious task. The people involved are usually clever and experienced, but they come from very diverse backgrounds and often represent major industrial interests, so constructing a consensus can be very difficult and is time consuming. Creating a consensus is essential because there is no way to force implementers to provide a faithful version of the standard and no way of forcing programmers to use novel features. Only by providing something almost universally agreed to be genuinely useful can we make progress. A standard committee is no place for single-issue fanatics. My estimate is that close to 100 organizations and maybe 300+ individuals are involved. That’s two to three times the numbers in the early years. We have had close to 100 people attending recent meetings. Our plan is to issue a new standard with minor new features and corrections in 2014, C++14. This will almost certainly happen because we have already had national body votes on the changes and implementations of every new feature are available somewhere. I expect to be using C++14 in 2014. After that, there is a plan for C++17 in 2017. That will be a more major upgrade, so I can’t be quite as optimistic about the timing. The ISO C++ standards committee has no resources (money, time, developers). The members actually have to pay $1200 a year to participate. If you don’t like what we do, don’t just complain. Don’t just say “I want a GUI library” or “there is no proper support for task-based concurrency” or whatever. We know that. Instead, come help us to get the work done right. We are always short of experienced application builders, so novel features have tendency to overly reflect the interests of implementers and library builders. Wong: Many embedded designers choose to use C because “it is simpler and closer to the hardware” than C++. Do you think that complexity of C++ should be a deterrent to embedded designers? Stroustrup: No. C isn’t simpler for C-style programming than C++ is, nor “closer to the hardware,” nor indeed more efficient. I have yet to see a program that can be written better in C than in C++. I don’t believe such a program could exist. By “better” I mean smaller, more efficient, or more maintainable. The myth that “C is simpler and more efficient” have caused (and causes) untold numbers of beginners to concentrate on obscure workarounds and difficult-to-master techniques, rather than learning how to use more powerful supporting features. Many then fall in love with their obscure and complex code, considering it a sign of expert knowledge. It is amazing what people can fail to learn when they are told that it is difficult and useless. The only reason I know of to use “plain C” rather than a suitable subset of C++ is lack of tool support on a given platform. We can’t just blame the beginners/novices/students, though. The presentation and teaching of C++ has been a constant problem. Almost a decade ago, when I first was to teach programming to freshman engineering students, I looked at the textbooks using C++ and despaired. More precisely, I did not despair, I was furious! There were (and are) books teaching every little obscure detail of C before getting to the far-easier-to-use C++ alternatives, and deeming those alternatives “advanced” to scare off all but the most determined student. Seriously, how could a standard-library vector be as hard to use well as a built-in array? How could using qsort() be simpler than using the more general and efficient sort()? C++ provides better notational support and stronger type checking than C does. This can lead to faster object code. Other books presented (and presents) C++ as a somewhat failed attempt to be a “pure object oriented programming language” and force most every operation into class hierarchies (a la Java) with lots of inheritance and virtual functions. The result is verbose code with unnatural couplings, and lots of casting. To add insult to injury, such code also tends to be slow. As I said: if that’s C++, I don’t like it either! I responded by writing a textbook for college freshmen and determined self-learners: “Programming: Principles and Practice using C++.” It does not assume previous programming experience, though it has been popular with programmers wanting to know what C++ is about. That book is a bit long for experienced programmers wanting a quick look at what C++11 is like. For that I recommend “A Tour of C++” which presents all the major features of ISO C++ and its standard library in just 180 pages! C++11 is completely supported by Clang and GCC, and partially by Microsoft C++ and many other implementations. I fear that C++11 support is still be a bit spotty of less mainstream systems. Wong: C++11 has added a number of features including lambdas and threading support. How has your view of features like these changed over time? Stroustrup: I have wanted thread support in the standard for at least 15 years. Now I finally got it after having to have to use nice, but non-standard, thread libraries for decades. C++11’s contribution to concurrent programming is the memory model (now also adopted by C) and to make traditional threads-and-locks level programming portable and type-safe. That’s major. No macros and void**s are needed to share information and pass information between threads. For some, the facilities for lock-free programming are also important. I have been concerned about lambdas for a while (maybe a decade), looking for a variant of the (inherently good) idea that would do more good than harm in the context of C++. The performance of the library versions were not sufficiently good, but the performance of the current implementations of C++11 lambdas (in current compilers) is as good as that of equivalent for-loop bodies. For example: double sum = 0; for (int I =0; i<v.size(); ++i) sum += v[i]; // array style and double sum = 0; for (auto p = v.begin(); p!=v.end(); ++p) sum += *p; // pointer style and double sum = 0; for_each(v.begin(),v.end(), [&](double d) { sum += d; }); // algorithm style These alternatives now run at exactly the same speed on all major C++ compilers. That is, we can now choose between those styles based on aesthetics, maintainability, etc. There are quite a few places where I use lambdas in preference to alternatives. For example: sort(v, [](const string& a, const string& b) { return a>b; }); // sort in reverse order That said, lambdas is a new and powerful feature. Such features are always overused until the community learns what pays off in the long run. In my opinion, it is often worthwhile to separately define a function or a function object so that the operation can have a specific name, can be used from multiple places in a program and where there is space for a helpful comment. Lambdas can easily become and exercise in write-only code. This is not the place to teach C++11, but let me give just one example: template<typename C, typename V> vector<Value_type<C>*> find_all(C& cont, V v) // find all occurrences of v in cont { vector<Value_type<C>*> res; for (auto& x : cont) if (x==v) res.push_back(&x); return res; } Here, I use several new features. The new for-loop, a range-for loop, is read “for all x in cont” and simplifies traversing the container cont. The auto& x declaration says that the type of x should be a reference to the type of the elements in the initializer of x, that is, a reference to the type of elements in cont. The loop collects the addresses of all occurrences of v in cont in the vector of pointers res. So far, the new features here have been merely “syntactic sugar,” but these are rather nice and useful notational improvements. The real novelty here is the return statement: Note that I return a potentially huge vector by value. In C++98, that would typically cause the copy of all elements of res, potentially many thousands of elements. That would be a serious performance bug. In C++11, vector has a “move constructor,” so that rather than copying elements, the representation of res (merely three pointers) is “stolen” for use in the caller and an empty vector is left behind. After all, we are just about to return from find_all() and won’t be able to use res again. Thus, returning a vector by value costs at most six word assignments independently of the number of elements. Move constructors is a simple facility available to every programmer and used by all standard-library containers implemented as handles. This allows us to return large objects from a function without messing around with memory management (explicitly) using pointers and free store. We can test find_all() like this: void test() { string m {"Mary had a little lamb"}; for (const auto p : find_all(m,'a')) // p is a char* if (*p!='a') cerr << "string bug!\n"; vector<string> v {"Mary”, “lamb", “Mary”, “mary”, “wolf”}; for (const auto p : find_all(v,”Mary”)) // p is a string* if (*p!=”Mary”) cerr << "vector<string> bug!\n"; } Feel free to compare this to a hand-crafted version without templates or C++11 features. For more information, read “A Tour of C++.” For all the details see “The C++ Programming Language (Fourth Edition).” Wong: What common mistakes do you see new C++ developers making? Stroustrup: They think they have to choose between “efficiency” and elegance, so they either stick to a small low-level subset (“for efficiency”) or build bloated “do-everything” designs (deeming those elegant). My ideal is for the most efficient code also to be the most elegant. That happens when you have a perfect fit between a problem and a solution. Obviously, you can’t always achieve that and you rarely achieve it at the first try, but it happens often enough for the ideal to be of practical relevance. Before dismissing C++ features, such as classes and templates, for demanding tasks, learn the basics of their use and try them out. Measure, rather than guessing about performance! Do not feel obliged to craft huge hierarchies or write complicated template meta-programs. Some of the most powerful C++ features are quite simple and leads to good object code. One of the best ways to get efficient code is to write simple source code. Wong: What do you like to do for fun? Stroustrup: Travel to interesting places, run, take photographs, listen to music, read (literature and history), spend time with family and friends. Of course, some of my programming is great fun also, but I guess you weren’t asking about work. Research and advanced system building is fun. As they say “I can’t believe we are getting paid for doing this!” Sursa: Interview: Bjarne Stroustrup Discusses C++ | Dev Tools content from Electronic Design

[h=1]Car hackers mess with speedos, odometers, alarms and locks[/h]By Darren Pauli on Oct 29, 2013 5:10 PM If you lend your car to Ted Sumers and Grayson Zulauf, there's a good chance it'll never work the same again. You might even get it back on a tow truck. The duo weren't street hoons but rather a pair of capable hardware hackers who know how to mess with a car's speedometre, brakes and alert systems. They were the latest in a burgeoning scene of academics and security boffins who along with a thriving but fragmented assortment of rev-head hobbyist geeks are battering the digital fabric powering modern-day cars. When Sumers and Zulauf began their research, they did not let the lack of computer documentation, the exorbitant costs of proprietary computer analysis kits or tight-lipped mechanics stop them. Speaking at the Breakpoint security conference in Melbourne, the researchers from automtive startups Automatic and Motiv Power Systems told how together with Chris Hoder of Microsoft the trio set off to discover how the digital bits flew around Controller Area Networks (CANs) embedded into many cars in use today. With physical access to the cars the men were able to make vehicles appear to drive slower than actual speed, manipulate brakes, alarms and unlock doors. They could also increase a car's odometer and with further research wind it back. Other researchers have accessed car networks via bluetooth and developed ways to compromise autos through firmware. The capabilities of CAN hacking were vast. In August, researchers Charlie Miller and Chris Valasek tapped into CANs to cut the brakes of a Ford Escape and caused the wheel of a Ford Focus to jerk out of the hands of a driver at high speed. Other hobbyists have used CAN bus hacking to alter functions such as the fuel injection levels of cars with some creating legitimate car customisation businesses using their skills. Criminals too have benefitted. Sumers said recent years a criminal gang sold a device they created to unlock doors for pricey Audis via a port that remarkably could be accessed from an exterior panel on the vehicle. A spate of car thefts resulted until their arrest. But much of the important parts of the research needed to start hacking CANs was not available, the researchers said. This forced them in their bid to deliver a project for the University of Dartmouth and open the field to others to effectively "start from ground zero". After initial trial and error -- and the purchase of a second car -- they gained access to the CAN and began fuzzing against to identitfy which of the arbitration ID packets were sent to particular components of the vehicle such as the speedometre, brakes and dashboard indicators. "The car started making horrible noises -- every light on the dashboard was blinking," Zulauf said. "If you do this yourself you might want to use a friend's car," Sumers added. Like other consumer products such as smart TVs and network-connected white goods, most vehicles were designed for functionality and paid little or no homage to security. The trio, for example, found that CAN transmissions contained no authentication requirements because car designers built the architecture with the intent it would operate in closed secure environments. Sumers said manufacturers would unlikely be able to introduce authentication because it would slow down the CANs too much. Indeed Ford and Toyota have not moved to fix the weaknesses, saying that the hacking scenarios were academic and did not place drivers at risk. The CANs also ran as single networks within all but the high-end vehicles -- notably the "over-engineered" German autos -- meaning that their fuzzing efforts were easier. Their fuzzing processes worked by a system of sniffing, searching and probing using Travis Goodspeed's GoodTHOPTER10. They would monitor CAN packets, find those that appeared interesting and then seek out what systems within the cars that they controlled. Breakpoint 2013 Inside car CAN hacking by Darren Pauli on Mixcloud The trio were keen for others to enter the hacking field and have produced a $25 open-modular source hardware tool for reading CANs that has the capability of those worth tens of thousands. "The more people play with it, the better it will get," Sumers said, adding that he was keen to learn how different CAN implementations were. Copyright © SC Magazine, Australia Sursa: http://www.scmagazine.com.au/News/362297,car-hackers-mess-with-speedos-odometers-alarms-and-locks.aspx

Trebuia sa le sparga muie ratatilor de la ProTV. NSA infiltrates links to Yahoo, Google data centers worldwide, Snowden documents say - The Washington Post

Table of Contents Cryptography and Computation Practical Covertly Secure MPC for Dishonest Majority – Or: Breaking the SPDZ Limits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Ivan Damg?ard, Marcel Keller, Enrique Larraia, Valerio Pastro, Peter Scholl, and Nigel P. Smart Practical and Employable Protocols for UC-Secure Circuit Evaluation over Zn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Jan Camenisch, Robert R. Enderlein, and Victor Shoup Privacy-Preserving Accountable Computation . . . . . . . . . . . . . . . . . . . . . . . 38 Michael Backes, Dario Fiore, and Esfandiar Mohammadi Measurement and Evaluation Verifying Web Browser Extensions’ Compliance with Private-Browsing Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 Benjamin S. Lerner, Liam Elberty, Neal Poole, and Shriram Krishnamurthi A Quantitative Evaluation of Privilege Separation in Web Browser Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 Xinshu Dong, Hong Hu, Prateek Saxena, and Zhenkai Liang Estimating Asset Sensitivity by Profiling Users . . . . . . . . . . . . . . . . . . . . . . 94 Youngja Park, Christopher Gates, and Stephen C. Gates Applications of Cryptography Practical Secure Logging: Seekable Sequential Key Generators . . . . . . . . . 111 Giorgia Azzurra Marson and Bertram Poettering Request-Based Comparable Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 Jun Furukawa Ensuring File Authenticity in Private DFA Evaluation on Encrypted Files in the Cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 Lei Wei and Michael K. Reiter XIV Table of Contents Code Analysis HI-CFG: Construction by Binary Analysis and Application to Attack Polymorphism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 Dan Caselden, Alex Bazhanyuk, Mathias Payer, Stephen McCamant, and Dawn Song AnDarwin: Scalable Detection of Semantically Similar Android Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 Jonathan Crussell, Clint Gibler, and Hao Chen BISTRO: Binary Component Extraction and Embedding for Software Security Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 Zhui Deng, Xiangyu Zhang, and Dongyan Xu Network Security Vulnerable Delegation of DNS Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . 219 Amir Herzberg and Haya Shulman Formal Approach for Route Agility against Persistent Attackers . . . . . . . . 237 Jafar Haadi Jafarian, Ehab Al-Shaer, and Qi Duan Plug-and-Play IP Security: Anonymity Infrastructure instead of PKI . . . 255 Yossi Gilad and Amir Herzberg Formal Models and Methods Managing the Weakest Link: A Game-Theoretic Approach for the Mitigation of Insider Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273 Aron Laszka, Benjamin Johnson, Pascal Sch¨ottle, Jens Grossklags, and Rainer B¨ohme Automated Security Proofs for Almost-Universal Hash for MAC Verification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291 Martin Gagn´e, Pascal Lafourcade, and Yassine Lakhnech Bounded Memory Protocols and Progressing Collaborative Systems . . . . 309 Max Kanovich, Tajana Ban Kirigin, Vivek Nigam, and Andre Scedrov Universally Composable Key-Management . . . . . . . . . . . . . . . . . . . . . . . . . . 327 Steve Kremer, Robert K¨unnemann, and Graham Steel Table of Contents XV Protocol Analysis A Cryptographic Analysis of OPACITY (Extended Abstract) . . . . . . . . . . 345 ¨ Ozg¨ur Dagdelen, Marc Fischlin, Tommaso Gagliardoni, Giorgia Azzurra Marson, Arno Mittelbach, and Cristina Onete Symbolic Probabilistic Analysis of Off-Line Guessing . . . . . . . . . . . . . . . . . 363 Bruno Conchinha, David Basin, and Carlos Caleiro ASICS: Authenticated Key Exchange Security Incorporating Certification Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381 Colin Boyd, Cas Cremers, Mich`ele Feltz, Kenneth G. Paterson, Bertram Poettering, and Douglas Stebila Privacy Enhancing Models and Technologies Efficient Privacy-Enhanced Familiarity-Based Recommender System . . . . 400 Arjan Jeckmans, Andreas Peter, and Pieter Hartel Privacy-Preserving User Data Oriented Services for Groups with Dynamic Participation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418 Dmitry Kononchuk, Zekeriya Erkin, Jan C.A. van der Lubbe, and Reginald L. Lagendijk Privacy-Preserving Matching of Community-Contributed Content . . . . . . 443 Mishari Almishari, Paolo Gasti, Gene Tsudik, and Ekin Oguz E-voting and Privacy Ballot Secrecy and Ballot Independence Coincide . . . . . . . . . . . . . . . . . . . . 463 Ben Smyth and David Bernhard Election Verifiability or Ballot Privacy: Do We Need to Choose? . . . . . . . 481 ´ Edouard Cuvelier, Olivier Pereira, and Thomas Peters Enforcing Privacy in the Presence of Others: Notions, Formalisations and Relations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 499 Naipeng Dong, Hugo Jonker, and Jun Pang Malware Detection Mining Malware Specifications through Static Reachability Analysis . . . . 517 Hugo Daniel Macedo and Tayssir Touili Patrol: Revealing Zero-Day Attack Paths through Network-Wide System Object Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 536 Jun Dai, Xiaoyan Sun, and Peng Liu XVI Table of Contents Measuring and Detecting Malware Downloads in Live Network Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 556 Phani Vadrevu, Babak Rahbarinia, Roberto Perdisci, Kang Li, and Manos Antonakakis Access Control Automated Certification of Authorisation Policy Resistance . . . . . . . . . . . 574 Andreas Griesmayer and Charles Morisset Fine-Grained Access Control System Based on Outsourced Attribute-Based Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 592 Jin Li, Xiaofeng Chen, Jingwei Li, Chunfu Jia, Jianfeng Ma, and Wenjing Lou Purpose Restrictions on Information Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . 610 Michael Carl Tschantz, Anupam Datta, and Jeannette M. Wing Distributed Shuffling for Preserving Access Confidentiality . . . . . . . . . . . . 628 Sabrina De Capitani di Vimercati, Sara Foresti, Stefano Paraboschi, Gerardo Pelosi, and Pierangela Samarati Attacks Range Extension Attacks on Contactless Smart Cards . . . . . . . . . . . . . . . . 646 Yossef Oren, Dvir Schirman, and Avishai Wool CellFlood: Attacking Tor Onion Routers on the Cheap . . . . . . . . . . . . . . . . 664 Marco Valerio Barbera, Vasileios P. Kemerlis, Vasilis Pappas, and Angelos D. Keromytis Nowhere to Hide: Navigating around Privacy in Online Social Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 682 Mathias Humbert, Th´eophile Studer, Matthias Grossglauser, and Jean-Pierre Hubaux Current Events: Identifying Webpages by Tapping the Electrical Outlet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 700 Shane S. Clark, Hossen Mustafa, Benjamin Ransford, Jacob Sorber, Kevin Fu, and Wenyuan Xu Language-Based Protection Eliminating Cache-Based Timing Attacks with Instruction-Based Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 718 Deian Stefan, Pablo Buiras, Edward Z. Yang, Amit Levy, David Terei, Alejandro Russo, and David Mazi`eres Table of Contents XVII Data-Confined HTML5 Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 736 Devdatta Akhawe, Frank Li, Warren He, Prateek Saxena, and Dawn Song KQguard: Binary-Centric Defense against Kernel Queue Injection Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 755 Jinpeng Wei, Feng Zhu, and Calton Pu Run-Time Enforcement of Information-Flow Properties on Android (Extended Abstract) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 775 Limin Jia, Jassim Aljuraidan, Elli Fragkaki, Lujo Bauer, Michael Stroucken, Kazuhide Fukushima, Shinsaku Kiyomoto, and Yutaka Miyake Author Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 793 Da, not bad

https://www.exodusintel.com/files/Aaron_Portnoy-Bypassing_All_Of_The_Things.pdf

Software Defense: mitigating heap corruption vulnerabilities swiat 29 Oct 2013 4:10 AM Heap corruption vulnerabilities are the most common type of vulnerability that Microsoft addresses through security updates today. These vulnerabilities typically occur as a result of programming mistakes that make it possible to write beyond the bounds of a heap buffer (a spatial issue) or to place a heap allocated object in an unexpected state such as by using the object after it has been freed (a temporal issue). Over time, attackers have developed a number of techniques to help them exploit various types of heap corruption vulnerabilities. Starting with Windows XP Service Pack 2, Microsoft began introducing hardening changes to the Windows heap manager that were designed to make it more difficult to exploit heap corruption vulnerabilities. In this blog post, we will review some of the general methods that have been used to exploit and mitigate heap corruption vulnerabilities and highlight hardening changes that have been made in Windows 8 and Windows 8.1 to further complicate exploitation. For more background on the Windows 8 heap architecture, please refer to the Channel 9 interview on the Windows 8 heap manager. Heap corruption exploitation, then and now In a previous blog post, we covered the history of heap-based exploitation and mitigation techniques from Windows XP through Windows 7. This blog post showed that prior to Windows Vista, most of the research on heap corruption exploitation techniques focused on corrupting heap metadata in order to achieve more powerful exploitation primitives (such as the ability to write an arbitrary value to any location in memory). One of the reasons attackers focused on corrupting heap metadata is because it was always present and therefore could enable application-independent (generic) exploitation techniques. The release of Windows Vista changed the landscape of heap exploitation through numerous heap hardening changes that addressed nearly all of the heap metadata corruption exploitation techniques that were known at the time. As a consequence of the hardening changes in Windows Vista, attackers have largely shifted their focus toward exploitation techniques that rely on corrupting application-specific data stored on the heap. For example, attackers will attempt to use a heap corruption vulnerability to corrupt the C++ virtual table pointer of an object on the heap or to corrupt the base or length field of a heap-allocated array to achieve the ability to read or write to any location in memory. There has been additional research on heap metadata corruption post-Windows Vista and there are a small number of known real-world exploits that have relied on these metadata corruption techniques[1,2,3,4], but as this blog post will show, all of the publicly known exploitation techniques that rely on metadata corruption have been addressed in Windows 8.1. Heap corruption mitigations The heap manager in Windows 8 and Windows 8.1 builds on the hardening changes of previous Windows releases by incorporating new security features that mitigate not only metadata corruption techniques but also less generic techniques that rely on corrupting application-specific data. These new security features can be broken down into the following threat categories: heap integrity checks, guard pages, and allocation order randomization. All of the security features introduced in Windows 8 have been inherited by Windows 8.1. Heap integrity checks The heap manager in Windows 8 and Windows 8.1 includes a number of new integrity checks that are designed to detect heap metadata corruption and terminate an application safely if corruption is detected. This section describes some of the noteworthy integrity checks that have been added. Catch-all exception handling blocks have been removed Previous versions of the Windows heap made use of catch-all exception handling blocks in certain cases where exceptions were considered non-fatal. This had the potential to make it easier for attackers to exploit heap corruption issues in certain cases, in particular by allowing an attacker multiple attack attempts. Therefore, these catch-all blocks have been removed from the heap in Windows 8, meaning such exceptions now lead to safe termination of the application. HEAP handle can no longer be freed The HEAP handle is an internal data structure that is used to maintain the state associated with a given heap. Prior to Windows 8, an attacker could use a heap-based memory corruption vulnerability to coerce the heap into freeing the HEAP handle data structure. After doing this, the attacker could force the heap to reallocate the memory that previously stored the HEAP handle state. This in turn allowed an attacker to corrupt internal heap metadata, including certain function pointer fields. The Windows 8 heap mitigates this attack by preventing a HEAP handle from being freed. HEAP CommitRoutine encoded by a global key The HEAP handle data structure includes a function pointer field called CommitRoutine that is called when memory regions within the heap are committed. Starting with Windows Vista, this field was encoded using a random value that was also stored as a field in the HEAP handle data structure. While this mitigated trivial corruption of only the CommitRoutine function pointer, it did not mitigate the case where an attacker could corrupt both the CommitRoutine and the field that stored the encoding key. The Windows 8 heap mitigates this attack by using a global key to encode the CommitRoutine function pointer rather than a key that is stored within the HEAP handle data structure. Extended block header validation Each heap allocation returned by the Windows heap has a header that describes the allocation’s size, flags, and other attributes. In some cases, the Windows heap may flag an allocation as having an extended block header which informs the heap that there is additional metadata associated with the allocation. In previous versions of Windows, an attacker could corrupt the header of an allocation and make it appear as if the allocation had an extended block header. This could then be used by an attacker to force the heap to free another allocation that is currently in use by the program. The Windows 8 heap mitigates this attack by performing additional validation on extended block headers to ensure that they are correct. Blocks cannot be allocated if they are already busy Some of the attacks that have been proposed by security researchers rely on reallocating memory that is already in use by the program (e.g. [3]). This can allow an attacker to corrupt the state of an in-use heap allocation, such as a C++ object, and thereby gain control of the instruction pointer. The Windows 8 heap mitigates this attack by verifying that an allocation is not already flagged as in-use (“busy”) when it is about to be allocated. If a block is flagged as in-use, the heap takes steps to safely terminate the process. Encoded FirstAllocationOffset and BlockStride One of the exploitation techniques proposed in [4] involved corrupting heap metadata (FirstAllocationOffset and BlockStride) that is used by the Low Fragmentation Heap (LFH) to calculate the address of an allocation within a subsegment. By corrupting these fields, an attacker can trick the heap into returning an address that is outside the bounds of a subsegment and potentially enable corruption of other in-use heap allocations. The heap manager in Windows 8.1 addresses this attack by encoding the FirstAllocationOffset and BlockStride fields in order to limit an attacker’s ability to deterministically control the calculation of allocation addresses by the LFH. Guard pages One of the ways that the Windows 8 heap better protects application data and heap metadata is through the use of guard pages. In this context, a guard page is an inaccessible page of memory that will cause an access violation if an application attempts to read from it or write to it. Placing a guard page between certain types of sub-regions within the heap helps to partition the heap and localize any memory corruptions that may occur. In an ideal setting, the Windows heap would encapsulate all allocations in guard pages in a manner that is similar to full-page heap verification. Unfortunately, this type of protection is not feasible for performance reasons. Instead, the Windows 8 heap uses guard pages to isolate certain types of sub-regions within the heap. In particular, guard pages are enabled for the following types of sub-regions: Large allocations. In cases where an application attempts to allocate memory that is larger than 512K (on 32-bit) or 1MB (on 64-bit), the memory allocation request is passed directly to the virtual memory allocator and the size is updated to allocate extra space for a guard page. This ensures that all large allocations have a trailing guard page. Heap segments. The Windows heap allocates large chunks of memory, known as heap segments, which are divided up as an application allocates memory. The Windows 8 heap adds a trailing guard page to all heap segments when they are allocated. Maximally-sized subsegments. Each heap segment may contain one or more subsegment that is used by the frontend allocator (the Low Fragmentation Heap, or LFH) to allocate blocks of the same size. Once a certain threshold has been reached for allocating blocks of a given size, the LFH will begin allocating maximally-sized subsegments, which are subsegments that contain the maximum number of blocks possible for a given size. The Windows 8 heap adds a trailing guard page to maximally-sized subsegments. For 32-bit applications, guard pages are inserted probabilistically to minimize the amount of virtual address space that is consumed. Allocation order randomization One of the behaviors that attackers rely on when exploiting heap buffer overruns is that there must be a way to reliably position certain heap allocations adjacent to one another. This requirement stems from the fact that an attacker needs to know how many bytes must be written in order to corrupt a target allocation on the heap (while minimizing collateral damage to the heap that could cause the application and hence the attack to be terminated). Attackers typically try to ensure that allocations are immediately adjacent to each other through techniques that are often referred to as heap massaging or heap normalization. These techniques attempt to bring the heap into a state where new allocations are placed at a desired location with respect to one another. In Windows 8, a new security feature has been added to the LFH which randomizes the order of allocations. This means that allocations that are made through the LFH are no longer guaranteed to be placed immediately adjacent to one another even after an attacker has attempted to normalize the heap. This has the effect of preventing an attacker from reliably assuming that an allocation containing a target object will be positioned after the allocation that they are able to overflow. While an attacker may attempt to increase the reliability of their attack by corrupting more data or allocating more target objects, they run the risk of destabilizing the process by corrupting other heap state or causing the process to terminate by accessing a guard page as described in the previous section. This is a good example of several mitigations working together: neither is foolproof on its own, but combined they result in increasingly complex requirements for a successful attack. Although allocation order randomization helps make the internal layout of the heap nondeterministic, there are limitations to how far it goes. First and foremost, the performance of the Windows heap is critical as it is used as a general purpose memory allocator by the vast majority of the applications that run on Windows. As a side effect of this, allocation order randomization is currently limited to randomizing allocations within individual LFH subsegments (which accounts for the majority of allocations made by applications). This means backend allocations have no inherent entropy and therefore may be subject to deterministic allocation patterns, as noted in [5]. In addition to performance, there are also inherent limits to the effectiveness of allocation order randomization. If an attacker can read the contents of heap memory, they may be able to overcome the effects of randomization. Similarly, allocation order randomization is not designed to strongly mitigate heap vulnerabilities that are related to object lifetime issues, such as use after free vulnerabilities. This is because an attacker will generally be able to allocate a sufficient number of replacement objects to overcome the effects of allocation order randomization. We’ll discuss some other mitigations that are targeted at addressing use after free issues, which are increasingly preferred by exploit writers, later in this series. Conclusion The hardening changes that have been made to the Windows heap manager in Windows 8 and Windows 8.1 have been designed to make it more difficult and costly to exploit heap corruption vulnerabilities. This has been accomplished by adding additional integrity checks to metadata that is used by the heap, by protecting application data stored on the heap through the use of guard pages, and by randomizing the order of allocations. These mitigations do not make heap corruption vulnerabilities impossible to exploit, but they do have an impact on the time it takes to develop an exploit and how reliable an exploit will be. Both of these factors play a role in determining whether or not an attacker will develop an exploit for a vulnerability. With that being said, the fact that heap corruption vulnerabilities are the most common vulnerability class that we address through security updates means it is likely that we will continue to see additional research into new exploitation techniques for heap vulnerabilities in the future. As such, we will continue to look for ways to harden the Windows heap to further increase the difficulty of developing reliable exploits for heap corruption vulnerabilities. - Matt Miller References [1] Ben Hawkes. Attacking the Vista Heap. Black Hat USA. Aug, 2008. [2] Ben Hawkes. Attacking the Vista Heap. Ruxcon. Nov, 2008. [3] Chris Valasek. Modern Heap Exploitation using the Low Fragmentation Heap. SyScan Taipei. Nov, 2011. [4] Chris Valasek. Windows 8 Heap Internals. Black Hat USA. Aug, 2012. [5] Zhenhua Liu. Advanced Heap Manipulation in Windows 8. Black Hat Europe, Mar, 2013. Sursa: Software Defense: mitigating heap corruption vulnerabilities - Security Research & Defense - Site Home - TechNet Blogs PS: Matt Miller e "skape". Nu ma astept sa stiti cine e, dar poate va informati.

Proxy DDOSer? Adica sa iti dai DOS singur? Cat despre Facebook bot, vezi ca a facut Zatarra ceva misto.

Intrati si voi mai des pe forum.

Mai grav e sa iti dai buletinu' unei gagici cu promotii la tigari Doar politia si in anumite cazuri jandarmeria au voie sa ceara buletinul. Iar gagica nu a prezentat nicio legitimatie. Desi cred ca i-ar fi stat bine in uniforma de gaborita.

Ai cui sunt banii?

Imi dati PM daca va hotarati. Muie.

“Secret” 3G Intel Chip Gives Snoops Backdoor PC Access vPro processors allow remote access even when computer is turned off Paul Joseph Watson Infowars.com September 26, 2013 Intel Core vPro processors contain a “secret” 3G chip that allows remote disabling and backdoor access to any computer even when it is turned off. Image: Intel Core vPro. Although the technology has actually been around for a while, the attendant privacy concerns are only just being aired. The “secret” 3G chip that Intel added to its processors in 2011 caused little consternation until the NSA spying issue exploded earlier this year as a result of Edward Snowden’s revelations. In a promotional video for the technology, Intel brags that the chips actually offer enhanced security because they don’t require computers to be “powered on” and allow problems to be fixed remotely. The promo also highlights the ability for an administrator to shut down PCs remotely “even if the PC is not connected to the network,” as well as the ability to bypass hard drive encryption. “Intel actually embedded the 3G radio chip in order to enable its Anti Theft 3.0 technology. And since that technology is found on every Core i3/i5/i7 CPU after Sandy Bridge, that means a lot of CPUs, not just new vPro, might have a secret 3G connection nobody knew about until now,” reports Softpedia. Jeff Marek, director of business client engineering for Intel, acknowledged that the company’s Sandy Bridge” microprocessor, which was released in 2011, had “the ability to remotely kill and restore a lost or stolen PC via 3G.” “Core vPro processors contain a second physical processor embedded within the main processor which has it’s own operating system embedded on the chip itself,” writes Jim Stone. “As long as the power supply is available and in working condition, it can be woken up by the Core vPro processor, which runs on the system’s phantom power and is able to quietly turn individual hardware components on and access anything on them.” Although the technology is being promoted as a convenient way for IT experts to troubleshoot PC issues remotely, it also allows hackers or NSA snoops to view the entire contents of somebody’s hard drive, even when the power is off and the computer is not connected to a wi-fi network. It also allows third parties to remotely disable any computer via the “secret” 3G chip that is built into Intel’s Sandy Bridge processors. Webcams could also be remotely accessed. “This combination of hardware from Intel enables vPro access ports which operate independently of normal user operations,” reports TG Daily. “These include out-of-band communications (communications that exist outside of the scope of anything the machine might be doing through an OS or hypervisor), monitoring and altering of incoming and outgoing network traffic. In short, it operates covertly and snoops and potentially manipulates data.” Not only does this represent a privacy nightmare, it also dramatically increases the risk of industrial espionage. The ability for third parties to have remote 3G access to PCs would also allow unwanted content to be placed on somebody’s hard drive, making it easier for intelligence agencies and corrupt law enforcement bodies to frame people. “The bottom line? The Core vPro processor is the end of any pretend privacy,” writes Stone. “If you think encryption, Norton, or anything else is going to ensure your privacy, including never hooking up to the web at all, think again. There is now more than just a ghost in the machine.” Facebook @ https://www.facebook.com/paul.j.watson.71FOLLOW Paul Joseph Watson @ https://twitter.com/PrisonPlanet ********************* Paul Joseph Watson is the editor and writer for Infowars.com and Prison Planet.com. He is the author of Order Out Of Chaos. Watson is also a host for Infowars Nightly News. Sursa: “Secret” 3G Intel Chip Gives Snoops Backdoor PC Access

La 19:00 in fata la Mc (sus) la Unirea. Cine vine sa imi dea PM.

Louisville Infosec 2013 - Past Due: Practical Web Service Vulnerability Assessment For Pen-Testers, Developers, And Qa - Jeremy Druin Description: Because web services facilitate mobile application development, support “Web 2.0” web applications, and integrate modern applications with legacy systems, web services are increasingly common. Like more familiar web applications, web services may be vulnerable to OWASP Top Ten issues. However, the evaluation of web services has not reached the level of automation and maturity of application assessment. We will provide an overview of web services and demonstrate a practical approach to assessing services for security vulnerabilities. Jeremy Druin works as an internal pen-tester, vulnerability management, and defect-remediation expert for a multi-national transportation logistics company. Jeremy manages web vulnerability assessment operations, authored corporate application and database security standards, created the developer training program, and teaches developers how to architect, design and write secure applications. Additionally Jeremy develops the open-source Mutillidae II training environment and consults on web-application security topics. As the Director of Education for the Kentuckiana ISSA chapter, Jeremy presents on application vulnerabilities, pen-testing and remediation along with operating the “webpwnized” YouTube video channel. Jeremy has a Bachelor in Computer Science from Indiana University and is a CompTIA and GIAC-certified Network/Web Application Pen-Tester and Exploit Developer. For More Information please visit : - Louisville Metro InfoSec - Theme: Mobile Security Louisville Infosec 2013 Videos Sursa: Louisville Infosec 2013 - Past Due: Practical Web Service Vulnerability Assessment For Pen-Testers, Developers, And Qa - Jeremy Druin

Sa vad daca ne strangem, dar nu cred ca o sa fim prea multi.

Symmetric and Asymmetric Encryption 1. Introduction This article explains how symmetric and asymmetric encryption work. It also describes how to build a secure mail system using these two types of encryption. 2. Symmetric Encryption Let’s assume that Alice wants to talk to Bob. She wants to keep the message secret. Bob is the only one who should be able to read the message. The message is confidential, so Alice uses a key to encrypt the message. The original message is called a plaintext while the encrypted message is called a ciphertext. The ciphertext is sent to Bob, who knows the key and uses the same symmetric cipher (e.g., AES or 3DES). Thus Bob is able to decrypt the message. Alice and Bob share the key, which is called symmetric. They are the only ones who know the key and no one else is able to read the encrypted message. This way, confidentiality is achieved. 2.1 Key Length vs. Security The key space doubles when one bit is added to the key. Longer keys are better, but don’t necessarily increase security. Because people tend to use patterns for passwords, the attacker can build a dictionary of commonly used passwords and launch a dictionary attack. This way the attacker can save time, because he doesn’t have to brute force the whole key space. 2.2 Symmetric vs. Session Key The symmetric key can be changed every time Alice communicates with Bob. Then it is called a session key (randomly generated and valid only for one session). If an attacker grabs the session key, he can decrypt only the messages from one session. If Alice and Bob always used the same key, the attacker would be able to decrypt all messages encrypted with this key. 2.3 Scalability and Secure Key Distribution There are a few problems with symmetric ciphers. This system is not scalable. If there are 1,000 people who want to communicate with each other, everyone needs 999 different keys to establish separate and confidential communication channels. Secure key distribution is another problem. The security of the system is broken if a man-in-the-middle can grab the key while it is being transmitted from Alice to Bob. 3. Asymmetric Encryption Two keys are used in asymmetric cipher (e.g., RSA)—a public and a private one. The public one is available for everyone, but the private one is known only by the owner. When the message is encrypted with the public key, only the corresponding private key can decrypt it. Moreover, the private key can’t be learned from the public one. Asymmetric cipher solves the problem of secure key distribution. Alice takes Bob’s public key and uses it to encrypt the session key. Only Bob can then decrypt the encrypted session key, because he is the only one who knows the corresponding private key. Asymmetric ciphers are quite slow when compared with the symmetric ones, which is why asymmetric ciphers are used only to securely distribute the key. Then, Alice and Bob can use symmetric cipher and the session key to make the communication confidential. Use of an asymmetric cipher also solves the scalability problem. Everyone will need only one public key and one private key to communicate with other people. 4. Mail Security Let’s analyze how symmetric and asymmetric encryption can be used to build secure mail system. 4.1 Achieving Message Confidentiality Alice is going to send a mail to Bob. She wants to keep the message secret. Bob is the only one who should be able to read the message. Confidentiality can be achieved by using symmetric encryption. The key used for symmetric encryption (the session key) needs to be securely sent to Bob. Asymmetric encryption is used for the purpose of secure key distribution. Let’s analyze this process step by step. Alice generates a session key (SESSION_KEY) and encrypts it with Bob’s public key (PUB_KEY_BOB). The result is PUB_KEY_BOB (SESSION_KEY), which is denoted by PART1. Then the message (MESSAGE) is encrypted with SESSION_KEY. The result is SESSION_KEY(MESSAGE), which is denoted by PART2. Finally PART1 and PART2 are sent to Bob. Only Bob can decrypt PART1, because he is the only one who knows the corresponding private key (PRIV_KEY_BOB). Bob decrypts PART1 and gets the SESSION_KEY. Then he uses SESSION_KEY to decrypt PART2 and get the MESSAGE. 4.2 Achieving Message Confidentiality, Integrity, and Authentication of the Sender Let’s discuss a more complicated case. Alice is going to send a mail to Bob. Bob wants to verify the sender of the message and check whether its integrity is preserved. Moreover, the message should be kept secret. Bob is the only one who should be able to read the message. Let’s analyze this process step by step. Alice generates a session key (SESSION_KEY) and encrypts it with Bob’s public key (PUB_KEY_BOB). The result is PUB_KEY_BOB (SESSION_KEY), which is denoted by PART1. The message (MESSAGE) is hashed by Alice. The result is H(MESSAGE). The ideal hash function is irreversible (one can’t get the message from the hash) and there are no two different messages MESSAGE1 and MESSAGE2 having the same hash. Then H(MESSAGE) is encrypted with the private key of Alice (PRIV_KEY_ALICE). The result is PRIV_KEY_ALICE(H(MESSAGE)), which is a digital signature of MESSAGE signed by Alice and is denoted by DIGITAL_SIGNATURE. MESSAGE and DIGITAL_SIGNATURE are encrypted with SESSION_KEY. The result is SESSION_KEY(MESSAGE concatenated with DIGITAL SIGNATURE), which is denoted by PART2. Finally PART1 and PART2 are sent to Bob. Only Bob can decrypt PART1, because he is the only one who knows the corresponding private key (PRIV_KEY_BOB). Bob decrypts PART1 and gets the SESSION_KEY. Then he uses SESSION_KEY to decrypt PART2 and gets MESSAGE concatenated with DIGITAL SIGNATURE. Bob uses Alice’s public key (PUB_KEY_ALICE) to decrypt DIGITAL_SIGNATURE. The result of decryption is H(MESSAGE). Then Bob calculates hash of MESSAGE and compares the result with decrypted DIGITAL_SIGNATURE. When they match, Bob knows that it was Alice who sent the message and exactly what message was sent by Alice. 5. Conclusions - Symmetric encryption is used to provide confidentiality of the message. - Asymmetric encryption is used to securely distribute the session key. - Asymmetric encryption solves the scalability problem related with symmetric encryption . By Dawid Czagan|October 23rd, 2013 Sursa: Symmetric and Asymmetric Encryption - InfoSec Institute

Sockets, Shellcode, Porting & Coding REVERSE ENGINEERING EXPLOITS AND TOOL CODING FOR SECURITY PROFESSIONALS James C. Foster with Mike Price Foreword . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxvii Chapter 1 Security Coding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2 C/C++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3 Language Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3 C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4 Hello,World! Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5 Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5 Flow Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8 Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9 Classes (C++ Only) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10 Case Study: Fourier Estimation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12 Fourier Estimation Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12 Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14 Language Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15 Object Oriented . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15 Platform Independence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16 Multithreading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16 Advanced Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16 Hello,World! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17 Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17 Flow Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18 Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20 Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20 GET HTTP Headers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22 C# . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23 Business Case for Migrating to C# . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24 Language Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24 Object-Oriented . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24 Other Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25 C#’s Hello,World! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26 xiv Contents Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26 Flow Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27 Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29 Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30 C# Threading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31 Case Study: Command Line IP Address Parsing . . . . . . . . . . . . . . . . . . . .32 Perl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40 Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41 Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42 A Sample Perl Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .45 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46 Special Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46 Pattern Matching and Substitution . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47 Regular Expression Modifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .48 Canonical Perl Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .49 I Am a Perl Coder! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .49 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .50 A Log Modification Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .50 Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .53 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .53 Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .55 InlineEgg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .57 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .58 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .60 Solutions Fast Track . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61 Links to Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .62 Frequently Asked Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63 Chapter 2 NASL Scripting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66 History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66 Goals of NASL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66 Simplicity and Convenience . . . . . . . . . . . . . . . . . . . . . . . . . . . . .67 Modularity and Efficiency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .67 Safety . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .67 NASL’s Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .67 NASL Script Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .68 Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .68 Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .68 Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .70 Control Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .74 Writing NASL Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .77 Writing Personal-use Tools in NASL . . . . . . . . . . . . . . . . . . . . . . . . . . .78 Networking Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .78 HTTP Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .78 Packet Manipulation Functions . . . . . . . . . . . . . . . . . . . . . . . . . . .78 Contents xv String Manipulation Functions . . . . . . . . . . . . . . . . . . . . . . . . . . .79 Cryptographic Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .79 The NASL Command Line Interpreter . . . . . . . . . . . . . . . . . . . . .79 Programming in the Nessus Framework . . . . . . . . . . . . . . . . . . . . . . . . .80 Descriptive Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .80 Case Study:The Canonical NASL Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . .82 Porting to and from NASL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .86 Logic Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .86 Identify Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .86 Pseudo Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .87 Porting to NASL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .88 Porting to NASL from C/C++ . . . . . . . . . . . . . . . . . . . . . . . . . . .89 Porting from NASL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .94 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .95 Solutions FastTrack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .95 Links to Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .97 Frequently Asked Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .97 Chapter 3 BSD Sockets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .100 Introduction to BSD Sockets Programming . . . . . . . . . . . . . . . . . . . . . . . . . .100 TCP Clients and Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .101 Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .102 Example Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .102 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .102 Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .105 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .105 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .106 UDP Clients and Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .107 Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .109 Example Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .109 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .109 Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .111 Example Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .111 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .111 Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .113 Example Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .113 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .113 Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .115 Example Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .115 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .115 Socket Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .116 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .118 Network Scanning with UDP Sockets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .118 Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .125 Example Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .125 xvi Contents Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .125 Network Scanning with TCP Sockets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .127 Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .136 Example Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .136 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .136 Threading and Parallelism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .139 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .141 Solutions Fast Track . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .141 Links to Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .143 Frequently Asked Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .143 Chapter 4 Windows Sockets (Winsock) . . . . . . . . . . . . . . . . . . . . . . . 145 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .146 Winsock Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .146 Winsock 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .148 Linking through Visual Studio 6.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . .148 Linking through Source Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .148 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .150 Case Study: Using WinSock to Grab a Web Page . . . . . . . . . . . . . . . . . . . . . .153 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .154 Writing Client Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .154 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .156 Writing Server Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .158 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .160 Writing Exploit and Vulnerability Checking Programs . . . . . . . . . . . . . . . . . .161 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .167 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .168 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .169 Solutions Fast Track . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .170 Frequently Asked Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .170 Case Study: Using WinSock to Execute a Web Attack . . . . . . . . . . . . . . . . . .172 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .173 Case Study: Using Winsock to Execute a Remote Buffer Overflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .174 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .176 Chapter 5 Java Sockets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .178 An Overview of TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .178 TCP Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .179 Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .181 Example Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .181 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .182 IP Addresses and Hostname Resolution . . . . . . . . . . . . . . . . . . . . . . . .183 Contents xvii Example Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .184 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .184 Example Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .185 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .185 Text-Based Input/Output:The LineNumberReader Class . . . . . . . . . . .186 Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .188 Example Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .188 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .189 TCP Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .189 Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .192 Example Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .192 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .192 Using a Web Browser to Connect to TCPServer1 . . . . . . . . . . . . . . . . .193 Handling Multiple Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .194 Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .200 Example Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .200 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .201 WormCatcher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .204 Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .207 Example Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .207 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .208 UDP Clients and Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .209 Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .213 Example Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .214 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .214 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .217 Solutions Fast Track . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .217 Frequently Asked Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .218 Chapter 6 Writing Portable Code. . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .222 UNIX and Microsoft Windows Porting Guide . . . . . . . . . . . . . . . . . . . . . . . .222 Pre-compiler Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .222 Using ifdefs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .223 Determining the Operating System . . . . . . . . . . . . . . . . . . . . . . . . . . .225 Example Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .226 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .226 Byte Ordering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .226 Example Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .227 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .228 Process Creation and Termination . . . . . . . . . . . . . . . . . . . . . . . . . . . . .229 exec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .229 Example Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .229 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .230 Example Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .230 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .230 Example Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .233 xviii Contents Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .233 fork . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .234 exit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .234 Multithreading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .234 Thread Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .234 Example Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .235 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .235 Example Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .237 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .237 Thread Coordination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .237 Example Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .239 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .239 Example Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .241 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .241 Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .242 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .243 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .244 File Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .244 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .245 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .246 Directory Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .247 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .248 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .249 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .250 Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .250 Dynamic Loading of Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .252 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .254 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .255 Daemon/Win32 Service Programming . . . . . . . . . . . . . . . . . . . . . . . . .256 Example Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .257 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .258 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .261 Memory Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .262 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .263 Command-line Argument Processing . . . . . . . . . . . . . . . . . . . . . . . . . .263 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .264 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .266 Example Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .267 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .268 Integer Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .267 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .267 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .269 Solutions Fast Track . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .269 Frequently Asked Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .269 Contents xix Chapter 7 Portable Network Programming . . . . . . . . . . . . . . . . . . . . 273 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .274 BSD Sockets and Winsock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .274 Winsock Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .274 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .276 Portable Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .276 Return Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .276 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .277 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .277 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .278 Extended Error Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .278 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .280 The API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .280 Winsock 2.0 Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .280 read(), write() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .280 socket() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .280 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .282 connect() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .282 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .285 bind() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .285 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .287 listen() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .287 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .290 accept() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .290 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .293 select() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .293 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .297 send(), sendto() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .298 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .301 recv(), recvfrom() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .301 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .304 Close(), Closesocket() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .305 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .306 setsockopt() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .307 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .309 Ioctl(), Ioctlsocket() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .309 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .311 Raw Sockets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .312 API Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .312 Header Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .312 IP(v4) Header File: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .313 ICMP Header File: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .315 UDP Header File: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .315 TCP Header File (tcp.h): . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .316 Local IP Address Determination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .317 Contents User Supplied . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .317 Listing Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .318 Example Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .321 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .322 Pcap and WinPcap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .323 Example Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .327 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .328 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .329 Solutions Fast Track . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .329 Frequently Asked Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .330 Chapter 8 Writing Shellcode I . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .334 Overview of Shellcode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .334 The Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .335 The Assembly Programming Language . . . . . . . . . . . . . . . . . . . . .335 Windows vs UNIX Assembly . . . . . . . . . . . . . . . . . . . . . . . . . . .339 The Addressing Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .339 Using the call and jmp Trick . . . . . . . . . . . . . . . . . . . . . . . . . . . .339 Pushing the Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .340 The NULL Byte Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .341 Implementing System Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .342 System Call Numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .342 System Call Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .343 System Call Return Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . .344 Remote Shellcode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .345 Port Binding Shellcode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .345 Socket Descriptor Reuse Shellcode . . . . . . . . . . . . . . . . . . . . . . . . . . .346 Local Shellcode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .348 execve Shellcode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .348 setuid Shellcode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .349 chroot Shellcode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .350 Windows Shellcode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .354 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .359 Solutions Fast Track . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .360 Links to Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .362 Mailing Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .362 Frequently Asked Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .363 Chapter 9 Writing Shellcode II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .366 Shellcode Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .366 The Write System Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .368 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .369 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .371 execve Shellcode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .372 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .373 Contents xxi Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .373 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .375 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .376 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .378 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .379 Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .380 Port Binding Shellcode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .380 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .381 The socket System Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .383 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .383 The bind System Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .383 The listen System Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .384 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .384 The accept System Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .385 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .385 The dup2 System Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .385 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .385 The execve System Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .386 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .386 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .389 Reverse Connection Shellcode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .391 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .393 Socket Reusing Shellcode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .394 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .395 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .395 Reusing File Descriptors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .396 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .396 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .398 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .399 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .399 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .400 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .401 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .402 Encoding Shellcode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .402 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .403 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .405 Execution Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .407 Reusing Program Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .407 Open-Source Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .408 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .409 Closed-Source Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .409 Execution Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .410 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .411 OS-Spanning Shellcode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .411 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .412 Understanding Existing Shellcode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .412 xxii Contents Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .414 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .416 Solutions Fast Track . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .416 Links to Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .418 Mailing Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .418 Frequently Asked Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .419 Chapter 10 Writing Exploits I . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .422 Targeting Vulnerabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .422 Remote and Local Exploits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .423 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .424 Format String Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .424 Format Strings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .424 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .425 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .425 Fixing Format String Bugs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .426 Case Study: xlockmore User-Supplied Format String Vulnerability CVE-2000-0763 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .427 Vulnerability Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .427 Exploitation Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .427 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .429 TCP/IP Vulnerabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .429 Race Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .430 File Race Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .430 Signal Race Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .431 Case Study: man Input Validation Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . .432 Vulnerability Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .432 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .435 Solutions Fast Track . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .435 Links to Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .436 Frequently Asked Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .437 Chapter 11 Writing Exploits II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 439 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .440 Coding Sockets and Binding for Exploits . . . . . . . . . . . . . . . . . . . . . . . . . . . .440 Client-Side Socket Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . .441 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .441 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .442 Server-Side Socket Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . .442 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .444 Stack Overflow Exploits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .444 Memory Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .444 Stack Overflows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .446 Finding Exploitable Stack Overflows in Open-Source Software . . . . . . .449 Case Study: X11R6 4.2 XLOCALEDIR Overflow . . . . . . . . . . . . . . . . . . . .450 The Vulnerability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .450 Contents xxiii The Exploit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .452 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .454 Finding Exploitable Stack Overflows in Closed-Source Software . . . . . .454 Heap Corruption Exploits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .455 Doug Lea Malloc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .456 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .458 Case Study: OpenSSL SSLv2 Malformed Client Key Remote Buffer Overflow Vulnerability CAN-2002-0656 . . . . . . . . . . . . . . . . . . . . . . . . . .459 The Vulnerability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .460 Exploitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .460 The Complication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .461 Improving the Exploit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .462 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .463 Exploit Code for OpenSSL SSLv2 Malformed Client Key Remote Buffer Overflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . .463 System V Malloc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .468 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .470 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .471 Integer Bug Exploits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .472 Integer Wrapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .472 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .473 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .474 Bypassing Size Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .475 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .475 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .476 Other Integer Bugs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .476 Case Study: OpenSSH Challenge Response Integer Overflow Vulnerability CVE-2002-0639 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .477 Vulnerability Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .477 Exploitation Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .478 Case Study: UW POP2 Buffer Overflow Vulnerability CVE-1999-0920 . . . . .480 Vulnerability Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .480 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .488 Solutions Fast Track . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .488 Links to Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .489 Frequently Asked Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .490 Chapter 12 Writing Exploits III . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .492 Using the Metasploit Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .492 Exploit Development with Metasploit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .498 Determining the Attack Vector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .499 Finding the Offset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .499 Selecting a Control Vector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .504 Finding a Return Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .509 Using the Return Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .513 xxiv Contents Determining Bad Characters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .514 Determining Space Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .515 Nop Sleds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .517 Choosing a Payload and Encoder . . . . . . . . . . . . . . . . . . . . . . . . . . . . .518 Integrating Exploits into the Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . .527 Understanding the Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .527 Analyzing an Existing Exploit Module . . . . . . . . . . . . . . . . . . . . . . . . .528 Overwriting Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .533 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .534 Solutions Fast Track . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .534 Links to Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .535 Frequently Asked Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .536 Chapter 13 Writing Security Components . . . . . . . . . . . . . . . . . . . . . 539 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .540 COM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .540 COM Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .540 COM Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .541 IUnknown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .541 Calling Convention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .541 The COM Runtime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .541 COM Object Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .542 COM Registration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .543 HKEY_CLASSES_ROOT\CLSID . . . . . . . . . . . . . . . . . . . . . . .544 HKEY_CLASSES_ROOT\CLSID\ {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx} . . . . . . . . . . . . . . .544 InprocServer32 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .544 LocalServer32 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .544 COM IN-PROCESS Server Implementation . . . . . . . . . . . . . . . . . . . .544 DllGetClassObject . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .545 DllCanUnloadNow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .545 DllRegisterServer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .545 DllUnregisterServer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .545 ATL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .546 C++ Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .546 ATL Client Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .547 Smart Pointers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .547 Datatype Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .548 BSTR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .548 VARIANT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .548 ATL Server Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .550 Class Composition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .550 Interface Definition Language . . . . . . . . . . . . . . . . . . . . . . . . . . .553 Class Registration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .556 COM IN-PROCESS Server Implementation . . . . . . . . . . . . . . .559 The _AtlModule Global Variable . . . . . . . . . . . . . . . . . . . . . . . . .559 Contents xxv DLL Exports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .560 Module Entry Point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .561 COM OUT-OF-PROCESS Server Implementation . . . . . . . . . . .561 Module Entry Point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .562 ATL Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .563 Module Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .564 Interface Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .565 Component Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .566 Adding COM Extensions to the RPCDump Tool . . . . . . . . . . . . . . . . . . . . .567 COM EXE Server Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . .568 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .570 Control Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .571 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .572 Application Integration Routines . . . . . . . . . . . . . . . . . . . . . . . . . . . . .573 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .574 Tool Interface Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .575 IRpcEnum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .576 IEndpointCollection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .577 IEndpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .578 Component Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .578 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .579 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .580 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .583 Application Integration: COMSupport.h . . . . . . . . . . . . . . . . . . . . . . . .584 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .585 Application Integration: RPCDump.C . . . . . . . . . . . . . . . . . . . . . . . . .585 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .585 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .586 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .586 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .586 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .587 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .587 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .587 Solutions Fast Track . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .588 Links to Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .588 Frequently Asked Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .589 Chapter 14 Creating a Web Security Tool . . . . . . . . . . . . . . . . . . . . . 593 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .594 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .594 Attack Signature Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .594 Signatures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .595 In-Depth Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .595 Sockets and Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .596 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .603 Parsing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .605 xxvi Contents Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .608 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .614 Header Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .616 Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .619 Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .619 The Usage Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .620 Tool Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .620 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .621 Solutions Fast Track . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .621 Links to Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .622 Frequently Asked Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .622 Appendix A Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625 Appendix B Security Tool Compendium. . . . . . . . . . . . . . . . . . . . . . . 633 Source Code Auditing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .633 Shellcode Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .634 Debuggers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .634 Compilers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .634 Hardware Simulators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .635 Security Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .636 Vulnerability Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .636 Network Traffic Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .637 Packet Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .638 Scanners . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .638 Appendix C Exploit Archives. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 639 Online Exploit Archives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .640 Appendix D Syscall Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 641 exit( int ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .642 open( file, flags, mode ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .642 close( filedescriptor ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .642 read( filedescriptor, pointer to buffer, amount of bytes ) . . . . . . . . . . . . .642 write( filedescriptor, pointer to buffer, amount of bytes ) . . . . . . . . . . . .642 execve( file, file + arguments, environment data ) . . . . . . . . . . . . . . . . . .642 socketcall( callnumber, arguments ) . . . . . . . . . . . . . . . . . . . . . . . . . . . .642 socket( domain, type, protocol ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .643 bind( file descriptor, sockaddr struct, size of arg 2 ) . . . . . . . . . . . . . . . .643 listen ( file descriptor, number of connections allowed in queue ) . . . . . .643 accept ( file descriptor, sockaddr struct, size of arg 2 ) . . . . . . . . . . . . . .643 Appendix E Data Conversion Reference. . . . . . . . . . . . . . . . . . . . . . . 645 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 653 Download: http://www.speedyshare.com/7TpWt/62624332-Sockets-Shellcode-Porting-1597490059.pdf http://www.fileshare.ro/e29946192 http://www.girlshare.ro/32940793.6

Care sunteti din Bucuresti? Care ati veni la un meeting? Care ati veni maine (sambata) la bere? Daca nu vreti sa ziceti aici imi puteti da PM.

Super, mai scurt decat o carte

Si care sunt exploit-urile? Sunt publice, nu?

TrueCrypt is an open-source encryption software capable of on-the-fly encryption on file-, partition- or disk-based virtual disks. It supports various ciphers, including AES, Serpent, Twofish or some combination of them; provides a full disk encryption (FDE) feature under Windows environment with pre-boot authentication; and even allows plausible deniability. Hence TrueCrypt seems to be a perfect solution to protect sensitive files. However, the recent news about the NSA programs enable all conspiracy theorists to imagine the worst of all. What if TrueCrypt was backdoored? What if the binaries provided on the website were different than the source code and they included hidden features? We show in this article how to reproduce a deterministic compilation process specific to TrueCrypt 7.1a for Windows that matches the official binaries, and relieve the world from at least some concerns. [h=2]Article versions changelog[/h] 2013-10-24: Added analysis results of v7.0a and v6.3a 2013-10-23: Explained differences in more details, added assembly comparison 2013-10-22: Added PGP/X.509 screenshots, clarified some comparison comments 2013-10-21: First version [h=2]Challenges and implications[/h] TrueCrypt is a project that doesn't provide deterministic builds. Hence, anyone compiling the sources will get different binaries, as pointed by this article on Privacy Lover, saying that "it is exceedingly difficult to generate binaries from source that match the binaries provided by Truecrypt." This has led some speculations regarding the possibility of having backdoors in the official binaries that cannot be found easiliy. This concern has also been raised in this analysis, saying: "Without a very expensive “reverse engineering” it can't be proved that they are compiled from the published source code. Since we haven't done such a reverse engineering we can't preclude that there is a back door hidden within those binary packages." Recently, the IsTrueCryptAuditedYet project was launched and aims at reviewing TrueCrypt's security and, among other things, providing deterministic build so as to enable everyone to compare her version to the official one. However, it is still at an early stage (as of October 2013) and tries to raise funds first. In this article, I present how I compiled TrueCrypt 7.1a for Windows and reached a very close match to the official binaries. I am also able to explain the small remaining differences and then prove that the official binaries indeed come from the public sources. Articolul aici: https://madiba.encs.concordia.ca/~x_decarn/truecrypt-binaries-analysis/

[h=1]DARPA ANNOUNCES CYBER GRAND CHALLENGE[/h] What if computers had a “check engine” light that could indicate new, novel security problems? What if computers could go one step further and heal security problems before they happen? To find out, the Defense Advanced Research Projects Agency (DARPA) intends to hold the Cyber Grand Challenge (CGC)—the first-ever tournament for fully automatic network defense systems. DARPA envisions teams creating automated systems that would compete against each other to evaluate software, test for vulnerabilities, generate security patches and apply them to protected computers on a network. To succeed, competitors must bridge the expert gap between security software and cutting-edge program analysis research. The winning team would receive a cash prize of $2 million. “DARPA’s series of vehicle Grand Challenges were the dawn of the self-driving car revolution,” said Mike Walker, DARPA program manager. “With the Cyber Grand Challenge, we intend a similar revolution for information security. Today, our time to patch a newly discovered security flaw is measured in days. Through automatic recognition and remediation of software flaws, the term for a new cyber attack may change from zero-day to zero-second.” Highly trained experts capable of reasoning about software vulnerabilities, threats and malware power modern network defense. These experts compete regularly on a global “Capture the Flag” tournament circuit, improving their skills and measuring excellence through head-to-head competition. Drawing on the best traditions of expert computer security competitions, DARPA aims to challenge unmanned systems to compete against each other in a real-time tournament for the first time. “The growth trends we’ve seen in cyber attacks and malware point to a future where automation must be developed to assist IT security analysts,” said Dan Kaufman, director of DARPA’s Information Innovation Office, which oversees the Challenge. The competition is expected to draw teams of top experts from across a wide range of computer security disciplines including reverse engineering, formal methods, program analysis and computer security competition. To encourage widespread participation and teaming, DARPA plans to host teaming forums on the CGC website atwww.darpa.mil/cybergrandchallenge. For the first time, a cyber competition would take place on a network framework purpose-built to interface with automatic systems. Competitors would navigate a series of challenges, starting with a qualifying event in which a collection of software must be automatically analyzed. Competitors would qualify by automatically identifying, analyzing and repairing software flaws. DARPA intends to invite a select group of top competitors s from the qualifying event to the Cyber Grand Challenge final event, slated for early to mid-2016. In that competition, each team’s system would automatically identify software flaws, scanning the network to identify affected hosts. Teams would score based on how capably their systems could protect hosts, scan the network for vulnerabilities and maintain the correct function of software. The winning team from the CGC finals would receive a cash prize of $2 million, with second place earning $1 million and third place taking home $750,000. A Broad Agency Announcement (BAA) with specific information for potential competitors is available at http://go.usa.gov/WqcH. Competitors can choose one of two routes: an unfunded track in which anyone capable of fielding a capable system can participate, and a funded track in which DARPA awards contracts to organizations presenting the most compelling proposals. DARPA also plans in the near future to issue a second BAA for proposals to develop technologies to support the competition. Support technologies will include accessible visualization of a real-time cyber competition event, as well as custom problem sets. That BAA will be available on the Federal Business Opportunities website. The program anticipates hosting two Challengers’ Days—one at DARPA’s offices in Arlington, Va., and the other on the West Coast—where interested competitors can learn more about the event. More information, including up-to-date rules and prize amounts, is available at www.darpa.mil/cybergrandchallenge. Sursa: DARPA ANNOUNCES CYBER GRAND CHALLENGE — Knight And Gale

Eu sunt mai de la tara. Ban o saptamana.

The big GSM write-up – how to capture, analyze and crack GSM? Posted on October 13, 2013 by domi007 So. I had some requests asking me about how I did what I did with GSM. What tools did I use, what hardware and what options? Since I believe strongly that GSM needs to be “out in the hands of the people” meaning everybody should have access to cheap hardware and free, opensource software that helps understanding GSM in practice I thought I will create a series of write-ups describing the whole process from the beginning. Enjoy! First Step: understanding the basics of GSM, what’s the theory behind GSM-cracking? GSM (Global System for Mobile communication) was introduced as a standard in 1991. The cipher used in GSM hasn’t been really well known but already in 1994 Ross Anderson published a theory about how to crack the encryption. Later many people contributed to this theory essentially making GSM theoretically broken since 2003, but practical tools existed only for governmental organizations and mobile operators for such high prices nobody from the hacker community could buy them (not mentioning none of the manufacturers would have given him/her anything). And this was the time when Karsten Nohl decided to dedicate some years as a researcher and as a manager to create both software and hardware that could turn theory into reality. Every single year since 2009 Karsten and one member of his team released something, a milestone if you wish, which contributed to the death of myth that GSM is secure. But there was one problem: all the details could never be released because of the rules of ‘responsible disclosure’ meaning that you can not give access to anybody to tools that exploit unpatched vulnerabilities in a live system. And boy, GSM does have quite some of these. However during the years we always got something, a piece of the puzzle so to speak: 2009 – GSM rainbowtables with the tool Kraken (created by Frank A Stevenson) – they are useless without proper hardware that can capture GSM data but once we have the hardware cracking is possible 2010 – airprobe which makes it possible to capture non-hopping GSM downlink channels with the USRP (combined with Kraken we have a full downlink sniffer on a single cell) I am not listing 2011 here because there was no code released in that year (since the presented solution was a full blown GSM eavesdropping attack there was nothing to be released). So, the landscape of GSM hacking consists of two hardware options: USRP or OsmocomBB. The USRP costs a lot, OsmocomBB has pretty much no code available. My ideal setup would be a combination of these two: cheap hardware and software already available. Is there such a solution? Yes, there is. You can use an RTL-SDR stick to capture GSM data from the air, just like you would do with a USRP. It is not as accurate, it does lose sync sometimes, but it works. And not only for single transmissions (SMS) but also for calls. I tested both, and I can confirm that it works. So, now we have an established platform: we are going to sniff single frequency (non-hopping) GSM downlink-traffic. These are our limitations, airprobe is only capable of decoding the downlink and RTL-SDR isn’t capable of hopping along (although in theory you can use more sticks and lock each of them to a frequency and then re-construct the transmission by combining data from all dongles). BEFORE YOU CONTINUE: if you haver never done anything with GSM, don’t know what a ‘burst’ is, or never heard of a ‘timeslot’ please stop reading this post and read at least the first 4 chapters of this introduction: http://web.ee.sun.ac.za/~gshmaritz/gsmfordummies/intro.shtml UPDATE: The page I referenced here went offline, so here is a PDF containing all its content. Steps to crack GSM (originally outlined by Karsten Nohl): Get the TMSI of the victim Analyze the cell you and the victim are camping on Capture traffic and use the results of your analysis to construct input data for Kraken Use Kraken to crack the key Use the key to decode the data you captured Get the TMSI of the victim TMSI stands for Temporary Mobile Subscriber Identifier which is used on GSM networks to avoid the transmission of any information that would possibly identify a certain person (customer). We need to know this ID so we can tell when the victim is being paged (meaning that he/she is going to receive something from the network – call or SMS). The idea behind uncovering a TMSI is quite simple: if the victim receives anything from the network he/she will get paged. So if we keep sending something to the victim (call/SMS) we can correlate the pagings we observe on the air with the frequency of the transactions we initiate. (this technique was first presented at 27c3 by Sylvain Munaut) The ideal “thing” to send is a silent SMS: it will not show up at all on the victim’s phone (no sound, no notification, nothing) but we will get an acknowledge from the victim saying that our SMS was delivered. Example scenario: we observe pagings and figure out that they page twice for each transaction, so if we send 3 silent messages there should be a TMSI which has been paged 6 times. By altering the number of messages sent we can quickly distinguish false positives from the real answers. Test results: I actually did this attack at Hacktivity with a room full of people (meaning that the cell serving us was quite busy) and on my first attempt using 3 messages I only got two results back (meaning one of them was a false positive). Repeating the process would probably eliminate the false positive easily (there is very little chance that the same false positive would show up). Analyze the cell Since GSM cracking is based on knowing the content of encrypted bursts we need to figure out some information about the cell’s configuration. But wait you might say, what’s the point of this, ‘knowing the content of encrypted bursts’ renders encryption useless, doesn’t it? Yes and no. Of course if you know the content of something that is encrypted there is no point in encryption. But in case of GSM it isn’t so simple: there are some bursts that are transmitted periodically, usually containing information about the system (System Information bursts). The only rule about these bursts is that they need to be transmitted no matter what. Even if the connection is currently encrypted these bursts will be transmitted (naturally in encrypted form). So if we keep looking at the cell’s broadcast channel we can easily find a pattern which could be for example something like this Paging Request for TMSI 11223344 Paging Request for TMSI 55667788 System Information Type 6 Empty Burst Paging Request for TMSI 99887766 Paging Request for TMSI 00112233 System Information Type 5 Empty Burst Paging Request containing TMSI 77001122 Paging Request containing TMSI 66005577 System Information Type 1 Empty Burst and so on. As you can see the pattern repeats itself, just the type of the System Information changes, but for example there is always an empty burst at the end. This is just a fictional pattern but I hope you see the idea: some of these bursts are transmitted even if the connection is encrypted. So if we look at the cell’s traffic, save the cleartext of a System Information Type 5 message, then capture some encrypted data containing the same message we can do: cleartext System Information Type 5 XOR encrypted System Information Type 5 The result is the so called keystream (that comes out of the encryption function A5/1). Guess what do we need to feed our cracker, Kraken with? Yep, A5/1 keystream. The challenge of course is to determine which burst of all the encrypted ones is the one containing in this case the System Information Type 5 message (again, we could have chosen any other message which has a known content). That’s why we need to analyze the cell’s configuration and make maybe one-two test calls to see the call setup. Usually the call setup always happens the same way, so once you figured out what messages are sent during a call-setup you can safely assume that the same messages will be transmitted whenever there is a call-setup. Using Kraken That’s pretty straight forward: download the 1.6 TB of rainbow-tables, write them out to a hard drive and then fire up Kraken. After it is ready just give it the crack command followed by the burst you would like to crack, like this: Kraken> crack 001101110011000000001000001100011000100110110110011011010011110001101010100100101111111010111100000110101001101011 Decrypting traffic Since GSM could be running in many different configurations you might need to try out more config. options of the tool go.sh to get it working properly. Otherwise there isn’t anything fancy about this step, all you need to do is pretty much giving it the key, the filename and ‘let it do the magic’. This is the end of the first part of the series. I covered just the history of GSM hacking, what hardware do we have to do GSM hacking and basic theory behind the attack. In the next part we are going to set up our environment, then start real hacking with it. Stay tuned! Sursa: The big GSM write-up – how to capture, analyze and crack GSM? – 1. | Going on my way…