He loves to work with his headphones on listening hip hop music, which leads to him avoiding interactions with the other team members.
It may help to remember that there's nothing inherently wrong with listening to music - many developers often work with headphones on and music playing to help them focus, and most I know that work this way will happily be interrupted if the need arises.
He spends a lot of time with the scrum master and makes a lot of decisions without talking to the other developers. When someone asks him something he often replies with "This is not your problem" or "You don't need to know this thing to work on your task".
Again, some of this behaviour may be ok, in the grand scheme of things. Some business related decisions may well be irrelevant to the team, and the scrum master shielding the team from that could well be a wise thing to do.
From the way you've asked the question though, it sounds like the scrum master has tried to go too far in this regard, and it sounds like your team leader may be confusing the role of "scrum master" with "manager". I know I'm likely preaching to the converted here, but the scrum master's purpose is to act as a facilitator for the team, removing obstacles, helping them reach decisions and keeping them focused. It sounds like your scrum master is, by working with the team lead this way, having the opposite effect.
Are you still following the agile processes properly - i.e. having stand-up meetings and interacting with each other at least to that degree? If not, that should be a priority, and you should be pushing to get those back. I'm a similar fan of occasional face-to-face code reviews for this reason too, so long as it doesn't become a "my code's better than yours mud slinging contest", it's often a great time to provide a springboard to share knowledge / compare approaches.
Some companies also have a morning / day a month set aside for an internal seminar of sorts - someone each month is allocated some time to research on a technology or approach that they feel would be useful to present, then they're invited to present it for discussion. This can also work really well to get people communicating and discussing.
Beyond that, my focus would be to try to bring your concerns to the scrum master, and see if he acts like a scrum master should. Talk to him, preferably as a team, and say why you feel that it's important you're kept in the loop on the rationale behind certain decisions.
