Nytro

Hackers Jailed for £26.9 Million Credit Card Fraud Cei vechi, care stiti de h4cky0u, cititi... By: Bianca Dima | comment : | June 07, 2012 Two “one-stop shop” hackers were sentenced in the UK for credit card fraud totalling more than £26.9 million. According to Serious Organised Crime Agency officers, the actual loss is likely to be a lot more. The two cyber criminals provided various services to bank fraudsters and were sentenced to almost 3, and, respectively, 2 years in prison. Under the moniker of ‘t0pp8uzz’, Jay Moore set up the ‘Freshshop’ website to facilitate the bulk sale of stolen financial data. He recruited Damian Horne, known as ‘GM’, on an underground forum. The two men started breaking the law by selling stolen iTunes vouchers and other online gaming codes on eBay. “Within a short space of time the two escalated their criminal enterprise to sell compromised credit card data and launder the proceeds of their criminality through a network of bank accounts, online financial institutions and overseas money exchangers,” SOCA representatives said in a press release. Though he had no formal qualifications, Moore used his IT knowledge to hack into computers and obtain payment card databases. He then made them available through his website, designed to look and operate like a common retail site. The hacker also made money out of commissions he received from other fraudsters who sold compromised data on his website. Last year, in a raid at his parents’ house, Police found a safe with over £80,700 in cash, a fresh out of the assembly line BMW car and personalized registration plate which alone was valued at over £10,000. “Such was Moore’s wealth that he also provided some £40,000 to help his father buy a substantial farm house, and attributed his earnings to a fake web design business created purely to hide his criminal activity,” Police said. In the attacks, more than 340,000 people had their personal information stolen. In addition to the £26.9 million fraud, the data breach could lead to fake bank accounts and to cheque or identity fraud. Sursa: Hackers Jailed for £26.9 Million Credit Card Fraud | HOTforSecurity

Probabil eu, daca o sa dau de PingLord, daca am cu ce. Teoretic am, dar nu sunt 100% sigur.

[h=3]Source IP address selection on a Multi-Homed Windows Computer[/h]MichaelPlatts [msft] 24 Apr 2009 4:59 PM Aka "Cum se selecteaza IP/NIC" cand se trimite un pachet in retea. There is often confusion about how a computer chooses which adapter to use when sending traffic. This blog describes the process by which a network adapter is chosen for an outbound connection on a multiple-homed computer, and how a local source IP address is chosen for that connection. [h=3]What is Source IP address selection?[/h] Source IP address selection is the process by which the stack chooses an IP address. Windows XP and Windows Server 2003 are based on the weak host model. When a Windows Sockets program binds to a socket, one of the parameters that is passed in the bind() call is the local (source) IP address that should be used for outbound packets. Most programs do not have any knowledge of network topology, so they specify IPADDR_ANY instead of a specific IP address in their bind() call. IPADDR_ANY tells the stack that the program is going to let the stack choose the best local IP address to use; [h=4]Windows XP behavior[/h] KB175396 - Windows Socket Connection from a Multiple-Homed Computer The TCP/IP component of all Microsoft Windows operating systems prior to Windows Vista is based on a Weak Host model. This model gives program developers the greatest amount of leeway when they design programs that use the network and are compatible with Microsoft products. This model also puts the responsibility of the behavior of the networking program on the developers, because the developers specify how the program accesses the TCP/IP stack and responds to incoming and outgoing frames. On a computer that has one network adapter, the IP address that is chosen is the Primary IP address of the network adaptor in the computer. However, on a multiple-homed computer, the stack must first make a choice. The stack cannot make an intelligent choice until it knows the target IP address for the connection. When the program sends a connect() call to a target IP address, or sends a send() call to a UDP datagram, the stack references the target IP address, and then examines the IP route table so that it can choose the best network adapter over which to send the packet. After this network adapter has been chosen, the stack reads the Primary IP address associated with that network adapter and uses that IP address as the source IP address for the outbound packets. Example: Source supplied in the call: IPADDR_ANY Target IP:192.168.1.5 Route Table: Nic 1 - 192.168.1.10/32 Nic 1 - 192.168.1.11/32 Nic 2 - 10.0.0.10/32 Nic 2 - 10.0.0.11/32 The chosen source IP:192.168.1.10 The chosen source NIC: Nic 1 If the program specifies a source IP address to use in the bind() call, that IP address is used as the source IP address for connections sourced from that socket. However, the route table is still used to route the outbound IP datagrams, based on the target IP address. As a result of this behavior, the source IP address may not be the one associated with the network adapter that is chosen to send the packets. Example: Source supplied in the call:10.0.0.10 Target IP:192.168.1.5 Route Table: Nic 1 - 192.168.1.10/32 Nic 1 - 192.168.1.11/32 Nic 2 - 10.0.0.10/32 Nic 2 - 10.0.0.11/32 The chosen source IP:10.0.0.10 The chosen source Nic: Nic 1 <- Note this is not the Nic the source IP is on. [h=3]Summary[/h] If a source IP is not given the Primary IP address of the adapter with a route that most closely matches the target IP address is used to source the packet and the adapter that the Primary IP is associated with is used as the source adapter. If the source IP is specified the adapter that is used to send the packet is the one with a route that most closely matches the target IP address and this may not be the adapter that is associated with the source IP. [h=4]Windows Vista/Windows Server 2008 behavior[/h] Windows Vista and later are based on the strong host model. In the strong host model, the host can only send packets on an interface if the interface is assigned the source IP address of the packet being sent. Also the concept of a primary IP address does not exist. Similar to XP when if a program doesn't specify a source IP, the stack references the target IP address, and then examines the entire IP route table so that it can choose the best network adapter over which to send the packet. After the network adapter has been chosen, the stack uses the address selection process defined in RFC 3484 and uses that IP address as the source IP address for the outbound packets. Example: Source supplied in the call: IPADDR_ANY Target IP:192.168.1.5 Route Table: Nic 1 - 192.168.2.10/32 Nic 1 - 192.168.1.11/32 Nic 2 - 10.0.0.10/32 Nic 2 - 10.0.0.11/32 The chosen source IP:192.168.1.11 The chosen source NIC: Nic 1 If the program specifies a source IP address, that IP address is used as the source IP address for connections sourced from that socket and the adapter associated with that source IP is used as the source interface. The route table is searched but only for routes that can be reached from that source interface. Example: Source supplied in the call:10.0.0.10 Target IP:192.168.1.5 Route Table: Nic 1 - 192.168.1.10/32 Nic 1 - 192.168.1.11/32 Nic 2 - 10.0.0.10/32 Nic 2 - 10.0.0.11/32 The chosen source IP:10.0.0.10 The chosen source Nic: Nic 2 <- Note this is the Nic the source IP is on. Note: the packet would be sent to the default gateway associated with Nic 2. [h=4]RFC 3484 and Source IP address selection[/h] The last thing I want to talk about is RFC 3484. Even though RFC 3484 says it only applies to IPV6 in Windows implementations IPV4 does follow the same rules when possible. Windows Source IP V4 address selection: Rule 1 Prefer same address (applies) Rule 2 Prefer appropriate scope (applies) Rule 3 Avoid deprecated addresses (applies) Rule 4 - Prefer home addresses - does not apply to IP v4 Rule 5 Prefer outgoing Interfaces (applies) Rule 6 Prefer matching label - does not apply to IP v4 Rule 7 Prefer public addresses - does not apply to IP v4 Rule 8a: Use longest matching prefix with the next hop IP address. (not in RFC!) "If CommonPrefixLen(SA, D) > CommonPrefixLen(SB, D), then prefer SA. Similarly, if CommonPrefixLen(SB, D) > CommonPrefixLen(SA, D), then prefer SB. " This says that the IP with the most high order bits that match the destination of the next hop will be used. Note: Rule 8 - Use longest matching Prefix is similar to rule 8a except the match is with the destination IP address rather than the next hop IP address. For example, consider the following addresses: Client machine IP Address 192.168.1.14 /24 192.168.1.68 /24 Default Gateway 192.168.1.127 The server will use the 192.168.1.68 address because it has the longest matching prefix. To see this more clearly, consider the IP addresses in binary: 11000000 10101000 00000001 00001110 = 192.168.1.14 (Bits matching the gateway = 25) 11000000 10101000 00000001 01000100 = 192.168.1.68 (Bits matching the gateway = 26) 11000000 10101000 00000001 01111111 = 192.168.1.127 The 192.168.1.68 address has more matching high order bits with the gateway address 192.168.1.127. Therefore, it is used for off-link communication. [h=3]SkipAsSource[/h] There is a new twist in the source IP selection process. Note: There are two variants of the below mentioned hotfix; one for Windows Vista / Windows Server 2008 and one for Windows 7 / Windows Server 2008 R2. 975808 All IP addresses are registered on the DNS servers when the IP addresses are assigned to one network adapter on a computer that is running Windows Server 2008 SP2 or Windows Vista SP2 2386184 IP addresses are still registered on the DNS servers even if the IP addresses are not used for outgoing traffic on a computer that is running Windows 7 or Windows Server 2008 R2 After you install the hotfix discussed above, you can create IP version 4 (IPv4) addresses or IP version 6 (IPv6) addresses by using the netsh command together with the new "skipassource" flag. By using this flag, the added new addresses are not used for outgoing packets unless explicitly set for use by outgoing packets. Note: This command only works when adding an address you can’t apply it to an address already on the machine. You would need to remove it and add it again. [h=3]Additional Information[/h] Default Address Selection for Internet Protocol version 6 (IPv6) For more information about Strong and Weak Host Models, see the following Cable Guy article: The Cable Guy: Strong and Weak Host Models The gethostbyname function has been deprecated. We recommend that you use the getaddrinfo function instead. However, we still cannot guarantee that primary IP address will be returned first. For more information about the gethostbyname function, visit the following Microsoft Web site: gethostbyname function (Windows) For more information about the getaddrinfo function, visit the following Microsoft Web site: http://msdn2.microsoft.com/en-us/library/ms738520(VS.85).aspx - David Pracht Sursa: Source IP address selection on a Multi-Homed Windows Computer - Microsoft Enterprise Networking Team - Site Home - TechNet Blogs

Windows 7.

Linux system debugging super tutorial Updated: June 1, 2012 In the last two years, I have introduced you to a number of so-called super-duper system administration tools. We learned how to properly analyze a range of problems by carefully studying symptoms and then isolating and fixing the root cause. We learned about strace and lsof, both immensely powerful tools. We focused on system profiling and auditing. We also worshiped the omnipotent GNU Debugger (gdb). Now it is time to combine the powers of all these into one mega tutorial. Today, we will use all of these tools, plus the slew of tips and tricks listed in my hacking guides, all three of them, to try to resolve a seemingly impossible problem. We will attack the issue from several angles, each time using a different tool, each time exposing a new facet of the phenomenon until we resolve it like champs. This is not going to be easy, but it will probably be the best, most comprehensive and most unique all-purpose system administration debugging guide you have read in a long while, if not ever. Did I say ever? [h=2]The problem we have[/h] All right, let's assume that the startup of applications is slow. You wait 5-10 seconds for application windows to launch. Sometimes it works fast, but you're not really sure why. Usually, the problems occur after you log out of your session or following a reboot. The most annoying thing is that if you try to fire up those same programs with sudo or as root, there are no startup delays and all seems to run fine. So how do you debug a problem like this one? [h=2]Rules![/h] If you want to be an awesome system debugger, then there are several would-be rules you must follow whenever you are trying to resolve a difficult problem. If it's something trivial you can fix in two minutes, fine, but if this is a brand new issue that has stumped you and your colleagues for more than an hour, then you should pause, rethink and be methodical about it. [h=3]Be methodical[/h] Having a formulaic approach may portray you as a noob - or a very efficient man. You choose. You should have a strategy that is uniform, generic and all-encompassing for every problem that may come up. This means that you will be able to handle the situation whether you're fixing airplanes or hacking the kernel. [h=3]Always begin with simple tools[/h] In theory, you can try to fix any problem with gdb right away, but that's not a smart use of either the tools at hand or your intellect and time. You should always begin with simple things. Check the system logs for weird errors. Check top to assess the basic system health. Make sure you're not out of memory. Examine the disk and CPU load. [h=3]Comparison to a healthy system[/h] This may not always be applicable, but if you have a machine with an identical hardware and software configuration that does not exhibit the same problems, or two workload scenarios that produce different results, then you should compare between them to try to find what might be causing the bad system or the component to misbehave. This may not always be easy, but component search is the most powerful tool in statistical engineering and it applies well for mechanical parts as well as software. Now, we're ready to dig in. [h=2]Symptoms[/h] Our healthy system fires up xclock, our sample graphical tool, in less than a second. The bad system does the same, except it takes 10 times longer. So we know something is slowed down but not necessarily broken. [h=2]Strace[/h] At this stage, running strace seems like a good idea. Rather than tracing every system call through endless logs, we will only do the summary run, specified with -c flag. We want to see if there's anything significant in the tool's run. [h=3]Strace log, good system[/h] Let's see what strace gives us: [h=3]Strace log, bad system[/h] The same thing for the misbehaving case: [h=3]Strace comparison[/h] I've placed the two summaries side by side. The font may be a little small, but it's identical to what you've see above. We can see that there's a significant difference in the behavior of the two cases. On the good system, the top four system calls are read, mprotect, open, and fstat. We get system calls in the range of several tens to several hundreds, with some errors, probably stemming from seeking files in the $PATH. Another important element is the execution time, which takes ~1-2 milliseconds for each of the four system calls. On the bad system, the top hitters are open, munmap, mmap, and stat. Moreover, we have system calls in the range of thousands, approx. 10-20x times more than previously. We also have a huge number of open errors. The execution time is in the range of 8-12 miliseconds, which is approx. 10 times longer than before. So we know something is wrong, but we don't know what exactly. [h=2]Ltrace[/h] We will now use ltrace and perhaps discover something else. System calls shows a marked difference in the behavior, but we do not know what is causing the problem. Maybe we will be able to determine the issue by looking at libraries, which is exactly what ltrace does. Again, we will execute the tool with -c flag, to see the summary. [h=3]Ltrace log, good system[/h] A whole new plate of information. The most significant library function is the creation of the xclock widget, which takes 20 milliseconds and almost 40% of the total execution time. Second on the list is the XftFontOpenName. [h=3]Ltrace log, bad system[/h] Here, we see something else. The XftFontOpenName is the leading function with a total of 18 seconds of execution time. Then, we have the creation of the widget, with no less impressive 16 seconds. After that, nothing else matters. [h=3]Ltrace comparison[/h] We can clearly see that there's something wrong with fonts, it seems. On the good system, the relevant library call took a fraction of the same, while on the bad system, it lasted almost 20 seconds. Now, if we cross-reference the strace logs with these two, we start to get a clearer picture. The long duration of the function responsible for creating the widget definitely explain the slowness we experience. Moreover, it aligns nicely with the huge number of system calls and errors on the bad system. We now have a clue. [h=2]Additional analysis - with vmstat[/h] Some people could decide they already have enough information - something seems to be wrong with fonts. But let's say you are still not 100% convinced and you want to learn more. Let's try using vmstat. [h=3]Good system[/h] vmstat provides useful information on the memory and CPU usage. We have discussed the tool in the past, so I will not be repeating myself. Today, the fields of interests are CPU metrics in the last five columns, specifically the two labeled us and sy, as well as the cs and in fields under system. The us and sy labels indicate the percentage of CPU usage by user and system, respectively. The cs and in labels refers to context switches and interrupts. The first metric tells us roughly how often the running process had to relinquish its place in the runqueue in favor of another waiting process. In other words, there was a context switch from one process to another. Interrupts indicates the number of times the running process had to access the underlying hardware, for example access the disk to read data from the filesystem, poll the screen or the keyboard, etc. Let's see what happens when we launch the xclock program. Ignore the first line, as it display the average values since the last uptime. We can see that there's a brief spike of user CPU, also reflected in the high number of interrupts and context switches. xclock is launched by the time the fourth line is displayed. [h=3]Bad system[/h] Here, the situation is a little different. We can see a significant increase in user CPU for almost 5-7 seconds. However, there's less context switches than before and many more interrupts. What does this mean? We can see that the launching of xclock, which is an interactive application and should be therefore treated as an interactive process, is behaving like a computational (batch) process. For interactive processes, we want as much responsiveness as possible, which means lots of context switches and little CPU activity so that we get dynamic priority from the scheduler and spend as little time thinking, giving control to the user. However, in our case, the process does fewer context switches than before and uses a lot more CPU, which is typical behavior for batch processes. This means there's some thinking going on. What is happening is that our system is reading fonts and creating the cache while we're waiting for xclock. This also explains the increase in IO activity and some wa CPU values, as we have to do this operation against the local filesystem. Now, it is important to emphasize that this kind of analysis is meaningless if you do not know how your process is supposed to behave and what it's supposed to do. However, if you have an inkling of an idea, then even a boring list of numbers as output by vmstat could provide you with a wealth of information. [h=2]Problem resolution[/h] I believe we have sufficient information to solve this. Something is wrong with fonts. The fact applications take so long to start probably indicates the font cache is being rebuilt every time, which in turn indicates the programs started by user cannot read the system font cache. This would also explain why sudo and root are not affected. Now, I know I'm being smart in retrospect, after this problem was identified and debugged and the tutorial written at leisure with cocky style and smartness. But the thing is, all the pieces are there. The application is slow. Strace logs indicate open errors. We could now run a full strace session and learn the exact paths of these errors. We would use -e flag against open system call, to reduce verbosity, and we would increase the string length using -s flag so we could see all of the information about failing paths. We would learn about fonts not being readable by the user. But we do not need to do that. We cross-reference our information with ltrace, which points out the problem to be in the opening of fonts. This library call blocks the creation of the widget, which is why the applications appear to be slow in launching. vmstat runs provide additional information, which help narrow down the issue further. And if we check the system font cache, located under /var/cache/fontconfig, we learn that fonts are created with 600 permissions, i.e. they are only readable by root. If we change the values to 644, we resolve the problem and all our applications start quickly. We also save disk space, as we do not require each user to create its own copy of fonts in their own home directory. [h=2]lsof comes to rescue[/h] Now, I will briefly demonstrate another problem. This one is completely different from the previous example. Moreover, in this case strace and ltrace are completely useless, because the process is stuck in a D state. We do not really know what might be wrong, but all of the tools above are of no help. Enter lsof. OK, let's assume you have some Java process that is stuck and not responding. Now, Java is always ugly and comes with hideous exception traces, but we must debug the issue and the conventional tools do not provide any useful information. In fact, this is what you see with strace: futex(0x562d0be8, FUTEX_WAIT, 18119, NULL But if you check the same process with lsof, you get something like this: java 11511 user 32u ipv4 1920022313 TCP rogerbox:44332->rogerbox:22122 (SYN_SENT) Ta-dam. We can see our Java is using two IPv4 ports to communicate internally. It has sent a packet from one port to another, initiating a TCP connection. This is indicated by the SYN_SENT state, the first sequence in the three-point TCP handshake. For some reason, the server, listening on port 22122, is not responding. At this stage, you may want to check why the packet is not being rejected or accepted by the server. Do we have a routing problem? On a local machine, this probably does not apply, but maybe the destination is somewhere else? Do we have a firewall problem? Can you connect to the relevant machine and port using telnet? At this point, you still do not have all the tools to fix the issue, but you are fully aware of what is causing Java to misbehave. For all practical purposes, the problem is solved. [h=2]Conclusion[/h] I told you you will like this tutorial, and if you do not, then I have utterly failed you as a human being. But I think this article has it all - rational thinking, methodical approach to problem solving, multi-dimensional use of system debugging tools to create a clear picture of the issue, including comparing system calls and library functions between a good and a bad system, use of vmstat to understand the computational behavior of processes, and more. As a bonus, we also learn about lsof usefulness for network-related stuff. From now on, your system administration will never be the same. Seemingly complex problems will become simple, if you stick to the discipline of sorting out the basic checklist first, then slowly advancing to intermediate and advance tools and methods. If you ever get stuck, you can always refer to my hacking guides, which detail some 30+ utilities and scripts that should help you in your journey into the heart of the system. Well, that would be all. More goodness coming soon. Cheers. Sursa: Linux system debugging super tutorial

IPv6 – Google

[h=1]VIDEO Romania se afla pe primul loc in lume in topul tarilor cu cea mai mare rata de adoptare a noului protocol de internet IPv6 in iunie 2012, sustine RCS&RDS[/h]de Adrian Vasilache HotNews.ro Miercuri, 6 iunie 2012, 17:51 Economie | Telecom Fiecare terminal cu care ne conectam la internet are o adresa IP (o secventa de numere), iar actualul protocol cu care functioneaza internetul, IPv4, a pus la dispozitie circa 4 miliarde de adrese, numar care este aproape de epuizare in conditiile exploziei numarului de terminale si de servicii web. Dupa ce a fost testat anul trecut, un nou protocol, IPv6, care permite alocarea unui numar aproape nelimitat de adrese, a fost lansat la nivel mondial miercuri, 6 iunie. Romania se afla pe primul loc in lume in topul tarilor cu cea mai mare rata de adoptare a IPv6, la inceputul lunii iunie din acest an (7,75%), urmata de Franta, Japonia, China si SUA, a anuntat miercuri operatorul de comunicatii prin cablu RCS&RDS. Datele au fost prezentate miercuri de Emanuel Popa, manager IP Design in cadrul RCS&RDS, la evenimentul local de lansare a IPv6, organizat de catre Internet Society Romania, ANISP si ICI. Sursa datelor o reprezinta masuratorile Google si APNIC, in perioada 1-6 iunie 2012. Citeste si: Zi istorica pentru viitorul internet-ului - Se lanseaza oficial noul protocol IPv6 La data de 3 februarie 2011, a fost o zi istorica pentru Internet. A fost ziua in care IANA (Internet Assigned Numbers Authority) a distribuit ultimul bloc de adrese IP versiunea 4 (IPv4) catre Registrele Regionale de Internet (RIR), conform Internet Society Romania. "Exista o autoritate globala care se cheama IANA care aloca resurse catre autoritatile regionale de pe fiecare continent si exista 5 autoritati regionale in Asia/Pacific, Europa, America de Nord, America de Sud si Africa. Pe 3 februarie 2011 IANA a ramas fara adrese IP. Cand au mai ramas doar 5 subneturi/8, conform politicii IANA, fiecare autoritate continentala a primit cate un subnet/8. Ulterior autoritatea din Asia/Pacific a epuizat si ea adresele IPv4 si anume in aprilie 2011. Probabil ca epuizarea adreselor IPv4 la nivelul autoritatilor regionale se va intampla probabil la nivelul anilor 2014-2015", a declarat miercuri Emanuel Popa, manager RCS&RDS. Popa, RCS&RDS: In Europa nu stam chiar atat de prost in privinta adreselor IPv4 care au mai ramas disponibile Operatorul de comunicatii prin cablu a pornit testarea IPv6 in octombrie 2011, fiind prima companie telecom locala si din regiune care a inceput implementarea acestui protocol. In acest moment, 19,57% dintre clientii de internet ai RCS&RDS prefera IPv6 in accesarea internetului, rata de adoptare a protocolului in cadrul retelei companiei fiind de 2,5 ori mai mare fata de rata de adoptare a Romaniei (7,75%) si de 28 de ori mai mare fata de media la nivel mondial (0,7%), sustine operatorul. "Am reusit ca la sfarsitul lunii aprilie sa obtinem o alocare noua din partea autoritatii din Europa (RIPE) - un subnet/14. Cat inseamna? Aproximativ 250.000 de adrese IPv4. Cam cat timp ne-ar ajunge noua acest spatiu de adresare? Sa zicem ca ne-ar asigura o crestere cu 30% a numarului de clienti. Asta inseamna foarte mult. O asftel de crestere probabil ca necesarul de IP-uri ar fi suficient pentru urmatorii 2-3 ani. (...) Adresele IPv4 sunt alocate dinamic. RIPE inca mai are libere doua blocuri de adrese 'slash 8' printre care si acela care a fost alocat de IANA la inceputul lui 2011. Deci in Europa nu stam chiar atat de prost", a spus Emanuel Popa. Cum pot fi afectati utilizatorii finali de tranzitia la IPv6? Conform Internet Society Romania, "in urmatoarele cateva luni, nu veti remarca nici o diferenta. Majoritatea sistemelor de operare suporta deja tehnologia IPv6, chiar si Mac OS X 10.2 si Windows XP SP1. Totusi, multe routere si servere web nu se pot conecta in IPv6, facand imposibila conectarea intre un terminal adresat in IPv6 si un server sau router IPv4". Organizatia sutine insa ca daca industria nu face tranzitia la IPv6, aplicatiile web vor raspunde mai greu, conexiunea intre terminale va dura mai mult si conectarea prin programe ca Skype va fi mai dificila si datele de conectare vor putea fi compromise din cauza divizarii adreselor. Sursa: VIDEO Romania se afla pe primul loc in lume in topul tarilor cu cea mai mare rata de adoptare a noului protocol de internet IPv6 in iunie 2012, sustine RCS&RDS - Telecom - HotNews.ro

Pacat... Insa imi place abordarea

TOR Virtual Network Tunneling Tool 0.2.2.36 Authored by Roger Dingledine | Site tor.eff.org Tor is a network of virtual tunnels that allows people and groups to improve their privacy and security on the Internet. It also enables software developers to create new communication tools with built-in privacy features. It provides the foundation for a range of applications that allow organizations and individuals to share information over public networks without compromising their privacy. Individuals can use it to keep remote Websites from tracking them and their family members. They can also use it to connect to resources such as news sites or instant messaging services that are blocked by their local Internet service providers (ISPs). Changes: This release updates the addresses for two of the eight directory authorities, fixes some potential anonymity and security issues, and fixes several crash bugs. Tor 0.2.1.x has reached its end-of-life. Those Tor versions have many known flaws, and nobody should be using them. You should upgrade. If you're using a Linux or BSD distribution and its packages are obsolete, stop using those packages and upgrade anyway. Download: http://packetstormsecurity.org/files/download/113352/tor-0.2.2.36.tar.gz

Phrack magazine #68 (14/04/2012) Current issue : #[URL="http://www.phrack.com/archives/tgz/phrack68.tar.gz"]68[/URL] | Release date : 14/04/2012 | Editor : The Phrack Staff [TABLE] [TR] [TD][URL="http://www.phrack.com/issues.html?issue=68&id=1#article"]Introduction[/URL][/TD] [TD][URL="http://www.phrack.com/authors.html?author=The+Phrack+Staff#author"]The Phrack Staff[/URL][/TD] [/TR] [TR] [TD][URL="http://www.phrack.com/issues.html?issue=68&id=2#article"]Phrack Prophile on FX[/URL][/TD] [TD][URL="http://www.phrack.com/authors.html?author=The+Phrack+Staff#author"]The Phrack Staff[/URL][/TD] [/TR] [TR] [TD][URL="http://www.phrack.com/issues.html?issue=68&id=3#article"]Phrack World News[/URL][/TD] [TD][URL="http://www.phrack.com/authors.html?author=TCLH#author"]TCLH[/URL][/TD] [/TR] [TR] [TD][URL="http://www.phrack.com/issues.html?issue=68&id=4#article"]Linenoise[/URL][/TD] [TD][URL="http://www.phrack.com/authors.html?author=various#author"]various[/URL][/TD] [/TR] [TR] [TD][URL="http://www.phrack.com/issues.html?issue=68&id=5#article"]Loopback[/URL][/TD] [TD][URL="http://www.phrack.com/authors.html?author=The+Phrack+Staff#author"]The Phrack Staff[/URL][/TD] [/TR] [TR] [TD][URL="http://www.phrack.com/issues.html?issue=68&id=6#article"]Android Kernel Rootkit[/URL][/TD] [TD][URL="http://www.phrack.com/authors.html?author=dong-hoon+you#author"]dong-hoon you[/URL][/TD] [/TR] [TR] [TD][URL="http://www.phrack.com/issues.html?issue=68&id=7#article"]Happy Hacking[/URL][/TD] [TD][URL="http://www.phrack.com/authors.html?author=*********+author#author"]********* author[/URL][/TD] [/TR] [TR] [TD][URL="http://www.phrack.com/issues.html?issue=68&id=8#article"]Practical cracking of white-box implementations[/URL][/TD] [TD][URL="http://www.phrack.com/authors.html?author=sysk#author"]sysk[/URL][/TD] [/TR] [TR] [TD][URL="http://www.phrack.com/issues.html?issue=68&id=9#article"]Single Process Parasite[/URL][/TD] [TD][URL="http://www.phrack.com/authors.html?author=Crossbower#author"]Crossbower[/URL][/TD] [/TR] [TR] [TD][URL="http://www.phrack.com/issues.html?issue=68&id=10#article"]Pseudomonarchia jemallocum[/URL][/TD] [TD][URL="http://www.phrack.com/authors.html?author=argp+%26+huku#author"]argp & huku[/URL][/TD] [/TR] [TR] [TD][URL="http://www.phrack.com/issues.html?issue=68&id=11#article"]Infecting loadable kernel modules: kernel versions 2.6.x/3.0.x[/URL][/TD] [TD][URL="http://www.phrack.com/authors.html?author=styx%5E#author"]styx^[/URL][/TD] [/TR] [TR] [TD][URL="http://www.phrack.com/issues.html?issue=68&id=12#article"]The Art of Exploitation: MS IIS 7.5 Remote Heap Overflow[/URL][/TD] [TD][URL="http://www.phrack.com/authors.html?author=redpantz#author"]redpantz[/URL][/TD] [/TR] [TR] [TD][URL="http://www.phrack.com/issues.html?issue=68&id=13#article"]The Art of Exploitation: Exploiting VLC, a jemalloc case study[/URL][/TD] [TD][URL="http://www.phrack.com/authors.html?author=huku+%26+argp#author"]huku & argp[/URL][/TD] [/TR] [TR] [TD][URL="http://www.phrack.com/issues.html?issue=68&id=14#article"]Secure Function Evaluation vs. Deniability in OTR and similar protocols[/URL][/TD] [TD][URL="http://www.phrack.com/authors.html?author=greg#author"]greg[/URL][/TD] [/TR] [TR] [TD][URL="http://www.phrack.com/issues.html?issue=68&id=15#article"]Similarities for Fun and Profit[/URL][/TD] [TD][URL="http://www.phrack.com/authors.html?author=Pouik+%26+G0rfi3ld#author"]Pouik & G0rfi3ld[/URL][/TD] [/TR] [TR] [TD][URL="http://www.phrack.com/issues.html?issue=68&id=16#article"]Lines in the Sand: Which Side Are You On in the Hacker Class War[/URL][/TD] [TD][URL="http://www.phrack.com/authors.html?author=*********+author#author"]********* author[/URL][/TD] [/TR] [TR] [TD][URL="http://www.phrack.com/issues.html?issue=68&id=17#article"]Abusing Netlogon to steal an Active Directory's secrets[/URL][/TD] [TD][URL="http://www.phrack.com/authors.html?author=the+p1ckp0ck3t#author"]the p1ckp0ck3t[/URL][/TD] [/TR] [TR] [TD][URL="http://www.phrack.com/issues.html?issue=68&id=18#article"]25 Years of SummerCon[/URL][/TD] [TD][URL="http://www.phrack.com/authors.html?author=Shmeck#author"]Shmeck[/URL][/TD] [/TR] [TR] [TD][URL="http://www.phrack.com/issues.html?issue=68&id=19#article"]International Scenes[/URL][/TD] [TD][URL="http://www.phrack.com/authors.html?author=various#author"]various[/URL][/TD] [/TR] [/TABLE] Sursa: .:: Phrack Magazine ::.

Dati subscribe: http://www.youtube.com/user/ChRiStIaAn008/videos

[h=1]Flame: Replication via Windows Update MITM proxy server[/h] Aleks Kaspersky Lab Expert Posted June 06, 16:43 GMT Tags: Flame, Cyber weapon, Cyber espionage, Zero-day vulnerabilities 0.2 The Flame malware uses several methods to replicate itself. The most interesting one is the use of the Microsoft Windows Update service. This is implemented in Flame’s “SNACK”, “MUNCH” and “GADGET” modules. Being parts of Flame, these modules are easily reconfigurable. The behavior of these modules is controlled by Flame’s global registry, the database that contains thousands of configuration options. SNACK: NBNS spoofing The SNACK module creates a RAW network socket for either all or pre-set network interfaces and begins receiving all network packets. It looks for NBNS packets of other machines looking for local network names. When such a packet is received, it is written to an encrypted log file (“%windir%\temp\~DEB93D.tmp”) and passed on for further processing. When a name in the NBNS request matches the expression “wpad*” or “MSHOME-F3BE293C”, it responds with its own IP address. If “SNACK.USE_ATTACK_LIST” variable is set to “True”, it also checks whether packets originate from IP addresses specified in its “SNACK.ATTACK_LIST” and responds to machines with these addresses. “Wpad” is a name used for automatic proxy detection. By responding to “wpad” name requests with its own IP address, the SNACK module announces the infected machine as a proxy server for its local network. SNACK and MUNCH also communicate with the GADGET unit that provides facilities for handling different events that come from other modules. The Flame’s registry contains LUA modules for processing events like “MUNCH_ATTACKED”, “SNACK_ENTITY.ATTACK_NOW”. MUNCH: Spoofing proxy detection and Windows Update request “MUNCH” is the name of the HTTP server module in Flame. It is started only if “MUNCH.SHOULD_RUN” variable is set to “True” and there are no running programs that can alert the victim. These programs (anti-virus, firewalls, network sniffers etc.) are defined in the Flame’s registry in a list called “SECURITY.BAD_PROGRAMS” When MUNCH is started, it reads a buffer from the “MUNCH.WPAD_DATA” variable, replaces the pattern “%%DEFAULT%%” with the IP address of its best suitable network interface and waits for HTTP requests. Contents of the “MUNCH.WPAD_DATA” variable The “MUNCH.WPAD_DATA” buffer is actually a WPAD file that is requested by network clients that implement automatic proxy server detection. The code in the WPAD file matches the MD5 hash of the hostname that the client is connecting to against its own list, and if found, offers itself as a HTTP proxy. We were able to identify some of the hashes: download.windowsupdate.com download.microsoft.com update.microsoft.com www.update.microsoft.com v5.windowsupdate.microsoft.com windowsupdate.microsoft.com www.download.windowsupdate.com v5stats.windowsupdate.microsoft.com So, when a machine configured with automatic proxy detection tries to access one of the Windows Update hosts, it receives an IP address of the infected machine from SNACK, and then receives the IP address of the same machine as a proxy server from “wpad.dat” provided by MUNCH. From then, requests to the Windows Update service are passed through the MUNCH server. When a network client connects to the MUNCH server and requests an URI other than “/wpad.dat” and “/ view.php”, the server : 1) Runs “MUNCH.SHOULD_ATTACK_SCRIPT” – Lua script that checks if the User-Agent header matches at least one of the patterns specified in “MUNCH.USER_AGENTS.CAB_PATTERN_*”. The Flame registry files that we have contained the following patterns: MUNCH.USER_AGENTS.CAB_PATTERN_4 : WinHttp%-Autoproxy%-Service.* MUNCH.USER_AGENTS.CAB_PATTERN_3 : Windows%-Update%-Agent.* MUNCH.USER_AGENTS.CAB_PATTERN_2 : Industry Update.* MUNCH.USER_AGENTS.CAB_PATTERN_1 : Microsoft SUS.* 2) Checks if the requested URI matches any pattern specified in the list of strings called “MUNCH.GENERIC_BUFFERS.*.data.PATTERN”. If one of the expressions match, it then gets the buffer specified in the corresponding “MUNCH.GENERIC_BUFFERS.*.data.FILE_DATA” value, reads the payload value called “MUNCH.GENERIC_BUFFERS_CONTENT.value_of_FILE_DATA” and sends it to the client. All the payloads are listed in the Flame’s registry with names starting with “MUNCH.GENERIC_BUFFERS_CONTENT.payload_name”, and are encoded with a fixed 104-byte RC4 key. [TABLE=class: fullbrd, width: 80%, align: center] [TR] [TD=width: 50%]URI pattern [/TD] [TD] Payload name [/TD] [/TR] [TR] [TD] *v9/windowsupdate/redir/muv4wuredir.cab* *v8/windowsupdate/redir/muv3wuredir.cab* *v7/windowsupdate/redir/wuredir.cab* *v6/windowsupdate/redir/wuredir.cab* *ws03sp1/windowsupdate/redir/wuredir.cab* [/TD] [TD] WUREDIR [/TD] [/TR] [TR] [TD] */v9/windowsupdate/?/?elf?pdate/WSUS3/x86/Other/wsus3setup.cab* */v9/windowsupdate/?/SelfUpdate/AU/x86/NetServer/*/wusetup.cab* */v9/windowsupdate/?/SelfUpdate/AU/x86/XP/*/wusetup.cab* */v9/windowsupdate/?/SelfUpdate/AU/x86/W2K/*/wusetup.cab* */v9/windowsupdate/?/SelfUpdate/AU/x86/W2KSP2/*/wusetup.cab* [/TD] [TD] WUSETUP [/TD] [/TR] [TR] [TD] *update.microsoft.com/v6/windowsupdate/selfupdate/wuident.cab* [/TD] [TD] XP_WUIDENT [/TD] [/TR] [TR] [TD] *v5/redir/wuredir.cab* [/TD] [TD] XP_WUREDIR [/TD] [/TR] [TR] [TD] *download.windowsupdate.com/v6/windowsupdate/?/SelfUpdate/ AU/x86/XP/en/wusetup.cab* [/TD] [TD] XP_WUSETUP [/TD] [/TR] [TR] [TD] *muauth.cab* [/TD] [TD] MUAUTH [/TD] [/TR] [TR] [TD] *muredir.cab* [/TD] [TD] MUREDIR [/TD] [/TR] [TR] [TD] *muident.cab* [/TD] [TD] MUIDENT [/TD] [/TR] [TR] [TD] */version_s.xml [/TD] [TD] VISTA_7_VERSION_S [/TD] [/TR] [TR] [TD] */version.xml [/TD] [TD] VISTA_7_VERSION [/TD] [/TR] [TR] [TD] *v9/windowsupdate/redir/muv4wuredir.cab* *v8/windowsupdate/redir/muv3wuredir.cab* *v7/windowsupdate/redir/wuredir.cab* *v6/windowsupdate/redir/wuredir.cab* *ws03sp1/windowsupdate/redir/wuredir.cab* [/TD] [TD] VISTA_7_WUREDIR [/TD] [/TR] [TR] [TD] */windowsupdate/?/?elf?pdate/WSUS3/x86/Vista/WuSetupHandler.cab* [/TD] [TD] VISTA_7_WUSETUPHANDLER [/TD] [/TR] [TR] [TD] */windowsupdate/?/?elf?pdate/WSUS3/x86/Vista/WUClient-SelfUpdate-ActiveX~31bf3856ad364e35~x86~~7.0.6000.381.cab* [/TD] [TD] VISTA_7_WUCLIENT [/TD] [/TR] [TR] [TD] */windowsupdate/?/?elf?pdate/WSUS3/x86/Vista/wsus3setup.cab* [/TD] [TD] VISTA_7_WSUS3SETUP [/TD] [/TR] [TR] [TD] *v9/windowsupdate/selfupdate/wuident.cab* [/TD] [TD] VISTA_7_WUIDENT [/TD] [/TR] [/TABLE] Most of the payloads are signed CAB archives. The archives that contain malicious code are signed by “MS” in Dec 2010 and Nov 2011 while other archives seem to originate from the genuine Windows Update service and are signed by “Microsoft Corporation”. [TABLE=class: fullbrd, width: 100%, align: center] [TR] [TD] Payload names [/TD] [TD] Contents [/TD] [TD] Signed [/TD] [/TR] [TR] [TD] WUREDIR VISTA_7_WUREDIR [/TD] [TD] wuredir.xml [/TD] [TD] Microsoft Corporation July 01, 2009 [/TD] [/TR] [TR] [TD] WUSETUP [/TD] [TD] Default/wuapplet2.ocx Default/wuaucom.dat Default/wuauinfo.ocx Default/wuconf.ini Default/wusetup.ocx wsus3setup.cat wsus3setup.inf wuapplet2.ocx wuaucom.dat wuauinfo.ocx wuconf.ini wups2.cab wups2.cat wusetup.cat wusetup.inf wusetup.ocx [/TD] [TD] MS November 10, 2011 [/TD] [/TR] [TR] [TD] XP_WUIDENT [/TD] [TD] wuident.txt [/TD] [TD] Microsoft Corporation May 25, 2005 [/TD] [/TR] [TR] [TD] XP_WUREDIR [/TD] [TD] wuredir.xml [/TD] [TD] Microsoft Corporation June 16, 2005 [/TD] [/TR] [TR] [TD] XP_WUSETUP [/TD] [TD] Default/ wuapplet2.ocx Default/wuaucom.dat Default/wuauinfo.ocx wups2.cab wusetup.cat wusetup.inf wusetup.ocx [/TD] [TD] MS December 28, 2010 [/TD] [/TR] [TR] [TD] MUAUTH [/TD] [TD] authorization.xml [/TD] [TD] Microsoft Corporation June 05, 2008 [/TD] [/TR] [TR] [TD] MUREDIR [/TD] [TD] wuredir.xml [/TD] [TD] "Microsoft Corporation July 01, 2009 [/TD] [/TR] [TR] [TD] MUIDENT [/TD] [TD] muident.txt [/TD] [TD] MS December 28, 2010 [/TD] [/TR] [TR] [TD] VISTA_7_VERSION_S [/TD] [TD] empty [/TD] [TD] no signature [/TD] [/TR] [TR] [TD] VISTA_7_VERSION [/TD] [TD] 92 bytes, not a CAB file [/TD] [TD] no signature [/TD] [/TR] [TR] [TD] VISTA_7_WUSETUPHANDLER [/TD] [TD] WuSetupV.exe [/TD] [TD] MS December 28, 2010 [/TD] [/TR] [TR] [TD] VISTA_7_WUCLIENT [/TD] [TD] update.cat update.mum [/TD] [TD] MS December 28, 2010 [/TD] [/TR] [TR] [TD] VISTA_7_WSUS3SETUP [/TD] [TD] WUClient-SelfUpdate- ActiveX~31bf3856ad364e35~x86~ ~7.0.6000.381.mum WuPackages.xml [/TD] [TD] MS December 28, 2010 [/TD] [/TR] [TR] [TD] VISTA_7_WUIDENT [/TD] [TD] wuident.txt [/TD] [TD] MS December 28, 2010 [/TD] [/TR] [/TABLE] Since the CAB files have valid signatures (revoked by Microsoft at the moment), the Windows Update service receives and processes them as valid updates. They are downloaded and installed, effectively executing the malicious payload. The main payload module within these CAB files is a downloader component called “Wusetup.ocx” or “WuSetupV.exe”. It collects general information about the computer, including time zone information, and tries to download “http://MSHOME-F3BE293C/view.php”, with host information appended to the request URI. Since the name “MSHOME-F3BE293C” is handled by the SNACK module, the URL points to the running MUNCH server that serves the main Flame module “mssecmgr.ocx” on this URI. WuSetupV downloads the file, saves it to “%windir%\Temp\~ZFF042.tmp” on the target machine, loads it as a DLL and invokes its export “DDEnumCallback”, which is Flame’s installation routine. The new machine then becomes infected. Better than zero-day When we first discovered Flame, we started looking in its code for at least one exploit that used a zero-day vulnerability to spread Flame and infect other machines inside the network. Given its sophistication and the fact that it infected fully patched Windows 7 machines, there should have been one. What we’ve found now is better than any zero-day exploit. It actually looks more like a “god mode” cheat code – valid code signed by a keychain originating from Microsoft. The signature was discovered and immediately revoked by Microsoft, and a security advisory with update KB2718704 was promptly published. Sursa: Flame: Replication via Windows Update MITM proxy server - Securelist

[h=3]Yes, you can have fun with downloads[/h] [h=2]May 30, 2012[/h] It is an important and little-known property of web browsers that one document can always navigate other, non-same-origin windows to arbitrary URLs; in more limited circumstances, even individual frames can be targeted. I discuss the consequences of this behavior in The Tangled Web - and several months ago, I shared this amusing proof-of-concept illustrating the perils of this logic: Beaver Peak Banking and BBQ Today, I wanted to showcase a more sneaky consequence of this design - and depending on who you ask, one that is possibly easier to prevent. What's the issue, then? Well, it's pretty funny: predictably but not very intuitively, the attacker may initiate such cross-domain navigation not only to point the targeted window to a well-formed HTML document - but also to a resource served with the Content-Disposition: attachment header. In this scenario, the address bar of the targeted window will not be updated at all - but a rogue download prompt will appear on the screen, attached to the targeted document. Here's an example of how this looks in Chrome; the fake flash11_updater.exe download supposedly served from adobe.com is, in reality, supplied by the attacker: All the top three browsers are currently vulnerable to this attack; some provide weak cues about the origin of the download, but in all cases, the prompt is attached to the wrong window - and the indicators seem completely inadequate. You can check out the demo here: http://lcamtuf.coredump.cx/fldl/ The problem also poses an interesting challenge to sites that frame gadgets, games, or advertisements from third-party sources; even HTML5 sandboxed frames permit the initiation of rogue downloads (oops!). Vendor responses, for the sake of posterity: Chrome: reported March 30 (bug 121259). Fix planned, but no specific date set. Internet Explorer: reported April 1 (case 12372gd). The vendor will not address the issue with a security patch for any current version of MSIE. Firefox: reported March 30 (bug 741050). No commitment to fix at this point. I think these responses are fine, given the sorry state of browser UI security in general; although in good conscience, I can't dismiss the problem as completely insignificant. Sursa: lcamtuf's blog: Yes, you can have fun with downloads

[h=3]Flame malware collision attack explained[/h]swiat 6 Jun 2012 8:57 AM Since our last MSRC blog post, we’ve received questions on the nature of the cryptographic attack we saw in the complex, targeted malware known as Flame. This blog summarizes what our research revealed and why we made the decision to release Security Advisory 2718704 on Sunday night PDT. In short, by default the attacker’s certificate would not work on Windows Vista or more recent versions of Windows. They had to perform a collision attack to forge a certificate that would be valid for code signing on Windows Vista or more recent versions of Windows. On systems that pre-date Windows Vista, an attack is possible without an MD5 hash collision. This certificate and all certificates from the involved certificate authorities were invalidated in Security Advisory 2718704. We continue to encourage all customers who are not installing updates automatically to do so immediately. Mysterious Missing Extensions When we first examined the Flame malware, we saw a file that had a valid digital signature that chained up to a Microsoft Root authority. As we reviewed this certificate, we noticed several irregularities. First, it had no X.509 extension fields, which was not consistent with the certificates we issued from the Terminal Server licensing infrastructure. We expected to find a Certificate Revocation List (CRL) Distribution Point (CDP) extension, an Authority Information Access (AIA) extension, and a “Microsoft Hydra” critical extension. All of these were absent. When we examined the certificate with the Windows utility certutil.exe we saw a different story emerge. > certutil.exe -dump MS.cer X509 Certificate: Version: 3 Serial Number: 1b7e Signature Algorithm: Algorithm ObjectId: 1.3.14.3.2.3 md5RSA Algorithm Parameters: 05 00 Issuer: CN=Microsoft LSRA PA DC=partners DC=extranet DC=microsoft DC=com NotBefore: 2/19/2010 2:48 PM NotAfter: 2/19/2012 2:48 PM Subject: CN=MS Public Key Algorithm: Algorithm ObjectId: 1.2.840.113549.1.1.1 RSA (RSA_SIGN) Algorithm Parameters: 05 00 Public Key Length: 2048 bits Public Key: UnusedBits = 0 0000 30 82 01 0a 02 82 01 01 00 a6 89 43 6f c6 ca 9d 0010 42 ad bd 28 d5 46 49 e0 55 f2 cc 38 e0 3d c0 7c 0020 ba 1d ca bb 92 c4 be 4c 5f 1a f9 d6 42 4b 34 0b 0030 2f 8a ac cb 97 31 ef 76 2f c3 85 af 95 93 47 46 0040 f6 ff 7c ca df c8 f9 d0 6a ec df 0e 91 55 23 ab 0050 64 06 90 d3 37 83 a8 0e 3e 5e 7f 77 35 66 74 20 0060 87 42 1f 25 17 8a d5 28 05 38 05 c8 48 6d 63 76 0070 3e fd 5a 11 67 07 09 6d 98 a3 08 4a f1 11 7f 80 0080 a7 4e 37 d4 f0 0e 34 7a d5 ba 83 ad 60 1e 57 44 0090 65 50 72 cd af 1e d0 1e 30 c2 eb 6a 51 e2 aa 54 00a0 85 57 fa 9c b1 59 e8 24 5e d4 38 d3 56 81 68 d5 00b0 05 8b 48 25 92 a2 11 1b e8 51 54 d9 d9 04 60 ee 00c0 1c fb 6a ec f0 6e 38 bb ad da 35 87 63 74 86 ef 00d0 1f cd 80 92 a2 98 3a 97 9a bd 35 d1 7d 2e 3a 47 00e0 04 48 17 74 db a3 67 d9 82 78 e0 77 2c cc ac 39 00f0 61 a6 d8 9d aa fc de 6f 60 4c 7c 73 07 31 93 2f 0100 67 28 4a 7e d1 ae 4c 42 dd 02 03 01 00 01 Issuer Unique Id: 0000 6a 4c e0 1f f5 91 69 b2 74 36 f0 7f 7b 4b 7b c6 jL....i.t6..{K{. 0010 be eb 3f 9f 98 3d a3 84 87 54 7e 72 87 71 25 4b ..?..=...T~r.q%K 0020 68 35 ae 65 bd 6c 8f dc 8d ac c4 e8 98 92 de dc h5.e.l.......... 0030 53 62 f5 72 6a 25 27 a3 12 46 eb 7f 6d 58 cd 30 Sb.rj%'..F..mX.0 0040 83 d7 7a 85 b8 48 e6 0e 01 11 68 65 7d 53 38 0b ..z..H....he}S8. 0050 40 f4 3b 68 43 59 c1 3c 05 c3 40 26 9d 51 97 e2 @.;hCY....@..Q.. 0060 eb 2e b8 c2 19 6e 4e 94 46 3b d8 d4 fd 0d 00 d1 .....nN.F;...... 0070 68 fa df f3 fa 18 8a 7c 65 9b da 23 11 9f 16 a6 h......|e..#.... 0080 8b 23 24 88 87 22 69 19 c2 11 ea 9d 36 81 ad fb .#$.."i.....6... 0090 e8 8b d2 d0 eb 06 f2 1a 86 8d c6 84 f3 88 c5 e0 ................ 00a0 d9 64 c6 48 95 d4 be d3 54 48 91 e6 6c e9 1e 33 .d.H....TH..l..3 00b0 97 15 42 ee b4 6d 1f 15 0b 27 dd 08 bb 81 de b6 ..B..m...'...... 00c0 96 16 39 d9 26 44 6a 5f d1 6b 3f 12 71 dc f0 99 ..9.&Dj_.k?.q... 00d0 62 d2 43 14 58 f8 6e f8 22 35 d2 90 f7 fd 93 6a b.C.X.n."5.....j 00e0 c4 49 b8 cb 0c e9 65 a8 f7 22 b5 f2 05 19 20 ef .I....e..".... . 00f0 25 63 c7 b3 97 4a 82 3e b2 e3 ee b4 5e cb 1d b3 %c...J.>....^... 0100 59 8f 8d f4 79 01 b1 b6 68 89 14 b4 8f 9d 60 d7 Y...y...h.....`. 0110 71 a5 3d 95 02 03 01 00 01 a3 82 02 5a 30 82 02 q.=.........Z0.. 0120 56 30 1d 06 03 55 1d 0e 04 16 04 14 9a 9a 5d 77 V0...U........]w 0130 bd 84 66 a4 f1 de 18 10 1b 6e 67 a5 97 c1 14 87 ..f......ng..... 0140 30 1f 06 03 55 1d 23 04 18 30 16 80 14 75 e8 03 0...U.#..0...u.. 0150 58 5d fb 65 e4 d9 a6 ac 17 b6 03 7e 47 ad 2e 81 X].e.......~G... 0160 af 30 81 c2 06 03 55 1d 1f 04 81 ba 30 81 b7 30 .0....U.....0..0 0170 81 b4 a0 81 b1 a0 81 ae 86 56 68 74 74 70 3a 2f .........Vhttp:/ 0180 2f 74 6b 78 70 61 73 72 76 33 36 2e 70 61 72 74 /tkxpasrv36.part 0190 6e 65 72 73 2e 65 78 74 72 61 6e 65 74 2e 6d 69 ners.extranet.mi 01a0 63 72 6f 73 6f 66 74 2e 63 6f 6d 2f 43 65 72 74 crosoft.com/Cert 01b0 45 6e 72 6f 6c 6c 2f 4d 69 63 72 6f 73 6f 66 74 Enroll/Microsoft 01c0 25 32 30 4c 53 52 41 25 32 30 50 41 2e 63 72 6c %20LSRA%20PA.crl 01d0 86 54 66 69 6c 65 3a 2f 2f 5c 5c 74 6b 78 70 61 .Tfile://\\tkxpa 01e0 73 72 76 33 36 2e 70 61 72 74 6e 65 72 73 2e 65 srv36.partners.e 01f0 78 74 72 61 6e 65 74 2e 6d 69 63 72 6f 73 6f 66 xtranet.microsof 0200 74 2e 63 6f 6d 5c 43 65 72 74 45 6e 72 6f 6c 6c t.com\CertEnroll 0210 5c 4d 69 63 72 6f 73 6f 66 74 20 4c 53 52 41 20 \Microsoft LSRA 0220 50 41 2e 63 72 6c 30 82 01 31 06 08 2b 06 01 05 PA.crl0..1..+... 0230 05 07 01 01 04 82 01 23 30 82 01 1f 30 81 8e 06 .......#0...0... 0240 08 2b 06 01 05 05 07 30 02 86 81 81 68 74 74 70 .+.....0....http 0250 3a 2f 2f 74 6b 78 70 61 73 72 76 33 36 2e 70 61 ://tkxpasrv36.pa 0260 72 74 6e 65 72 73 2e 65 78 74 72 61 6e 65 74 2e rtners.extranet. 0270 6d 69 63 72 6f 73 6f 66 74 2e 63 6f 6d 2f 43 65 microsoft.com/Ce 0280 72 74 45 6e 72 6f 6c 6c 2f 74 6b 78 70 61 73 72 rtEnroll/tkxpasr 0290 76 33 36 2e 70 61 72 74 6e 65 72 73 2e 65 78 74 v36.partners.ext 02a0 72 61 6e 65 74 2e 6d 69 63 72 6f 73 6f 66 74 2e ranet.microsoft. 02b0 63 6f 6d 5f 4d 69 63 72 6f 73 6f 66 74 25 32 30 com_Microsoft%20 02c0 4c 53 52 41 25 32 30 50 41 2e 63 72 74 30 81 8b LSRA%20PA.crt0.. 02d0 06 08 2b 06 01 05 05 07 30 02 86 7f 66 69 6c 65 ..+.....0...file 02e0 3a 2f 2f 5c 5c 74 6b 78 70 61 73 72 76 33 36 2e ://\\tkxpasrv36. 02f0 70 61 72 74 6e 65 72 73 2e 65 78 74 72 61 6e 65 partners.extrane 0300 74 2e 6d 69 63 72 6f 73 6f 66 74 2e 63 6f 6d 5c t.microsoft.com\ 0310 43 65 72 74 45 6e 72 6f 6c 6c 5c 74 6b 78 70 61 CertEnroll\tkxpa 0320 73 72 76 33 36 2e 70 61 72 74 6e 65 72 73 2e 65 srv36.partners.e 0330 78 74 72 61 6e 65 74 2e 6d 69 63 72 6f 73 6f 66 xtranet.microsof 0340 74 2e 63 6f 6d 5f 4d 69 63 72 6f 73 6f 66 74 20 t.com_Microsoft 0350 4c 53 52 41 20 50 41 2e 63 72 74 30 1a 06 08 2b LSRA PA.crt0...+ 0360 06 01 04 01 82 37 12 01 01 ff 04 0b 16 09 54 4c .....7........TL 0370 53 7e 42 41 53 49 43 S~BASIC Certificate Extensions: 0 Signature Algorithm: Algorithm ObjectId: 1.2.840.113549.1.1.4 md5RSA Algorithm Parameters: 05 00 Signature: UnusedBits=0 0000 96 b9 a2 43 a1 dd 17 48 b9 d6 ec a7 b7 71 a0 01 0010 63 0f f4 bc e7 c3 03 d3 c2 48 72 7f 85 90 b3 70 0020 17 d1 50 20 f7 8c ce aa d1 fe 68 fa 64 b3 8d 00 0030 b5 38 4a c9 0d 96 1f 6b 42 1f a9 44 05 c5 12 b1 0040 24 26 fd 19 bb 74 6f bf 16 ef 35 5c 4c d1 dd 30 0050 ac 64 3c e7 4f 10 14 49 d7 0e 20 c8 ac 36 af 01 0060 ca 80 ff 04 fb 9d 79 56 4b 8a 7b 11 4e d8 e2 97 0070 7e 1d 87 cd e5 e1 b1 3e e6 5f d0 9c 62 6d f6 8c 0080 dc ca e3 4a f2 e5 5c 29 bb 49 66 68 17 02 75 70 0090 71 7c f1 78 64 d6 ed db 85 f3 67 ee fb e8 57 50 00a0 35 94 7b 71 4d f7 b5 12 e5 bb e8 2b 40 de ec 5f 00b0 29 af bb 7e c9 0b 97 b2 d2 46 dc 77 ef f4 f5 3f 00c0 07 48 ab 25 c3 8a f3 5d e1 23 8b c9 49 7d c0 8b 00d0 c7 52 ca 5c 7f 29 4b 9b fd 5d fe 71 a1 34 50 00 00e0 10 a5 86 04 94 e8 07 b7 4b 58 05 4c 67 ca 76 ca 00f0 5a cc cf 27 d5 a4 04 a8 31 71 83 72 73 ab 4a 00 Non-root Certificate Key Id Hash(rfc-sha1): d6 11 4d 36 37 9e 6e e3 9e 9f 2f 61 88 98 f2 8d 56 38 69 c9 Key Id Hash(sha1): 38 ea d5 44 de a9 3f 76 78 43 6e 95 f0 2d 58 82 42 f6 55 dd Cert Hash(md5): ea 99 4e 63 fe 99 06 60 02 c9 9b 09 e3 50 06 2e Cert Hash(sha1): 1d 19 0f ac f0 6e 13 3e 87 54 e5 64 c7 6c 17 da 8f 56 6f bb CertUtil: -dump command completed successfully. This certificate had an unusual field—Issuer Unique Identifier. This field is obsolete and not used by Microsoft software or infrastructure. When we examined this field in detail, we realized that it did not contain random data, but rather it had structure. It contained a correctly encoded X.509V3 extension field starting at byte offset 0x119 into the Issuer Unique Identifier field. Here are some of the “missing” extensions we extracted from it: [TABLE] [TR] [TD]Offset[/TD] [TD]Field[/TD] [TD]Data[/TD] [/TR] [TR] [TD]0x161[/TD] [TD]CDP (CRL Distribution Point)[/TD] [TD]http://tkxpasrv36.partners.extranet.microsoft.com/CertEnroll/Microsoft%20LSRA%20PA.crl[/TD] [/TR] [TR] [TD]0x226[/TD] [TD]Authority Information Access[/TD] [TD] http://tkxpasrv36.partners.extranet.microsoft.com/CertEnroll/ tkxpasrv36.partners.extranet.microsoft.com_Microsoft%20LSRA%20PA.crt [/TD] [/TR] [TR] [TD]0x35b[/TD] [TD]Microsoft Hydra extension [1][/TD] [TD]Object Identifier 1.3.6.1.4.1.311.18 for value "TLS~BASIC" and is marked critical[/TD] [/TR] [/TABLE] The “Critical” Link The Microsoft Hydra extension is marked as "critical" and this is crucial to why the attacker needed to perform a collision attack. In X.509 parlance, if an extension is essential to the proper validation of a certificate chain, it must be marked critical. The behavior of a crypto library upon encountering an extension marked critical that it does not understand is to fail validation. The Crypto API in Window Vista and later versions of Windows behave this way and the certificates fail validation on those platforms. Hence, if the attacker wanted a certificate that worked on all versions of Windows they needed to remove this field. Circumstances that Collided To remove the critical extension, the attacker took advantage of a number of circumstances to perform a collision attack: An attacker took advantage of the Terminal Services licensing system‘s enrollment process for certificates that chained up to the Microsoft Root Authority which did not require internal access to Microsoft PKI. The signature algorithm on this certificate was md5RSA. The issuing certificate authority used known validity periods and certificate serial numbers that could be predicted with high probability. An essential part of performing a collision attack is that the attacker needs to be able to predict completely the certificate content that will be signed by the CA. Because of the predictable serial numbers, the attacker can perform a set of certificate enrollments that reveal the likely serial number when they perform their collision attack. This is also called a "chosen prefix collision attack" [2]. The attacker can then apply the collision algorithm documented by Sotirov et. al. [3] to create a forged certificate that removes the critical Microsoft Hydra extension and still matches the MD5 hash of the legitimate certificate signed by the CA. Quick Response to Extinguish Flame and Copycats Without this collision attack, it would have been possible to sign code that would validate on systems pre-dating Windows Vista, but that signed code would fail validation on Windows Vista and above. After this attack, the attacker had a certificate that could be used to sign code that chained up to the Microsoft Root Authority and worked on all versions of Windows. Given the risk for copycat attacks on systems pre-dating Windows Vista, without the complexity of a collision attack, we took action to release an out-of-band update. Hardening of the Terminal Server Licensing Certificate Infrastructure We also made a number of changes to the Terminal Server licensing infrastructure to minimize risk in the future: Rather than just invalidate certificates known to be used by the Flame malware, we invalidated the entire certificate authority hierarchy associated with Terminal Server licensing, both present and past. This was a broad action and was the fastest way to protect the largest number of customers. These certificates were invalidated in the update for Security Advisory 2718704. Existing Terminal Server Client Access Licenses (CALs) are not impacted and you can read more on the Terminal Server blog post. A new certificate chain was introduced that no longer chains up to the Microsoft Root Authority. It has a separate standalone root not trusted by Windows clients to minimize future risk. The certificates use SHA1 in the signatures. We have also discontinued issuing code-signing certificates for this new hierarchy. Also, its certificates are constrained with a new Enhanced Key Usage that is not used for code signing. This effectively constrains the capabilities of the certificates to just Terminal Server licensing. Microsoft takes the security of its customers seriously; therefore we took the swiftest action that would protect the largest number of customers first. We will continue to take the necessary actions to help protect our customers. Acknowledgements Thanks to John Lambert, Magnus Nystrom, David Molnar, and special thanks to Tolga Acar for their contributions to this investigation. - Jonathan Ness, MSRC Engineering References [1] Microsoft, “Object IDs associated with Microsoft cryptography”, Object IDs associated with Microsoft cryptography, March 1, 2007. [2] M. Stevens and A. Lenstra and B. de Weger. "Chosen-prefix Collisions for MD5 and Colliding X.509 Certificates for Different Identities", http://www.win.tue.nl/hashclash/EC07v2.0.pdf, Chosen-prefix Collisions, June 16, 2009. [3] A.Sotirov, M.Stevens, J.Applebaum, A.Lenstra, D.Molnar, D.A. Osvik, B. de Weger, “MD5 considered harmful today”, MD5 considered harmful today, Dec.30, 2008. Sursa: Flame malware collision attack explained - Security Research & Defense - Site Home - TechNet Blogs

[h=1]FBI Opens Investigation into Stuxnet Attack Leaks[/h]Wednesday, June 06, 2012 The Wall Street Journal reports that the Federal Bureau of Investigation is now probing the source of recently leaked information regarding covert cyber operations conducted by the U.S. government. Last week New York Times' writer David Sanger published a piece detailing the government's use of a sophisticated cyber weapon known as Stuxnet, which emerged in 2010. Stuxnet is a complex virus that infected systems which provide operations control for Iranian production networks, and was most likely produced to stifle Iran's nuclear weapons program. Stuxnet targeted Siemens Programmable Logic Controllers (PLCs) and is thought to have caused severe damage to equipment at Iranian uranium enrichment facilities, setting back the nation's weapons program by as much as several years. Stuxnet is largely considered to be a game changer in the world of information security, as the infection did not merely cause problems with the tainted systems, but actually affected kinetic damage on the equipment those systems controlled. The modular nature of the design behind Stuxnet and its data stealing cousins Duqu and Flame could mean that new variations of the viruses tailored to target critical components of other systems could already be in development. Senator John McCain of Arizona suggested that the leaks may have been intentional on the part of the White House in "an attempt to further the president's political ambitions for the sake of his re-election at the expense of our national security." White House spokesman Josh Earnest rebutted the speculation, stating "It's classified for a reason, because publicizing that information would pose a significant threat to national security." Sanger also dismissed McCain's assertion, saying "I spent a year working the story from the bottom up, and then went to the administration and told them what I had. Then they had to make some decisions about how much they wanted to talk about it…I'm sure the political side of the White House probably likes reading about the president acting with drones and cyber and so forth. National-security side has got very mixed emotions about it because these are classified programs." In late May, Secretary of State Hillary Clinton disclosed news that U.S. cyber operatives had recently hacked pro al-Qaeda propaganda websites in Yemen. The operation focused on changing violently anti-American content by injecting data related to the terrorist organization's crimes again Yemeni citizens, including death tolls. The operation was initiated by the State Department as part of a multi-agency counter-terrorism strategy aimed at disrupting al-Qaeda's online recruitment and propaganda efforts. The targets were websites controlled by the terrorist faction Yemen’s al Qaida in the Arabian Peninsula (AQAP) who has recently stepped up anti-American propaganda and online recruitment efforts. The disclosure, though not on par with the leaking of the Stuxnet attacks, was nonetheless unusual. For the most part, the Pentagon’s U.S. Cyber Command usually carries out cyber offensives, though they are rarely acknowledged publicly. Sursa: FBI Opens Investigation into Stuxnet Attack Leaks

Bun, sa vedem ce se poate face. Pe scurt, trebuie sa te conectezi pe portul 8081 (in cazul tau) prin TCP la acel host (127.0.0.1) si sa folosesti protocolul HTTP (versiunea 1.1) pentru a cere (GET) acea pagina. Pentru inceput, conteaza daca programul este pentru Windows sau pentru Linux. Pentru Windows, in primul rand, va trebui sa apelezi la inceput functia WSAStartUp() pentru initializarea Winsock (stack-ul de comunicatie Windows, unde ai nevoie de un pointer la o structura WSADATA, trimisa prin referinta, ce va contine ulterior informatii despre Winsock si de versiunea Winsock, 2.2 probabil). WSAStartup(MAKEWORD(2,2), &wsaData) Iar la final va trebui sa apelezi WSACleanup();. Imi e lene sa explic mai multe, uite ce am scris eu mai demult: /* Nume: FileDownloader v0.1 Autor: Ionut Popescu Data: 12-13 Noiembrie 2011 Descriere: Descarca un fisier de la URL-ul specificat in locatia specificata */ #include <stdio.h> #include <stdlib.h> #include <windows.h> #include <winsock2.h> #define WIN32_LEAN_AND_MEAN /* Prototipurile functiilor */ void InitWinsock(); char *GetServer(const char *url); char *GetIP(const char *server); char *BuildHTTPRequest(const char *url); int DownloadFile(const char *url, const char *filename); /* Functia descarca un fisier de la adresa specificata */ int DownloadFile(const char *url, const char *filename) { char *request = NULL, *server = NULL, *server_ip = NULL, recv_buffer[4096]; SOCKET sock; struct sockaddr_in conn; int eroare_connect = -1, rez_send = -1, rez_recv = -1, bytes = 0, first_packet = 1; /* Cream request-ul, si memoram IP-ul serverului */ request = BuildHTTPRequest(url); server = GetServer(url); server_ip = GetIP(server); sock = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP); /* Verificam crearea socketului */ if(sock == INVALID_SOCKET) { puts("Eroare, nu s-a putut crea socketul"); if(WSAGetLastError() == WSAENETDOWN) puts("- Problema cu conexiunea la internet"); exit(EXIT_FAILURE); } /* Facem "setarile" necesare si ne conectam la server */ conn.sin_family = AF_INET; conn.sin_port = htons(80); conn.sin_addr.s_addr = inet_addr(server_ip); eroare_connect = connect(sock, (struct sockaddr *)&conn, sizeof(conn)); /* Verificam daca s-a realizat conexiunea */ if(eroare_connect == SOCKET_ERROR) { puts("Eroare la conectarea la server"); eroare_connect = WSAGetLastError(); switch(eroare_connect) { case WSAENETDOWN: puts("- Problema cu conexiunea la internet"); break; case WSAEADDRNOTAVAIL: puts("- Adresa nu este valida"); break; case WSAECONNREFUSED: puts("- Conexiunea a fost refuzata"); break; case WSAENETUNREACH: puts("- Nu s-a putut realiza conexiunea la retea"); break; case WSAEHOSTUNREACH: puts("- Nu s-a putut realiza conexiunea la server"); break; case WSAETIMEDOUT: puts("- Conexiunea a esuat dupa timpul limita"); break; default: printf("- A intervenit eroarea cu codul: %d\n", eroare_connect); } closesocket(sock); exit(EXIT_FAILURE); } /* Trimitem request-ul */ rez_send = send(sock, request, strlen(request), 0); if(rez_send == SOCKET_ERROR) { puts("Eroare la trimiterea request-ului"); rez_send = WSAGetLastError(); switch(rez_send) { case WSAENETDOWN: puts("- Problema cu conexiunea la internet"); break; case WSAECONNABORTED: puts("- Conexiunea a fost terminata dupa timpul limita"); break; case WSAECONNRESET: puts("- Conexiunea a fost resetata de server"); break; case WSAETIMEDOUT: puts("- Conexiune inchisa din cauza retelei sau serverului respectiv"); break; default: printf("- A intervenit eroarea cu codul: %d\n", rez_send); } } /* Nu mai trimitem date */ shutdown(sock, SD_SEND); /* Citim raspunsul de la server */ do { bytes = recv(sock, recv_buffer, 4096, 0); if(bytes > 0) { /* Daca e primul pachet, separam datele de headerele HTTP */ if(first_packet == 1) { char *header = recv_buffer; char delim[5] = {0}; int pos_buf = 0; /* Prevenim eventuale probleme */ //if(strlen(recv_buffer) < 4) continue; sprintf(delim, "\r\n\r\n"); //while(recv_buffer[pos_buf+4] && (strncmp(&recv_buffer[pos_buf], delim, 4) != 0)) pos_buf++; printf("%s", &recv_buffer[0]); //break; first_packet = 0; } else puts(recv_buffer); break; } else if(bytes == 0) { puts(recv_buffer); } else { puts("Eroare la citirea datelor de la server"); rez_recv = WSAGetLastError(); switch(rez_recv) { case WSAENETDOWN: puts("- Problema cu conexiunea la internet"); break; case WSAECONNABORTED: puts("- Conexiunea a fost terminata dupa timpul limita"); break; case WSAECONNRESET: puts("- Conexiunea a fost resetata de server"); break; case WSAETIMEDOUT: puts("- Conexiune inchisa din cauza retelei sau serverului respectiv"); break; default: printf("- A intervenit eroarea cu codul: %d\n", eroare_connect); } } } while(bytes > 0); closesocket(sock); return 1; } /* Functia returneaza IP-ul unui server */ char* GetIP(const char *server) { struct hostent *host; struct in_addr address; host = gethostbyname(server); /* Verificam rezultatul */ if(host == NULL) { int eroare_ip = -1; puts("A intervenit o eroare la preluarea IP-ului serverului"); switch(eroare_ip = WSAGetLastError()) { case WSAHOST_NOT_FOUND: puts("- Serverul nu a fost gasit"); break; case WSANO_DATA: puts("- Nu a fost gasit niciun IP pentru server"); break; default: printf("- A intervenit eroarea cu codul: %d\n", eroare_ip); } exit(EXIT_FAILURE); } /* Verificare si conversie */ if(host->h_addr_list[0] == 0) { puts("Eroare, nu s-a gasit niciun IP pentru server"); exit(EXIT_FAILURE); } /* Convertim reprezentarea*/ address.s_addr = *(u_long*)host->h_addr_list[0]; /* address = *(struct in_addr*)(host->h_addr_list[0]); */ /* Convertim adresa la sir de caractere si o returnam */ return inet_ntoa(address); } /* Functia construieste headerele HTTP necesare, memoram serverul in al doilea parametru */ char *BuildHTTPRequest(const char *url) { const char browser[] = "Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20100101 Firefox/7.0.1"; char *request = NULL, *local_url = NULL, *host = NULL; char fileurl[1024]; /* Prevenim buffer oveflow */ if(strlen(url) > 1024) return NULL; host = GetServer(url); local_url = (char *)malloc(1024); /* Extragem si numele fisierului */ if(strncmp(url, "http://", 7) == 0) strcpy(local_url, url +7); else strcpy(local_url, url); strcpy(fileurl, local_url + strlen(host)); /* Alocam spatiu si cream headerul */ request = (char *)malloc(4096); sprintf(request, "GET %s HTTP/1.1\r\nHost: %s\r\nUser-Agent: %s\r\n\r\n", fileurl, host, browser); return request; } /* Functia returneaza serverul dintr-un URL */ char *GetServer(const char *url) { char *local_url = NULL, *host = NULL; int i = 0; /* Prevenim buffer oveflow */ if(strlen(url) >= 1024) return NULL; /* Extragem datele necesare pentru a crea headerul */ local_url = (char *)malloc(1024); if(strncmp(url, "http://", 7) == 0) strcpy(local_url, url +7); else strcpy(local_url, url); /* Copiem serverul in variabila host */ host = (char *)malloc(1024); while(local_url[i] && local_url[i] != '/') { host[i] = local_url[i]; i++; } host[i] = '\0'; return host; } /* Alocam resursele Winsock si verificam pentru potentiale erori */ void InitWinsock() { WSADATA wsaData; /* Initializare Winsock */ if(WSAStartup(MAKEWORD(2,2), &wsaData)) { int eroare_wsa = -1; puts("A intervenit o eroare la initializarea Winsock:"); switch(eroare_wsa = WSAGetLastError()) { case WSASYSNOTREADY: puts("- Problema cu conexiunea la Internet"); break; case WSAEPROCLIM : puts("- Problema cu resursele alocate de sistemul de operare"); break; default: printf("- A intervenit eroarea cu codul: %d\n\n", eroare_wsa); } exit(EXIT_FAILURE); } } /* Main-ul clasic */ int main() { InitWinsock(); DownloadFile("http://www.un.org/Depts/Cartographic/map/profile/romania.pdf", NULL); WSACleanup(); return 0; } E destul de explicat, ar trebui sa se inteleaga. Apoi, am mai scris prima parte pentru un astfel de articol: http://www.codexpert.ro/articole.php?id=33 Si azi am facut un client UDPv6, pe un anumit IPv6, daca ai nevoie de ceva informatii, intreaba-ma.

[h=4]Iphone Dns Spoofing , Arp Poisoning Redirecting Websites[/h] Description: Using Arp poisoning, All Your ARP Are Belong To Us! The ability to associate any IP address with any MAC address provides hackers with many attack vectors, including Denial of Service, Man in the Middle, and MAC Flooding. Sursa: Iphone Dns Spoofing , Arp Poisoning Redirecting Websites

[h=4]Refud Using Hex Editor (Work All Rat Crypter Keylogger Worm Bot Etc)[/h] http://www.youtube.com/watch?feature=player_embedded&v=34JuwNg9ECU Description: Perkongsian Ilmu Komputer | computer knowledge sharing: RE-FUD (under REFUD section) This method is hard . patient is needed This refud technique work with all stub ,crypter .net depencies , no dependencies ,worm ,trojan , all rat server ,keylogger ,stealer, botnet ,etc. For detail step, information and DOWNLOAD stuff... available at link below.. Perkongsian Ilmu Komputer | computer knowledge sharing: RE-FUD (under REFUD section) Sursa: Refud Using Hex Editor (Work All Rat Crypter Keylogger Worm Bot Etc)

[h=4]Automated Persistent Backdoor On Metasploit Framework[/h] Description: In This Video You will learn how to create automating persistent backdoors on our target using metasploit. After the exploitation Persistent backdoors works like RAT and accept all reverse https connections. And Watch this video How to create undetectable backdoors Video :- How To Create An Undetectable Backdoor (Bt5R2), Make Undetectable Backdoor Using Crypter.Py, How To Create An Undetectable Backdoor (Bt5R2) Sursa: Automated Persistent Backdoor On Metasploit Framework

[h=4]Backtrack 5 R2 Manual Sqlsus[/h] Description: SqlSus is an open source mysql injection and takeover tool. Using command line interface, we can retrieve the database structure, and we can inject our own SQL queries. we can download file from the web server, crawl the website. etc ... Tool :- Sqlsus - SecurityTube Tools Sursa: Backtrack 5 R2 Manual Sqlsus

[h=4]Flame Malware: An Overview[/h] Description: This video, with Sourcefire Chief Scientist Zulfikar Ramzan, provides a high-level description of the Flame (AKA Flamer, sKyWIPer) malware toolkit that appears to be a state-sponsored cyberweapon. Flame has similarities to other threats like Duqu and Stuxnet, but primarily functions as an infostealer. Sursa: Flame Malware: An Overview

[h=4]Metasploit With Microsoft Sql Server And Smb Exploits (Part 1/2)[/h] Description: A heap-based buffer overflow can occur when calling the undocumented "sp_replwritetovarbin" extended stored procedure. This vulnerability affects all versions of Microsoft SQL Server 2000 and 2005, Windows Internal Database, and Microsoft Desktop Engine (MSDE) without the updates supplied in MS09-004. Microsoft patched this vulnerability in SP3 for 2005 without any public mention. An authenticated database session is required to access the vulnerable code. That said, it is possible to access the vulnerable code via an SQL injection vulnerability. This exploit smashes several pointers, as shown below. 1. pointer to a 32-bit value that is set to 0 2. pointer to a 32-bit value that is set to a length influcenced by the buffer length. 3. pointer to a 32-bit value that is used as a vtable pointer. In MSSQL 2000, this value is referenced with a displacement of 0x38. For MSSQL 2005, the displacement is 0x10. The address of our buffer is conveniently stored in ecx when this instruction is executed. 4. On MSSQL 2005, an additional vtable ptr is smashed, which is referenced with a displacement of 4. This pointer is not used by this exploit. This particular exploit replaces the previous dual-method exploit. It uses a technique where the value contained in ecx becomes the stack. From there, return oriented programming is used to normalize the execution state and finally execute the payload via a "jmp esp". All addresses used were found within the sqlservr.exe memory space, yielding very reliable code execution using only a single query. NOTE: The MSSQL server service does not automatically restart by default. That said, some exceptions are caught and will not result in terminating the process. If the exploit crashes the service prior to hijacking the stack, it won't die. Otherwise, it's a goner. This video shows how to use Metasploit to gain access to a computer using a vulnerability in Microsoft SQL Server (1st step) and then using an SMB vulnerability (2nd step) to get administrative privileges. See part 2 for the exploitation of the access Sursa: Metasploit With Microsoft Sql Server And Smb Exploits (Part 1/2)

[h=2]XSS and CSRF via SWF Applets (SWFUpload, Plupload)[/h]Via: Defcamp [h=3]Summary[/h] Nathan Partlan and I discovered and reported vulnerabilities in two common Flash applets, SWFUpload and Plupload. SWFUpload’s developers have not released a fix for the XSS issue identified. Plupload’s developers have released v1.5.4 to address the identified CSRF issue. Both of these applets are present in WordPress installations. These vulnerabilities were addressed as part of WordPress 3.3.2. [h=3]Vulnerability #1: XSS in SWFUpload[/h] The latest version of SWFUpload (ActionScript code available here) contains the following code: // Get the movie name this.movieName = root.loaderInfo.parameters.movieName; // **Configure the callbacks** // The JavaScript tracks all the instances of SWFUpload on a page. We can access the instance // associated with this SWF file using the movieName. Each callback is accessible by making // a call directly to it on our instance. There is no error handling for undefined callback functions. // A developer would have to deliberately remove the default functions,set the variable to null, or remove // it from the init function. this.flashReady_Callback = "SWFUpload.instances[\"" + this.movieName + "\"].flashReady"; this.fileDialogStart_Callback = "SWFUpload.instances[\"" + this.movieName + "\"].fileDialogStart"; this.fileQueued_Callback = "SWFUpload.instances[\"" + this.movieName + "\"].fileQueued"; this.fileQueueError_Callback = "SWFUpload.instances[\"" + this.movieName + "\"].fileQueueError"; this.fileDialogComplete_Callback = "SWFUpload.instances[\"" + this.movieName + "\"].fileDialogComplete"; this.uploadStart_Callback = "SWFUpload.instances[\"" + this.movieName + "\"].uploadStart"; this.uploadProgress_Callback = "SWFUpload.instances[\"" + this.movieName + "\"].uploadProgress"; this.uploadError_Callback = "SWFUpload.instances[\"" + this.movieName + "\"].uploadError"; this.uploadSuccess_Callback = "SWFUpload.instances[\"" + this.movieName + "\"].uploadSuccess"; this.uploadComplete_Callback = "SWFUpload.instances[\"" + this.movieName + "\"].uploadComplete"; this.debug_Callback = "SWFUpload.instances[\"" + this.movieName + "\"].debug"; this.testExternalInterface_Callback = "SWFUpload.instances[\"" + this.movieName + "\"].testExternalInterface"; this.cleanUp_Callback = "SWFUpload.instances[\"" + this.movieName + "\"].cleanUp"; this.buttonAction_Callback = "SWFUpload.instances[\"" + this.movieName + "\"].buttonAction"; Each of those callbacks is used as the first parameter to ExternalInterface.call, which executes JavaScript in the context of the current page. Since movieName is derived from user input (a Flash parameter) and a Flash applet can be loaded directly (with parameters in the URL), the Flash applet allows for reflected cross-site scripting. For sites where the applet is hosted on the same domain as the main website, this is a serious security concern. At this point, I’m not aware of a patched version of the applet source (let me know in the comments if there is one!). My suggestion would be to filter the movieName parameter so that only alpha-numeric characters are allowed. Proof of Concept: [URL="http://demo.swfupload.org/v220/swfupload/swfupload.swf?movieName=%22]%29;%7Dcatch%28e%29%7B%7Dif%28%21self.a%29self.a=%21alert%281%29;//"]http://demo.swfupload.org/v220/swfupload/swfupload.swf?movieName=%22]%29;}catch%28e%29{}if%28!self.a%29self.a=!alert%281%29;//[/URL] [h=3]Vulnerability #2: CSRF in Plupload[/h] The Plupload applet called Security.allowDomain('*') to allow the applet to be used from any domain (so it could be served from S3, for instance). That meant people could interact with the Plupload applet from any other site on the Internet by embedding it on a page and using JavaScript. But due to the way the same-origin policy works in Flash, the applet could still make requests back to the domain on which it was hosted. In addition, people can specify the full URL for an upload request via JavaScript and the result of that request (ie: the HTML of the resulting page) is passed back via JavaScript to the embedding page. So, if an attacker could convince a target to interact with the applet (by selecting a single file to be uploaded), the attacker could make a request to the domain that the applet was hosted on and read back the full response. That could disclose CSRF tokens or other sensitive information. This issue was especially important for WordPress installations, where Plupload applets are hosted inside of the wp-includes directory by default. The issue was resolved by removing the call to Security.allowDomain('*') by default. [h=3]Conclusion[/h] Third-party Flash applets are vulnerable to many of the same sorts of attacks as other parts of web applications. However, they are often included in sites without a proper understanding of the security risks. Sursa: https://nealpoole.com/blog/2012/05/xss-and-csrf-via-swf-applets-swfupload-plupload/

Carbylamine - A PHP Script Encoder to 'Obfuscate/Encode' PHP Files Posted by FlashcRew at 14:33 Via: Defcamp Carbylamine PHP Encoder is a PHP Encoder to 'Obfuscate/Encode' PHP File, Faster way to encode your malwares offline. How to use: carbylamine.php Download carbylamine Home project it's here Sursa: Carbylamine - A PHP Script Encoder to 'Obfuscate/Encode' PHP Files | fLaShcRew

[h=2]Wireshark: Listening to VoIP Conversations from Packet Captures[/h]Author: ~ by D. Dieterle on May 21, 2012. I have never done a lot with “Voice over IP” or VoIP systems, but ran into this today and thought it was pretty cool. A lot of telephones and communication devices now use VoIP to communicate over the internet. I was wondering how hard it would be to listen to a VoIP phone call if you had a packet capture that included the call. How hard would it be, I wondered, to scan a packet capture, find the calls and be able to somehow listen to the call. Well, come to find out, it is not hard at all. The feature is built into Wireshark! And they also include a file capture on their website so you can try it out. So…. Let’s do it! 1. Download the sample capture from Wireshark’s website. 2. Run Wireshark and open the packet capture. 3. Now all you need to do is go to the menu bar, select “Telephony” and the “VoIP Calls”: 4. Okay, a list of calls from the packet capture will show up. Pick the one you want to listen to, in this sample the first one is the only one that really has a conversation: 5. Okay, easy peasy, just select the call you want, click “Player” then “Decode”: 6. The player screen shows up and shows the Waveforms of the conversation. You will have two, one for each side of the call. You can listen to each side individually, or if you tick both check boxes you can listen to the conversation as it plays out: That’s it, if the VoIP conversation is in a protocol that WireShark understands, and is not encrypted, you can very simply isolate the call and listen to it via WireShark. As always, do not try these techniques on a network or on systems that you do not have permission to do so. Also, check your local laws regarding communication privacy and telephony before trying something like this in real life. Sursa: Wireshark: Listening to VoIP Conversations from Packet Captures