Biblio
Initially, legitimate users were working under a normal web browser to do all activities over the internet [1]. To get more secure service and to get protection against Bot activity, the legitimate users switched their activity from Normal web browser to low latency anonymous communication such as Tor Browser. The Traffic monitoring in Tor Network is difficult as the packets are traveling from source to destination in an encrypted fashion and the Tor network hides its identity from destination. But lately, even the illegitimate users such as attackers/criminals started their activity on the Tor browser. The secured Tor network makes the detection of Botnet more difficult. The existing tools for botnet detection became inefficient against Tor-based bots because of the features of the Tor browser. As the Tor Browser is highly secure and because of the ethical issues, doing practical experiments on it is not advisable which could affect the performance and functionality of the Tor browser. It may also affect the endanger users in situations where the failure of Tor's anonymity has severe consequences. So, in the proposed research work, Private Tor Networks (PTN) on physical or virtual machines with dedicated resources have been created along with Trusted Middle Node. The motivation behind the trusted middle node is to make the Private Tor network more efficient and to increase its performance.
Browser extensions have by and large become a normal and accepted omnipresent feature within modern browsers. However, since their inception, browser extensions have remained under scrutiny for opening vulnerabilities for users. While a large amount of effort has been dedicated to patching such issues as they arise, including the implementation of extension sandboxes and explicit permissions, issues remain within the browser extension ecosystem through user-scripts. User-scripts, or micro-script extensions hosted by a top-level extension, are largely unregulated but inherit the permissions of the top-level application manager, which popularly includes extensions such as Greasemonkey, Tampermonkey, or xStyle. While most user-scripts are docile and serve a specific beneficial functionality, due to their inherently open nature and the unregulated ecosystem, they are easy for malicious parties to exploit. Common attacks through this method involve hijacking of DOM elements to execute malicious javascript and/or XSS attacks, although other more advanced attacks can be deployed as well. User-scripts have not received much attention, and this vulnerability has persisted despite attempts to make browser extensions more secure. This ongoing vulnerability remains an unknown threat to many users who employ user-scripts, and circumvents security mechanisms otherwise put in place by browsers. This paper discusses this extension derivative vulnerability as it pertains to current browser security paradigms.
Cloud computing provides so many groundbreaking advantages over native computing servers like to improve capacity and decrease costs, but meanwhile, it carries many security issues also. In this paper, we find the feasible security attacks made about cloud computing, including Wrapping, Browser Malware-Injection and Flooding attacks, and also problems caused by accountability checking. We have also analyzed the honey pot attack and its procedural intrusion way into the system. This paper on overall deals with the most common security breaches in cloud computing and finally honey pot, in particular, to analyze its intrusion way. Our major scope is to do overall security, analyze in the cloud and then to take up with a particular attack to deal with granular level. Honey pot is the one such attack that is taken into account and its intrusion policies are analyzed. The specific honey pot algorithm is in the queue as the extension of this project in the future.
Modern Browsers have become sophisticated applications, providing a portal to the web. Browsers host a complex mix of interpreters such as HTML and JavaScript, allowing not only useful functionality but also malicious activities, known as browser-hijacking. These attacks can be particularly difficult to detect, as they usually operate within the scope of normal browser behaviour. CryptoJacking is a form of browser-hijacking that has emerged as a result of the increased popularity and profitability of cryptocurrencies, and the introduction of new cryptocurrencies that promote CPU-based mining. This paper proposes MANiC (Multi-step AssessmeNt for Crypto-miners), a system to detect CryptoJacking websites. It uses regular expressions that are compiled in accordance with the API structure of different miner families. This allows the detection of crypto-mining scripts and the extraction of parameters that could be used to detect suspicious behaviour associated with CryptoJacking. When MANiC was used to analyse the Alexa top 1m websites, it detected 887 malicious URLs containing miners from 11 different families and demonstrated favourable results when compared to related CryptoJacking research. We demonstrate that MANiC can be used to provide insights into this new threat, to identify new potential features of interest and to establish a ground-truth dataset, assisting future research.
The early discovery of security bugs in JavaScript (JS) engines is crucial for protecting Internet users from adversaries abusing zero-day vulnerabilities. Browser vendors, bug bounty hunters, and security researchers have been eager to find such security bugs by leveraging state-of-the-art fuzzers as well as their domain expertise. They report a bug when observing a crash after executing their JS test since a crash is an early indicator of a potential bug. However, it is difficult to identify whether such a crash indeed invokes security bugs in JS engines. Thus, unskilled bug reporters are unable to assess the security severity of their new bugs with JS engine crashes. Today, this classification of a reported security bug is completely manual, depending on the verdicts from JS engine vendors. We investigated the feasibility of applying various machine learning classifiers to determine whether an observed crash triggers a security bug. We designed and implemented CRScope, which classifies security and non-security bugs from given crash-dump files. Our experimental results on 766 crash instances demonstrate that CRScope achieved 0.85, 0.89, and 0.93 Area Under Curve (AUC) for Chakra, V8, and SpiderMonkey crashes, respectively. CRScope also achieved 0.84, 0.89, and 0.95 precision for Chakra, V8, and SpiderMonkey crashes, respectively. This outperforms the previous study and existing tools including Exploitable and AddressSanitizer. CRScope is capable of learning domain-specific expertise from the past verdicts on reported bugs and automatically classifying JS engine security bugs, which helps improve the scalable classification of security bugs.