It’s been an eventful year for creative artificial intelligence (AI). The release of major language models (LLMs) has demonstrated how powerful technology can be to make business processes more efficient. Many organizations are now racing to adopt generative AI and train models on their datasets.
Developing and training AI models can be an expensive endeavor and they can easily become one of the most valuable assets a company has. It is therefore important to keep in mind that these models are susceptible to theft and other attacks, and the systems hosting them need to have strong security safeguards and policies in place.
A recent vulnerability in MLflow, an open-source machine learning lifecycle platform, highlights how sensitive training data can be exposed to attackers when a developer visits a random website on the Internet from the same machine where MLflow runs. How easy it can be to steal or poison The flaw, tracked as CVE-2023-43472, was fixed in MLflow 2.9.0.
Localhost attacks via malicious JavaScript code
Many developers believe that services bound to localhost—the computer’s internal hostname—cannot be targeted from the Internet. However, this is a false assumption, according to Joseph Beaton, a senior application security researcher at Contrast Security, who recently spoke at the DefCamp Security Conference on attacking developer environments via localhost services.
Beeton recently discovered critical vulnerabilities in the Quarkus Java Framework and MLflow that could allow remote attackers to exploit features of development interfaces or APIs natively exposed by these applications. Attacks would only require a computer user to visit a website controlled by the attacker or a legitimate site in their browser where the attacker is able to place specially crafted advertisements.
Drive-through attacks have been around for years, but they are powerful when combined with the vulnerability of cross-site request forgery (CSRF) in an application. In the past, hackers used drive-by attacks through malicious advertisements placed on websites to hijack the DNS settings of users’ home routers. In general, browsers only allow JavaScript code to make requests for resources from the same origin (domain). A special mechanism called Cross-Origin Resource Sharing (CORS) can be used to circumvent this restriction and allows scripts to make requests to different origins if specifically allowed by the target server.
For example, if domain A tries to request domain B by loading a piece of JavaScript code into the browser, the browser will first perform a so-called preflight request to check whether the domain B has a CORS policy that allows scripted requests. Domain A. While this applies to localhost as well, Batten points out that there is another type of request called a simple request that most browsers (except Safari) still allow that make a pre-flight request. doesn’t trigger because it predates CORS. Such requests are used, for example, by the HTML standard