Team casual in their approach

I have been given a team who is a little too casual in their approach when it comes to following scrum.

This isn't necessarily a problem. Scrum is a framework that has a bunch of good ideas, but not all of it may make sense for all organizations.

We have 10 working days in any given sprint. There is not even a single story that reaches for testing in the first 5 days. Stories starts coming in from the 6th or 7th day. Although the team manages to finish off the work and we have never carried on with a story after the sprint finishes.

Are you in an environment that, for contractual, legal, regulatory, or other compliance purposes needs testing to be done by someone who did not develop the work? It sounds like you have a handoff between a development team and a test team. I would want to make sure that this handoff is absolutely necessary, and if it's not necessary I would want to eliminate it. Even if independent testing is required, I would build the skills of the Development Team to perform all testing such that the handoff is for paperwork and compliance purposes only - finding any issues in this post-handoff testing is extremely rare and would get scrutiny in a retrospective.

In the daily status call, the resources keep pushing the timelines and then deliver stories on 6th and 7th day. I dont want to impose anything on them neither I want to look a fool by being lenient. For example, a new resource in the team was given a UI story that was estimated at 8 and it was told initially that since the resource has never picked UI story we can cut him some slack. This is justified, however today is the 2nd last day of  the sprint (sprint ends tomorrow) and half of the day has passed, but he has not delivered the story yet.

Two things immediately jump out. The Daily Scrum is a planning session, not a status session - the focus should be on regrouping and planning how to progress toward the Sprint Goals. I also don't like "resources" to refer to the people doing the work. Both of these can lead down some risky paths.

Having someone "given" work also doesn't seem right. I've had better experiences with people taking the most important unblocked work from an ordered list that they are capable of working on. This, coupled with working to cross-train to maximize the work that each individual can pick up, aligns much closer with cross-functional teams and maximizes the ability to do more work faster of the team. Depending on the experience and complexity, there may be some times where people need to pair up (or have larger group sessions) for learning, so it's about balancing learning with delivery, and that's a negotiation between the Development Team (who ideally should be advocating for ensuring they are learning new and necessary skills) and the Product Owner (who is advocating for maximizing value delivery and understands business and stakeholder needs), facilitated by the Scrum Master.

This may be something to discuss at the retrospective. I'd focus on two things. The first is the purpose of the Daily Scrum as a planning and coordination meeting and not a status meeting. The second is the need to raise impediments early to understand why work is not being started or completed by the Development Team.

Moreover, I want the team to be self organizing and manageable hence I let them take decisions and be on the backfoot.

It doesn't sound like the team is ready to make decisions on their own. Some teams need more active guidance before they reach that level of maturity. Sometimes, someone needs to enforce some minimal process framework first along with rationale for each part of it. Then, once the team is comfortable with what, they can get into why it's important or necessary for them and begin to make changes.

Also, when i try having a conversation on the scrum values, people take it so lightly and are least interested in understanding how can they be benifitted. They instead take it that something needs to be delivered in 10 days, thats it.

This is a hard one, but the emphasis needs to be on two things: (1) how the team can benefit and (2) how the team's way of working benefits stakeholders.

I have been given a team who is a little too casual in their approach when it comes to following scrum. 

Is there any demand for a higher level of performance, and if so where is it coming from? What threats are realistically being faced, and which require the team to up its game? Will customers be dissatisfied and move on for example, or might better performing competitors emerge who disrupt the market?

I am worried if I am being too lenient with them.

This statement makes me feel like you believe that the Scrum Master should be more command-control rather servant-leader.  How can you be too lenient when you job is to facilitate for them to be self-organizing and make their own decisions on how to do the work? You might ineffective in that role but I have never seen a Scrum Master doing the job as described by the Scrum Guide be too lenient. 

Everything that @Thomas and @Ian have provided is really good advice. You can't come in and demand change. You can suggest it but in the interest of transparency you should always share how you came to your recommendation and how you believe it will be beneficial. Then leave it up to the team to decide if they want to implement it. If they choose not to, feel free to bring it up again when the timing is right such as immediately following a situation where your suggestion could have made things easier or more productive. 

As @Thomas mentioned it doesn't sound like this team is mature enough in their agile knowledge to appreciate the benefits of self-management.  You might need to focus more on that aspect only and my suggestion is that it be the first thing you focus on.  Part of being a servant-leader is that last part.  A leader will allow the team to make decisions but if they cannot come to a consensus, the leader will make a decision for them while explaining how they came to that decision and how they believe it will be beneficial. Suggest it as an "experiment" or "starting point for adaption" so that they know they still have the ability to change it on their own. 

My advice is that you don't attempt sweeping changes.  Agile promotes incremental delivery of value and improvements in team dynamics does have value. So incrementally introduce improvements and let the team see the benefits of each one before moving to the next.  This will also help the team to understand your role and that you have the skills and knowledge to do that job to the benefit of them and the company as a whole.