Jump to content

Leaderboard


Popular Content

Showing content with the highest reputation since 12/22/17 in Posts

  1. 11 points
  2. 9 points
    Am accesat eu camera. Uite ce zice.
  3. 9 points
    Sa se cheme dupa cel mai tare hacker roman: Tinkoin
  4. 8 points
    https://www.amazon.co.uk/gp/aw/d/B001FCN7O8/ si https://www.amazon.co.uk/gp/aw/d/B01D8N84D0/
  5. 7 points
    Salutare, Aici avem singurul PoC real de meltdown, care functioneaza fara probleme (probat de mine). https://github.com/IAIK/meltdown This repository contains several videos demonstrating Meltdown Video #1 shows how Meltdown can be used to spy in realtime on a password input. Video #2 shows how Meltdown leaks physical memory content. Video #3 shows how Meltdown reconstructs a photo from memory. Video #4 shows how Meltdown reconstructs a photo from memory which is encoded with the FLIF file format. Video #5 shows how Meltdown leaks uncached memory. Am incercat sa scot parola de la un login de chrome (parola nefiind salvada, decat introdusa pentru login) merge ca si uns. Hai, la joaca!
  6. 7 points
  7. 7 points
    With WPA3, Wi-Fi security is about to get a lot tougher Finally, a security reprieve for open Wi-Fi hotspot users. By Zack Whittaker for Zero Day | January 8, 2018 -- 22:28 GMT (22:28 GMT) | Topic: Security At last, Wi-Fi security -- or lack of -- is about to get its day in the sun. The Wi-Fi Alliance, an industry body made up of device makers including Apple, Microsoft, and Qualcomm, announced Monday its next-generation wireless network security standard, WPA3. The standard will replace WPA2, a near-two decades-old security protocol that's built in to protect almost every wireless device today -- including phones, laptops, and the Internet of Things. SECURITY 101 One of the key improvements in WPA3 will aim to solve a common security problem: open Wi-Fi networks. Seen in coffee shops and airports, open Wi-Fi networks are convenient but unencrypted, allowing anyone on the same network to intercept data sent from other devices. WPA3 employs individualized data encryption, which scramble the connection between each device on the network and the router, ensuring secrets are kept safe and sites that you visit haven't been manipulated. Another key improvement in WPA3 will protect against brute-force dictionary attacks, making it tougher for attackers near your Wi-Fi network to guess a list of possible passwords. The new wireless security protocol will also block an attacker after too many failed password guesses. WPA2, the current incarnation of the wireless security standard since 2004, uses a four-way handshake to securely allows new devices with a pre-shared password to join a network. The newer WPA3 will use a newer kind of handshake, Mathy Vanhoef, a computer security academic, told ZDNet, which will "not be vulnerable to dictionary attacks." A new wireless security standard can't come soon enough. A few months ago Wi-Fi security was under scrutiny amid a security vulnerability in WPA2, discovered by Vanhoef, which put every WPA2-compatible device -- including routers, phones, and computers -- at risk of hijack. The new WPA3 security standard is expected to land in devices later this year. Sursa: http://www.zdnet.com/article/wpa3-wireless-standard-tougher-wifi-security-revealed/
  8. 6 points
    Vreau si eu o tura cu liftu
  9. 6 points
    Name: TheBodyguard.jpg MD5: 1593E87EA6754E3960A43F6592CC2509 import string alfabet = string.ascii_lowercase alfabet2 = string.ascii_uppercase parola = "?" plain_text = "" for i in parola: if i in alfabet: plain_text += i def enc1(text): ret = "" for i in text: tmp = alfabet.find(i) if tmp != -1: ret += alfabet2[(tmp + 3) % 26] return ret def enc2(t1, t2): ret = "" for i in range(len(t1)): ret += str(ord(t1[i]) + ord(t2[i])) + "," return ret print "You need this:", enc2(parola, enc1(parola)) Output: You need this:201,203,165,195,165,191,205,187,181,191,173,187,173,187,193,199,
  10. 6 points
    Reading privileged memory with a side-channel Posted by Jann Horn, Project Zero We have discovered that CPU data cache timing can be abused to efficiently leak information out of mis-speculated execution, leading to (at worst) arbitrary virtual memory read vulnerabilities across local security boundaries in various contexts. Variants of this issue are known to affect many modern processors, including certain processors by Intel, AMD and ARM. For a few Intel and AMD CPU models, we have exploits that work against real software. We reported this issue to Intel, AMD and ARM on 2017-06-01 [1]. So far, there are three known variants of the issue: Variant 1: bounds check bypass (CVE-2017-5753) Variant 2: branch target injection (CVE-2017-5715) Variant 3: rogue data cache load (CVE-2017-5754) Before the issues described here were publicly disclosed, Daniel Gruss, Moritz Lipp, Yuval Yarom, Paul Kocher, Daniel Genkin, Michael Schwarz, Mike Hamburg, Stefan Mangard, Thomas Prescher and Werner Haas also reported them; their [writeups/blogposts/paper drafts] are at: Spectre (variants 1 and 2) Meltdown (variant 3) During the course of our research, we developed the following proofs of concept (PoCs): A PoC that demonstrates the basic principles behind variant 1 in userspace on the tested Intel Haswell Xeon CPU, the AMD FX CPU, the AMD PRO CPU and an ARM Cortex A57 [2]. This PoC only tests for the ability to read data inside mis-speculated execution within the same process, without crossing any privilege boundaries. A PoC for variant 1 that, when running with normal user privileges under a modern Linux kernel with a distro-standard config, can perform arbitrary reads in a 4GiB range [3] in kernel virtual memory on the Intel Haswell Xeon CPU. If the kernel's BPF JIT is enabled (non-default configuration), it also works on the AMD PRO CPU. On the Intel Haswell Xeon CPU, kernel virtual memory can be read at a rate of around 2000 bytes per second after around 4 seconds of startup time. [4] A PoC for variant 2 that, when running with root privileges inside a KVM guest created using virt-manager on the Intel Haswell Xeon CPU, with a specific (now outdated) version of Debian's distro kernel [5] running on the host, can read host kernel memory at a rate of around 1500 bytes/second, with room for optimization. Before the attack can be performed, some initialization has to be performed that takes roughly between 10 and 30 minutes for a machine with 64GiB of RAM; the needed time should scale roughly linearly with the amount of host RAM. (If 2MB hugepages are available to the guest, the initialization should be much faster, but that hasn't been tested.) A PoC for variant 3 that, when running with normal user privileges, can read kernel memory on the Intel Haswell Xeon CPU under some precondition. We believe that this precondition is that the targeted kernel memory is present in the L1D cache. For interesting resources around this topic, look down into the "Literature" section. A warning regarding explanations about processor internals in this blogpost: This blogpost contains a lot of speculation about hardware internals based on observed behavior, which might not necessarily correspond to what processors are actually doing. We have some ideas on possible mitigations and provided some of those ideas to the processor vendors; however, we believe that the processor vendors are in a much better position than we are to design and evaluate mitigations, and we expect them to be the source of authoritative guidance. The PoC code and the writeups that we sent to the CPU vendors will be made available at a later date. Tested Processors Intel(R) Xeon(R) CPU E5-1650 v3 @ 3.50GHz (called "Intel Haswell Xeon CPU" in the rest of this document) AMD FX(tm)-8320 Eight-Core Processor (called "AMD FX CPU" in the rest of this document) AMD PRO A8-9600 R7, 10 COMPUTE CORES 4C+6G (called "AMD PRO CPU" in the rest of this document) An ARM Cortex A57 core of a Google Nexus 5x phone [6] (called "ARM Cortex A57" in the rest of this document) Glossary retire: An instruction retires when its results, e.g. register writes and memory writes, are committed and made visible to the rest of the system. Instructions can be executed out of order, but must always retire in order. logical processor core: A logical processor core is what the operating system sees as a processor core. With hyperthreading enabled, the number of logical cores is a multiple of the number of physical cores. cached/uncached data: In this blogpost, "uncached" data is data that is only present in main memory, not in any of the cache levels of the CPU. Loading uncached data will typically take over 100 cycles of CPU time. speculative execution: A processor can execute past a branch without knowing whether it will be taken or where its target is, therefore executing instructions before it is known whether they should be executed. If this speculation turns out to have been incorrect, the CPU can discard the resulting state without architectural effects and continue execution on the correct execution path. Instructions do not retire before it is known that they are on the correct execution path. mis-speculation window: The time window during which the CPU speculatively executes the wrong code and has not yet detected that mis-speculation has occurred. Variant 1: Bounds check bypass This section explains the common theory behind all three variants and the theory behind our PoC for variant 1 that, when running in userspace under a Debian distro kernel, can perform arbitrary reads in a 4GiB region of kernel memory in at least the following configurations: Intel Haswell Xeon CPU, eBPF JIT is off (default state) Intel Haswell Xeon CPU, eBPF JIT is on (non-default state) AMD PRO CPU, eBPF JIT is on (non-default state) The state of the eBPF JIT can be toggled using the net.core.bpf_jit_enable sysctl. Theoretical explanation The Intel Optimization Reference Manual says the following regarding Sandy Bridge (and later microarchitectural revisions) in section 2.3.2.3 ("Branch Prediction"): Branch prediction predicts the branch target and enables the processor to begin executing instructions long before the branch true execution path is known. In section 2.3.5.2 ("L1 DCache"): Loads can: [...] Be carried out speculatively, before preceding branches are resolved. Take cache misses out of order and in an overlapped manner. Intel's Software Developer's Manual [7] states in Volume 3A, section 11.7 ("Implicit Caching (Pentium 4, Intel Xeon, and P6 family processors"): Implicit caching occurs when a memory element is made potentially cacheable, although the element may never have been accessed in the normal von Neumann sequence. Implicit caching occurs on the P6 and more recent processor families due to aggressive prefetching, branch prediction, and TLB miss handling. Implicit caching is an extension of the behavior of existing Intel386, Intel486, and Pentium processor systems, since software running on these processor families also has not been able to deterministically predict the behavior of instruction prefetch. Consider the code sample below. If arr1->length is uncached, the processor can speculatively load data from arr1->data[untrusted_offset_from_caller]. This is an out-of-bounds read. That should not matter because the processor will effectively roll back the execution state when the branch has executed; none of the speculatively executed instructions will retire (e.g. cause registers etc. to be affected). struct array { unsigned long length; unsigned char data[]; }; struct array *arr1 = ...; unsigned long untrusted_offset_from_caller = ...; if (untrusted_offset_from_caller < arr1->length) { unsigned char value = arr1->data[untrusted_offset_from_caller]; ... } However, in the following code sample, there's an issue. If arr1->length, arr2->data[0x200] andarr2->data[0x300] are not cached, but all other accessed data is, and the branch conditions are predicted as true, the processor can do the following speculatively before arr1->length has been loaded and the execution is re-steered: load value = arr1->data[untrusted_offset_from_caller] start a load from a data-dependent offset in arr2->data, loading the corresponding cache line into the L1 cache struct array { unsigned long length; unsigned char data[]; }; struct array *arr1 = ...; /* small array */ struct array *arr2 = ...; /* array of size 0x400 */ /* >0x400 (OUT OF BOUNDS!) */ unsigned long untrusted_offset_from_caller = ...; if (untrusted_offset_from_caller < arr1->length) { unsigned char value = arr1->data[untrusted_offset_from_caller]; unsigned long index2 = ((value&1)*0x100)+0x200; if (index2 < arr2->length) { unsigned char value2 = arr2->data[index2]; } } After the execution has been returned to the non-speculative path because the processor has noticed thatuntrusted_offset_from_caller is bigger than arr1->length, the cache line containing arr2->data[index2] stays in the L1 cache. By measuring the time required to load arr2->data[0x200] andarr2->data[0x300], an attacker can then determine whether the value of index2 during speculative execution was 0x200 or 0x300 - which discloses whether arr1->data[untrusted_offset_from_caller]&1 is 0 or 1. To be able to actually use this behavior for an attack, an attacker needs to be able to cause the execution of such a vulnerable code pattern in the targeted context with an out-of-bounds index. For this, the vulnerable code pattern must either be present in existing code, or there must be an interpreter or JIT engine that can be used to generate the vulnerable code pattern. So far, we have not actually identified any existing, exploitable instances of the vulnerable code pattern; the PoC for leaking kernel memory using variant 1 uses the eBPF interpreter or the eBPF JIT engine, which are built into the kernel and accessible to normal users. A minor variant of this could be to instead use an out-of-bounds read to a function pointer to gain control of execution in the mis-speculated path. We did not investigate this variant further. Attacking the kernel This section describes in more detail how variant 1 can be used to leak Linux kernel memory using the eBPF bytecode interpreter and JIT engine. While there are many interesting potential targets for variant 1 attacks, we chose to attack the Linux in-kernel eBPF JIT/interpreter because it provides more control to the attacker than most other JITs. The Linux kernel supports eBPF since version 3.18. Unprivileged userspace code can supply bytecode to the kernel that is verified by the kernel and then: either interpreted by an in-kernel bytecode interpreter or translated to native machine code that also runs in kernel context using a JIT engine (which translates individual bytecode instructions without performing any further optimizations) Execution of the bytecode can be triggered by attaching the eBPF bytecode to a socket as a filter and then sending data through the other end of the socket. Whether the JIT engine is enabled depends on a run-time configuration setting - but at least on the tested Intel processor, the attack works independent of that setting. Unlike classic BPF, eBPF has data types like data arrays and function pointer arrays into which eBPF bytecode can index. Therefore, it is possible to create the code pattern described above in the kernel using eBPF bytecode. eBPF's data arrays are less efficient than its function pointer arrays, so the attack will use the latter where possible. Both machines on which this was tested have no SMAP, and the PoC relies on that (but it shouldn't be a precondition in principle). Additionally, at least on the Intel machine on which this was tested, bouncing modified cache lines between cores is slow, apparently because the MESI protocol is used for cache coherence [8]. Changing the reference counter of an eBPF array on one physical CPU core causes the cache line containing the reference counter to be bounced over to that CPU core, making reads of the reference counter on all other CPU cores slow until the changed reference counter has been written back to memory. Because the length and the reference counter of an eBPF array are stored in the same cache line, this also means that changing the reference counter on one physical CPU core causes reads of the eBPF array's length to be slow on other physical CPU cores (intentional false sharing). The attack uses two eBPF programs. The first one tail-calls through a page-aligned eBPF function pointer array prog_map at a configurable index. In simplified terms, this program is used to determine the address of prog_map by guessing the offset from prog_map to a userspace address and tail-calling throughprog_map at the guessed offsets. To cause the branch prediction to predict that the offset is below the length of prog_map, tail calls to an in-bounds index are performed in between. To increase the mis-speculation window, the cache line containing the length of prog_map is bounced to another core. To test whether an offset guess was successful, it can be tested whether the userspace address has been loaded into the cache. Because such straightforward brute-force guessing of the address would be slow, the following optimization is used: 215 adjacent userspace memory mappings [9], each consisting of 24 pages, are created at the userspace address user_mapping_area, covering a total area of 231 bytes. Each mapping maps the same physical pages, and all mappings are present in the pagetables. This permits the attack to be carried out in steps of 231 bytes. For each step, after causing an out-of-bounds access through prog_map, only one cache line each from the first 24 pages of user_mapping_area have to be tested for cached memory. Because the L3 cache is physically indexed, any access to a virtual address mapping a physical page will cause all other virtual addresses mapping the same physical page to become cached as well. When this attack finds a hit—a cached memory location—the upper 33 bits of the kernel address are known (because they can be derived from the address guess at which the hit occurred), and the low 16 bits of the address are also known (from the offset inside user_mapping_area at which the hit was found). The remaining part of the address of user_mapping_area is the middle. The remaining bits in the middle can be determined by bisecting the remaining address space: Map two physical pages to adjacent ranges of virtual addresses, each virtual address range the size of half of the remaining search space, then determine the remaining address bit-wise. At this point, a second eBPF program can be used to actually leak data. In pseudocode, this program looks as follows: uint64_t bitmask = <runtime-configurable>; uint64_t bitshift_selector = <runtime-configurable>; uint64_t prog_array_base_offset = <runtime-configurable>; uint64_t secret_data_offset = <runtime-configurable>; // index will be bounds-checked by the runtime, // but the bounds check will be bypassed speculatively uint64_t secret_data = bpf_map_read(array=victim_array, index=secret_data_offset); // select a single bit, move it to a specific position, and add the base offset uint64_t progmap_index = (((secret_data & bitmask) >> bitshift_selector) << 7) + prog_array_base_offset; bpf_tail_call(prog_map, progmap_index); This program reads 8-byte-aligned 64-bit values from an eBPF data array "victim_map" at a runtime-configurable offset and bitmasks and bit-shifts the value so that one bit is mapped to one of two values that are 27 bytes apart (sufficient to not land in the same or adjacent cache lines when used as an array index). Finally it adds a 64-bit offset, then uses the resulting value as an offset into prog_map for a tail call. This program can then be used to leak memory by repeatedly calling the eBPF program with an out-of-bounds offset into victim_map that specifies the data to leak and an out-of-bounds offset into prog_mapthat causes prog_map + offset to point to a userspace memory area. Misleading the branch prediction and bouncing the cache lines works the same way as for the first eBPF program, except that now, the cache line holding the length of victim_map must also be bounced to another core. Variant 2: Branch target injection This section describes the theory behind our PoC for variant 2 that, when running with root privileges inside a KVM guest created using virt-manager on the Intel Haswell Xeon CPU, with a specific version of Debian's distro kernel running on the host, can read host kernel memory at a rate of around 1500 bytes/second. Basics Prior research (see the Literature section at the end) has shown that it is possible for code in separate security contexts to influence each other's branch prediction. So far, this has only been used to infer information about where code is located (in other words, to create interference from the victim to the attacker); however, the basic hypothesis of this attack variant is that it can also be used to redirect execution of code in the victim context (in other words, to create interference from the attacker to the victim; the other way around). The basic idea for the attack is to target victim code that contains an indirect branch whose target address is loaded from memory and flush the cache line containing the target address out to main memory. Then, when the CPU reaches the indirect branch, it won't know the true destination of the jump, and it won't be able to calculate the true destination until it has finished loading the cache line back into the CPU, which takes a few hundred cycles. Therefore, there is a time window of typically over 100 cycles in which the CPU will speculatively execute instructions based on branch prediction. Haswell branch prediction internals Some of the internals of the branch prediction implemented by Intel's processors have already been published; however, getting this attack to work properly required significant further experimentation to determine additional details. This section focuses on the branch prediction internals that were experimentally derived from the Intel Haswell Xeon CPU. Haswell seems to have multiple branch prediction mechanisms that work very differently: A generic branch predictor that can only store one target per source address; used for all kinds of jumps, like absolute jumps, relative jumps and so on. A specialized indirect call predictor that can store multiple targets per source address; used for indirect calls. (There is also a specialized return predictor, according to Intel's optimization manual, but we haven't analyzed that in detail yet. If this predictor could be used to reliably dump out some of the call stack through which a VM was entered, that would be very interesting.) Generic predictor The generic branch predictor, as documented in prior research, only uses the lower 31 bits of the address of the last byte of the source instruction for its prediction. If, for example, a branch target buffer (BTB) entry exists for a jump from 0x4141.0004.1000 to 0x4141.0004.5123, the generic predictor will also use it to predict a jump from 0x4242.0004.1000. When the higher bits of the source address differ like this, the higher bits of the predicted destination change together with it—in this case, the predicted destination address will be 0x4242.0004.5123—so apparently this predictor doesn't store the full, absolute destination address. Before the lower 31 bits of the source address are used to look up a BTB entry, they are folded together using XOR. Specifically, the following bits are folded together: bit A bit B 0x40.0000 0x2000 0x80.0000 0x4000 0x100.0000 0x8000 0x200.0000 0x1.0000 0x400.0000 0x2.0000 0x800.0000 0x4.0000 0x2000.0000 0x10.0000 0x4000.0000 0x20.0000 In other words, if a source address is XORed with both numbers in a row of this table, the branch predictor will not be able to distinguish the resulting address from the original source address when performing a lookup. For example, the branch predictor is able to distinguish source addresses 0x100.0000 and 0x180.0000, and it can also distinguish source addresses 0x100.0000 and 0x180.8000, but it can't distinguish source addresses 0x100.0000 and 0x140.2000 or source addresses 0x100.0000 and 0x180.4000. In the following, this will be referred to as aliased source addresses. When an aliased source address is used, the branch predictor will still predict the same target as for the unaliased source address. This indicates that the branch predictor stores a truncated absolute destination address, but that hasn't been verified. Based on observed maximum forward and backward jump distances for different source addresses, the low 32-bit half of the target address could be stored as an absolute 32-bit value with an additional bit that specifies whether the jump from source to target crosses a 232 boundary; if the jump crosses such a boundary, bit 31 of the source address determines whether the high half of the instruction pointer should increment or decrement. Indirect call predictor The inputs of the BTB lookup for this mechanism seem to be: The low 12 bits of the address of the source instruction (we are not sure whether it's the address of the first or the last byte) or a subset of them. The branch history buffer state. If the indirect call predictor can't resolve a branch, it is resolved by the generic predictor instead. Intel's optimization manual hints at this behavior: "Indirect Calls and Jumps. These may either be predicted as having a monotonic target or as having targets that vary in accordance with recent program behavior." The branch history buffer (BHB) stores information about the last 29 taken branches - basically a fingerprint of recent control flow - and is used to allow better prediction of indirect calls that can have multiple targets. The update function of the BHB works as follows (in pseudocode; src is the address of the last byte of the source instruction, dst is the destination address): void bhb_update(uint58_t *bhb_state, unsigned long src, unsigned long dst) { *bhb_state <<= 2; *bhb_state ^= (dst & 0x3f); *bhb_state ^= (src & 0xc0) >> 6; *bhb_state ^= (src & 0xc00) >> (10 - 2); *bhb_state ^= (src & 0xc000) >> (14 - 4); *bhb_state ^= (src & 0x30) << (6 - 4); *bhb_state ^= (src & 0x300) << (8 - 8); *bhb_state ^= (src & 0x3000) >> (12 - 10); *bhb_state ^= (src & 0x30000) >> (16 - 12); *bhb_state ^= (src & 0xc0000) >> (18 - 14); } Some of the bits of the BHB state seem to be folded together further using XOR when used for a BTB access, but the precise folding function hasn't been understood yet. The BHB is interesting for two reasons. First, knowledge about its approximate behavior is required in order to be able to accurately cause collisions in the indirect call predictor. But it also permits dumping out the BHB state at any repeatable program state at which the attacker can execute code - for example, when attacking a hypervisor, directly after a hypercall. The dumped BHB state can then be used to fingerprint the hypervisor or, if the attacker has access to the hypervisor binary, to determine the low 20 bits of the hypervisor load address (in the case of KVM: the low 20 bits of the load address of kvm-intel.ko). Reverse-Engineering Branch Predictor Internals This subsection describes how we reverse-engineered the internals of the Haswell branch predictor. Some of this is written down from memory, since we didn't keep a detailed record of what we were doing. We initially attempted to perform BTB injections into the kernel using the generic predictor, using the knowledge from prior research that the generic predictor only looks at the lower half of the source address and that only a partial target address is stored. This kind of worked - however, the injection success rate was very low, below 1%. (This is the method we used in our preliminary PoCs for method 2 against modified hypervisors running on Haswell.) We decided to write a userspace test case to be able to more easily test branch predictor behavior in different situations. Based on the assumption that branch predictor state is shared between hyperthreads [10], we wrote a program of which two instances are each pinned to one of the two logical processors running on a specific physical core, where one instance attempts to perform branch injections while the other measures how often branch injections are successful. Both instances were executed with ASLR disabled and had the same code at the same addresses. The injecting process performed indirect calls to a function that accesses a (per-process) test variable; the measuring process performed indirect calls to a function that tests, based on timing, whether the per-process test variable is cached, and then evicts it using CLFLUSH. Both indirect calls were performed through the same callsite. Before each indirect call, the function pointer stored in memory was flushed out to main memory using CLFLUSH to widen the speculation time window. Additionally, because of the reference to "recent program behavior" in Intel's optimization manual, a bunch of conditional branches that are always taken were inserted in front of the indirect call. In this test, the injection success rate was above 99%, giving us a base setup for future experiments. We then tried to figure out the details of the prediction scheme. We assumed that the prediction scheme uses a global branch history buffer of some kind. To determine the duration for which branch information stays in the history buffer, a conditional branch that is only taken in one of the two program instances was inserted in front of the series of always-taken conditional jumps, then the number of always-taken conditional jumps (N) was varied. The result was that for N=25, the processor was able to distinguish the branches (misprediction rate under 1%), but for N=26, it failed to do so (misprediction rate over 99%). Therefore, the branch history buffer had to be able to store information about at least the last 26 branches. The code in one of the two program instances was then moved around in memory. This revealed that only the lower 20 bits of the source and target addresses have an influence on the branch history buffer. Testing with different types of branches in the two program instances revealed that static jumps, taken conditional jumps, calls and returns influence the branch history buffer the same way; non-taken conditional jumps don't influence it; the address of the last byte of the source instruction is the one that counts; IRETQ doesn't influence the history buffer state (which is useful for testing because it permits creating program flow that is invisible to the history buffer). Moving the last conditional branch before the indirect call around in memory multiple times revealed that the branch history buffer contents can be used to distinguish many different locations of that last conditional branch instruction. This suggests that the history buffer doesn't store a list of small history values; instead, it seems to be a larger buffer in which history data is mixed together. However, a history buffer needs to "forget" about past branches after a certain number of new branches have been taken in order to be useful for branch prediction. Therefore, when new data is mixed into the history buffer, this can not cause information in bits that are already present in the history buffer to propagate downwards - and given that, upwards combination of information probably wouldn't be very useful either. Given that branch prediction also must be very fast, we concluded that it is likely that the update function of the history buffer left-shifts the old history buffer, then XORs in the new state (see diagram). If this assumption is correct, then the history buffer contains a lot of information about the most recent branches, but only contains as many bits of information as are shifted per history buffer update about the last branch about which it contains any data. Therefore, we tested whether flipping different bits in the source and target addresses of a jump followed by 32 always-taken jumps with static source and target allows the branch prediction to disambiguate an indirect call. [11] With 32 static jumps in between, no bit flips seemed to have an influence, so we decreased the number of static jumps until a difference was observable. The result with 28 always-taken jumps in between was that bits 0x1 and 0x2 of the target and bits 0x40 and 0x80 of the source had such an influence; but flipping both 0x1 in the target and 0x40 in the source or 0x2 in the target and 0x80 in the source did not permit disambiguation. This shows that the per-insertion shift of the history buffer is 2 bits and shows which data is stored in the least significant bits of the history buffer. We then repeated this with decreased amounts of fixed jumps after the bit-flipped jump to determine which information is stored in the remaining bits. Reading host memory from a KVM guest Locating the host kernel Our PoC locates the host kernel in several steps. The information that is determined and necessary for the next steps of the attack consists of: lower 20 bits of the address of kvm-intel.ko full address of kvm.ko full address of vmlinux Looking back, this is unnecessarily complicated, but it nicely demonstrates the various techniques an attacker can use. A simpler way would be to first determine the address of vmlinux, then bisect the addresses of kvm.ko and kvm-intel.ko. In the first step, the address of kvm-intel.ko is leaked. For this purpose, the branch history buffer state after guest entry is dumped out. Then, for every possible value of bits 12..19 of the load address of kvm-intel.ko, the expected lowest 16 bits of the history buffer are computed based on the load address guess and the known offsets of the last 8 branches before guest entry, and the results are compared against the lowest 16 bits of the leaked history buffer state. The branch history buffer state is leaked in steps of 2 bits by measuring misprediction rates of an indirect call with two targets. One way the indirect call is reached is from a vmcall instruction followed by a series of N branches whose relevant source and target address bits are all zeroes. The second way the indirect call is reached is from a series of controlled branches in userspace that can be used to write arbitrary values into the branch history buffer. Misprediction rates are measured as in the section "Reverse-Engineering Branch Predictor Internals", using one call target that loads a cache line and another one that checks whether the same cache line has been loaded. With N=29, mispredictions will occur at a high rate if the controlled branch history buffer value is zero because all history buffer state from the hypercall has been erased. With N=28, mispredictions will occur if the controlled branch history buffer value is one of 0<<(28*2), 1<<(28*2), 2<<(28*2), 3<<(28*2) - by testing all four possibilities, it can be detected which one is right. Then, for decreasing values of N, the four possibilities are {0|1|2|3}<<(28*2) | (history_buffer_for(N+1) >> 2). By repeating this for decreasing values for N, the branch history buffer value for N=0 can be determined. At this point, the low 20 bits of kvm-intel.ko are known; the next step is to roughly locate kvm.ko. For this, the generic branch predictor is used, using data inserted into the BTB by an indirect call from kvm.ko to kvm-intel.ko that happens on every hypercall; this means that the source address of the indirect call has to be leaked out of the BTB. kvm.ko will probably be located somewhere in the range from 0xffffffffc0000000 to0xffffffffc4000000, with page alignment (0x1000). This means that the first four entries in the table in the section "Generic Predictor" apply; there will be 24-1=15 aliasing addresses for the correct one. But that is also an advantage: It cuts down the search space from 0x4000 to 0x4000/24=1024. To find the right address for the source or one of its aliasing addresses, code that loads data through a specific register is placed at all possible call targets (the leaked low 20 bits of kvm-intel.ko plus the in-module offset of the call target plus a multiple of 220) and indirect calls are placed at all possible call sources. Then, alternatingly, hypercalls are performed and indirect calls are performed through the different possible non-aliasing call sources, with randomized history buffer state that prevents the specialized prediction from working. After this step, there are 216 remaining possibilities for the load address of kvm.ko. Next, the load address of vmlinux can be determined in a similar way, using an indirect call from vmlinux to kvm.ko. Luckily, none of the bits which are randomized in the load address of vmlinux are folded together, so unlike when locating kvm.ko, the result will directly be unique. vmlinux has an alignment of 2MiB and a randomization range of 1GiB, so there are still only 512 possible addresses. Because (as far as we know) a simple hypercall won't actually cause indirect calls from vmlinux to kvm.ko, we instead use port I/O from the status register of an emulated serial port, which is present in the default configuration of a virtual machine created with virt-manager. The only remaining piece of information is which one of the 16 aliasing load addresses of kvm.ko is actually correct. Because the source address of an indirect call to kvm.ko is known, this can be solved using bisection: Place code at the various possible targets that, depending on which instance of the code is speculatively executed, loads one of two cache lines, and measure which one of the cache lines gets loaded. Identifying cache sets The PoC assumes that the VM does not have access to hugepages.To discover eviction sets for all L3 cache sets with a specific alignment relative to a 4KiB page boundary, the PoC first allocates 25600 pages of memory. Then, in a loop, it selects random subsets of all remaining unsorted pages such that the expected number of sets for which an eviction set is contained in the subset is 1, reduces each subset down to an eviction set by repeatedly accessing its cache lines and testing whether the cache lines are always cached (in which case they're probably not part of an eviction set) and attempts to use the new eviction set to evict all remaining unsorted cache lines to determine whether they are in the same cache set [12]. Locating the host-virtual address of a guest page Because this attack uses a FLUSH+RELOAD approach for leaking data, it needs to know the host-kernel-virtual address of one guest page. Alternative approaches such as PRIME+PROBE should work without that requirement. The basic idea for this step of the attack is to use a branch target injection attack against the hypervisor to load an attacker-controlled address and test whether that caused the guest-owned page to be loaded. For this, a gadget that simply loads from the memory location specified by R8 can be used - R8-R11 still contain guest-controlled values when the first indirect call after a guest exit is reached on this kernel build. We expected that an attacker would need to either know which eviction set has to be used at this point or brute-force it simultaneously; however, experimentally, using random eviction sets works, too. Our theory is that the observed behavior is actually the result of L1D and L2 evictions, which might be sufficient to permit a few instructions worth of speculative execution. The host kernel maps (nearly?) all physical memory in the physmap area, including memory assigned to KVM guests. However, the location of the physmap is randomized (with a 1GiB alignment), in an area of size 128PiB. Therefore, directly bruteforcing the host-virtual address of a guest page would take a long time. It is not necessarily impossible; as a ballpark estimate, it should be possible within a day or so, maybe less, assuming 12000 successful injections per second and 30 guest pages that are tested in parallel; but not as impressive as doing it in a few minutes. To optimize this, the problem can be split up: First, brute-force the physical address using a gadget that can load from physical addresses, then brute-force the base address of the physmap region. Because the physical address can usually be assumed to be far below 128PiB, it can be brute-forced more efficiently, and brute-forcing the base address of the physmap region afterwards is also easier because then address guesses with 1GiB alignment can be used. To brute-force the physical address, the following gadget can be used: ffffffff810a9def: 4c 89 c0 mov rax,r8 ffffffff810a9df2: 4d 63 f9 movsxd r15,r9d ffffffff810a9df5: 4e 8b 04 fd c0 b3 a6 mov r8,QWORD PTR [r15*8-0x7e594c40] ffffffff810a9dfc: 81 ffffffff810a9dfd: 4a 8d 3c 00 lea rdi,[rax+r8*1] ffffffff810a9e01: 4d 8b a4 00 f8 00 00 mov r12,QWORD PTR [r8+rax*1+0xf8] ffffffff810a9e08: 00 This gadget permits loading an 8-byte-aligned value from the area around the kernel text section by setting R9 appropriately, which in particular permits loading page_offset_base, the start address of the physmap. Then, the value that was originally in R8 - the physical address guess minus 0xf8 - is added to the result of the previous load, 0xfa is added to it, and the result is dereferenced. Cache set selection To select the correct L3 eviction set, the attack from the following section is essentially executed with different eviction sets until it works. Leaking data At this point, it would normally be necessary to locate gadgets in the host kernel code that can be used to actually leak data by reading from an attacker-controlled location, shifting and masking the result appropriately and then using the result of that as offset to an attacker-controlled address for a load. But piecing gadgets together and figuring out which ones work in a speculation context seems annoying. So instead, we decided to use the eBPF interpreter, which is built into the host kernel - while there is no legitimate way to invoke it from inside a VM, the presence of the code in the host kernel's text section is sufficient to make it usable for the attack, just like with ordinary ROP gadgets. The eBPF interpreter entry point has the following function signature: static unsigned int __bpf_prog_run(void *ctx, const struct bpf_insn *insn) The second parameter is a pointer to an array of statically pre-verified eBPF instructions to be executed - which means that __bpf_prog_run() will not perform any type checks or bounds checks. The first parameter is simply stored as part of the initial emulated register state, so its value doesn't matter. The eBPF interpreter provides, among other things: multiple emulated 64-bit registers 64-bit immediate writes to emulated registers memory reads from addresses stored in emulated registers bitwise operations (including bit shifts) and arithmetic operations To call the interpreter entry point, a gadget that gives RSI and RIP control given R8-R11 control and controlled data at a known memory location is necessary. The following gadget provides this functionality: ffffffff81514edd: 4c 89 ce mov rsi,r9 ffffffff81514ee0: 41 ff 90 b0 00 00 00 call QWORD PTR [r8+0xb0] Now, by pointing R8 and R9 at the mapping of a guest-owned page in the physmap, it is possible to speculatively execute arbitrary unvalidated eBPF bytecode in the host kernel. Then, relatively straightforward bytecode can be used to leak data into the cache. Variant 3: Rogue data cache load Basically, read Anders Fogh's blogpost: https://cyber.wtf/2017/07/28/negative-result-reading-kernel-memory-from-user-mode/ In summary, an attack using this variant of the issue attempts to read kernel memory from userspace without misdirecting the control flow of kernel code. This works by using the code pattern that was used for the previous variants, but in userspace. The underlying idea is that the permission check for accessing an address might not be on the critical path for reading data from memory to a register, where the permission check could have significant performance impact. Instead, the memory read could make the result of the read available to following instructions immediately and only perform the permission check asynchronously, setting a flag in the reorder buffer that causes an exception to be raised if the permission check fails. We do have a few additions to make to Anders Fogh's blogpost: "Imagine the following instruction executed in usermode mov rax,[somekernelmodeaddress] It will cause an interrupt when retired, [...]" It is also possible to already execute that instruction behind a high-latency mispredicted branch to avoid taking a page fault. This might also widen the speculation window by increasing the delay between the read from a kernel address and delivery of the associated exception. "First, I call a syscall that touches this memory. Second, I use the prefetcht0 instruction to improve my odds of having the address loaded in L1." When we used prefetch instructions after doing a syscall, the attack stopped working for us, and we have no clue why. Perhaps the CPU somehow stores whether access was denied on the last access and prevents the attack from working if that is the case? "Fortunately I did not get a slow read suggesting that Intel null’s the result when the access is not allowed." That (read from kernel address returns all-zeroes) seems to happen for memory that is not sufficiently cached but for which pagetable entries are present, at least after repeated read attempts. For unmapped memory, the kernel address read does not return a result at all. Ideas for further research We believe that our research provides many remaining research topics that we have not yet investigated, and we encourage other public researchers to look into these. This section contains an even higher amount of speculation than the rest of this blogpost - it contains untested ideas that might well be useless. Leaking without data cache timing It would be interesting to explore whether there are microarchitectural attacks other than measuring data cache timing that can be used for exfiltrating data out of speculative execution. Other microarchitectures Our research was relatively Haswell-centric so far. It would be interesting to see details e.g. on how the branch prediction of other modern processors works and how well it can be attacked. Other JIT engines We developed a successful variant 1 attack against the JIT engine built into the Linux kernel. It would be interesting to see whether attacks against more advanced JIT engines with less control over the system are also practical - in particular, JavaScript engines. More efficient scanning for host-virtual addresses and cache sets In variant 2, while scanning for the host-virtual address of a guest-owned page, it might make sense to attempt to determine its L3 cache set first. This could be done by performing L3 evictions using an eviction pattern through the physmap, then testing whether the eviction affected the guest-owned page. The same might work for cache sets - use an L1D+L2 eviction set to evict the function pointer in the host kernel context, use a gadget in the kernel to evict an L3 set using physical addresses, then use that to identify which cache sets guest lines belong to until a guest-owned eviction set has been constructed. Dumping the complete BTB state Given that the generic BTB seems to only be able to distinguish 231-8 or fewer source addresses, it seems feasible to dump out the complete BTB state generated by e.g. a hypercall in a timeframe around the order of a few hours. (Scan for jump sources, then for every discovered jump source, bisect the jump target.) This could potentially be used to identify the locations of functions in the host kernel even if the host kernel is custom-built. The source address aliasing would reduce the usefulness somewhat, but because target addresses don't suffer from that, it might be possible to correlate (source,target) pairs from machines with different KASLR offsets and reduce the number of candidate addresses based on KASLR being additive while aliasing is bitwise. This could then potentially allow an attacker to make guesses about the host kernel version or the compiler used to build it based on jump offsets or distances between functions. Variant 2: Leaking with more efficient gadgets If sufficiently efficient gadgets are used for variant 2, it might not be necessary to evict host kernel function pointers from the L3 cache at all; it might be sufficient to only evict them from L1D and L2. Various speedups In particular the variant 2 PoC is still a bit slow. This is probably partly because: It only leaks one bit at a time; leaking more bits at a time should be doable. It heavily uses IRETQ for hiding control flow from the processor. It would be interesting to see what data leak rate can be achieved using variant 2. Leaking or injection through the return predictor If the return predictor also doesn't lose its state on a privilege level change, it might be useful for either locating the host kernel from inside a VM (in which case bisection could be used to very quickly discover the full address of the host kernel) or injecting return targets (in particular if the return address is stored in a cache line that can be flushed out by the attacker and isn't reloaded before the return instruction). However, we have not performed any experiments with the return predictor that yielded conclusive results so far. Leaking data out of the indirect call predictor We have attempted to leak target information out of the indirect call predictor, but haven't been able to make it work. Vendor statements The following statement were provided to us regarding this issue from the vendors to whom Project Zero disclosed this vulnerability: Intel No current statement provided at this time. AMD AMD provided the following link: http://www.amd.com/en/corporate/speculative-execution ARM Arm recognises that the speculation functionality of many modern high-performance processors, despite working as intended, can be used in conjunction with the timing of cache operations to leak some information as described in this blog. Correspondingly, Arm has developed software mitigations that we recommend be deployed. Specific details regarding the affected processors and mitigations can be found at this website:https://developer.arm.com/support/security-update Arm has included a detailed technical whitepaper as well as links to information from some of Arm’s architecture partners regarding their specific implementations and mitigations. Literature Note that some of these documents - in particular Intel's documentation - change over time, so quotes from and references to it may not reflect the latest version of Intel's documentation. https://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-optimization-manual.pdf: Intel's optimization manual has many interesting pieces of optimization advice that hint at relevant microarchitectural behavior; for example: "Placing data immediately following an indirect branch can cause a performance problem. If the data consists of all zeros, it looks like a long stream of ADDs to memory destinations and this can cause resource conflicts and slow down branch recovery. Also, data immediately following indirect branches may appear as branches to the branch predication [sic] hardware, which can branch off to execute other data pages. This can lead to subsequent self-modifying code problems." "Loads can:[...]Be carried out speculatively, before preceding branches are resolved." "Software should avoid writing to a code page in the same 1-KByte subpage that is being executed or fetching code in the same 2-KByte subpage of that is being written. In addition, sharing a page containing directly or speculatively executed code with another processor as a data page can trigger an SMC condition that causes the entire pipeline of the machine and the trace cache to be cleared. This is due to the self-modifying code condition." "if mapped as WB or WT, there is a potential for speculative processor reads to bring the data into the caches" "Failure to map the region as WC may allow the line to be speculatively read into the processor caches (via the wrong path of a mispredicted branch)." https://software.intel.com/en-us/articles/intel-sdm: Intel's Software Developer Manuals http://www.agner.org/optimize/microarchitecture.pdf: Agner Fog's documentation of reverse-engineered processor behavior and relevant theory was very helpful for this research. http://www.cs.binghamton.edu/~dima/micro16.pdf and https://github.com/felixwilhelm/mario_baslr: Prior research by Dmitry Evtyushkin, Dmitry Ponomarev and Nael Abu-Ghazaleh on abusing branch target buffer behavior to leak addresses that we used as a starting point for analyzing the branch prediction of Haswell processors. Felix Wilhelm's research based on this provided the basic idea behind variant 2. https://arxiv.org/pdf/1507.06955.pdf: The rowhammer.js research by Daniel Gruss, Clémentine Maurice and Stefan Mangard contains information about L3 cache eviction patterns that we reused in the KVM PoC to evict a function pointer. https://xania.org/201602/bpu-part-one: Matt Godbolt blogged about reverse-engineering the structure of the branch predictor on Intel processors. https://www.sophia.re/thesis.pdf: Sophia D'Antoine wrote a thesis that shows that opcode scheduling can theoretically be used to transmit data between hyperthreads. https://gruss.cc/files/kaiser.pdf: Daniel Gruss, Moritz Lipp, Michael Schwarz, Richard Fellner, Clémentine Maurice, and Stefan Mangard wrote a paper on mitigating microarchitectural issues caused by pagetable sharing between userspace and the kernel. https://www.jilp.org/: This journal contains many articles on branch prediction. http://blog.stuffedcow.net/2013/01/ivb-cache-replacement/: This blogpost by Henry Wong investigates the L3 cache replacement policy used by Intel's Ivy Bridge architecture. Source: https://googleprojectzero.blogspot.ro/2018/01/reading-privileged-memory-with-side.html ### MELTDOWN ATTACK AND SPECTRE ### https://meltdownattack.com/
  11. 6 points
    This course looks at web users from a few different perspectives. First, we look at identifying techniques to determine web user identities from a server perspective. Second, we will look at obfuscating techniques from a user whom seeks to be anonymous. Finally, we look at forensic techniques, which, when given a hard drive or similar media, we identify users who accessed that server. Slides: http://opensecuritytraining.info/WebIdentity_files/WebIdentity_all_slides_pptx_1.zip HD video: Sursa: http://opensecuritytraining.info/WebIdentity.html
  12. 5 points
    Un Deep Neural Network (Read More) care `invata` sa faca distinctia intre o pisica si un caine. (Cel putin incearca) Link Imagini:
  13. 5 points
    Ce treaba ai tu ma. Lasa femeia sa bage si ea o mufa ceva :))))))) Puteai sa spui simplu ca vrei sa accesezi o camera, nu ca e coana ma-ta implicata acolo. Deja mi s-au sculat doua pule cu gandul la ce ar putea face in lift. Dubiosule.
  14. 5 points
    Matematic si statistic vorbind, daca e vorba de mame, e posibil ca @aelius sa fie implicat. Spune-i sa isi ia un GoPro sa vezi actiunea din lift cu mami tau in 60fps si HD.
  15. 5 points
    Introduction Bitcoin and cryptocurrencies made a lot of noise lately. I have been rather disappointed by the turn the cryptocurrencies took, from an amazing concept to what seems just another way to make quick money ( or not... ). But I became very interested by the technologies enabling cryptocurrencies, and obviously by the concept of a blockchain. The concept is fascinating, and not limited to Bitcoin and friends. We could imagine many applications for such a technology. So, in a proper developer manner, I decided to code one blockchain, or what I think is a blockchain, to understand better what it is. A simple project So, what do we need to create a very simple blockchain? A block A block is what the blockchain is made of. In our case, a block will be composed of a date, an index, some data ( a message in our case ), and the hash of the previous block. Cryptography To keep informations secure, we need to encrypt our data. For our little project, we will use the js-sha256 package. This process will create a string of 64 characters. Ultimately, our blockchain will be a series of hashes, each composed of 64 characters. As I said earlier, we use the hash of the previous block to encrypt a new block ( that is why we call it a chain ). Difficulty and nonce We don't just create one hash per block and that's it. A hash must be valid. In our case, a hash will be valid if the first four characters of our hash are 0. If our hash starts with '0000......', it is considered valid. This is called the difficulty. The higher the difficulty, the longer it takes to get a valid hash. But, if the hash is not valid the first time, something must change in the data we use right? If we use the same data over and over, we will get the same hash over and over and our hash will never be valid. You are right, we use something called nonce in our hash. It is simply a number that we increment each time the hash is not valid. We get our data (date, message, previous hash, index) and a nonce of 1. If the hash we get with these is not valid, we try with a nonce of 2. And we increment the nonce until we get a valid hash. Genesis block Their must be a first block in our chain. It is called the genesis block. Of course, this block can't use the hash of the previous block because it doesn't exist. We will just give it some arbitrary data to create its hash. And that is pretty much what we need for our blockchain. The methods We will need a few methods to make a functional blockchain: initialize our blockchain => creates the genesis block hash our blocks => a function responsible for creating a valid hash check the validity of a hash => does our hash starts with 'OOOO' ? get the last hash => we need the previous hash to create a new block add a new block => We need to do that at one point, if we want a chain THE COOOOODE !! Let's get coding now. For this little project, I will create two files, one called index.js and another called blockchain.js. The second one will hold our little module to create a blockchain. It's straightforward, let's take a look at it: const sha256 = require('js-sha256').sha256 const blockchain = (function(){ const blocks = [] const initBlockchain = () => { const data = 'Hello World!' const timestamp = new Date() const previousHash = 0 const index = 0 hashBlock(data, timestamp, previousHash, index) } const hashBlock = (data, timestamp, prevHash, index) => { let hash = '', nonce = 0 while( !isHashValid(hash) ){ let input = `${data}${timestamp}${prevHash}${index}${nonce}` hash = sha256(input) nonce += 1 } console.log(nonce) blocks.push(hash) } const getLastHash = blocks => blocks.slice(-1)[0] const isHashValid = hash => hash.startsWith('0000') // Difficulty const addNewBlock = data => { const index = blocks.length const previousHash = getLastHash(blocks) hashBlock(data, new Date(), previousHash, index) } const getAllBlocks = () => blocks return { initBlockchain, getLastHash, blocks, getAllBlocks, addNewBlock } })() module.exports = blockchain So, in this module, I have a few methods. At the top, I import the module that will handle the cryptography part. I have an empty array that will hold my blockchain's blocks, called blocks. initBlockchain: This method starts the blockchain by creating the first block, the genesis block. I give it a timestamp, a message, the block's index in the blockchain ( 0 ) and a arbitrary previous hash because there are no previous blocks in the chain yet. With all these informations, I can now create the hash for the genesis block. hashBlock: This method takes all the block's data and creates a hash. As you can see, the first time we run the function for a specific block, the nonce is set to 0. We encrypt our block and check if the hash is valid with isHashValid. In our case, a hash is valid if the four first characters are 0. This is called the difficulty. This is the problem we have to solve to make sure the block can be part of the blockchain. Once the hash is valid, we add it to our blocks array. addNewBlock: This method is responsible for creating a new block. We only need to give it the message as an argument, because all the other arguments ( index, previousHash, and timestamp) can be found in the blockchain. The method calls hashBlock with the data to create and validate the new block. getLastHash: The method I call to get the previous hash. We always need the previous hash to create a new block. getAllBlocks: Just returns all the blocks currently in the blockchain Great, so let's move to index.js to use our new blockchain! const blockchain = require('./blockchain') blockchain.initBlockchain() blockchain.addNewBlock('First new block') blockchain.addNewBlock('I love blockchains') blockchain.addNewBlock('Make me a new hash!!') console.log(blockchain.getAllBlocks()) We initialize our blockchain, then we create three new blocks. When I run this, I get the following chain in response: Initializing the blockchain 139355 30720 68789 51486 [ '0000d87875f12e8c00d60cdfc8c21c4867eb1e732d3bb0e4d60bd0febcfafbaf', '0000331d80f4e83461bad846e082baa08c5e739edfa19a4880c1dcbe4eed1984', '00000dcab247410050e357158edc20555cc0110429023fdadb1d8cda3e06da5e', '0000a16968811cf75c33d877e99f460d396c46b5485f669c8e55b193b862106d' ] The array represent the four blocks. As you can see, every single one of them starts with four zeros, so every single hash is valid. If one of those hashes didn't start with four zeros, I would know right away the hash was invalid, therefore, the data in the corresponding block should probably not be trusted. There are four numbers here: 139355, 30720, 68789, 51486. These are the nonce for each block. I printed them out to see how many times the function hashBlock ran to come to a valid hash. The first block, the genesis block, ran 139355 times before having a valid hash! The second, 30720 times. The third 68789 times and the fourth 51486 times. Conclusion This is a very simple example of a blockchain. I'm pretty sure I missed a few things here. I also kept things pretty simple because hey, I'm learning! This little project made me understand a few things: If one person decides to modify a previous block, she would have to change every single block after that one. Each block inherits from its parent ( previous hash ), so trying to cheat a blockchain seems complicated. But if a majority of the blockchain's users decide to cheat, they could modify a previous block and all agree to change the rest of the blockchain accordingly. A blockchain seems to work only if the majority decides to follow the rules. Or you could end up with two different blockchains, one where the users decided to stick with the original data, and the other where the users decided to use the modified blockchain. I've heard about the Bitcoin enormous use of power where it came to mining. Mining is the concept of solving the difficulty problem when you encrypt the data. You get the transaction and you try to find a valid hash for that block. As a reward for your effort, you get some bitcoin. I can only imagine the amount of power you would use when the blockchain becomes huge. Well, that's about what I got from that. It made things a lot clearer for me. Feel free to correct me if i got things wrong! Sursa: https://dev.to/damcosset/trying-to-understand-blockchain-by-making-one-ce4
  16. 5 points
  17. 5 points
  18. 5 points
    Peste 100 de site-uri românești minează criptomonede cu ajutorul tău! Antena 3 avea un script prin intermediul căruia vizitatorii minau criptomonede fără voia sau cunoștința lor, am întocmit o listă cu alte site-uri românești care fac bani folosind procesoarele utilizatorilor. Lista site-urilor românești care au codul care a fost prezent și pe live.antena3.ro (înlăturat ulterior) a fost compilată cu ajutorul lui Ștefan Tănase, Principal Security Researcher la Ixia, dar și cu ajutorul uneltei publicWWW. Merită menționat faptul că nu știm în care dintre cazuri codul a fost implementat cu știința proprietarilor de site. Site-ul aeroportului Craiova (aeroportcraiova.ro) are un script activ care se folosește de CoinHive pentru a mina criptomonede. Odată accesat, site-ul blochează practic computerul, folosind procesorul la capacitate maximă. CYD (cyd.ro), Frip (frip.ro) și Extra News (extranews.ro) sunt trei site-uri cu știri de autenticitate îndoielnică (ca să nu zicem din prima că sunt site-uri de fake news). Și acestea folosesc un script java pentru a genera monede virtuale pentru proprietari sau pentru persoana care a injectat scriptul fără voia acestora. Jocuri Kizi (jocuri-kizi.ro) este un site cu jocuri Flash (platformă extrem de vulnerabilă în general) care are un script de cryptojacking. Aici merită menționat că cei de la CoinHive și-au creat codul (care este folosit pentru a mina Monero) gândindu-se și la platformele de jocuri online, administratorii având posibilitatea de a le oferi utilizatorilor o parte din profituri, fie sub formă de avantaje în jocuri, fie chiar sub formă de bani. În politica de cookies a site-ului Jocuri Kizi nu apare nicio mențiune privind vreun script de minat, deci sigur utilizatorii nu au niciun avantaj. Filme Seriale Online (filmeserialeonline.org), un site care are conținut video piratat, este și el monetizat prin cryptojacking. ”Site-urile de filme și seriale au aproape toate astfel de cod. De când a fost folosit un script similar pe The Pirate Bay, s-au inspirat și ei”, a declarat Ștefan Tănase. Lista site-urilor o găsiți la finalul articolului, cu mențiunea că va fi actualizată pe măsură ce scanarea se va finaliza. Cum blochezi cryptojacking-ul? În 2018, sunt metode ușoare prin care blochezi posibilitatea unui site de a face cryptojacking fără știința ta. Iată pașii: Dacă simți că procesorul tău trage din greu, că ventilatorul calculatorului sau laptopului se aude foarte tare, înseamnă că ceva consumă foarte multă capacitate de procesare. E timpul să verifici. Pe Windows acest lucru se face prin Task Manager - Processes. Dacă ai un proces care consumă foarte mult din procesor, de obicei în Chrome, încearcă mai întâi să închizi Chrome, să restartezi calculatorul, să pornești din nou site-urile active și să vezi ce se întâmplă. Testează fiecare site în parte. Pe Mac te duci la Activity Monitor pentru a vedea. Zilele trecute am descoperit că un coleg mina din greșeală pentru un site. Procesorul avea un proces care consuma 110% din capacitate. Dacă vrei să blochezi înainte de a se întâmpla orice tentativă de minare prin CoinHive sau alte softuri poți instala extensia de Google Chrome numită NoCoin care blochează scriptul de la CoinHive. Altă extensie utilă de Google Chrome este minerBlock. Aceste extensii îți arată și dacă site-ul vizitat are mineri în cod. Dacă folosești browserul Opera (recomandarea mea personală, e browserul folosit de mine) are NoCoin integrat standard, fără să mai fie nevoie să rulezi o extensie. Lista site-urilor românești care fac cryptojacking La prima scanare, software-ul dezvoltat de Ștefan Tănase a identificat 107 site-uri. Expertul în securitate a menționat că lista încă nu este una exhaustivă, deoarece programul scris de el pentru a analiza site-urile nu a accesat și site-uri care nu pot fi apelate fără ”www.” în fața numelui domeniului și nici nu a căutat în profunzime, deci s-ar putea să existe site-uri mai mari cu scriptul mai bine ascuns. Tănase spune că următoarele versiuni vor căuta mai profund, iar noi vom actualiza această listă. 3dex.ro 520.ro abrevierile.ro aeroportcraiova.ro airparking.ro alinahelgiu.ro amudom.ro anunturi-vinatoare.ro aroganta.ro ascon.ro autoleder.ro badas.ro bazsar.ro blame.ro blme.ro bodyandbijoux.ro bonarte.ro bravustuning.ro caracriscosmed.ro cazarecovasna.ro cefacem.ro centralplace.ro cheribijou.ro cielovenezia1270.ro cityneamt.ro ciuhandu.ro clandestino.ro claudiuhelgiu.ro coderevolution.ro comanda-pizza.ro contabilitate-timis.ro costinestionline.ro cscshop.ro cyd.ro dimiangroup.ro doctordepiele.ro e-qual-see.ro estfalia.ro eventuspharma.ro expressdiet.ro extranews.ro femeiaputernica.ro folderjobs.ro forumorl.ro frip.ro galileonunti.ro gieuromag.ro glass4u.ro i-ferma.ro imobiliareterenuricasa.ro inchirieriospatari.ro ituniversity.ro japanautomoto.ro jocuri-kizi.ro kowax.ro krumar.ro krumaritime.ro ladyworld.ro lagrandevie.ro laparfum.ro mandezmembrari.ro mariailiescu.ro mercal.ro mobilasik.ro mufmuf.ro muntelemiconline.ro mutvitcu.ro newfeeria.ro nextworld2.ro oardobrogea.ro optimbike.ro panterraoverland.ro pasalternativ.ro pctelnet.ro pensiunea-mai.ro piratefm.ro pixwords.ro predict.ro premiulasistentului.ro primariapietroasele.ro (Primăria orașului Pietroasele, județul Buzău) pronuntasibiu.ro radio-pirat.ro realitateafaracenzura.ro romarketing.ro romportal.ro sbigl.ro scrieri.ro sieuvreau.ro sistemesanitare.ro spitalulmarghita.ro (Spitalul Municipal Dr. Pop Mircea Marghita, județul Bihor) srbbm-banat.ro (Romanian Society of Biochemistry and Molecular Biology – Banat Branch) sudokumeu.ro sunon.ro tandemparapanta.ro techlounge.ro telefericalpin.ro tgz.ro thecouncil.ro topmovies.ro uni-dongle.ro valahiatours.ro valeasadului.ro vanzari-auto-turisme.ro ventilatoare-industriale.ro viespar.ro xnn.ro Sursa: https://start-up.ro/toate-site-urile-romanesti-care-mineaza-criptomonede-cu-ajutorul-tau/ Articol: Octavian Palade + bonus Script use: https://github.com/cazala/react-coin-hive
  19. 5 points
    Ne certam ca boii de la guvernare, bem o bere, ragaim, dam o basina si ne bagam la somn. A mai trecut o zi din viata si ne-am duelat in argumente de cacat. Pasarile calde sunt in tarile calatoare. Noapte buna! 🐐💨💩
  20. 5 points
    Quality, not quantity... La rahat trag toate mustele. E vorba de timp in si de reward (satisfactie personala cand vezi ca altii invata, legaturi, colaborare si invatare impreuna, etc.). Spre exemplu daca ar fi apetit serios (din mai multe puncte de vedere) as putea aduce speakeri straini sa prezinte pe diferite teme in webinare dar s-a mai incercat si din cate am inteles nu s-a prea meritat. Cu alte cuvinte balansul dintre viata personala (munca, hobby, fun, social, etc) si giving back / the spirit of sharing.
  21. 5 points
    In this series of blog posts, I’ll explain how I decrypted the encrypted PDFs shared by John August (John wanted to know how easy it is to crack encrypted PDFs, and started a challenge). Here is how I decrypted the “easy” PDF (encryption_test). From John’s blog post, I know the password is random and short. So first, let’s check out how the PDF is encrypted. pdfid.py confirms the PDF is encrypted (name /Encrypt): pdf-parser.py can tell us more: The encryption info is in object 26: From this I can conclude that the standard encryption filter was used. This encryption method uses a 40-bit key (usually indicated by a dictionary entry: /Length 40, but this is missing here). PDFs can be encrypted for confidentiality (requiring a so-called user password /U) or for DRM (using a so-called owner password /O). PDFs encrypted with a user password can only be opened by providing this password. PDFs encrypted with a owner password can be opened without providing a password, but some restrictions will apply (for example, printing could be disabled). QPDF can be used to determine if the PDF is protected with a user password or an owner password: This output (invalid password) tells us the PDF document is encrypted with a user password. I’ve written some blog posts about decrypting PDFs, but because we need to perform a brute-force attack here (it’s a short random password), this time I’m going to use hashcat to crack the password. First we need to extract the hash to crack from the PDF. I’m using pdf2john.py to do this. Remark that John the Ripper (Jumbo version) is now using pdf2john.pl (a Perl program), because there were some issues with the Python program (pdf2john.py). For example, it would not properly generate a hash for 40-bit keys when the /Length name was not specified (like is the case here). However, I use a patched version of pdf2john.py that properly handles default 40-bit keys. Here’s how we extract the hash: This format is suitable for John the Ripper, but not for hashcat. For hashcat, just the hash is needed (field 2), and no other fields. Let’s extract field 2 (you can use awk instead of csv-cut.py): I’m storing the output in file “encryption_test – CONFIDENTIAL.hash”. And now we can finally use hashcat. This is the command I’m using: hashcat-4.0.0\hashcat64.exe --potfile-path=encryption_test.pot -m 10400 -a 3 -i "encryption_test - CONFIDENTIAL.hash" ?a?a?a?a?a?a I’m using the following options: –potfile-path=encryption_test.pot : I prefer using a dedicated pot file, but this is optional -m 10400 : this hash mode is suitable to crack the password used for 40-bit PDF encryption -a 3 : I perform a brute force attack (since it’s a random password) ?a?a?a?a?a?a : I’m providing a mask for 6 alphanumeric characters (I want to brute-force passwords up to 6 alphanumeric characters, I’m assuming when John mentions a short password, it’s not longer than 6 characters) -i : this incremental option makes that the set of generated password is not only 6 characters long, but also 1, 2, 3, 4 and 5 characters long And here is the result: The recovered password is 1806. We can confirm this with QPDF: Conclusion: PDFs protected with a 4 character user password using 40-bit encryption can be cracked in a couple of seconds using free, open-source tools. FYI, I used the following GPU: GeForce GTX 980M, 2048/8192 MB allocatable, 12MCU Update: this is the complete blog post series: Cracking Encrypted PDFs – Part 1: cracking the password of a PDF and decrypting it (what you are reading now) Cracking Encrypted PDFs – Part 2: cracking the encryption key of a PDF Cracking Encrypted PDFs – Part 3: decrypting a PDF with its encryption key Cracking Encrypted PDFs – Conclusion: don’t use 40-bit keys Sursa: https://blog.didierstevens.com/2017/12/26/cracking-encrypted-pdfs-part-1/
  22. 5 points
  23. 4 points
    MDB Pro 4.4.3 https://www.dropbox.com/s/ru5ku6cdmvkurjt/MDB-Pro.zip?dl=0 Enjoy
  24. 4 points
    https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/ Kernel page-table isolation (KPTI, previously called KAISER) is a hardening technique in the Linux kernel to improve security by better isolating user space and kernel space memory. KPTI was merged into Linux kernel version 4.15, to be released in early 2018, and backported into Linux Kernel 4.14.10. Windows implemented an identical feature in version 17035 (RS4). Prior to KPTI, whenever executing user space code (applications), Linux would also keep its entire kernel memory mapped in page table. https://www.youtube.com/watch?time_continue=1792&v=ewe3-mUku94 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5925 https://www.reddit.com/r/Amd/comments/7nqwoe/apparently_amds_request_to_be_excluded_from_the/ The effects are still being benchmarked, however we're looking at a ballpark figure of five to 30 per cent slow down, depending on the task and the processor model. More recent Intel chips have features – such as PCID – to reduce the performance hit.
  25. 4 points
    @Silviu, ca tot esti implicat, cateva observatii rapide: - ganditi-va rapid la alt nume, acum cat e mai usor de schimbat, inainte sa va treziti cu un proces in brate de la webdollar.com - activi din 1997, mai ales pentru ca se ocupa cu tranzactii financiare (domeniu activitate similar). Chiar daca par dormanti /inactivi, nu sunt. (in plus, wbd/wdb [usor de confundat] in engleza sunt acronime pentru "water-bottle dick" / "well-deserved boner" ) - opriti treaba cu "mining-ul" automat, altfel riscati un puhoi de procese de la folosirea neautorizata (vezi cum este "consent" definit in GDPR din Mai 2018) a unui pc, pana la furt de curent, uzura/arsura procesor, brower crash = loss of data, s.a.m.d. Rezultatul lor poate varia de la ineficienta si timp pierdut pana la sume destul de costisitoare, mai ales daca se formeaza un class action rapid. - daca tot mergeti la media cu treaba asta macar asigurati-va de o anumita calitate a ceea ce expuneti, eventual platiti pentru expunere de calitate. Dupa cum vezi mai sus, articole de rahat scrise de tot felul de aiuriti nu aduc prea multa imagine pozitiva. Iar avand treburi gen "libertatea" si "evz" in subsol iarasi nu ajuta imaginii. Te asociezi cu ratati.. vrei-nu vrei, arati ca si ei. Revin cu edit dupa ce citesc whitepaper-ul.
  26. This post cannot be displayed because it is in a forum which requires at least 10 posts to view.
  27. 4 points
    Tehnologia informatiei Manual pentru class a IX-a Informatica - Tehnologii asistate de calculator de Mariana Milosescu (Teora) Sisteme de calcul Sisteme de operare Birotica - Word, Excel, Paint Multimedia si Internet Link download: https://www.plustransfer.com/download.php?id=8a8014e3e5297e932d0284d0a91dc829
  28. 4 points
    Si apoi mai faceti thread-uri de genul in pula mea.
  29. 4 points
    A fost in trecut dar a fost fara succes. Userii, chiar daca sustin inital ca participa si sunt de acord cu ideea, in aproximativ 1-2 saptamani se lasa de treaba. Ca sa faci materiale pentru a invata pe cineva un subiect, ai nevoie de foarte mult timp. A pornit Python3 cu o initiativa de cursuri live prin text si video care a fost inchisa din lipsa de interes. Am pornit eu o initiativa in trecut cu un pool cu cateva carti pe care sa le studiem si saptamanal sa facem un thread cu intrebari, probleme, explicatii la ca am invatat in capitolul respectiv. Rezultatul a fost acelasi, inchis din lipsa de interes din partea utilizatorilor. Nu o sa stea nimeni cateva ore pe zi/saptamana sa faca si sa prezinte materiale in mod gratuit si doar de dragul a 5 useri.
  30. 4 points
    Fara awareness, vulnerabilitatile de genu' acesta nu vor fi niciodata rezolvate. Si e mai bine sa stie toata lumea de ele, inclusiv cei vulnerabili, decat sa stie de vulnerabilitate doar grupuri restranse de oameni. Grupurile astea (nu dau nume, dar ma refer si la prescurtari din 3-4 litere) ar folosi vulerabilitatile pentru propriul interes, iar restul ar avea un fals sentiment de siguranta...
  31. 4 points
    Slideurile si videourile de la DefCamp 2017 sunt up: https://def.camp/archives/2017/ Have fun!
  32. 4 points
    Primul program facut in "domeniul" machine learning. Sunt niste cerculete care evolueaza sa treaca peste un obstacol si sa ajunga la un target. Link Video link
  33. 4 points
    Cateva sugestii, majoritatea PEP8 related: - constantele ar trebui sa fie UPPERCASEd: (e.g: targetRadius ar trebui redenumit ca TARGET_RADIUS) - ar trebui sa lasi doua linii noi intre functiile din afara unei clase sau intre functii si clase Asta: .. particleColor = sf.Color(255, 255, 255, 50) def distance(x1, y1, x2, y2): """ Calculate the distance from 2 points. (X1, Y1) and (X2, Y2) Formula: ( (X1-X2)**2 + (Y1-Y2)**2 )**1/2 """ return math.sqrt((x1 - x2)**2 + (y1 - y2)**2) class DNA(): ... Ar trebui sa arate asa: .. particleColor = sf.Color(255, 255, 255, 50) def distance(x1, y1, x2, y2): """ Calculate the distance from 2 points. (X1, Y1) and (X2, Y2) Formula: ( (X1-X2)**2 + (Y1-Y2)**2 )**1/2. """ return math.sqrt((x1 - x2)**2 + (y1 - y2)**2) class DNA(): ... - denumirea variabilelor tre' sa fie snake_cased (la fel si numele metodelor): e.g: def applyForce -> def apply_force etc - cand iterezi printr-o lista, si ai nevoie si de index si de valoare, e recomandat sa faci asa: lista_mea = ['malai', 'faina', 'pui', 'clatite'] for i, value in enumerate(lista_mea): print(i, value) """ output: (0, 'malai') (1, 'faina') (2, 'pui') (3, 'clatite') """ - cand creezi o clasa care nu are nici-un argument poti renunta la paranteze: class DNA() -> class DNA: - urmatoarea functie: def crossover(self, partner): """ Take the genes from 2 parents and create 1 offspring """ newDNA = [] # Pick one random point from the genes randomPoint = random.randint(0, len(self.genes)) for x in range(len(self.genes)): if x < randomPoint: newDNA.append(self.genes[x]) else: newDNA.append(partner.genes[x]) return DNA(newDNA) Poate fi rescrisa cu recomandarea de mai sus si folosind list comprehensions astfel: def crossover(self, partner): """ Take the genes from 2 parents and create 1 offspring. """ random_point = random.randint(0, len(self.genes)) new_dna = [ value if i < random_point else partner.genes[i] for i, value in enumerate(self.genes) ] return DNA(new_dna) Probabil ca se pot face mai multe schimbari insa nu am timp sa ma uit peste tot codu'. Felicitari oricum pentru efort si keep it goin'
  34. This post cannot be displayed because it is in a forum which requires at least 10 posts to view.
  35. 4 points
    S-a trezit feministul din tine fixat pe ideea ca oamenii de aici nu sunt capabili sa constientizeze ca mai exista si femei care se pricep in domeniul asta, iar acum incerci sa stresezi ideea asta prin comentarii passive aggressive, desi, logic, nimeni intelege la ce te referi, ca e evident ca nu asta era problema, ci faptul ca e o pitipoanca. Pur si simplu mentalitatea de pitipoanca si cea de infractor informatic nu au loc in aceeasi persoana, si chiar daca se intampla, probabil se intampla foarte rar si de-aia e intrigant subiectul. Data viitoare, cand mai ai un argument de prezentat, incepe cu el, nu-l preceda cu doua replici passive aggressive din care nu intelege nimeni nimic.
  36. 4 points
  37. 4 points
    Today we are going to discuss how to Detect NMAP scan using Snort but before moving ahead kindly read our privious both articles releted to Snort Installation (Manually or using apt-respiratory)and its rule configuration to enable it as IDS for your network. Basically in this article we are testing Snort against NMAP various scan which will help network security analyst to setup snort rule in such a way so that they become aware of any kind of NMAP scanning. Requirement Attacker: Kali Linux (NMAP Scan) Target: Ubuntu (Snort as IDS) Optional: Wireshark (we have added it in our tutorial so that we can clearly confirm all incoming and outgoing packet of network) Let’s Begins!! Identify NMAP Ping Scan As we know any attacker will start attack by identifying host status by sending ICMP packet using ping scan. Therefore be smart and add a rule in snort which will analyst NMAP Ping scan when someone try to scan your network for identifying live host of network. Execute given below command in ubuntu’s terminal to open snort local rule file in text editor. sudo gedit /etc/snort/rules/local.rules Now add given below line which will capture the incoming traffic coming on 192.168.1.105(ubuntu IP) network for ICMP protocol. alert icmp any any -> 192.168.1.105 any (msg: “NMAP ping sweep Scan “; dsize:0;sid:10000004; rev: 1;) Turn on IDS mode of snort by executing given below command in terminal: sudo snort -A console -q -u snort -g snort -c /etc/snort/snort.conf -i eth0 Now using attacking machine execute given below command to identify status of target maching i.e. host is UP or Down. nmap -sP 192.168.1.105 –disable-arp-ping If you will execute above command without parameter “disable arp-ping” then will work as default ping sweep scan which will send arp packets inspite of sending ICMP on targets network and may be snort not able to capture NMAP Ping scan in that sinario, therefore we had use parameter “disable arp-ping” in above command. As I had declaimed above why we are involving wireshark in this tutorial so that you can clearly see the packet sends form attacker network to targets network. Hence in given below image you can notice ICMP request packet as well as ICMP reply packets both are part of network traffic. Come back to over your target machine where snort is capturing all in coming traffic here your will observe that it is generating alert for NMAP Ping Sweep scan. Hence you can block attacker’s IP to protect your network from further scanning. Identify NMAP TCP Scan Now in order to connect with target network, attacker may go with networking enumeration either using TCP Protocol or UDP protocol. Let assume attacker may choose TCP scanning for network enumeration then in that situation we can apply following rule in snort local rule file. alert tcp any any -> 192.168.1.105 22 (msg: “NMAP TCP Scan”; sid:10000005; rev:2; ) Above rule is only applicable for port 22 so if you want to scan any other port then replace 22 from the port you want to scan else you can also use “any” to analysis all ports. Enable NIDS mode of snort as done above. Now again using attacker machine execute the given below command for TCP scan on port 22. nmap -sT -p22 192.168.1.105 From given below image you can observe wireshark has captured TCP packets from 192.168.1.104 to 192.168.1.105 Here you can confirm that our snort is absolutely working when attacker is scanning port 22 using nmap TCP scan and it is showing attacker’s IP from where traffic is coming on port 22. Hence you can block this IP to protect your network from further scanning. Identify NMAP XMAS Scan As we know that TCP communication follows three way handshake to established TCP connection with target machine but sometimes instead of using SYN, SYN/ACK,ACK flag attacker choose XMAS scan to connect with target by sending data packets through Fin, PSH & URG flags. Let assume attacker may choose XMAS scanning for network enumeration then in that situation we can apply following rule in snort local rule file. alert tcp any any -> 192.168.1.105 22 (msg:”Nmap XMAS Tree Scan”; flags:FPU; sid:1000006; rev:1;) Again above rule is only applicable for port 22 which will listen for incoming traffic when packets come from Fin, PSH & URG flags .So if you want to scan any other port then replace 22 from the port you want to scan else you can also use “any” to analysis all ports. Enable NIDS mode of snort as done above. Now again using attacker machine execute the given below command for XMAS scan on port 22. nmap -sX -p22 192.168.1.105 From given below image you can observe that wireshark is showing 2 packets from attacker machine to target machine has been send using FIN, PSH, URG flags. Come back to over your target machine where snort is capturing all in coming traffic here your will observe that it is generating alert for NMAP XMAP scan. Hence you can block attacker’s IP to protect your network from further scanning. Identify NMAP FIN Scan Instead of using SYN, SYN/ACK and ACK flag to established TCP connection with target machine may attacker choose FIN scan to connect with target by sending data packets through Fin flags only. Let assume attacker may choose FIN scanning for network enumeration then in that situation we can apply following rule in snort local rule file. alert tcp any any -> 192.168.1.1045 22 (msg:”Nmap FIN Scan”; flags:F; sid:1000008; rev:1;) Again above rule is only applicable for port 22 which will listen for incoming traffic when packets come from Fin Flags. So if you want to scan any other port then replace 22 from the port you want to scan else you can also use “any” to analysis all ports. Enable NIDS mode of snort as done above. Now again using attacker machine execute the given below command for FIN scan on port 22. nmap -sF -p22 192.168.1.105 From given below image you can observe that wireshark is showing 2 packets from attacker machine to target machine has been send using FIN flags. Come back to over your target machine where snort is capturing all in coming traffic here your will observe that it is generating alert for NMAP FIN scan. Hence you can block attacker’s IP to protect your network from further scanning. Identify NMAP NULL Scan Instead of using SYN, SYN/ACK and ACK flag to established TCP connection with target machine may attacker choose NULL scan to connect with target by sending data packets through NONE flags only. Let assume attacker may choose NULL scanning for network enumeration then in that situation we can apply following rule in snort local rule file. alert tcp any any -> 192.168.1.105 22 (msg:”Nmap NULL Scan”; flags:0; sid:1000009; rev:1;) Again above rule is only applicable for port 22 which will listen for incoming traffic when packets come from NONE Flags. So if you want to scan any other port then replace 22 from the port you want to scan else you can also use “any” to analysis all ports. Enable NIDS mode of snort as done above. Now again using attacker machine execute the given below command for NULL scan on port 22. nmap -sN -p22 192.168.1.105 From given below image you can observe that wireshark is showing 2 packets from attacker machine to target machine has been send using NONE flags. Come back to over your target machine where snort is capturing all in coming traffic here your will observe that it is generating alert for NMAP Null scan. Hence you can block attacker’s IP to protect your network from further scanning. Identify NMAP UDP Scan In order to Identify open UDP port and running services attacker may chose NMAP UDP scan to establish connection with target machine for network enumeration then in that situation we can apply following rule in snort local rule file. alert UDP any any -> 192.168.1.105 any(msg:”Nmap UDPScan”; sid:1000010; rev:1;) Again above rule is applicable for every UDP port which will listen for incoming traffic when packets is coming over any UDP port, so if you want to capture traffic for any particular UDP port then replace “any” from that specific port number as done above. Enable NIDS mode of snort as done above. Now again using attacker machine execute the given below command for NULL scan on port 22. nmap -sU -p68 192.168.1.105 From given below image you can observe that wireshark is showing 2 packets from attacker machine to target machine has been send over UDP Port. Come back to over your target machine where snort is capturing all in coming traffic here your will observe that it is generating alert for NMAP UDP scan. Hence you can block attacker’s IP to protect your network from further scanning. Author: AArti Singh is a Researcher and Technical Writer at Hacking Articles an Information Security Consultant Social Media Lover and Gadgets. Contact here Source: http://www.hackingarticles.in/detect-nmap-scan-using-snort/
  38. 4 points
    Vreau sa urmez Craciun Fericit tuturor membrilor de aici. Sa aveti sanatate si noroc in proiecte, investitii si cu ce va mai ocupati voi. Multumesc tuturor membrilor ce m-au ajutat si care au stat de mine sa ma invete cate ceva.
  39. 4 points
  40. 3 points
    https://crypto.stanford.edu/cs155/syllabus.html
  41. 3 points
    While this setup of Kali on Windows is not optimal due to various environmental restrictions (such as the lack of raw sockets and lack of customised Kali kernel), there are still many situations where having Kali Linux alongside your Windows 10 machine can be beneficial. One example that comes to mind is consolidation of workspaces, especially if Windows is your main working environment. Other useful situations that crossed our minds were standardizing tools and scripts to run across multiple environments, quick porting of Linux penetration testing command line tools to Windows, etc. For example, below is a screenshot of running the Metasploit Framework from Kali Linux, over WSL. Link: https://www.kali.org/tutorials/kali-on-the-windows-subsystem-for-linux/
  42. 3 points
    TL;DR; Researchers warn of a new attack which can be carried out in less than 30 seconds and potentially affects millions of laptops globally. As Intel was rushing to roll out patches for Meltdown and Spectre vulnerabilities, security researchers have discovered a new critical security flaw in Intel hardware that could allow hackers to access corporate laptops remotely. Finnish cyber security firm F-Secure reported unsafe and misleading default behaviour within Intel Active Management Technology (AMT) that could allow an attacker to bypass login processes and take complete control over a user's device in less than 30 seconds. Link: https://thehackernews.com/2018/01/intel-amt-vulnerability.html Pe o nota personala, greu inceput de an pentru Intel. Multe "molii" iesite de la naftalina.
  43. 3 points
    Problema nu este asta...problema este ca au ramai pe forum numai aia de se cred cei mai destepti.Si sunt atat de destepti incat nu pot accepta nimic in afara de ideile si parerile lor.Iar peste ei sunt cei din staff care probabil din cauza unor probleme psihice sau sociale fac pe Dumnezeii pe aici.Din moment ce nu exista ratiune si putina intelegere nu ai cum sa construiesti ceva.Cand apare cate unul care nu are habar de o chestie sau cere ceva, este huduit si injurat in loc sa i se explice problema frumos.Si probleme sunt multe...
  44. 3 points
    Spectre Example Code: https://gist.githubusercontent.com/ErikAugust/724d4a969fb2c6ae1bbd7b2a9e3d4bb6/raw/41bf9bd0e7577fe3d7b822bbae1fec2e818dcdd6/spectre.c #define CACHE_HIT_THRESHOLD(80) - Pentru a nu avea erori puneti un spatiu intre THRESHOLD si (80)
  45. 3 points
  46. 3 points
    In my last post I discussed the basic implementation of Blockchain in Swift language. In this post I will take the Blockchain implementation to the cloud using server side Swift framework, Vapor. We will build the Blockchain Web API over the HTTP protocols, providing necessary functionality using different routes. This post assumes that you have installed Vapor framework on your computer and have basic knowledge of Swift Language. Implementing Models The first step is to create necessary models for the Blockchain Web API. These models will consist of the following. Block: A block class represents a single block which can contain inputs and outputs represented by transactions. class Block : Codable { var index :Int = 0 var dateCreated :String var previousHash :String! var hash :String! var nonce :Int var message :String = "" private (set) var transactions :[Transaction] = [Transaction]() var key :String { get { let transactionsData = try! JSONEncoder().encode(self.transactions) let transactionsJSONString = String(data: transactionsData, encoding: .utf8) return String(self.index) + self.dateCreated + self.previousHash + transactionsJSONString! + String(self.nonce) } } func addTransaction(transaction :Transaction) { self.transactions.append(transaction) } init() { self.dateCreated = Date().toString() self.nonce = 0 self.message = "Mined a New Block" } init(transaction :Transaction) { self.dateCreated = Date().toString() self.nonce = 0 self.addTransaction(transaction: transaction) } } The properties of Block class are explained below: index — The position of block in the blockchain. Index of 0 means that the block is the first block in the blockchain. Index of 1 means it is the second block in the blockchain.. you get the idea right! dateCreated — The date when the block was created previousHash — The hash value of the previous block hash — The current hash of the block message — Memo attached to each block. This is just for our purposes nonce — Auto incremented number which plays an important role for mining the hash transactions — An array of transactions. Each transaction represents a transfer of goods/value key — This is a computed property which is passed to the hashed function Transaction: Transaction consists of the sender, recipient and the amount being transferred. The implementation is shown below: class Transaction :Codable { var from :String var to :String var amount :Double init(from :String, to :String, amount :Double) { self.from = from self.to = to self.amount = amount } init?(request :Request) { guard let from = request.data["from"]?.string, let to = request.data["to"]?.string, let amount = request.data["amount"]?.double else { return nil } self.from = from self.to = to self.amount = amount } } The Transaction class is self explanatory. It consists of from, to and amount fields. For the sake of simplicity we will be using dummy names for from and to fields, in reality these fields will consist of wallet ID. Blockchain: Blockchain is the main class which represents a list of blocks. Each block points back to the previous block in the chain. Each block can contain multiple transactions, representing the credit or debit. class Blockchain : Codable { var blocks :[Block] = [Block]() init() { } init(_ genesisBlock :Block) { self.addBlock(genesisBlock) } func addBlock(_ block :Block) { if self.blocks.isEmpty { // add the genesis block // no previous has was found for the first block block.previousHash = "0" } else { let previousBlock = getPreviousBlock() block.previousHash = previousBlock.hash block.index = self.blocks.count } block.hash = generateHash(for: block) self.blocks.append(block) block.message = "Block added to the Blockchain" } private func getPreviousBlock() -> Block { return self.blocks[self.blocks.count - 1] } private func displayBlock(_ block :Block) { print("------ Block \(block.index) ---------") print("Date Created : \(block.dateCreated) ") //print("Data : \(block.data) ") print("Nonce : \(block.nonce) ") print("Previous Hash : \(block.previousHash!) ") print("Hash : \(block.hash!) ") } private func generateHash(for block: Block) -> String { var hash = block.key.sha256()! // setting the proof of work. // In "00" is good to start since "0000" will take forever and Playground will eventually crash :) while(!hash.hasPrefix(DIFFICULTY)) { block.nonce += 1 hash = block.key.sha256()! print(hash) } return hash } } Each model adheres to the Codable protocol which allows it to easily convert to JSON represented object. If you have followed the last article then the implementation above is very similar. Next step is to configure routes for our Web API, this is implemented in the new section using the Vapor framework. Implementing Web API Using Vapor There are several different ways of implementing the Web API using Vapor. Instead of adding all the code in the Routes class, I proceeded by adding a custom controller which will handle all Blockchain requests. The implementation of BlockchainController is shown below: class BlockchainController { private (set) var drop :Droplet private (set) var blockchainService :BlockchainService! init(drop :Droplet) { self.drop = drop self.blockchainService = BlockchainService() // setup the routes for the controller setupRoutes() } private func setupRoutes() { self.drop.get("mine") { request in let block = Block() self.blockchainService.addBlock(block) return try JSONEncoder().encode(block) } // adding a new transaction self.drop.post("transaction") { request in if let transaction = Transaction(request: request) { // add the transaction to the block // get the last mined block let block = self.blockchainService.getLastBlock() block.addTransaction(transaction: transaction) //let block = Block(transaction: transaction) //self.blockchainService.addBlock(block) return try JSONEncoder().encode(block) } return try JSONEncoder().encode(["message":"Something bad happend!"]) } // get the chain self.drop.get("blockchain") { request in if let blockchain = self.blockchainService.getBlockchain() { return try JSONEncoder().encode(blockchain) } return try! JSONEncoder().encode(["message":"Blockchain is not initialized. Please mine a block"]) } } } We will start by three basic endpoints for the Web API. Mining: This endpoint will initiate the mining proess. Mining will allow us to satisfy the proof of work and add the block to the Blockchain. Transaction: This endpoint is used to add a new transaction. The transaction will contain information about sender, receiver and the amount. Blockchain: This endpoint returns the complete blockchain. The BlockchainController uses the BlockChainService to perform the required operations. The implementation of BlockChainService is shown below: // // BlockchainService.swift // Run // // Created by Mohammad Azam on 12/25/17. // import Foundation import Vapor class BlockchainService { typealias JSONDictionary = [String:String] private var blockchain :Blockchain = Blockchain() init() { } func addBlock(_ block :Block) { self.blockchain.addBlock(block) } func registerNode(_ blockchainNode :BlockchainNode) { self.blockchain.addNode(blockchainNode) } func getLastBlock() -> Block { return self.blockchain.blocks.last! } func getBlockchain() -> Blockchain? { return self.blockchain } } Let’s go ahead and check out out Web API end points. Start the Vapor server and send a request to “mine” end point. Mining a New Block The proof of work algorithm generates a hash value starting with “000”. Once, the block has been mined we return it by converting it into JSON format. This is performed by using the Swift 4.0 Codable Protocols. Now, we can add our transaction to the blockchain. Here is a simple transaction which transfers $10 from Alex to Mary. New Transaction The final step is to check out our blockchain with the newly added block. Visit the endpoint “blockchain” to view the complete chain. Blockchain Hooray! Our Blockchain Web API is now working correctly. Unfortunately, the whole point of blockchain is to be decentralized and currently, we don’t have any mechanism to add new nodes. In the next section we are going to update our blockchain implementation so it can support multiple nodes. Adding Nodes to Blockchain Before allows the blockchain to add new nodes, we must define what a node looks like. The implementation of a node model is shown below: class BlockchainNode :Codable { var address :String init(address :String) { self.address = address } init?(request :Request) { guard let address = request.data["address"]?.string else { return nil } self.address = address } } The BlockChainNode class simply consists of an address property which represents the URL of the node server. We update the BlockchainController to add the ability to register new nodes. This is shown below: self.drop.post("nodes/register") { request in guard let blockchainNode = BlockchainNode(request :request) else { return try JSONEncoder().encode(["message":"Error registering node"]) } self.blockchainService.registerNode(blockchainNode) return try JSONEncoder().encode(blockchainNode) } The BlockchainService also gets updated to accommodate registering of the new nodes. func getNodes() -> [BlockchainNode] { return self.blockchain.nodes } func registerNode(_ blockchainNode :BlockchainNode) { self.blockchain.addNode(blockchainNode) } Let’s go ahead and test it out. Start the new Vapor server and try to register new nodes. Register a New Node Once, the node(s) has been registered, you can fetch it using the nodes end point as shown below: Fetching All Nodes Now, that we can register new nodes we should focus on resolving the conflicts between the nodes. A conflict happens when the blockchain on one node gets larger as compared to the other nodes. In this scenario, we always takes the neighboring nodes and updates them with the larger blockchain. Resolving Conflicts Between Nodes In order to create a conflict we need to run a second server or run the server on a separate port. We are going to use the later approach and start the Vapor server on a different port. Once, the two nodes are initiated, we will create transactions on both nodes which will add blocks to the blockchain. Finally, we will call a resolve end point which will resolve the conflicts between nodes and update the node to the larger blockchain. The BlockchainController has been updated to add a new end point for resolving conflicts. self.drop.get("nodes/resolve") { request in return try Response.async { portal in self.blockchainService.resolve { blockchain in let blockchain = try! JSONEncoder().encode(blockchain) portal.close(with: blockchain.makeResponse()) } } } We have used the async response feature of Vapor framework which will allow us to process the response asyncronously. The BlockchainService has also been updated to support the conflict resolution. The implementation is shown below: func resolve(completion :@escaping (Blockchain) -> ()) { // get the nodes let nodes = self.blockchain.nodes for node in nodes { let url = URL(string :"http://\(node.address)/blockchain")! URLSession.shared.dataTask(with: url) { data, _, _ in if let data = data { let blockchain = try! JSONDecoder().decode(Blockchain.self, from: data) if self.blockchain.blocks.count > blockchain.blocks.count { completion(self.blockchain) } else { self.blockchain.blocks = blockchain.blocks completion(blockchain) } } }.resume() } } The resolve function goes through a list of nodes and fetches the blockchain of each node. If the blockchain is larger than the current blockchain then it replaces the blockchain with the larger one, otherwise it returns the current blockchain which is also the larger one. In order to test it out let’s start two servers on separate port and add two transactions on port 8080 and three on 8090. You can start a Vapor server using terminal by issuing the following command. vapor run serve -— port=8090 We added three transactions on port 8080 node as shown below: Blockchain on Port 8080 After that we added two transactions on port 8090 node as shown below: Blockchain on Port 8090 Make sure to register the node with the 8090 address as shown below: Registering a Node Finally, it is time to test our resolve conflict end point. Invoke the “resolve” end point by visiting it in your Postman as shown below: Resolve End Point Returning Larger Blockchain As you can see the resolve end point returns the larger blockchain and also updates the blockchain for the other nodes. This completes our conflict resolution scenario. [Github] This post is based on an amazing post by Daniel Van Flymen “Learn Blockchains by Building One”. I hope you like the post. I am currently in the process of making a Udemy course on “Blockchain Programming in iOS”. You can subscribe here to get notified when the course is released. If you want to support my writing and donate then please visit my courses page and buy my amazing courses on Udemy. Thanks and happy programming! Source: https://hackernoon.com/building-blockchain-web-api-using-swift-and-vapor-2daf599c8449
  47. 3 points
    Hard forks? Soft forks? ICOs? Bombarded by no shortage of unfamiliar technical terms in 2017, consumers in the blockchain sector once again proved a ripe target for hackers and criminals. But, not all hacks and scams were created equal. Some rose above the froth – either due to their size or impact – as well as what they said about the state of blockchain technology and the industry itself. Still, the impacts of these incidents were far from academic. Whether it was a simple wallet hack, fraudulent ICO or a bug in a piece of software code, investors lost millions, with nearly $490 million taken in the incidents below. So far, none of the perpetrators of these crimes has been caught or even identified, and it's questionable whether most of these funds can be found or returned. 1. CoinDash ICO Hack Payment and shipment startup CoinDash launched an initial coin offering (ICO) campaign early this summer, but it quickly had to pump the brakes after its ethereum address was compromised. The startup raised $7.3 million before a hacker changed the address, causing donations to go to an unknown party. The company shut down the ICO, but promised to send its native token award, CDT, to those who attempted to donate. While the company stated that donations sent after it had released its statement would not be honored, some investors continued to show support by donating to the hacked address, inadvertently raising the amount of stolen funds from $7 million to $10 million at the time. All in all, the incident showcases the growing pains experienced by ICOs, which despite raising massive amounts of funds, still had to navigate the complexities of an early-stage technology. 2. Parity Wallet Breach It was a tough year for cryptocurrency wallet provider Parity, which has the rare distinction of being cited twice on our year-end list. Issues began in July when the U.K.-based startup discovered a vulnerability in version 1.5 of its wallet software, resulting in at least 150,000 ethers being stolen from user accounts. The bug was found in its multi-signature wallets, compromising several companies’ ICO fundraisers. At the time, the ethers were worth roughly $30 million, but they're worth closer to $105 million as of mid-December. The issue was deemed "critical," with the company's CTO, Gavin Wood, announcing at least three compromised addresses and saying efforts were being made to prevent further loss of funds. It was later found that more than 70,000 ethers were already cashed out or otherwise redeemed in some way, ensuring that their loss was permanent. 3. Enigma Project Scam Back in ICO-land, issues weren't limited to compromised addresses. Blockchain startup Enigma saw its website, mailing lists and an administrator account on its Slack channel compromised when fraudsters launched a fake token pre-sale in August, defrauding potential investors of more than 1,500 ethers. The hijacked accounts promised a large return on investment, and masquerading as the genuine operators of the project, those behind the effort were able to convince unsuspecting consumers to donate to the compromised website. While the team behind Enigma was able to recover control of the company’s accounts, the ether wallet used by the hacker was emptied, and the funds were not recovered. 4. Parity Wallet Freeze Perhaps the year's biggest security incident, this entry on the list is also distinguished by being one the few to take place without the apparent aid of a malicious party. Occurring suddenly this November, a Parity user accidentally found a bug in the software code, freezing more than $275 million in ether in the wallet’s second major incident of 2017. One of two widely used clients for ethereum, the miscue effectively called into question what was and is a central infrastructure component of the network, prompting some to doubt the company's offerings and renewing criticisms of ethereum itself. In subsequent updates, developers have pushed to restore the funds, though it's now believed that doing so would require all ethereum users to upgrade their software. 5. Tether Token Hack In another incident notable for its unresolved controversies, more than $30 million was stolen from the U.S. dollar-pegged cryptocurrency Tether in late November. At the time, Tether claimed that roughly $31 million’ worth of tokens were taken from their virtual treasury and sent to an unknown bitcoin address. Not a significant number in the cryptocurrency economy, the hack was more relevant as it effectively renewed long-standing criticisms of Tether the company, prompting scrutiny in the form of blog posts and mainstream news exposes. The company later moved to blacklist the tokens stolen through an update to the Omni protocol, the blockchain on which it is based. Still, Tether continues to be dogged by allegations the incident played no small part in stirring up. 6. Bitcoin Gold Scam Think forks were confusing? So did scammers, and those seeking to cash out new tokens awarded in blockchain splits often proved all too easy to target. Shortly after the launch of a bitcoin fork called bitcoin gold, for example, some bitcoin users had their cryptocurrency wallets drained after using a service seemingly endorsed by the project's development team. Marketed as a way to authenticate whether a user was eligible for bitcoin gold funds (effectively free money for bitcoin owners), the website’s operators instead stole more than $3 million in bitcoin, bitcoin gold, ethereum and litecoin. Bitcoin gold’s development team claimed no formal relationship with the website’s developer, arguing he reached out offering to build a wallet checking service and offering to make his code open-source. The site’s developer initially claimed the site was hacked, but later wiped his GitHub and ceased responding to users on the fork’s Slack channel. Overall, though, it was another case of consumers falling into traps over promises of free funds. 7. NiceHash Market Breach That's not to say that long-standing companies were spared by the year's attacks. This was the case when cryptocurrency mining marketplace NiceHash, a well-known marketplace for mining power, reported being hacked early in December, later confirming that about 4,700 in bitcoin was stolen. At the time, that was worth approximately $78 million. It was later revealed an employee’s computer was compromised, allowing the perpetrator to gain access to the marketplace’s systems and remove bitcoin from the company’s accounts. NiceHash CEO Marko Kobal later announced that his team was trying to determine how the hack occurred, but that it would take time to establish what happened. Disclosure: CoinDesk is a subsidiary of Digital Currency Group, which has an ownership stake in Enigma. Various images courtesy Shutterstock Via coindesk.com
  48. 3 points
  49. 3 points
    In 2015, artist Ai Weiwei was bugged in his home, presumably by government actors. This situation raised our awareness on the lack of research in our community about operating and detecting spying microphones. Our biggest concern was that most of the knowledge came from fictional movies. Therefore, we performed a deep study on the state-of-the-art of microphone bugs, their characteristics, features and pitfalls. It included real life experiments trying to bug ourselves and trying to detect the hidden mics. Given the lack of open detection tools, we developed a free software SDR-based program, called Salamandra, to detect and locate hidden microphones in a room. After more than 120 experiments we concluded that placing mics correctly and listening is not an easy task, but it has a huge payoff when it works. Also, most mics can be detected easily with the correct tools (with some exceptions on GSM mics). In our experiments the average time to locate the mics in a room was 15 minutes. Locating mics is the novel feature of Salamandra, which is released to the public with this work. We hope that our study raises awareness on the possibility of being bugged by a powerful actor and the countermeasure tools available for our protection. Video: https://media.ccc.de/v/34c3-8735-spy_vs_spy_a_modern_study_of_microphone_bugs_operation_and_detection#video&t=0
  50. 3 points
    Toate pisatele de tari suportate, mai putin Romania. Sa le dau muie. Si lor, si Spotify-ului.
×