Rule #1 is: Don't badmouth the existing code. Just complaining about the poor quality of the code is not very helpful and it can be dangerous. I vividly remember saying to another developer, "this code appears to have been written by someone who doesn't understand the basic concepts of
Java concurrency", only to find out later that it was written by the person I was talking to. *cringe*
When trying to convince management/business side to allocate time for refactoring, you have to frame the discussion in terms they understand. As developers, the main reason we want to refactor is to make the code easier to work with, reason about and extend. In other words, to make our own jobs more enjoyable. Unfortunately, for the business as a whole, "happier developers" is not a primary goal. It doesn't directly generate value for the business. (Of course, having happier, more motivated employees has an indirect effect on the health and profitability of the company, but there's a long chain of cause and effect in between.)
So try to come up with a way to express the benefits of refactoring in terms that management can understand. e.g. "Without refactoring, feature X will take N weeks to implement. If we spend a week on refactoring beforehand, feature X will take 2*N/3 weeks to implement, and future development will also be faster." Or "The web app currently has hundreds of XSS vulnerabilities, putting our users at risk. If we don't refactor and we instead try to fix them one by one, it'll take a year to fix them all, and we might accidentally miss some."